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.

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...

The ecosystem of malware production and infection may not be of interest to everyone, but a new report from Symantec provides a great insight, if you are interested or need to know.

Attack Kits and Malicious Websites (report PDF) describes attack methods, kit types and the evolution of these crimeware kits. The features and method of traffic generation are discussed, together with an excellent section on the prevalence of attack kits, malicious web sites and attack kit popularity. The top three most attacked vulnerabilities all affected web browser plug-ins, and out of five unpatched vulnerabilities used, five of these affected browser plug-ins; and all of these could be used in drive-by malware installation where a user only has to visit a page without any other action required.

Note that the web sites hosting the malicious code are a combination of intentionally malicious web sites, and legitimate web sites which have been compromised for malicious purposes.

The report includes some advice for systems administrators and end users on protective measures, although it is light on advice for preventing your own web site becoming compromised.

If you are interested in cyber fraud or how to detect it, and want to read more extensively, I'd recommend Cyber Fraud: Tactics, Techniques and Procedures, Auerbach Publications, 2009 (ISBN 978-1-420-09127-1), and Detecting Malice, Robert Hansen, SecTheory, 2009 (ISBN 978-0-557-18733-1).

The European Network and Information Security Agency (ENISA) has published a report on "Data Breach Notifications in the EU" to support the introduction of mandatory personal data breach notification following the EU Telecommunications Regulation Reform Package in 2009. That legislation requires the new rules to be transposed into the national laws of the 27 member states by May 2011.

The report will not only be useful to public authorities such as data protection agencies (DPAs), but also for those in the electronic communication sector directly affected by the legislation — communications providers including telecoms companies and internet service providers (ISPs). It will also be of use to any organisation developing policies and processes in the area of internal or external notification, regardless of whether r not there is a legal requirement.

The report is largely based on the results of a survey of 46 organisations conducted using interviews and questionnaires. The organisations primarily included DPAs, telecommunications operators and some other private sector organisations located in Europe. There is a good description of the legislative background including examples of existing local requirements/guidance in Germany, Ireland, Spain and the United Kingdom. In the UK, there is currently no legal duty to notify breaches (see ICO guidelines), but other mandates such as contracts, policies or requirements of trade organisations might dictate otherwise. There is a also a summary of working definitions and criteria for personal data, data subjects and data breaches across Europe, which is not as homogenous as you might hope.

The chapter about the private sector provides a good insight into operators' existing notification practices and incident handling procedures. It also examines the divergent objectives between regulatory authorities and the private sector. Remember that "breaches" are not only incidents relating to data loss. All aspects of privacy legislative contraventions need to be considered.

The ENISA report concludes with a list of aspects requiring further definition to simplify the transition to mandatory notification, and to ensure better harmonisation across the member states. Time may be against all these occurring before May 2011.

Other sectors - keep watching!

Application information gathering such as enumeration of directories, files and other resources are a type of forced browsing and which may be made easier by using predictable resource locations.

Some requested URLs are likely to be an attacker exploring the application or trying to find a published vulnerability:

• /.htaccess
• /index.php?file=../../../../../../../../../etc/passwd
• /plugins/editors/tinymce/jscripts/tiny_mce/plugins/tiny...
• /statistik/usage_201007.html
• /sumthin
• /FormMail.pl

If these do not exist, they may raise a 404 status error, and be listed in web and application error logs.

As part of my presentation at AppSec Washington DC in two weeks time, and the related guidance document, I wanted to provide examples of URLs which publicly exposed web applications may receive for non-existent resources (and thus generate a 404 status error), but which are not necessarily malicious and probably not even suspicious. This is important because one of the primary benefits of application level intrusion detection and prevention is its very low false positive rate (falsely identified attacks).

If URLs are requested which do not form part of the allowable entry points to the application, what does that mean? An attacker might be undertaking reconnaissance, testing defences or looking for vulnerabilities—just the types of things an intrusion detection system should be looking for. However, they may be benign requests.

In the tables below, I have set out 20 common types of non-malicious unexpected missing file URLs which most public web sites could receive. If the site is not exposed to search engines and external parties, this list will need to be shortened.

Type A: URLs that Should Not Exist

The first type is URLs that are requested with the premise the page/file does not exist.

Type B: Assumed Valid URLs

In this type, URLs are wrongly assumed to exist but are requested nevertheless.

Type C: Incorrect URLs

Some URLs are not, and never have been, valid entry points but are requested normally due to a user's mistake of some sort such as a transcription error.

Type D: Testing

Your own functionality and security testing, or testing services performed on your behalf, will request URLs that do not exist. These might also be considered benign if the scanning is authorised and from a known source.

Some of these could be being requested by an attacker, but they are usually not enough to identify one—Type D from an unknown source, or unauthorised, should not be assumed to be benign. Items such as incorrect case, truncation and mis-spelling (Type C) cannot be predicted in advance, but if they occur it may be necessary to add custom redirections to the correct URLs.

If you have further suggestions and examples, please share them. Tomorrow, I will extend the discussion of benign URLs to valid (non-missing) URLs.

Update 8th November 2010: Following a direct message, I have added /trackback and URLs referenced by client-side style and code libraries. Link to 'Tomorrow' enabled in last paragraph.

October 2010 is the (US) National Cybersecurity Awareness Month but cyber security is also a topical subject in the current news coverage about data theft overtaking physical property losses, identity fraud in the UK and spending priorities in the UK's defence budget and the National Security Strategy: A Strong Britain in an Age of Uncertainty released yesterday by the Cabinet Office.

Intrusion detection and prevention systems are an important complementary aspect to secure development processes. As previously mentioned, in a couple of weeks time I will be speaking about how to implement application attack detection and response using OWASP AppSensor at AppSec Washington DC 2010. When I presented an introduction to AppSensor at the June event of OWASP Leeds/North in Newcastle-upon-Tyne, the subject of how to choose detection points, implement them in an application and configure responses was asked. In Washington, I will be providing a methodology and tools to assist with these tasks.

AppSensor's techniques are useful tools in the armoury for the protection of software and data assets, and have the advantage over conventional network and host intrusion detection systems of having full knowledge about the business logic and an extremely low false positive rate. AppSensor aims to protect the application, the users and user & business data. AppSensor doesn't care about the identity of who is attacking, when they are going to attack or where they are coming from. It is an impartial guard waiting to act.

Building defences into applications in this manner makes sense for systems relating to critical national infrastructure and for business applications organisations which are crucial to operational processes.

The Web Hacking Incident Database 2010 semi-annual report was published in early September. I have only just managed to find time to read it.

This latest report for January to June 2010 analyses actual reported incidents (e.g. data breaches) collected by the Web Hacking Incident Database (WHID), a project of the Web Application Security Consortium and supported by Trustwave SpiderLabs. The WHID's goal is to raise awareness of the web application security (webappsec) problem and provide information for statistical analysis of web application security incidents. The data only include disclosed and reported targetted (i.e. non-random) attacks against specific organisations (see Zone-H for wider data on random or opportunistic defacement hacks).

The information is very clearly presented and includes attack source geographic location, the drivers (outcomes), attack methods, weaknesses exploited and organisation type. It will be very useful for risk and security professionals who want to prioritise resources protecting their web sites, applications and the associated data. In case you haven't guessed "SQL injection is still the top known attack category".

If you haven't seen them yet, the "real-time" interactive charts on the project's home page are fantastic. Other ways to keep up-to-date are using the RSS feed or Twitter.

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.

I have been meaning to write again about web application security logging, but luckily read a paper last week which provides excellent guidance.

How to Do Application Logging Right is the best guidance I have come across to date. Co-written by Anton Chuvakin and Gunnar Peterson for the IEEE Security & Privacy Journal, the paper describes the problems with typical logging systems, what events need logging, and for those, what to include and exclude. They have also provided some broader guidance on log management and protection.

Previously, the most notable application security logging guidance existed buried rather deeply in the documentation for OWASP's ESAPI Java edition, the OWASP Logging Project, and more general guidance in NIST's SP 800-92 Guide to Computer Security Log Management.

If you read those in conjunction with the new paper, and perhaps Chuvakin's and Peterson's own comments, you'll be well up to speed.

The content of the "module", "object" and "action" fields will be dependent upon the degree of granularity required and how much additional event information is collected as additional details (e.g. stack trace, request headers, response body). I believe a transaction ID should always be included so that all events for a single request/response can be more easily correlated—this has a request scope rather than the session scope of a username/id. If I might suggest some other additional items for "what to include", I would also consider:

• host address (e.g. host name and domain, or server IPv4 or IPv6 address) which is useful if clustering is being used, or to confirm logs are from live rather than staging systems
• service (e.g. name, port and protocol)
• full actual entry point URL (protocol, full domain, port, path and further parameters)
• canonicalised entry point URL
• HTTP method (for web applications)
• responses seen by the user and/or taken by the application (e.g. status code, custom text messages, session termination, administrator alerts)
• analytical confidence in the event detection (low, medium, high or a numeric value).

Full request headers and possibly the response body may be worth collecting for some events. But ensure these are sanitised for sensitive input such as passwords, session cookies or credit card numbers.

I would also tend to use a severity scale (0=emergency, 1=alert, ..., 7=debug) rather than the suggested "priority" field, for consistency with syslog protocol. But the paper's authors note that whatever scale is used, it will be different for each organisation due to their own priorities and views on risk.

You may also want to consider how the integrity of the logged information can be determined.

Whatever you log, bear in mind you probably want it to be relatively human-readable, but also done in a way you can share the information with other systems. For the moment, consider Common Event Format (CEF). But Common Event Expression (CEE) is an ongoing collaborative effort to develop an event interoperability format summarised in a presentation, and in more detail in a white paper. The CEE web site includes a description of alternative approaches for sharing data from event producers.

See also my previous web application logging related posts How Much Logging, Monitoring and Alerting?, Security Logging Requirements, Testing the Audit Trail, Don't Stop the Attack (Too Soon), and Application Log Management and Analysis.

Happy application logging!

The UK's Office of Fair Trading (OFT) promotes and protects consumers' interests by ensuring markets work well, and that businesses act fairly and competitively. The government has asked the OFT to develop a longer term national strategy for consumer protection and enforcement on the internet. The strategy is intended to promote a safe and vibrant internet market.

As part of this strategy development, the OFT has launched a consultation on E-consumer Protection. The objectives are to improve the effectiveness of online markets and increase the level of consumer trust, so that consumers have a real option to use the internet for transactions, as equally as any other channel. The aim is also to ensure that enforcement of consumer protection online is as good as anywhere else in the world.

The main consultation document outlines some useful statistics about the UK internet economy using data from the European Commission's Consumer Markets Scoreboard 2010, the OECD and the OFT's Attitudes to Online Markets (publication due shortly). For example, 71% of the UK's retailers use e-commerce/internet sales channel for retail, and internet/online accounted for 9.5% of UK retail trade (£38 billion) in 2009. Apparently UK consumers have a high level of trust in UK sellers/providers' protection of their consumer rights and that they are adequately protected. However, it is not all good news as almost 20% of UK internet users are not transacting online, with a third of these stating concerns about the security of their personal and financial information as the reason. Overall, two-thirds of all internet users are worried about unauthorised access to their personal information. There are also concerns about being conned by companies online. The consultation document outlines how consumers may be becoming complacent about security but that they lack awareness of issues such as mis-use of cookies and behavioural advertising.

The OFT suggests these problems reduce confidence, lead to lower levels of demand, and consequently lower levels of supply. Households can miss out on potential savings and this is especially problematic for low income households (LIH). The consultation document proposes that agencies should work together to empower consumers, promote business compliance and develop effective enforcement. It proposes a number of high-level actions under the themes of consumer education, tool provision and hardening, business information, cooperation and deterrence, and enforcement capability building, coordination and leveraging intelligence.

The outcome of this consultation will have a large impact on organisations in the business-to-consumer (B2C) sector (there is also some discussion of whether C2C should also be addressed). If you are an online retailer, perhaps get in touch with your trade organisation and ask them whether they are responding, or do so yourself.

There are five general response questions, and further more-detailed questions about the high-level actions and monitoring proposed. Responses can be submitted online, by email and by post. The consultation period closes on 13th October 2010.