LOGIN | REGISTER NOW | SUBSCRIBE
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
ASP.NET MVC 2 Ships
ASP.NET MVC 2 has shipped.
03/12/2010 10:26 AM EST

Microsoft plans 'open' Silverlight analytics framework
Microsoft is going to announce a multipurpose analytics framework for Silverlight at MIX.
03/11/2010 09:51 AM EST

About CSS processing
Two sites that lead to a startling CSS conclusion.
03/10/2010 02:29 AM EST

 

Events calendar tab
SHARE
3/14/2010 to 3/18/2010
Seattle, Wa.
SHARE

Cloud Connect
3/15/2010 to 3/18/2010
Santa Clara, Calif.
TechWeb

Microsoft MIX10
3/15/2010 to 3/17/2010
Las Vegas
Microsoft

SharePointPro Summit & Expo
3/16/2010 to 3/19/2010
Las Vegas
Penton Media

TheServerSide Java Symposium
3/17/2010 to 3/19/2010
Las Vegas
TechTarget


 
print Printable version 
Most Read Latest News Blog Resources
Even with its success, .NET causes some consternation
Despite its popularity, the developer community believes that .NET isn't being fully serve...

Guest View: The half-agile path leads nowhere
While businesses are taking on agile and adopting its practices, an incomplete implementat...

Gomez delivers cross-browser performance monitoring
Focusing on the wide variety of browsers for both PCs and mobile devices, Gomez provides a...

Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter

What Can Be Done About Software Security?


Good project management, enterprisewide commitment, ongiong training seen as crucial

By David Worthington
July 1, 2007 — 
Security flaws darken the sky over every company that encounters them. The consequences can be so severe that it is remarkable flaws continue to persist after years of stakeholders enduring the expense, pain and risks associated with insecurity. But just as a spate of failures of cast-iron bridges in the early years of Victoria’s reign caused the British government to regulate railroad construction, so too may failures in software security lead to future government controls on how code is written.

Gunter Ollmann, director of security strategy for IBM’s Internet Security Systems division, reported in May 2007 that ISS researchers had analyzed more than 7,000 publicly disclosed bugs in 2006. Strikingly, Ollmann estimated that the number of new code vulnerabilities could exceed 139,362 per year, increasing the perceived risk of zero-day vulnerabilities exponentially.

Software has transformed into a critical part of our infrastructure, yet its architectural standards are not on par with physical structures such as bridges. Although every situation is different, the experts SD Times interviewed for this story reached consensus on some of the most common underlying factors that beget flaws: Fundamental project management, organizational commitment and training were the most frequently discussed topics among those interviewed.

John Heimann, Oracle’s program director in the global security product group, observed that most companies have not defined standards for secure coding. But management must define standards, explain what they mean to developers, and measure developers on their achievement, he said.

Tight schedules may also lead to lax software security. Rex Black, president and principal consultant of Rex Black Consulting Services, said that schedule pressures drive out a lot of things required to produce quality software. “[Management believes] that pressure is part of getting peak performance out of an organization. There is frustration at the contributor level about constant pressure to meet dates. You can’t be surprised when [developers] don’t deliver fully functional or secure code.”

SPI Dynamics co-founder Caleb Sima remarked that even if management conveyed requirements precisely, another problem is that the person who created those requirements needs to know security. “Product managers deal with customers, not security. There must be a dedicated guy helping the product manager.”

Sima also noted that product managers drive for parity between diagrammed functionality and what is actually written. Unintended functionality, introduced when developers go above and beyond what is expected of them, spawns vulnerabilities. “QA people do not test the extra stuff…this is where security issues come into play,” said Sima.

According to Sima, security must be a companywide process and be integrated into the existing development life cycle, but he acknowledged that coordinating so many actors could be the biggest obstacle. “Security goes into the whole process; it’s one huge cycle and cannot be fixed at one point.”

Roy Stephan, director of security business units at Ashburn, Va.-based systems integrator Intelligent Decisions, recommends rapid prototyping for requirements development to uncover inconsistencies, because the “big build” model makes fixing problems costly and difficult. He surmised that outsourcing has added to the challenge of realizing a cohesive vision for security, citing language and interaction difficulties.

PUTTING YOUR MONEY WHERE YOUR MOUTH IS
Black, Heimann and Sima all agreed that companies that are serious about security must invest more in QA tooling, understand how to use those tools effectively, and retain developers who know how to write secure code with those tools. Whether or not this is done is a matter of organizational priorities, since these activities contribute to operating expenses.

But there is a business case for black-box security testing tools, according to the U.S. Department of Homeland Security. A document published on the department’s Computer Emergency Response Team Web site in December 2005 reported that the 2005 Computer Security Institute/FBI Computer Crime and Security Survey noted that the monetary loss reported by 639 companies in 2005 totaled US$130,104,542.

Oracle’s Heimann explained that companies also require tools because they have to look back to see how well they are doing, even with the correct processes in place. “If you don’t measure something, you can’t manage it,” he pointed out.

Black said that tools can make the process of designing secure software more efficient, noting that “most companies feel that code reviews are good, but [they] say that ‘we don’t have time.’” He added that even if there are pockets of people within companies that understand both quality and security issues, there is no mechanism to propagate their knowledge, because people are not reading one another’s code.

“Even when there are code reviews, one of the things companies don’t tend to invest a lot in is tools,” Black said. He bemoaned that companies focus too much on static analysis and not enough on subtleties even when they make the necessary investment, which leaves bugs that could easily be discovered with tools to be discovered manually.

Intelligent Decisions’ Stephan agreed that QA cannot be seen as an obstacle, and recommends that QA professionals establish best practices that pay special attention to the boundaries, where applications communicate through protocols or between libraries. He advocates peer code reviews as well: “Tools are getting more intelligent and automate the documentation process. In the end, it comes down to programmers documenting code properly, to be quickly patched by a successor” when necessary.

SPI Dynamics’ Sima recommended that tools be embedded in the development life cycle to scan and identify code, and check it against policy.

“Security must be introduced as another [presumed] defect,” he explained, adding, “QA people typically test for functionality and performance—not security.”

TRAINING AND EDUCATION
“Problems arise when you try to implement the technology,” said Black. He concurred with Sima that security testing is not well understood, stating that many QA professionals are domain experts who do not comprehend the underlying technologies. “A modest investment in tools and training can impact security,” he claimed.

Black cautioned against setting immovable deadlines, saying that as the scope of testing work increases, the question to management becomes, “What time and what people?” In his estimation, an understaffed and overworked product group will permit test dates to slip in order to meet a delivery date, and may be forced to skip critical tests.

“Organizations that are sincere about quality and security improvement will make it a priority,” said Black. “I am not suggesting an open-ended commitment, but companies must understand that other things [should] give way to achieving that.”

Education is another part of the equation. Black, Heimann, Sima and Stephan regard educating developers in security as a long-term solution, but Heimann had harsh words for the educational establishment, and Sima doubted that developers even care about security.

Training in secure programming is important because many information security professionals come from a networking background, Stephan remarked. “They understand networks and protocols well but do not understand what is happening inside of an application, and how code is being used and implemented behind the scenes.”

Heimann was critical of the skills of entry-level developers, maintaining that most university computer science programs and training programs do not offer classes in secure coding. “They do good things, but this is basic knowledge that software engineers should have,” he explained, adding that Oracle winds up bearing the expense of teaching programmers how to code securely.

QUALIFIED FACULTY NEEDED
Heimann asserted that most academics do not know how to write secure code, do not want to teach how to do so, and do not want to be called out for not knowing how. Consequently, most developers come out of school without fundamental knowledge of computer security.

Heimann suggested that accreditation standards should drive program changes that would allow qualified faculty to teach secure programming, and suggested that consumers of engineering talent, such as Oracle, ought to work together to influence universities and establish standards for the training and education of developers.

ABET is the recognized accreditor for college and university programs in computing and technology, and shapes the kinds of program offerings that institutions provide, taking its recommendations from the Institute of Electrical and Electronics Engineers.

While he acknowledged the importance of education, SPI Dynamics’ Sima re-emphasized the development life cycle, saying that security cannot be enforced on the backs of developers because they lack any incentive to write secure code. “They just do their job and most of the time won’t go out of the way to do anything better than that. Are you going to get them to care about security? I doubt that.”

In the not-so-distant past, it was widely understood that the phrase “beta test” presumed a certain amount of testing would take place. And tests were often limited to a core group of testers, who would run the unfinished bits for a defined period of time and could be relied upon to file quality bug reports.

Today, many beta tests are open to mass audiences, for better or worse. For example, MSN Live Local and Google’s Gmail were introduced as betas, but many users treated the services as if they were already in production. Whether companies have found a new stealth-marketing ploy, or a way to leverage the distribution power of the Internet, betas are more accessible than ever.

Whereas packaged software adheres to a defined build schedule, software-as-a-service applications—delivered over the Internet—may be slipstreamed with new beta code several times per day, if necessary. There is no shipping of physical media or build announcements involved; it is easier to keep the tester pool up to date.

Stephan claimed that many companies release betas into production, knowing that they can use their patching mechanisms to fix problems later. “Patch management bridges the gap between the problem and the solution by leaving a self-mechanism for updating and securing code after the fact,” he noted. “This is both good and bad: Patching is both a problem and a solution, to the extent it has become a crutch to move deadlines.”

Another one of Stephan’s concerns is code reuse—leveraging other people’s code, which is especially prevalent in open source deployments. He argued that while it may be beneficial to “stand on the shoulders of giants” and use code that has been error-checked and vetted by the market, by incorporating this type of library into a project, one might be introducing vulnerabilities as well.

Stephan recommended that companies work to secure their underlying libraries. “The code-reuse problem is [one of] relying on underlying problems and drivers. Microsoft in particular is attacking this angle.”

Heimann also identified legacy code as a big issue, noting, “Legacy is a problem at Oracle. Our database has been around at least as long as [Microsoft’s] Windows.”

The final thing that Stephan suggested on the code front was randomization. Randomization creates process-specific randomized instruction sets. Stephan explained that through randomizing implementations in the compilation process, one version will not be susceptible to the same exploit as another version of the same product.

For instance, if there is a buffer overflow attack against Server A, it may not take down Server B or C; the domino effect is contained.

END OF SELF-REGULATION?
In the play “Julius Caesar,” Shakespeare pointed out that the fault “is not in our stars, but in ourselves.” Our experts agreed that not all of the blame lies with corporate management: Market trends and consumer buying behavior may have relegated security to the back burner.

Consultant Black said that security flaws are symptomatic of software development in general, with companies caring more about adding new functionality and turning out more code that is less reliable. “Security has not kept up. There is more code in a cell phone today than the software that got us to the moon,” Black quipped.

Stephan added that developers have a certain number of features to get out in a particular time frame. As a result, he said, information security flaws are not discovered for months or years following a release, and are difficult to link back to a specific programmer.

Developers are also externalizing the cost of failure, Black added. “As long as organizations are able to transfer the cost onto consumers and users, they will not be fully incentivized to fix problems,” he noted. “They are transferring cost onto customers to a degree that could not be done” with more tangible goods. He cited Microsoft as an example: “They invest a lot of money into fixing problems, which is certainly laudable, but a number of my clients have had significant expense doing regression testing on patches.”

Black suggested that it might take government action to see a transfer of cost back onto companies. Homeland Security is drafting a software assurance standard that is voluntary for now, but Black said that its conditions could change. Compliance could become mandatory, he pointed out, noting that the industry may be “one or two major software disasters away from pretty harsh government regulations.”

There is already precedent for government involvement. In the wake of several high-profile data breaches, California law makes the organization that created the problem responsible.

Although its scope is only tangential to software development, the California Information Practice Act (SB1386), a consumer privacy act, obligates companies to disclose when unencrypted personally identifiable data is or may have been accessed illegally and to adopt security procedures to limit the vulnerability of their data systems. Companies that are not compliant may be held liable in civil court.

Oracle’s Heimann said there is much work to be done and recommends security standards across the industry. “The industry has a lot of internal processes to measure the security of code,” he noted, “but is not at a point where processes can be carried across organizations.”


Share this link: http://www.sdtimes.com/link/30849
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading