Incloud security responsibility is shared. Is it a risk or a benefit? There may be initial concerns replaced by enthusiasm about how secure and useful the cloud can be? In this article, I’ll give you my take on the topic of cloudsecurity and describe eight security principles to follow when going to the cloud.
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 and infrastructure management..
In on-premise it is different, where 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 have historically associated 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 that regularly rank cloud security at the top, such as the State of the Cloud Report2022:
Sharing responsibility has brought with it 8 security principles for the journey to the cloud, which we will discuss in detail:
- Let’s deal with the new principles of IT architecture.
- Let’s address areas of security that we didn’t need to address in on-premise.
- Let’s define our approach to security in the cloud.
- Integrate cloud and on-premise security.
- Let’s take advantage of the plethora of cloud-based security tools.
- Manage security with predefined policies and configurations.
- Let’s improve security through automation, blueprints and a risk base approach.
- Let’s achieve security nirvana or continuous cloud compliance.
1. Coping with new IT architecture principles
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 so has the approach to security. The basic differences are in the following seven areas:
|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 their role.|
|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 need 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?
- How 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’ll talk more about these topics in a future Cloud Encyclopedia article on cloud compliance.
3. Let’s define our approach to security in the cloud
For both on-premise and cloud security, the basic premise applies: it’s our environment and we need to take care of its security.This premise needs to be set in stone in both environments, but it’s 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 in order for on-premise and cloud environments to coexist.
|Conditional access||Control access to applications and IT services based on device type and status, user or application location and role, 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 safety||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 – a security hub in the Amazon Web Service environment that 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 AWS Security Hub, however it can be used independently 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 price – it’s completely free.
- Defender for Cloud – a tool not only for Azure environment (it can also integrate AWS and GCP), 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 rules 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?
Existují i předpřipravené bezpečnostní politiky a pohledy pro různé standardy, například:
- 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 – continuously check 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 using the CI/CD pipeline to 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 placement, data encryption, etc.) and the rules for when the parameters should be applied.
A good practice for building 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. The result can be, for example, five classes of applications, where the higher class extends the parameters of the lower class.
|Class||Type of Application||Security measures|
|L0||For all – the bare minimum||OS hardening, application server hardening, 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. Achieving 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 makes it possible to manage cloud application environments and monitor compliance with security and operational policies not only at the time of environment creation, but continuously throughout the application’s lifetime.
In case of 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).
Cloud security in conclusion
When moving to the cloud, it is important to address cyber security & defence in your cloud strategy and roadmap. The first four of the eight principles described in this article are hygiene principles, and therefore need to be addressed early in the cloud journey – when you are at level 2 or 3 on the cloud maturity scale.
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 take advantage of them after reaching higher cloud matriculation (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 fears 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 will prevail as we will be able to take full advantage of principles 5-8.
How do you see it?
This is a machine translation. Please excuse any possible errors.