A new report from Ponemon Institute describes the results from a survey of developers and information security employees in the United States.

2012 Application Security Gap Study: A Survey of IT Security & Developers provides useful data on the viewpoints from these important groups, and of course isn't necessarily encouraging reading. A very small proportion of the IT security budget is spent on application security, most do not have a standardised way of building security into new applications and security is most often addressed in later stages of the software development life cycle (SDLC). See the overview on the ISACA website.

The information could be used to help compare secure software development life cycle (S-SDLC) maturity, but the input of other groups such as product owners, architects, testers, QA, audit and operations would also provide useful data, and hopefully senior management might be able to provide an oversight of the all the processes and the organisation's needs and risk profile.

BITS, the technology policy division of the Financial Services Roundtable, an industry body representing the US financial services industry, has published a Software Assurance Framework.

The 50-page guidance document describes an outline of recommended components of what they describe as a "mature, strategic program for secure software development" for software used within the US financial services industry. The framework was a collaborative effort that involved several financial services companies in conjunction with Microsoft, and it references the Microsoft-sponsored Forrester Consulting research which indicated that the use of a prescriptive secure software development lifecycle achieves the greatest return on investment (see also the similar Aberdeen Group research).

This is not a hands-on "how to" for software architects, developers, testers or operational staff, but instead describes a framework of activities that contribute to the specification, production, deployment and operation of secure software throughout the development lifecycle. In that respect, the comparable documents to refer to are BSIMM, MS SDL and Open SAMM, and indeed these are referenced in the BITS framework. Some organisations also build their software assurance efforts around the Capability Maturity Model Integration (CMMI).

So what does BITS consider to be the key components of a software assurance framework? Eight are defined and explained:

• Education & Training
• Security Software Assurance Development Standard
• Threat Modeling
• Coding Practices
• Security Testing
• Pre-Implementation Practices
• Software Assurance Documentation Archive Best Practices
• Post-Implementation Phase Controls

There is of course considerable overlap with the references mentioned above which describe actual practices in place, how Microsoft undertakes secure SDLC and a maturity model for software assurance respectively. I have tried to indicate below how the BITS key components broadly map to Open SAMM:

So quite a lot of overlap. There is an existing mapping of Open SAMM to BSIMM activities which could be used to extend the above mapping onto BSIMM. As the BITS framework has been developed in conjunction with Microsoft, I expected to see a much closer relationship with MS SDL, and yes this is the case.

There isn't a direct one-to-one mapping here, but I hope the above help navigate the document if you use Open SAMM or MS SDL and want to delve into another source of ideas for secure software development lifecycles. Although the BITS framework might be somewhat heavyweight for some non-financial services organisations, especially on the documentation front, it is perhaps an easier starting point than the closely related MS SDL, to begin working on building security into development (and acquisition) processes. Take what suits, makes sense and fits your own organisation's type of applications and tolerance of risk.

Most of the content will be relevant, and since it is spelt out in reasonable detail, this could be very helpful. Some notable nuggets deeper in the document are:

• pp2-3 "teaching techniques of good design and their subsequent use can result in software secure not just against known attacks, but also against unknown attacks and attacks yet to come"
• p20 "Security defects are "defects", not just "security defects"
• p35 Security vulnerabilities identified in applications in production .... should not be treated as software defects, but as one part of the company's incident response process".

And on page 36 in the section relating to emerging threats in the post-implementation phase controls, there is a comment relating to the OWASP Top Ten and CWE/SANS Top 25 which seems out of kilter with the rest of the framework's text. The document states these as being valuable sources of information but "both represent an earlier generation of software security intelligence". I am not sure each of those sources set out to define the only threats to consider, and are instead a way of introducing the concepts to less-knowledgeable groups and encourage reading of the much deeper related materials. But perhaps this is more of a comment about PCIDDSS which specifically mentions these two sources. I wonder.

As you can see, worth the read.

In 2005, the US Federal Financial Institutions Examination Council (FFIEC) published Authentication in an Internet Banking Environment building on their earlier work on electronic banking. A supplement to the 2005 guidance has now been published.

The 2005 guidance recommended periodic risk assessments so that control mechanisms can be adjusted to respond to changing internal and external threats. The guidance stated that authentication techniques should be appropriate to the risks associated with the product or service, but that single-factor authentication is inadequate. It also recommended building customer awareness, and minimum supervisory expectations for authentication controls relating to high-risk online transactions involving customer information and the movement of funds to other parties.

On 28th June 2011, the FFIEC announced its Supplemental Guidance on Internet Banking Authentication to reinforce the guidance's risk management framework and update the expectations for authentication, layered security and other controls in an increasingly hostile environment.

The supplementary guidance reiterates the need for risk assessments and authentication for higher-risk transactions. It also recommends a layered security approach "since virtually every authentication technique can be compromised". Its recommendations for layered security controls include fraud detection & monitoring, dual device authentication, out-of-band verification, positive pay & debit blocks, transactional limits, activity limits, geo-location IP address reputation monitoring, policies & processes for handling compromised devices and malicious users, monitoring of account maintenance activities and customer education.

So, useful information, and not just for internet banking. The guidance is a good reference source for anyone considering authentication controls for access to more sensitive information.

Thank you to Alexis Fitzgerald for bringing this document to my attention.

Whilst on the subject of new information security reports from WhiteHat Security and Veracode, here is another one to add to your reading material.

The 2011 Data Breach Investigations Report examines data from data breach investigations for Verizon's customers. So, a lot wider than application security, but useful reading.

The information about how long it takes from point-of-entry to compromise, and compromise to discovery are interesting. Especially when the vast majority of data breaches are apparently discovered by third parties — not the target of the attack themselves.

Will that be you?

In my previous post, I mentioned the lack of data on return of investment (ROI) concerning building security into the software development life cycle (SDLC). Well after commenting on the Aberdeen Group report earlier this week, another study has been published by Forrester Consulting.

The report State of Application Security - Immature Practices Fuel Inefficiencies, But Positive ROI Is Attainable was commissioned by Microsoft to survey influencial people in software development in the United States and Canada. Appendix B of the report defines the demographics of the 150 people — there is a heavy bias towards people working in the "high tech" industry sector (rather than say financial, utilities or manufacturing) with more than half their organisations having annual revenue in excess of $5 billion including the development of software products and services.

The study examined the secure development drivers, practices, effectiveness and maturity. Table 1 in the report identifies that almost half of the organisations use their own software security methodology, with others using CMM/CMMI, Microsoft SDL, OpenSAMM and DISA STIG.

The conclusions? Most of the organisations surveyed have implemented some form of application security measures, but these are not yet mature and risk is still most commonly transferred from development to operations, where the remediation costs are highest. Tactical approaches with point technologies are less effective than prescriptive application security methodologies applied strategically throughout the SDLC. Those using a more coordinated, prescriptive approach reported a better ROI for application security. However, the ROI for these organisations is not has high as suggested in the Aberdeen Group study.

Last week the UK Information Commissioner's Office (ICO) announced a draft Data Sharing Code of Practice beginning a 12-week consultation process.

The new code aims to provide clear guidance to protect the rights of employees, citizens and consumers under the Data Protection Act when organisations undertake systematic/routine and exceptional ad-hoc data sharing. By improving data sharing arrangements, the ICO hope that both organisations and people can benefit from increased confidence in the processes and reduce the risks to personal data such as from data theft, loss (i.e. data breaches) and unauthorised alteration or destruction. The Data Sharing Code of Practice Consultation Paper explains what data sharing is, the difference between legal requirements and best practice, provides information on security, governance and, for public sector organisations, free of information.

The draft document has been produced in a clear easy-to-read style which will be familiar to those who have seen other recent ICO guidance documents. Where necessary, explanations are included within the text rather than as references external sources (e.g. the eight data protection principles, individuals' rights, ICO powers and penalties).

The document also includes nine short case studies which illustrate data sharing issues, but perhaps further private sector examples, and those related to more common day-to-day activities are required. These might negate the need for an additional Data Sharing FAQs document. Section 14 provides a template for a suggested data sharing protocol between organisations and will be a helpful start for most organisations.

It is worth reading now and responding to the ICO with any suggestions for changes or additions. If it raises questions in your own mind, send those too. An improved document will help you, your suppliers and your customers improve data protection standards and increase awareness. The ICO has produced a list of consultation questions—responses to the consultation can be sent by email or post. The consultation closes on 5th January 2011.

Update 20th October 2010: See follow-up post about companies' powers to share data.

The UK Centre for the Protection of National Infrastructure (CPNI) have published new guidance on understanding and managing the risks from phishing and pharming.

Whilst most readers of this blog won't work on projects considered part of the national infrastructure, that doesn't mean you should ignore good, free advice.

The CPNI document discusses the threats and impacts (on employees, customers, clients and citizens), the modes of attack and possible countermeasures. I'm pleased to see that countermeasures to reduce the likelihood of successful attacks include both technical and cultural measures. Measures to mitigate the effects of successful attacks are also discussed.

Although some of the document is necessarily technical in places, the case studies in Appendix C should make sense to everyone. Remember, this is about business risk, not technical risk. The "I don't understand technical things" argument does not stand up.

Of course, assessing and implementing information security policies and controls is hardly ever simple or quick. But with the government's aim to reduce the number of different web sites this process may be a little easier. It's good to see such guidance, especially when the Central Office of Information (COI) has to date avoided the subject of security in its own web standards and guidelines. In view of the perception that the government isn't keeping up with threats (for example see the response to the petition to upgrade away from Internet Explorer 6), how are the CPNI phishing and pharming countermeasures being implemented by the government?

Knowledge about the degree to which the cultural countermeasures have been adopted within the government sector cannot be adequately measured from outside, and it would be good to see these included in work performed by the National Audit Office. Similarly most of the technical countermeasures would require privileged access to government networks (and permission!). However "use of SSL and TLS" and "signing of digital communications" should be easily observable, without doing any testing, from the outside world.

These two measures have security benefits beyond protection against phishing and pharming. They can assist citizens wanting to verify the identity of, and rely on the integrity of the information they see on what looks like a government web site, or receive in an official-looking email or other form of correspondence, perhaps during a national emergency. These types of event can attract themed phishing attacks for example. I haven't received any official government electronic communications recently apart from reminders from HMRC about tax deadlines and the like, so can't comment on how the sender and data integrity is verified. The tax reminders don't contain any sensitive data, and occur when there are known forthcoming business events or relate to actions undertaken by myself, so correctly don't need the same degree of verification.

But anyone can visit a web site, so what about those? Well, the CPNI web site appears to also be available over SSL/TLS as we'd expect. But, looking at https://www.direct.gov.uk using SSL (now more correctly called transport layer security, TLS) in the Chrome web browser, I was a bit surprised to see:

and this is the same for the prime minister's web site at https://www.number10.gov.uk/. Another possible primary governmental address is https://www.hmg.gov.uk which gives:

Maybe these have been deemed to be acceptable risks. But let's hope the other recommended countermeasures have been implemented.

This year I have mentioned web application security programmes, how software vulnerability testing recommended risk-based, application security programmes and generalised results from a survey about web application security programs.

But what are enterprises doing in real life and what are the issues? During the second day of OWASP AppSec Research 2010, Michael Craigue of Dell presented on Secure Application Development for the Enterprise: Practical, Real-World Tips. Although I missed it, people who did attend this track were enthusiastic about it and the video recording has now been published. I watched it last weekend.

Michael described Dell's 10-strong Global Information Security Services group and how it works with 3,000-5,000 developers in internal teams and how their appsec work is built on a published and maintained secure application development standard. Some of the problems encountered at Dell were platform diversity, security expert retention, the need to develop self-help documentation for the low and medium risk projects, lack of good metrics around security awareness training, high overhead of conventional threat modelling and the need to build security into the development lifecyle slowly, and in a business-focused manner.

At Dell, the project risk is calculated from ten factors including data classification, compliance requirements, whether it is externally facing, and the security knowledge of the development team. Interestingly, in the final questions from the audience, Michael mentioned Dell are using Open SAMM to identify gaps, measure how well their security programme is performing and to focus improvement efforts. Even projects that the group does not get involved with directly, are subject to quality checks and audit such as using Control Self Assessments (CSAs), which look for the artifacts required in the self-help documentation, even for low-risk applications.

There is another description of how software assurance practices at Ford in 2009, and recently published on US DHS's best practices web site Build Security In. The Ford programme is quite different. Every application security programme is unique because every organisation's culture, application and acceptance of risk is different.

What is yours like?

Continuing on the theme of confusing users, Security Dialogs and Graphics discussed the multitude of inconsistent styles for security warnings on web sites, mobile applications and in email.

This is usability hell. Why should each device, browser and application choose how these messages are worded and displayed? I mentioned previously the contributing factor of tab colouring in IE8 and a recent post Tabnabbing: A New Type of Phishing Attack demonstrates how users can be tricked into providing sensitive information to the wrong web site. But it's not just inconsistent technical implementation that matters; the humans in the process matter too.

Last week I came across two web sites in my normal business usage that gave me invalid SSL/TLS secure certificate warnings, and these weren't little businesses that might not know any better—both are multinational enterprises—one a UK bank, and the other a UK mobile phone company.

1. In one case a registration process used a domain www.[subdomain].[company].co.uk whereas the certificate was for [subdomain].[company].co.uk
2. In the other, the company had recently been taken over and the site was using www.[oldcompanyname].com whereas the certificate was for www.[newcompanyname].co.uk

But what surprised me most was the response I received when reporting these problems to the respective site owners. Neither organisation had a clear process for sending details of possible security problems and therefore the responses seem to have been directed through customer support channels.

One provided the initial response:

and:

and even though I re-explained the problem, and that it hadn't stopped me from doing what I wanted:

and then:

and the rather indefinite:

and then back to asking me to supply screenshots, my username and details of my browser:

Mmm.. and still no idea about the issue:

My issue? Their issue I believe.

The other company suggested it was the date/time on my own computer which was the fault:

and some advice about security:

at which point I rang them up, and stumped them by quoting their own tracking number. No further call back from them yet.

I found this all rather depressing. How can we expect customers (end users) to take care with security if the understanding and processes are not in place within the organisation, especially with customer-facing staff? Organisations like Get Safe Online and Card Watch are trying their best to educate people, but the web site owners need to play along too. So here's a quick checklist, including a couple of new items:

1. Obtain your own domain like example.com or example.co.uk (not a sub-domain of someone other company e.g. example.uk.com)
2. Provide security training to web site architects and developers
3. Determine how SSL/TLS will be applied on the site
4. Buy a certificate and apply SSL usage appropriately through the site
5. Verify the proper usage of SSL and session management
6. Verify the correct SSL configuration
7. Include SSL/TLS certificate management in change control processes
8. Provide awareness training to customer support staff about what "secure web site" means and the types of enquiries customers may have
9. Give some basis security advice to customers and direct them to other resources for more information
10. Ensure there is a simple way for people to inform you of security concerns and possible incidents such as phishing, browser security warnings, compromised credentials, account mis-use, etc.

Please—I don't want to have to go through customer support again! At the time of publishing this post, the certificate problems still exist.

Today I was looking around for UK energy providers, and came across this home page from one of the major suppliers:

Can you see what's wrong? I don't think "hello test" should be there. It's not humorous enough to be an April Fool's Day joke, and the page footer suggests the text may have been there for a couple of weeks:

I've mentioned previously test and old pages being found by site searches, but having test content on a PLC's home page is fairly bad. What will potential new customers think? If this appeared in a company's printed brochure, would heads roll?

Was the web site hacked or was it just some poorly thought-out testing? I suspect a hacker might have added something a little bit more malicious than 'hello test' so the implication is the content was added by an authorised person. I'm worried that the live site is being used as a test platform and that content can be added without review or approval. Also, why has site monitoring not picked up on this change?

I tried to "email" the company concerned but their web form insisted I had to be a customer, so I rang a telephone number instead which again asked for an account number. I eventually got through to someone and explained the problem. It's been "passed to the IT Department". Really? Not PR or Marketing?

Don't make it difficult for people with good intentions to tell you about concerns, possible security incidents or phishing emails—help them to do it easily and quickly. You'll benefit. Why do you think food manufacturers try to encourage you to contact them about complaints, rather than leaving you to speak with your local trading standards department?

Update 14:30 hrs: No change yet—let's hope it wasn't a hacker and digital forensics are beginning.

Update 16:40 hrs: The text has been removed.