The second last talk I attended at the conference was on the topic of managing multiple AWS accounts while still keeping secure. The speaker was Andrew Bienert, a security architect at SEEK.
Andrew started by saying that the median time between intrusion of a system and detection is 81 days. That's nearly 3 months that someone is in your system, poking around, trying to spread the scope of their access. 81% of hackers who were interviewed said that once they were inside a system, they could infiltrate and export data within 12 hours. Keeping your perimeter safe is important, but it's also important to make sure that access within your systems is controlled so that a compromise in one system doesn't result in all of your other systems being compromised, too.
Sharing prod AWS accounts within an organisation is tough once you have too many applications. You tend to hit a bunch of limits, such as running out of IP space, or having too many instances of a particular service. What tends to happen at this point is that you start to split your services across multiple AWS accounts. He mentioned Conway's law, which states that "organisations which design systems... are constrained to produce designs which are copies of the communication structures of these organisations." The problem with having so many accounts is that these services will need to be able to share information between them, but in a way that prevents an attacker from also gaining access to that information. It's fairly easy when you have two systems A and B, and you just need to be sure that A can access B and B can access A.
Once you start to get to what SEEK has, which is over 99 systems, it becomes far more complex. System Q might need to talk to Systems D and J, F needs to talk to C and W. How do you keep track and make sure the systems have only what they need to? Add to that the fact that systems will become obsolete, and you also need to make sure the permissions it had are also revoked, as we learned in a previous talk that being able to guess the role name of someone who has access is one step towards gaining access yourself.
To be honest, some of this went over my head, as I'm not that familiar with AWS, so I'll try to note as much as I think I managed to understand.
It's important to log everything, this can help you track intrusions.
Ensure all S3 buckets are private, unless whitelisted. You can use Cloud Custodian (https://github.com/capitalone/cloud-custodian)to help with this.
You can also create a honeypot resource with monitoring (e.g. CloudTrail). None of your systems will use it, so you know if someone has accessed it, then you have an intruder.
And.... that's all I managed to get from the talk. It was a bit tough, as it was right after lunch, so the food coma feeling hit pretty hard. :(
No comments:
Post a Comment