Cloud Security: Sample Cloud Analysis
Introduction
You have recently been hired by another voting software company as the Chief Information Security Officer. This company does not have any cloud presence at all, mainly due to fear of the unknown on the part of the CEO. You have been hired to prepare a recommendation on the viability of AWS as a solution to their soaring data center costs. Your part in this report is based on the security services and practices of Amazon Web Services, and how those services and practices impact customer data.
Situation
Using what you have learned about AWS security, you are confident that the company can safely migrate their data and servers to it. While you are not responsible for determining the method of migration, or any aspect of the setup, you are responsible for briefing the CEO and executive committee on your findings related to security. When the migration is complete, you will be responsible for the company’s website (the primary source of revenue for the company), as well as many internal servers and internal data that will be stored in EC2/S3. You are to consider the security aspects of:
The internal data
The internal servers
The external (Internet) website, including the database servers that support that site
The company’s Microsoft Active Directory
The separation of data based on classification (i.e. regular company data vs. confidential financial data)
Disaster recovery/business continuity
Company policies related to the cloud
Technical Write-Up
Prepare a report for the executive committee detailing your findings of the security in AWS related to the points above. Do not go into detail about the implementation of the services in AWS, but rather concentrate on how AWS should be secured by your company. Include the services you will use from AWS and how they enhance or create the security infrastructure that protects your data. Discuss policies that you will need to create, but you do not have to specifically write those policies, rather just outline what they need to cover. This should be a fairly high-level report, going into details only where necessary to enhance the readers understanding of the security aspects and services provided by Amazon.
Requirements
3-6 pages in length (not including references or title pages) with references in APA style:
—-
Overview
As part of the current evaluations into the viability of AWS as a potential IT infrastructure platform, an assessment highlighting the necessary security precautions on a technical and procedural level has been needed. This includes protection of all critical technical assets impacted by such a move to AWS to ensure the continued operation of this company and protection of information ans services. This includes internal servers and services moving to the cloud as well as the external facing Voting Application that will also move to the cloud.
Purpose
This document lists the recommended technologies and policies to secure a potential migration to the Cloud using AWS.
Recommended Security Solutions
The internal data
Internal data moving to the cloud needs to be secured in transit and in storage. As data will be managed by a third party; evalation of the data should be performed prior to it moving to the cloud. Sensitive data will need to be encrypted in storage by default. This applies to all systems handling this data as well. As such EC2 and S3 storage will need encryption for all sensitive data. Unless otherwise stated all internal data should be considered sensitive.
An encrypted channel should be put in place for all communication going between on premises and AWS. AWS Direct Connect is recommended. As an alternative a site-to-site VPN may be put in place at a lower cost, with higher latency.
Backup and archiving of internal data is also a necessity to ensure ongoing availability of services and data and prevent business outages. As an interim measure Cloud Virtual Tape Libraries can be used as part of the transition to the cloud. On the final target architecture, data should be moved onto S3 services with replication across availability zones, and taking snapshots onto Glacier for long term storage.
The internal servers
The Amazon EC2 VM Import Connector should be used as to assist in the move of internal VMs onto AWS as EC2 instances in the move to AWS for IaaS. this will help to ensure that the VM instances are configured identically to on-premise servers and that they are transferred securely.
Servers will need to be patched on a regular basis by leveraging the AWS System Manager Patch Management capabilities.
Internal servers are expected to reside within private subnets in AWS, and only key servers which internal users should have access to should be routeable from on-premise computers. This can be defined within the subnet routing rules.
A second offline site should be defined within AWS at a different availability zone with active data replication (see internal data). In a disaster scenario the Disaster Recovery Plan should be carried out to bring the secondary site online to continue internal services and make internal data available again.
The external (Internet) website, including the database servers that support that site
Most servers should be placed within a private subnet, with only major interface points (ie Webservers gateways) placed within a public subnet.
Amazon API Gateway should be used as the interface point for any exposed APIs to ensure that back-end servers are not directly accessible by the public. Web servers should be protected by a Web Application Firewall to eliminate known web-based exploits on websites.
Servers should be set up with elastic load balancing and autoscale groups to dynamically grow with acceptable load to help prevent a DoS attack.
The servers for this service should reside in at least two different availability zones with data replication much like in the case of Internal Data. Ideally in this case the service would be able to operate across availability zones simultaneously with Route53 determining the appropriate availability zone instances to respond with based on user location. This will help in providing an overall resilient service and segmenting the impact in the case of an outage in one availability zone.
Servers should be set up with load balancing and autoscale groups to be able to grow within expected top limits. Logging and monitoring should be put in place with alerts on scaling to detect abnormal growth rates. A process will need to be defined on how to handle abnormal growth. For example whether to limit access for specific locations using CloudWatch.
The company’s Microsoft Active Directory
The company’s Active Directory should be synchronizes with AWS Directory services to allow AWS to leverage corporate user information and provide a unified authentication that is traceable for security events.
IAM rules and groups should be used in AWS, and should leverage Active Directory Roles where possible to determine what users can perform what actions within AWS. A process needs to be defined for change control on Active Directory and IAM updates or changes so that adequate approvals are recorded and verified.
Multi Factored Authentication needs to be enforced for all privileged users performing privileged actions in AWS, and all critical actions must be logged with verifiable user identification information along with event and action details.
The separation of data based on classification (i.e. regular company data vs. confidential financial data)
Data classification can be determined using Amazon Macie and it’s compliance requirements before analyzing data sets. The results of Macie’s analysis can be used to determine the appropriate controls that can be placed on the data, and whether data should be re-organized to provide better data enhancements.
Depending on which services are using the data sets (internal, external, or other categories) different access control rules can be put in place or data can be blocked all together through a combination of this analysis and restructuring; as well as some of the controls described in the Active Directory section above.
Disaster recovery/business continuity
A set of Disaster Recovery Plans and Business Continuity Plans across both internal and external services needs to be defined and be complete and tested on a regular basis.
Technologically internal and external disaster recovery plans can be different based on the Recovery Time Objectives and Recovery Point Objectives they each have. A warm or cold DR strategy can be employed for the internal applications where a hot DR strategy may be needed for the external Voting Application service based on expected usage and demands. Strategies for each have been suggested in the sections above.
Policies
The following policies should be written or updated as a part of this move to AWS cloud
patching
change management
Password Construction Guidelines
Password Protection Policy
Security Response Plan Policy
End User Encryption Key Protection Policy
DR Plan
Business Continuity Plan
Acceptable Use Policy
Data Breach Response Policy
Remote Access Policy
Remote Access Tools Policy
Router and Switch Security Policy
Wireless Communication Policy
Wireless Communication Standard
Database Credentials Policy
Technology Equipment Disposal Policy
Information Logging Standard
Lab Security Policy
Server Security Policy
Software Installation Policy
Web Application Security Policy
References
AWS Systems Manager Patch Manager. (n.d.). Retrieved from https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html
How Patches Are Installed. (n.d.). Retrieved from https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-how-it-works-installation.html
IAM Best Practices. (n.d.). Retrieved from https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html
determine and trace sensitive and private information:
Features: Amazon Macie: Amazon Web Services (AWS). (n.d.). Retrieved from https://aws.amazon.com/macie/details/
“Restricting the Geographic Distribution of Your Content.” Amazon, Amazon, docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/georestrictions.html.
(n.d.). Retrieved from https://docs.aws.amazon.com/rds/?id=docs_gateway
Deekonda, A. (2019, April 17). Implementing a disaster recovery strategy with Amazon RDS: Amazon Web Services. Retrieved from https://aws.amazon.com/blogs/database/implementing-a-disaster-recovery-strategy-with-amazon-rds/
Creating an SMB File Share. (n.d.). Retrieved from https://docs.aws.amazon.com/storagegateway/latest/userguide/CreatingAnSMBFileShare.html
Best Practices for Amazon EC2. (n.d.). Retrieved from https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-best-practices.html
(n.d.). Retrieved from http://docs.media.bitpipe.com/io_13x/io_136616/item_1510269/CloudBerry_Lab_Whitepaper_A_Complete_Guide_for_Backup_and_DR_on_AWS.pdf