20 August 2010

Compliance

Posts relating to the information security principle "Compliance" are listed below.

20 August 2010

Avoiding Popular Passwords

A few weeks ago I mentioned two new research papers about the use of passwords on website. Another new paper from Microsoft Research and Harvard University discusses how to avoid, and protect web sites from, users selecting popular passwords.

Part of the first page from 'Popularity is Everything: A New Approach to Protecting Passwords from Statistical-Guessing Attacks'

The paper Popularity is Everything: A New Approach to Protecting Passwords from Statistical-Guessing Attacks describes online and offline threats and defences against the sue of common popular passwords.

Password implementation policies can be guided by legacy approaches and various standards, but as mentioned previously, economics plays a large part too. Following a much publicised successful brute force against Twitter accounts, the company increased its password requirements. But rather than forcing passwords to be more complex, they instead took the decision to prevent the use of 370 common passwords. Whilst the list is culturally-biased, due to other breaches, there is similar data from other sites (e.g. here and here). But how does banning popular passwords help, and if the lists of common passwords are known, does this matter?

Firstly I'll mention here a couple of typical online tools for determining password complexity:

  • Password meter providing an indication of complexity
  • Hammer of God providing an estimate of how long it would take to obtain the password using a brute force attack

Don't put your real passwords into these sites or any other checkers! But these types of tools do not take into account popularity (e.g. '123456') or common manipulations (e.g. is 'P@ssword' really that much more secure than 'password'?). If attackers try popular passwords first (i.e. a dictionary attack), the time to break into a user's account may be much shorter.

The research paper, which does include some mathematics, suggests that simple passwords should be allowed providing they are not subject to statistical guessing attacks and proposes attack detection methods.

Good reading and inspiration for password-based authentication systems. I'm off to the station now, to get a train to Newcastle which was cancelled last night.

Posted on: 20 August 2010 at 07:00 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

19 August 2010

Software Licensing

Software licensing may not be high on your agenda once a web site is operational. But software licences are an important part of ensuring your web site does not infringe any laws, regulations and contracts.

From 15:30 hrs today, train services from a number of operating companies including East Coast, First Capital Connect and Grand Central are being affected by a line-side fire involving acetylene cylinders near Grantham. This has led to cancellations and delays. But curiously an hour ago, the East Coast web site was showing something a little unexpected—only the words "LicenseException: License has expired." were being displayed:

Browser window showing the East Coast Trains website at http://www.eastcoast.co.uk with only the message 'LicenseException: License has expired.' shown on an otherwise blank white page

Ooops. It is slightly odd that the web site issue is occurring at the same time as the fire—I wonder if it is due to a licence limit being reached caused by high demand from customers checking the status of their trains, or trying to make alternative arrangements. The wording "expiry" suggests it is simply time related, but it does seem a bit of a coincidence.

Doing a quick search for this error message suggests many other web sites have sent this response in the content whilst being indexed:

Browser window showing part of the first page of 162,000 search results for the phrase 'LicenseException: License has expired.'

So that seems unexpectedly common. Interestingly, some of the sites seem to be development or staging sites (e.g. using just an IP address, or using a "staging." sub-domain). These might well have been using temporary licences, but why are search engines allowed access at all, and even if they are, why isn't the robots exclusion standard for compliant crawlers being used?

Apart from the legal aspects, commercial software licences need to be acquired to allow for the total number of installations, processors, usage (e.g. bandwidth) and concurrent users (however the licence is defined) for:

  • peak stress loads allowed to reach the web, application and database servers
  • supporting systems
  • development, testing, staging and production environments
  • clusterering, failover and disaster recovery.

Licensing of all components and third-party services (e.g. data providers, hosting) also need to be considered. Don't just cross your fingers and hope for the best! All types of licence, commercial or otherwise, need to comply fully with their terms (e.g. non-commercial use, one licence per server). Check what happens when licences expire or if limits are exceeded. The situation might occur when most eyes are looking at your organisation.

A lesser related issue is that your own site may be masking the server type quite well, but an error message like this can give the game away. Even if the message doesn't state the type of web server and operating system, another web site with the same message may provide the answer. This can help a malicious user who is probing the site for vulnerabilities.

Shortly afterwards, the normal East Coast Trains web site had returned; much sooner than you would expect if it needed a new licence agreed, purchased and installed. I'm still wondering if it was too many simultaneous users.

I'm hoping the fire is sorted soon so I can travel tomorrow morning, instead of this evening as originally planned.

Posted on: 19 August 2010 at 20:08 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

13 August 2010

PCI DSS and PA-DSS Standards Changes

PCI DSS and PA-DSS standards changes have been pre-announced by the Payment Card Industry Security Standards Council (PCI SCC).

Photograph of an emergency repair van parked on the pavement outside a TK Maxx store in central London; TK Maxx are famous for a credit card data breach in the US

Yesterday's announcement, which also includes notice of changes to PIN Transaction Security (PTS) requirements, provides a summary of the upcoming changes to v2.0 of PCI DSS and PA-DSS due in October 2010. Apart from increased alignment between the standards, the upcoming changes are meant to provide clarifications, additional guidance, new requirements and provide ways to improve organisations' flexibility to implement controls using a risk-based approach. There is also mention of a more forward-looking approach with guidance on managing evolving threats.

The indication that a risk-based approach is to be recommended for assessing vulnerabilities is a welcome change. This of course needs to be undertaken with a real regard of the risks to the business and its customers, clients and citizens, not just the data itself. The references to additional sources of good coding standards and vulnerabilities is encouraging.

The new standards are expected to be published on 28 October 2010 and will come into force on 1 January 2011. This will be quite a tight deadline for many operators to ensure they continue in compliance. The press release also includes details of upcoming meetings and webinars where additional information will be provided by the PCI SSC.

Posted on: 13 August 2010 at 08:36 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

10 August 2010

Phishing and Pharming Protection - Theory and Reality

The UK Centre for the Protection of National Infrastructure (CPNI) have published new guidance on understanding and managing the risks from phishing and pharming.

Some of the text from the Centre for the Protection of National Infrastructure (CPNI) infosec briefing on Phishing and Pharming showing the words 'SSL and TLS are not foolproof: it can be complex for users to interpret information about certificates; there have been technical attacks against the technology; and valid websites using SSL or TLS can be compromised and used for malicious ends. Ultimately, SSL and TLS are a form of electronic identity, and as with all identity schemes can be subject to identity fraud. Nonetheless, SSL and TLS is an essential tool in the fight against phishing and pharming. Heading: Cryptographic signing of digital communication. Similar to the use of SSL and TLS, cryptographic certificates can be used to prove the identity of the sender of an email. Using appropriate software, individuals or complete organisations can be issued with a certificate which they then use to digitally

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:

Screen capture of a web browser showing what is displayed when the website www.hmg.gov.uk is requested over SSL/TLS - it reads 'This is probably not the site that you are looking for! You attempted to reach www.direct.gov.uk, but instead you actually reached a server identifying itself as a248.e.akamai.net. This may be caused by a misconfiguration on the server or by something more serious. An attacker on your network could be trying to get you to visit a fake (and potentially harmful) version of www.direct.gov.uk. You should not proceed.'.

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:

Screen capture of a web browser showing what is displayed when the website www.hmg.gov.uk is requested over SSL/TLS - it reads 'SSL connection error.  Unable to make a secure connection to the server. This may be a problem with the server or it may be requiring a client authentication certificate that you don't have.  More information on this error - Below is the original error message - Error 107 (net::ERR_SSL_PROTOCOL_ERROR): SSL protocol error.'

Maybe these have been deemed to be acceptable risks. But let's hope the other recommended countermeasures have been implemented.

Posted on: 10 August 2010 at 08:45 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

09 August 2010

WCAG 2.0 Coming to More Commercial Websites Soon

Early last year I mentioned the security implications of the Web Content Accessibility Guidelines 2.0 and the scope for accessibility testing. I also spoke about whether an accessible web application be secure at the OWASP AppSec EU09 conference.

Partial view of the start of the US Department of Justice Civil Rights Division's proposal 28 CFR Parts 35 and 36 CRT Docket No. 110; AG Order No. RIN 1190-AA61 'Nondiscrimination on the Basis of Disability; Accessibility of Web Information and Services of State and Local Government Entities and Public Accommodations'

At that time, I found it fairly difficult to identify many web sites that were making WCAG 2.0 conformance claims.

The US Department of Justice is now seeking comments on proposed rule changes to the Americans with Disabilities Act that might make compliance to Level AA of WCAG 2.0 more widely mandated. A full analysis of the legal implications and timescales are presented on the Outlaw web site. As we see increased take-up in the US, it's likely similar levels of compliance will be required elsewhere.

In my conference presentation, I discussed how some security vulnerabilities could occur if WCAG 2.0 is implemented poorly.

Posted on: 09 August 2010 at 18:31 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

06 August 2010

E-Consumer Protection Consultation

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.

Photograph of a tag label lying on the ground - it has the word 'SECURITY' written on it

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.

Posted on: 06 August 2010 at 09:02 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

03 August 2010

Real World Enterprise Application Security Programmes

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.

Photograph of a circular gauge labelled 'synchronisation meter' with a pointer sitting between 'slow' and 'fast' marked on the face, from the London Transport Museum in Covent Garden

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?

Posted on: 03 August 2010 at 09:00 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

27 July 2010

When is a Vulnerability not a Vulnerability?

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?

Non-vulnerability based threats aim to exploit weaknesses in server applications that cannot be defined as vulnerabilities.

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.

These attacks go unnoticed by existing protection technologies and can result in information theft, fraud activities and service disruption.

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.

Posted on: 27 July 2010 at 09:29 hrs

Comments Comments (1) | Permalink | Send Send | Post to Twitter

23 July 2010

Mobile Web Application Best Practices (Draft)

Mobile Web Application Best Practices has been published as a last call working draft by the W3C Mobile Web Best Practices Working Group.

Partial image from the header of the W3C 'Mobile Web Application Best Practices'

Mobile Web Application Best Practices is intended to to aid the development of rich and dynamic mobile web applications. It includes guidance sections concerning application data, security & privacy, user awareness & control, (conservative) use of resources, user experience and handling variations in the delivery context.

The document defines "web application" as:

A Web page (XHTML or a variant thereof + CSS) or collection of Web pages delivered over HTTP which use server-side or client-side processing (e.g. JavaScript) to provide an "application-like" experience within a Web browser. Web applications are distinct from simple Web content (the focus of BP1) in that they include locally executable elements of interactivity and persistent state.

However it also states the 32 best practices are equally applicable to other kinds of web run-time, such as widgets and vendor-specific initiatives.

Unfortunately there is only one recommendation relating to security & privacy. If I had to choose just one security or privacy aspect to raise with mobile web application developers, I don't think it would be "Do not Execute Unescaped or Untrusted JSON data". From a business risk point of view, injection flaws would probably be my choice, and that may also be the same from the user's perspective. Worrying about privacy options is irrelevant if someone can steal all the information from the databases. Of course choosing just one is difficult but I believe additional, perhaps broader, guidance is needed here.

The W3C are seeking comments on the document which should be sent to public-bpwg-comments@w3.org before 6th August 2010. There are specific instructions for feedback from mobile web application implementers.

Posted on: 23 July 2010 at 08:39 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

20 July 2010

Payment Card Data Tokenisation

Visa Inc has released a guide to Card Data Tokenization Best Practices.

partial image of the cover from Visa Inc's 'Card Data Tokenization Best Practices, Version 1.0', July 2010

The intention is to provide guidance on using non-sensitive surrogate values (tokens) as a proxy for card data (typically the primary account number or PAN) by merchants, vendors, service providers and acquirers. This in turn can reduce where card data exists, and therefore the scope for compliance with the Payment Card Industry Security Standards Council (PCISSC) Data Security Standard (DSS). The guidance joins other information in Visa'a Cardholder Information Security Program (CISP).

The guidance describes Visa's best practices for the tokenization system, token generation, token mapping, the card data vault (the secure repository that maps tokens to cardholder data), cryptographic key management and the management of historical data.

However the guidance may not generally accepted and is being debated here and here, especially with regards to reversibility of the process and the use of salts when hashing, but Visa are seeking feedback on this first version, and have asked for responses by 31 August 2010 to be sent by email to inforisk@visa.com.

Posted on: 20 July 2010 at 10:57 hrs

Comments Comments (0) | Permalink | Send Send | Post to Twitter

More Entries

Compliance Security Principle : Web Security, Usability and Design
http://www.clerkendweller.com/Compliance
ISO/IEC 18004:2006 QR code for http://clerkendweller.com

Page http://www.clerkendweller.com/Compliance
Requested by 38.107.191.109 on Friday, 3 September 2010 at 04:31 hrs (London date/time)

Please read our terms of use and obtain professional advice before undertaking any actions based on the opinions, suggestions and generic guidance presented here. Your organisation's situation will be unique and all practices and controls need to be assessed with consideration of your own business context.

Terms of use http://www.clerkendweller.com/page/terms
Privacy statement http://www.clerkendweller.com/page/privacy
© 2008-2010 clerkendweller.com