Search

Brian Pennington

A blog about Cyber Security & Compliance

Tag

PA QSA

ADVICE FROM AN ASSESSOR: DevOps, Automation, Security and Compliance

By Andrew Barratt, QSA, PCIP.  Managing Director, International/Managing Principal, Payments, Application Validation
Coalfire; Manchester, UK, http://www.coalfire.com

Phew, the title of this post alone sounds like it could be quite a lot to deal with!

So what is DevOps?  DevOps is simply the blending of infrastructure operations processes and software development to enable faster changes to business applications/technology.  These processes share a lot of ideology with the Agile & Lean camps but are more fundamentally trying to bridge the traditional divide between the development world and the IT operations/Service management teams.

In practice, DevOps can mean a lot of different things to different audiences and sometimes it can be difficult to apply compliance requirements without getting a good understanding of what DevOps is for your company.

Terms such as ‘treat your code as infrastructure’ can often scare the life out of traditional auditors along with the fear that with rapid release and change comes rapid loss of control. These shouldn’t be scary but should be embraced and understood. In audit parlance these processes can become embedded, configurable application controls that require less substantive audit testing and sampling when under scrutiny and allow the focus to be on how they are designed to be a security control.

DevOps environments typically make heavy(think obsessive!) use of automation tools to enable rapid change and release processes to be possible at large and frequent scale. This is typically where the confusion starts to begin when evaluating these environments for security and compliance purposes. Typical service management controls such as change management on the surface may appear to have been cast aside in the rush to ‘be DevOps’. This rush to implement tooling can often lead to the underlying processes being weak or ill conceived. However this is common in other disciplines too. Poor planning = poor performance.

DevOps done well can bring a great set of tools and capability for building secure, scalable and compliant environments. Building on modern source control, streamlining change control and building dependency on the tools authentication and access control can quickly be used to demonstrate the control requirements of many compliance frameworks including the PCI DSS. Just doing things faster or without lots of paper forms and signatures on doesn’t necessarily equate to non-compliance.

The implementation of PCI DSS requirements 2 and 6 can be rapidly transformed using a DevOps approach. If we look at requirement 2 as being primarily focused on hardened configuration management traditionally seen as an ‘Ops’ area, whilst Requirement 6 focuses on change management and software development.

There is nothing fundamentally in these requirements (or in other areas of the DSS) that prevents a DevOps environment being used to support and implement PCI compliance if done carefully. Whilst the security and compliance mandate might tweak certain implementation decisions most of the tools marketed for ‘DevOps’ support building workflows that can be used for approval / review decisions and capture/log the necessary approval processes to support compliance. As the level of automation increases so can the ease of which compliance requirements be met.

Recently I worked with a client that had invested heavily in building their dev-ops tooling but had built in PCI requirements as part of this process so also incorporated automation of documentation production too.  Their focus was, and still is, to automate as much as possible into the release process to minimize the failure of an activity. Every time a new release was pushed all configuration documentation was also updated automatically (supporting requirement 2) .

This particular client used a software issue and tracking tool that could be used to demonstrate management approval for changes as well as to show that code review processes had been followed. As they continued to improve they were investigating automation of their code review processes so that static analysis tools were orchestrated immediately after changes were approved as part of the build process.

One of the biggest challenges they faced initially was the size of their team, they were small and specialist and in the past had struggled with creating segregation of duties between their test/production systems.  Moving to DevOps helped with this significantly. No developers were required to have access to production systems in any manner as the build and release process was entirely orchestrated by tools with an approval workflow that the developers couldn’t authorize alone. The tools were the only thing with the ability to push to their production systems and the workflow done under management approval. These tools were treated the same way as other in-scope systems but the overhead from this was so minimal that it enabled them meet security requirements without complicated manual processes and multiple sets of access permissions.

Advertisements

PCI Awareness Training – official courses are now available

The PCI Council has announced that it is offering PCI Awareness Training to anyone interested in learning more about PCI DSS.

The dates of the official council courses are

  • 2 March 11, 2011 London, England 09:00-17:30 $995 USD plus local taxes
  • 3 April 1, 2011 Sydney, Australia 09:00-17:30 $1500 USD plus local taxes

 Course Description

  • What is PCI and what does it mean to companies that must meet compliance with the DSS?  An overview of the payment card industry, the terminology used within the industry, the flow of transaction data through the various components that make up the payment card industry, and the relationships between the various organizations in the process.
  • How the credit card brands differ in their validation and reporting requirements – Detailed coverage of the classifications and compliance requirements for merchants and service providers and details about the various card brands’ compliance programs.
  • Roles and Responsibilities – Descriptions of the key actors in the compliance process including high-level overviews of the Qualified Security Assessor (QSA), Internal Security Assessor (ISA), Payment Application Qualified Security Assessor (PA-QSA) and Approved Scanning Vendor (ASV) programs.
  • PCI Data Security Standard (DSS) – An overview of the current DSS (version 2.0), the testing procedures for validating compliance, and what constitutes compliance with the requirements.
  • PCI Hardware and Communications Infrastructure – Generalized overview of the types of devices used by organizations to accept payment cards and communicate with the verification and payment facilities.
  • PCI Reporting – An overview of the different types of reports that must be submitted to the card brands or their designated agents to demonstrate compliance (or non-compliance) of the organizations filing the reports.
  • Real world examples – An overview of compliance issues and mitigation strategies including defining compensating controls, creating policies and modifying the cardholder data environment.

 

PCI often fails because of an employee’s action so it is good to see the PCI Council has launched these courses. However, there is only one course in Europe and it is on a first come first served basis which means only a few of the millions of European Merchants will gain any advantage.

I have found “general” PCI Awareness courses fail to meet the needs of organisations because:

  • The course will be pitched at differing skill levels, from beginners (hopefully there are not too many left) to experts who may have been through external Audits by a QSA.
  • It is not specific to an industry type, the needs of an e-commerce merchant are very different to a mail order/telephone merchant.
  • The individual employee has the daunting task of taking the knowledge and rehashing it for the rest of their organisation. Even if they have the slide ware they never have the gravitas of an external trainer or QSA who can handle all the questions that will be fielded.

 

There are alternative sources of training who will deliver public or bespoke courses for an organisation.

In a recent client scenario, we provided a 1-day classroom based training for senior managers, a series of ½-day road trip stop local sites for branch workers and 1-hour web-based sessions for field-based staff.

This ensured the right people gained the right knowledge when and where the client required it.

Find the details of the PCI Council courses here or ping me an email for ideas on how you can make your employees more aware of PCI.

Blog at WordPress.com.

Up ↑

%d bloggers like this: