In our first blog on Continuous Security, an outline for three thematic areas, each containing two key capabilities was provided. This 4^th and final blog in the series will focus on the Assure theme and the capabilities of Measure and Audit.

So why did we pick “Assure”?  Because we have noticed that too often security is more reactive than proactive. In fact, a 2018 Study from the Ponemon Institute found that an astonishing 78% of cybersecurity and infosec teams spent more than 250 hours per week (on aggregate) dealing with alerts that were erroneous. We need to do better. Good security done right should add value to the business, breed more confidence in systems and reduce time spent on non-productive things. Instead of wasting time trying to understand whether every alert is actually an issue, we need real assurance of the security program.

With continuous security, the aim is to learn from the process and to improve upon it. For instance, if a certain team is struggling with continual sanitization issues, then perhaps there is a need for stronger secure coding education. If a certain vulnerability is being exposed across many teams, perhaps the coding guidelines need to be amended. To be successful, you need to ensure that controls are in place to meet your guidelines and standards. Metrics are needed to measure the success and Audit is needed to ensure you meet the objectives.

Measure

The measure capability is one of the key aspects of success in continuous security. With this capability, we examine both specific aspects of security – the measurements – and the relationships those measurements have to one another and the business – the metrics.  We need to pay attention to both and apply them correctly as processes mature and progress. This capability is also where so many organizations differ in their approaches. For example, I have seen cases where the most important measurement is that an application is scanned before release. Unfortunately, this places no emphasis on the results that are being found by those scans. So yes, scans were run, but what value did it add to the business if nothing was done with the findings?  Typically, the underlying reason for this approach is that the program is being driven from compliance needs such as PCI DSS.

Others value as a core metric the number of applications tested compared to the total number of applications in the portfolio. Those organizations often start with the “crown jewels” or the most important critical applications and ensure they meet some level of security policy. Perhaps that all high-risk issues are mitigated before the application can pass to the next phase.

More mature organizations use measurements to reduce the time to fix vulnerabilities, and use team-based metrics to determine where vulnerabilities appear or are created. This was emphasized In Episode 5 or our “Application Paranoia” Podcast series, through a discussion with HCLSoftware’s CISO Joe Rubino, where he discussed metrics that he saw as important in his security program. Core metrics he valued were that of coverage area and scope, vulnerability identification by source, types of vulnerabilities identified, what new is coming out new over time compared to historic trending, and how teams were responding to those findings.

Joe also mentioned that a key metric for his team was associated with “what are we hearing from the development teams.”  Are there concerns from development about vulnerabilities or about security in general, and how are those concerns impacting their workloads? How can the security team improve the process to ease that burden?  His point being that we need to ensure this is not just a one-directional communication flow, and we need to use metrics to ensure that everyone feels part of the same team.

Whatever the approach, ultimately what is important is that metrics are driven from a security governance perspective and not the other way around. For instance, we may outline the test process for an application based on its business risk, or we can include secure coding guidelines that determine what types of policies will be applied to our scanning. This leads directly to our decision about what risks can be accepted and what ones need to be fixed. If we are doing governance well, then that helps us know better what to measure and then use that information to influence the outcomes we desire.

Audit

That brings us nicely to Security Audit activity. For many organizations, this is an independent function and they might be responsible for security testing or application pen testing of critical applications. Having worked in this capacity in the past, I know that these teams are highly-skilled and pride themselves on the ability to ensure no rock is uncovered when it comes to looking for vulnerabilities.

The problem is that their work is lengthy and for a company that has hundreds of applications, it does not scale. They also may not always leverage the security testing that has occurred in the SDLC. Nor would they review the types of testing that are being undertaken.

With continuous security, Audit is also a key component and corporate security should really take responsibility for the full security program as it passes from development through to production. Audit is more than just verifying compliance against a set of rules or regulations. Audit is really about validating that we are executing policies, practices and procedures correctly, so that the business can function in a healthy manner. Pen testing is one capacity, but it should not be done in isolation. Instead, it should fit into an overall corporate security strategy that includes reviewing the metrics that have been gathered and contributing their vulnerability findings to the reporting.

If a SIEM is being used, that information should also be leveraged to make decisions on the application and its exposed risks. As information is gathered from all of the activities, this information can and should be fed back to governance to alter the process as appropriate. This might provide education to the teams to enhance their security awareness, influence the threat model or make changes to security standards and guidelines. What this means is that Audit is a key aspect in determining the overall risk of our applications.

Summary

So, the pillars to assure the success of continuous security are having audit, measure and governance working together. In essence, governance outlines why and how security testing is happening throughout the process, measurements are facts about the testing and audit is confirming that it is working to the desired level.

In this blog, we focused on the Assure theme and the capabilities of Measure and Audit.  This concludes the continuous security circuit and 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

Part 3: HCL AppScan – Intensify Continuous Security

Co-Authors

Rob Cuddy

Global Application Security Sales Evangelist

Kristofer A Duer