Cyber Failure Leads to False Claims Penalty
We have a fascinating enforcement action from the Justice Department this week, where a subsidiary of Verizon has agreed to settle charges that its failure to meet certain cybersecurity standards as part of a government contract qualified as a violation of the False Claims Act.
Verizon Business Network Services, an IT services subsidiary within the Verizon Communications empire, had contracted with the government from 2017 to 2021 to provide federal agencies with secure connections to the public internet. Verizon’s solution, known as the Managed Trusted Internet Protocol Service (MTIPS), was supposed to satisfy three cybersecurity criteria spelled out by the General Services Administration, the agency that handles most government contracts.
Except, MTIPS didn’t satisfy those three criteria. Once Verizon became aware of that cybersecurity weakness, it did voluntarily self-disclose the issue to the GSA, and then took all the other steps we usually see — cooperated with the government’s ensuing investigation, implemented “substantial” remediation measures, and so forth.
The disclosure, cooperation, and remediation are all well and good, but Verizon’s failure to implement the promised cybersecurity measures do mean it didn’t fulfill all terms of the contract. That qualifies as violation of the False Claims Act, the federal government’s primary tool to sanction government contractors that either over-charge or under-deliver on promised goods and services.
Per the settlement agreement announced on Tuesday, Verizon will pay a $4.1 million civil penalty. Verizon neither admits nor denies any liability, of course.
This case is interesting because it’s one of the first we’ve seen under the Justice Department’s Civil Cyber Fraud Initiative, announced at the end of 2021. The program uses the False Claims Act to bring cases against companies that provide shoddy IT services to the federal government, but also to reward companies with more lenient treatment if they voluntarily disclose the cybersecurity issues they discover.
Or, as deputy attorney general Lisa Monaco said at the time, “For too long, companies have chosen silence under the mistaken belief that it is less risky to hide a breach than to bring it forward and to report it. Well, that changes today.”
I’m not sure how much has changed, really, since enforcement actions under the program are few and far between — but Verizon did follow all the tenets of the Corporate Enforcement Policy, and did only walk away with a $4.1 million penalty, which is chump change for a company as huge as Verizon.
Remediation for Cybersecurity Failures
So precisely what did Verizon do to smooth over the government’s ruffled e-feathers? The settlement order from the Justice Department goes into some fairly extensive detail. If your compliance or audit duties encompass data protection, pull up a chair.
First let’s specify the three cybersecurity controls Verizon failed to implement properly. We’re about to go full nerd here, but trust me, I’ll tie it back to compliance soon.
The controls are part of the Department of Homeland Security’s TIC Reference Architecture Document, TIC standing for “trusted internet connection.” Verizon was supposed to implement TIC 2.2, the version in force at the time. (TIC has since upgraded to Version 3.0.) The three controls, designed as “critical” controls in TIC 2.2, were:
- DNS Security Extension;
- Real-time header and content capture of all traffic with storage capacity for 24 hours;
- Certain encryption requirements that are part of the FIPS 140-2 standard for information processing.
At some point during the contract term (2017 to 2021), Verizon personnel realized those three controls were not fully effective. The company voluntarily self-disclosed, launched an internal investigation, cooperated with the GSA’s investigation, and implemented numerous mitigation measures. Those mitigation steps included:
- An extensive root cause analysis to figure out why the controls weren’t implemented correctly;
- Implementing compensating controls to get that MTIPS solution back into proper compliance;
- Conducting a line-by-line review of the MTIPS system security plan, and then updating that plan and other relevant documents and policies;
- Establishing a “Compliance Center of Excellence” to improve the company’s cybersecurity compliance framework;
- Making “substantial capital investments” to improve the company’s GRC program, and to automate compliance processes across the MTIPS program;
- Disciplining the employees who allowed this to happen, including one manager who got fired.
To be clear, that’s a lot of remediation. That leaves me wondering whether the deficiencies here were more alarming and inexcusable than the genteel language of the Justice Department settlement suggests, but whatever. For those GRC professionals wondering what you might do to avoid such a predicament, go through the bullet points above and see whether any of them might be best practices you should implement before signing a big IT services contract, not after.
A Word on Tools
I promised that we’d tie all this hardcore nerd stuff back to compliance programs! To my thinking, this mess with Verizon underlines the importance of using a GRC tool to track — and ideally automate — all the steps you need to take to comply with cybersecurity standards. That’s true whether the standard in question is TIC, or CMMC for defense contracting, PCI-DSS for credit card data, HIPAA for health data, or any other security framework that comes along.
In the ideal world, you have a GRC tool that can map out each framework’s requirements and map them to your existing controls, or to the gaps where you don’t have a needed control and will need to plug that hole somehow. In many cases you’ll find much overlap among all these frameworks, where one control can meet numerous compliance obligations; then you can eliminate duplicative controls and simplify data handling processes as much as possible.
My point is simply that companies can no longer execute the above paragraph with manual processes; you’ll drown in spreadsheets or float away on a sea of email messages that pass for documentation. You need a tool to automate the work. Rest assured, plenty of GRC vendors out there will be happy to help you with this task. Some of them might even have software that, ya know, works.
Clearly, however, the federal government is alarmed enough about effective cybersecurity that it’s ready to sanction IT contractors who can’t deliver the goods. I don’t know how often we’ll see actual enforcement actions from the Justice Department, but you could also be debarred from future contracts (worse than a civil penalty, really) or simply lose out to rivals because your GRC program isn’t efficient and you can’t provide the cybersecurity documentation federal agencies want to see.
That’s the future, folks. It’s already here.