The Software Assurance Forum for Excellence in Code (SAFECode) engaged with developers at the Black Hat Technical Security Conference yesterday in a brainstorming session to clarify a vision for software security over the next decade.
More than 50 Black Hat attendees participated in the session. SAFECode Members include Adobe Systems, EMC, Juniper Networks, Microsoft, Nokia, SAP AG and Symantec.
The No. 1 issue was education and training, said Steve Lipner, senior director of security engineering strategy at Microsoft and SAFECode board member. The discussion focused on how to get new graduates and entry-level developers to be prepared to write secure code, or even be aware of the need to write secure code, he observed.
Some specific suggestions included adding software security classes to university curricula; getting universities to “push back” against employers that are more interested in applicants that know about new technologies but might not be able to create secure code; requiring developers to have security certifications to write code; and establishing a mindset for secure development.
“I don’t see this as very realistic,” said Rex Black, president of Rex Black Consulting, a security group. “Academics telling practitioners how to do their job is not something that has traditionally gone down well in software engineering. What would be preferable, in my mind, would be for software and systems vendors to have the same kind of legal liability that vendors of other products—e.g., cars, airplanes, microwave ovens—have for the quality and safety of their products.”
One attendee said that the security needs are different everywhere, and different companies have different requirements that can’t be covered in a course. Lipner said that most members on the panel have a policy in place that includes security requirements for developers.
“This would be a good thing, as would requiring certifications to test code. What’s important here is that the job market start to see value in such certifications,” Black said.
The rest of the discussion had no single point of emphasis, but there was a lot of focus on secure Web (rather than client) application development, he said.
On Web application security, attendees asked panelists how they will fix cross-site scripting, saying that it is a design flaw and that there is no way to fix it without “breaking the Web.” Another attendee suggested that developers bar older, “insecure” browsers from their websites.
Other ideas included introducing a new model for Web pages that would be more secure and transitioned in over a 10-year period; barring browsers from carrying log-in information from tab to tab; and whether more of a reliance on mobile client-side applications would improve things.
More general suggestions were security for “plug and play;” improving upon API design; encouraging the widespread adoption of software assurance processes; taking steps to eliminate injection attack vulnerabilities from applications; and establishing borders between the application and operating system.
Software should come digitally signed, telling you what it will do and access, an attendee suggested. Another believed that applications should include behavior profiles with information for the user and the operating system.
The SAFECode panelists were also told to effectively change consumer behavior by telling customers about the benefits of the security features in their products and what could happen when they make risky decisions. Panelists raised the question of whether software makers were better off telling the user the consequences of what they are doing, or whether they want customers to trust the company to make the decisions.
“As I mentioned above, I think the better way to handle this is to make software and system vendors responsible for the quality and security of their systems,” Black said.
Some attention was paid on how to “kill” the economics of vulnerability exploitation, which can be a very lucrative criminal act. A more radical suggestion from an attendee was for the security community to work together with society to “make our data worthless” by “getting rid of” social security numbers and credit card numbers entirely.
SAFECode will filter the suggestions to its technical committees to work on security white papers and to establish best practices, Lipner said. The papers are made public, and developers can apply the ideas should they choose, he added. “We’re not asking them to tell us, but what I do know what is happening is sharing of best practices among SAFECode members.”
“All of us have learned about techniques, tools and training processes from each other.”
