“Security and Cloud, What Is the Right Recipe?” The Technologies

“Security and Cloud, What Is the Right Recipe?” The Technologies

In the last but certainly not least in our cloud security series, we’ll be covering technologies. Under this umbrella, we cover both the security requirements and the cloud-native (or third-party) technologies that are needed to implement a “secure-to-be” public cloud.

In literature, there are plenty of ready-to-be-used security frameworks that give great insight into what is required to create a cloud security architecture. CIS Controls or the NIST 800-53 publications are good examples, but also ISO 27002 is quite a useful document to draw security requirements. In our field experience, these 12 domains below of security controls are a good starting-point to cover most needs:

  1. Inventory
  2. Authentication
  3. Authorization
  4. CI/CD Pipeline
  5. Access Control
  6. Audit & Monitoring
  7. Confidentiality
  8. Key Management Solution (KMS)
  9. Run-time Security
  10. Data protection (Compliance)
  11. Incident and Response (I&R)
  12. Security Operation Center (SOC)

It’s beyond the scope of this article to go through such domains in detail and analyze all requirements, which would be anyway pointless because they vary from company to company.  Still, it is interesting here to have a more general overview of the security technology trends that are popular in public clouds.

First, it is important to be aware that leading public cloud providers tend to offer not only managed security services (to provide automated data at rest) but also fully-managed developing suits (like Kubernetes-aaS), where security patching/scanning of the underlying operating systems are completely taken in charge by themselves. All these managed services are of great help to companies, especially the ones that have a small IT department that need to focus on other project deliverables given by the business.

Some would say that traditional security tools from legacy environments could still be used and lift & shifted into the cloud, but in reality, they do not fit well with cloud-native apps designed for the public cloud because they are built with completely different design criteria like depicted in the table below:

Cloud native security tools are not so sophisticated like legacy security tools, which have been developed and improved over the last 20 years. This is by-design because cloud-native means that each security feature is broken down in atomic and decentralized tools.

The golden security rule of “defense-in-depth” ensures that protection is still as efficient as before by extending it to the full-stack of ISO layers. For example, a deep packet inspection (DPI) next-generation firewall may be replaced by traditional layer-4 security groups together with distributed endpoint threat management solutions and together with anomaly detection loggings, etc. It’s not a replacement, but the result of these measures can be the same or even better because there isn’t a bottleneck do-it-all product that pretends to secure all IT environments by itself.

Each security tool used in the cloud is important, but the real added value comes from their cross-layer integration via common APIs and the capability to automate their action based on common attack scenarios reproducible in pre-tested security playbooks. Like we discussed in the Processes section where it was the whole team, and not a single security officer, to assume the security responsibility in an organization. Here it is not a single product that will save your data from being stolen, but rather a collection of security products tightly integrated and automated.

This ends our series on Public Cloud Security, where we introduced and focused on key security challenges and pitfalls that arise when a company gets involved in resourceful and time-consuming projects to drive the refactoring and re-platforming of critical Business workloads.

“Security and Cloud, What Is the Right Recipe?” The Processes

“Security and Cloud, What Is the Right Recipe?” The Processes

In the first part of our series, we discussed the myths that arise in organizations by having different groups of people with different perspectives on cloud risks. In part two, we’ll be tackling the Processes.

Not without reason, security has been synonymous with either saying no or missing project deadlines. Therefore, during key app-refactoring projects, security must adopt new processes and find the right balance between the compliance needs of security and the business needs of agile sprints.

An Automation Mindset

First, it is imperative for security to embrace automation and put as many security controls as possible directly into the pipelines. Automated security tools (that are accessible via APIs) can provide many security measures like compliance checks, static and dynamic security checks (SAST or DAST), vulnerability scannings, and more. Although they are prone to false positives, they act as the first line of defense.

Secondly, security officers need to be an integral part of the DevOps community by participating, to the extent of their capabilities, in the coding process and in the creation of “Hacker/Abuse stories” (potential hacker scenario simulations.) This way, they have the opportunity to be listened to by the rest of the team and considered as a cooperative resource inside the organization.

Finally, infrastructure changes (also known as merged-requests) are first validated under the 4-eyes principles and then by automatic compliance checks are defined and run in a production (e.g. check that a file bucket is not publicly accessible) that would alert the support department immediately in case of a failed compliance.

The other takeaway implicit in all the 3 points above is that there is a shift in responsibilities from a single person overseeing security to the whole DevOps team, which ultimately really becomes a DevSecOps team at the moment that is in charge of the security stream collectively.

Rapid Risk Assessment

We all know that security ultimately comes down to risks. Without considering corner cases where the risk assessment procedure has become just “ticking a checkbox.” Quite frankly companies these days do not treat risks properly. This is due to several factors, some being that security teams are always understaffed, overwhelmed or simply missing the necessary technical depth/breadth for these projects. In fact, in these circumstances, sometimes it’s easier to run an external pentest or risk assessment, effectively delegating responsibilities outside of the organization, which could have risk implications in and of it themselves.

Instead, it is more advisable to create an even tighter connection between security and DevOps processes by integrating risk assessments inside pipeline processes. In literature and in the field, there are more and more examples of Agile Risk Assessments (see for example the RRA-project in Mozilla), where single DevOps stories are created for each risk after a short assessment (max 30/45 mins) made by two to three people from technical and business backgrounds.

This way not only is there collective ownership of risks by all members of the team but most importantly, visibility and transparency of risks are finally achieved throughout the whole lifecycle of the project (which wasn’t necessarily the case before.)

Even if all the processes described above were done by-the-book, this might still not be enough if security lacks proper management support: as discussed previously, security is indeed dug in tight into DevOps and Business processes, but it must also have a direct link and sponsorship at the Cx level throughout the whole project to highlight potential risks to the board.

Furthermore, security should be greatly incentivized with bonuses and rewards by management to prioritize, for example, critical bug fixes against other Business/App processes. This will increase the spirit from the engineering teams towards security because it’s not a mystery that security is mostly conceived by many departments as a mere extra burden that sits on top of what they already need to do. This way engineers won’t see security solely as a checkbox-tasks dictated from above, but as a real added value to the organization for protecting core assets, businesses and, ultimately, reputation.

This second article focused on a fundamental aspect of public cloud security: processes. It is in these processes where we see the incubation of many breakthrough ideas that – once established – will totally reshape the concept of the current security landscape and potentially lead the way for the DevOps community to transform other IT and business functions of organizations.

In the third and final article, after introducing the key requirements to make the public cloud secure, we will see how the landscape of security tools has changed to adhere to the new cloud-native design principles. Stay tuned for Technology.

Security and Cloud, What is the Right Recipe? The People

Security and Cloud, What is the Right Recipe? The People

In this three-part blog series on public cloud security, Kudelski Security’s Cybersecurity Architect Giulio Faini, covers the trinity of People, Process and Technology that comprise all good transformation recipes.

Infrastructure-as-a-Service (IaaS) and Platform-as-a-Service (PaaS) are on the radar of every CISO. Not only are they the public cloud services with the fastest growth projected over the next few years, but they’re arguably the best-suited cloud migration approaches for major digital transformations.

Classic security practices designed for on-prem deployments are ill-adapted to apply to the specificity of cloud native services and thus require a deep rethink. Generally speaking, we all agree that security is about three main components, all of which are equally important: People, Processes, and Technology.

Having been a techie for many years, I would be tempted to jump straight to Technology, hoping that the other two would follow consequentially. But the reality is that the People/Human factor plays a vital role for the success of these kinds of projects, and so my article series will begin with this and common misconceptions that need to be addressed in order to move forward with digital transformation.

People – Change your Mindset; Address the Myths

A radical change of mindset is in fact required from all stakeholders in the organization but foremost, from the security staff that usually keeps working across old legacy projects as well as new cloud-specific designs.

The main actors playing a role in cloud security streams (CISO and security officers, DevOps teams, security and system architects, legal and compliance teams, Cx Levels) need to agree on how best to debunk myths based on widely held beliefs about cloud, like the ones listed below this is important: failure to separate fact from fiction will impede innovation and lead to endless delays in your digital transformation.

  • Myth #1: Visibility is Lost in the Cloud – There is a common belief among customers, that they will lose sight of their precious data/resources.In reality, public cloud resolves this issue for good. In the public cloud space, even turned-off devices are listed in automatic inventory tools, so there is no more risk in having unknown devices hanging around the domain controller like it was happening on-prem. Every major cloud vendor has an automatic and freeware inventory tool to ease this task.But what about data visibility from the geopolitical point of view? Assuming you trust your vendor (at least as much you have trusted your computer manufacturer so far), then the legal department needs to do its due diligence in signing off contracts, preferably assisted by security teams, to clarify all technical issues.

    Finally, for the most conscious minds, cryptography is your friend and can keep your data safe maybe with private keys stored on your premises. If cryptography has been used in the past for e-commerce use-cases, then it can be reused for protecting cloud data when it is located elsewhere.

  • Myth #2: No Perimeter Means Weak Security – Legacy-minded people feel reassured when their data is behind a locked door. They’ll try to transfer the perimeter onto the public cloud. But in reality, perimeter security is a red herring: we know that there is more than one entry point into a network and internal attacks pose more of a threat because they can go undetected for a long time.Public cloud approaches the security challenge with the concept of Zero-Trust Architecture: Rely on strong authentication (MFA), short-lived, least privileged credentials and cryptography (which goes just about everywhere).
  • Myth #3: Cloud Impacts Availability – There is a widely held belief that Availability would be more complex in Public Cloud because there is an additional dependency on somebody else (i.e. Cloud provider).In practice, this situation can be mitigated by adopting Infrastructure-as-a-Code (IaaC), which makes easier to mirror cloud workloads to DRP locations, which is not often the case for legacy DCs.But what if the public cloud service provider itself fails? It’s not a problem if you choose a multi-cloud strategy from the start of the project. As developers are already aware, the Container Revolution has already started in the IT industry. Critical apps are packaged in wrappers (i.e. containers) that include all the required logic for the app to run autonomously. Containers, standardized by the Cloud Native Computing Foundation (CNCF), can thus easily (i.e. without any modification) be transposed to other public cloud providers.  As a result, the availability risk is addressed. Plus, as a bonus, the security requirement itself can also drive savings by allowing you to choose the vendor you want and avoid vendor lock-in.
  • Myth #4: It’s Got to Be Perfect Before We Migrate – Legacy-minded people often believe a high-level of security assurance is needed before the program can progress.
    To avoid perpetual delays in cloud migration go-live dates, all stakeholders should agree on a baseline security architecture that covers MVP (minimum viable product) requirements. It goes without saying that security is, and always will be, improved constantly over time. But with at least a minimum level of security (e.g. limiting the project initially to a private-facing environment) it’s possible to allow business to start using the cloud infrastructure for their projects.

To conclude, in this first article about public cloud security, we have looked at some common myths that still persist in 2019, especially in the initial phases of cloud migration projects.

Clarify facts with your team as soon as possible to avoid project failure. With some corner cases, get help from a trusted external advisor who can help untie knots and facilitate progress without never-ending discussions.

In Giulio’s next article, he will explain how DevOps movements, which are at the heart of most public cloud migration projects, have deeply changed security processes and unpack the risks for organizations who don’t follow these new IT trends.