Hacker News new | past | comments | ask | show | jobs | submit login

Part of my job is designing software that is resistant to amplification once the hacker is already in, so maybe I can help here.

When you plan your security, step 1 is making it hard to get in, step 2 is making it hard to persist, i.e. plant a command and control process somewhere inside the perimeter, and to move laterally in the system, i.e. get from one service into a more important service.

There's some basic stuff, such as firewall rules that prevent outbound traffic from ports/processes you aren't expecting. That makes it harder for the hacker's command and control systems to get instructions. There's other stuff like using separate credentials for low sensitivity vs high sensitivity systems, two-stage approval processes for especially sensitive operations to prevent a single compromised user from being able to get to the good stuff, automatic password rotation so that exfiltrated tokens aren't valuable, and more.

Those are just single things though. I think the more interesting part is an exercise like this: assume that the hackers have compromised a developer's computer. In that case, what does a system look like that would prevent that developer from exfiltrating payment info? I would argue that the developer doesn't normally need access to real payment info, so maybe the network should be configured so that the developer is unable to SSH into that set of database servers without first requesting a special short-lived SSH keypair. That at least means the developer has to explicitly ask for access. That doesn't make the hacker's job impossible, it just makes it harder. Also makes things less convenient for the developer, so is it worth the trade-off? For especially sensitive data, it probably is. With this setup, maybe the hacker gets to the account information, but they're stopped short of account numbers long enough to notice the breach.

This is all on the theoretical side, but that's the thought exercise once you go "let's pretend someone compromised ____ system."




One of my favorite Hacktober tricks was putting an alias around SSH on the developers machine, so the next time they used 2FA to get into a remote host I would drop a note into their MOTD (to prove persistence). That short-lived SSH token would be enough to install persistence.

So obviously, your payment hosts should be very wary of things like port forwarding over SSH, and any unknown outbound traffic.


Yup, at some point it just becomes an arms race.

The fundamental imbalance in such an arms race is that the tech giant might have countermeasures that would prevent the SSH alias from working (my team does), but the level of paranoia required to get those countermeasures in place is beyond what a bank could effectively implement. This particular battle disproportionately favors the red team.

And that's not to say that my team has everything covered. The red team consistently manages to find forehead slapping holes in our defenses. There's just too much surface area to cover.


Really enjoyed reading this, thank you for the time you put into it and the clear explanation.




Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: