18 May 2015

Preventative

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

20 February 2015

Software Assurance Maturity Model Practitioner Workshop

The OWASP Open Software Assurance Maturity Model (Open SAMM) team are holding a summit in Dublin at the end of March.

Extract from the Open Software Assurance Maturity Model (Open SAMM) document that describes the four business functions - governance, construction, verification, and deployment

As part of the two-day Open SAMM Summit 2015 a full day is being allocated to software assurance practitioners and those who want to learn about using the vendor-neutral and free Open SAMM to help measure, build and maintain security throughout the software development lifecycle.

Open SAMM helps organisations formulate and implement a strategy for software security that is tailored to the specific risks facing the organisation. The resources provided by SAMM assist:

  • Evaluating an organisation's existing software security practices
  • Building a balanced software security programme in well-defined iterations
  • Demonstrating concrete improvements to a security assurance program
  • Defining and measuring security-related activities within an organisation.

There seems to be plenty activity in the project. Keep up-to-date by following or joining the mailing list.

The users day, on Friday 27th March, is a combination of presentations, workshops and round-table discussions to help explain the approach, to make best use of a maturity model, to show how SAMM is being used by other companies, and to describe some upcoming project initiatives. The user day runs from 08:00 for 09:00 hrs through to 17:00 hrs, and is followed in the evening by an optional social event. Attendance is limited to the first 40 people who register and costs 150 EUR + VAT (21%). Travel, accommodation, subsistence at your own cost.

The following day, the SAMM project team, and any other volunteers who want to participate, will be working on creating outputs for the project.

The event is being held at The Gibson Hotel at Point Village Dublin 1, Ireland.

Posted on: 20 February 2015 at 09:59 hrs

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

17 February 2015

AppSensor Now A Flagship OWASP Project

I was extremely pleased at the release of the v2 AppSensor reference implementation inJanuary. Now I am excited that the Open Web Application Security Project (OWASP) has elevated the project's status.

Photograph of a green pendant flag flying against a blue sky

The completely voluntary OWASP project task force, led by Johanna Curiel, has been working through a backlog of project reviews. Over the last couple of years OWASP AppSensor Project has delivered significant steps in the coverage, quality, and depth of outputs. In fact it is also the only OWASP project that is both a documentation type of project, and a code one.

OWASP has promoted the project to the highest level - Flagship status. As co-leader with John Melton and Dennis Groves, and project founder Michael Coates, I am thrilled with this recognition.

OWASP's project inventory includes nine other Flagship projects and defines flagship status as:

The goal of OWASP Flagship projects is to identify, highlight, and support mainstream OWASP projects that make up a complete application security product of high quality and value to the software security industry. These projects are selected for their strategic value to OWASP and application security as a whole.

OWASP Flagship projects represent projects that are not only mature, but are also projects that OWASP as an organization provides direct support to maintaining. The core mission of OWASP is to make application security visible and so as an organization, OWASP has a vested interest in the success of its Flagship projects. Since Flagship projects have such high visibility, these projects are expected to uphold the most stringent requirements of all OWASP Projects.

It is important to remember all the people who have volunteered their time and effort to reach this stage. So many good and generous people.

Mark Miller has just interviewed John Melton about the OWASP AppSensor Project as part of the OWASP 24/7 podcast series. He provides an overview of application-specific attack detection and response, discusses what is new in version 2.0.0, explains the architectural options, describes the process flow, and mentions what else is on the roadmap.

AppSensor will be participating in this year's AppSec EU application security conference in Amsterdam, from 19th to 22nd May 2015. I hope you can make it.

Posted on: 17 February 2015 at 07:55 hrs

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

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

30 January 2015

OWASP AppSensor Code v2.0.0 Final Release

I was extremely pleased to read yesterday that the final version of the new AppSensor reference implementation has been published following three previous release candidates.

Screen capture from the AppSensor microsite developed by John Melton for the OWASP AppSensor Project

The OWASP AppSensor project defines a conceptual framework and methodology that offers prescriptive guidance to implement application intrusion detection and automated response.

John Melton with the help of other code contributors and feedback from the project's code development mailing list have finished a complete overhaul of the previous code. In the words of the version 2.0.0 announcement, the most significant changes are:

  • Client-server architecture supporting multiple communication modes including: REST, SOAP, Thrift, local (shared JVM, java-only)
  • Any language can be used on the client application. The only requirement is that the language selected must support the communication protocol of the execution mode that is configured (i.e. if using REST as the execution mode, the language must be capable of making HTTP requests.) The server-side components are Java, but this places no restriction on the client applications themselves
  • There is no longer a hard dependency on [OWASP] ESAPI. AppSensor is a standalone project, though it can be integrated with projects that also use ESAPI if desired
  • The core components of the system have been renamed and now follow the AppSensor v2 book naming conventions, which is based on standard IDS terminology for clarity
  • Basic user correlation is supported so that client applications that share a user base (SSO) can share attack detection/response information.

John also created a special AppSensor microsite.

This is all free to use (see code licence). Begin using the new code with the getting started information.

Posted on: 30 January 2015 at 08:26 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

16 January 2015

New Application Security Program Quick Start Guide

WhiteHat Security has donated a getting started guide to the Open Web Application Security Project (OWASP).

To be successful, we should aim for a program that is more than simply testing sites and delivering results to stake holders. Those activities represent just two of the many inputs and outputs necessary to reduce the risk associated with web applications.

The Application Security Program Quick Start Guide provides information on setting up or improving a software development security initiative, and is now an OWASP project. It was created by Gabriel Gumbs, Jeremiah Grossman, Robert Hansen, Jerry Hoff and Matt Johansen. The guide is arranged in "5 days" of actions, which might be somewhat hopeful, but is a useful summary of what WhiteHat has found to work elsewhere.

The version 1.0 document is available in Word and PDF formats. The guide is free to use and is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Posted on: 16 January 2015 at 19:10 hrs

Comments Comments (0) | 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

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

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

Requested by 23.23.62.93 on Tuesday, 26 May 2015 at 12:31 hrs (London date/time)

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

Terms of use https://www.clerkendweller.uk/page/terms
Privacy statement https://www.clerkendweller.uk/page/privacy
© 2008-2015 clerkendweller.uk