AWS Series #2: Cloud Security Roadmap

This part of AWS series is about Cloud Security Roadmap. It is imperative that you understand how much security is considered essential and what is considered over-architecting of security for your Organization. A good rule is to consider all the data and information assets strictly private with restricted and need based access, extremely conservative approach while providing access rights to users. The first essential step to work on the Security Layer, which is part of the “Must have Stack” is to have a clear Security Roadmap for your organization.

Before even starting to think about “S” of Cloud Security, it is imperative that the Organization has a Cloud Security expert and team working on coming up with the Roadmap and the Security Layer. The team size depends on the size of the firm. While the Security team might have implemented strong Security protocol and working well in the On-Premise environment, Cloud is a different ball game and Cloud Security Expert along with the On-Premise Security experts must work hand-in-hand to get a clear Cloud Security Roadmap and designing AWS Security Layer. I am not an AWS Cloud Security Expert. This article is part of the AWS series of Articles around the four stacks that I am writing. The Below is only an indication / representative and must not be taken as a blue print. The AWS Cloud Security as mentioned, must be designed by “Cloud Security Expert” of the organization. Having said that, every one must be aware and security must be practiced throughout the organization.

How will you ensure your organization follows Security First Architecture:

Every organization today is an “Internet Organization” with organizations moving towards cloud adoption. All organizations that architects using Public / Private / Multi-cloud are exposed to all kinds of “Cyber-Security threats” and it becomes important for the organization to ensure that the Security-First approach is adopted and is not optional anymore. DevSecOps / SecOps is an emerging field and is effectively integrated with the Application / Platform Architecture and Software Development Lifecycle. To enforce Security-First architecture, it is imperative that every organization has a strong Security by Design Framework, and adoption of this within the firm must be part of the KPI for all those who are involved in the cloud-related work.

Building a Security by Design Framework:

Regardless of the size of your Organization, Security is the key, and especially with Cloud architecture, organizations must have a strong Security By Design Framework. This article is about how to build Security By Design framework and adopt a Security-First approach for your organization. Security is not an afterthought and all the products and services that are part of the architecture must be encompassed by Security. Before designing the security framework for your organization you need to understand the following

As part of your Technology Risk Management process for your organization, the Threat and Risk register must be maintained and updated. As much as Security by design is important, how you react to threat and what processes go into threat prevention is important. Most of the country’s/state/city’s Technology Risk Management guidelines will suggest what, how, when, where and which security and governance measures shall be taken by the firm. This is covered as part of the auditing process for the firm and must be furnished, surveyed and any findings must be fixed within the stipulated period.

1. Build and maintain Threat and Risk Register

1. Define all types of threats that your firm is/potentially exposed to.
2. The most sensitive data and what kind of data protection protocol is followed included Encryption at Rest, Encryption at Transit, Encryption at use.

2. Assess your firm’s current policy, remediation management, and routine exercises

3. Having a solid, structured, simple, adoptable and measurable Security Roadmap.

4. Continuously assess and measure your firm’s security policy

Landing Zone:

AWS Landing Zone is the essential first step to set up secure and multi-account environment for your organization. When this article was written (June 2021), AWS Landing Zone provides long term support and organizations that prefers to use Landing Zone must do it via AWS Control Tower and Customization for AWS Control Tower. It is ok to create Landing Zone either before or after understanding the Security needs of the organization as the Landing Zone itself will guide what needs to be done and will take you in the right direction.

AWS Landing Zone includes 4 accounts (1) Organization Account (2) Shared Services Account (3) Log Archie Account (4) Security Account. Add On products can also be deployed using the AWS Service Catalog such as Centralized Login solution and AWS Managed AD and Directory connector for AWS Single Sign-On.

Reference: AWS Landing Zone.

(1) Organization Account:

The Landing Zone is created deployed into the AWS organization Account. Provides ability to create and financially manage user accounts. Using this account you can configure Landing Zone configs, S3 buckets and pipelines, organization’s Service Control Policies and Single Sign-On.

(2) Shared Services Account:

This account is a reference for creating shared services such as directory services. This account hosts AD, SSO integration across several AWS sercices.

(3) Log Archive Account:

This account contains central S3 bucket for storing all the copies of monitoring tool CloudTrial and AWS Config files in log archive account.

(4) Security Account:

This account creates (1) Read-only for auditor (2) Read-Write for Admin cross account roles from account to all AWS Landing Zone managed accounts.

Understand Security needs for your Organization:

In order to understand the Security needs for your Organization, you first need to understand what Security threats your organization is exposed to and if you move cloud what are the potential threats you may be exposed to. Designing for security should be at all levels

1. Ring-fence Security around your Cloud Infrastructure
2. Login Security
3. Security-First design for each and every servicies and products added from AWS.
4. Security for Data
5. Security for your Web Server and Logs etc.

This is further discussed as part of AWS Security Layer.

Before going ahead with the To-Be State of security, understanding the As-Is Security in place and where you want to potentially move towards to the desired state, a clear and structured Gap-Analysis for Security is a must.

For most of the above, as part of the Technology Risk Management (TRM) and Regulatory needs, proper Risk Registry and actions would have been caught and maintained. As part of this Cloud Security Roadmap exercise, it is imperative to read and understand the existing so the the Cloud Security section can be amended to the existing TRM.

General Risk Assessment:

1. List of all the Information Assets in the firm including data, source code, client information, business critical information etc., that are critical to the firm.
2. List of Threats and vulnerabilities of the all the Business Processes.
3. If exposed to any of the Risk, what are the legal, financial, operational risks.
4. What are the standard ways of measuring such Risks.
5. What are the current Risk monitoring, Reporting, Reviewing and Treatment mechanisms in place.

Cryptographic Assessment:

1. What Information assets must be secured and under what security protocol HIPPA, PII etc.
2. What are the current Cryptographic practices, algorithms and protocol in the firm and what products are being used.
3. How the Security, Corruption of the Cryptographic algorithm is ensured, how the phishing tests are performed on the Cryptographic algorithm,
4. How the cryptography usage is currently monitored.
5. How frequently the keys and algorithm is rotated internally and with external providers. Cryptography Key management protocol. Expiration of Cryptographic keys, revoking of the keys etc.

Cyber Security Vulnerability Assessment:

1. Identify the Cyber Security threats and identify potential vulnerabilities.
2. What kind of Cyber Security threats the firm has been subjected to in the past 3 years and what treatment and remediation actions has been taken.
3. Current Cyber Security Penetration test protocol, Cyber Security exercises, Cyber event detection methods and tools in place.
4. Cyber incident response management and what is the maximum legal actions, penalties etc., paid by the firm due to an event.

Data Security needs:

1. The Data / Information Assets Register and what are the vulnerable Data or Information Assets within the organization.
2. What are the different kinds of Data Assets such as Personal Data, Clients Data, Financial Data, Images, IoT etc. and how each of them are secured and what International standards and protocol used to secure.
3. Data threats, compromises, fines, data locking issues and payments etc., made during the last 3 years and which part of it was compromised and what was the remediation action.
4. Current level of Data Virtualisation in place.
5. Data access and sharing protocols.

Infrastructure Security needs:

1. Current Hardware and Software Infrastructure and International standards adopted.
2. List tools and standards of early detection protocol in place.
3. End-Point protections, System ring fencing etc., in place
4. Number of compromises, threats, fines, locks and payments etc., made during the past 3 years.
5. Current level of Virutalization in place.
6. System Accessibility protocol.

Network Security needs:

1. Number of Network intrusions happened, break of network access controls etc. and incidents happened, fines and payments made during the past 3 years.
2. Denial of service and cyber attack list and remediation.
3. LAN and WAN security protocol and ring-fencing in place.
4. Internet and web browsing in servers and common systems and allow and deny websites and services.
5. Network Security devices, Network access control, DDoS protection etc. in place.

Design for Security or Security By Design:

Security by Design must be in conjunction with the SDLC and Technology Risk Management. What is applicable to SDLC is applicable to Security also.

Security By Design Lifecycle and Framework:

The Security by Design Lifecycle must follow (and more steps depends on the organization) the Software Development Life Cycle.

Along with the above, establishing clear Control gates and having a sophisticated monitoring protocol and early detection of the Risk is imperative.

Based on the size and kind of organization (Finance, Health-care, Manufacturing etc.) a defined Security By Design Framework must be established by the organization in-line with the above Lifecycle.

Develop Security-As-Code:

Like Infrastructure-As-Code, Security-As-Code is the best practice for Security by Design so that the standards, governance and required protocols can be established and is central and any changes to regulations or compliance are impacted at a single place instead of having multiple moving components for Security by Design. Security-As-code is about building the Secuirty into the DevOps tools and practicies — the DevSecOps CI/CD.

Like 12 Factor App where all the essential ones for the Serverless design is encompassed, a Security-As-Code encomposses all the required security protocol for different types of applications and that must be included before any system design. This ensures that the entire infrastructure and each and every component is Ring-Fenced and tight in security. Once integrated into DevOps, it is an essential part of any application that gets designed and delivered by the organization whether it is internal or external facing. With Development of Software, you keep the purpose of the software in mind and try to achieve the end state, security might often be compromised. With Secuirty-As-Code, Security is also part of the Software’s end purpose. The key components of Secuirty-As-Code incldues

1. Security Testing
2. Vulnerability Scanning
3. Access restrictions and policy controls

As most of the firms are moving to the DevOps Model, implementing DevSecOps makes sure that the firm has designed and developed for Security By Design and can respond to any security or compliance changes faster, respond to threats easier, better collaboration across the business units and teams, better ways to automate security, increases application security testing, security literacy can be easy due to its visibility, makes release easier and simpler due to quick vulnerability scans etc., Security patches and upgrades can be done much faster.

Identify Team segregation and users for user creation:

Once the DevSecOps (essential for Security By Design) is in place, clearly identifying Admins, Super users, Power users and Simple users for each of the different kinds of applications and associating them at policy level becomes part of the Security-As-Code. Who should access what and at what level, how conservative the firm should be in terms of data access etc. will be defined at a central firm level and it need not be essentially an independent team’s decision. There will be ready-made policies available, the only job at this stage is to simply attach the users to such policies so that the segregation and access for the user and creation is not only simpler but is highly compliant to the Organization’s central Secuirty system. Auditing, monitoring and gathering the issues becomes easier and also early identification of threats are also made simple because of this.

Time-Out and other policies:

With DevSecOps, having policies at different levels including the Time-out and several other policies are well defined and configurable. Most of the methods as stated in the above section.

Security Governance and Adoption:

Security Hub and AWS Organization:

Security Hub provides comprehensive view of the Security state in AWS and enables to check your environment against security indstry standards and best practicies. It collects security data across your AWS accounts and services (including thrid party) you use — it identify and reports any highest priority security issues. If Security Hub is used with AWS Organization, automatically Security Hub is enabled for all accounts.

Referenfce: AWS

Cloud Security Governance:

1. Strict implementation of DevSecOps and Security By Design
2. DAMA or DCAM — Data Governance and Secuirty
3. A good reference for Cloud Security in the AWS Blog.
4. There are several amazing references by Drew Firment on Cloud Governance.

Note: This section of the article will be updated in the near future.

AWS Compliance Center:

AWS Compliance Center is for cloud related regulatory requirements and enables to research the impact of your industry for the country of interest. You can directly contact AWS to enable this for the country of your organization’s interest.

Benefits:

• Identify Regulatory Requirements
• Browse Country specific resources
• Discover AWS Compliance programs.

The AWS Security Layer:

The next series of 5 articles is about the AWS Secuirty Layer.

AWS Security Layer

Parent Article: AWS Multi-Part series.