eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Experts agree that although absolute application security is nearly impossible, there are key steps you should take to mitigate risk.
Step 1: Define the process
The first step is to define the process you’re going to use to develop and measure the security of your software.
Software development has many phases, from requirements gathering through design, development, testing and deployment. You must consider how your existing processes must be augmented in every phase of development to include security, said Ben Chelf, chief technology officer at Coverity, a maker of static source code analysis tools.
“Defining the process includes thinking about coding standards for your developers to avoid potentially dangerous code constructs; thinking about how to design the system in a secure way so that there is no unintended access, even in the case where the code itself is bulletproof; and so on,” Chelf said.
Security is not just something you can slap on at the end of the proc??Ãess after the system is put together, Chelf added. That is too late. With a good process in place that spans the entire software development life cycle, you can set up checkpoints to measure and verify that security is being addressed appropriately.
However, there is no single process that works for all organizations.
“The companies that I’ve seen as the most successful put together a team of security experts to help define the processes and standards for software development that occurs within the entity,” Chelf said. “This group should be seen as an enabler, not a -slap on the wrist’ to the software development organization.”
Eric Bidstrup, Microsoft’s group program manager for Security Engineering and Community, Trust??Ãworthy Computing, said it is important to get management support for secure development-no matter what.
“Ensure that you have absolute management support for building secure software, including the ability to halt shipment of a product if it doesn’t meet your predefined, approved and documented specifications for secure software development,” Bidstrup said.
Indeed, account??Ãability, priorities and buy-in need to be established before progress can be made on application security.
“Application security requires a partner??Ãship between security teams and their development counter??Ãparts,” said Mike Weid??Ã??Ãer, director of se??Ã??Ãcurity solutions at IBM Rational. “Organizations need to place a priority on this alongside building new features and meeting deadlines. This applies for internally or externally developed applications.
Third-party developments and offshore com??Ãpanies need to be held accountable for delivering secure code by building this into the legal contracts.”
Sebastian Holst, senior vice president of sales and marketing at PreEmptive Solutions, also recommends a de??Ã??Ãtailed inventory of the existing IT environment.
“An organization must have an accurate inventory of what it has developed and deployed and where those applications are being used, for what purposes and by whom,” Holst said.
The biggest problems come when organizations wait until the end of development to think about security, Weider added.
There is no silver bullet
“Just as [it’s more effective to fix] quality during coding than once in production, the same holds true for security,” Weider said. “It’s a mindset shift that needs to be created-baked-in security. Testing for quality needs to go hand in hand with testing for security. The development process needs to be adapted over time so that organizations are thinking about application security right away-during requirements, design, development and testing.”
Adam Kolawa, co-founder and CEO of Parasoft, a maker of automated software quality tools, said developers must “realize there is no silver bullet for security and that security is really an infinite issue.”
Kolawa added that it’s important to get away from thinking about security in terms of fixing bugs and instead look at it as making sure that security errors don’t exist in the code in the first place. “Security errors cannot be treated as bugs,” he said. “You may or may not find bugs, but you must prevent security errors. In other words, you need to guarantee that certain classes of security errors do not exist in the code.”
Step 2: Educate the players.
The second step in developing secure software is to educate the players in your software development organization.
Software security hasn’t exactly been at the forefront of computer engineering, so chances are your developers, architects, product managers, QA (quality assurance) engineers and so on are not properly trained in what it means to design and implement secure software, Coverity’s Chelf said.
“It’s not just a matter of programming securely,” Chelf said. “If you have a system that is perfectly implemented from a coding perspective but allows access because of poor password choices for the users, the system is still insecure. So it really does begin at the very earliest part of the software development life cycle.”
Chelf said a variety of good resources, including books and online courses, are available for training developers on how systems can be compromised.
But in addition to book smarts, he said, developers need street smarts.
“You can set up a real lab, with a real system, and then exploit the system with a previous and known exploit,” Chelf said. “Give your teams of developers the firsthand experience of debugging the exploited system, tracing the failure to its root cause and seeing firsthand not only how difficult it can be to track down the problem in an exploited system but also how subtle the error likely is that was taken advantage of. The goal of this type of exercise is to get your developers to feel the real impact of security vulnerabilities in the system.”
As an adjunct to a lab, Microsoft’s Bidstrup suggested, set up a security response process. “And be prepared to update your security development life cycle based on what you learn from your root-cause analysis of discovered vulnerabilities,” Bidstrup said.
Equip the team
IBM Rational’s Weider went so far as to say that educating developers is critical to winning the war on security-and that organizations need to take on the responsibility of that education. “Developers rarely get security training during school, so this needs to happen on the job,” he said.
Step 3: Equip the team.
The third step to secure development is to equip team members with the tools and technologies that will help them build applications in a secure manner from the very beginning.
Chelf warned, however, that some of these tools can slow the process-something that irks business managers and developers alike.
“Make no mistake, adding security to your software development process can potentially slow down your release efforts,” Chelf said. “And not only is time to market absolutely critical to your business, your developers also do not enjoy anything that is added to their process that slows them down.”
Fortunately, tools are available that can help developers be more secure and more efficient, Chelf said. Static code analysis is a great way to counteract the otherwise-onerous process of manually reviewing an entire code base for security vulnerabilities-a task no one really wants to undertake, he said.
Tools and technologies are available to help organizations with verification, validation and security and to help enhance software integrity throughout the system.
“The benefits gained by discovering defects earlier in the software development process counterbalance the additional time you are asking your developers to spend in developing secure code,” Chelf said. “I recommend picking tools that are designed for the developer.
You can pick analyzers that are made for the security audit team, or QA, but the most influential group of people as it pertains to software security is your software developers.”
Microsoft’s Bidstrup echoed the importance of minimizing risk from implementation vulnerabilities by using static code analysis tools. He also said organizations should “use defense-in-depth mitigations by applying the best options available from compilers and build tools.”
Meanwhile, PreEmptive’s Holst said organizations should “select common practices, frameworks, technologies, architectures and suppliers to ensure consistency and a -principle of least surprise’ across the enterprise.”
Step 4: Test and test again.
The fourth step in developing for security is to employ security-testing techniques.
In the past, verification-ensuring a program did not fail-and validation-ensuring a program did what it was supposed to do-were the primary tasks a software development organization needed to address prior to release, Chelf said.
“[However,] the difference between verification/validation and security is that it is much more difficult to test for security,” he said. “Testing to make sure the program runs correctly and does not fail is something observable. Testing to see if a certain failure could be exploited is much more difficult to observe.”
Part of this stems from the fact that, when developing software with security in mind, you’re developing against an adversary, Chelf said.
“This is a much different paradigm than simply trying to make your customers happy with features that work,” he said. “And when working against an adversary, you must concern yourself with not only whether a system fails, but how exactly it fails, because that hacker will try every mode of failure he or she can to try to uncover the weakness in your system.
Monitor the process
“The reality is that even if your application fails 99.9999 percent of the time in a secure way, some hacker out there likely will uncover that one-in-a-million failure mode to exploit your application,” he said. “And that is very difficult to test for.”
However, vigorous testing must be done nonetheless, say experts.
“Components of an application need to be tested separately and also again together,” Weider said. “A part of an application could be secure on its own, but when code created by another person [is introduced], a new security vulnerability could be created. Security can never be taken for granted.”
Moreover, Weider said, there have been some incredible advancements in the quality of security-testing tools in the last several years. “Used in conjunction with good process and training, tools can significantly reduce the cost and time required for security testing,” he said.
Step 5: Monitor the process.
Lastly, compliance with security policies should be monitored on an ongoing basis.
“Monitor compliance to security policies using an automated infrastructure,” Parasoft’s Kolawa said. “At a scheduled time each night, the automated infrastructure should retrieve the latest code modifications from source control and determine whether that code complies with the security policy. If a problem is found, the developer who introduced it should be notified within his or her IDE [integrated development environment] to promote fast remediation.”
This step also includes security code reviews and maintaining security vigilance as applications move into production.
“No development project, no matter how well-designed or executed, will remain 100 percent secure 100 percent of the time if left to its own devices,” said Andrew Zaikin, a security expert and project director at outsourcing specialist Exigen Services.
“Watch production, read production logs as they are being developed, and stay involved on a consistent and continual basis,” Zaikin said.