When you think of open source systems available over the ‘net what do you think of? Apache Tomcat? Emacs? How about the F-35 Joint Strike Fighter or the U.S Navy’s Littoral Combat Ship. Well the last two aren’t technically open source, but according to the Washington post, their system designs are available … if you have the right hacking skills.
From a U.S. defense perspective this opens the horrifying prospect of combined cyber-kinetic attacks. i.e., the defensives systems or sensors are compromised by cyber-attack immediately preceding the kinetic portion (when the metal is inbound.) Or even non-kinetic attacks that result in physical damage (like Stux.)
Exposed system designs or software could diminish the system’s ability to perform or defend itself. How would the DoD know which of the exposed system information leads to detected weaknesses or vulnerabilities … or working exploits?
The key takeaway for me from the Post’s article and the DoD's Defense Science Board's review on Resilient Military Systems CyberThreat can be summed in this quote:
“While DoD takes great care to secure the use and operation of the “hardware” of its weapon systems, the same level of resource and attention is not spent on the complex network of information technology (IT) systems that are used to support and operate those weapons or critical IT capabilities embedded within them.”
+1. Agree. Attack graphs can be complex. They are the set of steps (modeled or actual) that a hacker could take to compromise or access some off-limit asset. They are complex because they can cross boundaries: It’s not just a network or system problem; It’s not just a human problem. Attack-paths can traverse the intersections and trust-boundaries between people, organizations, networks, responsibilities, web applications and security systems. Big interconnected organizations (like DoD or defense contractors) have lots of connections and partners that skilled attackers can exploit.
- Attack-surface calculations should account for the number and types of these connections (trust-boundaries.)
- Protect the jewels: defend first what is most important. Some times this is obvious (like a source code tree) other times it may be less obvious (engineering docs on system tradeoffs or test results.) Every company has jewels: designs, important applications, people’s identity. You have to know what is most important – and work outward from that.
- Risk analysis: factor the down-stream impact of any incident-based risk analysis. Consider attack-graph/security intelligence tools that allow you to understand and project the impact – and hacker motivation – of security incidents. If you see incident activity down a known attack-path towards the jewels – then prioritize this higher than a similar incident on machines not on known paths. Or if you see malicious activity on a power subsystem AND the backup subsystem then it might be more than coincidence.
- Don’t trust the model. Test, test. Consider automated pentest tools to extend frequency and the reach of your live pentests. You goal is to detect new potential attack-path connections before the bad guys.
So to open the old debate - what’s more secure: open source or closed source? For the F-35 and other systems on the list, I hope we never have to actually find out.
Andy Rappaport, Chief Architect.