Creating an Effective Cybersecurity EO
In 2008, the day before the presidential elections, I wrote an open letter to President Obama. I should have cc’ed the vice president. It’s been more than 12 years since I provided my suggestions for securing the federal government against cyberattacks. Perhaps some of my cybersecurity suggestions would have prevented the numerous successful attacks if they had been implemented.
Don’t forget that, at the time, the outgoing POTUS had briefed Obama on Olympic Games (Stuxnet). Obama was better informed about the power of cybersecurity capabilities than any of us.
My recommendations, though directed at the federal government, are applicable to any organization’s cybersecurity efforts. It starts with:
Assign responsibility for cybersecurity to one person in each agency. This is the “one throat to choke” approach. Then, assign real costs to that person if they fail at their job. Just as a sea captain faces an automatic trial by court martial if they lose their ship, the head of IT security should face the loss of their job if they fail to ward off attacks.
This job is usually given to a chief information security officer (CISO) who should, in turn, pass down responsibility to people in other roles. The CISO works with the entire team to scope out the security controls needed to fend off attackers. The CISO rallies the resources needed to put those controls in place.
Most system administrators make decisions every day that weigh the balance between security and production needs. They often decide in favor of the production needs. It is faster to telnet into a server with a username/password shared among all the other servers and admins than it is to assign unique SSH credentials to each superuser. (I am looking at you, Pentagon admins.)
If, instead, the CISO prioritized security, their thought process is simple: “If my systems get hacked, I will get fired; therefore, I will dictate that no telnet is allowed anywhere in my domain. You sys admins will be fired unless you implement stronger access controls.” That changes the calculus for the sys admins. They already had long lists of tasks to accomplish, but this task has to be done now, or they’ll lose their job.
Banning telnet is just one of thousands of controls that need to be put in place. How should the CISO enforce them all? By continuous scanning and monitoring, of course.
Twelve years later, the man who was vice president in 2008 is now POTUS. What is President Biden doing? According to reporting from NPR, he is putting together an Executive Order to address the latest and greatest attack methodology, SUNBURST.
“So essentially, federal government procurement allows us to say, ‘If you’re doing business with the federal government, here’s a set of things you need to comply with in order to do business with us,'” Anne Neuberger, the deputy national security adviser for cyber and emerging technology at the White House, told NPR in an exclusive interview.
Preventing more SolarWinds-style breaches, where software is compromised at the vendor, is a daunting task. Since the root problem involves the compromise of software development teams at a vendor, the proposed EO hopes to change procurement processes for Federal agencies. The idea is that software providers will improve their processes and earn some sort of certification in order to sell to the government. Those who like this idea claim it will improve software assurance processes across the board. If SolarWinds creates a process to validate that code has not been tampered with at the time of commit, then all of SolarWinds’ customers will benefit.
Unfortunately, I am afraid this will do nothing to reduce future threats, and will only reduce the number of products available to Federal agencies.
There is no question that every software vendor has investments to make with regard to security, including:
- Everything needed to prevent a developer from being compromised.This is cybersecurity 101.
- In addition, check all code before it can be committed for all changes. This is in addition to standard QA for bugs and static code scanning to check for vulnerabilities, hard-coded credentials, etc. All committed code has changes in it. The developer has fixed a bug, added a feature or improved a function. The hard part is identifying changes the developer did not make. You have to check for changes made by the Russian SRV, for example – things that do not trigger vulnerability alerts, but which are coded back doors.
But most software vendors are good at measuring risks versus returns. Many will decide that the cost of imposing the types of controls necessary to prevent the next SolarWinds does not justify the benefit of selling to the Federal government. Startups, by their nature, don’t worry about security at all. They don’t have customers yet. Plenty of time to add in security once they are on a roll. Therefore, they will opt out of selling to a customer that requires a lot of added expense.
There will be software companies that decide their existing government business does not justify the security investment.
The result will be fewer options for Federal agencies. Only large companies will make the investment to keep their Federal contracts. Software procurement costs will rise. In some cases, only foreign companies will meet the requirement. Think of the hypothetical case of Oracle not meeting the requirements, while SAP does.
Here is a proposal: Rather than impose the requirement for a bunch of controls that will be almost impossible to verify, require all source code to be submitted to a special group, maybe CISA, for verification. For a new product, this could be a long process. Updates, however, would be faster, as only changes would need to be inspected. A backdoor would be identified before it was distributed.
I have a a history in automotive manufacturing. This approach worked to improve quality from suppliers. At first, a supplier’s parts were 100% inspected and rejects sent back. Over time the supplier would improve their own processes to reduce returns. Ford did not have to tell them to improve their processes, just their products.
In the software world, companies would acquire the same capabilities as the Federal quality control group to ensure their code passed through the system quickly. Instead of viewing security investments as added cost, they would view it as reducing delays getting to market, thereby reducing costs.
Two different cybersecurity approaches: an EO requiring software vendors to impose a lot of new controls, or an inspection that will make the suppliers want to devise their own controls.
