Amazon Web Services and other cloud providers can seem an attractive proposition for organisations wanting rapid system deployment, combined with seemingly lower costs.

An investment in cloud services, requires careful architectural design, strong identity management, protection of access credentials, design of appropriate security controls and a definition of processes to support the on-going operations. The latter need to include patching, host configuration, data destruction, encryption key management, usage monitoring and incident response.

But what about the compliance aspects? For many companies with e-commerce facilities, the spectre of PCI-DSS compliance is one of the ordinary considerations in selection of hosting providers. If the systems cannot be de-scoped so they do not store, process or transmit cardholder data, can cloud services be utilised? Yes, of course they can, but it is not an out-the-box solution that takes away the organisation's own responsibilities.

AWS provides summary information but will provide what is calls a PCI Compliance Package for customers seeking PCI certification. However, a blog post on Infosec Island describes AWS's Attestation of Compliance, and most importantly the responsibilities that Amazon accepts, and those that it does not.

This is a very useful overview and reminds us that nothing is free of charge.

Continuing from the first successful day, the second day of AppSec EU conference on Friday 13th July had another packed 3-track agenda.

The day's proceedings began in the main auditorium with a keynote from Gary McGraw.

Gary McGraw provided gave a stimulating presentation on what's wrong in software security, and how best to make changes through the software development lifecycle to have the greatest effect on identifying software bugs and architectural flaws, and on increasing confidence about the actual security of the application. He summarised how software security has progressed over the last ten years, how large companies like Microsoft has developed their own secure development life cycles, and how it is much more common to see security being considered at multiple stages of the development. He described the Building Security In Maturity Model survey of what companies are really doing and how the source data has expanded over four reports. He explained that this real survey work has made a large difference in convincing others that these activities, what would otherwise just be "good practices", are actually being used.

Following a brief break, I listed to a talk in the Defenders track. Dan Cornell introduced the issue of identifying the best dynamic automatic software security testing tool (automated black box testing). He conveyed how some of the publicly available comparisons and discussions about application scanning are very worthwhile reading and provide much insight, but what matters is whether a scanner will work sufficiently well with your own applications, with their own particular frameworks, architectures, patterns and conventions. He said that application coverage, low false positive identification of security vulnerabilities and low false negatives were the most general desirable properties. He outlined how log in processes often cause difficulties for scanners and described some common issues — complex authentication is not necessarily the issue, just unusual log in schemas can be very difficult for some scanners to learn without considerable tuning. He said the issue of identifying false negatives is related to the issue of ranking the severity of the vulnerabilities found. Finally he went on to demonstrate the open source ThreadFix tool that can be used to aggregate, normalise and de-duplicate findings from many different test sources, and output consolidated data to software issue tracking systems, giving a complete overview of the status of applications over time.

Dinis Cruz introduced the OWASP O2 project and described how it connected different technologies in a way that could be used by security consultants or developers to help with code analysis and improvement. In this presentation he focused on a customisation of the interface that integrates with an integrated development environment (IDE) to perform security static analysis of an ASP.Net application in real time as the developer types code. This is accomplished by integrating Microsoft's CAT.NET is a binary code analysis tool with the Roslyn compiler as a service tool. He demonstrated convincingly how injection flaws such as SQL injection and cross-site scripting could be flagged immediately within the IDE. By linking this to coding standards and external resources, knowledge can be inserted into the implementation stages of projects within the environment developers already utilise.

In the second keynote of the day, Diomidis Spinellis, professor at Athens University Department of Economics and Business, explained the problems associated with SQL, Xpath and JavaScript injection attacks. He informed the audience of a generic approach that uses location-specific signatures to identify these types of attacks. The functionality is available as open source libraries (EnSign) that can be used with any web application.

Pravir Chandra continued the theme of injection attacks in the third keynote entitled "Everything You Know About SQL Injection is Wrong". He illustrated how SQL injection, cross-site scripting and Xpath injection are all related to the same issue of failure to segregate data and code. He proposed we should use design patterns that enforce a separation between these concepts to prevent the intermingling of data and code, and thus eliminate these most dangerous vulnerabilities. He argued the case for the concept of an output assembler, or parameterised wrapper, that takes data, code and combines these safely using encoding libraries to prevent the un-necessary exposure of code resources directly.

The break for lunch provided time to absorb some of the sunshine and speak further with the other delegates.

After lunch, Stephen de Vries discussed using the concepts of Behaviour Driven Development (BDD) to write security requirements in structured plain English with JBehave. These unit tests can then be used to automate the execution of security testing to verify the desired outcomes. He provided a live demonstration that linked the use of JBehave, Selenium 2 (Web Driver) and Burp Suite; the latter is controlled remotely using a specially developed script. He explained how these ideas could be built into a continuous integration environment like Jenkins.

Immediately following on from Stephen de Vries, there was another excellent presentation from John Wilander. He defined, illustrated and demonstrated multi-step cross-site request forgery (CSRF) using a sequence of self-generating inline frames (iframes) which he described as semi-blind since the attacker never sees the responses. He explained that a common technique using tokens to prevent this type of attack cannot help in rich internet applications (RIAs) where the complete process is undertaken client-side and a single request is made to the server at the end. An attacker can forge the JSON structure and he suggested protection mechanisms that can be used including restricting the HTTP method to POST, limiting the request to Ajax where possible and restricting the allowable media types for the request. He went on to define and demonstrate double-submit CSRF protection and how this could be circumvented via a vulnerable sub-domain of the same domain name and proposed the concept of using a triple submit CSRF protection mechanism.

At this point I had to depart for my return journey, and unfortunately had to miss the final presentation, a keynote by Christian Papathanasiou, the closing ceremony and an early evening visit to the Acropolis Museum.

In summary, another very well organised conference with valuable sessions and unparalleled opportunities to meet with application security experts from around the world. Apart from thanking the organising committee especially Konstantinos Papapanagiotou, and OWASP staff for ensuring such a high standard of event, I think we should give special praise to all the excellent volunteers, including local students, who put in so much effort, and were so attentive and helpful. Athens was an excellent choice.

The next OWASP Global Conferences are AppSec North America 2012 (Austin, Texas, USA) in October and AppSec Latam 2012 (Montevideo, Uruguay) in November. The next AppSec EU will be held in Hamburg, Germany during July 2013.

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?

Many organisations like to do land grab with domain names by purchasing the same name with different generic top-level domains (e.g. .com, .net, .info), country code top-level domains (e.g. .uk, .es, .fr), and multiple second-level domains (e.g. .co.uk, .org.uk). Then of course there are mis-spellings, similar sounding words, brand names and trademarks.

Well all that leads to complexity, and it's not uncommon for many domains to be aliased to the same site in a way that any of them can be used to access the complete web site.

But it can get especially messy when SSL is enabled on some or all of the site too. Inevitably there end up being certificate warnings. Some organisations should know better. So when I was searching for providers of online and business privacy "seals",

I was very surprised to click on the link to an SSL page which was reported as using an invalid certificate.

Actually the certificate was fine, it just wasn't valid for the .ORG domain. Perhaps they had hoped the wildcard SSL certificate *.trust.com would somehow cater for *.truste.* - no.

Identity theft? Privacy? But apart from these configuration issues, isn't it just very confusing to have many different domains appearing in search engine results? How does this duplicate content affect their search engine ranking? Does it undermine trust in the brand? Should the SSL part of the site be indexed at all? Perhaps. Who makes these decisions? Is it the developers, the person who configured the site or does the business have a viewpoint?

I overheard a (loud) mobile telephone conversation this week in which a marketing manager* was apologising for a problem but they "did not know any of the technicalities". Mmmm, who is accountable? Make it your business to know.

[* Security and technology managers should also understand their organisation's business objectives.]

It's common for access to some web sites to be restricted to users from particular Internet Protocol (IP) addresses. This is usually in addition to some other identification and authentication method. But other IP addresses are often added to this "allow list" and these should not necessarily be trusted in the same way.

In a typical scenario, a web site hosted on the internet that is used to administer another web application might be restricted to the company's own IP addresses. Then the developers say they need to check something on the live site, or another server needs to index the content, or someone wants to work from home for a while, or the site needs to be demonstrated at a client's location. All these additional IP addresses are added to the "allow list". These restrictions may be being applied at a network firewall, traffic management system, at the web server, in the application itself, in intrusion detection systems or in log analytical software, or in many of these. These are difficult to manage and in time there will be many IP addresses that no-one knows why they are allowed unless they are carefully documented, and subject to a fixed time limit when they are confirmed again by an appropriate person or removed. These extra addresses are quite often hard for someone else to guess.

However, there is another area where IP addresses are added to "allow lists", and this is for remote monitoring and testing services. These might be checking uptime, response times, content changes, HTML validation or security testing. The service providers publish the IP addresses of the source systems so that companies can specifically allow access to their web sites. Since the number of these services is relatively small, it's not too difficult to find which one might give access to areas of a web site or web application that the public (and malicious people) should not be able to get to. The particular danger here is that the IP addresses might be excluded from monitoring and logging, and therefore even a diligent web site manager might not realise for example the uptime monitoring service is making unusual, or excessive, requests.

Although it is not likely a malicious person is using this "trusted" address unless routing has been compromised as well, problems can go undetected, from what might seem to be a legitimate source. The IP address may have been typed incorrectly, or worse, the restrictions/exceptions may not have been implemented correctly allowing more addresses to have the privileged access than intended. Not logging a user's session is privileged access.

Allow traffic through, but be very specific what is allowed and monitor what's going on. Review all the exceptions periodically. Be especially careful about anything that bypasses authentication (such as allowing a search engine to crawl restricted-access content) on an otherwise public site.

Do You Have SSL Configured Correctly? Let me start by saying that "correctly" means "best for you". There isn't a single correct answer, although there are certainly some "don'ts" that apply in every situation.

This information is not about whether to use SSL, and is mainly for your systems folk (or hosting company), but do read on and perhaps gain a better understanding.

Ivan Ristić recently announced the SSL Server Rating Guide (draft 10, 21 July 2009) and an associated online assessment tool called the Public SSL Server Database. These had reminded me to post my comments last Tuesday about the slightly related Colour Overload with IE8 Tab Grouping.

The SSL Labs' resources describe, and allow you to check, the SSL configuration of your own, or any other public site that has SSL enabled. The checks span the certificate and three categories of web server configuration settings. Previously, it needed more specialist tools that most people wouldn't have the time or inclination to use.

The rating guide contains much useful information, but will be too detailed for many people. However, do read the "Minimal Configuration Requirements" and pass these on to appropriate person responsible for the configuration and operation of your own web sites. Not every site needs an overall rating of 73 or 85 or whatever. You'll see in Table 6 of the guide, an idea of what might be suitable for a range of web site types.

After all, your competitors, and some customers, have probably already checked your site.

Many websites are updated using File Transfer Protocol (FTP). Don't do it.

A discussion thread How Do You Store FTP Login Information For Your Clients? highlighted what common practices are, but almost entirely missed the issues of transfer of login credentials over unencrypted channels, privileged access to the whole of the server, account sharing, password and user management.

It's no surprise that some of the most serious hacks are suspected of being undertaken using compromised FTP accounts.

FTP is not an option. Ask your hosting company or systems staff to disable FTP services and block all traffic to/from your web servers on TCP ports 20 and 21, at your network firewall.

Hardening the underlying server operating system is an important fundamental task to help protect your web applications.

For example, the Payment Card Industry Data Security Standard (PCIDSS) requirement 2.2 states:

Two United States organisations producing guidance in this field are:

• Security Configuration Benchmarks from the Center for Internet Security (CIS)
• Security Content Automation Protocol (SCAP) Checklists from the National Institute of Standards and Technology (NIST) Computer Security Division (CSD)

These are detailed documents and all the recommendations may not be appropriate for your own situation.

There have been some good discussions recently on the security of cloud computing services. Are you using or considering using external cloud computing for data storage or to undertake business functions?

A recent post A follow-up on SaaS & Cloud Risk reminded me to raise the topic here. The posting highlighted comments on The Register regarding Multi-site Bug Exposes Cloud Computing's Dark Lining included one by Raife Edwards:

Does this affect you? Not sure? Does your business use any of the following (the categories and terminology overlap)?

• software as a service (SaaS)
• platform as a service (PaaS)
• infrastructure as a service (IaaS)
• hosted application
• application service provider (ASP)
• cloud computing
• online office application (e.g. Microsoft Business Productivity Online Standard Suite, Google Docs)
• external web mail (e.g. Hotmail, Gmail, Live Mail)
• peer-to-peer services (e.g. Skype)
• online backup and synchronisation (e.g. Iron Mountain, iDisk, Live Mesh)
• other people's content included directly into your software applications (e.g. news feeds, maps)
• third party online service (e.g. address lookups, payment gateways).

If so, perhaps answer these three questions. Does it matter...

• if someone else deletes, or an unauthorised person views, your data?
• in which geographic location your data are stored?
• if your data or service are unavailable for more than 10 minutes?

If you answered "yes" to any of the above, take time to consider what the effects would be if any of your data was stolen or the service was unavailable for an hour, a day or a week. The considerations are very similar to any other business decision, but it's easy to forget the trust we are placing in another party.

The key security issues to review are software liability, right to audit, service level agreement (SLA), security testing plans, authentication policies, intellectual property, storage locations, system isolation, data encryption in transit and at rest, backup and recovery, archival, support, complaints procedure, contract jurisdiction and legal compliance. If you have cyber liability insurance, you will also need to check whether these cloud services are covered.

In Part 2 (of 2) on Tuesday, I'll highlight some more recent cloud computing issues and provide links to additional discussions.

Update 27th November 2009: See also Cloud Computing Risks.

E-consultancy.com has many excellent online marketing and e-commerce resources, and I read the blogs and forums regularly. The following posting appeared on the forum a couple of days ago:

This cry for help worried me. Although the forum replies were helpful, it did make me wonder how many other web site owners have no idea where their web site is hosted.

If this is really the case here, it probably means the owner doesn't have all the resources to rebuild the site elsewhere and possibly is without back-ups of the data. And what about the intellectual property ownership? It's something which all developers should be discussing with their customers. My first suggestion would have been to contact the development company. A cursory examination of the source code reveals:

This company even showcases the site:

Now, we have no idea of the background and cannot guess if there is anything amiss. But the site is a card payment enabled e-commerce site, and surely the owner has had to comply with the Payment Card Industry (PCI) Security Standards Council's Data Security Standard (DSS)? Knowing where your web site is hosted would be one of the earlier things to discover.

Let's hope it's sorted soon.