Microsoft's Steve Lipner, who was a major proponent of the need for a secure development methodology, talks about the successes of Microsoft's push--and the costs.
When Microsoft announced the Trustworthy Computing Initiative more than a decade ago, it seemed little more than a marketing push. Yet the company managed to create a sustained security program aimed at locking down its software. A key component of the initiative is the Secure Development Lifecycle (SDL), an iterative approach to programming that helps identify and resolve security weaknesses.
Steven Lipner, the partner director of program management for Microsoft's Trustworthy Computing, had once held the belief that the computer security could be solved in a provable way. After a decade of working on Microsoft security, Lipner is the first to admit his former naivete. Dark Reading caught up with Lipner before the coming RSA Conference and talked about the success of the SDL and its costs.
DR: In what ways has the SDL paid off for Microsoft and its code base? What sort of metrics does Microsoft look at to gauge success or failure? Lipner: In terms of measuring success, we look at a couple things. One of them is customer confidence--do people believe that we are in fact doing the right thing in developing software securely? And on that front, [a decade ago] Microsoft was not in the best position from a security perspective, whereas today we are in a much better position. So from that perspective, we view the initiative as successful.
Internally, we look at numbers, we look at metrics. We look at how many vulnerabilities, how many issues we have to fix. And that includes severity--how much impact do the vulnerabilities have on customers? We also look at the exploitability index. We have the exploitability index out for more than 18 months, and we are looking at that to say, OK, if there are vulnerabilities out there and they are discovered, how hard is it to exploit them and do harm to our customers?
How can companies find and fix vulnerabilities before they lead to a breach? Better yet, how can software developers identify flaws in their applications before the new software is ever deployed? In this report, Eliminating Vulnerabilities In Enterprise Software, Dark Reading offers a look at some tips and tricks for software development and vulnerability assessment. (Free registration required.)
Published: 2014-11-21 Multiple cross-site request forgery (CSRF) vulnerabilities in Huawei HiLink E3276 and E3236 TCPU before V200R002B470D13SP00C00 and WebUI before V100R007B100D03SP01C03, E5180s-22 before 21.270.21.00.00, and E586Bs-2 before 21.322.10.00.889 allow remote attackers to hijack the authentication of users ...
Published: 2014-11-21 Multiple SQL injection vulnerabilities in Dolibarr ERP/CRM before 3.6.1 allow remote authenticated users to execute arbitrary SQL commands via the (1) contactid parameter in an addcontact action, (2) ligne parameter in a swapstatut action, or (3) project_ref parameter to projet/tasks/contact.php; (4...
Published: 2014-11-21 SQL injection vulnerability in Open-Xchange (OX) AppSuite before 7.4.2-rev36 and 7.6.x before 7.6.0-rev23 allows remote authenticated users to execute arbitrary SQL commands via a crafted jslob API call.
Published: 2014-11-21 The REXML parser in Ruby 1.9.x before 1.9.3 patchlevel 551, 2.0.x before 2.0.0 patchlevel 598, and 2.1.x before 2.1.5 allows remote attackers to cause a denial of service (CPU and memory consumption) a crafted XML document containing an empty string in an entity that is used in a large number of nes...
Published: 2014-11-21 Cross-site scripting (XSS) vulnerability in Guests/Boots in AdminCP in Moxi9 PHPFox before 4 Beta allows remote attackers to inject arbitrary web script or HTML via the User-Agent header.