21 April 2015

Administrative

Posts relating to the category tag "administrative" are listed below.

10 February 2015

NIST SP 800-163 Vetting the Security of Mobile Applications

In the last of my run of three mobile app related posts, US standards body National Institute of Standards and Technology (NIST) has released Special Publication (SP) 800-163 Vetting the Security of Mobile Applications.

One of the tables from NIST SP 800-163 'Vetting the Security of Mobile Applications' showing top level general categories of iOS app vulnerabilities

SP 800-163 is for organisations that plan to implement a mobile app vetting process or consume app vetting results from other parties. It is also intended for developers that are interested in understanding the types of software vulnerabilities that may arise in their apps during the software development life cycle (SDLC). The report is grouped into planning, testing and app approval/rejection sections:

  • Planning
    • Security requirements
    • Understanding vetting limitations
    • Budget and staffing
  • Testing
    • General app security requirements
    • Testing approaches
    • Sharing results
  • App approval/rejection
    • Report and risk auditing
    • Organisation-specific vetting criteria
    • Final approval/rejection.

The guidance is practical and highlights risks that are mobile app specific as well as general application security risks. Appendices B & C provide helpful categorised lists of Android and iOS mobile app vulnerability types respectively.

Posted on: 10 February 2015 at 07:48 hrs

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

02 February 2015

CMA Consultations on Consumer Data

The UK Competition and Markets Authority (CMA) has two current related consultations.

Photograph of a yellow pendant flag flying on a mask against a blue sky

Data Sharing and Open Data in Banking

Following the publication of the report Data Sharing and Open Data for Banks in December 2014 which examined how financial technology firms can make better use of bank data on behalf of customers through application programming interfaces (APIs) and open data, the government is now seeking views on how an open API standard could be delivered in UK banking.

The call for evidence describes evidence is sought from banks, consumer groups, financial services providers, card schemes, payment institutions, financial technology firms and app and software designers. In particular views are sought about how the recommendations in the report should be developed, what benefits more open data in banking could bring to consumers and how an open API standard in UK banking could best be delivered.

The Data Sharing and Open Data in Banking call for evidence closes on 25th February 2015. Responses can be sent by email to Datasharing.CfE@hmtreasury.gsi.gov.uk or by post to Data Sharing and Open Data in Banking, Banking and Credit Team, HM Treasury, 1 Horse Guards Road, London SW1A 2HQ.

The Commercial Use of Consumer Data

The CMA is also seeking information on the commercial collection and use of UK consumers' data, and the implications (benefits and risks) for firms and consumers.

The briefing document details the scope as UK consumer data collected both inside and outside the UK in the context of the internet and more widely; collected directly by businesses as well as by appliances, applications and cloud services; collected at any time, both with and without the knowledge of consumers; includes both data on specific transactions for goods and services (including paid for and free-at-use services) as well as data not specific to such transactions; and used by firms dealing directly with consumers (for instance to target groups and individuals with offers), and third party firms (using data sourced from firms dealing directly with consumers) who analyse this data to provide commercial services to other firms.

The consultation on Commercial Use of Consumer Data closes at 5pm on Friday 6 March 2015. Responses can be submitted using the online form or by completing a form and returning to ConsumerData@cma.gsi.gov.uk or by post to Consumer Data Call for Information, Competition and Markets Authority, 7th floor Victoria House, 37 Southampton Row, London WC1B 4AD.

Posted on: 02 February 2015 at 10:32 hrs

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

23 January 2015

Undertaking by Office for Data Protection Act Breach

UK privacy regulator The Information Commissioner's Office (ICO) has published details of its enforcement action against shoe retailer Office.

Partial screen capture of a page from Office e-commerce website www.office.co.uk

The action relates to the unauthorised access of more than a million customer records on a legacy system that was not being protected adequately.

Office Holdings Ltd has signed an undertaking to comply with the fifth (retention) and seventh (security) data protection principles.

The undertaking requires Office to:

  • Undertake regular penetration testing of its websites and servers
  • Implement new data protection policy documents, including a retention and disposal policy for customer data
  • Provide initial and refresher formal data protection training to all Office employees
  • Implement any other security measures as necessary to protect personal data
  • Only retain personal data as long as necessary.

Office seem lucky not to have been fined. There is nothing above that they shouldn't already have been doing and "exposure of decommissioned software/services" is one of the most common classes of IT security vulnerabilities in online systems that result in failures to secure personal data identified by the ICO last May. This document was published by the ICO at about the same time as the Office incident occurred so I think other retailers have been warned and would not be treated as lightly for a similar breach now.

Posted on: 23 January 2015 at 08:34 hrs

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

14 January 2015

Application Security and Privacy Mapping 2015

I have updated my chart detailing the most important guidance, standards, legislation and organisations that can influence mobile and web application development security and privacy in the UK.

Principal Influences on UK Web Applications' mind map diagram for January 2015

For a fuller explanation, read my post about the update last October.

Access the Principal Influences on UK Applications 2015 chart, hosted on my company's web site.

Posted on: 14 January 2015 at 10:39 hrs

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

09 January 2015

FTC Final Order Against Snapchat

Following a public comment period in May-June 2014, at the end of December the US consumer protection body Federal Trade Commission has approved a final order settling charges against Snapchat that lasts for twenty years.

Part of the FTC's final order against Snapchat Inc showing the text 'VII. IT IS FURTHER ORDERED that respondent within ninety (90) days after the date of service of this order, shall file with the Commission a true and accurate report, in writing, setting forth in detail the manner and form of its compliance with this order. Within ten (10) days of receipt of written notice from a representative of the Commission, it shall submit an additional true and accurate written report. VIII. This order will terminate on December 23, 2034, or twenty (20) years from the most recent date that the United States or the Commission files a complaint (with or without an accompanying consent decree) in federal court alleging any violation of the order, whichever comes later; provided, however, that the filing of such a complaint will not affect the duration of: A. any Part in this order that terminates in fewer than twenty (20) years; B. this order's application to any respondent that is not named as a defendant in such complaint; and C. this order if such complaint is filed after the order has terminated pursuant to this Part.'

The charges related to how Snapchat deceived consumers about the automatic deletion of private images sent through the service.

The key FTC documents are:

The final order, 23rd December 2014::

  • Prohibits Snapchat from misrepresenting how its products or services maintain and protect the privacy, security, or confidentiality of any covered information
  • Requires Snapchat to establish and implement, and thereafter maintain, a comprehensive privacy program
  • Requires Snapchat to obtain an initial and, for 20 years, biennial assessments and reports from a qualified, objective, independent third-party professional, who uses procedures and standards generally accepted in the profession
  • Requires Snapchat to retain for 5 years records of all communications, complaints, notifications about possible order compliance failures, and assessment materials
  • Requires Snapchat to ensure it provides a copy of the order, and keep evidence of this, to all current and future subsidiaries, current and future principals, officers, directors, and managers, and to all current and future employees, agents, and representatives having responsibilities relating to the subject matter of the order
  • Requires Snapchat to notify the FTC of relevant corporate structure changes
  • Requires Snapchat to provide, within 90 days of the order, a document detailing the manner and form of its compliance with the order.

The order ends on 23rd December 2034 — an additional twenty year compliance overhead on top of the privacy program they should already have had in place.

I wonder if US consumers are also affected by the Moonpig API saga.

Posted on: 09 January 2015 at 08:42 hrs

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

07 January 2015

Moonpig Website Vulnerability, Incident and Breaches

Personalised greetings card service Moonpig was all over the popular news yesterday.

Partial screen of the Moonpig customer support page that states 'A MESSAGE TO OUR CUSTOMERS: You may have seen reports this morning about our Apps and the security of customer details when shopping with Moonpig. We can assure our customers that all password and payment information is and has always been safe. The security of your shopping experience at Moonpig is extremely important to us and we are investigating the detail behind today's report as a priority. As a precaution, our Apps will be unavailable for a time whilst we conduct these investigations and we will work to resume a normal service as soon as possible. The desktop and mobile websites are unaffected.'

Paul Price found an exploitable weakness in Moonpig's public API and contacted them in August 2013, and again a year later. Eventually he gave up and published details on Monday.

Following much Twitter activity, yesterday Moonpig tweeted:

We are aware of claims re customer data and can confirm that all password and payment information is and has always been safe.

Interesting spin, since the vulnerability relates to other personal data — passwords or payment card holder data. Shortly afterwards, Moonpig tweeted:

As a precaution, our Apps will be unavailable for a time whilst we conduct these investigations: http://www.moonpig.com/uk/Information/Press/

Moonpig also added the following message to their customer support page:

A MESSAGE TO OUR CUSTOMERS: You may have seen reports this morning about our Apps and the security of customer details when shopping with Moonpig. We can assure our customers that all password and payment information is and has always been safe. The security of your shopping experience at Moonpig is extremely important to us and we are investigating the detail behind today's report as a priority. As a precaution, our Apps will be unavailable for a time whilst we conduct these investigations and we will work to resume a normal service as soon as possible. The desktop and mobile websites are unaffected.

Although Moonpig has not responded to the core issue (personal information), the published details appear to indicate:

  • Breach of principle 7 of the Data Protection Act
  • Breach of the Payment Card Industry Data Security Standard (PCI DSS)
  • A disregard for customers' data when the company has been aware of the problem for so long, and it continued to collect and process personal data through the period.

PCI DSS is only relevant here if the system components for api.moonpig.com are within the PCI environment. There is no need for a cardholder data breach for there to be a breach of compliance with PCI DSS. The main www.moonpig.com systems are definitely within scope since payment cardholder data is collected on forms generated by the website and the data is sent back to the same Moonpig website.

Nevertheless, by passing through the shopping basket and check out, other application security and privacy concerns are evident such as system information leakage, sending personal data over unencrypted channels, and third-party code on checkout pages.

The API issue and the other public issues on the web site do not seem to even meet the baseline security controls published for years by OWASP.

The help page about Payment and Personal Details Security states:

Security is an important priority for us and we are committed to protecting your privacy. We are registered as required under the Data Protection Act 1998 (Reg. Z4843659) and we use the most up-to-date technology available to protect your personal details. To avoid the risk of computer fraud, your credit card number is not stored in our system at any point in the payment process. Please see our privacy and security policy here.

That is clearly not true and might therefore be a breach of the Advertising Standards Authority Online Remit. The above also hints that somehow payment cardholder data is safe because it "is not stored". That's good, but it is not the same as saying it is not processed by Moonpig systems at all, which is likely to be misleading to some consumers. The terms and conditions say very little about protecting personal data - except from "in transit", and as we know that is not true for all parts of the web site that collect or display personal data.

If that is not enough for Moonpig, if the API vulnerability also affects United States customers, we will see the US Federal Trade Commission get involved. That body has been very strict in recent enforcement actions for online privacy failings. Affected US readers can submit complaints to the FTC online.

Posted on: 07 January 2015 at 12:55 hrs

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

17 December 2014

Business Failure at the Speed of Software

This week we saw two events where the automated nature of processes lead to major business failures.

Partial extract from the RepricerExpress showing some of the liability clauses in its terms and conditions of service published at http://www.repricerexpress.com/terms-and-conditions/

On Friday, a number of Amazon retailers were affected by a pricing problem. Those that had chosen to subscribe to the third-party RepricerExpress service that automatically adjusts prices to match or better competitors, found their products were being sold for as little as 1 pence. Those organisations that despatched their own goods were able to spot the problem themselves, but those that used Amazon to stock and ship product, were affected more seriously because Amazon simply carried on regardless for some time.

The cause of the hour-long issue has been fixed. RepricerExpress's clients are outraged, and of course for some of them this could put them out of business. I am sure RepricerExpress will be reminding its clients what they agreed to in the RepricerExpress end user licence agreement (partial screenshot in the image above). Including for example that the maximum liability "shall be limited to a sum equal to the total Licence Fees paid to the Licensor in the period of 12 months considered retrospectively from the date the cause of action arose". So, how much would you pay for something that can reduce your product prices by almost 100%? £20-70 per month apparently seems to be the answer.

Express indeed.

Then on Monday, taxi-like company Uber, which had another PR disaster last month, managed to incense everyone by rapidly escalating its prices in Sydney as "demand increased" i.e. people attempted to leave the city during the dreadful cafe hostage event. Later reacting to pressure, Uber cancelled the change and offered some free services instead and a refund to those affected by its pricing.

These have a common factor of automated software making unmoderated changes to pricing that would clearly be perceived as unreasonable to a human. And doing it fast.

Superfast fail.

Automation is good — but enumerate all the possibilities, and implement limits, checks and alerts. And monitor these. And more importantly, check your contracts and who is liable for what. Then do a risk assessment and make sure someone senior reviews this and makes some decision about the risks. Can you survive the unexpected?

Posted on: 17 December 2014 at 17:23 hrs

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

16 December 2014

Guidance on the ASA's Online Remit Extension

The UK's Advertising Standards Authority (ASA) has had a digital remit since 2011 in the form of the CAP Code Digital Remit for Advertisements and Other Marketing Communications.

Advertisements and other marketing communications by or from companies, organisations or sole traders on their own websites, or in other non-paid-for space online under their control, that are directly connected with the supply or transfer of goods, services, opportunities and gifts, or which consist of direct solicitations of donations as part of their own fundraising activities.

Last week the ASA announced guidance on the remit extension. Broadly the new guidance explains through example cases that the ASA Council will take into account the entire context in which claims are made, in determining whether the primary purpose of the communication is to sell something and therefore whether it falls within the remit of the CAP Code.

The guidance provides six illustrative case studies that show that if the primary purpose of a web page is to sell something it is almost certain to be in scope, and how the scope can grow by including other marketing communication copy on a web site. Similarly, the context of the page in regards purpose and navigation can affect whether the remit applies, advertgames that are closely linked to products increase the likelihood of being in scope, and user generated content (UGC) can be misused so that it then becomes within scope

So I believe a claim of security or privacy that is intended to help complete a sale would perhaps fall within the remit.

Posted on: 16 December 2014 at 19:27 hrs

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

05 December 2014

The Problems with Security Badges, Seals and Marks

A paper presented at this year's Association for Computing Machinery (ACM) Conference on Computer and Communications Security discusses why security-related third-party seals are poor indicators of site security, and how in some cases can actually assist attackers to compromise the web sites.

Partial view of the content in the paper 'Clubbing Seals: Exploring the Ecosystem of Third-party Security Seals'

Problems with one of the privacy seal providers have been in the news recently, and the paper Clubbing Seals: Exploring the Ecosystem of Third-party Security Seals assesses the effect on a web site's security by including a security seal from service providers Norton Secured, McAfee Secure, Trust-Guard, SecurityMetrics, WebsiteProtection (provided by GoDaddy), BeyondSecurity, Scan Verify, Qualys, HackerProof, and TinfoilSecurity.

The paper's authors Tom Van Goethem, Frank Piessens, Wouter Joosen and Nick Nikiforakis examined the guarantees offered by these schemes, and the realities. Their findings were:

  • There is a lack of thoroughness, meaning insecure websites being certified as secure
  • Malware hosted on a certified web site can trivially evade detection
  • Some attacks can be facilitated by the seal scheme
  • Phishing attacks can be aided by the use of seals
  • The seals can be used to help attackers find vulnerable web sites.

The message is to concentrate on building and operating secure web sites, rather than using a seal to create the illusion of security. Application security through the software development life cycle (SDLC).

Posted on: 05 December 2014 at 08:32 hrs

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

02 December 2014

SANS SWAT Checklist and Poster

The SANS Institute has published a poster called Securing Web Application Technologies (SWAT).

Partial view of one section of the SANS Securing Web Application Technologies (SWAT) 2014 poster

SWAT 2014 (PDF) is a two-page large-format colourful poster combining a SWAT checklist with a What Works in Application Security chart.

The SWAP checklist groups its suggested best practices into the following areas: authentication, session management, access control, input and output handling, data protection, error handling and logging, configuration and operations. These are hopefully familiar; here are some similar categories elsewhere:

SANS Institute David Rook Open Web Application Security Project
SWAT Checklist Category AppSec Principle Cornucopia Suit Proactive Control
Authentication Authentication Authentication Establish identity and authentication controls
Session management Session management Session management
Access control Authorisation,
Secure resource access
Authorization Implement appropriate access controls
Input and output handling Input validation,
Output validation
Data validation and encoding Validate all inputs,
Parameterize queries,
Encode data
Data protection Secure communications,
Secure storage
Cryptography,
Cornucopia
Protect data and privacy
Error handling and logging Error handling Cornucopia Implement logging, error handling and intrusion detection
Configuration and operations - Cornucopia -
- - (all requirements) Leverage security features of frameworks and security libraries,
Include security-specific requirements,
Design and architect security in

So, a good overlap, albeit each of these has somewhat different intent. The SWAT best practices are cross-referenced to Common Weakness Enumeration (CWE) list of software weaknesses where applicable.

The What Works in Application Security part provides suggestions for application security programmes in four areas — govern, design, test and fix — showing how security needs to be built into multiple aspects of the software development lifecycle (SDLC).

The file can be downloaded without registration.

Posted on: 02 December 2014 at 06:16 hrs

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

More Entries

Administrative : Application Security and Privacy
ISO/IEC 18004:2006 QR code for https://clerkendweller.uk

Requested by 54.87.76.100 on Tuesday, 21 April 2015 at 15:42 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 https://www.clerkendweller.uk/page/terms
Privacy statement https://www.clerkendweller.uk/page/privacy
© 2008-2015 clerkendweller.uk