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.

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.

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?

Two great papers on web site password security were published this month. We are swamped with passwords and every daily activity is increasingly linked with an online version, which requires users to register to obtain some additional benefits. Every organisation, resource, activity and event encourages us to visit their own website and sign-up.

Firstly, in Where Do [Password] Security Policies Come From?, Dinei Florêncio and Cormac Herley of Microsoft Research discuss the password policies of 75 different web sites, in an effort to determine password strength requirements with other aspects such as size of site, assets protected, number of users and frequency of attacks.

The authors' findings suggest that none of these are the key factors, and in fact some of the largest sites, most attacked and with higher-value assets have the weakest password policies. The authors suggest stronger policies exist where organisations are more insulated from the consequences of poor usability, whereas online retailers and sites that rely on advertising revenues have to compete rigorously for users and traffic. The paper also discusses how strong passwords need to be, and how this is affected also by what attack methods you are considering (e.g. online vs. offline brute-force), and whether other security controls are implemented (e.g. account lock-out).

This idea of considering the whole password environment is taken further in The Password Thicket: Technical and Market Failures in Human Authentication on the Web by Joseph Bonneau and Sören Preibusch at the Cambridge University Computing Laboratory, and presented at this year's Economics of Information Security (WEIS 2010). Their study included 150 web sites looking at password implementations. the study looked more broadly at the protective measures used— not just complexity requirements—but whether these were applied consistently across the site's functionality (e.g. registration/enrolment, log-in/authentication, password change, password reset/recovery, log-out), encryption during transmission, storage of passwords in clear text, inclusion of passwords in emails, as well as protection from brute-force attacks.

The authors found that stricter security in one area was often undermined by weaknesses in another, suggesting that a lack of standards is harming security. The paper also discusses economic interpretations, such as how deploying passwords might be being used to justify collection of marketing data, and how password insecurity can be a negative externality.

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.

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

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:

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.

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?

Last night, after the first day of the OWASP AppSec Research 2010 conference, we had the pleasure of attending the conference gala dinner at the lavishly decorated Stockholm City Hall, also used for the annual Nobel Prize award ceremony.

Steve Lipner (Microsoft) gave the keynote speech today. He described the early step, creation and evolution of Microsoft's Security Development Lifecycle (SDL). This began in early 2002 which included team-wide security training, the introduction of early threat modelling, code review, use of some tools, undertaking security testing and modifying software defaults to make them more secure. These were seen as quick wins but were immature and ad-hoc processes. They then worked on the security "science" and "security audit" to build a more robust and repeatable program leading to the first edition of the SDL in 2004. It is regularly reviewed and updated and version 5.0 was released this year and 5.1 is due in October 2010. Whilst the SDL is based on Microsoft's own experiences and culture, he said it can be applied to non-Windows development, it does not rely on Windows tools and is not just for shrink-wrapped software development. Neither is it only suitable for waterfall or spiral development methodologies; the application of SDL to agile processes has been described recently. But the most important point he made is that SDL at Microsoft is not necessarily what will work in other software development teams—it is a very helpful starting point, but requires commitment and time to create processes and apply these consistently.

Immediately following the keynote speech, Pravir Chandra (Fortify and OWASP SAMM Project Leader) outlined the Software Assurance Maturity Model (SAMM) and lessons learned in its application to real software development programs. He emphasised the need to identify and classify all applications by risk, to determine what security activities are undertaken. He described that the argument for secure software development must be a business argument based on risk, that it has a real return on investment (ROI), and starting with a single development process and enhancing that can be a good way to introduce secure development practices. The activities undertaken need to be mapped to preventative, detective and corrective controls, and that the tasks need to specify roles, responsibilities and mappings to process flows. Also, he said that security knowledge needs to be spread widely with champions and experts, not just kept by a single specialist or group. He believes SAMM has a large proportion of overlap with Microsoft SDL and BSIMM, and is in the process of mapping SAMM's activities to the latter.

David Rajchenbach-Teller (MLState) described a new programming language for web applications called OPA. It has been designed from a clean start to avoid legacy concepts from the 1970s and 80s and is based on formal methods, is safe from the bottom up, using a single language for the whole application and is based on the distributed system model where not all principals are trusted, communications use web standards and security is mostly automatic. He showed some example code and described real applications in use today. He then described how it prevents a number of issues in the OWASP Top Ten 2010 but that is still under development, and for example, they are working on cross-site request forgery (CSRF) prevention mechanisms and extending the security policy feature set.

Cassio Goldschmidt (Symantec and SAFECode) presented an engaging explanation of how we are all responsible to a certain extent for the creation of software flaws. Whilst software manufacturers may be increasingly applying secure development practices, software is very complex, there are multiple layers of software on top of software and there is no effective way to prove software correctness. Adopters (e.g. home and corporate users) desire feature-rich software and security is not always visible. The environment affects purchasing decisions and home users in particular may not keep software patched. He said purchasing decisions in corporate entities may be made by different people than the users leading to a disconnect, and even patching can be delayed due to corporate cycles. Security researchers also have a part to play where the motivation and consequences of actions are not always transparent. Similarly governments find it difficult to make good law and the timescales cannot keep up with the fast pace of developments. They may provide incentives or require higher standards, but these can be blunt instruments. In summary he proposed that economics plays a larger part than technical solutions to the risks and impacts, even thought industry is moving in the right direction.

During and after lunch, OWASP board members and leaders discussed opportunities, issues and proposals to assist end-users find organisations who are providing products and services based on OWASP's knowledgebase.

Nick Nikiforakis (KU Leuven) described their analysis of eight file sharing services that are cloud-based, provide "one-click hosting" and are mostly anonymous. They found that although the services tended to offer both private distribution (e.g. by email link or instant messaging) and public distribution (e.g. links added to forums, blogs, etc) most of the services were relying on obscurity through obscurity. In many cases the URL token was predicable and even if the source filename was included, this was often not required. Given the predictability of tokens, they were able to obtain details of many different files on the file sharing systems, and tried to identify which were of the private or public type by an examination of whether the source filename could be found elsewhere using Yahoo. The remaining non-binary types were downloaded and examined to find a wide variety of data including bank statements, company budgets & salaries, personal data, documents with admin credentials, doctors notes and even a death certificate. Their advice, choose file sharing systems that have unpredictable tokens, encrypt the files and remove from the store as soon as possible.

The conference closed with thanks being given to the organisers, Kate Hartmann (OWASP Operations Director), OWASP board, helpers from the university, the sponsors, the sound and video teams, the caterers and the attendees. Prizes from various sponsor competitions and the capture the flag event were given. John Wilander reminded attendees about the upcoming AppSec US 2010 in September and announced that next year's AppSec EU would be help in Trinity College, Dublin, Ireland, and in Athens the year after.

Congratulations to the team from Sweden, Norway and Denmark for such a well-organised, and excellent appsec conference!