26 June 2015

Threats

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

21 April 2015

Data Breach Investigations Report 2015

The Verizon annual Data Breach Investigations Report was published last week.

Partial view of Figure 43 from the Verizon 'Data Breach Investigation Report' showing the SANS critical security controls mapped to incident event chains

The Data Breach Investigations Report (DBIR) summarises findings from the collection and analysis of almost 80,000 security incidents relating to over 2,000 confirmed data breaches, sourced from 70 contributing organisations.

A breakdown by industry sector is provided. The 2015 DBIR incident and breach information collection processes have no substantial changes from the 2014 DBIR, focusing on security events resulting in confirmed data disclosure, as well as other security incidents such as denial-of-service attacks, and compromises of systems without data loss. The report re-iterates that it only represents a sample of events — the results are only representative of the sources of information contributed.

An analysis of the threat actions illustrates that the proportion of actions involving RAM scraping is growing, spyware/keylogger is falling and both credentials and phishing are broadly similar.

There is plenty of interesting data on breach discovery, phishing, patching, malware, industry profiles and impacts. The discussions on the problems with threat intelligence and the limited impact of mobile device compromise are insightful.

Nine common incident classification patterns are used to summarise the findings, including "web application attacks", accounting for 9.4% of incidents. Almost all the attacks in this category were opportunistic in nature, with information, financial services, and public entities being particularly affected. Use of stolen credentials are the most common action involved.

The last figure in the report (illustrated above) is a mapping from the recommended SANS Critical Security Controls to incident event chains. Although this only relates to Verizon's own source data, and not any of the other contributors, it illustrates that many basic security measures can help protect against the most common attacks. These include two-factor authentication, patching web services, verifying the need for internet-facing devices, proxying outbound traffic and web application testing.

Posted on: 21 April 2015 at 10:49 hrs

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

16 April 2015

PCI DSS v3.1 for Ecommerce Payments

Lots happening this week. The Payment Card Industry Security Standard Council (PCI SSC) has announced the release of an update to the PCI Data Security Standard (PCI DSS).

Partial view of the title sheet from the Payment Card Industry (PCI) Data Security Standard, Requirements and Security Assessment Procedures, Version 3.1, April 2015

PCI DSS v3.1 (15 April 2015), includes several changes to reflect changing threats and recently discovered vulnerabilities, but also including some clarifications and additional guidance.

The most important aspects changed for ecommerce channels relate to the following PCI DSS requirements:

  • 2.2.3 and 4.1 - Removed SSL as an example of a secure technology. Added note that SSL and early TLS are no longer considered to be strong cryptography and cannot be used as a security control after June 30, 2016. Additional guidance provided in Guidance column. Also impacts Requirements 2.3 and 4.1.
  • 2.3 and 4.1.1 - Removed SSL as an example of a secure technology and added a note to the requirement.
  • 3.4 - Clarified in requirement note that additional controls are required if hashed and truncated versions of the same PAN are present in an environment.
  • 6.6 - Added clarification to testing procedure and Guidance column that if an automated technical solution is configured to alert (rather than block) web-based attacks, there must also be a process to ensure timely response.

The PCI SSC has provided an on demand webinar to assist with understanding all the changes. Version 3.1 is effective immediately and PCI DSS Version 3.0 will be retired on 30 June 2015.

Posted on: 16 April 2015 at 11:38 hrs

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

15 April 2015

Security of Public Communications Network and Service Providers

The European Union Agency for Network and Information Security (ENISA) has published guidance on what nations should take into account when evaluating the security compliance of public communications network and service providers.

Bars on a chart from the ENISA document 'Technical Guideline on Security Measures for Article 4 and Article 13a'

The requirements relate to Article 13a of the Framework Directive (2009/140/EC) and Article 4 of the e-Privacy Directive (2002/58/EC).

At first glance, many organisations might assume they do not fall within the remit of this "network and services" legislation, but Technical Guideline on Security Measures for Article 4 and Article 13a describes the "assets in scope" as "all assets of the provider which, when breached and/or failing, can have a negative impact on the security of networks, services and/or the processing of personal data".

The guidance provides a non-exhaustive list of networks and services, and related systems "which are often supporting, directly or indirectly, the provision of networks and services or the personal data processing". Whilst many in scope systems are communication and network related, including wires and fibre, network devices and DNS, other components mentioned are PCs, removable media, power supply systems, backup power supply and cooling systems. Many companies may be providers of services like these to organisations that are affected by the legislation.

The document goes on to describe "additional services" in scope that include "Provider web sites for customers, billing portals, et cetera, if they contain personal data which was collected and processed in connection with the provision of networks or services", "Customer premises equipment (CPE), if under the control of the operator (such as VOIP boxes)" and "Other systems used for storing or processing of personal data collected in connection with the provision of networks or services. This could involve procedures involving paperwork like paper-printed letters, contracts or bills". As the document states "Third party assets are in scope just as if they were assets of the provider".

The guidance defines a "security incident" as "a single or a series of unwanted or unexpected events which could have an impact on the security of networks, services and/or the processing of personal data". It goes on to provide examples of various scales of incident and whether they are reportable.

The technical guidance is divided into 26 security objectives, each with three levels of sophistication that demonstrates what level of controls are in place. The objectives and measures might be useful for other organisations to assess their own maturity, regardless of legislative applicability.

Posted on: 15 April 2015 at 18:18 hrs

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

07 April 2015

Penetration Testing Guidance for PCI DSS

The Payment Card Industry (PCI) Security Standards Council (PCI SSC) has published another information supplement for PCI Data Security Standard (PCI DSS), this time on penetration testing. It would appear there has been a large variability in penetration tests being undertaken for PCI DSS.

The cover from the PCI Security Standard's Council  'Information Supplement: Penetration Testing Guidance'

Information Supplement: Penetration Testing Guidance, v1 March 2015, replaces the PCI SSC's original penetration testing information supplement titled "Payment Card Industry Data Security Standard (PCI DSS) Requirement 11.3 Penetration Testing" published in 2008.

The scope of a penetration test is defined in PCI DSS Requirement 11.3. It must include the entire cardholder data environment (CDE) perimeter and any critical systems that may impact the security of the CDE, as well as the environment in scope for PCI DSS. This includes both the external perimeter (public-facing attack surfaces) and the internal perimeter of the CDE (LAN-LAN attack surfaces).

The information supplement is comprised of the following sections:

  • Introduction
  • Penetration testing components: Understanding of the different components that make up a penetration test and how this differs from a vulnerability scan including scope, application and network- layer testing, segmentation checks, and social engineering
  • Qualifications of a penetration tester: Determining the qualifications of a penetration tester, whether internal or external, through their past experience and certifications.
  • Methodology: Detailed information related to the three primary parts of a penetration test: pre-engagement, engagement, and post-engagement
  • Reporting and documentation: Guidance for developing a comprehensive penetration test report that includes the necessary information to document the test as well as a checklist that can be used by the organization or the assessor to verify whether the necessary content is included
  • Case studies / scoping examples.

Hopefully this will help organisations define more consistent objectives and requirements for penetration tests, improving the quality, and thus benefits of doing such testing.

Posted on: 07 April 2015 at 06:39 hrs

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

27 March 2015

Financial Conduct Authority Update March 2015

The UK's Financial Conduct Authority (FCA) is becoming more proactive in the online application space.

Photograph of one of the dragon boundary marks at the boundary of the City of London on Embankment

Following last year's consultation on use of social media, the FCA has completed its review and has now confirmed its approach for financial promotions in social media.

The finalised guidance has been published as FG15/4 - Social Media and Customer Communications: The FCA's Supervisory Approach to Financial Promotions in Social Media.

This covers web sites and applications that enable users to create and share content or participate in social networking, including blogs, microblogs (e.g. Twitter), social and professional networks (e.g. Facebook, LinkedIn, Google+), forums, and image and video-sharing platforms (e.g. YouTube, Instagram, Vine, Pinterest. Any form of communication (including through social media) is capable of being a financial promotion, depending on whether it includes an invitation or inducement to engage in financial activity. So, for example, it would include 'advergames', where promotional messages are placed in entertainment applications.

On another matter, in addition to the document published in July on Considerations for Firms Thinking of Using Third-Party Technology (off-the-shelf) Banking Solutions, legal news blog Out-law.com reports the FCA is examining platforms' technology systems later this year.

The FCA is also consulting on proposed changes to its consumer credit rules and guidance. Almost a year ago on 1st April 2014 the FCA took over the regulation of consumer credit from the former Office of Fair Trading (OFT). This brought around 50,000 consumer credit firms into its scope.

And finally, the UK's new Payment Systems Regulator (PSR), launching next week and part of the FCA, has announced its regulatory framework for payment systems (summary factsheet). Customers of payment services providers may not be aware of this change — Card payment systems is in the 2015/16 programme of work.

Keep up-to-date with FCA and PSR news.

Posted on: 27 March 2015 at 08:40 hrs

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

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

More Entries

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

Requested by 23.20.186.146 on Thursday, 2 July 2015 at 17: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