If I were looking for vulnerabilities I'd probably start with any XSS. Chances are the credit card data is locked down tight and encrypted. But what if I can scoop it up as it gets transformed into a token? Also look at where you store the encryption keys to decrypt the card data. There are hardware devices you can use that are especially hardened.
The problem with bitcoin is that it necessitates an even more secure architecture because you don't have a 3rd party to run to if things hit the fan. Suppose all your credit #s got stolen in this case. You can run to Visa/Mastercard and they will invalidate the card #s in bulk. Or at least do monitoring on them. What do you do when all your bitcoins are stolen?
Then you check these two different modalities of tracking money conclude your the same liquidity measure for your company.
If they do not then you have sprung a leak somewhere and can halt everything.
That would be an extra layer of security. Passing loads of tokens round is still a single point of failure at the conceptual level.
If ledgering is interesting to you, http://blog.balancedpayments.com/the-ledger/ and http://blog.balancedpayments.com/state-machines/ are what you're going to want to read.
I first have to give you a thumbs-up for calling your fraud detection layer "precog".
Does AWS let you firewall off Knox from the open internet? PayPal's architecture has most of the machines that touch payments isolated behind hardware firewalls, with only certain front-end machines able to punch through the firewall.
Once closed off from the world, only your servers within the public subnets can access those in the private subnet. By default, the private subnet can't talk to the outside world. You'd typically setup a NAT instance in your public subnet that tunnels your private subnet's internet to the outside world (because the NAT is in a public subnet, it can access the outside world).
That's just an example setup. It's a very powerful tool for securing your infrastructure. For example, you should typically put your databases, and anything that isn't password protected that stores information or something (except web servers) in a private network so that only your public servers have access to them.
User -> Public Network -> Public Server -> Private Network -> Private Server -> NAT (Tunnel) -> Public Network -> Internet
VPC does take quite a bit of effort to setup, but after that, it's pretty straightforward.
I'm sure Amazon does a lot on securing its infrastructure, but for credit card data wouldn't a physical, fenced off server be more secure?
It's also worth noting that Amazon.com itself is hosted off AWS (since ~2010) though I'm struggling to find a good cite for that
I got asked this on Twitter, you might find the thread worthwhile: https://twitter.com/moritzheiber/status/442037431089786881
It seems like a lot of people are interested in hearing more details, so I'll try to get into that eventually in another post. Always more to talk about!
We wrote about logging here: http://blog.balancedpayments.com/status-page/
> We already log these to a centralized server using RSYSLOG, so I already had
> a data source to draw from. Next, I went and brewed a fresh pot of coffee and
> bestowed it upon bninja for his prescient work in building our log parser,
> Slurp. We wrote a quick Slurp script that read the HTTP status code from each
> request and then fed them into Graphite buckets. Each bucket was based on
> service name (DASHBOARD, API, JS) and then response code family (2xx, 3xx,
> 4xx, 5xx, and a special case timeout for slow requests).
It's honestly a mystery to me why the system even lets submitters specify titles.
But I could be paranoid.
That doesn't seem to be the case: