March 21, 2008

The Foreign Software Threat and Enterprise Architecture


Enterprise architecture is the developer and keeper of the organization's systems inventory, and it is the champion for system interoperability, integration, standardization, and modernization. Of course, all this within the framework of a secure information infrastructure.

What happens though when the security of systems is threatened from the inside—that is through malicious code itself?

Imagine a terrorist sleeper cell embedded in our country that can be activated at any time to cause destruction and havoc. So too, hidden malicious software code can be embedded in applications developed overseas or even by homegrown adversaries. And this code can be launched or used as a back door to disable our vital military systems for communications, weapons, navigation, and so on.

Military Information Technology, April 2008, reports that “DoD combats risks of a ‘mole’ in software written in other nations.”

According to a March 2007 report by the Center for Strategic and International Studies (CSIS), “malicious code, cyber-attacks, and espionage [are cited] as top threats facing the DoD and defense industry today, resulting primarily from software developed overseas, and to a lesser extent, from the global use of commercial software.”

Further, “the CSIS report noted that the number of U.S. companies outsourcing software development overseas had grown 25% from 2003 to 2006.”

“In September [2007], the Defense Science Board Task Force…came to similar conclusions” about foreign software exploitation. It states: “'while COTS development environments are more porous to attack than those of DoD custom development environments,’ subversion of the latter is more like to achieve adversarial objectives.”

Custom code does not get the same scrutiny as commercial code (especially open source) and so it is more vulnerable to exploitation via back doors or malicious code written into the software.

Dan Geer, the chief scientist and vice president of Verdasys, a security software firm, states: “Instead of trying to put a mole in the CIA, they try to put a mole in software.”

While “the technology industry has made progress at finding which writing patterns leave software vulnerable to inadvertent bugs…we don’t have as good a handle on what malicious programmers introduce.”

So how can we architect safer software?

  1. Scan—conduct vulnerability scans of software to identify known vulnerabilities.
  2. Patch—when vulnerabilities are detected, patch them quickly.
  3. Inform—have developers disclose what tools they are using and how they developed the code.
  4. Test—embed security testing and analysis in all phases of the systems development life cycle.
  5. Measure—develop metrics for software assurance so it can be rated and improved on.

Of course, we also need to ensure that developers are security-cleared to work on the software being developed or customized and that we layer our defenses and create redundant systems so that we mitigate risk from any single particular entry point.


Share/Save/Bookmark

No comments: