When I started working in the field of security - around 20 years ago - everything was driven top-down from the Ivory Tower in an almost military-like style. I got into the field of security while working at a bank and it was actually the “pre-framework” area. Imagine that: ISO27001 did not exist. Many consulting companies aimed at the financial industry to make it more secure (and made a lot of money from it). They all followed and advised the same approach which still is preached today:
- You need to get management buy-in for the overall program (e.g. stating something in the corporate strategy like “we take care of our customer data”)
- From there, you drill down your program and link it to corporate risk management. A common way to start is with a charta, vision or another high-level document.
- In some places, you define the CIA classification of information (Confidentiality, Integrity, Availability).
- Then there follows much ‘blah-blah’ like security strategy, policies, guidelines, formalizing it all.
- The technical implementation is usually performed by the IT departments (installing AV, Firewalls, forward proxies, …)
- And finally, you wrap the PDCA (Plan Do Check Act) cycle around it to continuously improve the whole program.
Where did Security happen?
In this pre-framework era security was in place; maybe incomplete but it was there, usually, at least at the operational level. The tactical and strategic level typically was lagging or missing entirely. So a new dimension had to be created and put on top of the existing operational levels which is where the ‘real’ security was usually done.
A crucial role: the CISO
Depending on the skills of the CISO, they’re typically used to be a gap between the management layer (tactical and strategic) and the operational layer. In case you were lucky and the CISO had technical knowledge and management skills, this disconnect was quite small. If security had been assigned to any random IT manager or a technical guy being promoted from the operational level, this disconnect would most likely resemble rather a complete disconnection.
Model vs. Innovation
Please don’t take me wrong, the top-down approach is still a valid way to establish security within an organization. The model, however, is 20 years old. To make this more tangible, here are some items that had been new in 1999, too:
Yes, I admit, 1999 had been an awesome year! And yet: The approach to Security so many times still feels like it never made it beyond the 1990s.
What should we do?
It sounds easy: throw away your policies and find a way to remove the disconnected area of CISOs using agile principles and methods.
Agile, scrum, who?
The Scaled Agile ”SAFE” Framework was first described in 2007, the Large Scale Scrum LESS Framework in 2013. Both try to scale up scrum and other agile methods to an enterprise level.
Scrum itself has been around for much longer but the core elements are almost valid for all agile methodologies I know. The practical adoption of these principles in the area of IT programming started in the early 2000s.
Scrum has three core roles: the product owner, the development team and the scrum master. The product owner defines the product from the customer’s perspective and does prioritization, scoping and funding and creates the schedule with the development team as well as key stakeholders.
Agile + Security = a novelty!
The diligent reader of these agile frameworks will notice that security is not mentioned at all. At the same time, security on its end has not followed the agile and organizational changes which had started after 1999. I refer to this in my talks about making Cyber Security more agile by saying that “security has been left behind”.
Turn policies into user stories
Now, this is where a new approach comes into the picture. It is not the senior management, the CTO, the CIO or another high-level role which needs to implement security. It is the product owner as king/queen of the product who needs to prioritize security within a product. If you initially hand over functional and non-functional requirements to the product owner, this may actually work (or not). In my experience, it is much more effective to redefine security requirements as “user stories” because this is the format and language a SCRUM team understands best.
Good User Stories should consist of the following elements:
“As a <particular class of user>, I want to <be able to perform/do something> so that <I get some form of value or benefit>”
| Policy | User Story |
| Users may not log in as or use a super-user (Administrator, root, etc.) or equivalent account for activities that do not require such access. | As a developer or engineer, I want to work with a separate privileged admin account next to my user account so that a compromise of my user account or device does not give an attacker admin privileges. |
|
All personal computers and servers that are connected to the network or otherwise using the IT facilities must run an approved and up-to-date anti-malware product that continuously monitors for malicious software (viruses, worms, etc.).
|
As a security champion, I want to detect malicious behaviour such as malware or hackers on developer devices so that I can take adequate countermeasures against these and prevent further harm to our organization. |
Sometimes a user story might be almost the same as the policy, but there are cases where a single user story or a small set of user stories might replace a huge policy. The main difference is the last part “<I get some form of value or benefit>”. With every User Story, you describe what you’d like to achieve and why this is important. You explicitly leave out how it will be done.
Group user stories as epics
If you start translating policy into security user stories you will soon face the need to group these stories accordingly. Now there are several ways to do that. Epics are an excellent way to group the user stories, for example. Epics themselves than can be grouped further as initiatives and so on. Atlassian has provided a good overview of how to do that.
If we look at our more simple anti-virus user story, as a practical example, this user story can be grouped with other related stories like the following:
What comes next?
I invite you to follow our blog series and to learn how TRUST, a DIFFERENT LANGUAGE and LESS CONTROL all come into play. I expect you will be inspired to sharpen your profile of a LEADER, ENABLER, CONSULTANT while staying the CISO who instructs and define the minimum boundaries - well, the latter, sometimes at least.
Coming up next are several deep dives in which I will share core elements of the Agile/Modern CISO approach.
- Deep Dive: Security User Stories and Epics
- Deep Dive: Leverage Bottom-up
- Deep Dive: Risk Tower
- Deep Dive: Become data-driven / Metrics
- Deep Dive: CISO automation and the CISO Bot
- Deep Dive: User-Focused Security
Following these, we will continue with a more technical part, the Security Automation or Shift Left approach for DevOps. In conclusion of the whole series, you will get a glimpse at our Zero Trust Architecture called BeyondCorp which we apply throughout our company.
I hope you enjoy this series and in the spirit of agile, I welcome your feedback and comments along the way, best on LinkedIn or via email.
