Building Security In Maturity Model (BSIMM) version 3 (BSIMM3) was released on Tuesday by Cigital and Fortify.

Building Security In Maturity Model is an analysis of the results from a detailed surveying process about how companies build security into their software development processes. Its aim is to help all organisations understand, assess and plan software security initiatives. The findings identified are grouped into 12 practices across four domains called governance, intelligence, SSDL touchpoints and deployment in what is called the Software Security Framework. In these practices, a total of 109 activities are defined, spread across three tiers of complexity (levels 1 to 3) to give the appearance of a maturity model.

BSIMM3 includes data from 42 software security initiatives — 12 more than in BSIMM2. Although the data is primarily collected from organisations in the financial services, independent software vendor and technology sectors, other sectors are represented too. Many of the programmes are large, with the average number of developers being over 5,000 — but it ranges from just 10 to 30,000. No organisation survey does all 109 activities.

With the increase in source data, there has not been any significant change the the general findings, and the structure of domains, practices and activities has virtually not changed at all. The descriptions for most of the activities have been extended to clarify the meaning and provide further examples; in a small number of cases minor corrections have been made. But the total number of activities in unchanged, and their titles are the same. The following activities have been demoted from level 2 to level 1:

• Strategy & Metrics (SM) 2.4 "Require security sign-off" is now SM 1.6
• Attack Models (AM) 2.3 "Gather attack intelligence" is now AM 1.5
• Security Testing (ST) 2.2 "Allow declarative security/security features to drive tests" is now ST 1.3
• Penetration testing (PT) 2.1 "Use pen testing tools internally" is now PT 1.3

One activity has been promoted from level 1 to level 2:

• SM 1.5 "Identify metrics and drive initiative budgets with them" is now SM 2.5

So, previous scoring under BSIMM2 will need to be re-calculated, but there is a one-to-one mapping, and the numbering of all other activities remains unchanged.

The new scorecard presentation format demonstrate how to do a comparison of your own initiatives at a glance, and since some of the data sources have now been assessed more than once, BSIMM3 provides some comparison of changes over time.

So, some useful information for organisation wanting to assess and build out software security initiatives. Also take a look at Building Security In, Microsoft SDL, Open SAMM.

Following a successful training course yesterday with great group of delegates, today I attended the OWASP AppSensor Project working group at AppSec USA 2011.

The AppSensor Summit was held to review the project's recent developments and activities, and to gather ideas from existing and new contributors to create a future roadmap. It was good to meet at long last John Melton, AppSensor's lead programmer, and catch up with Michael Coates and Ryan Barnett.

The summit also attracted a diverse range of developers, architects, users and security vendors. There were probably about 10-12 people attending all day, with a few more popping in and out as their timetables and other commitments allowed. The discussions defined the contents for a new book, an AppSensor development life cycle, an integration plan and a new concept to modularise the analysis engine to simplify integration with application software. The idea of creating a set of example usage profiles was also suggested. I think my name is down to help mainly with a new version of the AppSensor book, but I hope I can contribute with some of the interface definitions for interactions with the analysis engine, and possible signalling/exporting functionality.

The meeting notes are available, so if you have any comments or suggestions, please add them there, or discuss them via the project's mailing list.

The talks at the conference begin tomorrow.

This week I attended and spoke at the Software Assurance Forum Fall 2011 in Arlington, Virginia.

With three tracks running, my own talk was in the "SwA at the Code Level". It seemed to be received well and the audience asked some great questions including some relating to practicality and scaleability. There were also some good suggestions for me to investigate concerning integration with, and cross-referencing with, other standards and protocols.

On the remainder of the day I listed to Jack Mannino talking about the OWASP Top 10 Mobile Risks, Jeff Williams on OWASP Acquisition Language for Software Assurance, and Jim Manico on Scalable Application Security Practices.

On Thursday, I attended the discussions on education and training, the educational supply chain and standards for software transparency. On Friday the presentations focused on software lifecyle development afforts including the effects of standards, people and culture.

I really enjoyed the event and heard about things I wouldn't normally have had time to investigate. And yes, I have some homework to do now.

Update 18th October 2011: The presentations at the Software Assurance Fall 2011 Forum have been published.

The UK's Centre for the Protection of National Infrastructure (CPNI) has updated its guidance on protecting business applications with the publication this month of a new document on developing and implementing secure web applications.

Development and Implementation of Secure Web Applications is a well-written and digestible 81-page A4 document arranged in seven main sections:

• Introduction to web application security
• General aspects of web application security
• Access handling (authentication, session management and access control)
• Injection flaws
• Application users and security
• Thick client security
• Preparing the infrastructure

It appears to replace the good, but somewhat dated document "Briefing 10/2006 - Secure web Applications - Development, Installation and Security Testing" created by their predecessor National Infrastructure Security Co-ordination Centre (NISCC), and issued in April 2006. The new document is more compact and focused, and I think I prefer it. Yes of course it is more up-to-date, and while it would be possible to argue why some things are included and not others, these others things tend to be explained further in the references. It's clear there is considerable overlap with information from OWASP and the Microsoft SDL, but I'm sure the reverse is true to an extent too.

It is very encouraging CPNI have taken the time to produce an updated document, but that probably reflects the types of risks facing their audience. I am especially pleased to see the section on infrastructure, since application security cannot be an island on its own. I would say the guidance is probably on the medium-to-heavy weight side of advice, but that is probably appropriate for critical national infrastructure, and the document does discuss threat modelling initially. It might seem overwhelming to some organisations new to the subject, and that might need some help on what to do first.

I think the document could perhaps do with more cross-referencing to additional information resources elsewhere. Yes, documents can always be improved, and I am sure we will find niggles and faults with use, but threats evolve and so does our knowledge.

For those concerned with wider cyber crime research, three recent documents should be of interest.

The documents address much wider issues than application security, but there are some useful nuggets in them of specific interest such as the average time to resolve or contain attacks.

Second Annual Cost of Cyber Crime Study

This updated report from the Ponemon Institute sponsored by ArcSight, describes the types of attacks, costs and governance, risk management and compliance practices for 50 mainly commercial organisations, involving 379 interviews. Key findings: annualised cost was found to be $1.5 million to $36.5 million, relating to on average one successful attack per week, and most likely to involve malicious code, denial of service, stolen devices and web-based attacks.

US Department of Defense Strategy for Operating in Cyberspace

The unclassified version of this document, released in mid-July, presents an overall strategy to defend against cyber threats and addresses aspects relating to the economy, security, law enforcement, military, governance, international development and internet freedom. Key quotation: "Our reliance on cyberspace stands in stark contrast to the inadequacy of our cybersecurity".

Operation Shady Rat

This report describes McAfee's investigation of targeted intrusions into 70 organisation's assets over the last five years. Key findings: the intrusion durations lasted from less than a month to 28 months, and affected organisations in all sectors and in all geographical regions.

See also Home Office Cyber Crime Strategy and scale of cyber crime in the UK.

On the second day of AppSec Washington DC 2010, I had a particularly difficult choice to make concerning which session to attend after the first break.

In the end, I went to Dan Cornell's talk about Application Portfolio Risk Ranking (slides) as I thought it was most relevant to my "day job". It was a great presentation and it's worth asking Dan for a copy of his spreadsheet if you are interested, but it meant I missed Jeff Williams' talk about Website Security Facts Labelling (slides).

I mentioned initiatives in this area from 2002 onwards in my previous blog post about Software Assurance Labelling. Having now read the presentation slides and related discussion on OWASP mailing lists, I can see Jeff Williams' ideas have moved forward significantly. He has even produced a Security Facts Tool to help build demonstration security facts labels, for example:

Well, that's a long label. The concept is based on his earlier work, and research on related consumer labelling examples from other industries (see presentation slides). The label includes information about what major modules and code libraries are used, the platform components, interfaces and connections, what types of sensitive data are collected, processed, stored & transmitted. But it also suggested that it should include some concept of how security risks have been reduced—in this case, whether the risks in the OWASP Top Ten 2010 have been addressed, and what common security practices are in place in the development lifecycle using those defined in the OWASP Software Assurance Maturity Model. The label might benefit from having the target site/application name recorded.

But the key finding from his research was the precise content of the label does not really matter that much. In his words:

Whatever you think about the appropriateness of the items included, one area where I think this labelling could be used immediately is in procurement. Organisations will often ask potential bidders for examples of previous work. The design agencies/software houses could be asked to complete the security facts label for whichever web products they choose to showcase—they should have this information available, they can use the tool quickly to produce a label and it's not going to become released to the public domain. The acquisition team will then have greater knowledge of the technologies and processes used, to help make more informed decisions about software choice instead of "does it look nice". The actual specification and contract will need to be more explicit about security, but for examples of previous projects, this would work very well.

So the concept is to make security concrete and visible—see the final "Security in Sunshine" slide at the end of the presentation slides. And, contribute your ideas and feedback.

The roadmap charts in the Software Assurance Maturity Model (SAMM) provide a great way to highlight how an organisation plans to improve its software security practices across a number of stages once an initial assessment has been undertaken.

In a three-part post on the OpenSAMM blog, I describe how charts, identical to the ones in the documentation, can be created using XML data and Scalable Vector Graphics (SVG). Part 1 was published today and will be followed by Parts 2 and 3 on Monday and Tuesday.

Sometimes when I'm out socially and people ask what I do, the conversation progresses to concerns about their own web site. They may have a hobby site, run a micro-business or be a manager or director of a small and medium-sized enterprise (SME)—there's all sorts of great entrepreneurial activity going on.

It is very common for SMEs not to have much time or budget for information security, and the available information can be poor or inappropriate (ISSA-UK, under the guidance of their Director of Research David Lacey, is trying to improve this). But what can SMEs do about their web presence—and it is very unusual not to have a web site, whatever the size of business.

Last week I was asked "Is using <company> okay for taking online payments?" and then "what else should I be doing?". Remember we are discussing protection of the SME's own web site, not protecting its employees from using other sites. If I had no information about the business or any existing web security issues, this is what I recommend checking and doing before anything else:

• Obtain regular backup copies of all data that changes (e.g. databases, logs, uploaded files) and store these securely somewhere other than the host servers. This may typically be daily, but the frequency should be selected based on how often data changes and how much data the SME might be prepared to lose in the event of total server failure.
  • check backup data can read and restored periodically
  • don't forget to securely delete data from old backups when they are no longer required
• Use a network firewall in front of the web site to limit public (unauthenticated user) access to those ports necessary to access the web site. If other services are required remotely, use the firewall to limit from where (e.g. IP addresses) these can be used.
  • keep a record of the firewall configuration up-to-date
  • limit who can make changes to the firewall
• Ensure the host servers are fully patched (e.g. operating system, services, applications and supporting code), check all providers for software updates regularly and allow time for installing these.
  • remove or disable all unnecessary services and other software
  • delete old, unused and backup files from the host servers
• Identify all accounts (log in credentials) that provide server access (not just normal web page access), such as used for transferring files, accessing administrative interfaces (e.g. CMS admin, database and server management/configuration control panels) and using remote desktop. Change the passwords. Keep a record of who has access and remove accounts that are no longer required and enable logging for all access using these accounts.
  • restrict what each account can do as much as possible
  • add restrictions to the use of these accounts (e.g. limit access by IP address, require written approval for use, keep account disabled by default)
• Check that every agreement with third parties that are required to operate the web site are in the organisation's own name. These may include the registration of domain names, SSL certificates, hosting contracts, monitoring services, data feeds, affiliate marketing agreements and service providers such as for address look-up, credit checks and making online payments.
  • ensure the third parties have the organisation's official contact details, and not those of an employee or of the site's developers
  • make note of any renewal dates
• Obtain a copy of everything required for the web site including scripts, static files, configuration settings, source code, account details and encryption keys. Keep this updated with changes as they are made.
  • verify who legally owns the source code, designs, database, photographs, etc.
  • check what other licences affect the web site (e.g. use of open source and proprietary software libraries, database use limitations).

Do what you can, when you can. Once those are done, then:

• Verify the web site and all its components (e.g. web widgets and other third party code/content) does not include common web application vulnerabilities that can be exploited by attackers (e.g. SQL injection, cross-site scripting).
  • use resources such as the OWASP Top Ten and WASC Threat Classification
  • build security requirements into future developments
• Check what obligations the organisation is under to protect business and other people's data such as the Data Protection Act, guidance from regulators, trade organisation rules, agreements with customers and other contracts (e.g. PCI DSS via the acquiring bank).
  • impose security standards and obligations on suppliers and partner organisations
  • keep an eye open for changes to business processes that affect data
• Document (even just some short notes) the steps to rebuild the web site somewhere else, and to transfer all the data and business processes to the new site.
  • include configuration details and information about third-party services required
  • think about what else will need to be done if the web site is unavailable (does it matter, if so what exactly is important?)
• Provide information to the web site's users how to help protect themselves and their data.
  • point them to relevant help such as from GetSafeOnline, CardWatch and Think U Know
  • provide easy methods for them to contact the organisation if they think there is a security or privacy problem
• Monitor web site usage behaviour (e.g. click-through rate, session duration, shopping cart abandonment rate, conversion rate), performance (e.g. uptime, response times) and reputation (e.g. malware, phishing, suspicious applications, malicious links) to gather trend data and identify unusual activity.
  • web server logs are a start, but customised logging is better
  • use reputable online tools (some of which are free) to help.

That's just the basics. So, what would be next for an SME? If the web site is a significant sales/engagement channel, the organisation has multiple web sites, is in a more regulated sector or one that is targetted particularly by criminals (e.g. gaming, betting and financial), takes payments or does other electronic commerce, allows users to add their own content or processes data for someone else, the above is just the start. Those SMEs probably need to be more proactive.

This helps to protect the SME's business information, but also helps to protect the web site users and their information. After all, the users are existing and potential customers, clients and citizens.

Oh, the best response I had to someone when I was explaining my work: "You're an anti-hacker than?". Well, I suppose so, but it's not quite how I'd describe it.

Any comments or suggestions?

Security and audit logging should be defined, implemented and tested for every web application. But what about log management and analysis?

This week Raffael Marty posted an updated item to his blog about a Maturity Scale for Log Management and Analysis. It is an excellent review.

Whilst much of this management and analysis is intended to be external to an application, we need to remember each application needs to record adequate information to feed into these analysis and reporting tools. And why do that? Read the bullet points under return on investment (ROI) at the end of the article. What else? Well perhaps also:

• feedback into the development lifecycle (to improve subsequent patches, versions and other projects)
• greater trust by users
• brand protection
• protection of information assets (not just preventing leaks, but ensuring accuracy and integrity).

Therefore, build adequate logging in from the start. Web server logs are not enough!

An article about the upcoming new regime for the classification and labelling of chemicals reminded me to write about software assurance (i.e. software security) labelling (and since web sites are software). From 1 December 2010, the UN Globally Harmonized System of Classification and Labelling of Chemicals (GHS) comes into force, implemented in Europe by the Regulation (EC) No 1272/2008 of the European Parliament and of the Council of 16 December 2008 on classification, labelling and packaging of substances and mixtures (CLP), amending and repealing Directives 67/548/EEC and 1999/45/EC, and amending Regulation (EC) No 1907/2006.

CLP implications and guidelines are explained by the UK Health and Safety Executive (HSE) but are defined fully in the UN's documentation. The headline chemical labelling indicates the potential damage/harm that can occur, rather than the content/properties of the agent. I like this "impact" approach. Nutritional labelling on the other hand generally tends to focus on ingredients and their properties, but some food labelling is also beginning to attempt to classify low/medium/high fat/saturates/sugars/salt levels, which is more akin to the impact approach.

Jeff Williams (CEO of Aspect Security and Chair of OWASP Foundation) proposed a Software Facts label five years ago at OWASP Appsec Europe. This would be similar to appliance energy usage labels, food nutrition facts label, material safety data sheets or laser safety classes. That idea was taken up by NIST and the Software Assurance Consortium (SwAC) to develop another proposal.

Comment here and here around the same time in 2005 describes some of the challenges. Indeed many more aspects of the software development lifecycle impact upon the creation of secure software. But simplicity is needed in the presentation of such information—perhaps some high-level impact related indicators augmented by the more detailed information for different audiences (e.g. users, operators, administrators, system achitects). SwAC's version seems to be somewhat aimed at software development teams, instead of people in end user organisations, especially those involved with procurement decisions. Whilst some people will want to know the data behind a classification, most businesses and consumers will need something more akin to the CLP headline labels relating to business (or personal) impact as a starting point for their decisions.

• How dangerous is this software?
• How reliable is it?
• How does it affect privacy?
• How does the IT environment affect these?
• How are these affected by changing the default settings?

This a big challenge. Just specifying the privacy practices for a web site can be complex. ENISA's Common Assurance Maturity Model (CAMM) project is trying to define how cloud service providers can be compared to allow users to make informed decisions about the risks. Perhaps that project will develop into some form of labelling scheme, or at least provide ways for typical consumers of the services to determine their own risks as simply as possible.

I don't know the status of the SwAC project but will now make the effort to find out.