RedLock is now a part of Palo Alto Networks - READ MORE
AWS Security
< Back

What You Must Know About AWS Security

by   |   08.21.18, 6:00 AM

Businesses and institutions are rapidly deploying their networks on the infrastructure of third-party cloud providers. In the first quarter of 2018, the cloud infrastructure services industry grew by 51%. It’s easy to see why organizations are choosing third-party cloud providers. Having all of your infrastructure on premises is very expensive. By deploying part of your network or most of your network with a third-party cloud platform, your company can reduce how much data center space they need, save money on electricity, and benefit from the cloud’s rapid innovation and powerful new features with the experience of a huge enterprise like Amazon.

Having part of your network on third-party cloud infrastructure comes with its own unique cybersecurity challenges. And the cyber threat environment for enterprise operations is only getting more severe and complex over time. But it is possible to have good security and regulatory compliance while using AWS. Here’s what you need to know.

What is AWS cloud security?

A lot of the principles of securing on-premise networks also apply to cloud networks. There are perimeters that must be guarded, service configurations which must be monitored, data that must be encrypted, and physical security that must be watched. Distributed denial of service attacks (DDoS), malware, and man-in-the-middle (MITM) attacks can affect a cloud server just as they do any other sort of server which is connected to the public internet.

But because your AWS services aren’t operated on your company’s premises, your approach to securing them must be a bit different.

As with any other cloud service, the shared responsibility model applies to AWS. Some aspects of security are your responsibility, and some are Amazon’s. Here’s how Amazon describes how the shared responsibility model applies to your organization’s use of their services.

 

AWS Shared Responsibility Model AWS Shared Responsibility Model

 

AWS’s responsibility is the “security of the cloud.” That means they’re responsible for securing their infrastructure. That includes the hardware, software, networking, and facilities that run AWS Cloud services. If a cyber attacker acquires physical access to your machines or a hardware firewall wasn’t plugged in, that’s on them.

Your responsibility is “security in the cloud.” This is a bit more complicated because AWS offers a variety of different services. Here’s what they have to say:

"Customer responsibility will be determined by the AWS Cloud services that a customer selects. This determines the amount of configuration work the customer must perform as part of their security responsibilities. For example, services such as Amazon Elastic Compute Cloud (Amazon EC2), Amazon Virtual Private Cloud (Amazon VPC), and Amazon S3 are categorized as Infrastructure as a Service (IaaS) and, as such, require the customer to perform all of the necessary security configuration and management tasks. If a customer deploys an Amazon EC2 instance, they are responsible for management of the guest operating system (including updates and security patches), any application software or utilities installed by the customer on the instances, and the configuration of the AWS-provided firewall (called a security group) on each instance."

Your applications which operate within AWS’s infrastructure as a service (IaaS) are your responsibility.  Your identity and access management are also your responsibility. Your platforms, your operating systems, your virtual machines and clients, your network and firewall configurations are all your organization’s responsibility to keep secure.

How secure is the cloud?

Cloud SecurityAccording to the shared responsibility model, the “security of the cloud,” the infrastructure, is the provider’s domain. Therefore you have less control than you would have if your cloud was entirely on your premises. However, cloud vendors like AWS have considerable experience and resources when it comes to securing cloud infrastructure, probably more than your organization alone would have.

Because of the scale of platforms like AWS, their cloud services can operate at maximum efficiency according to the available computing resources. Unless your organization is one of the world’s largest tech companies, you can’t possibly match their efficiencies of scale, and all of the extra redundancy they have to maximize your bandwidth and uptime in the wake of cyber attacks.

When deployed and monitored properly, the experts agree that networks in public cloud deployments can be more secure than traditional on-premise networks.

Addressing Customers’ Security Responsibility

But less control doesn’t necessarily mean less responsibility. The physical location of your data matters less than the means of access. AWS provides many native security tools which are designed to give users the ability to address each aspect of the customer portion of the shared responsibility model. These AWS security benefits include, but aren't limited to:

  • AWS Config for monitoring resource configurations
  • AWS Trusted Advisor for compliance configuration monitoring
  • AWS CloudTrail for analyzing user activity logs
  • Amazon Virtual Private Cloud flow logs to search for suspicious activity
  • Amazon Inspector for the detection of host vulnerability
  • Amazon GuardDuty to monitor for host compromise

While each of these technologies can address aspects of cloud security, they do not necessarily provide a comprehensive view of cloud security or unified cloud intelligence. To create automation and transparency in a cloud environment, adopting third-party tools for proactive monitoring in the cloud can correlate data sets from across the cloud environment. This can allow cloud administrators to understand cloud security based on intelligence from configurations, users, network, vulnerabilities, and third-party intelligence sources for total risk context.

AWS Security Facets

  1. Keeping Track of Assets

    Asset inventory is an essential function of all cloud security solutions. In order to secure your organization’s resources on an AWS cloud, you must understand what they are, where they are, and how they are. Many organizations struggle with asset inventory, but the use of the right solution can make it much more manageable. Here are some of the pertinent things to consider.

    Ephemeral Resources: RedLock research indicates that the average lifespan of a cloud resource is two hours and seven minutes. In order to track them properly, they must be automatically identified upon creation and upon deletion.

    Fragmented Environments: It’s normal for organizations to have their AWS cloud as a part of a multi-cloud environment which may include another cloud platform. This can make visibility a real challenge. What’s needed is a solution that can be deployed across the entirety of an organization’s cloud network for ideal visibility of everything they have on all platforms and physical environments.

    Ineffective Tagging: An asset cannot be managed if it isn’t labeled properly. Rapid expansion of cloud environments by privileged users without security oversight often leads to poor tagging
    practices. The solution is to deploy AI to identify assets by correlating configurations with network activity

  2. Losing Track of Configurations

    Managing configurations is very important when it comes to security hardening and industry regulation compliance. A cloud network that’s completely on-premises can be managed with a configuration management database, but they don’t work well in public cloud environments.

    Dynamic Environments: Cloud assets last for an average of two hours and seven minutes. Combined with multiple cloud platforms, keeping track of assets and their configurations can be difficult. Automatic asset inventory and configuration monitoring are necessary to keep pace.

    Privileged Users: Non-security users that have configuration modification privileges can result in poor security practices whenever configuration changes are made. User attribution and policy guardrails are needed so that users are promptly notified of misconfigurations.

    Feature Velocity: Cloud platforms and applications introduce many new features all of the time. That’s a great benefit for organizations. Unfortunately, maintaining good security posture can be a challenge unless developers and security teams can keep up with new features and study their impact on security.

    Alert Fatigue: Cloud environments can change rapidly and security professionals can be overwhelmed with alerts, making attending to them a challenge. Therefore, alerts must support
    auto-remediation or integrate with DevOps workflows.

  3. Account Compromises & Insider Threats

    Insider Threat

    It is becoming increasingly common for cyber attackers to hijack a privileged account on your cloud network. In addition, malicious insiders could deliberately use their legitimately assigned accounts in order to do harm.

    Privileged Users: Having multiple privileged users and accounts is good for productivity, but bad for risk exposure. Your cloud should be monitored for all of the actions that privileged users engage in.

    Fragmented Environments: Multiple users across multiple cloud platforms can make security visibility a real challenge. User activities must be correlated across an environment to detect risk patterns.

  4. Insecure Networks

    Cloud networks have a virtual perimeter which is more difficult to secure than an on-premises network’s physical perimeter. Public clouds need a security approach that’s different from what an on-premises network requires.

    Performance and Scale Implications: Inline network security solutions can negatively impact important cloud architecture benefits such as bursting and auto-scaling. An out-of-band approach is necessary.

    Blind Spots: Traditional network security tools can be ineffective in cloud environments and create security blind spots. They aren’t designed for API-driven services. What’s required to avoid blind spots is an out-of-band approach.

    Privileged Users: Users being able to create and modify assets on-demand is a tremendous benefit to an organization’s productivity and agility. But the lack of security oversight can be a challenge and a simple network misconfiguration can open up the network to attack.

    Alert Fatigue: Alerts based solely on network configuration changes could inundate security teams with false positive results. Configurations must be continuously correlated with network traffic and other threat intelligence sources to truly assess risk.

  5. Effective Host Security

    Host SecurityHost vulnerability management and host monitoring for compromise is a special challenge with public clouds.

    Dynamic Environments: Traditional vulnerability management tools identify hosts with missing patches based in IP addresses. But clouds are dynamic with constantly changing IP addresses and new assets. Data from traditional vulnerability management tools must be combined with real-time cloud context to be effective.

    Lack of Context: Host activity data by itself does not provide enough context
    to assess the severity of a threat. It must correlate with other data from the cloud environment and threat intelligence sources to assess true risk.

  6. Incident Response Problems

    Cloud environments typically allow multiple privileged users to create, modify, and scale
    storage, network and compute resources whenever it’s necessary. That is excellent for development agility, but it can make incident response tricky when there’s a cybersecurity problem.

    Lack of Context: Without context, the severity of alerts are hard to ascertain which makes it tough to prioritize response. Risk severity must be algorithmically quantified by assessing
    context.

    Dynamic Environments: Cloud assets typically only exist for a couple of hours. Cloud environments change quickly. A snapshot of the environment at the time of the incident is required to perform a thorough analysis.

    Privileged Users: When multiple users have the privileges to create, delete, and configure cloud resources, determining the root cause of an incident can be tricky in a rapidly changing network. An audit trail is necessary to quickly pinpoint the responsible user and action that led to an incident.

    Alert Fatigue: Because cloud environments and assets change so quickly, administrators can be overwhelmed by a large volume of security alerts. In order for security to keep pace, alerts must support auto-remediation or integrate with existing incident response tools and DevOps workflows.

RedLock’s on-demand webinar on AWS security automation and orchestration will show you what you need to know about the security issues and how to address them.

Amazon Web Services reduces cloud security risks by securing the physical infrastructure. However, it's the customers' responsibility to develop adequate controls to mitigate risks after adopting AWS cloud.

With an understanding of AWS native cloud security tools and common risks, organizations can mitigate many issues. Adopting third-party tools for unified oversight and additional context can enable comprehensive control over AWS cloud security.

RedLock is a leading solution for comprehensive threat defense across AWS environments. Click here for more information about AWS Security and Compliance.


Related Posts