Feds commit to getting their software house in order
Before you accuse me, take a look at yourself.
— Eric Clapton
You hypocrite! First take the plank out of your own eye, and then you will see clearly to remove the speck from your brother’s eye.
— Jesus Christ, Matthew 5:7
OK, neither the British guitar god nor the Son of God were talking about software vulnerabilities. But the principle they were talking (or singing) about applies. And the federal government, to its credit, looks like it is trying to take it to heart regarding the security of the software its civilian agencies use.
As in, get your own house in order before bringing the hammer down on everybody else. Set an example. Don’t throw stones from a glass house and all that.
In this case, applying the principle took the form of a Nov. 3 Binding Operational Directive from the Cybersecurity & Infrastructure Security Agency (CISA) requiring civilian federal agencies to fix software vulnerabilities that are known, have already been exploited, and “carry significant risk to the federal enterprise.”
But less to its credit, the agency could have issued the directive sooner — a lot sooner. The CISA-managed catalog of vulnerabilities includes nearly 300, most from this year and 2020, but 91 dating back as far as 2010. Keep in mind that, besides including dozens found in the software of major players like Apple (24), Cisco (11), Google (22), IBM (4), and Microsoft (80), these are all publicly known. They all have Common Vulnerabilities and Exploits (CVE) numbers on a list maintained by the MITRE Corp. CISA is a CVE sponsor.
And CISA itself says “it is essential to aggressively remediate known exploited vulnerabilities to protect federal information systems and reduce cyber incidents.”
Which means those that are still unpatched look like a massive attack surface for cyber criminals.
One caveat: It may not be quite as massive as it looks. Emile Monette, a former program manager at CISA and now director, government contracts and value chain security at Synopsys, said there is speculation “that CISA is only really after a few of the vulnerabilities on the list, but they put a bunch more on it to hide what’s really important.”
Still, even if all of them aren’t crucial, that buildup, over years, of unpatched vulnerabilities is commonly called “security debt.” It’s a version of “technical debt,” a term coined more than a decade ago by programmer Ward Cunningham, (developer of the first wiki) who compared failure to address problems with software to “borrowing money thinking you never had to pay it back.”
“Of course, if you do that — say with your credit card — eventually all your income goes to interest and your purchasing power goes to zero,” he said.
So why wait, for two to eight years in some cases, to issue such a directive? Also, while CISA is requiring 2021 vulnerabilities to be fixed in two weeks, the deadline to patch older vulnerabilities is May 3, 2022 — six months away. How is that aggressive?
Especially in light of President Joe Biden’s executive order on “Improving the Nation’s Cybersecurity,” issued May 12, which calls for both the public and private sector to be much more aggressive about keeping the software they build and use patched and up-to-date.
The agency declined to comment on either of those questions. A spokesperson provided a link to a press release in which CISA Director Jen Easterly declares that fixing the problem is urgent. “Every day, our adversaries are using known vulnerabilities to target federal agencies,” she said. “As the operational lead for federal cybersecurity, we are using our directive authority to drive cybersecurity efforts toward mitigation of those specific vulnerabilities that we know to be actively used by malicious cyber actors.”
And a CISA official said on background that the six-month timeframe to remediate vulnerabilities identified before 2021 “is based upon a likely significant backlog of these vulnerabilities across the federal government, which will require potentially significant time and effort to resolve.”
The official added that “timelines may be adjusted if a vulnerability poses a particularly grave risk to the federal enterprise.”
Better late than never, but …
All of which is obviously better than nothing. But how much better? The reviews from software security experts generally fall into the “better late than never” category.
“It’s unfortunate — it never should have happened,” said Monette. “Many in the community have been loudly decrying the technical debt the government has accrued over the years to no avail. But at least now something is happening.”
Sammy Migues, principal scientist within the Synopsys Software Integrity Group, said the main problem is that “no one knows where this list came from or why it was made with some things and not others. It feels like there’s no direction on how agencies can figure out if they have these issues. There’s no tool that finds all of these — only a handful are open source and findable by a software composition analysis tool.”
That’s not the only source of confusion. Michael White, applications engineer within the Synopsys Software Integrity Group, said one vulnerability on the CISA catalog, listed as affecting iOS, is also on another list of vulnerabilities “that has broader applicability since it affects an open source library called WebKit, which is used in far more cases than just Apple products.”
“In this case, are they asking agencies simply to make sure they patch their iPhones or are they asking for complete remediation of that vulnerability wherever it might occur?” he said. “These are two completely different requests.”
Then there are the deadlines. Monette said he doesn’t understand why CISA is giving agencies six months to fix older vulnerabilities and only two weeks to fix newer ones. “There may be some technical and compatibility issues that make the older ones more difficult, but I wouldn’t think that would make them less urgent,” he said. “So this is a head-scratcher for me.”
He is glad to see deadlines imposed, although he doesn’t expect most agencies to meet them. “I think six months is aggressive for remediating ICT [information and communications technology] risks in fielded systems,” he said. “But I think the drafters were correct to apply pressure on the agencies. The work required is long overdue in the first place.”
On the face of it, it might seem like it shouldn’t be that difficult to comply with either deadline. After all, these are known vulnerabilities with CVE numbers and patches available. Is it that hard to apply a patch?
Not that simple
Well, it’s not as simple as applying a patch. First, an organization needs to know if it’s using a software component that is on the list. And most organizations don’t maintain a comprehensive software Bill of Materials, which tracks not only the components — where they came from, who made them, how they were built and tested, and how they are maintained — but also what other libraries and components those components may rely on, known as dependencies. Dependencies can increase exponentially the number of components an organization needs to track and keep up-to-date.
That means the time it takes to fix any or all of the hundreds of vulnerabilities in the CISA catalog “may be related to agencies’ lack of rigorous asset management. They don’t see the vulnerabilities so they don’t know they need to patch them,” Monette said.
Still, while the road to compliance with the CISA directive may be bumpy, the good news is that government is publicly committing to start improving the security of its software. And to continue that improvement by updating the list.
“CISA will review this directive to account for changes in the general cybersecurity landscape and consider issuing supplemental direction to incorporate additional vulnerability management best practices for federal information systems,” the agency said in an explainer to the directive.
It added that “annually, by the end of each fiscal year, [CISA will] provide a status report to the Secretary of Homeland Security, the director of the Office of Management and Budget, and the National Cyber Director, identifying cross-agency status and outstanding issues in implementation of this Directive.”
Monette also has a recommendation that could result in far fewer additions to the CISA catalog. The federal government should “improve its software purchasing practices — only buy software that’s tested various ways for all the bad things, and from manufacturers that will share test results and other risk mitigation practices to demonstrate that the software being sold is best-in-breed and free to the greatest degree practicable from known vulnerabilities,” he said.
Indeed, it’s much faster and cheaper to find and fix vulnerabilities during software development than to have to come back and fix them later.