Continuous Security and Monitoring from a CISO’s Perspective
This is the last post in a three-part series on continuous 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 alike need to recognize that the continuous security approach will be what enables engineering velocity, and not what hinders it, for elite engineering teams.
Being able to fix vulnerabilities, bugs and issues before they end up in production is the key to unleashing developer velocity with the required guardrails organizations need today, while also being far more cost effective. Where this differs from known concepts of continuous monitoring in the cyber world is that formerly popular approaches looked at controls and security implementations after the fact (for example, tools like ServiceNow and Archer), more for collecting evidence.
In this post, when referring to continuous security monitoring, the idea is to create a framework that is the security equivalent of continuous integration or deployment, aligned with modern DevOps and software delivery processes. This is because we can’t get away from the need for security. It’s not an afterthought any longer — the stakes are too high. Yet the constant gripe is that security slows down engineering.
By adopting the continuous security approach in your software delivery, you will increase velocity in the long term as you’ll be able to deploy with more confidence and not get bogged down by security findings that are too late to fix cost-effectively.
Embedding security up front and continuously, as code, is the only way to make security part of your dev processes, while decreasing security debt. This aligns directly with everything we’d like to achieve as CISOs, where the chief priority is to support developer velocity for the business.
The Five Pillars of Continuous Security All CISOs Need
From a CISO’s perspective, there are five important pillars to continuous security to be able to support the engineering velocity that the CTO requires, without leaving security behind. In this post, we’ll dive into the elements that create peace of mind for CISOs to get behind increasingly rapid software delivery, converging on the common interest for both the CTO and CISO for the business.
Pillar No. 1: Security Tools to Support Developer Velocity
Progressive CISOs formerly wouldn’t introduce security tools in order to prevent adding friction to delivery processes. However, when the CISO stays too far out of the way, only checks for gaps and detects vulnerabilities later, what often happens is that “after the fact” findings will certainly destroy developer velocity.
Yesterday’s tools like quarterly pentests, audits and postdeployment scans don’t live inside our development processes. They provide outdated data that increase risk and expose us to breaches, with new vulnerabilities being discovered every day. Real security needs to be embedded into development processes, and this has completely flipped the approach to security in a CI/CD era.
Progressive CISOs realize that without DevSecOps tooling, they’re running blind and will not be able to mitigate risks quickly enough when they arise. “After the fact” fixes are always delivery and velocity killers, and very costly to embed.
Pillar No. 2: Real-Time Posture
Another byproduct of outdated vulnerability data — based on results from scans that were run a month ago, pentests and audits that are performed once every three months or in cycles, whether internal audits and reviews or external ones — is that they all fail at the same place. They are all time based and do not provide immediate actionable data.
Continuous security provides immediate results, which helps with navigating the ever-changing cyber landscape. As a constantly moving target and source of pain for CISOs, even a month-old data is stale and likely too late to be effective.
Real-time data ensures that engineering organizations are not increasing their security debt, and when it’s done correctly, it will stop the security bleed.
The major advantage of working with immediate results is that once scanners and controls are integrated, it’s like starting with a clean slate. From that point onward, organizations won’t be increasing debt.
By fixing any new security breaches before they go into the very long backlog, security becomes more manageable and less daunting in the long term.
Pillar No. 3: Prioritized Remediation
CISOs today are swimming in technical debt, findings and issues with long lists of vulnerabilities and issues. Even seasoned CISOs need direction on what should be their most pressing concern. What do I need to fix first?
Running continuous security tests helps CISOs and engineering teams have a prioritization framework. While there are plenty of tools such as NIST that provide security ratings, understanding the effect and likelihood of a specific vulnerability in your own stack, or even coupled with other vulnerabilities in your stack, takes a lot of time to assess and is quite difficult to ascertain.
The real-time posture we described provides the perspective of what’s new right 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 is fixed over time. Our previous post made reference to a boat analogy: You have to fix the hole before removing the water.
The reason why this segregation of immediate fixes and the backlog is so important is that you will otherwise find yourself spending years fixing existing issues, while introducing new vulnerabilities all the time, making security a Sisyphean effort.
However, likely the greatest advantage is that there is no additional tax on fixing. 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 already being worked on. Developers will, in any case, be in flow and context until their code is deployed to production or merged to main. It’s a good way to eliminate security overhead entirely (provided a fix is available), the eventual vision and promise of continuous security.
Pillar No. 4: A Security Baseline
One of the biggest challenges as 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 have essentially created this baseline by taking all the data and orchestrating it into a single, unified dashboard. This makes it possible, for each pull request or product update, to be in the context of this security posture. That can then be used as the baseline for our specific product and environment.
This helps CISOs with metrics, tracking and reporting of ongoing security posture, where it’s now possible to state with confidence how the engineering organization and product is performing with regard to security.
Whether you are at the level you defined as your baseline, or slightly below or behind, as a result of a specifically problematic sprint or zero day in your last development cycle, it is now possible to provide real answers regarding what is happening in your stack and product, in addition to providing context and insights regarding what has recently affected security posture, and even how this 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 the CISO, we may need to update processes, integrate new tools, even make acquisitions that will all introduce new products and changes into our environments. This requires our security programs to be flexible and scalable, as it is not viable any longer to wait three months or until the next security audit to gain visibility.
This also enables updates to environments using the continuous security process by incorporating the relevant checks such changes would require. Receiving real-time results and feedback that are actionable is another major challenge as a CISO that is now resolved.
Continuous security provides that kind of visibility, making it possible to incorporate additional checks into environments as the need arises, and even future-proofing by planning ahead for known and upcoming changes when adding a new technology.
Continuous Security: Where Engineering and Security Intersect
Security and engineering have been separate disciplines for too long, creating differing workflows, tools and processes for each. However, with software products being the backbone of many modern businesses and the growing threat landscape from the code, these two worlds need to be better together, similar to the transition that dev and Ops underwent in the last decade.
The continuous security approach finds the key places to benefit both software delivery and security engineering by providing different yet aligned values for both organizations that converge around a common vision — high-velocity engineering that is secure and safe for the business.
Embedding continuous security practices into your engineering serves to benefit security engineering, and vice versa, by ensuring that engineering organizations don’t destroy their culture and velocity with security requirements after the fact.
We hope these two perspectives provided you with insight into why the CTO and CISO need to mutually champion continuous security and the ways you can get started with building such programs in your engineering organizations right away.
