Reference:www.csoonline.com
Fewer security holes means better software quality and lower costs. Merkow and Raghavan provide expert guidance on building and managing a software security program that pays off.
By Mark S. Merkow and Lakshmikanth Raghavan, Authors of Secure and Resilient Software Development
October 04, 2010 — CSO —
If we have learned nothing else from 60-plus years of software development it’s that secure, high-quality code does not happen by accident. National governments have long understood that quality and security must be specified, designed, and implemented from soup-to-nuts throughout the software development lifecycle (SDLC).
Governments go to great length to assure that only provably secure software is used to protect national secrets. Unfortunately, this philosophy never spilled over into the commercial world and what we’re left with today is a precarious branch filled with brittle applications of questionable reliability.
This article address these issues and offers solutions to help you avoid repeating the same mistakes that lead to even more insecure and unreliable software and systems. We’ll look at what people expect when they acquire software and what they actually get, reasons for the gaps, what you as managers can do to improve your own organization’s software development practices and measure the progress of your success.
The authors’ book Secure and Resilient Software Development
See an excerpt Security testing of custom software applications on CSOonline.com, where you can also find the authors’ primer on software security for developers
Software is useful for what it does. People purchase software because it fulfills their need to perform some function. These functions (or features) can be as simple as allowing a user to type a letter or as complex as calculating the fuel consumption for a rocket trip to the moon. Functions and features are the reasons people purchase or pay for the development of software and it’s in these terms that people think about software.
People also (erroneously) assume that the software they purchase is written with some degree of quality. When you purchase a software package you just assume it will operate as advertised and you never really think about how well the program does its job—just as long as it works!
The sad truth is that most software is flawed straight out of the box and these flaws can threaten the security and safety of the very systems on which they operate. These flaws are not just present in the traditional computers we use everyday, but also in critical devices, like our cell phones and medical devices—think pacemakers and cars—and national infrastructures like Banking and Finance, Energy, and Telecommunications.
Programmers are taught to write code—they are not taught how to write good code.
Organizations incent programmers to write more code, leaving good code out of the equation while cheap code and rapidly-developed code dominates the landscape.
Web applications especially are inherently flawed with certain types of vulnerabilities (e.g. Cross Site Scripting (XSS)) unless the developer has made a conscious effort to prevent it. If the developer fails to include appropriate output encoding routines and input validation routines, the application will most certainly be vulnerable by default to XSS.
To a developer, the software may in fact work just as he intended it to work but never tested it to see how it behaves when it’s being fed malicious input or is under direct attack.
Writing software, like driving a car, is a habit. Until someone teaches us how to drive safely, we don’t personally know the dangers of driving and the skills needed to prevent or avoid accidents. Cars often have safety mechanisms built into them, but as drivers, we have to consciously use our own safe driving skills. Experience teaches us that we are better off instilling safe driving skills before we let people loose on the roads since their first accident may be their last.
How Bad is the Problem, Really?
In 2008 there was significant increase in the count of identified vulnerabilities in commercial software—a 13.5 percent increase compared to 2007. The overall severity of vulnerabilities also increased, with high and critical severity vulnerabilities up 15.3 percent. Medium severity vulnerabilities were up 67.5 percent and nearly 92 percent of 2008 vulnerabilities reported can be exploited remotely.
Of all the vulnerabilities disclosed in 2008, only 47 percent are able to be corrected through vendor patches. At the end of 2008, 74% of all web application vulnerabilities disclosed in 2008 had no available patch to fix them.
Web applications are the Achilles Heel of Corporate IT Security too. Every year organizations across the globe spend millions of dollars on securing their software infrastructure—a significant portion of an entire year’s IT budget. Software security spending tends to focus on detecting existing vulnerabilities in the software organizations already own and finding ways to reduce the associated risks of using it. Rewriting software, whether to fix a problem or fundamentally change what the software does, also results in tremendous corporate expenditures year after year. Bad code also negatively affects productivity whenever the application or a system goes down, leading to indirect or direct losses to the business. Other Web applications flaws lead to brand damage, reputation damage, information theft, and denial of service problems. [Editor’s note: For more, see ‘Broken windows revisited: Why insecure software hurts the global economy’ by David Rice.]
Don’t Bolt Security On—Build It In!
Software flaws appear in software because somewhere along the specification, development, and testing conveyor belt, requirements that mandate secure software fell on the floor and were neglected. Software is only secure when it’s designed for security—most attempts at bolting on security after the fact yield even more problems than when it’s considered from the beginning of a development effort.
To actually move the needle on progress for software security requires that security be built in to the development life cycle itself and begins with a management sponsored Secure Coding Initiative to fundamentally improve how an organization thinks about and developments software for public use, for in-house use, and for sale to others.
Any secure coding initiative must deal with all stages of a program’s lifecycle. Secure programs are secure by design, during development, and by default. As with any significant change initiative, education plays a key role. Education is the cornerstone to any effective intervention to improve software quality and should be treated as non-optional. Prior to relying on the people involved in software development for secure code, it’s essential that training in secure design and coding is administered to help the analysts, designers, and developers to better understand how incomplete analysis, poor design decisions, and poor coding practices contribute to application and system vulnerabilities.
Once educated, SDLC participants begin behaving differently and start to serve as an internal checks-and-balances mechanism that catches problems earlier in the SDLC and leads to lower costs of development and higher quality systems.
Education needs to prepare personnel in the basics of Web application flaws, familiarize them with the hacking tools of the trade intended to break application software, and preparing them to carry out their craft with new skills and techniques.
From the earliest days of software development, studies have shown that the cost of remediating vulnerabilities or flaws in design are far lower when they’re caught and fixed during the early requirements/design phases than they are after launching the software into production. Therefore, the earlier you integrate security processes with the development life cycle, the cheaper software development becomes in the long haul.
These security processes are often just “common sense” improvements and any organization can and should adopt them into their existing environment. There is no one right way to implement these processes—each organization will have to fine tune and customize them for their specific development and operating environments. These process improvements add more accountability and structure into the system too. There are a number of well-accepted secure software development methodologies, including Microsoft’s Secure Development Lifecycle (SDL), Cigital’s Touchpoints, and the one we’ll examine here, called CLASP.
Comprehensive, Lightweight Application Security Process (CLASP)
The Open Web Application Security Project (OWASP) is an open community dedicated to enabling organizations to conceive, develop, acquire, operate, and maintain applications that can be trusted. One of their more prominent projects is called the Comprehensive, Lightweight Application Security Process, or CLASP.
CLASP is a pre-defined set of documented processes and tools that can be integrated into any software development process. It is designed to be both easy to adopt and effective.
CLASP uses a prescriptive approach, documenting activities that organizations should be doing. CLASP is rich with an extensive collection of freely available and open source security resources that make implementing those activities practical and achievable.
Think of CLASP as a resource library to avoid re-inventing the wheel when you come across the need for new processes or new ideas for secure software development.
CLASP provides extensive detailed information on:
- Concepts behind CLASP to get started
- Seven key Best Practices that define CLASP
- High-level Security Services that serve as a foundation
- Core Security Principles for software development
- Abstract Roles that are typically involved in software development
- Activities to augment the development process to build more secure software
- CLASP Process Engineering and Roadmaps
- Coding Guidelines to help developers and auditors when reviewing code
- A lexicon of Vulnerabilities that occur in source code
- A searchable Vulnerability Checklist in Excel format for the CLASP Vulnerability lexicon
You can obtain a free copy of CLASP in book form or from the OWASP CLASP Wiki.
mplementing software application security best practices requires a reliable process to guide a development team in creating and deploying an application that is as resistant as possible to security attacks. Within a software development project, the CLASP Best Practices are the basis of all security-related software development activities. Here are the seven CLASP best practices:
- Best Practice 1: Institute awareness programs
- Best Practice 2: Perform application assessments
- Best Practice 3: Capture security requirements
- Best Practice 4: Implement secure development practices
- Best Practice 5: Build vulnerability remediation procedures
- Best Practice 6: Define and monitor metrics
- Best Practice 7: Publish operational security guideline.
Essential security concepts and techniques may be foreign to your organization’s software developers and others involved in application development and deployment. So it is imperative at the outset to educate everyone involved. Awareness programs can be readily implemented, using external expert resources, as appropriate, and deliver a high return by helping to ensure that other activities promoting secure software will be implemented effectively. Here are some tips to help with security awareness:
Provide security training to all team members
Before team members can reasonably be held accountable for security issues, you must ensure they have had adequate exposure to those issues. This is best done with a training program. Everyone on the team should receive training introducing them to basic security concepts and secure development process that is used within the organization.
Promote awareness of the local security setting
Everyone on a development project should be familiar with the security requirements of the system, including the basic threat model. When such documents are produced, they should be distributed and presented to team members, and you should solicit and encourage feedback from all parties on the team.
Institute accountability for security issues
Traditional accountability within development organizations is based primarily on schedule and quality. Security should be treated in much the same way as any other quality consideration.
Appoint a project security officer
An excellent way to increase security awareness throughout the development lifecycle is to designate a team member as the project security officer, particularly someone who is enthusiastic about security.
Institute rewards for handling of security issues
Accountability is a necessity for raising security awareness, but another highly effective way is to institute reward programs for doing a job well done with regard to security. For example, it is recommended to reward someone for following security guidelines consistently over a period of time—particularly if the result is that no incidents are associated with that person.
Testing and assessment functions are typically owned by a test analyst or by the QA organization but can span the entire SDLC. CLASP offers detailed guidance for each of the following areas of application assessments:
- Identify, implement, and perform security tests
- Find security problems not found by implementation review
- Find security risks introduced by the operational environment
- Act as a defense-in-depth mechanism, catching failures in design, specification, or implementation
- Perform security analysis of system requirements and design (threat modeling)
- Assess likely system risks in a timely and cost-effective manner by analyzing the requirements and design
- Identify high-level system threats that are documented neither in requirements nor in supplemental documentation
- Identify inadequate or improper security requirements
- Assess the security impact of non-security requirements
- Perform source-level security review
- Find security vulnerabilities introduced into implementation
- Research and assess security posture of technology solutions
- Assess security risks in third-party components
- Determine how effective a technology is likely to be at alleviating risks
- Verify security attributes of resources
- Confirm that software abides by previously defined security policies
It is especially important in the context of application updates and enhancements to define which steps will be taken to identify, assess, prioritize and remediate vulnerabilities. CLASP guidance can be found for:
- Addressing reported security issues
- Ensure that identified security risks in an implementation are properly considered
- Managing the security issue disclosure process
- Communicate effectively with outside security researchers when security issues are identified in released software, facilitating more effective prevention technologies
- Communicate effectively with customers when security issues are identified in released software
You cannot manage what you cannot measure. Unfortunately, implementing an effective metrics monitoring effort can be a difficult undertaking. Despite this, metrics are an essential element of your overall application security effort. They are crucial in assessing the current security posture of your organization, help focus attention on the most critical vulnerabilities, and reveal how well — or poorly — your investments in improved security are performing.
- Monitor security metrics
- Gauge the likely security posture of the ongoing development effort
- Enforce accountability for inadequate security
You will see more on metrics and metrics models in the next section on measuring progress.
Security does not end when an application is completed and deployed in a production environment. Making the most out of existing network and operational security investments requires that you inform and educate those charged with monitoring and managing the security of running systems. The following advice and guidance on the security requirements will help to assure that your organization makes the best use of the capabilities you have built into your application.
- Build an operational security guide
- Provide stakeholder with documentation on operational security measures that can better secure the product
- Provide documentation for the use of security functionality within the product
- Specify a database security configuration
- Define a secure default configuration for database resources that are deployed as part of an implementation
- Identify a recommended configuration for database resources for that are deployed by a third party
Development organizations should be bought into the process which they use for development. The most effective way to do that is to build a process engineering team from members of the development team so that they can have ownership in creating the process.
Here are the recommended steps to form the process engineering team:
Build a process engineering mission statement
Document the objectives of the process team. It is reasonable to have the entire development team sign off on the mission, so that those people who are not on the team still experience buy-in and inclusion.
Identify a process owner
The process team should have a clearly identified process “champion,” whose foremost job is to set a direction and then evangelize that direction. Make it clear that this team will be held accountable for all aspects of the engineering and deployment activities associated with early adoption of this new security process framework.
Identify additional contributors
As with the process owner, people who make good evangelists should be valued as well as people who will be the most worthy contributors.
Document roles and responsibilities
Clearly document the roles and responsibilities of each member of this team.
Document the CLASP process roadmap
It is time to make the classic “build-versus-buy” decision for a process framework. Can one of the process roadmaps that are a part CLASP be used as-is? This decision and the resulting process roadmap must be documented and approved before moving into the deployment phase.
Review and approve pre-deployment
Institute a checkpoint before deployment, in which a formal walk-through of the process is conducted. The objective at this point is to solicit early feedback on whether or not the documented framework will indeed meet the process objectives set forth at the beginning of this effort. The team should not proceed to the deployment phase of this project until organizational approval is formally issued.
Document any issues
Issues that come up during the formation of the process engineering team should be carefully documented. These issues will need to be added to the process engineering or process deployment plans — as appropriate to managing risk accordingly.
While any SDLC methodology—with the appropriate security activity in place from start to finish—will do, what should be clear is that metrics and measurement are vital to assure you are headed in the right direction
Measuring Your Secure Development Program’s Success
In the last section of this article we’ll take a look at the two leading software security maturity measurement models, OWASP’s Open Software Assurance Maturity Model (OpenSAMM) and the Building Security in Maturity Model (BSIMM).
OpenSAMM
SAMM is an open framework to help organizations formulate and implement a strategy for software security that is tailored to the specific risks facing the organization. OpenSAMM offers a roadmap and well-defined maturity model for secure software development and deployment, along with useful tools for self-assessment and planning.
SAMM was defined to fit any small, medium, and large organizations using any style of an SDLC. The model can be applied organization-wide, for a single line-of-business, or even on an individual project. OpenSAMM comes as a 96-page PDF file with detailed descriptions of each core activity and corresponding security processes that you can download for free from the OpenSAMM Web site. The OpenSAMM security practices and framework are shown in Figure 1 below.
[Figure 1&mdas;OpenSAMM security practices]
Using OpenSAMM, a company can benefit through:
- Evaluating your organization’s existing software security practices
- Building a balanced software security program in well-defined iterations
- Demonstrating concrete improvements to your security assurance program
- Defining and measuring security-related activities within your organization
Building Security in Maturity Model (BSIMM)
The Building Security in Maturity Model is designed to help you understand, measure, and plan a software security initiative. It was created through a process of understanding and analyzing real-world data from nine leading software security initiatives and then validated and adjusted with data from twenty-one additional leading software security initiatives.
Properly used, BSIMM can help you determine where your organization stands with respect to real-world software security initiatives and what steps can be taken to make your approach more effective.
BSIMM lists twelve practices organized into four domains. The domains are:
- Governance: Those practices that help organize, manage, and measure a software security initiative. Staff development is also a central governance practice.
- Intelligence: Practices that result in collections of corporate knowledge used in carrying out software security activities throughout the organization. Collections include both proactive security guidance and organizational threat modeling.
- SSDL Touchpoints: Practices associated with analysis and assurance of particular software development artifacts and processes. All software security methodologies include these practices.
- Deployment: Practices that interface with traditional network security and software maintenance organizations. Software configuration, maintenance, and other environment issues have direct impact on software security.
The BSIMM Software Security Framework (SSF) is illustrated in Figure 2 below.
[Figure 2—BSIMM Domains and Practices]
To help you get started with BSIMM, there are free resources on the BSIMM website for collecting information in MS Excel and developing a project implementation plan in MS Project. The spreadsheet will help you study, slice, and dice the activity info within the BSIMM, while the Project file will enable you to copy or click-click-drag the activities to arrange them in the phases or groupings you need. Once you have completed your own assessment, you can build spider diagrams from the results and begin comparing them to others in the same or similar industries. The BSIMM Begin survey tool is also a helpful tool to get started with BSIMM. The survey is a Web-based study focused on 40 of the 110 activities covered in the full BSIMM that lets you walk away with some idea of how your basic software security activities stack up against those practiced by other organizations. [Editor’s note: See ‘Code writers finally get security? Maybe’ for a progress report.]
Software Security for Managers: Summary
It makes no difference what path you take to implementing a secure coding initiative —as long as you continue to strive for improvements, your efforts will be rewarded. While any methodology to get there will do, metrics and measurement are vital to assure that you are headed in the right direction for secure systems and software.
Don’t let the perfect be the enemy of the good. For software assurance, the time to get moving is now!
Read more about application security in CSOonline’s Application Security section.
Thank you,
Best Regards,
Nilay Sangani
Neel's Security Articles 