Why you need a dedicated AWS security account

“Please provide proof that these logs haven’t been tampered with.”

It’s the nightmare scenario for any IT department. You’ve been  notified by an auditor – or a legal team, a government body, or even a  customer — that your cloud security program is being reviewed. You’ve  been told to provide reams of logs and monitoring data, and you need to  show that you’ve guarded them so professionally that they have never  ever been tampered.

It’s hard enough technically to pull this off… if you’re like me,  your jaw is tightening a bit just thinking about the unpleasant feeling  of thrashing around while under the microscope from your management,  board, government, or even the media.

There’s a refreshingly simple answer to all this, and you can deploy  it today. You can guarantee, from this point forward, that the  security-related data you collect – whether it be logs, monitoring data,  access logs, or anything else – be totally private, available, secure,  and completely untouched and untampered with.

It’s call the AWS Security-only account, and it’s like a black hole  for security data. Everything goes in, but nothing comes out.

When I first heard about a dedicated security account, I thought it  was overkill. It’s hard enough to know what is going on with a single  account. Why would you add to the trouble? Now you have multiple root  account credentials, not just one. And so on.

But it turns out the benefits outweigh the administrative overhead.  The clean separation of concerns gives you an undeniably strong cutoff  between your production data and all things security. This is a huge  asset when it comes to organizing and analyzing security data. At some  point you’re going to have to get really serious about digging deep  through some application logs, or combing through what happened with  that weird SSH session. You want people to easily read the logs without  worrying that they will be deleted or modified.

Yes, you can accomplish this in your own account, but it’s just so  much easier to do it in a dedicated security account. How do you do it?  It’s easy: you literally only have two policies in the security account.

1. Write-only security data generator. this policy allows writing  data, but not reading or deleting. You will assign this to a cross  account role in your security account. Some principal in your production  account will assume this role when it comes time to send logs to your  security account. This is the only function of this policy.
2. Then,  you have a read-only policy. This policy allows reading all sorts of  logs and data, but cannot write / update / delete. This is the only  policy you give to any Role or Group in the security account. The only  thing you do when you log in, is read stuff. That is what an auditor  does.

Why this emphasis on a clear separation of duties?

Because of the “I” in CIA – confidentiality, integrity, and  availability. It is essential that data have integrity – meaning you can  trust it hasn’t been tampered with.Logs that have been tampered with  are no longer the truth.

Here are the best practices for implementing a security-only account so that you can breeze effortlessly through any audit.

• send all logs into a write-only account.
• then make roles  that are read only. The only thing that can write are cross-account  roles. No account in the security account can create anything.
• Even the creation of infrastructure should be from a cross account role.
• Create a security admin also from another account else
• Create an auditor Group. It’s just read only.
• Create  a security datalake in the security account. Then, send to it logs  from:cloudtrail (all api actions), vpc flowlogs (look at questionable ip  traffic for example), guard duty findings, config logs, macie findings,  application logs.
• Application logs especially are essential  because a good hacker will try to cover up his tracks by modifying the  logs, or deleting the logs.
• 2-factor delete on the security data  lake. This is an extra layer of protection because you shouldn’t have  any roles that have the ability to modify data anyway
• Alarms when someone attempts to delete log generation from the destination
• After a certain period, when the data is not longer “hot”, use glacier vault to archive and save money.
• Encrypt  data during the entire lifecycle. Strangely, KMS this doesn’t work  across regions – you can’t easily pass KMS data keys or Customer managed  keys between regions. So, keep the data in the region where it  originated.

Well, we’ve seen that with a security-only account, you can guarantee  the three pillars of the CIA triad – availability (S3 is at least 9 9’s  of availability), integrity (MD5 hash checking and the limitation of  roles – no role in the account is able to delete or edit logs of any  kind), and finally confidentiality (again, the limitation of roles — who  can even log in and assume the role of auditor).

If this sounds great but the implementation in your specific  situation sounds daunting, annoying, or time-consuming, contact us. We  implement security-only accounts on day 1 of our engagements with all  our customers, and begin pointing the most essential  security-data-producing assets to it.