Last week, the Wall Street Journal reported a troubling series of cyber breaches at a US Navy contractor connected to the Naval Undersea Warfare Center. Over the last eighteen months, hackers made off with sensitive military information such as ship maintenance data and missile plans. These incidents prompted an official review of the Navy’s cybersecurity posture, and will likely result in additional requirements for government contractors down the line.
The contractor cybersecurity challenge
Government agencies continuously grapple with the challenge of securing contractor networks. As more of the day-to-day administration of government networks is contracted out (even on high security systems), agencies are increasingly worried about the cyber implications. Repeated incidents have shown that contractors don’t feel the same obligation to secure their networks as government agencies do.
Subcontractors present an even greater problem. Most large-scale government IT contracts are a tangle of technical alliances, small business partnerships, and outsourced task orders. Even the most diligent government contracting officers and compliance staffers can have a hard time securing these “flow-down” networks.
Up to this point, contracting language has been the government’s cybersecurity mechanism of choice. DFARS (NIST 800-171), Kaspersky-related provisions, and other standard terms and conditions are used to prompt action at the contractor level. The threat of disbarment, fines, and legal action is supposed to keep contractors and their subs in line.
As the Navy incidents and many other case studies demonstrate, this strategy clearly isn’t working. Contracting language is no substitute for an active, coordinated cyber defense.
In reality, the threat of disbarment and severe financial penalties actually carries very little weight. Most government IT contractors are “too big to fail” in the sense that few agencies would be able to move to another provider quickly. Given the vagaries of the Federal IT employment market, the same personnel and processes would migrate from any disbarred or disgraced contractor at any rate.
Exhibit A: the contractors involved in the Navy cyber incidents will probably get off with little more than a slap on the wrist. None of the other contractors involved in major government breaches have faced any meaningful sanction.
In the absence of a workable proxy accountability mechanism, it seems increasingly likely that the government will have to take a more active role in securing contractor networks. While this approach will certainly be more work-intensive and expensive to create, it is also more likely to produce lasting results. In this case, if the government wants cybersecurity done right, it will have to put that system in place itself.
Is there a technical solution?
Visibility is the primary challenge in securing the tangle of government contractor networks. SOCs at the agency, contractor, and subcontractor level need a common picture of what’s happening and a common mitigation strategy to stop threats in a coordinated way.
DNS offers an intriguing solution to this shared visibility challenge. As the foundation of every network action and a clear indicator of intent, DNS can provide the earliest warning signs of a cyber incident.
Unfortunately, few if any government agencies or contractors currently use DNS to monitor their operations. Most don’t keep comprehensive DNS logs (or any DNS logs) to track malicious activity as it moves within a network. Even fewer actively use DNS to monitor, block, or redirect known malicious activity.
The EINSTEIN program was an attempt to bring DNS data under a single roof and leverage it for security purposes. Unfortunately, that effort is hampered by lack of client-level visibility, procedural challenges which effectively prevent real-time mitigation, and limitations of government networks. With the ongoing challenges to government and contractor networks, decision-makers would do well to reconsider the scope and application of EINSTEIN, moving to a more comprehensive, hands-on model which brings DNS to the forefront.
DNS Edge is a proven solution which is already making a significant difference in securing the networks of US government agencies and the contractors they depend on. Learn more about how DNS can provide a new level of visibility and control on your network.
9.3 Integrity Deep Dive On-Demand Replay
Learn how you can get more security data, ramp up automation, and adopt cloud without compromising performance.
For DNS server caching, what is the ideal TTL?
Many factors affect how to set time to live (TTL) for DNS servers. Learn more, plus how BlueCat Edge’s TTL features can bolster your network.
Comparing AWS, Azure, and GCP cloud DNS services
The public cloud presents major challenges for DNS management. Examine various capabilities and limitations of Azure, AWS, and GCP with BlueCat.
DDI Day: Kudos, awards, and insights from pioneers
BlueCat’s DDI Day on April 13 celebrated network infrastructure professionals, gave awards to superstars, and drew insight from DNS and DHCP pioneers.