SAM.GOV Security Issue

by Brandon Graves, Partner

  • Cybersecurity, Government Contracting, GSA
Share

There were two significant problems with SAM.gov this morning.  First, it sent automated emails to registered organizations that said [email protected] had updated the SAM.gov registry information for {{LBN}}.  Then, the site was unavailable.  Although general access to the site has been restored, a number of organizations are reporting that they still cannot access their records.

Many people immediately speculated that SAM.gov was experiencing a data breach.  This is reasonable speculation; just days earlier, Federal News Network published a story highlighting GSA’s security misrepresentations.  In 2018, FedScoop published an article claiming a 2018 data breach of the SAM.gov site.  And of course, SAM.gov continues to have issues around the UEI transition.

GSA has stated that “[t]his does NOT appear to be a scam, phishing, hack, malicious behavior or security breach,” and that the outage and email were unrelated.  While this may be true, GSA lacks credibility here.  The government often takes a skeptical view of cybersecurity victim statements, going so far as to attempt to pierce attorney client privilege on mere supposition of third party misconduct.  Given the significant impact on government contractors of a SAM.gov data breach and GSA’s lack of adequate implementation to date, no one should take GSA’s statements at face value.  The government owes what it demands of the private sector: transparency and accountability.

Even if the issues were not caused by a data breach, they indicate a security issue.  Specifically, multiple inadvertent behaviors within hours of each other raises questions about the adequacy of controls and software development within the system.  This is on the heels of President Biden’s National Cybersecurity Strategy.  A central tenant of the strategy is to shift liability for software defects onto developers to “promote secure development practices” and ensure that “Federal grant programs promote investments in new infrastructure that are secure and resilient.”  More organizations need to implement secure software development practices, but the federal government should be setting an example, not making demands when its own house is not in order.  One might hope that the government’s inability to develop modern, secure systems would give it some humility when imposing liability on private entities, but that is unlikely.

So what should government contractors do?  First, they should validate that their information in SAM.gov is still present and accurate.  Second, they should assume that information submitted through SAM.gov is compromised; most of that information is public, but password reuse is always a concern.  Third, they should assume that SAM.gov will be unavailable at the most inopportune times.