This week I attended the MIL OSS-LANT (Military Open Source Software) working group. I enjoyed having my brain stretched a bit as I thought about the major transitions we have made in the past decade.
Twenty years ago almost everything that DoD purchased was pure GOTS (Government off the Shelf). Operators gave their tough specifications to the engineers and systems were built in government laboratories – completely locked down. It might be contracted out to Industry to actually build the production models, but there weren’t a lot of options in the final design. Think AEGIS.
It soon became glaringly apparent that this approach wouldn’t work in a Moore’s Law environment of constantly improving high-end IT equipment. Rather than be perpetually BEHIND and irresponsibly BROKE, government adopted more COTS (commercial off the shelf) solutions. These pieces were integrated into existing designs and saved the government a bunch of R&D dollars!
Now here comes Open Source Software (OSS). The biggest and most fundamental change is the “community of interest” involvement in making it better. Most of us have seen open source apps and how they can improve when community attention comes to them. When savvy developers in a community of interest start working together, applications continuously improve. Including the “interested and educated crowd” into the solution breaks all the old barriers. Collaboration is the key here.
No matter how you procure your code, due-diligence, governance and configuration control are key components of any deployment of an IT solution. Most of the IA scanning tools out there cannot identify the layered cross-connects of vulnerabilities (i.e.: A is safe, and B is save, but A&B are not safe together). Being able to perform meaningful monitoring at the application layer is a must when considering a kludge of GOTS/COTS/OSS components. Anyone can run a scanner tool on the network. Making meaningful conclusions from the deluge of returned information is the hard part. Compound vulnerabilities are the hardest ones to detect and generally require human analysis to see it. That’s something that just doesn’t scale well.
DoD has been tiptoeing in the OSS world for a few years now. There are plenty of successful pilots that have used OSS to solve tough DoD problems. Today’s tough fiscal constraints might be just the push OSS solutions need to move forward into the real warfighter domain. The major paradigm shift needed to adopt more OSS solutions is a proven track record of working, secure and evolving DoD solutions at greatly reduced cost. Moving DoD from a “NEED TO KNOW” mind-set to a “NEED TO COLLABORATE” mind-set is not easy.
What would greatly help these OSS providers is a “Rosetta-Stone” to translate the many (MANY) DoD policies that need to be met before OSS can be used on a specific project. If I were on the team trying to make this happen, I would concentrate hard on documenting (in warfighter-speak terms) the bottom line – the return on investment. Focusing on this bottom line can help push good policies. But however it is done I hope it is done quick, the old days of Educated Obfuscation just do not work anymore.