By Dan Cornell and Michael McBryde
There has been a lot of hubbub over the past day and a half about insurgents intercepting video feeds from US unmanned drone aircraft. Wired has covered this story pretty extensively:
Basically, a system was designed quickly, without security as a requirement, for a very limited number of Predator drones used by Special Operations. Then the drones became much more popular, the system was adopted for much wider use, and the system’s scope was increased to include a majority of the jets flown in the U.S. military. Net result? Iraqi insurgents can view or potentially jam video feeds from the majority of U.S. aircraft using materials they could get at Radio Shack. Yikes!
So let’s review:
· A system was designed and implemented quickly – with limited scope.
· Obscurity was the main security protection, and general system security was not a requirement.
· The usage and utility of the system increased rapidly – so rapidly that decision-makers ignored security reviewers warning of the vulnerability.
· Gaping security holes were found by 3rd parties and exploited.
· Fixing the problem will not be cheap and will likely result in material operational downtime
Strange … I’ve heard this before. This isn’t a case study specific to the military – this is something we see all the time with both public and private sector organizations. Business (or “mission,” in this case) requirements for new features and functions are favored over addressing known system weaknesses. This decision gets made once. And then again. And then again.
Vulnerability management and security remediation are ongoing tasks in the development of any system. Ignoring vulnerabilities and focusing exclusively on new features pretty much guarantees that you will get hit eventually.
Contact us if you would like help remediating those pesky, lingering, known vulnerabilities in your software systems.
dan _at_ denimgroup.com