Cloud security models to the rescue!
How to use this simple and easy cloud cybersecurity model — CyberForged
How a reference architecture helps your systems be more secure
Good morning everyone! Today on CyberForged we are going to look at a cloud cybersecurity model that is extremely simple and, although it is a bit generalist, it actually covers all the architectures recommended by the Cloud Security Alliance (CSA). But before we talk about the model itself….What is a model? What is a framework? Who am I? We’ll look at all of this next.
Cybersecurity models, frameworks, and guides
Well, the first thing we need to know is what we mean when we talk about a “cloud cybersecurity model”. This concept, along with that of reference architecture, can be likened to an artist’s mold: When a sculptor wants to make 200 arms of 200 statues, it is unlikely that he will go one by one sculpting and shaping them. Most likely, in order to make these 200 statues of the same quality, he will end up making a mold of arms so that, when filling it, the result will always be the same: slender, perfect arms, of the same length and quality.
Well, if we take this same simile to the world of cybersecurity, we have what is a model or reference architecture: they are guides that include aids so that when it comes to making migrations or modifications to our cloud systems, cybersecurity always remains the same.
In fact, according to the Cloud Security Alliance itself:
Reference architectures are templates for implementing cloud security, typically generalized (e.g. an IaaS security reference architecture). They can be very abstract, bordering on conceptual, or quite detailed, down to specific controls and functions.
As you can see, in our explanation we can interchange “cloud cybersecurity model” with the term “cloud reference architecture”, and in fact, the CSA itself points out that there are many terms such as conceptual model or design patterns that are used indiscriminately to express the same idea:
The lines between these models often blur and overlap, depending on the goals of the developer of the model. Even lumping these all together under the heading “model” is probably inaccurate, but since we see the terms used so interchangeably across different sources, it makes sense to group them.
Basically, we can take a cloud cybersecurity reference model or architecture as all those guidelines that tell us how to work or how to do a certain task so that the result is always secure and we can certify that the security of the system before and after the change is still acceptable.
As examples of these reference architectures approved by the CSA and publicly accessible, we have:
The simple and easy cloud cybersecurity model
Now that we know what a reference architecture or conceptual model as such is, we can go on to explain the different steps that make up the generic model for managing cloud cybersecurity:
We will explain them step by step
1. Identify requirements
The first thing we must always do, in any system of any kind, is to gather and identify the requirements. That is, we have to know what and why we are going to do what we are going to do.
Once the system requirements have been defined, we can include the security and compliance requirements. That is, let’s imagine that we have a system that allows users to be able to log into a web page to be able to buy products from our systems. The functional requirement would be that a user must be able to log into the application and obtain access tokens. The cybersecurity requirements would be derived from this based on the operation of the system: the user must use a password of at least 8 characters, the user must not be able to see the login information of other users…..
The result of this phase would be a list of functional and non-functional (cybersecurity) requirements, leaving the system fully characterized.
2. Select provider, service, and deployment models
Once we know what we want to do and the security requirements that this system brings with it, we must select a provider, a service model, and a deployment model. These concepts we have already seen in the previous article, which you can visit here.
Following the example of our login system, at the end of this phase, we would have made the decision that we are going to use a service provider that gives us the code libraries already made, which provides a SaaS service in a public cloud.
3. Define architecture
So, we already know what we want to do, the security requirements and we have a provider/service model/deployment model that fits the system. Now we need to know the architecture we have in hand.
What ports do the provider’s systems use, do they need a connection to our on-premise systems, do we need a fault-tolerant system so that under no circumstances will any user be left without service?
At the end of this phase, we will have the technical designs of the architectures involved in the new login system.
4. Asses security controls
This phase is easy, we only have to answer one question: Are the security controls we currently have in place able to withstand the load/functionality that this new system brings? If the answer is no, we should go to step 5, if not, we can go directly to step 7.
5. Identify control gaps
Well, let’s imagine that for our login system we need a level 7 firewall (WAF) so that it can protect us from attacks such as XSS or SQLi. We analyzed in the previous step our current cloud security systems and it turns out that our firewall is only level 3 (network) so it would not work for us. We just identified a gap within our systems.
Each of these gaps will be analyzed to ensure that nothing in the new system goes unnoticed.
6. Design and implement controls
Once we have all the gaps in our current system, we must design and implement the new controls. If we need a new WAF, the Azure Application Gateway can bring one with it in its WAF version.
This is why it is very important to have the entire system architecture and cloud provider selection before looking at and implementing the new security controls. Each of the cloud providers will have its own native controls and its own supports.
7. Manage changes
Once we have the new login system implemented and installed, we must always be aware of any changes (both at the development and infrastructure level) to be able to manage it again following this process.
If we follow this simple process, without skipping steps, we can say that cybersecurity in our cloud systems is assured. Of course, it is important to say that these steps can take time so it is always best to include cybersecurity teams from the beginning of the developments.
What did you think, do you have any questions? Let me know in the comments!
Originally published at https://cyberforged.com on April 15, 2021.