8 principles to ensure cloud security or a different perspective on cloud security than you expect

Cloud, Security, Shared Responsibility and 8 Principles  

One of the fundamental features of the cloud is that security is shared between cloud providers and cloud users. The provider is responsible for the security of the cloud platform itself. The user is responsible for the security of their data and, depending on the type of cloud, shares responsibility with the cloud provider for endpoint devices, identity, applications and network management and infrastructure.  

In on-premise it is different, there the user is responsible for everything (as shown in the following image from cisecurity.org): 

While innovation and the availability of exciting technologies are the main motivations for moving to the cloud, we associate cloud security with fear of the unknown and caution about entering the cloud.

So while general concerns about the cloud are long gone, cloud security is still a big topic. This is evidenced by cloud surveys in which cloud security regularly comes out on top, for example in State of the Cloud Report 2022:

Sharing responsibility has brought with it 8 safety principles for the journey to the cloud, which we'll discuss in detail:

1. Let's deal with the new principles of IT architecture.
2. Let's address areas of security that we didn't have to address in on-premise.
3. Let's define our approach to security in the cloud.
4. Integrate cloud and on-premise security.
5. Let's take advantage of the plethora of cloud-based security tools.
6. Let's manage security with predefined policies and configurations.
7. Let's improve security through automation, blueprints and a risk base approach.
8. Let's achieve security nirvana or continuous cloud compliance.

1. Coping with new IT architecture principles

Why is security a significantly bigger issue in the cloud than on-premise? With the existence of the cloud, many IT principles have changed, and with it, the approach to security. The fundamental differences are in the following seven areas:

Area	On-premise	Cloud
Perimeter	IT lies inside the perimeter, which is its line of defense.	The perimeter has ceased to exist or exists in multiple dimensions.
End devices	Everything within the perimeter is secure, access from the outside is secured.	Security depends on the type of device, the location, the user and the role of the user.
Automation	They are rarely available.	It is a natively supported functionality.
Governance of security	Full liability (E2E) inside the perimeter	Shared responsibility by service type (IaaS, PaaS, SaaS)
Principles of safety	Static sources and statistical safety rules	Dynamic resources and dynamic security rules
Security tools	Each technology is separately integrated into the security model and monitored.	Security features are natively integrated into the cloud platform's security model, monitoring and APIs.
Business Continuity (BC)	BC plans are individual according to applications and infrastructure.	BC plans can be aligned to the capabilities and limits of the platform.

In on-premise architecture, we only need to consider some of the above areas. But if we want to use the cloud, we need to consider all seven areas in the architecture, security and related processes.

2. Let's address areas of security that we didn't need to address in on-premise

Because of the shared responsibility in the cloud, we have to address these areas of security and its governance in a new way:

• How do the terms and conditions guarantee safety?
• Where is the data located and what is its classification?
• How can I leave the provider?
• In what way does he manage to provide security?
• Do the provider's staff have access to my data and how am I informed?
• How does the provider audit security management and how is this information accessed?

We will talk more about these topics in a future article Cloud Encyclopedia dedicated to cloud compliance.

3. Let's define our approach to security in the cloud

For security in on-premise and in the cloud, the basic premise applies: It's our environment and we need to make sure it's safe. This premise needs to be set in stone in both environments, but it is doubly true in the cloud because of the shared responsibility.

4. Integrate cloud and on-premise security

The cloud brings technical issues to security that need to be addressed for on-premise and cloud environments to coexist.

Area	Cloud
Conditional access	Control access to applications and IT services based on the type and status of the device, the location and role of the user or application, and real-time risk determination (based on Zero Trust principles)
Hybrid Cloud Identity	A functioning hybrid identity is a prerequisite for the ability to manage users and corporate data anywhere on the corporate network and in the cloud.
Classification of information	Data and document protection through classification, including security by technical means (e.g. encryption)
Adaptive Security	Change the approach from static rules to a continuous dynamic style. Normal behaviour is safe and unusual behaviour is dangerous.
Cloud integration into on-premise	Landing zone of the cloud must be connected with on-premise at the level of networks, operational and security monitoring, identities.

5. Take advantage of the plethora of cloud security tools

If we successfully master the previous four areas, we can reap the benefits of the cloud. The first is that cloud providers offer us a plethora of security tools and technologies that are integrated and ready to use in cloud platforms.

Examples of tools in AWS and Azure:

• AWS Security Hub - security centre in the Amazon Web Service environment, which integrates disparate security services and solutions, provides a central view of all security policy compliance, and enables automatic response to specific security incidents.
• AWS Config - part of the AWS Security Hub, however, it can be used independently of the Security Hub. AWS Config maintains the current state and configuration of all components and allows you to create individual rules to control them.
• Azure Policy - a tool for defining security policies and validating (non-)compliance of individual resources with these policies. A huge advantage of Azure Policy implementation is its price - it is completely free.
• Defender for Cloud - tool not only for Azure environment (it can integrate AWS and GCP as well), which enables: a) continuous e.g. Microsoft Sentinel).

6. Manage security in the cloud with policies and configurations

Another key benefit of the cloud is security management through predefined policies and configurations, which both AWS and Azure providers offer for free and can be used immediately. There are more than hundreds of pre-made policies like:

• Is the web application firewall enabled on my loadbalancer?
• Is my database backed up?
• Are my disks encrypted?
• Is public access to my Kubernetes cluster disabled?

There are also pre-prepared security policies and views for different standards, for example:

• ISO 27000:2013
• Center for Internet Security benchmark (CIS)
• NIST Framework
• Payment Card Industry Data Security Standard (PCIDSS)

and more, including the ability to create your own security policies or edit predefined ones.

The tools, along with pre-built configurations and policies, support the three core principles of cloud security:

(A) continuously assess - keep checking your security settings,

B) secure - improve the security settings of cloud resources and services,

C) defend - Detect and resolve security threats.

7. Improve security in the cloud with automation, blueprints and risk base approach

Another key benefit of the cloud is the use of automation and blueprints, an infrastructure configuration standard in the form of IaaC (Infrastructure as a Code). Together, cloud automation ties in well with application deployment automation by CI/CD pipeline and help innovate, accelerate and streamline IT. DevOps is becoming an IT reality.

Blueprint templates for repeatable deployment of application, infrastructure and security configurations. It is important to have a defined set Security parameters (for example vulnerabilit scan, penetration tests, OS hardening, data location, data encryption, etc.) and rules for when the parameters should be applied.

It is good practice to use a catalogue of safety parameters risk based approach, i.e. define risk classes for applications in the cloud and assign security measures to them. The result can be, for example, five classes of applications, where the higher class extends the parameters of the lower class.

Class	Application type	Security measures
L0	For all - the bare minimum	OS hardening, hardening of application servers, audit log to a separate security account
L1	For development environments without sensitive data	SIEM monitoring 2 months
L2	Test and acceptance environments Development environments with sensitive data	SIEM monitoring 1 year, vunerability scan, data masking, pentest
L3	Production environment without sensitive data	data encryption with AWS key
L4	Production environment with highly sensitive data	AWS CloudHSM data encryption

8. Let's reach security nirvana or continuous cloud compliance

The last key benefit of the cloud is continuous cloud compliance (discussed in a separate EC article). This principle allows to manage cloud application environments and to monitor the fulfillment of security and operational policies not only at the time of environment creation, but continuously throughout the entire application operation.

In case of a non-compliance status, the operations or security team is automatically notified according to the type of violated policy - see the following figure:

The following areas are the basis for implementing continuous cloud compliance:

• existence of security tools in the cloud
• the existence of security configurations and policies
• ability to automate everything in the cloud using blueprints
• the ability to define your own catalogue of security parameters using a risk base approach

...complete with processes:

• continuous data collection (which sources or their parameters must be continuously monitored),
• data evaluation (defining individual policies assessing compliance or non-compliance),
• reactions (how to respond to policy inconsistencies).

Security in the cloud in conclusion

When going to the cloud, it is important to process the topic cyber security & defence in the cloud strategy and roadmap. The first four of the eight principles described in this article are hygienic and therefore need to be addressed right at the beginning of the cloud journey - at a time when on the cloud maturity scale you are on level 2 or 3.

The remaining four principles will bring you real benefits when using the cloud only after the previous four principles have been fulfilled. We are able to reap their benefits after reaching higher cloud maturity (approximately level 3-4).

Let's go back to the initial questions: is shared responsibility for security in the cloud a risk or a benefit? Can initial concerns be replaced by enthusiasm?

It is only a risk if we do not take shared responsibility into account and implement the first four principles correctly. Otherwise benefits and enthusiasm prevailas we will be able to take full advantage of principles 5-8.

How do you see it?