Which of the design principles for security in the cloud is the architect applying

How to apply security by design in the cloud

Here are three areas in the cloud where organizations should apply security-by-design principles.

1. Cloud service providers' infrastructures

Developers and other stakeholders should follow the shared responsibility model and use built-in security-by-design principles within their cloud service provider's (CSP) infrastructure.

These built-in security controls from the provider can include the following:

• hardened and secure hypervisor technology;
• secure APIs that are tested and validated regularly;
• access restrictions between tenants; and
• cloud provider administration, for example, using virtualization and network segmentation.

Google Cloud, for example, describes several tactics employed to harden its kernel-based VM hypervisors, including vulnerability research, attack surface reduction and source code tracking.

2. DevOps pipeline

The second opportunity to build a secure-by-design cloud infrastructure is in the DevOps pipeline. Given the nature of software-defined infrastructure and deployments, there are many ways to ensure security controls and considerations are baked into cloud-focused applications.

To begin, DevOps and security teams should engage in threat modeling to ensure all parties understand the design of the applications being built and deployed, the threat surface, the controls available and the technologies they're going to use, including CSP offerings. Threat modeling should enable organizations to make design decisions with security as a priority before developing and deploying applications and components.

Additional security-by-design principles in the DevOps pipeline should include the following:

• automated static source code scanning upon code check-in, with vulnerability and risk thresholds defined for what code is allowed to progress in the builds and what needs to be fixed first;
• use of secure container and workload images that have been scanned for package and component vulnerabilities -- similar to source code scans, a minimum viable threshold of vulnerability posture should be agreed upon to ensure continuity across teams; and
• infrastructure-as-code templates that include security architecture design and controls for cloud-based network access controls, identity policies and privilege assignments, cloud provider security services and other best practices for using CSPs.

3. Operational guardrails

Organizations should embed security-by-design principles in the operational guardrails that run in the CSP. Guardrails can range from secure cloud configuration settings -- for example, disabling the root identity for cloud accounts and subscriptions -- to the enablement of cloud monitoring and assessment services.

In AWS, for example, monitor for unusual behavior that may indicate security events or other issues with services such as Amazon Inspector, GuardDuty and Detective. These services help evaluate the environment and alert security professionals of issues when needed. AWS Resource Access Manager can also help proliferate and share secure configurations across accounts.

Enabling operational guardrails early in the development and design phases -- ideally, by the time threat modeling commences or completes -- can facilitate cloud deployments that not only have secure code and components, but also manifest and operate in a well-secured environment.