This is the final post in a three-part series on ongoing security.
Read Part 1.
Read Part 2, the CTO’s perspective.
In our previous posts, we talked about why Security as Code, security orchestration and continuous monitoring are the backbone of truly viable continuous security, the next phase of the CI/CD revolution. CISOs and CTOs need to recognize that a seamless security approach will enable engineering velocity, not what inhibits it, for select engineering teams.
The ability to fix vulnerabilities, bugs, and issues before they end up in production is the key to unleashing developer speed on the necessary guardrails that organizations need today, while also being more cost effective. Where it differs from well-known concepts of continuous monitoring in the cyber world is that previously popular approaches look at security controls and implementation after the fact (for example, tools like ServiceNow and Archer), more for in collecting evidence.
In this post, when referring to continuous security monitoring, the idea is to create a framework that equates to the security of continuous integration or deployment, aligned with modern DevOps and software delivery processes. This is because we cannot escape the need for security. This is not an afterthought – the stakes are too high. But a persistent complaint is that security slows down engineering.
By adopting a continuous security approach to your software delivery, you’ll increase speed in the long term because you’ll be able to deploy with more confidence and not be bogged down by security discoveries that come too late to fix the cost .
Embedding security up front and continuously, as code, is the only way to make security part of your dev processes, while reducing security debt. This aligns directly with everything we want to achieve as CISOs, where the top priority is to support developer speed for the business.
The Five Pillars of Continuous Security Every CISO Needs
From the CISO’s perspective, there are five essential pillars to continuous security to support the engineering speed required by the CTO, without leaving security behind. In this post, we’ll examine the elements that create peace of mind for CISOs to get behind increasingly rapid software delivery, joining the common interest for the CTO and CISO for the business.
Pillar No. 1: Security Tools to Support Developer Speed
Progressive CISOs used to avoid introducing security tools to avoid adding friction to delivery processes. However, when the CISO stays too far away, only checks for gaps and finds vulnerabilities later, what often happens is that the findings “after the fact” will inevitably break the developer’s momentum.
Yesterday’s tools like quarterly pentests, audits and postdeployment scans don’t live within our development processes. They provide outdated data that increases risk and exposes us to breaches, with new vulnerabilities being discovered every day. Real security needs to be embedded in development processes, and this completely reverses the approach to security in a CI/CD era.
Progressive CISOs realize that without a DevSecOps tool, they are operating blind and unable to quickly mitigate risks when they arise. “After the fact” fixes are always delivery and velocity killers, and very expensive to embed.
Pillar No. 2: Real-Time Posture
Another byproduct of outdated vulnerability data — based on results from scans run a month ago, pentests and audits performed once every three months or in cycles, whether internal audit and review or external — is all this failed at the same time place. They are all time based and do not provide immediate actionable data.
Continuous security provides immediate results, helping to navigate the ever-changing cyber landscape. As a constantly moving target and source of pain for CISOs, even one month old data is out of date and likely too late to be effective.
Real-time data ensures that engineering organizations don’t increase their security debt, and when done right, it prevents security bleeding.
The main advantage of working with immediate results is that when scanners and controls are combined, it’s like starting with a clean slate. From that point on, the organization’s debt will not increase.
By fixing any new security breaches before they go into a very long backlog, security becomes more manageable and less scary in the long run.
Column No. 3: Priority Remediation
Today’s CISOs are swimming in technical debt, findings and issues with a long list of vulnerabilities and issues. Even seasoned CISOs need direction on what they should be most focused on. What do I need to fix first?
Running continuous security tests helps CISOs and engineering teams have a prioritization framework. While there are many tools like NIST that provide security ratings, understanding the impact and likelihood of a particular vulnerability in your own stack, or even in combination with other vulnerabilities in your stack, takes takes a lot of time to analyze and is quite difficult to ascertain.
The real-time posture we’ve described provides insight into what’s new now and what needs to be addressed immediately in this pull request. This helps us know what we need to fix first, and what goes into the backlog and gets fixed over time. Our previous post made reference to a boat analogy: You have to fix the hole before removing the water.
The reason this separation of immediate fixes and the backlog is so important is that otherwise you’ll find yourself spending years fixing existing issues, while introducing new vulnerabilities all the while of time, making security a Sisyphean effort.
However, probably the biggest advantage is that there is no additional tax on the arrangement. While working on fixing bugs or other quality issues that arise in peer reviews for example, it is then possible to easily add security fixes to the list while the code is being developed. Developers are, in any case, in flow and context until their code is deployed to production or merged into main. This is a great way to completely remove security on top (if a fix is available), the ultimate vision and promise of continued security.
Column No. 4: A Security Baseline
One of the biggest challenges as a CISO is having a clear understanding and baseline for what good security looks like from a stack, workflow and operations perspective.
By having a continuous security program, you essentially create this baseline by capturing all the data and organizing it into a single, unified dashboard. This makes it possible, for every pull request or product update, to be in the context of this security posture. That can be used as a baseline for our specific product and environment.
It helps CISOs with metrics, monitoring and reporting of the ongoing security posture, where it is now possible to say with confidence how the organization and product engineering is performing with regards to security.
If you are at the level you defined as your baseline, or slightly below or behind, as a result of a particular problematic sprint or zero day in your final development phase, it is now possible to provide real answers about what’s happening in your stack and product, in addition to providing context and insights about what has recently affected the security posture, and even how it affects the long-term security and product plan.
Pillar No. 5: Flexible and Scalable Security
Security programs need to be engineered to be as flexible and scalable as our systems. As CISOs, we may need to update processes, integrate new tools, even make acquisitions, all of which will introduce new products and changes to our environments. This requires our security programs to be flexible and scalable, because it is no longer viable to wait three months or until the next security audit to gain visibility.
It also enables updates to environments using a continuous security process by incorporating the relevant checks that such changes will require. Receiving real-time results and actionable feedback is another big challenge as a CISO that has now been solved.
Continuous security provides that kind of visibility, making it possible to integrate additional checks into environments when needed, and even future-proof by planning ahead for known and upcoming ones. change when adding new technology.
Continuous Security: Where Engineering and Security Meet
Security and engineering have been separate disciplines for too long, creating different workflows, tools and processes for each. However, with software products being the backbone of many modern businesses and the growing threat landscape from code, these two worlds need to work better together, similar to the transition that dev and Ops went through in the last decade.
A continuous security approach finds key areas to benefit both software delivery and security engineering by providing different but aligned values for both organizations that converge on a common vision — high-velocity engineering that is safe and secure for business.
Embedding continuous security practices in your engineering serves to benefit security engineering, and vice versa, by ensuring that engineering organizations do not destroy their culture and speed with security requirements after the fact.
We hope these two perspectives have given you insight into why CTOs and CISOs need to work together to promote continuous security and the ways you can start building such programs in your organizations right away. – engineer.
