National Cybersecurity Deep Dive: Invest in a Resilient Future and Forge International Partnerships 

The first three pillars of the National Cyber Security Strategy focused on activities that could be accomplished in the near term–perhaps within a few years. The last two pillars start looking at some challenges that we need to address now.

Pillar 4 includes the following strategic objectives:

• 4.1: Secure the technical foundation of the internet
• 4.2: Reinvigorate federal research and development for cybersecurity
• 4.3: Prepare for our post-quantum future
• 4.4: Secure our clean energy future
• 4.5: Support development of a digital identity ecosystem
• 4.6: Develop a national strategy to strengthen our cyber workforce

There are two objectives that I want to dive deeper into: 1) the need to reinvigorate federal research and development for cybersecurity and 2) the development of a national strategy to strengthen our cyber workforce. 

Reinvigorating federal cybersecurity research 

If you are familiar with how the US government conducts research, then you may have heard of the Valley of Death. The Valley of Death refers to the continuous inability of the U. government to move a solution from research into actual production. I fear that the Valley of Death will apply to this federal cybersecurity research unless some critical changes are made. 

The product of that research must be available for companies like Devo to incorporate into our products. However, if the research is done collaboratively with industry, then industry will attempt to limit the ability of the Government to share the results. Data rights will be of the utmost importance in how this objective is met. The government is not in the business of producing cybersecurity software to sell to the masses, and if this investment in research only results in marginal improvements for only a handful of companies, then the investment is wasted.

The strategy calls out for many areas of research, which could cover the areas needed to enable the Autonomous SOC. Unfortunately, it doesn’t specifically address reducing the workload within the SOC–I hope that is simply an oversight by the authors. Continued research specifically on how AI can conduct SOC operations are critical and is only the way to reduce the current labor challenges. Can you imagine what a SOC could learn if every alert was fully investigated?

Strengthening the cybersecurity workforce 

The reality is that the US will never have a sufficient cyber workforce within a huge investment in research related to augmenting and automating many of the current human functions within cybersecurity. 

The problem is just too big, the work is too tedious, and labor is too expensive for every company to have a fully staffed Security Operations Center (SOC) with the absolute best cybersecurity analysts in the world. This isn’t to say that we need more cybersecurity talent, but that talent should be focused on directing the automation that is performing the grunt work.

Devo realized this some time ago, and is why we are pursuing the Autonomous SOC. We are doing the research ourselves, and evolving our product to provide our customers with the results of that research.

Forge International Partnerships to Pursue Shared Goals

Pillar 5 acknowledges that the US is not alone, and that cybersecurity is a global activity. Just like there are cybercriminals in every country including the US, there are cybersecurity professionals battling those criminals on a daily basis around the world.

Pillar 5 has five strategic objectives:

• 5.1: Build coalitions to counter threats to our digital ecosystem
• 5.2: Strengthen international partner capacity
• 5.3: Expand US ability to assist allies and partners
• 5.4: Build coalitions to reinforce global norms of responsible state behavior
• 5.5: Secure global supply chains for information, communications, and operational technology products and services

While the majority of this pillar deals with international politics, the overarching goal is to manage risk caused by critical products and services with a global supply chain alongside a lack of transparency and accountability. The risk is real–there have been multiple verified incidents of either a nation state or cybercriminal compromising a supply chain with fraudulent or compromised hardware and software.

There are two primary concerns when it comes to supply chain risk management:

• Can I trust my build process?
• Do I know what is in my product?

From a software development perspective, this highlights the importance of collecting the logs from not only your production environments, but also your build processes. For software, having an accurate Software Bill of Material (SBOM) is a critical part of understanding your risk. What I find interesting is the intersection between supply chain and incident response. At some point to address this risk, a company’s Security Operations Center (SOC) will need to treat issues with either the build system or software components as cyber incidents, and to conduct remediation actions. 

For example, if a company is dependent on a specific software library, and it is later found that that specific library has been compromised, then this is a legitimate incident for the SOC to respond to. This means the logs from the build process and any SBOM tools would need to be forwarded to the SOC.

As a logging platform, Devo can consume logs from a customer’s SDLC processes to include SBOM information. This puts these logs into the scope of the SOC’s ability to analyze. To support this, potentially new threat feeds focused on supply chain concerns need to be leveraged by applications like Devo. This would allow Devo to alert on supply chain concerns.

Supply chain isn’t just about software libraries. It includes everything in your environment, including hardware and software. Having robust and automated asset detection capabilities and configuration management processes will be critical to determine if a detected component is authorized or not. All of these can either forward logs to Devo or to create an alert in the Devo SIEM. Again, this starts moving supply chain incident response from IT Operations and into security operations.