28 May 2015

Threats

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

24 March 2015

Web Application Attacks from a WAF Perspective

I had lost track of Imperva's useful Hacker Intelligence Initiative (HII), threat advisories and Web Application Attack Reports (WAARs). The latest WAAR was published in October 2014.

Part of Imperva's 'Web Application Attack Report Edition #5 - October 2014' illustrating two of the charts included

Web Application Attack Report Edition #5 - October 2014 describes the most popular web application targets, attack vectors, duration and magnitude. The analysis is based on data from 99 web applications that had a web application firewall (WAF) from the vendor deployed in the period 1st August 2013 to 30th April 2014.

Attack data are included for:

  • SQL injection
  • Remote file inclusion
  • Local file inclusion
  • Directory traversal
  • Cross-site scripting
  • Comment spamming.

Other types of attack vector and threats are not covered. The report's introduction suggests that a further 201 web applications did not see any of these types of attack during the period.

Posted on: 24 March 2015 at 08:32 hrs

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

20 March 2015

The Hard Problem of Securing Enterprise Applications

This paper about securing enterprise applications has been sitting in my email since November. I eventually got round to reading it and apologise for not highlighting it sooner.

Vendor recommended security controls and compliance requirements leave huge gaps in application security. ... Most have no understanding of how the application platforms work, where security events should be collected, nor how to analyze application specific information.

Securing Enterprise Applications describes the problems modern enterprises have with application security: security use cases, security gaps and recommendations. These are my favourite selective snippets. This:

The biggest gap and most pressing need is that most monitoring systems do not understand enterprise applications. To continuously monitor enterprise applications you need to collect the appropriate data and then make sense of it.

And:

Traditional application security vendors who claim "deep packet inspection" for enterprise application security skirt understanding how the application actually works.

And:

Continuous monitoring of enterprise application activity, with full understanding of how that application works, is the most common gap in enterprise security strategies.

And:

This means that you can block activity, not just monitor. Properly configured with white/black listing, they help prevent exploitation of 0-day attacks and filter out other unwanted behavior. They work at the application layer so they are typically deployed one of three ways: as an agent on the application platform, as a reverse proxy for the application, or embedded into the application itself.

Read and implement AppSensor. It's free.

Posted on: 20 March 2015 at 08:16 hrs

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

06 March 2015

Introduction to AppSensor for Developers

Following the recent v2.0 code release and promotion to flagship status there has been increased interest in the OWASP AppSensor Project concerning application-specific real-time attack detection and response.

Front page of the new 'AppSensor Introduction for Developers'

During the OWASP podcast interview with project co-leader John Melton, the idea of creating briefings for target groups was discussed by podcast host Mark Miller. I am pleased to say that thought rolled onto the project's mailing list, and John Melton rapidly wrote and published the text copy.

I took that copy and additional suggestions by Louis Nadeau to design a two-page briefing document. This is available to download from the OWASP web site:

Please circulate this to software developers. The text is also available on CrowdIn if anyone would like to volunteer to translate the briefing, or the guide for that matter, into other languages..

We also plan to create a short guide for Chief Information Security Officers (CISOs), with content drawn primarily from the first few chapters of the existing AppSensor Guide v2.0.

Posted on: 06 March 2015 at 10:21 hrs

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

03 March 2015

User Interface Modifications to Combat Buyer Fraud

A paper published for the 2015 Network and Distributed System Security (NDSS) Symposium in February describes user interface modification techniques to address liar buyer fraud, and the results of experiments assessing the potential for these to reduce ecommerce fraud losses.

Title from the paper 'Liar Buyer Fraud, and How to Curb It' by Markus Jakobsson, Hossein Siadati and Mayank Dhiman

Liar Buyer Fraud, and How to Curb It authors Markus Jakobsson, Hossein Siadati and Mayank Dhiman describe "liar buyer" fraud, how traditional anti-fraud technology fails to curb this problem, and details the results of experiments of proposed alternative techniques to reduce the problem.

The authors explain that liar buyer fraudsters are generally not repeat fraudsters, but are otherwise honest people who are first-time offenders that act fraudulently as the result of temporary poor judgement. This manifests itself in claims that deliveries were not made. It is believed that at least a quarter, and as much as half, of direct fraud affecting some organisations is the result of liar buyer fraud.

The ideas considered by the authors for their research involve changes to the user interface that promote user honesty:

  1. Disclosure that the customer's computer/device has been recognised
  2. Disclosure of the customer's location (e.g. IP address, post code or location map)
  3. Production of statements by the delivery person
  4. Simplifying methods of goods return
  5. Forcing the customer to make a promise
  6. Attending to angry and upset customers carefully.

The research focused on the first two of these and found they have a significant reduction in customer's willingness to file false claims. The other options look promising and, perhaps with the exception of the third approach, could be undertaken by real-world retailers in A/B/N testing.

Posted on: 03 March 2015 at 07:48 hrs

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

13 February 2015

Security Information Sharing Standards and Tools

European Union Agency for Network and Information Security (ENISA) has published a summary of security information sharing formats, at the same time of the release of its good practice guide on Actionable Information for Security Incident Response.

Diagram from the ENISA report 'Standards and Tools for Exchange and Processing of Actionable Information' illustrating the relationships between standards for sharing of security information

Actionable security information is accurate and timely information that may help incident handlers reduce the number of infections, or address vulnerabilities before they are exploited.

The companion to the good practice guide is Standards and Tools for Exchange and Processing of Actionable Information which describes 53 different information sharing standards that are a mix of formats, protocols, technical approaches and frameworks in common use. These span:

  • Information sharing formats
    • Formats for low level data
    • Actionable observables
    • Enumerations
    • Scoring and measurement frameworks
    • Reporting formats
    • High-level frameworks
  • Transport and serialization
    • Transport methods
    • Serialization methods.

In addition, the report highlights 16, primarily open source, information sharing tools and platforms for the exchange and processing of actionable information, spanning automated distribution of data, supporting analytics, general purpose log management and handling high-level information.

Very useful - thank you ENISA.

Posted on: 13 February 2015 at 11:10 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

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

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

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

More Entries

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

Requested by 54.205.20.160 on Saturday, 30 May 2015 at 03:12 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