Starting with Strong Security in the AWS Cloud
Guest post by Mark Nunnikhoven, VP, Cloud Research, Trend Micro
When you’re first starting to build a new product or service, it’s critical to have a singular focus on getting that MVP into the hands of your customers.
It’s also easy to push security to the side and justify that move with statements like:
- “We’re not big enough to be a target”
- “No one is interested in our data”
- “We’ll hire more security folks later”
These statements are understandable—but they are also misguided. Security isn’t just about stopping hackers. It’s about making sure that your systems work as intended…and only as intended.
Security is often viewed as too difficult or that it requires too many special skills to do well. That’s ridiculous. It’s a core part of development and operations.
After all, who wants to write bad code or constantly fix an unstable service?
Security thinking is just an extra step on a path you already know. The perfect time to build security into your product is when you are laying the foundations of your startup.
Shared Responsibility Model
The AWS Cloud operates on a shared responsibility model. The idea is simple: there are a number of areas that need attention daily. The responsibility for the work in areas (physical, infrastructure, virtualization, operating system, application, and data) is split between you, the user, and AWS.
The key is to understand where each service you use falls on the spectrum. From there, you can plan what it’ll take to build and run your product.
In the AWS Cloud, a fantastic approach is to build out your culture around the “DevOps” concepts of no silos between responsibilities and short feedback loops. In general, this makes security folks a bit antsy as a core tenant of information security is “separation of duties.”
That concern can be balanced by adopting AWS’ philosophy of using automated systems to enforce policies, reduce risk, and accelerate innovation.
The good news? All of the pieces you need are available within the AWS Cloud. AWS CodePipeline provides a continuous integration/continuous delivery service that easily integrates with other AWS services (like AWS CodeStar, AWS CodeCommit, AWS CodeBuild, and AWS CodeDeploy) or popular third-party services.
With this as a base, you can start to build a strong, automated security foundation.
Stephen Schmidt, the CISO of AWS, said it best at AWS re:Invent 2017, “…we love mechanisms. They drive repeatable correct behavior””. He goes further to highlight the need to converse human resources because developers want to get their job done well and on time.
Stephen highlights the need for tooling that supports smart and secure development decision and how automation is the key to security thinking.
When you’re taking the first steps with your product, that’s the time to add the security tooling to help your team build a strong product. In the AWS Cloud, that starts with the Identity and Access Management service or IAM.
Every AWS service uses IAM to determine who can do what when. Built on a set of primitives (users & roles, permissions, and policies), this is the first stop for all security and privacy work.
A core tenant of information security is called the “principle of least privilege.” This simply means that a user or system should only have the permissions they need to do their job and no more.
IAM makes this easy by providing a scalable, granular system that lets you grant permissions in your environment.
Don’t just granted everyone “Full Access” to a service. Take a few minutes to review the permissions they actually need. It’s a small time investment that will substantially reduce your risk. Take things a step further and make sure that policy is consistently in place by adding a unit test in your CI/CD pipeline.
Once you’ve familiarized yourself with the IAM basics, this fantastic talk from AWS re:Invent 2017 will take your IAM skills to the next level.
But even with your IAM configuration smartly set, issues are still going to come up in production. This is where a security phase called “Incident Response” comes into play.
Now, “Incident Response” sounds official and formal but it’s something that you’re already used to dealing with when things break. There’s very little difference here for most cases.
Ignoring the response to an active attack—that’s a completely different post but this advice sets you up well to handle it too!—there are some steps you can take ahead of time to both simplify and automate the incident response process.
As an added bonus, these steps help with all manner of troubleshooting.
The key to incident response is having the right information at the right time. By default, all new AWS account have a service called AWS CloudTrail enabled (it’s a one check deployment for older accounts).
CloudTrail is an audit trail of most of the AWS API activity that happens in your account. When a new set of instances are created, that call is logged in CloudTrail. Setup a new VPC? There it is in CloudTrail. Change the permissions on an S3 bucket? CloudTrail tracks those changes.
CloudTrail is a fantastic data source for incident response after something has happened. Combine with a service like AWS Config and CloudTrail becomes your go-to source for compliance information.
This simple system trumps many of the mature security practices out there. You can use this workflow for any type of issue in production. From highlighting a problem to the team on your Slack channel, to isolating EC2 instances so issues don’t spread, to recovering in another region.
Learn more about this workflow from my AWS re:Invent talk in 2016.
You might not think of these key AWS services in a security context. But these simple building blocks can create powerful workflows.
Security Services & Partners
For those workflows that require deeper security knowledge, there is a suite of additional AWS services to help address most of your needs:
Amazon Cognito – A cloud-native way to manage user sign-ups, sign-ins, and permissions at scale
AWS Directory Service – A managed service for Microsoft Active Directory to help connect legacy applications and enteprise identity schemes
AWS Secrets Manager – Shhhh! Keep your secrets out of the rest of your deployment by safely storing, rotating, and control access to sensitive material like API keys
Amazon GuardDuty – Managed threat detection looking for malicious and unauthorized behaviour on your AWS workloads and accounts
Amazon Inspector – Easy vulnerability scanning
Amazon Macie – Intelligent monitoring of sensitive data in your Amazon S3 buckets
AWS Certificate Manager – A simple to issue and manage SSL/TLS certificates to encrypt your data in transit
AWS CloudHSM – The easiest way to get a hardware security module (HSM) to protect sensitive material in the cloud
AWS WAF & Shield – Seamless web application firewall and DDoS protection for your applications
AWS Artifact – A one-stop shop for all of the documentation for AWS Cloud compliance reports. Yes, there are so many that keeping track of them requires it’s own service!
This set of services covers a lot of your security needs but even with all of these tools, you may need additional help fulfilling your responsibilities under the shared responsibility model.
This is where partners like Trend Micro come into play. Trend Micro has long been an advanced technology partner of AWS. Trend Micro’s Deep Security platform helps you protect the operating system, applications, and data in your EC2 and ECS deployments.
Security can seem overwhelming. Unfortunately, that feeling leads to security being pushed aside for “later.” This bolt-on approach is more expensive and leads to worse security outcomes.
If you integrate security into all stages of your product or service, you’ll not only simplify the work but also generate better security outcomes.
AWS provides an unparalleled set of tools to help achieve these goals. Add to that toolset a large ecosystem of partners like Trend Micro, and you can easily integrate and automate the security of your AWS deployments.