Security in software needs careful scrutiny
Jack Danahy
This isn’t news.
In 500 BC, the famous Chinese military strategist and philosopher Sun Tzu highlighted the importance, care and impact of spies, raising them to an elevated status in his battle planning. He wrote, "Hence it is only the enlightened ruler and the wise general who will use the highest intelligence of the army for purposes of spying and thereby they achieve great results."
In modern times, there is a new asset in our national defense from whom discretion and trustworthiness is equally critical. It’s an asset that has complete access to virtually every piece of data relating to personnel, plans and programs. This new asset is software.
However, a new threat has arisen because software -- unlike trusted government employees -- is subject to no comparable background checks. In spite of its ubiquitous access to data, and its natural underlying complexity, there exists no consistent or mandated requirement for the certification of software security before systems are deployed and entrusted with private, instructive or mission-critical data.
This exposure screams for attention, but the enormity of our reliance on software, and the daunting scope of attempting to vet these programs for their vulnerabilities, in many cases drives us simply to ignore the problem. While we are busily ignoring them, the risks persist and, in fact, grow daily.
Software arrives on duty with a built-in capacity for corruption that has been intentionally or accidentally woven into its source code -- its "Application DNA," if you will. The potential exposure that arises from these risks is mind-boggling. Personal information on roughly 33,000 airmen and officers, terabytes of data from the NIPRNet and critical mission planning applications all have been revealed through unintentional and inappropriate release of data which was served up by software, via networks, applications or even lost or stolen laptops.
Sometimes data is supposed to be protected by encryption; sometimes by limiting network access to the systems or files; and sometimes the applications are never intended to store anything considered confidential.
How these security requirements are met necessitates an understanding of how the systems, access control or the application is written, which quickly brings the problem back to the source code.
During the past 15 years, the problem has increased more quickly than any could have predicted. The introduction of pervasive internetworking has created seemingly limitless paths to applications, paths which increase in number and intimacy every day, through service-oriented architectures, Web-enabling technologies and inter-organizational information sharing. The sources of applications also have changed drastically. Now, they include outsourced, off-shored applications, open-source, anonymous development, and dated, misunderstood legacy applications reworked to serve a much broader and less transparent audience.
The sheer number of applications is also growing at an unprecedented rate. The flexibility of new language platforms, the rise of component-based frameworks and the common requirement of tailored functionality make applications much easier to write and much more likely to change over time.
All of these trends point to a clear mandate for a consistent process for articulating and evaluating the required security in software. Without doing so, it is impossible even to begin to measure the adequacy of protection, the potential corruptibility of systems and the corresponding level of mission risk.
This process needs to cover all software -- new and old -- and to assign responsibility and accountability in the same way they have been managed for other critical components.
The first security advancement that must be made is in the area of requirements. While everyone instinctively understands that software needs to be secure, the indefiniteness of that description precludes any sort of consistent interpretation in its execution. Organizations must define requirements for limiting access to systems and data, and then ensure that those requirements are implemented in the applications that fetch and present that data. This includes understanding new accesses to legacy systems, existing systems as they are updated and maintained, and the development of systems from scratch.
There must be similar diligence focused on the predictability of the applications behavior, as organizations accept the eventual likelihood and execution of attacks against them. These requirements must be captured in project and contract requirements, and must be made a priority through certification and user acceptance terms.
This leads to a second area, improvements in assessments. Functional testing and lightweight reviews have proven to be inadequate to the challenge of ensuring the delivery and deployment of secure systems. As a result, it is necessary to create a more uniform and consistent framework for the appropriate assessment technologies.
Understanding and analyzing source code for malicious code and vulnerabilities plays a central role in this. In much the way that the House Committee on Oversight and Government Reform has created an overall security report card across the federal government, a system for understanding and weighting the potential impact of vulnerable software must be created to support investment in processes that better highlight and weigh the risks relative to the information being presented.
The fact that these threats exist, and that we are regularly seeing the impact of their exploitation, leads to the third and most controversial components: regulation and investment. On their own, forward-thinking organizations already are creating programs to perform these types of risk analyses, base-lining their systems to better understand necessary remediation investment.
In the commercial sector, regulations and standards like PCI, CA 1386 and Sarbanes-Oxley are encouraging investment in better security awareness at this level through the threat of fines and exposure. It is necessary for our nation to both demand and fund new diligence for any system that is housing critical, private or mission-sensitive information. New regulations are not enough. They must be paired with a recognition that this problem has been exacerbated during the last 40 years, and that it cannot simply be mandated out of existence by flogging today’s system owners.
It is undeniable that our nation faces a pervasive and growing threat from our unknowing reliance on applications that may well be flawed. Ours is the most capable, advanced and flexible fighting force in the world. In support of that force, there has been a massive investment in software and systems development. Unfortunately, our reliance on that infrastructure makes our missions increasingly vulnerable to problems with these critical components.
As with any threat, we need a compensating mechanism, and we should look to the past. When forced to trust people with sensitive data, we first took the time to understand the history and potential weaknesses of those individuals. Now, without delay, we must take responsibility to create the same level of confidence in our software. Otherwise, we are offering up much to our adversaries’ enlightened generals and wise rulers.
Jack Danahy is founder and chief technology officer of Ounce Labs, Inc. www.ouncelabs.com
- Add your comment
- trackback url: http://www.gsnmagazine.com/cms/trackback/128-1
