Cloud, Security, Shared Responsibility and 8 Principles

One of the fundamental principles of the cloud is that security is shared between cloud providers and 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 and infrastructure management.

In on-premise it is a little different, where the user is responsible for everything:

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

So while the 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 appears at the top of the table, such as the State of the Cloud Report 2022:

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

Let's come to terms with the new principles of IT architecture.
Let's address areas of security that we didn't have to deal with on-premises.
Let's define our approach to security in the cloud.
Let's integrate cloud security and on-premises.
Let's take advantage of the plethora of cloud-based security tools.
Let's manage security with predefined policies and configurations.
Let's improve security through automation, blueprints and a risk base approach.
Let's reach security nirvana or continuous cloud compliance.

1. Let's get to grips with the new principles of IT architecture

Why is security a significantly bigger topic 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 basic differences are in the following seven areas:

Area	On-premise	Cloud
Perimeter	IT lies within the perimeter, which is its line of defense.	The perimeter has ceased to exist or exists in multiple dimensions.
End User devices	Everything within the perimeter is secure, access from the outside is secured.	Security depends on the type of device, location, user, and role.
Automation	They are rarely available.	It is a natively supported functionality.
Security Governance	Full Liability (E2E) Inside the Perimeter	Shared responsibility by type of service (IaaS, PaaS, SaaS)
Principles of safety	Static Sources and Statistical Safety Rules	Dynamic Sources 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 API.
Business Continuity (BC)	BC plans are individual by application and infrastructure.	BC plans can be aligned according to the platform's capabilities and limits.

In on-premises architecture, we need to consider only some of the above areas. However, if we want to use the cloud, we need to take all seven areas into account in terms of architecture, security and related processes.

Let's address areas of security that we didn't have to deal with on-premises

Due to shared responsibility in the cloud, we need to refocus on the following areas of security and governance:

How do the terms and conditions guarantee security?
Where is the data located and what is its classification?
How can I leave the provider?
How does the security provider manage?
Do the provider's employees have access to my data and how am I informed about this?
How does the provider audit the security management and what is the access to this information?

We will talk more about these topics in one of the next articles dedicated to cloud compliance.

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

There is a basic premise for security in both on-premises and in the cloud: It's our environment and we must take care of its security. This premise must be set in stone in both environments, but it is doubly true in the cloud due to shared responsibility.

4. Let's integrate cloud security and on-premises

The cloud brings technical issues to security that need to be addressed so that on-premises and cloud environments can coexist.

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

5. Take advantage of a plethora of cloud-based 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 into cloud platforms and ready for immediate use.

Examples of tools in AWS and Azure:

AWS Security Hub – a security hub in the Amazon Web Service environment that integrates various security services and solutions, provides a central view of all security policy compliance, and allows you to automatically respond to specific security incidents.
AWS Config – part of AWS Security Hub, however, it can be used separately regardless of 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 implementing Azure Policy is its cost – it's completely free.
Defender for Cloud – a tool not only for Azure environments (it can also integrate AWS and GCP), which enables: a) continuous e.g. Microsoft Sentinel).

6. Let's manage security in the cloud with policies and configurations

Another key benefit of the cloud is security management with predefined policies and configurations that both AWS and Azure providers offer for free and can be used immediately. There are more than hundreds of pre-built rules such as:

Is the web application firewall on my load balancer enabled?
Is my database backed up?
Are my drives encrypted?
Is public access to my Kubernetes cluster disabled?

There are also pre-prepared security policies and views for various standards, such as:

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 modify predefined ones.

The tools, along with out-of-the-box configurations and policies, support the three basic principles of security in the cloud:

A) continuously assess – continuously check your security settings,

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

C) defend – detect and solve security threats.

7. Let's improve security in the cloud with automation, blueprints, and a risk-base approach

Another key benefit of the cloud is the use of automation and blueprints, i.e. an infrastructure configuration standard in the form of Infrastructure as a Code (IaaS). Together with cloud automation, they build well on automating application deployments with a 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 of security parameters (e.g. vulnerability scan, penetration tests, OS hardening, data location, data encryption, etc.) and rules for when these parameters should be applied.

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

Class	Application type	Precautions
L0	For everyone – 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	Testing & Acceptance Environments Development Environments with Sensitive Data	SIEM monitoring 1 year, vunerability scan, data masking, pentest
L3	Production environment without sensitive data	Encrypt data with an AWS key
L4	Production environment with highly sensitive data	AWS CloudHSM Data Encryption

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

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

In the event of a non-compliance, the DevOps or security team is automatically notified according to the type of policy violated – see the following picture:

The implementation of continuous cloud compliance is based on the following areas:

Existence of security tools in the cloud
Existence of security configurations and policies
Ability to automate everything in the cloud with blueprints
Ability to define your own catalogue of security parameters using a risk-based approach

… supplemented by processes:

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

Security in the cloud in conclusion

When moving to the cloud, it is important to put emphasis on Cyber Security & Defense in the cloud strategy and roadmap.

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

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

How do you see it?