Still some years ago many security professionals considered the cloud as a mostly dangerous and risky environment better to be avoided. At the same time more and more organisations started to move workloads to the cloud.

This led to a mostly difficult situation: business and parts of IT rushed to the cloud without thinking of security and security tried to prevent this move or tried to secure the cloud with the same approaches that worked in the past.

This may work initially as long as move to the cloud mostly means a lift and shift of existing workloads. However the more the cloud native capabilities are being used by developers yesterday’s best practices for securing applications on static infrastructure are becoming anti-patterns. As security we need to adapt to the new paradigms or we will fight an uphill battle.

Main characteristics that change

If everythings‘s under control you‘re going too slow - Mario Andretti

Cloud-native environments are being built to increase in the speed at which teams and organisations operate. I see three main characteristics of a cloud-native environment that are impact traditional security:

• DevOps: “You build it you run it”
• Continuous delivery and deployment: Amazon is on record as making changes to production every 11.6 seconds on average already 10 years ago
• Microservices, Containers and agile scaling: “Pet vs. cattle”

Traditional security approaches become anti-patterns

In an environment that operates using these paradigms typical standard security patterns become anti-patterns:

1. Careful security planning: This typically includes activities that fit well into a waterfall model:
   • Early in the lifecycle we look at the design and derive a threat model.
   • We vet and control an approved set of frameworks/AppServer/OS that can be used.
   • At stage gated lifecycle requires security approval and hand-over between the stages.
2. Segregation of duties: We want to prevent error and fraud.
   • Hence we implement a „4 eyes principle for important changes“.
   • We may even want to have different teams with strict hand-over.
3. Strict change management that tightly controls what gets into production and does so only after thorough checks. A strict change advisory board (CAB) provides visibility:
   • Carefully planned release cycles.
   • Evaluate security impact of each change.
   • Regular code reviews and pentesting exercises.
4. Securing the environment largely relies on network controls:
   • We want to know exactly which servers with specific IP addresses are allowed to talk to other servers
   • We need to know which applications run on which servers.

How to adapt our security strategy

“You cannot be a blocker—your job is not to say no to innovation. Security needs to be everyone’s job.” —Henrik Johansson

Adapting this way of working to the new reality poses a nummer of challenges and opportunities:

• we need to rethink our processes and approaches
• we need to seek how to achieve the desired outcome integrated into the new ways of building and running software
• we can increase security and better fight the current security threats.

The focus mostly on infrastructure and involvement “late in the game” needs to change. I’m convinced we will only succeed if we move left and up:

This means every security professional needs to understand at least basics of programming and current application development strategies. This is key to being able to talk to the developers and being part of the team.

Secondly we need to take advantage of the new approaches and integrate security into continuous delivery to test security features and check for vulnerabilities before deployment as well as improve the audit trail of changes to the production. This can also dramatically reduce the configuration drift of systems which makes investigations much easier.

Finally we need to invest in “fluid” security controls that scale automatically.

This involves to investigate how we can

• Stop patching, start replacing
• Let security devices scale similar to other parts of the environment
• Microsegmentation and “East-West” firewalls as part of the infrastructure
• Tap into existing performance monitoring

Of course all of this doesn’t mean that we need to forget everything we learned and use

• Identity management in fact becomes even more important
• Data security including encryption at rest and in transit
• Thorough logging

A while ago I had the privilege to present my thoughts around this at the ISC2 Security Summit. You can find here a video of my talk and also the slides I used.