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?

Until this week, I had thought this question would be answered by checking the vulnerability could be exploited and by determining whether there was any technical or business impact.

But I have just finished reading the Summer 2010 edition of Information Security Now, the quarterly magazine of the BCS Security Forum, incorporating the Information Security Specialist Group. One of the articles forced me to stop and think.

The article titled "Attack Spotting" describes the motivation for modern attackers and in particular attacks on application software. But the author introduces the idea of "non-vulnerability attacks". Just what might they be?

I was even more confused. I thought a vulnerability was any weakness that could be exploited by a threat (and a similar definition). The article's author goes on to describe that in "traditional vulnerability-based attacks", there is always the possibility of creating a signature to block the attack or of developing a patch for the application. In "non-vulnerability-based attacks" the author says there is no malicious payload and therefore it is not possible to create an attack signature or patch. The author helpfully provides three examples of non-vulnerability attacks:

• Brute force attack on authentication
• Web application vulnerability scanning
• Service flooding which exhaust server resources

No, no, no! These are all attacks against real vulnerabilities. These three are listed in Common Weakness Enumeration (CWE) (e.g. CWE-307, CWE-200 and CWE-410) and real examples are listed in Common Vulnerabilities and Exposures (CVE). The examples also fall into categories in the Web Application Security Consortium 's Threat Classification.

I have to disagree that these attack methods are new, and that they are not being detected. I may have misunderstood the article, but I believe there is plenty of guidance on building applications securely, security verification and for testing for these types of flaws. I also disagree with the article author's suggestion that the answer lies with expert systems to perform network behavioural analysis (NBA). Why bother? The application already knows right from wrong and doesn't need to guess. Implement application-based intrusion detection and prevention, on top of secure code, and benefit from very low false positives. At least, that's my view.

So, perhaps if it depends on your viewpoint. Maybe some traditional security folk see this other stuff as black magic? I hope not.

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?

I read the Following the White Rabbit blog which had a special series on web application security whoops in April. I've had too much else to write about, so only just got round to mentioning it here.

If you haven't read all thirty of the month-long "Whoops" series, I'd recommend them to you. Many things can go wrong designing, developing, testing and verifying web applications, but my personal favourite whoops are:

• Episode 7 - "The Spider That Ate My Site!"
• Episode 10 - "Just Another File-Upload Bu...whoa"
• Episode 17 - "1 Million Emails"
• Episode 18 - "Loyalty, Free"
• Episode 30 - "But wait! there's more!"

Keep up-to-date with more web application incidents by subscribing to the Web Hacking Incident Database (WHID) RSS feed from the Web Application Security Consortium.

We can all learn from by sharing incident data.

Security Development Lifecycle for Agile Development has now been added into the latest release of Microsoft's Security Development Lifecycle (SDL) Process Guidance.

SDLv5, issued on 31 March 2010, includes the Agile guidance first published in November 2009. This provides advice on applying lightweight software security practices when using Agile software development methods, such as Extreme Programming (XP) and Scrum.

Additional changes particularly relevant to web applications include:

• Use ViewStateUserKey or ValidateAntiForgeryTokenAttribute to add a layer of defense against Cross-Site Request Forgery (XSRF) attacks.
• Conduct an integration-points security design review with dependent product teams across your end-to-end scenarios.
• Strong log-out and session management. Proper session handling is one of the most important parts of Web application security.
• Include third-party code licensing security requirements in all new contracts.
• Use secure methods to access databases. Creating dynamic queries using string concatenation potentially allows an attacker to execute an arbitrary query through the application.
• All HTTP-based applications that use cookies must specify HttpOnly in the cookie definition for all cookies not explicitly required by legitimate scripts in the Web page.
• Internet Explorer 8 MIME handling: Sniffing OPT-OUT. This recommendation addresses functionality new in Internet Explorer 8 that may have security implications in some cases. It is recommended that for each HTTP response that could contain user controllable content, you utilize the HTTP Header X-Content-Type-Options:nosniff.
• Identify any ActiveX controls, new and existing, that can be locked to a preselected set of domains, and incorporate the SiteLock 1.15 Template for ActiveX Controls during implementation to lock each control to that set of domains.
• ClickJacking defense. For each page that could contain user controllable content, you should use a "frame-breaker" script and include the HTTP response header named X-FRAME-OPTIONS in each authenticated page.
• Use a passive security auditor. Use Watcher and Fiddler to detect vulnerabilities.

There's plenty more to read though.

The first report on the state of software security has been published by Veracode who provide a cloud-based application risk management service.

The data presented in State of Software Security Report - The Intractable Problem of Insecure Software are interesting, it relates to both web application (40%) and non-web application (60%) software but spans in-house developed, commercial, open source and outsourced, developed in .NET, C/C++ and Java. But don't get bogged down in the data. I'd recommend that everyone responsible for web development, or who commissions or operates a web site, read the executive summary. I was quite surprised that backdoors (a method of bypassing normal authentication) are still a significant issue: "Open Source projects have ... fewer potential backdoors than commercial or outsourced software". This is why "V13 Malicious Code Search Verification Requirements" appears in the Application Security Verification Standard.

There are seven recommendations, which are in summary:

• Implement a comprehensive, risk-based, application security programme.
• Implement security acceptance criteria for third-party suppliers.
• Test code from outsourced, commercial and open source suppliers as rigorously as internally developed code.
• Verification of C/C++ code must not be ignored and it is likely to be present in many applications.
• Implement specific developer training on security.
• Learn from organisations in higher-risk sectors such as finance and government.
• Ensure security requirements are built into outsourced software development.

Some good advice there. The report provides a fuller description and gives the background to these recommendations.

I guess there must be much more detailed data available to Veracode than is presented in this "Volume 1". Perhaps Volume 2 will look at trends over time, but I'd also like to see:

• Breakdown of root causes (e.g. unvalidated user input).
• Breakdown of how the vulnerabilities had been fixed when the software was re-tested (e.g. parameterized queries implemented).
• What proportion of faulty code was identical — found in more than one application (i.e. copied/duplicated from elsewhere).
• Details of any secure development lifecycle in use by suppliers and their level of maturity with these.

Hopefully this type of aggregated data can be shared under Veracode's terms of service and agreements with individual customers. The software suppliers included in Veracode's analysis are likely to exclude customer organisations who do not have the knowledge or resources to have their code analysed. It would be an interesting research project to test a selection of applications developed by other suppliers to see how they compare.

Look out for the busy schedule of upcoming Open Web Application Security Project (OWASP) events.

This Thursday 5th November, the next OWASP London meeting is taking place. There will be a presentation about using Selenium to hold state for web application penetration testing, and a discussion of the chapter's activities and plans. Advance registration is required, but there is no charge.

Also on 5th November in Rome, there is Italy OWASP Day E-Gov 09 for public administrators, and the day after on the 6th in Milan the Italy OWASP Day IV.

Then next week, AppSec 09 is taking place in Washington DC, United States, with two days of training courses, an OWASP summit for the OWASP board, project leaders, chapter leaders and global committee members. The main conference has 4 agenda tracks about OWASP, tools, Web 2.0 and software development life cycle, and 4 further tracks on the second day encompassing Attack & Defend, Process, Metrics and Compliance.

In December there is the BeNeLux OWASP day in Leuven, Belgium, at which I am speaking about compliance driven vulnerabilities.

If web application security is an area of interest, try to get along to one or more of these, or download the presentations after the events.

Last week I discussed the business case for web security and how this is necessarily organisation-specific.

If you use common IT investment models, you may want to look at the paper Business Models for Assurance on the US Build Security In (BSI) web site. But what are real organisations spending?

Sources of data to compare yourself with are very rare and it's good to see the second quarterly report on Web Application Security Spending Benchmarks. This quarter, the report has a special emphasis on three aspects of cloud computing:

• Infrastructure-as-a-Service (IaaS)
• Platform-as-a-Service (PaaS)
• Software-as-a-Service (SaaS)

This type of benchmarking is really useful. Years ago, I helped with some work on benchmarking water usage across UK industry sectors—without this type of initiative it is difficult to determine whether what you are doing is reasonable.

It can be hard to justify business spending when web sites are often viewed as low-value assets. The fact that so much Internet content and services are free, and you can buy a web site for less than the cost of a colour TV licence in the UK reinforces this idea in many small and medium enterprises (SMEs).

Much of my work is related to dealing with security incidents, such as web sites which have been hacked, or where an organisation is having security requirements imposed by their own customers and clients. Often these activities are undertaken late in the project and are therefore less effective, and more costly, than they might need to be.

I adhere to the principle "prevention is better than cure", and encourage the early consideration of security and privacy matters—just like any other business process requirement. It was encouraging to read the useful guidance and pointers on Business Cases For Software Security Initiatives but for many organisations, the issues are too complex and they don't have any supporting data. For those I recommend, as a starting point, concentrating on four types of issue:

1. mandatory compliance issues (e.g. legislative and contractual)
2. problems which can assist theft or fraud
3. security events which would be severely disruptive and possibly put the organisation out of business
4. issues for customer trust and ongoing reputation

It's always organisation specific though. As organisations mature, they can be encouraged to look at wider security issues—but, let's get the basics right first.

Blind adherence to methods without using professional judgment is commonplace across all work sectors.

Just because a system is out-of-date, not supported by the supplier or contains known security weaknesses, doesn't mean it has to be rebuilt or replaced.

An article in The Chemical Engineer April 2009, by Harvey Dearden, discusses professional judgement and reproduces the following statements from the UK Engineering Council's Code for Professional Conduct regarding risk issues:

and:

The first statement could easily be re-written replacing "hazard" and "safety" with "threat" and "security" respectively. The second is equally true for assessing application security risks. However, in security engineering we do need to be aware of the lack of good statistical data to help form valid judgements.