Last week, the European Network and Information Security Agency (ENISA) announced the publication of two guidance documents relating to Article 13a of the new telecommunications legislation (Directive 2009/140/EC) regarding security incidents and security controls.

I don't often quote legislation here, but I thought it was relatively short and provides the intent behind ENISA's guidance. ENISA has published two documents.

Technical Guideline on Incident Reporting provides guidance on the annual summary of significant issues and the notification of cross-border incidents. While most (all?) readers of this blog won't necessarily work in the telecommunications sector, I think the document is useful more widely for two aspects. It demonstrates the type of reporting which could be required if breach notification becomes a requirement for other sector or types of data (e.g. personal data)in the future. Also, the Section 5 on impact parameters and thresholds provides some insight into the continental and national viewpoint on the effects of security incidents.

The second document Technical Guideline on Minimum Security Measures defines the security controls national regulators need to consider when evaluating public communications networks. These are relatively high-level and are grouped into governance/risk management, human resources security, security of systems and facilities, operations management, incident management, business continuity management, and monitoring, auditing and testing. So a clear mapping to ISO27001/2/5 for information security and risk management, and BS 25999 for business continuity.

The UK's data protection agency Information Commissioner's Office (ICO) has updated the previous guidance on the use of cookies and similar tracking technologies, under the revised Privacy and Electronic Communications Regulations which came into force on 26th May this year.

In a press release today, organisations were warned they are not doing enough during the lead-in period to formal enforcement.

The updated Guidance on the Rules on use of Cookies and Similar Technologies provides concrete advice and practical guidance on the legal requirements, their interpretation and what are considered acceptable practices. The guidance was issued as a result of a review of progress to date which shows a lack of knowledge and action from web site owners. Of most concern are likely to be persistent cookies, cookies issued by third parties, cookies issued immediately a user visits a web site, are used for any sort of profiling or which span multiple website hostnames or multiple domains.

If you have any analytics, advertising, tracking or content provision by third party web sites, beware — you may just find the terms and conditions of service state you are responsible for obtaining and managing consent.

If you are a web site owner, take note and act now, if you have not already done so. From May 2012, the ICO will be accepting complaints from users, and will then contact web site owners to ask them to respond to the complaint and explain what steps they have taken to comply with the regulations. Therefore, document what you are doing and the decisions taken.

This week, the Cloud Security Alliance has announced its new repository of security control self -assessments for cloud computing providers.

The CSA Security, Trust and Assurance Registry (STAR) lists providers who have completed and submitted a Consensus Assessments Initiative Questionnaire (CAIQ) or Cloud Controls Matrix (CCM) response to indicate their compliance with CSA best practices.

Currently only two providers are listed, but more are in progress. This will be a very helpful resource for those seeking assurance about controls from suppliers, and potentially standardise the way cloud providers publish information about their security practices, simplifying procurement processes. If you are an IaaS, PaaS or SaaS provider, the existing submissions may help your own controls development or completion of an assessment.

There is more information in the detailed FAQ and LinkedIn forum.

COBIT defines a range of domains, processes and control objectives relevant to to secure software development lifecycle. ISACA has now published a white paper on web application security risks.

Web Application Security - Business Risk Decisions provides an introduction to the security issues relating to web applications and discusses the risks and common security weaknesses. It references other projects and resources that are relevant to web application security.

The paper recommends a systems-based approach which will be familiar to adopters of COBIT and similar frameworks. It emphasises the governance aspects, especially the need for enterprise support. The paper recommends a programme to drive security throughout the SDLC to include:

• Business/executive support
• Training
• Supply chain
• Policies and standards
• Technical controls
• Ongoing programme of scanning/code review
• Legacy code
• Project management
• Effective incident response capabilities

The approach is welcome. IT Auditors can be your friends! It will be interesting to see if this develops into a more formal initiative by ISACA.

The UK's Ministry of Justice published a consultation about the draft Defamation Bill in March 2011.

The Joint Committee on the Draft Defamation Bill was appointed by the House of Commons and the House of Lords in March to examine the Draft Defamation Bill and report to both Houses by 31 October 2011. The report is now available.

Web publishers may want to take note of the suggestions in paragraphs 26 to 30 concerning the protection of freedom of speech. In particular, paragraph 30 notes the need to be able to allow for rapid corrections and apologies, and the potential requirement to be able to attach a notice to the material indicating it has been challenged as libellous.

Also worthy of note may be the recommendations on the single publication rule in paragraphs 58 and 59.

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 the busy Thursday, I returned to the Minneapolis Convention Centre on Friday.

I began the second day of AppSec USA 2011 on the OWASP track, where I was speaking in a session shared with Michael Coates.

Michael described the objectives and current content of the practical OWASP cheat sheet series of documents, which cover the most common web application security issues developers come across and who need accurate, and up-to-date information. The relatively concise cheat sheets are undergoing review, and three further cheat sheets (HTML 5, password storage and web services) are in progress. He also said the full set of cheat sheets are likely to be produced as a single book, as well as being freely accessible on the OWASP wiki (where all these are currently located and available). There was some useful feedback from the audience about the need for another tier of 1-2 page lists/summaries, and that all the cheat sheets should be formatted and structured in an indentical style where possible. Another delegate asked if all the details could be incorporated into the OWASP development guide. And as a last question, one person asked if issues relating to mutual authentication might be addressed.

I then described a different sort of strategy by OWASP, the OWASP Application Security Codes of Conduct project. I adopted these documents which were largely produced during the summit in Portugal earlier this year, to consolidate the work, produce release-quality documents and then promote their adoption. If you remember, these describe what OWASP believes other types of organization could do to support OWASP's mission. While these are aspirational (by OWASP), they do define some minimal normative behaviour, and optional additional recommendations, for government bodies, educational institutions, standards groups, trade organisations and certifying bodies. Excellent feedback from the audience included whether there was a need for prioritised approach for organisations that might fall into two target groups (e.g. educational institution and government body). The audience also asked about the specific requirements for educational institutions and the practicality of achieving them. I will revirew these ideas and post some suggestions to the project's mailing list.

Ryan Stinson provided an introduction to Common Attack Pattern Enumeration and Classification (CAPEC), and how this can be used to help target resources in an implementation agnostic through typical secure software development life cycles (SDLCs). This is easiest when threat modelling is used so that threats can be linked with attacks listed in CAPEC. It provides a way to cross-reference data from different points in the secure SDLC such as requirements, design, development, code review, QA, testing and operations. Switching to Common Weakness Enumeration (CWE), Ryan explained how this describes an overall style of a vulnerability and what challenges developers face relating to these. The taxonomy is extensive and fine-grained. Ryan uses this in his company to link vulnerabilities found during their engagements with the matching CWE issue. This provides additional centralised support resources and demonstrates the relevance to clients.

After a short break, I continued my pursuit of good threat modelling guidance and attended Mike Ware's session on this topic. He explained the need to keep threat modelling simple and described a process built around identifying who, what, where & how, combined with the impact and mitigations. The suggested process needs to involve a range of stakeholders which Mike referred to as the builders (e.g developers, suppliers), gluers (e.g. enterprise architects, CTO, shared service providers), owners (e.g. system, business, data), defenders (e.g. infrastructure, operations), and breakers (e.g. security teams, external penetration testers). The eight-part method includes diagramming the software architecture, enumerating the attack surface, documenting threats, illuminating assets, illuminating trust boundaries, and mitigation. A key take-away was that if you don't have good design information, don't attempt to begin threat modelling.

During lunch Moxie Marlinspike described the problems with trust using the internet, and in particular the difficulty of proving authenticity using SSL. His approachable presentation style won over the audience while he was discussing what might be called a complete failure in the current trust model that relieas on certificate authorities, domain name registrars and top level domain owners. He said that trust agility needs to have the ability for trust decisions to be reversed, and for users to be able to decide where they can place their trust. He described a previous concept called Perspectives but this had problems with completeness, privacy and responsiveness. Moxie went on to discuss his own inititiative called Convergence which could be a new authenticity system for SSL. It uses local caching and notary bounce to avoid the problems Perspectives had, and is designed with future extensibility buit in. There is a plugin for Firefox and this doesn't break the existing model — there is no need for changes on individual (web) servers. I need to check this out further.

After lunch I returned to the software assurance track to attend Adam Meyers' presentation on assessing threats to mobile computing. He described the milestones facilitating the current wave of mobile computing. He said that mobile security concerns relate to all the components (e.g. device, networks operating system, third party applications, browsers & web sites, enterprise applications), limitations (OS API, 3rd party application validation, carrier device authentication, data encryption, mandatory security controls, security updates). He described protections (and lack of) for data at rest, data in motion and voice for each operating system, and the additional personal security concerns, perimeter issues and data ownership concerns relating to mobile computing. Adam went on to explain detection and mitigation concerns due to issues like devices not always remianing on enterprise infrastructure, klack of real auditing for installed applications, difficulty in tracking user behaviour and difficulty in removing malicious code. He then identified the mobile computing attack surface and his most important recommendations for mobile software developers.

Continuing, Charles Schmidt described how to utilise Security Content Automation Protocol (SCAP). He said that even if you have an application with no flaws, no weaknesses and no bugs, it's still not secure. This is because deployment and operational management also matter. Perfect engineering makes an application securable, not secure. He said that documentation is a complete guide to an application, whereas guidance is a set of suggestions for how to configure it for specific use cases. The idea is that there can be automated security guidance, in a format that allows automated assessment of meeting these in the actual environment. This can provide the specific deviations to be identified that can then be assessed, and mitigated as necessary. SCAP is an open standard being used by the US government and others, for this automated guidance. The seven components are connected together by SCAP are:

• Common Configuration Enumeration (CCE) for configurable items in software
• Common Vulnerabilities and Exposures (CVE) for public vulnerabilities in public software
• Common Platform Enumeration (CPE) for identifying software & hardware items
• Common Vulnerability Scoring System (CVSS) to rank vulnerabilities on its likely danger
• Extensible Configuration Checklist Description Format (XCCDF) defining a standard format for security guidance that allow tailoring structures to customise recommendations and assessments
• Open Vulnerability Assessment Language (OVAL) format to express assertions about system state
• Open Checklist Interactive Language (OCIL) standard format for user questionnaires.

Apart from SCAP's well-known uses for vulnerability management, Charles described a use case for an off-the-shelf software package. The guidance for the application and the underlying infrastructure can be built using XCCDF, with OVAL for the low-lying technical checks and OCIL for the non-technical checks. If it is not a public application, CCE and CPE could be used for further annotation. The software acquirers can then use this for initial configuration and ongoing assessment. In another use case for inventory management, users can use the standardised format to be alerted about rogue installations and outdated versions.

For the final session of the day I returned to the OWASP track to listen to Ryan Barnett discussing how the ModSecurity Core Rule Set can be extended to implement some aspects of detection and response from AppSensor. After a brief introduction to the concepts, his dynamic presentation highlighted the pros and cons of building defense logic external to the application, and then how experimental rules have been created for the CRS for many detection points. There are some ideas there I will need to investigate, and make sure I write up for the next version of the AppSensor book.

The conference closed with a final recap by members of the board and the local organising committee. Vendors' prizes were distributed and thanks given to the volunteer organising team in Minneapolis. Yes, the whole week had been run fantastically well, and I hadn't heard any complaints. With over 540 delegates, that's excellent work. A high standard for Austin TX to follow next year.

The next global OWASP events are AppSec Latin America October 4th-7th in Porto Alegre, Brazil, and AppSec Asia November 8th-11th in Beijing, China. The next European AppSec conference will be held in Athens during July 2012.

All presentations will be available on the OWASP AppSec USA web page.

The first keynote speech at AppSec USA 2011 was given by Mark Curphey, a founder of OWASP.

He described OWASP's beginnings in 2001, how the organisation has grown and become the success story it is today. And that success is completely about the people and its open principles. Despite having contributions from all round the world, he described that connecting people in person together, face-to-face, is critical and thus how important the local chapters, local events and regional conferences are. He included a compilation of short videos from chapters around the world. He also saluted many of the exceptional people involved over ten years, and how he believes the application security community needs to keep instead with the trends in the developer community.

The talks were spread over four parallel tracks. Following the morning break, I attended a talk by Andres Riancho on web application security testing payloads. Andres described the lack of post exploitation techniques available in web penetration testing tools. If these do exist, they are mainly in the area of buffer overflows rather than for web exploits where there is often much reduced capability. He showed how W3AF has been extended to build a number of post exploitation payloads, mainly in Linux/Apache HTTP space. He also demonstrated how a custom payload could be used to download an web site's source code where there is a file read vulnerability, and then with a proof-of-concept static code analysis tool, examine that code to look for additional vulnerabilities that may be exploitable to achieve file write capabilities, and thus file execution. This combination of blackbox penetration testing and static-code analysis is a fascinating and useful concept.

I then attended a presentation on the mobile track by Ryan Smith about a distributed framework for performing large-scale android application security analysis called STAAF (Scalable Tailored App Analysis Framework). He described how there are many Android app analysis tools, but these are mostly designed to analyse a single app at a time. STAAF uses these as modules but has additional efficiency, scalability and data analysis capabilities. Ryan described the low barrier to entry for Android developers and the problem with third-party market places from where some users will download and install apps. The mobile devices treat all the apps the same. For users there is no distinction between core apps and third party applications and they can only make decisions based on trust of the source and the permissions requested. In practice this means malicious apps are widely available and downloaded by unsuspecting users. STAAF was built to scale across multiple servers to process scanning requests with centralised long-term storage and results reporting. Modules include extraction of permission requirements, libraries used, referenced static URLs, methods, manifest and Dex bytecode. Efficiencies are obtained by caching intermediate results, data conversion to ASCII, Smali & Java and storing the control flow graph from the Dex. Additionally common libraries and shared resources are not re-processed every time. The framework is bound by CPU power due to database activity, but it appears to have the potential to scan 50,000 apps in less than 8 hours with a relatively small number of nodes.

Next I listed to Scott Matsumoto's presentation on threat modelling for cloud-based services and applications. Threat modelling can be complex, and therefore I am always interested to hear about different approaches. Scott used the NIST Cloud Definition Framework to describe how Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) affect application design, deployment and operation. He discussed the use of Amazon Web Services (AWS) S3 as an example change to an application's architecture to identify the assets, threats and risks of using a cloud-based approach. He described the risks unique to cloud-based applications as well as those that are often very relevant, but are common to other architectures too. There is a related presentation tomorrow, by one of Scott's colleagues, on simplifying threat modelling.

During lunch the OWASP Board described the current healthy status of participation, membership and supporters, chapters, conferences and project activity. Michael Coates is now the new OWASP chair as Jeff Williams steps down after 8 years. The board also announced awards for people who had made special efforts during the previous year,and Michael Coates thanked Jeff Williams for his previous tenure.

After lunch, Dan Cornell described a technique to reduce the exposure time between vulnerability identification to short-term remediation. He explained that when code changes occur, this can lead to vulnerabilities where potential solutions might include web application firewalls, finding all the vulnerabilities and fixing before deployment, or avoiding vulnerabilities in the first place. These all have challenges and problems. His suggested approach for some classes of vulnerability such as injection, is to implement a process to automatically identify new code (e.g. change control processes, file system and network monitoring), analyse this code for vulnerabilities (e.g. using normalised data from manual and automated code review and vulnerability scanning tools) and automatically block traffic that is being targeted to exploit these using virtual patching using IDS/IPS/WAF systems. Once the rules are created, the alerts can be mapped back to the vulnerabilities to provide insight into what attackers have discovered and what they are interested in. These techniques may be of use where you have little or no control over the deployed code, or where it takes a,long time to create and deploy security fixes.

I returned to the mobile track to listen to Kevin Stadmeyer and Garret Held give an information-rich presentation on the security issues relating to iPhone applications, and how to develop these applications more securely. They described the secure storage of credentials and other data, inadvertent local storage, caching, and client-side sanitisation. Following a description of the most common issues, Kevin and Garret defined some secure coding practices to protect against buffer overflows, format string attacks, race conditions, and measures to take server side and to secure communications.

Jon McCoy demonstrated the use of tools and methodologies to verify security in C# .NET applications based on legacy tools and his own research. He used his tool GrayWolf to decompile demonstration executables & DLLs and GrayDragon to attack a test application while running, by modifying the memory. He described that once you have access to the source code, you can examine the protection measures and have much more ability to identify vulnerabilities and thus validate information assurance of deployed code. It is also possible to modify the code or insert calls to your own procedures. For example, he described a range of methods he has used to circumvent cryptographic controls using these tools. He went on to describe measures such as code signing, package encryptors and obfuscation which are used to prevent this reverse engineering, but also described how these techniques can be ineffective or lead to additional vulnerabilities.

The talks continue tomorrow. All presentations will be available on the OWASP AppSec USA web page.

Application Attack Detection & Response is the title of the one-day hands-on training course I am providing at North America's most important application security conference AppSec USA 2011 in Minneapolis, MN.

I mentioned the course in May and since then have been preparing the course presentations, exercises, team handouts and other supporting materials. This week they are now ready and I have been through a dry-run of the whole day. The course is going to be very participatory. I will be presenting information largely based on the OWASP AppSensor Project, but half of the time will be spent on practical exercises which show how to plan a defensive strategy using application-specific intrusion detection and response.

Through the day the attendees will work in small teams building the specification for application-specific defenses of an example web application, in a tutorial-based approach. The course is technology and programming language-agnostic. In fact there is no code at all, but attendees need to be familiar with web application risks, vulnerabilities and the types of techniques attackers use to identify and exploit weaknesses. The exercises will be paper based but electronic templates will also be provided. The day will culminate in a defense simulation exercise, where the teams will score each other's defensive models against a range of attacks. 12 attacks will be selected at random from a set of pre-built scenarios with the code names:

• Slow Discoverer
• Yadda Yadda Yadda
• Hit & Run
• An Offshore Enquiry
• Scratch 'n' Sniff
• A Visit From A Foreign Gentleman
• Nosey Parker
• Coupon Chaser
• Build Your Own Data Warehouse
• Fraudulent Fingers
• Teen Leaver's Delight
• Blast From The Past
• The Forbidden Scriptures
• Slab Fondler's Folly
• Yet Another Hopeless User
• The Thirteen Problems
• Protect and Survive

You will have to be there to discover what these are all about, but perhaps you can guess some of them?

The AppSec USA 2011 organisers have been fantastic, especially Adam Baso and Lorna Alamri of the OWASP Minneapolis-St. Paul (OWASP MSP) chapter. I am really looking forward to the week there.

I believe there are still some places left on the course, so if you want to learn about this topic and leave well-briefed to apply the techniques in your own projects or software specifications, please register as soon as possible. The course begins at 8:30 am. This is the only time this one-day course is being offered in the Americas.

On the following day (21st September), apart from one-day training courses with Robert Zakon and Sumit Siddharth, there will be an AppSensor working session, and ESAPI summit. The conference then runs on the 22nd-23rd September.

Do you remember Lush Cosmetics' rather public payment card data and personal data loss announced in January 2011? After 4 months of being compromised, the problem was recognised, customers were notified and the web site was shutdown.

Lush had allowed people's data to be stolen via its own web site. We still await to hear what the fines and other penalties will be levied under the Payment Card Industry Security Standards Council (PCI SSC) Data Security Standard (DSS) if they are found to have been non-compliant at the time. However the UK's Information Commissioner's Office (ICO) became involved due to the related loss of 5,000 individual's personal data and confirmed in a press release on Wednesday this week that Lush Cosmetics had also breached the Data Protection Act 1998. Formed in 1994-1995, Lush Cosmetics has been a registered data controller (No. Z8189523) since late 2003.

As expected, no enforcement notice or monetary penalty has been issued, but Lush Cosmetics Limited's Managing Director, Mark Constantine, has signed an undertaking to ensure that personal data are processed in accordance with the seventh data protection principle concerning security, and in particular take the following measures to improve the protection of personal, and cardholder data:

1. Appropriate technical and organisational measures are employed, and maintained, to prevent the unlawful processing of customer data, particularly within web based systems;
2. Only the minimum amount of customer personal data is stored and that this is retained only for as long as a relevant business need exists;
3. Computer systems storing customer personal data must be subject of regular penetration testing , with activity logs retained for an appropriate period of time and frequently interrogated for evidence of malicious attack;
4. The processing of customer credit card data is conducted by a PCI compliant external service provider;
5. The data controller shall implement such other security measures as it deems appropriate to ensure that personal data is protected against unauthorised and unlawful processing, accidental loss, destruction, and/or damage.

...as long as the Data Protection Act, or succeeding legislation are in force. So correctly a focus on Lush's web systems, including penetration testing of systems holding personal data. But also other appropriate security measures as necessary. Let's hope Lush aren't left thinking penetration testing is the answer — security needs to be considered at all stages of acquisition, development, deployment and operation.

And yes, that's right, the ICO is insisting on compliance with PCI DSS. The ICO made it clear in the press release of its expectations for PCI DSS compliance by other online retailers, that will otherwise risk enforcement action by the ICO.

This seems to be a valid approach, since fines, investigation costs, etc may still be levied for lack of PCI DSS compliance too. But I have some concerns with how Lush are portraying their squeaky-clean new status in the web site's terms and conditions:

I'm not entirely sure that moving all cardholder data off-site to a PCI DSS compliant third party processor necessarily means much about the security of other data on the Lush web site and elsewhere at Lush, or much about systems outside the cardholder data environment. Is this just meaningless bubbly rhetoric to provide false assurance, or maybe Lush still does not understand what they are doing? Complying with regulatory and contractual mandates isn't the same as believing in "filling the world with perfume and in the right to make mistakes, lose everything and start again". Some of that "honest meaning" mentioned by Lush would be welcome here too.

Personally I think the PCI SSC should be a bit more strict about how their name can be used to endorse systems. Hey, clerkendweller.com meets PCI DSS compliance criteria too! There's no cardholder data to begin with...