Welcome to Day 3 of the "How to AWS" series: Security
If you missed the introduction and drivers behind this series, check it out here.
In our previous blog post in this series we:
- Considered how you will interact and utilise AWS moving forward
- Selected the best AWS regions for your business
- Discussed identity management
- Proposed guiding principles and standards to strive for
Today we will be discussing Security. Security is a First Class Citizen in AWS and should be front and centre in your minds in everything you design and deploy. In AWS the implementation of a secure, auditable, transparent and hardened environment for your workloads is readily achievable but does require some foresight and planning.
Know your responsibilities!
Right from the start, you need to know what you are responsible for, what AWS is responsible for, and what your third party suppliers or partners are responsible for. I can't stress enough the importance of knowing who is responsible and accountable for securing and managing your environments!
To this end, AWS are very upfront with their Shared Responsibility Model. This model provides a very clear cut definition of who looks after certain aspects of your cloud environment.
To borrow a sentiment from the wider industry: “AWS looks after the security of the cloud, you look after the security of the things in the cloud”.
Beware however, as with all things, there are exceptions to these rules. This model does change as you use different services available within AWS. As you leverage PaaS or AWS-Managed services, you offload some management and security responsibility to AWS. This can absolutely lighten both the operational and regulatory requirements for your AWS environment. Be sure to review the responsibility model for each service within AWS to know where you stand!
As you engage partners or Managed Service Providers, are you clear on the lines of responsibility? You should be. Just as you share responsibility with AWS, any engaged partners also share certain aspects of responsibility for your environment.
Important aspects fall through the cracks if you don't know who is accountable for which aspect! If you don't know, now is the time to check and ask the questions!
Checkout our free checklist on how to choose the right Managed Service Provider for your business.
Define your Security Policy
Yes, you need one. I'm not going to tell you how to write one here, but below are some key concepts to consider when setting up your baseline security in AWS.
Start with your stance we determined in our last blog post, how will you treat/interact with AWS? This informs your overarching security stance.
Are you subject to any industry or government regulations? If so, these will often shape your minimum requirements for your AWS environment.
Documentation as to who is responsible for each aspect within your AWS environment can be super critical. This is compounded when there may be multiple parties working together! Knowing who is responsible for what leaves no ambiguity.
Everything you implement should be secure from the ground up. AWS provide secure but sane defaults across the board. Ensure you know what they are and if they're appropriate for your environment.
Secure from Day 1
Beware of the “lets open it up for now, we will lock it down later” conversation - odds are you won't get back around to it later. Have you ever heard this conversation? “Locking down the rules is old news, not a priority and might break the app all over again. Besides, we’ve got live customers on the platform now. We can't have that. Let’s focus on...”
You are much better off working it out from the start and if you don't know, there are tools to help with this!
Log those events
Ensure you have traceability of all events. In AWS the minimum baseline is ensuring you have AWS CloudTrail and AWS Config enabled. Remember that AWS account we set up to hold your audit data in the Day 1 blog post? You should put the associated S3 buckets in there! It's not that I don't trust you or your team, but if something malicious does happen, don't let that actor delete the audit logs as well! Separation of concerns is king here!
Remember, the worst attacks can come from within, often carrying admin level privileges!
Define and setup your AWS Config rules. These will help you check your environment and report on the compliance of resources within your account. Leverage the AWS-supplied ones and extend to meet your own requirements with custom rules.
As a pro tip, use CloudFormation StackSets to implement your policies across your entire AWS Organisation from the one location - This will be the master, consolidated billing account.
Each of your AWS accounts will have root credentials. You should secure these with strong passwords, multi-factor authentication (MFA) tokens and not use these accounts for business as usual activities. AWS Identity and Access Management (IAM) can give you all the access you need for day to day activities.
Speaking of IAM, your security policy should cover how you will be granting permissions to users. As a best practice, leverage groups for granting similar privileges to IAM users. This simplifies your management overhead. You will also use roles for your granting permissions for cross account role access and programmatic access to AWS APIs from your EC2 instances or Lambda functions.
You should always adhere to the principle of “least privilege”.
For your IAM policies, consider using the AWS-Managed policies, but ascertain whether the permission set is correct for you. Bear in mind the possibility that these policies may be updated over time to accommodate new features. This is a two-edged sword, on one hand AWS are maintaining your permissions for you, but on the other you have permission scope creep for users which you may not expect or control. There is your trade off.
The AWS Managed roles are “service” focused (e.g. EC2FullAccess) or “Job Function” focused (e.g. Network Administrator). What you use is up to you and your specific requirements.
All IAM users should have MFA enabled on their IAM accounts. This can be a hardware token (see MFA recommendations) or a virtual device (e.g. Google Authenticator). The exception you will find is that certain programs or scripts cannot use credentials requiring MFA as they have no means to generate one. These are essentially your “service accounts” in IAM. Lock these down as much as possible.
You will need to consider the access and potential impacts from giving third parties access to your AWS account. Best intentions aside, if they are compromised, how would that potentially impact your environment?
What is your password policy? You should implement one across all your AWS accounts. Consider using an industry-recommended standard as your baseline.
Consider how you will address the creation, use and rotation of your EC2 key pairs. These are required for access to your Windows or Linux instances (unless you bootstrap them through other methods). Key pairs should be rotated both in the AWS IAM service (for use by future instances) and inside your existing EC2 instances.
I will cover the identity setup and cross account access for our AWS scenario later in this blog series.
Have you considered your approach if an EC2 instance is facing the public Internet? What do you need to do to secure your environment? Think WAF, IPS/IDS solutions... What is your risk/mitigation for things like software Zero-days? There aren’t any new concepts here, but you should think about these.
Will you harden your instances? Do pen testing?
Itoc strongly advocates for automated security testing and reviews. We leverage a number of third party solutions to provide independent, comprehensive reports and advice. This simply means we can source, supply and act upon unbiased inputs and reports for such an important aspect of operating on AWS.
Make things secure then get the professionals to check it!
Secure your code
For this blog post, I’m going to take it as a given that everyone is implementing secure coding practices into their applications. Your infrastructure may be as secure as possible, but if your application has security flaws, that may all be negated.
With AWS being a huge enabler for levelling the technology playing field, everyone now has access to the same enterprise grade functionality as the big players! In this marketplace, your true differentiator is now your code base coupled with your execution.
With this important business competitive advantage/differentiator in mind, how do you protect and grow this asset? Where do you store this code? Perhaps AWS CodeCommit? Is your code repository secured and access audited?
Do you trust a third party vendor (e.g. GitHub) to keep it secure? What are the risks of their staff vs. 0-days compromising these platforms? At the end of the day, you may not be the target, but your business may be impacted by any potential fallout e.g. Your code is not the target, but it may be in the cross hairs just because Github is a target. If the code is leaked/stolen, what are the ramifications to your business?
On the flip side, you could store your code in a private (internal) repository. This could suit you best, but can you configure, secure and run a solution in-house at the same level that a specialised company can?
It’s a trade off, and neither approach is wrong. In today’s convenience driven society, should convenience always win? Pick an approach and run with it, just make sure to consider your Total Cost of Ownership.
Keep up the comms!
Remember, you’re making decisions which will impact and guide your AWS implementation. You must document and communicate these decisions, keep your team up to date and socialise this information. Without this, how will they know the direction you have chosen? How will you get feedback?
Document your decisions, keep it concise, and explain reasoning for bonus points.
In this blog post we have barely scratched the surface of security in AWS, but have addressed some of the big ticket items including defining your security policy, establishing logging and audit trails, Identity Management on AWS, platform hardening and the importance of securing your code.
The next blog post in this series will take the decisions and ideas covered in this post and focus on laying the groundwork for operating within AWS.