I have been exploring further the possible response actions an application might make once it has detected a suspected or actual attack, as a contribution to the OWASP AppSensor project. There is now a draft document describing response actions, discussed and announced last week.

The draft document AppSensor - Response Actions describes thirteen response actions, provides examples of each, and discusses how they might be categorised in order to help with selection of appropriate responses.

It is still a working document. If you have any suggestions or comments on the draft document, please send them to the AppSensor project's mailing list, or perhaps add them below. In particular, I'd like to discuss whether there are any other responses which aren't covered by the ones already included.

There is additional background information and links relating to web application intrusion detection and the OWASP AppSensor project in my posts about presentations in Newcastle and London, but I hope to present again later in the year.

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?

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.

Following a consultation process earlier this year, the European Payments Council has published the first edition of a white paper on mobile payments.

The European Payments Council (EPC) supports and promotes the creation of the Single Euro Payments Area (SEPA). In this white paper, the EPC sets out to present an overview of mobile payments (contactless and remote) for SEPA, and the initiation of of payments via the mobile channel leveraging existing SEPA payment instruments—SEPA Credit Transfer (SCT), SEPA Direct Debits (SDD) and SEPA for Card Payments. Whilst this is not a technical document there is some mention of the security aspects.

The paper describes the business rationale for mobile payment services, example usage scenarios and the business & technical aspects for mobile contactless (proximity) card payments. The payment scenarios include access to premium web content using credit card payments and also direct debit subscription services. If you are scoping out usage scenarios for future services which may involve mobile payment, the descriptions and diagrams are invaluable. Further implementation guidance is expected in due course.

A second edition of the white paper is due in the first part of 2011 that will contain more detailed information about mobile remote payments.

Fed up with false positives when trying to detect malicious users with network intrusion detection systems (IDS)? Application intrusion detection is the way to go.

Like an advanced robot, applications can build in security protection, detection and response.

Next Thursday 15th July 2010, I will be presenting "Real Time Application Attack Detection and Response" at the next OWASP meeting in London. Like all OWASP chapter meetings, the event is free but prior registration is required.

I will talk about how advanced attackers probe and try to exploit applications, how some common defences against these attacks are of no use, and why we need to use protection that:

• understands the application
• understands normal vs. suspicious use
• can identify and shut down attackers in real time.

Is this possible? Yes. AppSensor specifies how application-based detection points can be used to stop attackers. I will also describe how project leader Michael Coates has demonstrated how real web sites can deploy such measures in practice to protect an application against automated scanners, advanced attackers and build in protection against application worms.

Arrive from 17:30 hrs since the talks start promptly at 18:00. Hope to see you there.

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?

It has been common in the past to include JavaScript "frame busting" or "frame killing" code to prevent a web site being displayed inside a frame (typically by someone else's frame).

It is also referred to as a frame killer frame buster. For those with an interest in coding, the type of thing I mean is something like:

<script type="text/javascript">
   if(top.location != location) {
	top.location.href = document.location.href;
   }
</script>

Originally this was mainly related to the concern of other sites framing your own content to make it look like their own. This was common where the frames site also used frames and had little branding on its content pages.

Well frames are used much less for this purpose nowadays but there are plenty of uses for frames in dynamic sites, and there are other problems to consider too such as Clickjacking identified by Robert Hansen and Jeremiah Grossman. So what is it best to use?

The Stanford Web Security Group has published a paper on Busting Frame Busting: A Study of Clickjacking Vulnerabilities at Popular Sites which examines existing frame busting code, ways it can be circumvented and includes a recommendation for current use. The paper is very readable, and easily digested if you are involved with web development.

So what are the recommendations? The paper suggests using the X-Frame-Options HTTP header, and creating a Firefox Content Security Policy, and adding code like:

<style type="text/css">
    html { visibility:hidden; }
</style>
<script language="javascript" type="text/javascript">
    if ( self == top ) {
	document.documentElement.style.visibility='visible';
    } else {
	top.location = self.location;
    }
</script>

This requires JavaScript to be supported and enabled. This may be an acceptable assumption if the site itself relies on JavaScript. But the code uses CSS to blank the content and JavaScript to make it visible, meaning that it could be inaccessible by some (many?) users. The paper's authors believe the code does not significantly alter page rendering or load time. The code is not guaranteed to be a secure approach to frame busting but the authors believe it is the best approach currently.

There is of course no harm in having target="_top" in all hyperlinks and forms, and using the BASEHREF tag and/or full URL in hyperlinks and form actions. If you allow parts of your site to be framed by your own or other web sites, you will need to be more careful how all these anti-framing techniques are applied.

However, I think there could be an adverse effect on public content search engine ranking, due to the use of content hiding, and I do not believe this risk has been examined. If the JavaScript code is used on content which is not meant to be indexed (e.g. registration, log in, password reset and content meant for authenticated users only), this is no longer a risk.

Pass this information on to your development team and ask them what they are doing to protect your web site and its users from framing.

Spring is not just the time for daffodils, lambs and security conferences. The last couple of weeks have seen a plethora of new information security reports too.

Since there are so many security reports, here is a very brief summary of each.

State of Web Application Security

This survey (April 2010) was conducted by the Ponemon Institute on behalf of Imperva Inc and WhiteHat Security Inc. It analyses responses from IT and IT security practitioners in large US organisations about their web application security programs. The findings include that security budgets are not being applied proportionately to the risks with a lack of high-level support for application security.

Security of Cloud Computing Users: A Study of US and Europe IT Practitioners

This new survey (May 2010) conducted by the Ponemon Institute for CA Inc described how many organisations are deploying business-critical applications, IT platforms and IT infrastructure services in the cloud, yet are lacking confidence in their ability to quantify or control the risk. The most difficult risks to minimise were found to be securing the physical location of data assets and restricting privileged user access to sensitive data.

Website Security Statistics Report

The 9th Edition Spring 2010 (May 2010) from WhiteHat Security Inc examines data from a range of security assessments to compare programming languages and frameworks, and the effect of the size of the attack surface on the number of vulnerabilities.

Infosecurity Europe Information Security Breaches Survey

This survey by PricewaterhouseCoopers, formerly conducted for the UK's Department for Business, Enterprise & Regulatory Reform (Now BIS, and launched at Infosecurity Europe (April 2010) examines business information security survey, including controls, incidents and exposures every two years. The 2010 survey highlights the increasing number of attacks on UK businesses (especially on larger organisations) and growing demands for improved information assurance through the whole supply chain.

Symantec Internet Security Threat Report

Symantec's bi-annual analysis of internet attacks, vulnerabilities, malicious code, phishing, spam and security risks. In Volume XV (April 2010) the changing geographical sources of malicious activity are discussed. Although enterprises continue to be the focus of targetted attacks (and in particular those in financial services sector), end users are increasing being attacked at random via their web browsers. Cybercriminals are being aided by more mature malware creation toolkits.

European Country Reports

The European Network and Information Security Agency) has published the 2nd Edition (May 2010) of its Country Reports. The Country Reports were produced by Deloitte, and maps the organisations, government agencies and other bodies, strategies, and good practices in information security in each country (e.g. UK).

Revolution or Evolution? Information Security 2020

Written by PricewaterhouseCoopers for the UK government's Technology Strategy Board, Revolution or Evolution? is a forward look at trends affecting information security and suggests a roadmap of drivers for information security over the next decade. The reports suggests that trust and identity are the key drivers.

Some good reading for the weekend then—no need to buy a Sunday newspaper.

Last week, Symantec published its latest Internet Security Threat Report.

The 95-page report describes Symantec's methodology, findings and recommendations about internet security threats to businesses and individuals. It describes the financial and other losses possible such as damage to reputation and data theft. There is a strong focus on protecting confidentiality and less about how internet threats affect the integrity of data and availability of information systems and business processes.

In the two chapters on Vulnerabilities and Malicious Code Trends, the importance of publicly accessible services (web, mail and FTP) and vulnerabilities in web browsers and web browser plugins in the malware ecosystem are highlighted and recommendations for protecting these servers are provided. The top Web-based attack in 2009 was associated with malicious PDF activity, which accounted for 49 percent of the total.

The chapter on Phishing, Underground Economy Servers, and Spam Trends provides a good insight into how your users may be targetted by third parties hoping to lure them into visiting other web sites. the report makes the important point that "the use of brand(s) in phishing activity can significantly undermine consumer confidence in its reputation". The financial sector continues to be the primary target for phishing attacks, but all types of organisation can be targetted.

Appendix A describes some best practices that businesses (enterprises) and consumers should follow to reduce the risk from internet threats. Many of these relate to using electronic mail and browsing web sites. The slightly more web application related recommendations include employ defense-in-depth strategies, administrators should limit privileges on systems for users, turn off and remove services that are not needed for normal company network operations, test security regularly to ensure that adequate controls are in place, educate management on security budgeting needs, administrators should update antivirus definitions regularly, always keep patch levels up to date, enforce an effective password policy and ensure that emergency response procedures are in place.

A shorter executive summary of the report is also available.