Management: Security Principle of the month

When we consume public cloud services, a significant part of our network, system, applications and data will move under 3rd party provider control. The cloud services delivery model will create islands of virtual perimeters, as well as a security model with responsibilities shared between us and the CSP. This shared responsibility model is bringing new security management challenges to the organisation’s IT operations staff. With that in mind, the first question Security must answer is whether we have adequate transparency from Cloud services to manage the governance (shared responsibilities) and implementation of security management processes (preventive and detective controls) to assure the Business that the data in the cloud is appropriately protected. The answer to this question has two parts: what security controls we must provide over and above the controls inherent in the cloud platform, and how enterprise’s security management tools and processes must adapt to manage security in Cloud. Both answers must be continually re-evaluated based on the sensitivity of the data and the service-level changes over time.

The guiding Principle is:

Environments, data and resources hosted on Cloud, must be maintained continuously and securely, via various management capabilities, increasing control over the hosting platform

Here are few high-level key points to help us maintain management, in the spirit of the Principle:

Patch management:

• Maintain a patch management process across all infrastructure, OS and Apps where available, utilising CSP native services (e.g. AWS SSM/Azure Update Management) or in-house/3rd parties tools

• For patches/updates pulled down from a public/shared network, ensure to have a Proxy/NAT GW in place to control egress and pull only from trusted/approved locations, subject to malware scanning

• If Compliance requires, validate with the CSP that a Firmware patching process is in place across hardware in-use

Bastion/Jump-box Hosts:

• Deploy across multiple physical and logical locations, to support immediate access, and include it within an auto-scaling policy

• Deploy in the public (DMZ) subnets of a VPC/Virtual Network (based on the use-case)

• Shut down the bastion/jump-box and start only when required

• Attach Static IP to Hosts, for maintaining trusted IP addresses, upon termination

• Access to Hosts should be locked-down only to known limited CIDR scopes for ingress, with ports limited to allow only the necessary access

• Consider skipping bastion hosts altogether by using native CSP services (e.g. AWS SSM ‘Session Manager’)

Immutable Infrastructure:

• Where possible, all changes must be made via the CI/CD pipeline, reducing likelihood of mis-configurations, insecure defaults and removing unknown resources from the environment . Note: The CI/CD pipeline itself must go under a separate security review before use

• "Shift Left” security, as possible, into developments and deployments pipelines. Keep security aware and involved as pipelines moves right

*The "Security Principle Of The Month" posts are a series of short articles aim to help and guide the security SME, whether it's a Consultant who is reviewing a solution design proposal, or a DevSecOps engineer deploying a solution, by listing key points of various security controls which should be considered for the proposed solution or to an existing product/environment. This list should be used as a 'complementary' list to any other security controls and strategies already in use within solutions.

**Sources:

- (ISC)² CCSP certification exam materials

- 'AWS Certified Security Speciality' certification exam materials

- 'Azure Security Technologies certification exam materials

- NCSC (National Cyber Security Centre); Cloud Security Principles

- Broad projects experience

- Online information