Image: © aleks-p/Stock.adobe.com
IT expert Ed Price discusses the need to prioritise security in the development process.
Rapidly maturing DevOps teams are breaking boundaries, strengthening processes and building products at a faster pace with each iteration.
This, seemingly, is a win for everyone. DevOps teams have a continuous opportunity to perfect their processes with each release; leadership sees deadlines being met and exceeded; and end users get faster, more reliable improvements to the apps and software they use daily. Overall, efficiencies almost always mean a healthier bottom line, and the adoption of DevOps practices is often lauded for making them a reality.
But if you ask a security professional about the accelerating pace of development, the reception won’t be as rosy. Recent research shows they have reason to be less than enthused about rapid iteration in increasingly agile development environments. Nearly 70pc of security professionals report their CEOs will do anything to prevent slowdowns and 52pc of the same professionals report that security has been sacrificed during development to meet a business deadline.
These statistics aren’t just disheartening for the security professionals, they are downright risky for business. Security is very much siloed in modern DevOps environments. About 44pc of developers aren’t equipped to code securely and 42pc of operations do not have proper security training. It’s no wonder, then, that data breaches are on the rise – as are the costs, at an average $7.9m per breach in the US.
Deprioritising security and allowing DevOps professionals to operate in a vacuum is not sustainable. The high price tag associated with the risks is one thing, but breaches can do serious damage to a brand’s reputation and cause a hard-earned user base to shrink rapidly.
Ed Price. Image: Devbridge Group
Fortunately, marrying security with existing DevOps processes and practices doesn’t have to mean a step backwards when it comes to agile processes and continuous deployment. By implementing the following principles and considerations, DevOps teams discover that integrating security isn’t as daunting a task as they may think.
Shatter the existing perception of SecOps
Here’s a sobering statistic: 85pc of organisations report building a bridge with security and implementing better SecOps practices is an important organisational goal, yet nearly 20pc of organisations surveyed in this study report not having any established SecOps practices. These statistics make it clear that security professionals need to make their voices louder, while developers, engineers and operations professionals need to demonstrate a willingness to listen.
A simple compromise to get started? Have security work on tasks on a different schedule than developers and engineers, allowing security to build in proper functions without hindering the development process. This is the first step towards a larger goal of bringing security integration and testing into the automated continuous iteration/continuous deployment (CI/CD) pipeline.
If security professionals struggle to make the case for these changes, it’s important for them to remind both DevOps teams and leadership that catching security flaws and red flags early saves time and money in the long run. Fixes are almost always simpler towards the beginning of development than just before or after deployment, and carry far less risk.
Use data to make informed security decisions
Not all security risks are created equal. Some flaws need immediate attention, while others can be fixed in a future deployment. In some cases, leadership may even be willing to risk bad public relations or regulatory fines to hit a deployment deadline. All of these situations have justifications, but security professionals need to set thresholds and procedures to define how critical certain security functionality might be in order to determine when to recommend pushing back a deadline. This means baking in data measurement and metrics.
With each release, all flaws and quality issues that affect security should be documented and measured against previous releases. The goal is to improve with each iteration, not compile a list of flaws that place blame on DevOps or the organisation as a whole. Ultimately, these metrics help set a threshold for basic security standards during a release and allow security to have a louder voice when CEOs are tempted to rush a deployment deadline.
Make security everyone’s priority
Ideally, solid security practices are woven into the start of establishing a DevOps practice and process. But we don’t live in an ideal world. More often than not, DevOps has already built a well-oiled machine before security can ingrain itself in the process.
To catch up, security needs to find champions in every department that can help make the case for implementing changes to the process. The data and metrics mentioned in the previous point are important – being able to quantitatively show the value of security measures goes a long way. With every sprint report that is shared with senior management, security metrics about the release should always be included. Additionally, security professionals should constantly strive to be included as early as possible in the development process. By doing so, they can make recommendations about security measures that will be far easier and cheaper to implement early on.
Finally, remember that security considerations need to be a priority even for those in non-technical roles. Beyond leadership, team members like project and product managers need to see the value of involving security, especially as they control the budget and timelines of releases. Security can’t play an integral part in the process if these individuals don’t take their recommendations into consideration.
By stating their case and getting involved early, security professionals can prove not only their value, but that they aren’t a hindrance to the development process. Taking these steps toward working more closely with DevOps can greatly increase security’s stake in the process – and help improve the final product. Before they know it, security professionals will no longer fear their work is the first to the chopping block during development.
By Ed Price
Ed Price is director of compliance at Devbridge Group and has more than 25 years of IT and development experience in firms such as JPMorgan Chase, the Quaker Oats Company and BMO Harris Bank.
