The exposed surface of an application is often called its "attack surface" or "defensive perimeter". I prefer "exposed surface" since the term is a little less judgemental and I think better implies why we need to be careful about it.

Remember that many security weaknesses come about due to unexpected functionality existing, as well as implementation and design flaws. The number of weaknesses is generally proportional to complexity, often measured as lines of code, or in the context of this discussion, this is often proportional to the amount of exposed surface. The exposed surface of a web application would be all the addresses (URLs), methods (e.g. POST, GET, HEAD) and parameters (form, query string, URL path, cookie and other headers) which the application responds to. Quite often this normally means every possible path and combination of parameters you can throw at it, even if the results is just a "not found" error message.

I was reminded to write about this topic, after reading Essential Attack Surface Management recently on Jim Bird's Building Real Software blog. I like his suggested approach of, well at least making a start, even if it is to focus only on the higher risk areas. Things like search engine friendly paths, dynamic URLs and URL rewriting will cause difficulties, but these are not insurmountable, especially if the site's path naming system can be considered, analysed and defined early in the development process. You might also want to focus on the authenticated parts of the application first.

If you can reduce the exposed surface, or even better limit it to only the necessary entry points, this is a huge step forward in defending your application. Your web application will be a combination of the necessary functionality for your business processes, combined with extra functionality (intended or otherwise), but it also needs to be able to handle other types of request gracefully (e.g. site icon, robots.txt file, missing page tests).

The types of things which are commonly exposed, but should not be are:

• Templates, used by other scripts
• Included code, such as modules and libraries, never meant to be an entry point
• Entry points meant for users with a different role or permissions (e.g. system initiated web services, customer-only content)
• Unused, but included, functionality.

The exposed surface might also include the following things, but should really never exist in web-accessible locations:

• Administrative interfaces
• Logs
• Temporary files
• Configuration files such as encryption keys (yes really), and database connection strings
• Backups
• Default installation files, including help documentation
• Old and archived scripts, test versions of a site, and other unused content.

Some entry points may only be meant for different groups of authenticated users, although there may be some overlap with unauthenticated public users. Every application will be different, but the following attempt to illustrate this for a public website with some functionality used exclusively by authenticated customers.

There are choices on where you enforce limitations on the inbound exposed surface. Some typical places are:

• Network firewall
• Traffic management device
• Web application firewall (WAF), guard or other type of filter
• HTTP proxy server
• Web server
• Application code.

No one of these is the best answer, and in many cases it is better to use a combination of more than one. For example on a web-based content management system, you might use a firewall to limit access from only known office IP addresses, use a web application firewall to limit requests to only well-formed HTTP requests and for known URLs and parameters, use the web server or proxy server to enforce the use of TLS, and let the application enforce the parameter type and range checks, before any business layer authorisation checks and input data validation occurs. The decisions might be different here if requests from internal users do not pass through all the same network devices.

You might even enforce the same restriction in more than one place. For example, you may only open port 443 through a network firewall, as well as having the web server listening solely on port 443, and also the application checking TLS is in use and setting the Secure flag on the session cookie.

But do remember, your web applications will probably also receive requests for entry point URLs that are not on your list, and which are not necessarily malicious, you may have forgotten to take into account, or include unexpected extra or missing parameters. You may want to ensure the web application responds in the correct manner for your own context and user base. Just blocking everything else may not be the correct option.

If you are in a situation of being unable to determine the exposed surface, there are approaches to use application profiling to create a good estimate. At its simplest this may be undertaking a web site crawl, but there has been some work in the area of using web application firewalls to build up a model of the site from actual usage. There is some good information on using ModSecurity for this, and I will try to summarise the information sources in a later post.

Another approach is to fingerprint the page content and monitor for changes such as defacement and cross-site scripting injection. Again, I will look out some references I have for this.

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.

On Wednesday and Thursday 18th & 19th May 2011, I attended the 2nd International Secure Systems Development (ISSD) Conference in London. I had mentioned this previously in March.

Conference organiser Sarb Sembi (Enabled Security) had created an excellent programme, although it is a pity the track on SCADA and embedded systems had to be dropped due to lack of sponsorship. The remaining management and technical/coding tracks benefited from the high-quality chairmanships of Peter Wood (First Base Technologies) and Raj Samani (McAfee), and the strong keynote speakers Carlos Solari (CSC) and Merlin Hay, Earl of Erroll.

I particularly enjoyed the talks by Sebastian Schinzel (Virtual Forge) on "Secure SAP Coding" and "Making Best Use of Static Code Analysis", and by Peter Wood on "Security Testing in Critical Systems" and "Configuration Management Problems and Solutions". They provided practical guidance and advice from working in the field.

Carlos Solari, who authored the EURIM Security by Design Subgroup's paper on Can society afford to rely on security by afterthought not design?, provided an well thought-out, yet entertaining, description of the problems being faced. He outlined a four-layer model called the security stack to illustrate the need for actions at multiple levels, including national cyber response at layer 4.

Justin Clarke (Gotham Digital Science) presented a talk about application security metrics on behalf of OWASP, whilst at the same time I gave a presentation on building active defences into software using OWASP AppSensor. David Harper (HP Fortify) had preceded me and got everyone up-to-speed on secure development lifecycle using Open SAMM.

Raj Samani also presented on the concept and current status of the Common Assurance Maturity Model, an initiative I support and have contributed effort to by creating the security objectives and controls for the Acquisition and Development sub-domain.

As with the best of conferences, some of the most productive time is spent with other delegates in-between the formal sessions. The attendees were knowledgeable and I had a number of useful discussions on issues around designing security in. Keep an eye open for this one again next year.

Microsoft has released their annual update to the Security Development Lifecycle (SDL) Process Guidance.

SDL 5.1 includes several new, updated and promoted controls which probably reflect better more typical design and coding faults. For example in Phase 2 - Design, these have been added:

• Mitigate against Cross-Site Scripting (XSS).
• Apply no-open X-Download-Options HTTP header to user-supplied downloadable files.

In security controls for cryptography:

• Provide support for certificate revocation.
• Limit lifetimes for symmetric keys and asymmetric keys without associated certificates.
• Support cryptographically secure versions of SSL (must not support SSL v2).
• Use cryptographic certificates reasonably and choose reasonable certificate validity periods.

During Phase 3 - Implementation, the following requirements have been updated:

• Use minimum code generation suite and libraries.
• Compile native code with /GS compiler.
• Use secure methods to access databases.

And still in Implementation, the following have been added/promoted:

• Do not use Microsoft Visual Basic 6 to build products.
• Ensure that regular expressions must not execute in exponential time.
• Harden or disable XML entity resolution.
• Use safe integer arithmetic for memory allocation for new code.
• Use secure cookie over HTTPS.
• AllowPartiallyTrustedCallersAttribute (APTCA) review.
• Mitigate against cross-site request forgery (CSRF).
• Load DLLs securely.
• Minimum ATL Version and Secure COM Coding Requirements.
• Reflection and authentication relay defense.
• Sample code should be SDL compliant.
• Internet Explorer 8 MIME handling: Sniffing OPT-OUT.
• Safe redirect, online only.
• Comply with minimal Standard Annotation Language (SAL) code annotation recommendations
• Use HeapSetInformation.
• COM best practices.
• Restrict database permissions.
• Use Transport Layer encryption securely.

And finally in Phase 4 - Verification:

• File parsing.
• Network fuzzing.
• Binary analysis.

There are also some changes to the SDL-Agile Requirements.

So, quite a significant update really, with many good recommendations being added or improved upon. Whatever your programming language, it is worth cross-checking these items with your own coding standards.

The third semi-annual "State of Software Security Report - The Intractable Problem of Insecure Software" has been issued by Veracode (see my previous comments on volume 1 and volume 2).

This report provides even more data on the types of vulnerabilities found and further comparison between applications by industry sector, company type, purpose, supplier type and time to acceptable quality. There is a wealth of statistics which will be useful to anyone looking to reduce software vulnerabilities including developers, testers and those in the information security industry. I'm particularly impressed by the thought that has gone into the design of the data-rich charts and the honesty about whether trends are statistically significant.

One aspect mentioned is that newer applications tested on first time submission are not much better than older ones (in this case "older" means "a year or so ago"). The reasons suggested are either lack of secure development practices, or such practices were performed but inadequately. But I wonder if this may be the result of Veracode's customers beginning to work backwards through their legacy applications, to assess and thus rank them for remediation effort? Therefore, these legacy applications will not have had the same degree of care and attention as perhaps more recently developed software.

The mine of information presented over 50 pages also discusses the relatively low level of security knowledge of developers, and the need to provide better awareness and training. But a new section in this report attempts to examine the remediation efforts. I really appreciate the effort that has gone into this and the presentation of so much data analysis. We have to thank Veracode's customers for allowing their data to be included in this aggregated data.

The report also discusses how there is a growing usage of third-party risk assessments, where the software is assessed independently using multiple testing techniques. In some sectors, software suppliers are increasingly being held accountable for the security quality of the applications they produce. I think that is a good thing.

While there is a comparison of different sectors, I wonder if it will be possible to delve greater into some details in future? For example, some large providers of outsourced development are also active in the software security space, and have their own products for static & dynamic security testing, and even provide software security consultancy services. Do those companies take their own medicine? Do they apply the knowledge and tools they offer in another part of their business in their own software development services? We probably won't find out any time soon, but it would be fascinating to know.

The report's data suggests web applications are still plagued by vulnerabilities such as cross-site scripting (XSS), information leakage and injection (SQL injection as CRLF injection). Meanwhile the most frequently found issues for non-web applications are buffer overflow, error handling and potential backdoors. Cryptographic issues are also very common. The majority of applications tested suffer from these well-known defects, and all of which are well documented and have a range of methods to solve them.

Good reading for the beach this weekend!

SAFECode, a non-profit organisation of some of the major software vendors, has published the second edition of their Fundamental Practices for Secure Software Development: A Guide to the Most Effective Secure Development Practices in Use Today.

The updated and extended 2nd edition is a significant improvement on the previous version, but focuses only on secure design, secure coding and testing stages of development, as well as some separate recommendations concerning technologies. The previous information on training and secure code handling no longer form part of this paper, as they are addressed in other SAFECode publications. Thus the paper concentrates on what SAMM would consider to be constuction and verification functions, and not the governance or deployment functions. But the SAFECode document provides more prescriptive, detailed advice than SAMM. Perhaps only the three secure design principles (threat modelling, use of least privilege and implement sandboxing) are most similar in concept to SAMM's level of granularity; the remaining items would fit well within secure coding guidelines for developers.

Helpfully, the principles, practices and & have been cross-referenced with the Common Weakness Enumeration (CWE) list of software weaknesses, and links to verification resources such as references, tools and tutorials have been provided. It is also probably worth reading the SAFECode paper in conjunction with other guidance on application security programmes e.g. those mentioned previously here and here.

SAFECode has asked for comments and contributions.

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.