Protecting the AWS environment requires continuous security to ensure that data is not left unprotected. AWS offers a rich set of tools and technologies to help protect and ensure that sensitive data is not exposed. A recent security breach at Booz Allen Hamilton exposed sensitive NGA data and was extensively reported in the media. It is critical to ensure that the AWS services such as s3 are configured properly and continuous security monitoring is executed using best practices prescribed by FISMA and FedRAMP for Government Systems. Security breaches of the kind chronicled at Booz Allen Hamilton generally are not just about technology but a larger process, policies and procedures problem.
stackArmor’s ARM methodology addresses this holistically through a Assess. Remediate and Monitor paradigm that is explained on our website. Organizations operating in regulated industries such as Financial Services, Healthcare, Public Sector and US Federal & Defense markets must pay special attention to relevant policies prescribed in the NIST Cybersecurity Framework under the section of Data Security (PR.DS) specifically sub-category PR.DS-5: Protections against data leaks are implemented. Specific controls for FISMA, FedRAMP and applicable controls for Federal contractors based on NIST 800-53 Rev 4 include NIST SP 800-53 Rev. 4 AC-4, AC-5, AC-6, PE-19, PS-3, PS-6, SC-7, SC-8, SC-13, SC-31, SI-4. The key question is where did the breakdown occur related to the Booz Allen Hamilton data breach?
Data protection and integrity management is a very core information systems management function. All federal contractors and system owners in regulated industries should use this opportunity to review their compliance with the relevant standards and controls applicable to their industries. The process of Data Protection includes a well-designed and structured Data Loss Prevention (DLP) strategy.
Data Loss Prevention (DLP)
The first step to DLP is to inventory and categorize your data assets. For most US Federal contractors and system owners, the NIST’s FIPS 199 Security Categorization publication is a great starting point. The system and its data is categorized in High, Moderate or Low risk along three dimensions of Confidentiality, Integrity and Availability. Once the data is categorized and its risk profile is understood, it is critical to inventory it. Do you have a structure and method in place to inventory your data? The stackArmor Data Security team has leveraged AWS’ Serverless Datalake solution to create meta tags around datasets and to help create a basic inventory of available data especially on the AWS s3 service. There are a number of other available solutions for CMDB of datasets both open source and commercial products. Then it is critical to identify the potential threat vector – is it data at rest, in motion or during processing? Network, disk, and access controls are required to adequately respond to such threats. Once a comprehensive and structured, Data Loss Prevention (DLP) strategy and plan is in place, it is important to implement the solution.
Protecting AWS s3 based data through policies
The AWS s3 service is a very popular and widely used service for storing data and files in buckets. There is a comprehensive set of tools, support and resources available to configure, manage and monitor all aspects of the s3 service. When creating a s3 bucket, by default, all resources—buckets, objects, and related subresources (for example, lifecycle configuration and website configuration)—are private: only the resource owner, an AWS account that created it, can access the resource. Access to other entities must be granted through an explicit access policy. AWS s3 offers access policy options at the resource-based level or user-based level. For example, bucket policies and access control lists (ACLs) are resource-based policies, whereas access policies attached to users are user policies.
Encrypting AWS s3 data
A multi-layer security in depth approach recommends encrypting the stored data at rest. AWS s3 provides for multiple server-side encryption approaches that offer AES-256 bit protection. The s3 service encrypts data at the object level as it writes it to disks in its data centers and decrypts it when it is accessed. AWS offers three encryption options depending on requirements for key management and ownership. The three options include:
- AWS Managed Keys (SSE-S3) – Each object is encrypted with a unique key employing strong multi-factor encryption. AWS s3 server-side encryption uses 256-bit Advanced Encryption Standard (AES-256).
- AWS KMS-Managed Keys (SSE-KMS) – SSE-KMS also provides an audit trail of when the keys were used and by whom. It offers the ability to create and manage encryption keys generated by the user using the KMS service.
- Customer-Provided Keys (SSE-C) – The customer manages the encryption keys and Amazon S3 manages the encryption, as it writes to disks, and decryption, when accessing objects.
Learn more about server side encryption options and available solutions.
Monitoring s3 buckets
AWS s3 notifications provide alerts when buckets or their contents are updated or deleted. Any changes in the bucket can generate and send alerts to a specified destination e.g. a SQS queue or a Lambda function. Such an alerting feature allows the creation of a monitoring system that checks the relevant policy associated with the object to determine if it is encrypted or not and if it has public access rights. Learn more about AWS s3 notifications on the AWS site.
Managed Security Services with stackArmor ThreatAlert
stackArmor has developed an easy to use light-weight AWS misconfigurations and security solution to automatically detect and manage security events within an AWS environment. stackArmor ThreatAlert provides a ready made and highly configurable service that can be deployed within the customers’ account without any long-term subscription fees. The ThreatAlert system utilizes the AWS EC2 API’s to continuously monitor the application of best practices from a security perspective. The table provides a sample set of rules and vulnerabilities detected and monitored by ThreatAlert. Some sample rules included in stackArmor ThreatAlert are shown below.
SA.AWS.S3.ACC.0001 ACL – AuthenticatedUsers USED
SA.AWS.S3.ACC.0002 ACL – AllUsers USED.
SA.AWS.S3.ACC.0003 ACL – Unknown Cross Account Access
SA.AWS.S3.ACC.0004 POLICY – This Policy Allows Access From Anyone.
SA.AWS.S3.ACC.0005 POLICY – Unknown Cross Account Access.
If you have an interest in seeing how stackArmor AWS and Security experts can help secure your AWS environment and meet your regulatory compliance obligations calls us at 1-888-964-1644 or send an email to solutions at stackArmor dot com.
