By Richard Davies, Director AN/Z at Lacework
There remains a perception that security hampers speed, and can’t keep pace with today’s increasingly fast software development and release cycles. Maybe that’s not far from the truth – in Australia, demand in the cyber security market is predicted to grow by 8-9 percent annually, while Gartner predicts a 31.8 percent growth on cloud spending in 2022. This could well lead to continued cybersecurity shortfalls as security is outpaced by cloud infrastructure, capability, and capacity.
Chances are you now know what DevSecOps is and why it’s so important in this context. However, what seems to be missing from the dialogue currently is the logistics around actually making DevSecOps a reality in today’s siloed and increasingly complex business environments, and more importantly, making it stick. Our research found that obstacles like budget constraints, skills shortages and lack of appropriate processes are still preventing, slowing or stalling local business’ DevSecOps initiatives.
For any DevSecOps practice to be successful, a long-term strategy is needed. Here are five ways to future proof your DevSecOps strategy.
- Give developers a security voice
Leaders need to empower development teams with a security voice to maintain agility and speed to market – without compromising security. There are a few ways to make this successful.
Firstly, developer and application teams should be able to make daily decisions about what to build and how, free from heavy intervention. This external pressure is the cause of many bottlenecks in the software cycle. It can also diminish the team’s sense of ownership, resulting in difficulty attracting and retaining talent in an already scarce pool.
Another increasingly popular approach of bringing security into the developer ecosystem is to imbed traditional security headcount directly into the development team.
- Enhance efficiency through tooling
Look for underperforming tools amongst niche point solutions. These often require specialised talent or, at the very least, talent requirements that are not proportionate to the benefit of the solution itself. Modern tooling can often cover these areas plus more in a single platform.
Security tools that rely heavily on manual processes like rule and policy writing should also be abandoned. Writing accurate rules is a specialised skill, and even the most skilled practitioner will slow DevOps considerably using this method. Advancements in machine learning (ML) and artificial intelligence (AI) can now offer a broad capability without slow, manual processes. These tools can also help foster collaboration if they provide a shared view of the IT estate between developers, operations, and security teams.
- A paradigm shift from rules to monitoring
We now know that rule writing is an incredibly inefficient security practice, but perhaps more importantly, it will ultimately lead to unforeseen cyberattacks from threats that do not conform to the set rules, the ‘unknown unknowns’. There needs to be a paradigm shift from blocking-by-default to monitoring – using guardrails, instead of stop signs.
Security needs to be instructed to embrace this “monitor first” approach and work with developer teams to act on vulnerabilities found. To do this, you’ll need to invest in monitoring in both build-time and run-time.
- Position build-time security as an investment
Investing an already stretched budget in build-time security whilst maintaining risk mitigation on the run-time side may appear to be yet another expense. Leaders should think of this not as expenditure, but as a way to save on remediation costs.
Even without considering the risk mitigation advantages for your business, the cost is exponentially cheaper the earlier errors are picked up and corrected. As the security discussion moves upward into the boardroom, so too is the need for business leaders to show progress against their security objectives. Investing in a solution that can improve compliance, while bringing cost savings through automated, scalable security is a win from any perspective.
- Monitoring requires less noise from more data
With more cloud and developer activity leading to increased system interaction, IT teams need to be aware of their data volumes and how best to manage them.
On one hand, logs contain crucial information like Critical Indicators of Compromise (IOC) data, that can provide an early warning of an attack. On the other hand, teams need to reduce the number of alerts and noise pollution coming from their logging software as this is bogging them down. Security professionals are managing more and more data, with logs often containing more information than most organisations can handle. Companies that use more advanced tooling regularly find more accurate indicators or potential breaches – effectively making it easier to reduce the noise while managing more data.
Given all the buzz around DevSecOps, understandably there is a temptation to rush to implementation but the best place to start is to take a step back, and take stock. First, understand how your current security and developer teams work and the technology and operations tools you already have. Only then can you create the right environment for long-term collaboration, enhance efficiency through tooling and garner the right security investment you need to make DevSecOps a long-term practice instead of a flash in the pan.
