In our first blog on Continuous Security, an outline for three thematic areas, each containing two key capabilities, was provided.  This third blog in the series focuses on the Intensify theme and the capabilities of Educate and Govern.

You might think that intensify is an odd word to use for a theme related to Continuous Security.  After all, when one looks up the word “intensify,” the definition simply reads to “become or make more intense.”

So what do we mean?

Many organizations have adopted, or are in the process of adopting, DevOps practices and are also working to incorporate security into those practices.  This is a great thing, but it is not just a single effort or project. It is not like we add security testing into a pipeline, share some results and call it “done.”  Instead, we have to build off the initial efforts we’ve made, learn from them and course-correct.  Further, we are also looking to expand the security program beyond the security team and intensify it by embedding it with the organization’s development practices.

We need to continue improving our ability to find and mitigate risk.  In short, the efforts to intensify are conducted to ensure applications are healthier and more secure over time.

To make security really continuous, we need to amplify and extend our security paradigm, so that the result is more secure code being written and better security practices being followed.  That takes better education and better governance.

Educate

When we talk about educate, there are several different aspects that come into play and each are important.  Education transcends the whole security program and the needs differ depending on where security aligns with development, testing, operations and security. The first and foremost is for teams that are writing and working with code.

Let’s be honest, developers are usually not trying to write insecure code but often struggle with a lack of awareness about what is really vulnerable or how exploits even happen.  Developers generally want to be able to make code that is secure from the outset.  This can, and usually does, involve formal training, but alongside classes developers need concrete and contextual examples such as a repository of vulnerability fixes that have been performed by teams in your organization, so that others can benefit from them. After all, with so much code being shared, chances are good that if you run into a vulnerability, someone else has, too.  This ideally should be reflected in secure coding guidelines that will tie in with our governance of the security program.

A clear step that really advances the wider security program in organizations is to develop and grow independent security champions within development teams. Education on security awareness and best practices is key to making this successful. By having the security champions independent, and perhaps more aligned to the security team, ensures that corporate-based security policies and practices are administered. Security Champions may even work together as a wider team and learn from each other.

The second aspect is around tools and process.  In order to maintain the kind of pace that DevOps demands, it is imperative to have tooling that can provide help at the time of coding – without being distracting or too disruptive.  Teams get frustrated when critical security issues are identified at the end of a release cycle and pivots need to occur to accommodate fixing.  Instead, it is much more helpful to gain insight on code health when it is committed so that critical issues can be addressed quickly, in context and while the new code is still fresh in the developer’s mind.  With DevSecOps, automation and integrations are very critical. As every team usually approaches it in slightly different ways, education around best practices and the steps to integrate can be very beneficial.

And the final aspect to address is budget.  Getting better and more secure is an investment.  It is about getting training and rewarding those who are lowering risk.  And, it is not just good practice, it actually elevates overall morale of the business.  A recent study by Sonatype found that developers who regularly receive secure coding training are 5 times more likely to be happy in their work.

Now that we have talked about the people, let’s talk about the processes.

Govern

While in our Continuous Security model govern is seen as a later step, it is really often where the security program begins. Many organizations pursue application security due to a compelling need coming from an external compliance requirement. The Payment Card Industry Data Security Standard (PCI DSS) or Sarbanes-Oxley Act (SOX) are examples of common compliance drivers that align with security governance and provide excellent direction at the beginning. The challenge is to ensure we move the program beyond that, so we can reach the objectives of continuous improvement and continuous security.

In an ideal world, we would have completely flexible policies and practices that work perfectly to achieve the operational excellence that we need.  Policies and procedures would align with business goals and naturally move us toward an expedient and safe outcome.

Too often what we have is a good amount of automation that yields a lot of alerts, notifications, monitoring and a juggling of priorities.  If fact, a 2019 Study conducted by CriticalStart, found that 70% of security professionals have to investigate more than 10 alerts per day.  Investigate, not just receive. In a world where everyone is looking for ways to “shift left,” those investigations typically involve development teams.  And when that happens, the same study found that 35% are either trying to hire more staff or even turning off high-volume alerting features.

Not exactly what we were looking for.

As mentioned, the right governance is a business enabler.  It provides just enough rules and to ensure that policies are met, compliance is addressed and business goals are achieved.  So how do you really achieve it?  You start by measuring outcomes more than behavior.

Here’s a simple example.  It’s late afternoon on the Friday of a holiday weekend.  Code has been committed and the build process is running.  Part of the process includes an incremental security scan to validate new code changes.  And then it happens.  A critical test fails, the build process starts and emails start flying.  What happens next?

If you are measuring behavior, then the first question you have is likely, “Who?.”  As in “who checked in bad code?”, “Who didn’t run a scan before committing?,” “Who added that library in?,” and so on.  The focus is on finding the PERSON because the assumption is that this person is the one who needs to fix it.

If instead you are measuring outcomes, then the first question is more likely “What?.”  As is “What went wrong?,” “What did we miss?,” “What tests were run?,” and questions like that.  The goal is to understand what happened, and to be able to prevent it in the future.  Maybe the process needs to be tweaked to encourage more scans prior to the build starting, or maybe there needs to be a change in the way code is consumed and reviewed.

The point is that Governance needs to influence controls in the system.  It should outline the standards and rules around application security. It should effectively answer the question, “What are our secure coding guidelines?”  It is the framework of policies, standards and processes that form a structure for making decisions and defining expectations with respect to software. In essence, governance outlines why and how the security testing is happening throughout.

Summary

In this blog, we focused on the Intensify theme and the capabilities of Educate and Govern.  In our final part of this series, we will examine the Assure theme and the capabilities of Measure and Audit.

Finally, if you missed the earlier posts in this series you can find them here:

Part 1:  AppScan – It’s Time For Security To Be Continuous Too

Part 2:  HCL AppScan – Constructing Continuous Security

Co-Author Details

Colin Bell

Colin has over 30 years of IT experience. Over the past 18 years he has specialized his skills in Application Security and the deployment of the AppScan portfolio to customers worldwide. His current role is within HCLSoftware team as the AppScan CTO.

Kristofer A Duer

Kristofer Duer is currently an architect for research projects at HCL AppScan. He has worked in the application security field for the last 9 years in the world of Static Application Security Testing (SAST) and researching language specific attack surfaces. His particular specialty deals with applying machine learning to solve some of the impossible problems which occur naturally in the world of SAST – namely Intelligent Finding Analytics (IFA) and Intelligent Code Analytics (ICA). He wants to find new ways to discover vulnerale code being written and help the world be a safer place for all of us to enjoy.Outside of work he enjoys the gym, Disc Golf (super fun!) and spending time with his wife and two kids.