Cybersecurity and the Unexpected Consequences of the Government Shutdown

On December 22, 2018, the U.S. government instituted a partial shutdown when Congress failed to approve an appropriations bill. The consequences of this lapse in funding are obvious and very visible, from parks closed due to lack of trash collection, to the suspension of key services like federal housing loans.

In today’s heavily connected and integrated world, deep dependencies have developed between enterprise development and external resources. This is especially true in the world of cybersecurity, where key standards, guides and repositories of data play a critical role in efficient cybersecurity operations. These resources often become deeply embedded, and in some cases, a fallback service either doesn’t exist or suffers from a complex failover process.

As a result, the incapacity of NIST, and the suspension of all its resources, is being felt throughout the entire cybersecurity industry.

What happens when NIST is no longer there?

Some impacts, like the inability to download standards or test data, are obvious and immediate. Others, such as the impact on automation, caught many people completely off-guard.

When DevOps teams employ continuous integration, code is pushed automatically through a series of steps before it’s packaged and deployed to production or test environments. Human involvement is deliberately minimized to reduce friction and speed up the build and deployment process.

These steps generally include a battery of unit tests, including security checks, to ensure that the code is compliant and any obvious bugs are identified and resolved. For security tests, many resources on NIST’s online platform have become the gold standard across the industry. A number of organizations are learning, the hard way, that those integrations, and the dependencies that rely on them, are now broken.

Rumblings within the Twitterverse

All across the internet, thousands of DevOps processes are seeking to connect with NISTs various resources, and failing. As these operations fail, staff are left with two choices: fail over to an alternative service (if they have one), or simply comment out the step (and suspend security checks) until NIST comes back.

What does this mean? The answer will vary from organization to organization, but in many cases it means code is being packaged and built without the full set of unit tests.

Assuming there are security checks performed without this dependency later in the development cycle, then this won’t be an issue. If, however, there are no additional checks, then many organizations could be setting themselves up for a substantial uptick in software vulnerabilities further down the line.

What has become abundantly clear, is that once the shutdown is over, we need to have a conversation about dependencies. What data sources and services should be considered critical? How do we ensure their continued availability when general systems fail? It appears that, moving forward, we need to plan for the unusual and the extraordinary.