Cloud Security and the Modern CISO: How to Move from Blocker to Enabler
The revolution of the public cloud has irrevocably changed the role of the CISO in the modern enterprise.
The cloud is the biggest enabler in a generation and is a massive opportunity for enterprises to start innovating at speed and scale. But only if they bring their security with them on the journey!
But the pace of change in the new world can feel unsettling, so it is not uncommon for CISOs and security teams to want to stick to older models and to double down on familiar ways of working.
What happens when old world thinking and behaviours are applied to the new world?
We often see disappointing and frustrating outcomes! The CISO and the security function becomes a blocker to the agility and innovation of the public cloud, rather than an enabler.
In this blog, I will discuss the key differences between the old world of security and the new world of cloud security and how CISOs can move from being a blocker to an enabler so they can take advantage of the public cloud!
The CISO as ‘Blocker’
I remember having a standoff with an IT Security Manager who told me the security requirements for a solution I was designing were on a “need to know basis!”
Does this sound familiar? Do your engineering teams see the CISO and the security team as a blocker? Over the years I have heard IT security referred to as the Department of NO.
There are two main reasons for this:
- The Ivory Tower Effect: IT security has traditionally been a specialised area, well paid, lots of power and operating under a veil of mystery as to what is allowed and what is not.
- Security as Siloed Afterthought: traditional IT development has held security at arm’s length, an external body that needs to approve designs and sign off for production readiness at the end of the development lifecycle.
It certainly is not a good place to be as it will stifle innovation and change: two of the greatest benefits the public cloud can bring to an organisation.
The introduction of public cloud has brought about not only a big technological shift but also a cultural one with the adoption of modern development techniques that make these old security postures and attitudes untenable. I’ll explore some of these key differences before exploring the ramifications for the CISO.
Cloud Security versus On-Premises Security: The Key Differences
The cloud fundamentally changes both the playing field and the rules of the game when it comes to security. Not only technologically but also culturally.
Responsibility: end-to-end versus shared responsibility
The Public Cloud has a shared risk and responsibility model between the customer and the CSP on a sliding scale depending on the type of service being used. There is a good description here Shared responsibility in the cloud - Microsoft Azure.
Boundaries: static resources, perimeter-based security boundaries versus dynamic resources, ephemeral security boundaries
In the public cloud, all of the resources you use are dynamically allocated and deallocated and scaled up and down automatically on demand to meet your needs. Environments can be deployed and destroyed for each release to prove the application and build work cohesively together. The majority of services are ephemeral and do not store state or persistent data to support this elasticity. Even data stores can be rebuilt and refreshed with a few lines of code. The security boundary changes to meet this elasticity with different controls needed as I describe below.
Automation: difficult to automate versus built for automation
The public cloud has been designed to be automated through code and CI/CD pipelines. Every action taken to build, configure and destroy services in the public cloud is executed through an API call meaning that services can be automatically spun up or down at the push of a button.
On-premises systems require physical access for the hardware and often console access to configure them making them harder to automate.
Security added on versus shifting security left
On-premises security is often configured and applied as additional controls and tools that are only tested and configured when solutions are about to go live.
In the public cloud you build these controls into the platform and application from day one.
Siloed security versus embedded in processes
The silos and demarcation of traditional enterprise IT departments is a big hindrance to shipping secure solutions.
With automation there is a need to embed security processes into the delivery lifecycle rather than being an external dependency.
Given the scope and pace of change, it would take an individual an enormous amount of effort, time and resource to remain completely up to date on all things. So, the modern CISO has to become an enabler to ensure that the business achieves agility and gains the value from the public cloud.
How the CISO Can Become an Enabler
1. Trust the Cloud
The starting point has to be trust in the cloud and the CSPs.
As a CISO you need to validate the respective security and governance controls yourself to build trust.
From my experience with Microsoft Azure it is very difficult to run your own audit of a Cloud DC with the vast majority of requests being met with a flat “no”. The alternative is to make use of the independent audit and compliance reports that each CSP has had done. These are beneficial for the CSP because they can schedule and manage when they happen and from a customer perspective you save time and money.
You will need to satisfy yourself that these independent audits provide sufficient information to meet your security and compliance requirements. You should do this with the support of your CSP representative or a partner organisation that has experience in building solutions in highly regulated environments.
Each CSP takes the security of their products seriously and works with independent standards bodies such as NIST and ISO to achieve certifications. The CSPs lists the standards and compliance they have achieved through audit reports and attestations. See:
- Azure: Service Trust Portal
- AWS: AWS Artifact
- Google: Cloud Compliance & Regulations Resources
2. Your Security Must Be an Onion, Not an Egg!
The traditional approach to IT security in the majority of organisations was to ensure the edge was secure and that the doors and windows were closed. The goal was maintaining the security of the perimeter.
I call this the ‘egg’ security model. So long as the shell is hard, the centre can remain soft and gooey.
This does not apply to the public cloud.
The changing threat landscape of public cloud is forcing the adoption of a strength and depth approach to security design with controls on each component of the architecture - for example, implementing TLS encryption on the internal network, storage encryption and even homomorphic encryption (a form of encryption allowing one to perform calculations on encrypted data without decrypting it first) to process data while it remains encrypted. I call this layered approach the “onion” security model.
3. Shift Security Left
The adoption of modern delivery techniques such as Agile, DevOps and multi-disciplinary squads are helping to shift security to the left.
Shifting security to the left involves building security controls earlier in the development lifecycle, including into your platform and application code.
Building security controls into the platform and application code, performing automated security testing as part of the Continuous Integration process, and the introduction of compliance as code making use of capabilities in the cloud such as policy and automation to prevent compliance breaches on build and run.
4. Analyse the New Threat Actor Landscape
When you move to the public cloud it is important to review the threat landscape and identify the threat actors. The primary actors to consider are:
- Bad Company System Admin - Company admin that has access inside your cloud environment and takes action that has a negative impact
- Bad Company Tenant - This is where there is a malicious activity happening within your cloud tenancy that impacts others
- Bad CSP System Admin - A Cloud Service Provider admin that has access to the cloud fabric and takes action that has a negative impact on customer services
- Bad CSP Employee - A Cloud Service Provider employee that takes action that has a negative impact
- Naughty Neighbour (in the Cloud) - Another tenant in the Cloud taking action that has a negative impact on other tenants
- Eavesdropper - Listening in to ingress/egress traffic collecting customer data
- Malicious external party - A party not associated with the customer or the CSP that seeks to access the Cloud and take action that has a negative impact
- Supply Chain attack – A party that takes action on the CSP upstream supply chain that has a negative impact.
State sponsored cyber terrorism is not included as they have access to sophisticated capabilities that are not in the public domain. For the majority of sectors this will not be a realistic threat unless companies are operating at elevated security levels of Secret or Top Secret. For these scenarios multi-tenant public clouds are not the best solution.
5. Identify Key Threats to Your Cloud Environment
Knowing the actors, the next stage is to identify the key threats to your public cloud environment. You must consider the full supply chain as well as the services implemented.
Some example threats could be:
- Unauthorised code - has someone introduced weak or malicious code
- Data Breach - customer data is copied
- Customer Admins have “god” status and full control - this increases the blast radius of human error or malicious actions.
- CSP Admins have “god” status.
- The DevOps tool chain is not controlled - fully automated pipelines allow bad or malicious code to be deployed automatically.
Having built your knowledge earlier you are now in a position to work with your internal senior engineers to identify all the mitigations that are needed to manage the threats that are relevant to the solution you are deploying. Bring the CSP Solution Architects into these discussions to get the latest thinking and identify all of the controls that each service has.
For each of the controls it is your role to validate that they have been proven through compliance testing against a standard or audit using the tools that each CSP provides (as mentioned above). Where you need further detail, you can also ask your CSP to connect with the product teams so they can talk you through detail under the covers.
Finally, once your solution is designed and is built you must undertake Pen tests and IT Health Checks as you would do for all solutions.
One word of caution: If pen tests are going to in any way impact services outside of your cloud boundary then you should let the CSP know or they will think you are a hacker. Not all of the security testing service providers have experience in working with public cloud so it’s important to do your homework.
6. Establish a Security-First Culture
This is where the modern CISO can make a massive difference to the business. By driving security to the heart of your organisation’s culture you can ensure that it can innovate and be agile while staying secure.
I recommend three steps to drive this culture change:
- Educate Your Security Teams
- Dissolve the Security Silo with Cross-Functional Teams
- Evangelise with Security Champions
Let’s dive into a bit more detail in each of these.
7. Educate Your Security Teams
As a starting point I recommend that the IT Security teams should build their knowledge in the following key concepts:
- Software Defined Networking and Zero Trust Architecture
- Disk and network Encryption
- Key and Certificate management
- Cloud Network security devices
- Policy management
- Identity and Access Management
- Public and Private interfaces in the public cloud
I would also recommend asking for support from your CSP representative. Their Solution Architects will be able to take time to work through your questions and help with access to product teams to get more detail. They will also help you with establishing training paths for yourself and your teams. This will increase your credibility when talking with the delivery teams and provide a mechanism to test your knowledge and understanding.
8. Dissolve the Security Silo with Cross-Functional Teams
Adopt the cross functional team concept by embedding empowered security personnel into engineering teams.
What do I mean by empowered security personnel?
This is someone that has delegated authority and knowledge to make relevant security decisions that are within the bounds of the project. The key thing here is that the person has sufficient knowledge and understanding to recognise if the impact of the decision is greater than the scope of the project. Wider decision making that impacts across the enterprise will still need to go through a security governance process for approval.
Security personnel pick-up user stories that build out controls and policies. This approach puts the ownership into the IT Security team removing misunderstandings and accelerating approvals.
For instance, at a banking customer we set up the cross functional team with a member from IT security. This person picked up the user stories to build policy as code into the governance layer of the cloud environment. This was a challenge. But, by using techniques like pair programming and knowledge sharing across the team enabled this person, and after a few weeks, they developed policy as code under their own steam. The person became a valued member of the team and changed the perception of IT security completely.
9. Evangelise with Security Champions
The final task on the journey is to educate the wider business community and be seen to champion IT Security and how it can empower the business. There are few options that can be used:
- Targeted workshops: knowledge sessions for different parts of the business such as high-level sessions for the C-suite and technical deep dives with engineering teams
- Training/L&D/education plans: make resources available for the development of security-focused learning paths
- Community of Practice: create a Security Community of Practice to boost shared knowledge and learning
Conclusion
As IT has embraced the latest innovations of Public Cloud and DevOps ways of working, is it time for you to change as well?
The journey to becoming a modern CISO is rooted in trust. Trust the cloud and CSPs and enable the IT security teams and community to drive change.
