Steps for Establishing Your AWS Security Roadmap
Is your team thinking about using Amazon AWS? Read on to see what 3 industry leaders have to say about shoring up your cloud security in AWS.
Join the DZone community and get the full member experience.
Join For FreeLast month, we hosted one of our most popular webinars to date: Steps for Establishing Your AWS Security Roadmap. Threat Stack’s VP of Engineering, Chris Gervais, was joined by AWS Solution Architect, Scott Ward, along with Zuora’s Head of Infrastructure Security, Bibek Galera for a practical discussion on how companies can build an effective cloud security roadmap from day one. This webinar focused on four key steps to developing a roadmap:
- Understanding the shared security responsibility model as it applies to AWS.
- Developing a cloud security maturity model for your company.
- Meeting compliance and security on AWS.
- Scaling security for the future.
You can listen to the full webinar recording above. Below, we have provided an overview of Chris, Scott, and Bibek’s recommendations for a step-by-step approach to security on AWS.
1. Know the AWS Shared Security Responsibility Model
We’ve talked before about the shared responsibility model in the cloud. As an AWS user, it’s important to first know what areas of the cloud AWS is responsible for securing and which are up to you.
In short, AWS is responsible for the security of the infrastructure itself, whereas you as a user are responsible for the security of anything you’re doing on top of AWS. This means it’s up to you to secure your applications, data, and users. To do so, you’ll need to implement security monitoring, alerting, and user access policies, among these other best practices.
“This is where a tool like Threat Stack comes in,” Scott explained. “AWS customers can implement and run additional tools and services to give them the security profile they need to run successfully and with confidence on AWS.” You can also leverage tools that AWS offers to begin understanding who is doing what within your account. Tagging, for example, allows you to specify which groups of users can take action on which sets of resources, allowing you to reinforce security policies.
As Scott put it, “When you marry the AWS and customer portions of the model, the result is a complete security profile that ensures you’re up and running in the most secure way.”
2. Develop a Cloud Security Maturity Model for Your Company
Once you know which areas of security lie in your court, it’s time to evaluate how mature your cloud security is today — meaning that you need to understand which best practices you have in place now and where the gaps are. We have created a simple model to make sense of security maturity, which we explained in detail during the webinar. The three maturity levels in the model apply across nearly every company size and industry sector, making them a great point of reference to build your model on.
These three fundamental steps help to crystallize and identify where you are in the maturity lifecycle and what you still need to implement. From there, you can begin to create your own roadmap to security maturity.
Bibeck shared how Zuora created theirs. Here’s their model:
Zuora didn’t start off in the cloud, so when they were making their move to AWS, they had to think hard about:
- What controls they had on-premise that they would need to replicate in the cloud.
- What security measures AWS already provided.
- What other controls they needed to ensure a complete security profile in the cloud.
They began by asking themselves:
- How do we create the same network segmentations that we had in a data center?
- What happens to our data at rest and in transit in the cloud?
- Who can access different types of data now and how do we verify that?
- How do we meet compliance in the cloud?
“After we went through these fundamental questions,” explained Bibek, “we had to come up with a maturity model for ourselves.” This model aligned their team on the standards they needed to meet in the cloud and gave key stakeholders visibility into the cloud security journey so everyone involved was on the same page. With every facet of their model laid out up front, Bibek and team were able to get up and running in the cloud fast and seamlessly overcome obstacles along the way.
Wondering how to develop a model like Zuora’s that will be unique and effective for your organization? It all starts with knowing your baselines. Chris explained that you first need to know your organizational baselines, and where security currently stands among organizational priorities.
This includes answering the following questions:
- Why do we need security in the cloud?
- What are the internal security drivers for our organization?
- Do we have a corporate responsibility or customer requirement to uphold a certain level of security?
- What are the consequences of not paying attention to security and not establishing a strategy now?
While it might seem obvious to you why you need cloud security, it’s important to run through this exercise to ensure that all stakeholders understand and that every requirement is taken into account as you plan your maturity model.
Next, establish your technical baselines. As Scott explained, “You first need to be able to understand what’s happening within the infrastructure and services you’re running, so you can plan for control and visibility across your environment.” That includes knowing:
- Who can access data vs. who should access data?
- Where do different types of data live? How valuable are they?
- What are the data protection requirements we must uphold?
In short, you need to know who is doing what, where, and when. Ideally, that comes in the form of cloud visibility.
With an understanding of where your organization stands from a security perspective, you can begin planning an implementation roadmap for AWS best practices, including:
- IAM configurations.
- Multi-factor authentication (MFA).
- Tagging of AWS resources.
- Encryption.
- Logging and auditing with CloudTrail.
- Automated monitoring and alerting.
“Figure out what makes sense for you first and foremost, and then think about which controls, policies, and tools are right for you,” explained Scott.
3. Know Your Compliance Requirements
Planning for security also means knowing what compliance requirements you have to meet in the cloud. Often compliance requirements will overlap with security best practices and other compliance frameworks you need to meet, so mapping that out upfront can save a lot of work down the line.
If you’re in the healthcare industry, for example, you have to meet HIPAA requirements, but many of those also bleed into SOC 2 and PCI compliance requirements. “Understand what you need to do to meet compliance and invest the time to understand the roadmap upfront,” said Chris. “Understand what AWS already does for you from a compliance standpoint, and then assess what other tools and policies you need to meet your requirements.”
Compliance is, in fact, a big reason many companies move to AWS. Amazon has done the legwork already to meet requirements for SOC, FedRAMP, FISMA, HIPAA, PCI, and much more (see the full list here). But just because AWS has met their requirements for compliance doesn’t mean there isn’t any work for you to do as a customer. This goes back to the responsibility model: There are requirements that cloud providers like AWS must uphold and requirements that you must uphold. Your end of the bargain includes making sure the applications and services you’re running on top of AWS meet your compliance requirements. What you no longer have to worry about is compliance for your infrastructure — that’s the part AWS handles for you.
Being very clear about where your data lives, what controls you need, what level of visibility you have, and how you keep track of changes over time are some of the most important pieces to understand and address in your security roadmap.
4. Planning for What’s Next
While it’s important to get the fundamentals of cloud security in place early on, you don’t have to try doing it all at once (which is impossible in any event). “If you can integrate security best practices from the beginning, you won’t have to worry about backtracking later on. It’s already taken care of,” said Bibek.
With baselines established, a plan in place, and best practices implemented, your focus can shift to more strategic security efforts, including:
- Fine tuning alerts.
- Better understanding user behaviors and adjusting IAM and security groups accordingly.
- Further automating routine or sensitive tasks (eliminating human error and reducing risk).
- Bringing in other tools such as Slack and PagerDuty to extend the security conversation to your whole team.
“This is where Threat Stack comes in for us,” explained Bibek. “Automated security monitoring provides visibility across all our services so we can see things right when they need to be taken care of.” With Threat Stack integrated across their AWS environment, Zuora’s security is now scalable. “Security is no longer an afterthought. It’s automatically there as new services are spun up as we scale in the cloud.” This way, Bibek and his team can focus on boosting their security in other ways, knowing that the rest is handled automatically. “Automate where you can,” recommended Bibek.
A Final Word
We want to send a huge thank you to both Scott and Bibek for joining us and providing so many useful strategies. We hope this framework is helpful to you as you begin or continue your cloud security journey.
Published at DZone with permission of Allison Stokes, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Trending
-
Best Practices for Securing Infrastructure as Code (Iac) In the DevOps SDLC
-
Essential Architecture Framework: In the World of Overengineering, Being Essential Is the Answer
-
Top Six React Development Tools
-
4 Expert Tips for High Availability and Disaster Recovery of Your Cloud Deployment
Comments