Clearing the Fog Around the Cloud and Cloud Security (Part 1)

Making Sense of Cloud Security

The more organizations move to the cloud, the wider the gap when it comes to cloud security. In this blog post series, we talk about the cloud, its security challenges, and practical steps you can take to handle it. Still, before we get into the down and dirty, we need to understand some of the terminologies out there.

Let’s start with the basic terminology and some history that explains how things got to where they are. 

First step- The development lifecycle or like it is also known as – SDLC

We all know how it works; The business has goals to reach (KPIs), so the product creates requirements for the R&D to develop the relevant features and then get the hardware resources from the operation/IT to provision what they developed.

Here is a quick recap to those too young to remember how we worked before everyone moved to the cloud. 

We used to have on-prem environments, and when the R&D wanted to deploy their code, they needed to ask the IT for resources. Basically, the IT was the gatekeeper of the security and the contact of the CISO in all the environment. All provisioning requests went straight to the IT person. It is a very clear pipeline.

We worked according to the waterfall methodology in the development process. It is called waterfall because just like the water flows downstream but never up, the development process moves down through all project phases (analysis, design, development, and testing, for example), with each stage completely wrapping up before the next step begins. 

The waterfall methodology reportedly started back in 1956! Back then, the waterfall approach builders decided to base it on manufacturing and construction processes. It might not sound reasonable to take strategies from those industries and implement them in software development. Still, in those days, computers were massive, and there was almost no other work similar to software development to copy, learn and implement on software development.

Waterfall Advantages and Disadvantages

There are some advantages to the waterfall approach. Let’s name them: 

1. It’s a straightforward approach to understand and apply. 
2. Easy to control. There is no need to juggle many balls in the air simultaneously because you don’t move to the next phase until you finish the current one. 
3.  No collusion between phases. 
4. Great for small, ad-hoc projects.

Ok, we’re now clear on that, so what are the disadvantages? 

1. When we get to the testing stage and find out that we need to make some adjustments and changes, we can’t. We have to keep going to the next phase. 
2. It takes a long time to deploy to production. 
3. Because it takes so long to deploy, the market might change, and we can’t even make changes along the way. 
4. It’s not a good fit for complex and object-oriented projects. 

That’s partially why most organizations don’t use this approach anymore. The other reason is the agile methodology. We’ll discuss a few lines down. 

Another thing that’s important to know is the RND used a monolithic architecture that is the traditional unified model for designing a software program – meaning, everything is in one place. 

The Agile Methodology

Over the 1990s, the agile methodology started to get more popular in the software development realm. The agile methodology approach stands for breaking a project into small pieces, moving from phase to phase faster, and releasing quicker. The keyword in agile is a collaboration between team members and other parties. All stakeholders need to be involved in each phase to confirm and reaffirm the result fits the business and user’s needs.

Agile brought us into a situation that:

1. Every development cycle is faster.
2. More stakeholders are involved in that cycle.
3. R&D needs to develop fast, and because they are using microservice architecture to reduce the dependency between the teams, teams can now develop in many different technologies.
4. Scale – more infrastructure, resources are needed from the IT/Operation team.

You’re probably asking yourself what changed in the security and how all that is related to the cloud.

Here’s the answer, because of the rapid changes in the organization SDLC, the R&D needed to provision environments to test and deploy in minutes. But, unfortunately, that caused a block from the IT team because the process of approval and buying new equipment for infrastructure takes a long time.

That brings the company to embrace the CI/CD Method, which frequently delivers products to customers by using automation in the stages of software development.CI/CD approach overpass the gaps between development and operation activities and teams by enforcing automation in building testing and deployment of applications.

That’s how the cloud got more attention, and more R&Ds decided to move to the cloud and start to consume more services from cloud providers.

Once the R&D advanced to being the lifecycle owner, new positions and roles started to emerge. It began with creating DevOps teams to help build the CI, and then the SRE was added to monitor the production environments. Then, FinOps optimized the cloud environments. Later the DevSecOps was added to help implement security policy from the development cycle and on all the CI/CD (which is almost impossible when there are many stakeholders and not one owner of the whole process…but we’ll discuss that in the next chapter).

One additional role that emerged is CloudOps. CloudOps is responsible for helping in the governance challenges and operation when it comes to handling the data flood in the cloud services and, last but not least, the CompOps that are in charge of the compliance regulations related to the cloud environments.

But not all organizations are on the same stage when it comes to managing the cloud. Not all of them can afford to build a cloud team with all the human resources to handle all the changes we talk about, and even if they do, it means more cooks in the kitchen. 

And that’s my friends, the reason we should all be worried about cloud security.

Let me ask you this: 

• How can the cloud be secure when there is no one owner of the cloud environments? 
• What happens now that the gatekeepers we used to have are no longer there? 
• Can we feel secure when most cloud tools out there don’t include all stakeholders? 

The good news, there are solutions. We’ll discuss them in the next blog post.