In a recent coffee chat with Jeff Jacobs CISO at IAG he talked about how, their team was making inroads into being ‘Secure by Design’. We reflected on how that advanced thinking re-positioned IT Security into being part of the process and not a milestone to tick.
Jeff went on to explain how his team was involved in all the agile scrum standups as a regular team member. While clearly this created added pressure around resource allocation, you can easily see the benefits of being involved early.
In contrast, where is your shop?
Applying an Agile Framework
In most enterprises there is an increasing focus on using an agile approach to deliver software. The basis of agile is that we build software using an iterative approach, instead of the normal ‘waterfall’ method. During this switch it has been the norm that the actual approach to managing security has not adjusted to this new reality.
The velocity of delivery has fundamentally changed and at the back end, just prior to ‘going live’ there has been pen testing and security review. Clearly this is better than doing nothing, but is not going to be the ideal approach.
Invariably some vulnerabilities and issues will be uncovered and this leaves the business product owner having to either accept a risk or the developer an additional task to figure out if there is a viable workaround. No-one wins and the CISO is the big bad wolf, who doesn’t understand the importance of this business initiative and is getting in the way of progress.
Building Security into the process
The alternative is that we build security into the application and not around the technology. By definition, agile is about being able to morph and change one’s approach – thus this means we have to apply security principles into the actual build process.
This means that stories that are developed as part of the agile process to depict “a day in the life of”, will by default build-in security controls. It places a responsibility for the developers working on user stories to understand the overarching security requirements of the new system.
Taking a practical example this would mean that the software engineer would need to consider all the new components and integration points, including any new cloud technologies. What else does it take to achieve this goal?
Coders are accountable to write “secure code”
Firstly take the onus off the CISO and the security team, instead change the focus so that security is part of the deliverable and the developers are expected to write ‘secure code’. This means that it is no longer acceptable for a software engineer to say that Personal Information, PCI etc is someone else’s responsibility.
Read more: Microsoft builds custom Windows 10 sanctioned by Chinese government
Therefore any new software routines needs to be built with security in mind – both secure at rest and in transit.
CISO or delegate are part of the project
Essentially this means you must have a “security expert” on every project. This person is on the team from day 1 and provides a security lense and hopefully is also engaged for their broader business expertise as well.
The advantage is that you bring to bear the security experience to the table and it will ensure that the user stories are robust and include security requirements. This also means that proactively the knowledge of current vulnerabilities and any new potential ones is understood and factored into the new design.
Specifically, there can be attention to security sensitive aspects in relevant user stories. This will include authentication, data entry and manipulation.
Security Testing by pieces
Agile development is iterative by nature and not end-to-end. On the other hand IT security requires a more complete holistic review. Thus integral to this is usually to get evidence of regression and test automation.
The Security professional will be seeking that there is a good validation of the design and a comprehensive review of controls. Thus even with the involvement of security from day 1 it is still going to be a challenge to take the pieces and understand the total picture.
However the critical element is that once a new vulnerability is understood, then an automated test can be developed to ensure that this is never repeated.
A Persona covers all needs
To be ‘secure by design’, means that the customers that we are designing for include the ‘persona’ that one would expect for the new system. In agile development these personas are used as proxies for the customer. By definition a persona is:
“archetypical user of a system, an example of the kind of person who would interact with it” [1]
The customer experience is what every enterprise is striving for. A great or at least good experience and it’s hard to think about a user that would realistically want the system to be insecure by design.
[1] http://www.agilemodeling.com/artifacts/personas.htm#sthash.NW0p1r4Y.dpuf