3 Basic Controls to Improve your AWS Security Posture
foundational security measures to prevent getting rekt from hackers
Howdy anon, Celt here to talk about some foundational AWS security measures. Many people think these things are basic, yet every year we hear about hacks that occurred because of one of the following reasons. Consider these day 0 type security controls, these are basic. Regardless, security fundamentals are the most important, as more advanced security measures do not help if the foundation is not there. Again, some customers legitimately either do not know the following information, or just ignore it because they don’t realize the consequences. So lets start from the fundamentals and work our way up to the advanced controls.
Do not use the account root user
Always mentioned at almost every AWS security talk, yet people still dont get this right. Do not regularly (ideally ever) use the account root user. The account root user should be used for emergencies, if at all. The best practice would be to create an IAM role for admins. This probably sounds dumb, why not use the root account they have the same permissions in this case? There is a caveat that makes this incorrect. The reason for this is because the account root user cannot have privileges revoked or decreased. If someone has access to your account root user you are rekt, they can do anything on the account. Conversely, if a nefarious hacker were to get access to an admin account, you would be able to revoke the credentials and remove permissions from the user. Simple control that can save you from serious damage.
Turbo Note: You can set up monitoring for the account root user logins. It would look something like:
This is not going to cost you very much, and overall good for your posture to have some kind of monitoring in place. This will not cost you very much because Lambda is serverless compute, which has advantages you can read about on my previous post about serverless. If someone is using the account root user, you need find out and remediate the issue. Setting up alerting will allow you to do that. The output of this could even go into a compliance report. Would not be unusual for Info/Cyber sec folks to be tracking the number of account root user logins.
Use Multi-Factor Authentication (MFA)
Again, some of you probably think this is really dumb. But the security fundamentals are the cornerstone of security posture. Somewhere in your authentication process there should be at least a second form of authentication. Root account user 100% *needs* multi-factor, this is non-negotiable. At least for production account access there should be MFA enabled. For MFA we prefer hardware device or U2F security key > app generators like Duo > SMS. More from AWS on MFA here
Hacks are becoming more and more popular. No one wants to be the reason why, and cyber security is on the mind of every business leader. One of the easiest way to reduce your exposure for an attack is to enable MFA. You also may have MFA built into your federated authentication process, that is probably enough to check this box as well.
Overall, use MFA wherever you can. Easy way to reduce the probability of an attack, and if there is one, you can say you at least had MFA enabled.
Adhering to the principle of least privilege
Almost every AWS talk you are going to hear the phrase “following the principle of least privilege”. If you don’t listen to any talks, that is alright, because i do that for you. Simply put, least principle means giving only the permissions that are *needed*. Easy to say, but harder to implement and control in practice. It is paramount to not be cavalier with what permissions are given. This sounds obvious but in reality it is really easy just to give someone admin or full privileges to a service. This is a huge mistake. If you are applying for an AWS security engineer position or something like that, expect a question on how to implement and control least privilege. It is just that important. You would need to determine the different personas that need access to AWS, what services, and what service capabilities they would need access to. For example granular role for business analysts that has read only access to billing information on the organization root account. Not following least privilege would be something like just giving business analysts full access to the organization root account. If someone has permissions they don’t *need* its only a matter of time until it goes wrong.
Turbo note: security and developer productivity are on a pendulum. Not enough permissions and developer productivity is decreased, too much and they accidently nuke something. There needs to be a dialogue open with the different engineering departments to what their people need. These needs often change over time as new services are onboarded to the company’s approved services. The one role approach for all of engineering is a bad approach. One example: the full stack developers do not need access to the machine learning infrastructure, so taking the one engineering role approach is not going to work either.
Conclusion
Thanks for reading anons. I know for a lot of you this is probably basic, but really question if you are doing all of these things. The more advanced things I am going to cover is not going to be helpful if the above controls are not in place. Fundamentals are always the most important, nothing new here.
Help My SubStack Grow
I appreciate every one of you, if you like my work please consider subscribing and sharing. There is much more to come frens.