Back to blog results

7월 17, 2019 By Sridhar Karnam

Why you need to secure your AWS infrastructure and workloads?

Enterprises are increasingly adopting a cloud-first approach and migrating their workloads, data and applications to the Cloud. Amazon Web Services continues to lead the Public Cloud industry with more than 30% of the market. As digital transformation progresses and the digital space expands, so does the attack surface that exposes the ongoing proliferation of security risks.

In today’s cloud-first world, security remains the primary concern. The proliferation of complex, multi-cloud environments creates security silos that expand the surface of the rapidly changing threat landscape, which undermines the existing protective layers.

However, this doesn’t mean that Cloud Architects and Security Specialists are completely helpless. We can still protect our environments, but amid all these threats, we have to be more proactive about securing them. Here are the six areas that you need to consider:

AWS's shared responsibility model requires your action

As an AWS customer, you will benefit from a data center and network architecture built to meet the requirements of the most risk-sensitive organizations. However, AWS operates on the Shared Responsibility Model, which means that the security of the infrastructure is the responsibility of AWS, but it also implies that the user needs to perform his part in the security equation.

AMAZON WEB SERVICES SHARED RESPONSIBILITY MODEL

According to Amazon, AWS is responsible for securing the underlying infrastructure that supports the cloud, and you’re responsible for anything you put on the cloud or connect to the cloud. On the other hand, AWS’s IaaS products, such as Amazon EC2, Amazon VPC and Amazon S3 are completely under your control and require you to perform all of the necessary security configuration and management tasks. Research the details that apply to your cloud infrastructure and act accordingly.

AWS security tools fulfill only very specific roles

There is an abundance of different AWS security tools across the different domains: network security, configuration management, access control, data security, monitoring and logging. Consider the following tools:

  • Directory Service - it enables single sign-on for Amazon EC2 instances and applications compatible with MS Active Directory.
  • Identity and Access Manager - creates users, groups and roles to allow access to AWS.
  • Trusted Advisor - checks your AWS account for security, as well as cost optimization, performance and fault tolerance.
  • CloudTrail - offers deep visibility into API calls and enables security analytics.
  • Key Management Service - managed service that allows one to create, control and use data protection keys.
  • Cloud Watch - provides visibility into resource utilization and operational performance with metrics and logs.
  • AWS Config - an inventory of AWS resources that lets you audit the configuration history and notifies you of changes to settings.
  • Service catalog - used to create and manage catalogs of IT services that are approved for use on AWS.

As you can see, there is a wide variety of products available to tighten security in AWS. The so called ‘detective tools’ - CloudTrail and CloudWatch - will likely be more useful to your organization than some other features. In any case, it’s important to understand what each tool covers and what it doesn’t in order to use them in a way that fully benefits your organization.

The default configurations aren’t always tight

The services you choose to benefit from and the level of sensitivity of your data will determine the amount of security configuration that will have to be done. Each AWS asset has its default settings that have to be customized for security. The detailed view of the configuration of AWS resources (including historic settings) is available through the AWS Config feature on your account. Consult AWS Config Supported AWS Resource Types and Resource Relationships for a list of AWS resources supported by this feature.

Bear in mind that there are certain security features that should be configured regardless of the services you’re using. These include individual user accounts and their credentials, SSL/TLS for data transmissions and user activity logging. You can browse the web for checklists which list the default settings that must be tightened to ensure full security. These are available for most of the popular service providers, including SQL and Linux.

Access and monitoring controls require extra protection

As much as 80% of breaches are caused by stolen privileged access credentials. User accounts that are unrestricted or overly permissive create a great risk of both internal and external threats. Thus, it’s necessary to make the best use of AWS Identity and Access Management (IAM). It allows you to control access to AWS services and resources; create and manage AWS users and groups; and grant or deny access to individual users. It also gives you control over permissions for API calls. Use IAM to restrict a user’s permission to the extent necessary to complete their required tasks, applying the so-called least privilege rule. Also consider rotating access keys every 90 days.

Complexity obscures visibility

You cannot control what you don’t see; this applies especially to complex multi-cloud environments. Recent studies found that enterprises are operating within an average of 4.8 clouds and use 16 different SaaS tools to run their businesses. As AWS environments reside within their own silos, end users' view of the attack surface is obscured. You need to ensure you have full visibility of all your cloud accounts and instances, so you can see across and between them. Make sure you connect all your clouds inside your CMP to eliminate operational blind spots. What’s more, full visibility into sensitive data allows you to identify which regulations apply to specific applications and their data (both internally and externally), which helps determine the right type of security controls that have to be ensured for protection. Sumo Logic can help you ensure multi-cloud visibility, thanks to native support for AWS infrastructure.

Open S3 buckets are the cause of numerous data breaches

Just last year, an unsecured Amazon S3 server belonging to Bongo International, which is affiliated with FedEx, exposed over 100k personal documents, including passports and driver’s licenses. There are video tutorials available on YouTube with instructions on how to hack an open S3 bucket. This means there is a lot of responsibility for Cloud Administrators to restrict access to S3 resources. There are several different ways to do that. You can write bucket-specific policies with AWS Policy Generator, specify user policies in IAM, use Block Public Access to limit public access centrally and by setting access control lists (ACLs) directly on the buckets. Be sure to also review the list of ACL permissions to understand who has read and write access (be stringent about them!). There are other options for restricting access to your S3 resources, but it’s equally important to monitor them and use encryption to protect your data. By default, AWS will manage the encryption keys, but we recommend doing it on your own.

Conclusion

The cloud-first approach requires you to prioritize security. AWS provides numerous tools that can help you secure your deployments. If you adopt the multi-cloud strategy, remember to secure all your clouds with external tools that are a good fit for AWS and other large public clouds.

Complete visibility for DevSecOps

Reduce downtime and move from reactive to proactive monitoring.

Sumo Logic cloud-native SaaS analytics

Build, run, and secure modern applications and cloud infrastructures.

Start free trial
Sridhar Karnam

Sridhar Karnam

Senior Director of Product Marketing

Sridhar Karnam leads the security product marketing for Sumo Logic. Sri has a decade of experience with SIEM, Security Analytics, Cloud Security, and IT Operations. He has led product management & marketing for SIEM solutions at ArcSight, Arctic Wolf, and at Oracle. He has written hundreds of blogs on SIEM, and has also spoken at many security and IT events.

More posts by Sridhar Karnam.

People who read this also enjoyed