This week we are launching a short blog series on AWS security foundations. We have worked with many customers to help them use best practice to optimise the security of their AWS based solutions. This series will focus on some foundational approaches in bite size pieces that everyone organisation can and should adopt. We hope by the end of the series, you will have the knowledge to ensure a baseline level of security for your AWS environment.
Doesn’t AWS do that for me?
While it’s far easier, cheaper and quicker to build a highly secure solution using the AWS Cloud than in a traditional environment, the first thing you need to be aware of is the shared responsibility model. In essence, it’s an agreement between AWS and the customer of the platform where:
- AWS is responsible for the security “of the Cloud”. AWS is responsible for the security of the infrastructure that run the Cloud services. This includes the underlying network, hardware, software and data centres;
- Customers are responsible for the security “in the Cloud”. The customer is responsible for configuration of the services. They also need to think about managing access and protecting data. EC2 operating systems, for example, are under the control of the customer. This includes patching and closing vulnerabilities in the OS or the applications.
What does it mean for me?
Having good security foundations means that you can be confident in your AWS environment. Don’t rely on the default configuration as that may not suit your use case. By thinking about how your applications make use of AWS services, you can ensure you configure these services as required. Covering the fundamental elements will take you a long way towards a secure solution. In this series of blog posts, we will concentrate on helping you with the Protect and Detect components of your security approach (as defined by the NIST Cybersecurity Framework).
- Protect focusses on configurations and controls that can help to prevent security events happening in the first place;
- Detect provides the capability to detect potential events so that they can be investigated. In 2021, a world of mandatory breach reporting and GDPR, we still see an average time to detect for a data breach of 206 days. How can we identify potential issues in near real-time?
Let’s go
We are kicking off our series this week with a look at how you can see what is going on in your AWS environment. Keep an eye out for the post later this week.
