Providing Technology Training and Mentoring For Modern Technology Adoption
AWS is responsible for security "of" the cloud.
Customers are responsible for security "in" the cloud.
AWS is responsible for providing cloud-grade infrastructure, including Physical and Environmental Security, Redundant power supply, Data center access control, Storage device decommissioning controls, Network perimeter security.
You are responsible for security of your accounts, networks, and applications, including User access control, User roles, Application passwords, Instance OS patching, Network configuration (public / private)
AWS Infrastructure is designed and managed using best IT security practices and it is in compliance with a variety of IT security standards, including, but not limiting to Payment Card Industry (PCI) Data Security Standard (DSS), ISO 27001 Information Security Standard, Annual SOC (Service Organization Control)1 audits, SOC 2, SOC 3, Federal government systems evaluations, e.g. DIACAP Level 2 for DoD systems, US Federal Information Security Management Act (FISMA) compliance.
Security is consistently rated as a major concern and blockage to cloud adoption. Cloud security focuses on the security domains like access control, application security, information and data security, network security, operational security.
Cloud security in each of the above domains must enforce the three main principles of information security (the CIA triad) for both data at rest and data in transit. Confidentiality means data protection against unauthorized access. Integrity means data protection against modification and / or deletion. Availability is on-demand provisioning of data to authorized entities.
IP Spoofing is an attack in which AWS cloud-hosted instances are incapable of sending spoofed IP traffic. Port Scanning is an attack in which Client applications that perform port scanning are viewed as a violation of the AWS Cloud User Policy resulting in investigation and closing of the account. Please note that existing cloud vendor network security must be supplemented by client's own network hardening efforts.
OpenSSL Security Advisory for this SSL/TLS implementation bug was published 07 Apr 2014, "A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server".
AWS Security Advisory for Amazon EC2 with a work-around was published two days later (see the Notes section)
Sample of AWS Security Advisory for Amazon EC2
From: Amazon Web Services, Inc. <email@example.com>
Date: Wed, Apr 9, 2014 at 4:06 AM
Subject: AWS Security Advisory for Amazon EC2
Dear Amazon EC2 Customer,
The OpenSSL project has recently announced a security vulnerability in OpenSSL affecting versions 1.0.1 and 1.0.2 (CVE-2014-0160). Customers that are running Linux and are using SSL could be affected by this issue and should upgrade to a fixed version as soon as possible.
If you’re using the Amazon Linux AMI, you can simply run “sudo yum update openssl”, and then restart any services using OpenSSL to protect any at-risk instances.
Find more details and update instructions from the websites of your Linux vendor of choice:
* Amazon Linux AMI: https://aws.amazon.com/amazon-linux-ami/security-bulletins/ALAS-2014-320/
* Red Hat: https://rhn.redhat.com/errata/RHSA-2014-0376.html
* Ubuntu: http://www.ubuntu.com/usn/usn-2165-1/
Please note that several of the prominent Linux operating systems have released fixed packages that still bear the OpenSSL 1.0.1e name. Even though the OpenSSL project released 1.0.1g as their newest software, downstream Linux providers have in some cases elected to include just the fix for CVE-2014-0160 in their packages in order to provide a small update quickly. Updates to 1.0.1g are likely to come later.
For more information about this vulnerability, please visit
* AWS Security Bulletin page: https://aws.amazon.com/security/security-bulletins/
* OpenSSL’s official advisory: https://www.openssl.org/news/secadv_20140407.txt
* The Heartbleed Bug: http://heartbleed.com/
Amazon Web Services, Inc. is a subsidiary of Amazon.com, Inc. Amazon.com is a registered trademark of Amazon.com, Inc. This message was produced and distributed by Amazon Web Services Inc., 410 Terry Ave. North, Seattle, WA 98109-5210
Identity and Access Management (IAM) service deals with user and group management, authentication and authorization.Though IAM you can set and enforce the minimum acceptable strength of user passwords and other credentials as well as their expiration policies. IAM enables one to control access to AWS service APIs and to specific resources. IAM also enables one to add specific conditions to control how a user can use AWS, such as time of day, their originating IP address, or whether they are using SSL. IAM helps establish identity federation between a corporate directory (Active Directory, LDAP, etc.) and AWS services. One can enable Single Sign On (SSO) to the AWS Management Console and grant secure access to cloud resources and services under existing corporate identities (without the need to create new cloud-based identities)
IAM enables secure access to AWS services and resources for users. It also enables the creation and management of users in AWS, and the granting of access to AWS resources for users managed outside of AWS.
This enables the use of existing corporate identities to grant secure and direct access to AWS resources, such as S3 buckets, without creating a new AWS identity for those users.
Some of the AWS Account Security Features are :AWS Credentials, Multi-Factor Authentication (MFA), Access Keys, Key Pairs, X.509 Certificates, AWS CloudTrail.
Mandatory Access Control (MAC) systems can help you minimize access scopes in your cloud-based solutions at run-time. AWS supports both AppArmor and SELinux.
AppArmor is a Mandatory Access Control (MAC) system which is a kernel (LSM) enhancement to confine programs to a limited set of resources. AppArmor's security model is to bind access control attributes to programs rather than to users. AppArmor confinement is provided via profiles loaded into the kernel, typically on boot. AppArmor profiles can be in one of two modes: enforcement and complain. Profiles loaded in enforcement mode will result in enforcement of the policy defined in the profile as well as reporting policy violation attempts (either via syslog or auditd). Profiles in complain mode will not enforce policy but instead report policy violation attempts.
AppArmor is different from some other MAC systems on Linux in that it is path-based, allows for mixing of enforcement and complain mode profiles, uses include files to ease development and has a far lower barrier to entry than other popular MAC systems.
Core AppArmor functionality is in the mainline Linux kernel from 2.6.36 onwards; work is ongoing by AppArmor, Ubuntu and other developers to merge additional AppArmor functionality into the mainline kernel. [Source: https://wiki.ubuntu.com/AppArmor ]
Security-Enhanced Linux (SELinux) is a Linux kernel security module that provides a mechanism for supporting access control security policies, including United States Department of Defense–style mandatory access controls (MAC).
Cloud vendors assume responsibility for data center physical security
System access audit trail must be maintained and record the information like who accessed the system (user id and source IP address), log-in time-stamp, system(s) accessed, operations performed, was privilege escalation requested (e.g. sudo in Linux)?, log-out time (if any)
One should follow the security best practices like , enforcing the principle of least privilege, partitioning your infrastructure to minimize the exposure surface and contain damage if some parts of it are compromised, VPC / subnets / security groups, strong authentication between system components (on-way or two-way), encrypting sensitive Data-at-rest and Data-in-transit, using AWS managed services, creating audit trails for resource access via logging and leverage AWS services (CloudTrail and CloudWatch), and implementing MFA where possible.
Encryption in-place – data should be encrypted so as to protect confidentiality and integrity in case of a data breach.
Encryption in-transit – data should be encrypted when moved around (particularly between zones) to protect against disclosure due to man-in-the-middle attacks.
Strong authentication between system components – data should only be delivered to known participants.
Spear-phishing is a type of social engineering-based attack that focuses on a single user working for an organization, addressed from someone within the company in a position of trust and requesting information such as login IDs and passwords.Spear-phishing scams will often appear to be from a company's own human resources or technical support and may ask employees to update their username and passwords.Once hackers get this data they can gain entry into secured networks
In this article, we reviewed the concepts and techniques related to AWS security like access control, shared responsibility model, AWS account security features, security best practices.
Your email address will not be published. Required fields are marked *