On the heels of the release yesterday of information about the top 25 programming errors that lead to Web security problems like SQL injection attacks and cross-site scripting, InternetNews.com has learned that the state of New York plans to implement procurement contracts that include language demanding application security.
That language was co-developed by Will Pelgrin, director of the state’s office of cyber security and critical infrastructure coordination, and Jim Routh, chief information security officer of Depository Trust and Clearing, for inclusion in software contracts. It is available here.
The language requires vendors to conduct an analysis of the top 25 programming errors, and
document in writing that they have been mitigated, among other things.
When implemented, the language will let organizations planning to build applications either in-house or via outsourcing ensure they get secure applications.
Pelgrin told InternetNews.com the document containing the language is being sent to all information security officers in the state for review and he will meet with them on February 10 to discuss its implementation.
“I think the Top 25 Errors list is an incredibly powerful tool to help bring us to a more secure layer of software within and beyond government,” he said.
The list of programming errors, jointly agreed upon by more than 30 U.S.
and international cyber security organizations, grew out of the Common Weakness Enumeration (CWE) project launched by MITRE, a not-for-profit organization chartered to work in the public interest in 2005.
Funding for work on the Top 25 list, which is available here, came from the Department of Homeland Security’s National Cyber Security Division, and MITRE and the SANS (SysAdmin, Audit, Network, Security) Institute collaborated on the project to put it together.
What not to do
MITRE launched the CWE Project to provide what project leader and MITRE principal engineer Robert Martin described to InternetNews.com as a dictionary of all the things that software developers, designers and architects should pay attention to if they want to ensure their software is secure.
“We felt that no one had done a good job explaining to developers what not to do when writing code,” Martin said. “When we teach people to do software programming, we don’t teach them to make the products secure; it’s not taught in any college course.”
The CWE project has listed 750 programming errors, and the Top 25 list is a subset of that. “Anybody who wanted to start addressing application security was faced with the daunting task of what to do first,” Martin said.
“The Top 25 was created so that people can go after the most dangerous problems first and we can lead in to the rest over time.”
The lack of application security is one of the major causes of data breaches. In the wake of major credit card data breaches such as the one at TJX, the PCI Security Standards Council, which issues, maintains and enforces the payment card industry security standards, has begun requiring merchants to either conduct application code reviews or install Web application firewalls.
Poorly written applications also create openings for SQL injection attacks and cross-site scripting, two of the most common attacks by hackers.
Error CWE-116, improper encoding or escaping of output, is at the root of most injection-based attacks, according to the Top 25 list of programming errors.
In addition to planning to include security-specific language in procurement contracts, New York State is attacking the problem of insecure programming through education. Its CSO, Pelgrin, said it has developed a cyber academy with top universities and colleges in the state to train students in the basics of secure application development.
“That’s one of the most essential ways we can improve programming because we’ll have changed the culture,” he said. “If security isn’t a component of the application development you learned in school, you’re less likely to use it when you enter the workforce than if you had learned it from the beginning.”
The first class will graduate in 2009 or 2010, Pelgrin said, but the effort will not stop after they have graduated.
“We’re going all the way to periodically assessing whether or not individuals are implementing what they’ve been taught.”
