In October Securosis published a free paper concerning the security of "big data" systems.

Securing Big Data: Security Recommendations for Hadoop and NoSQL Environments focuses on the security aspects relating to the specifics of "big data" that are different architecturally and operationally to other environments rather than the, also important, security of the applications themselves. Thus, consideration of how nodes and client applications are vetted before joining the cluster, how data at rest is protected from unwanted inspection, the privacy of network communications, and how nodes are managed are covered.

The paper discusses what "big data" means, and the particular architectural and operational security issues that arise. It then presents six recommendations.

Applications that accept payments and are installed on consumer mobile devices, not used exclusively used for a single payment application, such as smart phones, tablets and PDAs have been excluded from the PCI SSC's validation programme Payment Application Data Security Standard (PA-DSS). These types of mobile payment acceptance applications are known as Category 3 - payment applications operating on any consumer electronic handheld device that is not solely dedicated to payment acceptance for transaction processing.

Mobile payment Acceptance FAQs, published in June 2011, recommended that Category 3 applications intended for use in the cardholder data environment are developed using PA-DSS as a baseline for protection of payment card data and in support of PCI DSS compliance, until the development of appropriate advice, guidance, and/or standards to ensure that such applications are capable of supporting a merchant's PCI DSS compliance. On Friday the PCI SSC published new guidance for developers.

PCI Mobile Payment Acceptance Security Guidelines v1.0 September 2012, describes firstly 3 objectives and guidance for application payment transactions:

1. Prevent account data from being intercepted when entered into a mobile device
2. Prevent account data from compromise while processed or stored within the mobile device
3. Prevent account data from interception upon transmission out of the mobile device

Secondly, guidance on 15 risks and controls in the supporting environment (mobile platform and associated applications):

1. Prevent unauthorized logical-device access
2. Create server-side controls and report unauthorized access
3. Prevent escalation of privileges
4. Create the ability to remotely disable payment application
5. Detect theft or loss
6. Harden supporting systems
7. Prefer online transactions
8. Conform to secure coding, engineering, and testing
9. Protect against known vulnerabilities
10. Protect the mobile device from unauthorised applications
11. Protect the mobile device from malware
12. Protect the mobile device from unauthorized attachments
13. Create instructional materials for implementation and use
14. Support secure merchant receipts
15. Provide an indication of a secure state

Recognising that no one party has sole responsibility for security of Category 3 applications, a table in Appendix B of the guidance suggests responsibilities for the 18 practices. The responsibilities are assigned to device manufacturers (e.g. Apple, Huawei, Motorola, Nokia, Samsung), operating system developers (e.g. Apple, Google, Microsoft), application developers (e.g. you?), and merchants as end-users or payment acceptance service providers.

The guidance also provides a list of ten additional sources of information to support the guidance. Further advice and standards on mobile payments are expected from the PCISSC in 2013.

In the next post, I will discuss some related updated guidance from Visa.

The next meeting of OWASP London will be on Thursday 29th March from 18:00 for an 18:30 prompt start.

Jim Manico will be speaking about Deep Access Control Best Practices and Anti-Patterns, and Manish Saindane about IronWASP, a web application testing platform. These talks sound very useful and I am disappointed that I won't be able to attend that evening.

The event is being held at Morgan Stanley, Canary Wharf. Full details are available on the chapter page. It is free to attend, and everyone is welcome, but prior registration is required to gain access to the building.

In 2005, the US Federal Financial Institutions Examination Council (FFIEC) published Authentication in an Internet Banking Environment building on their earlier work on electronic banking. A supplement to the 2005 guidance has now been published.

The 2005 guidance recommended periodic risk assessments so that control mechanisms can be adjusted to respond to changing internal and external threats. The guidance stated that authentication techniques should be appropriate to the risks associated with the product or service, but that single-factor authentication is inadequate. It also recommended building customer awareness, and minimum supervisory expectations for authentication controls relating to high-risk online transactions involving customer information and the movement of funds to other parties.

On 28th June 2011, the FFIEC announced its Supplemental Guidance on Internet Banking Authentication to reinforce the guidance's risk management framework and update the expectations for authentication, layered security and other controls in an increasingly hostile environment.

The supplementary guidance reiterates the need for risk assessments and authentication for higher-risk transactions. It also recommends a layered security approach "since virtually every authentication technique can be compromised". Its recommendations for layered security controls include fraud detection & monitoring, dual device authentication, out-of-band verification, positive pay & debit blocks, transactional limits, activity limits, geo-location IP address reputation monitoring, policies & processes for handling compromised devices and malicious users, monitoring of account maintenance activities and customer education.

So, useful information, and not just for internet banking. The guidance is a good reference source for anyone considering authentication controls for access to more sensitive information.

Thank you to Alexis Fitzgerald for bringing this document to my attention.

Web users should be very familiar with challenge-response CAPTCHA test which are also known as Human Interactive Proofs (HIPs).

A lot of time is spent devising CAPTCHAs and trying to break CAPTCHAs in an automated manner. They are used where website owners want to try to ensure a real person is undertaking a transaction such as logging in or submitting content. Now, most web sites don't need to use CAPTCHAs and there can be accessibility problems, but they are often needed for more high-profile sites or when targetted automated attacks are occurring.

A new paper Attacks and Design of Image Recognition CAPTCHAs examines image recognition CAPTCHAs (IRCs) and analyses the effectiveness and security of the schemes considering:

• ease of use by humans
• difficulty to automate
• universality
• reistance to no-effort attacks
• scalability
• use of a secret database.

The authors describe the lessons learned, some fundamental guidelines for IRCs and propose an alternative IRC which relies on recognising an object by exploiting its surrounding context. This requires the user (hopefully a human) to select an item from a set of objects detached from the original image, and then place it back at its original position in the image. Its usability, robustness and copyright issues are discussed.

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?

Privileged database accounts should generally not be used by web applications. It is a very common problem but verifying this often requires access to the servers or a copy of the web site's configuration information or database. However, sometimes you are given a big clue—like this order acknowledgement email I received on Tuesday.

Now that's interesting. This makes me wonder if sales orders placed manually, say by telesales staff, have staff names appearing here. But via the e-commerce site "Database Administrator" (DBA) is entered. This could indicate the account name being used by the online system to connect to the database.

It may not be a vulnerability, but it is un-necessary information to give to customers. Even if it is a vulnerability, it may not be exploitable. There may be no technical and business impacts. But let's imagine there is a problem.

There is almost certainly no need for this function, or the rest of the web site, to use what is probably a highly privileged database account. The account may have access to many more fields, tables, views, procedures, schemas, etc than are necessary for the business process. Whilst it would be impossible for most web sites to use different accounts (connection strings) for every use, it is often possible to have a small number of accounts, such as:

• unauthenticated public user
• registration/log-on/log out/password reset
• authenticated users
• content editors
• content publishers
• site administrators
• logging (e.g. usage trends, audit trail, security log)
• scheduled application tasks.

Any people who need direct access to the database (e.g. to extract other data, or alter the schema) should have their own personal account, and mustn't use the above or DBA accounts.

These should then only have access to the appropriate methods and database assets necessary for their role. This would mean for example, a dangerous function could not be used in the database. Or, that even if a public page could be exploited by SQL injection, it would be difficult to obtain access to the database schema or extract data limited to authenticated users (this does NOT prevent SQL injection, but may partly mitigate the effects). Similarly, if the account used by logging only has INSERT permissions to a subset of tables and no other application account has access, it's going to be much harder to modify or delete log entries accidentally or maliciously.

Therefore, build database roles into your web site's design, and enforce permissions appropriately through the code. When combined with server and database hardening, it will help protect the application and your business.

Thinking of creating a mobile phone application for your business? A major privacy failure with an iPhone application has been reported on the Zero Day blog and is a useful case study.

All iPhone apps have to be approved by Apple to "protect consumer privacy, safeguard children from inappropriate content, and avoid applications that degrade the core experience of the iPhone". But the application Quip from Addy Mobile Inc provides provided unlimited photo texting with the slogan "Why pay more for MMS? Don't you pay enough for your iPhone already?". Well, many of the application's users are paying for it now.

It seems the images (typically photos) were stored on a publicly-accessible web site, with the only access "control" being a random directory (folder) name five characters long—something that is easily iterated through to find photos and breach their customers' privacy. What makes it worse is that many of these messages and images were also turning up in public search engine results leaking sensitive information.

I was unable to find any privacy notice or privacy policy from the company:

The cached search results indicate the images are being stored using Amazon Web Services (AWS) S3. This is not a cloud computing specific issue. It could just as well be on a web site hosted by the company itself. The Quip web site (http://www.quiptxt.com), Quip message site (http://www.quiptxt.com) and Quip S3 image repository (http://quipimg.s3.amazonaws.com) are all currently offline. The comany issued a statement via Reddit. As the Zero Day blog says, these vulnerabilities would have been trivial to fix and protect the confidentiality of users' message text and photos. Using any of common sense, threat modelling, risk assessment or security verification should have identified the problems. I'm sure lawyers in the US will be circling. Since Apple approved the application, let's hope they are ready in case the lawyers knock on their door as well.

Addy Mobile Inc may itself be unavailable soon.

This weekend the clocks change as we revert from British Summer Time (BST) to Greenwich Mean Time (GMT) at 02:00 BST on Sunday 25 October 2009 and the clocks go back, giving an extra hour.

What does this mean for web site security? Does running 01:00 to 02:00 twice matter? Well some brave web application owners will be disabling their systems like this online bank:

And, I don't think it's just being done as a finale to the current Energy Saving Week. Most people, quite rightly, won't be taking this rather severe step. Another millennium bug anyone? The date/time should be considered rather like other untrusted user input. Most problems will probably fall into the "business logic" category such as:

• Failure of time-based logic where dates are being compared.
• Assumptions of uniqueness in time-stamped output (e.g. by a single-threaded process).
• Running tasks again leading to possible:
  • loss of data due to overwriting
  • duplication of exports or emails
  • creation of inaccuracies in management information.
• Chronological ordering anomalies leading to other faults.

It's not just banks and other financial organisations that may have difficulties.

The time change may expose some other vulnerabilities that only exist at changeover time and/or during the next overlap hour.

• Circumvention of brute force attacks on user authentication mechanisms.
• Increased risk due to extension of a session's validity where local time is recorded.
• Failure in data validation routines for time-related comparisons.
• Incubated vulnerabilities where a time-related aspect causes the attack to be possible.
• Denial of service due to extension of account lock-out.
• Using time as a loop counter.
• Additional errors caused by any of the above leading to information leakage.

Recording the offset of local time to GMT/UTC and synchronisation should certainly be done, but may not resolve the time overlap issues. The effects on long-running "saga" requests might be especially difficult to determine. Time dependencies need to be specified and considered through the development lifecycle. Perhaps the bank is right after all?

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.