Security and Compliance in AWS
These are my notes and thoughts on security and compliance on AWS.
Security is a primary focus for AWS across all services and one of the most prominent benefits of using a cloud provider. AWS can implement extremely robust security through economies of scale that can far exceed what any organization could have the finances and experience to implement on their own.
Shared Responsibility Model
Any large and complex IT system is built upon multiple layers of services and components, and a cloud is certainly a prime example of that model. With any cloud offering, the underlying infrastructure is the sole responsibility of the cloud provider. This includes everything from the physical building and facilities to the power infrastructure and redundancy, physical security, and network cabling and hardware components. This also includes the underlying computing infrastructure such as hypervisors, CPU, memory, and storage.
Make sure to understand the shared responsibilities model and what the customer is responsible for in each service category.
With Infrastructure as a Service, the customer is responsible for everything beginning with the operating system. The cloud provider is responsible for the underlying host infrastructure from which the customer can deploy virtual services into, whether they are virtual machines or virtual networking components.
With Platform as a Service, the cloud provider is responsible for an entire hosting platform, including all software, libraries, and middleware that the customer needs. The customer then deploys their application code and data into the environment. This is most heavily used for DevOps, where developers can quickly obtain fully featured hosting environments and only need to deploy their code and any needed data to test and develop with, and do not need to worry about any underlying operating system or middleware issues.
With Software as a Service, the cloud provider is responsible for everything except specific customer or user data. SaaS is a fully featured application that a customer only needs to load users or do minimal configuration, along with possibly importing data about customers or services.
Managed vs. Unmanaged
A major question for any customer is whether to use managed or unmanaged resources within a cloud environment. While both can provide what is needed to meet the business needs of the customer, there are pros and cons of each approach.
Managed resources are those where the cloud provider is responsible for the installation, patching, maintenance, and security of a resource. On the inverse, unmanaged resources are those hosted within a cloud environment, but where the customer bears responsibility for host functions. Managed resources will typically cost more than unmanaged resources.
Regulatory Compliance
If your application utilizes or stores any type of sensitive information, there will be specific regulatory requirements that you will need to incur compliance with. This type of data can range from credit card and financial information to health records, academic records, or government systems and data.
To assist with meeting regulatory requirements, AWS offers their Artifact service, which can be accessed directly from the AWS management console. As part of the Artifact service, AWS undergoes certification reviews and audits by various governing bodies. An additional feature that AWS offers through Artifact is enabling a customer to review and accept agreements for their individual account and what they need to maintain compliance with, along with terminating the agreement if no longer needed.
Data Security
Several toolsets and technologies are commonly used as data security strategies. These are: encryption, key management, masking, obfuscation, anonymization, and tokenization.
With the concepts of multitenancy and resource pooling being central to any cloud environment, the use of encryption to protect data is essential and required, as the typical protections of physical separation and segregation found in a traditional data center model are not available or applicable to a cloud environment. The architecture of an encryption system has three basic components: the data itself, the encryption engine that handles all the encryption activities, and the encryption keys used in the actual encryption and use of the data.
Data in transit is the state of data when it is actually being used by an application and is traversing systems or going between the client and the actual application. Whether the data is being transmitted between systems within the cloud or going out to a user’s client, data in transit is when data is most vulnerable to exposure of unauthorized capture. Within a cloud hosting model, the transmission between systems is even more important than with a traditional data center due to multitenancy; the other systems within the same cloud are potential security risks and vulnerable points where data capture could happen successfully.
In order to maintain portability and interoperability, the cloud security professional should make the processes for the encryption of data in transit vendor neutral in regard to the capabilities or limitations of a specific cloud provider. The most common method for data in transit encryption is to use the well known SSL and TLS technologies under HTTPS. With many modern applications utilizing web services as the framework for communications, this has become the prevailing method, which is the same method used by clients and browsers to communicate with servers over the internet.
Data at Rest
Data at rest refers to information stored on a system or device. This data can be stored in many different forms to fit within this category.
Data residing on a system is potentially exposed and vulnerable far longer than short transmission and transaction operations would be, so special care is needed to ensure its protection from unauthorized access.
While encrypting data is central to the confidentiality of any system, the availability and performance of data are equally as important.It is important to ensure that encryption methods provide high levels of security and protection and do so in a manner that facilitates high performance and system speed.
With portability and vendor lock-in considerations, it is important to ensure that encryption systems do not effectively cause a system to be bound to a proprietary cloud offering. Data at rest encryption and security are very important in a cloud environment due to the reliance on virtual machines. In a traditional data center, you can have systems that are powered off and inaccessible. In a virtual environment, when a system is not powered on or started, the disk and memory are gone, but the underlying image still exists within storage and carries a possibility of compromise or corruption, especially if a developer has stored application or customer data on the VM image.
Encryption with Data States
Encryption is used in various manners and through different technology approaches, depending on the state of the data at the time.With data in use, the data is being actively accessed and processed. Because this process is the most removed from and independent of the host system, technologies such as data rights management and information rights management are the most capable and mature approaches that can be taken at this time.
Challenges With Encryption
There are a myriad of challenges with implementing encryption. Some are applicable no matter where the data is housed, and others are specific to cloud environments. A central challenge to encryption implementations is the dependence on key sets to handle the actual encryption and decryption processes. Without the proper security of encryption keys, the entire encryption scheme could be rendered vulnerable and insecure. With any software based encryption scheme, core computing components such as processor and memory are vital, and within a cloud environment specifically, these components are shared across all of the hosted customers.
Encryption Implementations
The actual implementation of encryption and how it is applied will depend largely on the type of storage being used within the cloud environment. With database storage systems, two layers of encryption are typically applied and available. First, database systems will reside on volume storage systems, resembling a typical file system of a server model. The actual database files can be protected through encryption methods at the file system level. This also serves to protect the data at rest.
For object storage, apart from the encryption at the actual file level, which is handled by the cloud provider, encryption can be used within the application itself. The most prevalent means for this is through IRM technologies or via encryption within the application itself. With IRM, encryption can be applied to the objects to control their usage after they have left the system. With application-level encryption, the application effectively acts as a proxy between the user and the object storage and ensures encryption during the transaction. However, once the object has left the application framework, no protection is provided.
Lastly, with volume storage, many of the typical encryption systems used on a traditional server model can be employed within a cloud framework. This encryption is most useful with data at rest scenarios. Due to the application itself being able to read the encrypted data on the volume, any compromise of the application will render the file system encryption ineffective when it comes to protecting the data.
Hashing
Hashing involves taking data of arbitrary type, length, or size and using a function to map a value that is of a fixed size. Hashing can be applied to virtually any type of data object, including text strings, documents, images, binary data, and even virtual machine images.
The main value of hashing is to quickly verify the integrity of data objects. Within a cloud environment this can offer great value with virtual machine images and the potentially large number of data locations within a dispersed environment. As many copies of a file are potentially stored in many different locations, hashing can be used to very quickly verify that the files are of identical composure and that the integrity of them has not been compromised.
A large variety of hashing functions are commonly used and supported. The vast majority of users will have no problem using any of the freely and widely available options, which will suit their needs for data integrity and comparison without issue.
Key Management
Key management is the safeguarding of encryption keys and the access to them. Within a cloud environment, key management is an essential and highly important task, while also being very complex. One of the most important security considerations with key management is the access to the keys and the storage of them. Access to keys in any environment is extremely important and critical to security. In a cloud environment, where you have multitenancy and the cloud provider personnel having broad administration access to systems, there are more considerations than in a traditional data center concerning the segregation and control of the staff of the customer.
No matter what hosting model is used by an organization, a few principles of key management are important. Key management should always be performed only on trusted systems and by trusted processes, whether in a traditional data center or in a cloud environment. In a cloud environment, careful consideration must be given to the level of trust that can be established within the environment of the cloud provider and whether that will meet management and regulatory requirements. If the externally hosted key management system becomes unavailable, like an inadvertent firewall change or ACL change, the entire system will be inaccessible.
Key storage can be implemented in a cloud environment within the same virtual machine as the encryption service or engine. Internal storage is the simplest implementation, it keeps the entire process together.
Tokenization
Tokenization is the practice of utilizing a random and opaque token value in data to replace what otherwise would be a sensitive or protected data object. The token value is usually generated by the application with a means to map it back to the actual real value, and then the token value is placed in the data set with the same formatting and requirements of the actual real value, so that the application can continue to function without different modifications or code changes. Tokenization represents a way for an organization to remove sensitive data from an application without having to introduce more intensive processes such as encryption to meet regulatory or policy requirements.
Data Loss Prevention
A major concept and approach employed in a cloud environment to protect data is known as data loss prevention. It is a set of controls and practices put in place to ensure that data is only accessible and exposed to those users and systems authorized to have it. The goals of this strategy for an organization are to manage and minimize risk, maintain compliance with regulatory requirements, and show due diligence on the part of the application and data owner.
DLP Components
Any DLP implementation is composed of three common components: discovery and classification, monitoring, and enforcement. The discovery and classification stage is the first stage of the DLP implementation. It is focused on the actual finding of data that is pertinent to the DLP strategy, ensuring that all instances of it are known and able to be exposed to the DLP solution, and determining the security classification and requirements of the data once it has been found. This also allows the matching of data within the environment to any regulatory requirements for its protection and assurance.
Once data has been discovered and classified, it can then be monitored with DLP implementations. The monitoring stage encompasses the core function and purpose of a DLP strategy.
The final stage of a DLP implementation is the actual enforcement of policies and any potential violations caught as part of the monitoring stage. If any potential violations are detected by the DLP implementation, a variety of measures can be automatically taken, depending on the policies set forth by the management.
DLP Data States
With data at rest, the DLP solution is installed on the systems holding the data, which can be servers, laptops, desktops, workstations, or mobile devices. In many instances, this will involve archived data and long-term storage data.
With data in transit, the DLP solution is deployed near the network perimeter to capture traffic as it leaves the network through various protocols such as http,https, and smtp. It looks for data that is leaving or attempting to leave the area that does not conform to security policies.
Lastly, with data in use, the DLP solution is deployed on the workstations or devices in order to monitor the data access and use from the endpoints. The biggest challenges with this type of implementation are reach and the complexity of having all access points covered.
DLP on end-user devices can be a particular challenge for any cloud application. Because it requires the end user to install an application or plug in to work, you will need to make sure you fully understand the types of devices your users will be utilizing, as well as any costs and requirements associated with the use of the technology.
DLP Cloud Implementations and Practices
The cloud environment brings additional challenges to DLP. The biggest difference is the way cloud environments store data. Data in a cloud is spread across large storage systems, with varying degrees of replication and redundancy, and oftentimes where the data will be stored and accessed is unpredictable. For a DLP strategy, this can pose a particular challenge because it makes properly discovering and monitoring all data used by a system or application more difficult, especially because the data can change locations over time.
Data De-identification
Data de-identification involves using masking, obfuscation, or anonymization. The theory behind masking or obfuscation is to replace, hide, or remove sensitive data from data sets. The most common use for masking is making available test datasets for nonproduction and development environments. By replacing sensitive data fields with random or substituted data, these nonproduction environments can quickly utilize datasets that are similar to production for testing and development, without exposing sensitive information to systems with fewer security controls and less oversight.
Typically masking is accomplished either by entirely replacing the value with a new one or by adding characters to a data field. This can be done wholesale on the entire field or just portions of it.
The two primary methods for masking are static masking and dynamic masking. With static masking, a separate and distinct copy of the data set is created with masking in place. This is typically done through a script or other process that will take a standard data set, process it to mask the appropriate and predefined fields, and then output the dataset as a new one with the completed masking done. The static method is most appropriate for data sets that are created for nonproduction environments. With dynamic masking, production environments are protected by the masking process being implemented between the application and data layers of the application. This allows for a masking translation to take place live in the system and during normal application processing of data. Dynamic masking is usually done where a system needs to have full and unmasked data but certain users should not have the same level of access.
With data anonymization, data is manipulated in a way to prevent the identification of an individual through various data objects. It is often used in conjunction with other identifiers such as masking. Data generally has direct and indirect identifiers, with direct identifiers being the actual personal and private data, and indirect identifiers being attributes such as demographic and location data. Data anonymization is the process of removing the indirect identifiers to prevent such asn identification from taking place.
AWS Identity and Access Management
Just like a root account on a computer system, the AWS root account has full access to everything under your account. It can create users, provision resources, and incur financial obligations for any activities that are done with it. As with superuser accounts on any computer system, it is a best practice to not use the root account unless absolutely necessary, but instead to provision accounts that have more limited access.
The AWS IAM dashboard can be found at https://console.aws.amazon.com/iam and you can log into this address using the same email address and password for your root account.
Securing The Root User
When you created your root account, you established a password for it. This password is what you will use to access the AWS console when using the root account. Along with a strong password, MFA will add another layer of security to the account so it is recommended to do this.
IAM User Groups and Roles
Groups are used to assign a standard set of permissions to users as they are added to the system. As you add more users, going through each user and assigning permissions can become a very labor intensive process. It is easy to make errors like this. Groups represent the way to create packages of settings that are maintained in a single location. As users are added to the system, they can be added to the appropriate groups and will automatically inherit the appropriate permissions in a consistent manner.
Roles in AWS are the granular permissions that users can be granted. Within each AWS service, there are multiple roles that allow different activities, such as reading data, creating data, deploying services, and provisioning access. The AWs system has predefined roles for every single service offering that you can select to attach to groups. Within each service offering, there are several different roles that grant different types of access.
Federated Access
A powerful way for provisioning user access to AWS is through federated access. With federated access, you can use technologies such as SAML or Microsoft Active Directory to provision users, rather than creating them manually through the IAM account process in the console. The big advantage with using federated access is that users will use accounts and credentials they already have established to access AWS. This enables an organization to use already existing security and account practices, without having to worry about maintaining them in another system.
SAML
SAML 2.0 is the latest standard put out by the nonprofit OASIS consortium and their security services technical committee and can be found at https://www.oasis-open.org/standards#samlv2.0. SAML is xml based and it is used to exchange information used in the authentication and authorization process between different parties. Specifically, it is used for information exchange between identity providers and service providers, and it contains within the xml block the required information that each system needs or provides.
User Reporting
As with any system that has a number of users on it, you will want a way to keep track of what users you have, what access they have, when they last logged in, and their status of being issued keys and when they were last rotated. This report is offered as a csv download that you can either review directly from the csv or import into any data or reporting tool you desire. The report can be accessed from the left menu with the credential report button.
AWS Support
When we created an account, we selected the free support option. It is not ideal for organizations that are more heavily invested in AWS and certainly not for anyone running production business services in AWS.