by Matthew Flannery – CTO of Accelera Group
This is the second part in our series where we will explore what DevSecOps means, and how it can be adopted. Part 1 ‘What the Sec is DevSecOps?’ provides an introduction and includes our popular DevSecOps Infographic.
An age-old issue when designing software is considering security from the outset. It’s rare to find a developer with the battle scars of security issues and incidents to inform their design thinking, and besides, isn’t security somebody else’s problem?
Traditionally, security reviews and remediation happen late in the design and development of new software, risking tension between agile, creative design teams and risk-oriented security experts. The security folks are seen as the gatekeepers, but also the fun-spoilers. Many production deployment schedules have been derailed and pushed back due to security concerns that weren’t picked up early in the cycle.
Being alert, not alarmed
Security is becoming more of an organisation-wide responsibility now; there’s even talk of officeholders like CEOs and board members being made accountable for security breaches. While security issues can arise in many different ways, an overarching awareness of information security can play an important role in getting buy-in from technical operators and developers, as they come to realise security isn’t going to be someone else’s problem, but everyone’s.
For those organisations considering security certification such as ISO 27001 or the Australian Prudential Regulation Authority (APRA)’s CPS234, a policy that applies to internally and externally developed software will call for principles, practices, training and well-reviewed audit trails of the design process to ensure security principles are considered in every design.
Bringing security into the room
The skills and mindset needed to consider security at the start of the software development process are less about specific hacking techniques and the latest downloadable tools or system vulnerabilities, and more about having a mindset to consider security from the get-go. Security practitioners want to imbue teams with the principles of their trade so that they can apply them with their own initiative – to teach developers to ‘fish’.
One way that is starting to get traction is to bring the security experts into the room to work with the development teams – or even being part of the team – early, to help foster learning. The design process can then be informed by security experts with knowledge and experience of what’s out there, so that security concepts are covered and reflected in the design, rather than bolted-on later as a reaction. Developers can have their lightbulb moments and apply that knowledge next time around.
Training your developers the fun way
Integrating security into software design is not that different to other parts of the design process. A set of peer-reviewed and practiced principles such as the OWASP Top 10 can be brought into play to guide what’s important. To keep teams up to date and make the process fun and interactive, gamification of learning the subject matter and keeping up to date, such as the approach being pioneered by Secure Code Warrior, could be considered.
While risk-based security reviews, technical operations checks, and software design processes all have a unique view of security, a well-informed training and education program that gets devs to think a bit more like hackers and compliance folk will go a long way to bringing the team onto the same page. This will reduce friction and set your organisation up for success as you transform your software development life cycle to truly embrace and deliver on security.
Remember the champions
Within organisations of varying size, a recurring theme we have found effective is a security champion program, to foster a culture of security as a shared responsibility, and helping to ensure there is universal buy-in, cements the effectiveness of your DevSecOps program. Security champions empower the cross-functional DevOps teams to focus on the benefits of application security and security operations, and help overcome the sentiments of security being a tax and an impedance to performance. These champions can be developed from within the team, or may need to be introduced; regardless, they play a vital role in ensuring security is inclusive, offering guidance, triaging and encouraging others to play their part.
Forrester, defines security champions as “extended members of the security team that work in various roles across the organization that translate security-speak into a language that everyone can understand.”
The report outlines five steps for building a developer security champions program:
- Make the case – get buy-in and budget
- Choose the right security leaders – invest in empathetic security pros
- Identify & train – arm engaged champions with resources
- Support & reward – provide feedback and offer incentives
- Measure, monitor and improve – track KPIs and optimise for improvement.
Bringing security into your development processes early through a combination of cross-functional teaming, education and awareness, best practices and empathy aligned around an excellent security outcome takes some effort, but we reckon it’s worth the effort, because it makes the rest of your DevSecOps practice work so much more smoothly.
In subsequent posts in this series, we will dive into more of the key phases and provide insight and ideas on how to activate DevSecOps within your organisation.
Download the DevSecOps Infographic
