The National Cyber Security Summit last week that brought the Department of Homeland Security to the table with the Business Software Alliance, the Information Technology Association of America, TechNet and the U.S. Chamber of Commerce yielded a good deal of rhetoric but also some interesting future directions for developing more secure software.
At the root of the cybersecurity problem-besides the malevolent nature of some humans-- is the lack of secure code and coding practices. One of the five task forces formed at the summit -- Security Across the Software Development Life Cycle-is charged with making recommendations regarding the engineering, deployment and subsequent management (patching) of software.
Ron Moritz, chief security strategist at Computer Associates and one of the chairs of the software lifecycle task force, said that one of the ideas for improving the quality of software would be to license software engineers in the same way the medical practitioners, lawyers or CPAs are governed by various officially sanctioned bodies.
"CPAs are not licensed by government, and the bar association is organized by states-we have to look at which is most applicable," Moritz said. "We could recommend that [software engineers] be regulated by the government, but the government may not favor the idea. It could be the government would want to license people who are working on national infrastructure."
The governance of CPAs is a good model. CPAs have specialized degrees from accredited educational institutions. The American Institute of Certified Public Accountants (AICPA), for example, is a national, professional association that works with state CPA organizations. It has a code of professional conduct, peer review and ethics enforcement, a national accreditation commission, ongoing education programs, and audit and attest standards. One of the main AICPA goals is to seek "the highest possible level of uniform certification and licensing standards and promote and protect the CPA designation." The legal and medical professions have similar organizations.
Of course, we all know about the recent accounting scandals --WorldCom, Health South, Enron, Adelphia, Tyco, and many others-have undermined the notion that AICPA or any other organization can be credible and protect the interests of its customers. But the acts of a few too many individuals or companies doesn't mean that an organization like AICPA or an equivalent organization for software engineers specializing in critical infrastructure systems (which could be defined as every network-attached device on the planet) isn't an important body for establishing standards and practices.
The software industry, particularly as it relates to security, has numerous organizations-such as the CERT Coordination Center, SANS Institute, Computer Security Institute--but totally lacks consistent education, ethic standards or standards and practices of the more regulated accounting, medical and legal professions.
"I think that some level of competence and professionalism is required in order to do these jobs properly and that that level is rarely found today across the necessary spectrum of jobs involved," said Fred Cohen, chairman of the education subgroup of the Software Development Life Cycle task force and a principle security analyst with the Burton Group. "What form the certification of competence and professionalism take is something we will be discussing. I have never been a fan of these things in the sense of taking a test to get approved, but on the other hand, I have degrees which represent certification by my schools that I earned the degree. The schools are accredited and as a result there is a general level of competence that we can come to believe exists from all of their graduates. This would be a good starting point."
Given its software engineers, or at least individuals with some technical knowledge, who are taking advantage of software vulnerabilities, Moritz believes that more of a focus on integrating security more deeply in software engineering curriculums and on ethical programming. "Software engineers are lucky if they have one day a year of ethics training," Moritz said. "Teaching security separate from software engineering, and ethics separately as well, is not sufficient."
Even if the task force reaches consensus on formally licensing software engineers with security or other specialties next year, the issue over who manages the process, how it's funded, or what involvement from government and at what levels could take years to play out.
Even if licensing is mandated, neither professional associations nor educational systems have yet to provide definitive, continually updated standards and practices for secure software engineering.
Some software developers collect certifications, but that doesn't mean they can actually perform with live ammunition. In addition, how long would it take to build an army of security practitioners who have taken the required courses, passed the tests, and completed an "internship" to qualify for a job? What kind of cost would these highly qualified practitioners add to an already tight IT budget?
Creating a more universal system in the U.S. or even internationally for certifying and licensing software engineers-- like medical practitioners or accountants--is a necessary step for turning out better programmers, not just for security issues, but any major software discipline. But, without improved coding practices and techniques for writing more secure code, the licenses and certifications won't be much help.
Moritz believes that a huge barrier is the existing population of software developers. "Some of them have been coding for 25 years. If they have been programming a certain way for years, it's difficult to change their methods, even if they are defective. We haven't taught kids how to create secure code either. There is some science that is valid for producing more secure code, but it's an area that has not been focus of computer science research."
He suggests that the task force may recommend funding research in certain areas that aren't mature enough. "There is some fundamental research in academia and at companies like Microsoft, for example, on writing secure software. But there isn't a sufficient body of knowledge and trained academicians in engineering schools." It's safe to say no matter how much training and improvement is applied to coding techniques, defects will persist. If code cannot be guaranteed secure coming from the programmer's workbench, the next line of defense is measuring and testing code in the target environment.
Both Moritz and Cohen are skeptical that the security aspect of code can be easily measured. "The first step is to identify what the properties are and to put metrics on achievement of those properties. This calls for research because we don't even know what many of the right properties are yet," Cohen said. "We have metrics for some things like reliability and availability, but not for others such as code complexity as opposed to problem complexity. We can pretty easily certify that programs don't have specific and widely known vulnerabilities, but this is not really much of a guarantee of their ability to withstand the broad range of attacks they may face in use. In addition, properties of systems are far harder because two secure components can be put together so as to form an insecure system. Composition is a very hard problem where some progress has been made for some properties. But there is along way to go."
Moritz said that the task force will make some recommendations to the sponsoring organizations at the beginning of March. "It's a start, the vision is going to be changing rapidly, but we need to get started," Moritz said. The various cybersecurity task forces have taken on some large scale problems, with scientific, cultural, financial and political dimensions. Like Moritz says, you have to get started. The question over the next year or two is whether we will end up with more position papers and strategies or real solutions. A good first step would be funding research and educational initiatives to build the curriculum and discover coding practices that will minimize the vulnerabilities in the next generation of software.
You can write to me at email@example.com. If you're looking for my commentaries on other IT topics, check the archives.