10 AWS security considerations when migrating

SnykSec - Dec 5 '22 - - Dev Community

Cloud data storage has many practical advantages over traditional data centers, but making a move also comes with many unique security considerations.

When moving to AWS, begin how you wish to continue. Companies that transition to cloud data storage must update their approach to information security to protect their data. Setting up proper security practices during migration will help future teams securely and efficiently deliver applications and features. Conversely, sticking to traditional security practices will slow teams down and limit their future success.

We’ve recently created our Snyk Top 10: Security Strategies when Migrating to AWS report to cover the top considerations for making the leap easy and secure. In this post, we’ll take a brief look at each consideration:

  1. Approach AppSec and CloudSec together.
  2. Embed security teams with AppDev and DevOps teams.
  3. Modernize app development with security across the SDLC.
  4. Design cloud architecture with security in mind.
  5. Empower developers and cloud engineers to build securely.
  6. Use infrastructure as code right from the start — and secure it.
  7. Use cloud security guardrails in deployment pipelines.
  8. Build cloud security on a foundation of policy as code (PaC).
  9. Use identity and access management (IAM) services securely.
  10. Decide what matters — and measure continuously.

1. Approach AppSec and CloudSec together — holistically

In the past, it was possible to segment cloud operations and app development into different layers. Now, the lines between application security and infrastructure security are increasingly blurry. Bad actors can easily exploit vulnerabilities anywhere in your stack. If AppSec and CloudSec teams use separate tools to scan applications for security risks, there is a real risk of missing vulnerabilities that span layers or situations where one layer impacts another.

Don’t allow AppSec and CloudSec security to become siloed. A comprehensive DevSecOps approach should use a centralized, consolidated process to find and mitigate risk. Not only does this allow for greater context around both the cloud environment and software development, but it is also more efficient and leads to better overall risk prioritization across the organization.

2. Embed security teams with AppDev and DevOps teams

Silos slow down both full-stack security and agile development. The conventional practice of treating security as a separate function can become a huge time drain as teams must stop what they’re doing to deal with every new risk that crops up.

Instead, tackle security risks early by integrating security practices and control into the software development lifecycle. The DevSecOps approach integrates security objectives into the software development life cycle (SDLC) as early as possible and creates a culture of shared responsibility around security. When security teams work in tandem with developers and cloud engineers while designing and developing cloud-based systems, they can bake security into every phase of the SDLC to maximize efficiency.

This shared responsibility happens through developer-first tooling that integrates into the platforms developers are already using and familiar with. Platforms for centralized visibility and easy cross-team communication are also essential for effective collaborations.

3. Modernize app development with security across the SDLC

The move to AWS is an excellent opportunity to shift to end-to-end security coverage across the SDLC.

Leaving security testing until later in the app development process can lead to delays. Instead, adopt a shift left approach to integrate security as early as possible in the SDLC to keep development agile and manage new risks introduced by cloud technology.

Use automated security checks for every pull request to identify security issues before accepting the new code changes into production environments. This process will help establish high-level security visibility as the application is built and tested to confirm its security state.

4. Design cloud architecture with security in mind

Bad actors often exploit architectural weaknesses to gain access to valuable data. Minimize the impact of security threats by thinking like an attacker to identify where these weak spots lie. Look for common cloud misconfigurations and proactively avoid them.

Fortify your security team’s AWS security architect skills. Take advantage of resources like Cloud Security Podcast, AWS training programs and certifications. Consider creating a dedicated role for a cloud security architect to set up and manage secure cloud architecture.

5. Empower developers and cloud engineers to build securely

When cloud misconfigurations crop up, developers are best positioned to fix them without breaking functionality. They are often the only people who can secure their application code and infrastructure as code (IaC) templates (e.g. AWS CloudFormation; AWS CDK, Terraform) before deployment.

Empowering developers means allowing them to make decisions and take ownership of their applications’ security. This shift is often both a cultural and a functional change that requires support in the form of messaging from above, education, visibility and transparency across teams, and the right tools. Make sure developers have what they need to identify and fix their own code weaknesses.

6. Use infrastructure as code right from the start — and secure it

Infrastructure as code (IaC) means that infrastructure can now be treated like code. It’s no longer the IT team’s responsibility to secure it, but the developers’. And the best way to secure it is simply by following coding best practices and checking it alongside application code.

IaC is a more efficient and consistent way to build and manage AWS environments at scale that also allows you to perform check cloud security at pre-deployment. Checking the security of IaC results in a 70% median reduction in cloud misconfiguration — and a 70% median improvement in engineering productivity and deployment speed.

Having processes and procedures defined around enabling secure IaC at the start of your AWS transition will enable absolute clarity, speed, and efficiency for the AWS migration. Amazon Web Services offers AWS CloudFormation as their native IaC solution, independent options like Terraform are widely used too.

7. Use cloud security guardrails in deployment pipelines

A byproduct of shifting security left is that you’ll need to continuously monitor your environment to catch security issues. Security checks must be automated in CI/CD to prevent misconfigurations pre-deployment. Using IaC would enable adding security checks for cloud security in the infrastructure being built for the applications to be deployed in AWS.

A DevSecOps approach to cloud security means that engineers will get automated feedback when an issue appears and clear guidance on correcting the problem quickly and safely. IaC ensures that engineers avoid repeatedly deploying similar misconfigurations later on.

8. Build cloud security on a foundation of policy as code

Manual compliance reviews are time-consuming and tough to scale. Policy as code (PaC) tools automate the process by codifying and enforcing policies. Not only is this faster and more efficient, but taking the possibility of human error out of the equation means it’s also more reliable and consistent.

Use PaC to create a single source of truth policy to which developers, security, DevOps, and compliance can align. Automating policy helps security teams scale their effort without scaling up headcount.

9. Use identity and access management services securely

While it may appear that the purpose of identity and access management (IAM) is solely to manage user permissions, it’s also the best way to see the entire cloud-based network. Overly permissive IAM configurations are an open door for attackers to access the cloud control plane.

Secure IAM configurations should be a core part of your cloud security architecture. Continuously evaluate IAM configurations for weaknesses and help engineers use IAM services securely built using the principles of least privilege access. A dedicated cloud security expert can ensure that IAM is correctly configured and managed.

In addition to the above, users require individual user security awareness training on the importance of strong passwords and multi-factor authentication (MFA).

10. Decide what matters — and measure continuously

Metrics are essential to ensuring your AWS security efforts are working correctly. It’s important to measure the effectiveness of your cloud security programs. Teams that get AWS security right operationalize it and are disciplined about measuring what matters.

You should know the state of your security posture and be able to demonstrate it using concrete numbers. These numbers may look different than those in traditional deployment models. In a CI/CD deployment model, a certain level of vulnerability is acceptable and expected. It takes an end-to-end security approach to differentiate between critical and non-critical vulnerabilities and prioritize what matters most. Demonstrate progress not just by measuring the reduction of risk but by an increase in developer and DevOps efficiency in remediating those vulnerabilities.

Some metrics to consider, depending on your organization’s priorities, are time to remediate, percentage of high severity open vulnerabilities, number of risk-accepted vulnerabilities, and percentage of low severity vulnerabilities. No metric is a one-and-done — the goal is constant and continuous improvement.

Security strategies when migrating to AWS

Want to learn more about these 10 considerations? Read the full report for free.

Read report

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .