Within the security industry, a recent trend is a focus around considering security from the start during the development of applications. This is by no means a new concept; it simply was not a focus in the industry as vulnerabilities within infrastructure (network, operating systems, and databases) were what were being exploited at the time.
However, as these vulnerabilities were remediated and defence mechanisms at those levels improved, attackers shifted their focus to other avenues such as phishing and application level vulnerabilities. In addition, as we are more connected to the Internet via high speed connections, more and more organisations have migrated their software applications to the Internet for wider accessibility. As a result, focus within the security industry has shifted to software security.
An example of this shift in focus can be seen in the evolution of the payment card industry data security standard (PCI-DSS). The earlier version of this standard (when it was called Visa Cardholder Information Security Program) mentions that organisations should follow change control procedures for their software modifications as best practice items under a few of the requirements. In contrast, the latest version of the standard (v1.2) dedicates the majority of one of its 12 requirement areas (requirement 6) to the security of software applications.
Software security issues
As an application security consultancy, a question we get asked a lot is what issues are you seeing your clients? What do you help them with? Organisations have differing drivers for security such as compliance (DPA, SOX, PCI-DSS), governance, protection against crime, brand reputation, etc, but the primary issue our clients face is figuring out how to manage and operate information security processes effectively within their organisation. Due to the pervasive nature of information security controls, they must be embedded within business and IT processes.
Information security within software development is a prime example of this.
Many organisations struggle with how to incorporate information security into their software development projects effectively, largely due to time and budget constraints. Some of the more common questions we get asked include:
- What does 'it' look like?
- How can we understand and manage 'this'?
- Do we have enough resources / skills to do 'this'?
- How does 'this' fit in with the security function, shouldn't they do 'it'?
- We are used to security projects that implement tools or systems but now we need to change our processes?
- Isn't there an established method or model for all 'this'?
You may have noticed that I have referred to information security within the software development process as either 'this' or 'it'. Currently, information security within the software development process is still a discipline in definition.
There have been many guides and methodologies published in recent years by both public and private sector organisations. While many of these differ in naming conventions and presentation, they are all very similar in nature. While there are many definitions and acronyms for this discipline, it is commonly referred to as software assurance.
OpenSAMM
Recently, an attempt has been made to capture the elements of the discipline of software assurance within a framework that varying organisations can use as either reference, to assess where they are in terms of software assurance maturity, or to build a roadmap to implement security into their software development process.
My company has adopted the software assurance maturity model (SAMM) in order to put all of 'this' into a framework that the business can understand. It has been released under an open license, the creative commons attribution-share alike license, and is set to be an official project within the open web application security project (OWASP).
As such, it is also commonly referred to as OpenSAMM or simply SAMM. This body of work was written and edited by a group of software security experts within the industry under the support and funding of Fortify Software, Inc., a leading provider of application lifecycle security and source code analysis tools. It can be downloaded from www.opensamm.org.
Here I will discuss some of the core activities within SAMM but firstly, I would like to mention what SAMM is not. SAMM is not a prescriptive 'how to' document for software assurance; nor is it a 'one size fits all' methodology; nor is it an audit checklist around secure software development.
Core activities of OpenSAMM
As mentioned before, there have been many guides and methodologies published around software assurance over the years with common areas addressed. The following are some of the key core activities within SAMM in which we work with our clients to achieve software assurance:
- Education and guidance - EG. This includes focusing on the right security training for the right personnel involved within all stages of the software development process. SAMM goes as far as suggesting information security related certifications in areas of software development which can be a good motivator for technical staff.
- Security requirements - SR. In order to plan for information security to be built in to software, it has to be detailed as requirements so they can be developed and tested in the same way as other functional or non-functional requirements. SAMM recognises that not all software development projects are the same. Security requirements need to be tailored based on several risk factors such as the type of software being developed, data that will be processed or who will have access.
- Threat modelling - TM. Threat modelling is an activity performed in order to focus on what the threats are to an application and likely attacks it may face once developed and deployed. Information security requirements are then matched up against the identified threats in order to determine whether the security requirements have addressed all identified threats appropriately. This is done early in the software development process usually prior to when functional and technical specifications have been finalised.
- Architecture review - AR. The architecture review activity is focused on the review of software designs and architecture models for potential security related deficiencies. This allows an organisation to detect architecture-level issues early in software development to avoid potentially large costs from refactoring down the road. The security requirements developed for the project as well as either the organisation's security architecture or best practices are used as the basis for the review.
- Standards and compliance - SC. In order to meet the information security requirements of the organisation (both internal and external), software development projects need to have an understanding of such requirements as well as have periodic compliance reviews at the appropriate project gateways.
- Security testing - ST. This activity is the one that is most recognisable in the industry as it has been performed for many years. This includes traditional penetration testing such as black-box and white-box testing. SAMM also suggests performing more tailored testing based on test cases derived from the security requirements as well as source code analysis for information security related issues using automated tools.
Within this article through the introduction of OpenSAMM, I have highlighted the core areas in which we work with organisations as they address their issues around how to implement and operate information security into their software development processes.
As software assurance is still a young discipline within a young industry such as information security, we believe that organisations can benefit greatly in embracing a framework such as OpenSAMM. This is in much of the same manner as how the BS7799 standard was embraced by organisations over the past 10 years to incorporate the fundamentals of information security into their business.
Matt Bartoldus is an information risk management professional with over 10 years of experience managing and delivering information security projects. Service delivery experience spans the scope of IT audit; security penetration and vulnerability assessments; regulatory compliance and information security governance consulting; policy and standard development; as well as security business transformation.
