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.

Giulio Faini