Vulnerabilities / Threats
3/6/2013
00:42 AM
Connect Directly
RSS
E-Mail
50%
50%

Secure Development: Must-Do Or Money Pit?

At the RSA Conference, two software security specialists debate over whether the cost of secure programming is too much for most companies, recommending simple steps to improve development

SAN FRANCISCO -- RSA CONFERENCE 2013 -- The common wisdom among security experts is that every company should kick off a development program to teach secure programming, find vulnerabilities in their software, and include security at the design phase.

RSA Conference 2013
Click here for more articles.

Yet that wisdom was questioned at the RSA Conference last week during a panel discussion that pitted Brad Arkin, Adobe's senior director of product security, against John Viega, executive vice president of products, strategy, and services at SilverSky, a cloud security provider. One point argued by Viega: Companies like Adobe and Microsoft can handle the costs of a secure development process, but smaller companies cannot necessarily foot the bill.

"I know dozens and dozens of companies that look at what they are doing and say, 'Are you kidding me? This will put me out of business because I would spend 90 percent of my time securing software, and I would never actually do anything,'" Viega said.

The panel discussion turned comical at times, as the two debated the merits of implementing secure development practices, with Viega mostly arguing against secure programming as he played the role of devil's advocate.

Still, the pair of software-security professionals agreed more often than not. Viega is the author of number of books on secure programming, including Beautiful Security and the Secure Programming Cookbook. Arkin has helped Adobe create its secure product development program, which includes threat assessment, developer training, iterative testing, and incident response. All software developers should invest in such a program to make their software better, Arkin said.

"The investment that you make up-front is important," he said. "You want to build a good foundation so that you have a chance to be secure."

The two security experts agreed -- mostly -- on five steps that companies can take to make their software more secured.

1. If tricky, code it once.
While code reuse is a general rule in software development, it's especially important when writing code for a security feature. Security features need to be done right; by focusing efforts on where it matters, development teams can write the security code ince and then move on, Arkin said.

[A panel at the RSA Conference showed how the DevOps paradigm could actually provide a huge step forward for security teams seeking to insert themselves into the development process. See Using DevOps To Upgrade Application Security.]

"Any time something is tricky for security, you want to bring that into a central place, do it right once, and then give that out for everyone to use in their code base," Arkin said. "That way, we don't have to keep redoing that dangerous section of code."

2. Review all code once, then only check new code.
Code audits are expensive. Conducting frequent audits can quickly push up development costs. Instead, companies should analyze their code once, and then do iterative checks whenever a developer submits his code.

In addition, some companies may find a better return on investment if they focus on dynamic -- "black box" -- testing first, and static code analysis later, Viega argued.

"For software-as-a-service vendors, [code review] is vastly less important because you are not putting software in the bad guys' hands," he said. "Instead, you should focus on the same sort of black-box testing as the bad guys."

3. Use developer mitigations.
When Adobe created Reader 10, it included a number of security features -- such as a sandbox, address space layout randomization (ASLR), and data-execution prevention (DEP) -- that made that version of the program much more difficult to exploit. Adobe did not see an in-the-wild exploitation of that version of reader for more than 30 months, Arkin said.

"The bad guys all understood that it had become too hard, it really raised the cost to exploit writers," he said.

Companies should take a similar tack and use the software security features that are designed to make exploiting software more difficult.

4. Train developers, but ...
Developers should be required to go to classes on secure programming, but Arkin and Viega disagreed on who should go. Microsoft and Adobe both train their developers to program securely. Viega argued that, as a way to cut costs and reduce productivity downtime, companies should train only those developers who show an interest in secure programming.

"You should only spend money on training the people who want to do this," he said, "because the reality is that those are the only people that are going to make a difference."

5. Regulations don't help.
While Viega attempted to make a case for the government serving a role in software development, Arkin immediately went on the offensive. Regulations that impact software development -- such as the Payment Card Industry's standards -- have led to no measurable changes, Arkin said.

"Thank God PCI regulations came out, because now we will never have another credit-card compromise," he joked.

Government regulations would fare no better, he said.

"Any regulation that tries to legislate software development is so woefully out of date that, by the time it is printed, it's just a waste of time," Arkin said.

Instead, companies and consumers should demand more secure software, he said. The inclusion of security requirements in software contracts has started to lead to greater awareness of secure development practices.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
MROBINSON000
50%
50%
MROBINSON000,
User Rank: Apprentice
3/13/2013 | 9:11:23 AM
re: Secure Development: Must-Do Or Money Pit?
For a better understanding of security challenges and how to overcome security threats, I recommend attending the free webinar Designing Secure Embedded Software http://bit.ly/XUooTg
Justin Rocket
50%
50%
Justin Rocket,
User Rank: Apprentice
3/6/2013 | 9:38:30 PM
re: Secure Development: Must-Do Or Money Pit?
"You should only spend money on training the people who want to do this," he said, "because the reality is that those are the only people that are going to make a difference."- I agree with this statement the same way that I agree with the statement, "You should only spend money on training structured programming to-the people who want to do structured programming."-- You should fire the rest.- "Security features need to be done right; by focusing efforts on where it matters, development teams can write the security code ince and then move on"- I agree with this.- However, the greatest security gains in software engineering come from architecture, not writing lines of code.- Smart and secure software architecture expands opportunities for code re-use.- "companies should analyze their code once, and then do iterative checks whenever a developer submits his code".- This is true only if your code has no side effects.- But, to know this, you need to emphasize good secure code writing (both in the original code and in the deltas)-in the first place.- "you should focus on the same sort of black-box testing as the bad guys."- That's true only if you've got as many black box testers as the bad guys.- You don't.--I am, however, glad that they were against government regulations.- Government regulations make us less secure.- They exist to protect the business, not it's clients.- The business needs to meet only the regulations - which may not make it's product actually secure (particularly since large businesses can influence politicians to relaxe regulations).
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-2963
Published: 2014-07-10
Multiple cross-site scripting (XSS) vulnerabilities in group/control_panel/manage in Liferay Portal 6.1.2 CE GA3, 6.1.X EE, and 6.2.X EE allow remote attackers to inject arbitrary web script or HTML via the (1) _2_firstName, (2) _2_lastName, or (3) _2_middleName parameter.

CVE-2014-3310
Published: 2014-07-10
The File Transfer feature in WebEx Meetings Client in Cisco WebEx Meetings Server and WebEx Meeting Center does not verify that a requested file was an offered file, which allows remote attackers to read arbitrary files via a modified request, aka Bug IDs CSCup62442 and CSCup58463.

CVE-2014-3311
Published: 2014-07-10
Heap-based buffer overflow in the file-sharing feature in WebEx Meetings Client in Cisco WebEx Meetings Server and WebEx Meeting Center allows remote attackers to execute arbitrary code via crafted data, aka Bug IDs CSCup62463 and CSCup58467.

CVE-2014-3315
Published: 2014-07-10
Cross-site scripting (XSS) vulnerability in viewfilecontents.do in the Dialed Number Analyzer (DNA) component in Cisco Unified Communications Manager allows remote attackers to inject arbitrary web script or HTML via an unspecified parameter, aka Bug ID CSCup76308.

CVE-2014-3316
Published: 2014-07-10
The Multiple Analyzer in the Dialed Number Analyzer (DNA) component in Cisco Unified Communications Manager allows remote authenticated users to bypass intended upload restrictions via a crafted parameter, aka Bug ID CSCup76297.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Marilyn Cohodas and her guests look at the evolving nature of the relationship between CIO and CSO.