Global travel retail business – As part of their Cyber Security Strategy – Attain PCI DSS (Payment Credit Industry Data Security Standard) compliance.
The client is one of the world’s leading travel management companies and operates in 92 countries.
They are an Australian-based international travel company and the largest retail travel outlet in Australia. Its global operations include stores in New Zealand, the United States, United Kingdom and Canada, as well as outlets in India, China, Hong Kong, Singapore and South Africa. The company is listed on the Australian Stock Exchange with an annual total turnover of $13.2 billion sales as of June 2012. It has more than 2,500 stores in 10 different countries with over 15,000 staff and owns several niche brands.
The client takes the security of their client’s data and the security of its systems very seriously.
They greatly value the long term relationships and trust they have built up with clients over many decades and have no intention of harming the relationships and risking confidence in the business as the travel industry becomes even more reliant on the flow of data.
One of their cyber security objectives is to become globally PCI DSS (Payment Card Industry Data Security Standard) compliant.
The achievement of the PCI DSS standard in the travel industry is recognised as a mark of quality, and shows that customers can trust their sensitive payment card information will not be mis-used or vulnerable to abuse.
The PCI DSS standard has also become an important differentiator when tendering for new, and maintaining existing, contracts.
Compliance with the PCI DSS means that a company’s systems are secure, and its customers can have trust and confidence in doing business with them.
Many other travel companies and airlines have tried to become PCI DSS compliant but have suspended the project, mainly because they cannot properly define System Components and the Cardholder Data Environment (CDE).
The PCI Security Standards Council (PCI SSC) defines System Components as network, servers, virtualisation components and applications. Network components may include firewalls, switches, routers, and other security appliances. Server types may include web, database, authentication and other devices. Applications include internal and external applications, including internet-based.
The system component becomes part of the CDE if it stores, transmits or processes Cardholder Data, or if it is connected to another system that performs such a function. As such, any IT infrastructure that is part of the CDE becomes liable to scrutiny under PCI compliance laws, including any application or service provided by a third party.
In order to capture the System Components and CDE and a company needs to understand:
- Which people are involved at each stage of a credit card transaction – from taking the initial payment, to processing orders, generating refunds, preparing invoices, ensuring order fulfilment, customer account creation, financial consolidation of orders from credit card companies.
- What systems are used at each stage of the process, and which IT equipment is needed for that system to operate.
- Which hardware and software is utilised when handling and transmitting Primary Account Numbers (PANs) which can uniquely identify the user and cardholder account.
- Where the data flows and the points on the network it touches so cyber security techniques can be applied to prevent penetration gaining access to vulnerable equipment.
- At what point is data at rest and whether it is encrypted or unencrypted.
This is a challenge.
Becoming PCI DSS compliant is usually an onerous task, one which many companies have difficulties achieving.
A critical problem is that companies cannot identify the relationships and dependencies between the people, processes and IT assets in the business. Which means they cannot create the mandatory dataflow diagrams that are now a requirement.
By using The OBASHI Methodology, the client successfully mapped its System Components and fully defined its Cardholder Data Environment.
In order to maintain the good governance and operational integrity achieved for PCI DSS, the client is further embedding OBASHI within its change control process. A further case study about this aspect of the project will be published in the future.
Senior Management were well aware of the fact that other well known global travel companies had tried and failed, at considerable expense, in their attempts to attain PCI DSS compliance.
Circumstantial evidence as to why these failures occurred indicates that the major factor was that there was no standard way to capture and communicate information (internally, externally with third party service providers, and particularly with the Auditor) in a clear and consistent manner to meet the compliance standard requirements.
In order to achieve PCI DSS v3 compliance there has to be an initial understanding of how the existing business processes operate. Only then can an assessment be made of which processes form the CDE and how those processes would need to be changed to ensure the criteria set out by the PCI SSC could be met. All of the IT equipment, and the data flowing through it that support those business processes, also needs to be mapped to ensure PCI DSS compliance.
In practical project terms, the problems of achieving PCI DSS v3 compliance is understanding the complexity and interconnectivity of the IT assets and which of those devices support the business processes. Without this clarity, organisations are not aware of how a seemingly small or apparently inconsequential decision about business process change for PCI DSS v3 can have a profound impact on how the IT systems operate and the risks to the business that a change may generate.
And conversely the technical experts are constrained by being unable to see clearly of how important the equipment and software they manage affects the business through their interaction with the CDE.
Being able to pull together domain experts from business and IT disciplines and being able to communicate problems, requirements, risks and recommendations is critical to project success.
- The client became PCI DSS complaint on the 20th February 2015
- Cyber Security and PCI DSS compliance are strategically important to the client
- Clear communication between business and IT personnel was critical to project success
- OBASHI B&IT diagrams used to model the Card Data Environment and Card services
- OBASHI Dataflow Analysis View diagrams solves PCI DSS requirement 1.1.3
An example B&IT diagram showing how people, process and technology can be combined to provide a context rich document that aids communication and is easy to understand across all disciplines.
As well as clear communication being key, the new requirement in Section 1.1.3 for compliance has been added to version 3 of the standard.
Section 1.1.3 says there must be a “current diagram that shows all cardholder data flows across systems and networks”
The standard guidance states : Cardholder data-flow diagrams identify the location of all cardholder data that is stored, processed, or transmitted within the network.
Network and cardholder data-flow diagrams help an organization to understand and keep track of the scope of their environment, by showing how cardholder data flows across networks and between individual systems and devices.
To achieve this requirement takes a rigorous engineering approach, not just to the technical side, but a deep understanding of how and when IT supports the business.
An example Dataflow Analysis View (DAV) diagram showing how data flows through the people, process and technology in an organisation. A great way to document and analyse how credit card data flows through the Cardholder Data Environment.
Under the leadership of the Head of Technical Services, the IT function had used The OBASHI Methodology to map out some of the existing landscape in order to provide better operational and project support within their highly virtualised environment.
Like many global organisations, the clients operational and communication infrastructure is a sophisticated mixture of thin client, thick client and a vast array of virtual computing, cloud and other global 3rd party digital support systems and services.
Their Information Security Officer and Quality Assurance team realised very quickly that to become PCI DSS compliant they had to find a simple practical way to communicate internally between different groups of employees spread across different levels in the organisation.
Having been given exposure to The OBASHI Methodology they recognised early on that OBASHI could solve both the communication and PCI DSS v3 1.1.3 problems.
As some of the employees were already OBASHI certified, they knew the 5 phases that make up The OBASHI Project Life Cycle. These project phases, and how they applied to PCI DSS Compliance Project are given below:
Scope phase – The Scope phase defines the business requirement. The OBASHI project is initiated to service this business requirement.
Initial consultation with the client, together with the PCI DSS v3 Requirements documentation, enabled the Compliance Project to define the delivery requirements for the OBASHI project. Understanding the System Components was to be essential in order to define the Cardholder Data Environment.
Capture phase – The Capture phase gathers and analyses information which is used to create the OBASHI model.
A key part of the Capture phase involves identifying sources of information which can be used to build the OBASHI model. The client, had some existing OBASHI diagrams which proved an excellent start to the project as they detailed some of the current operating environment.
Coupled with this, the client had made extensive use of IBM’s BlueWorks business process modelling application. The Business Analysts had a good definition of current business processes but, like many other companies, had no sight of how these processes mapped onto the underlying applications and IT equipment that delivered the service.
Asset registers and network diagrams were also identified as key documents which could be used to build the model.
Design phase – During the Design phase the information gathered during the Capture phase is modelled with Business and IT diagrams (B&ITs) and Dataflow Analysis Views (DAVs). B&ITs are produced detailing the specific areas of project delivery identified during the Scope phase.
Additional B&IT diagrams were created specifically to define the CDE. By using the IBM Blueworks business process flow diagrams we could model all of the Applications, Operating Systems, Hardware and Infrastructure needed to support the business process flow. That provided an excellent context for the PCI DSS requirements, and allowed the Business Analysts to gain an appreciation of the impact of change at a business process level.
These B&IT diagrams described the business as it operated in its Current State, known as “Business As Usual” or BAU. Future State diagrams were also created to show how the network, systems and processes would look once the project was completed. These could be used to plan the project phases and provide the documentation which could be handed over to reflect the new operating environment on project completion.
Refine phase – The Refine phase drills down further into the B&IT diagrams, adding more detail where required. This activity ensures that B&ITs are finalised and ready for handover and sign-off of the project.
One of the essential refinements made to the Dataflow Analysis View was that of colouring the elements on the diagram. While this seems a simplistic refinement, the colours were used to signify where data was at rest and where it was in transit. This simple visualisation made it clear to all concerned where attention needed to be made to ensure encryption and cyber security considerations were at their most effective.
Handover phase – The Handover phase ensures that the deliverables created during the project are passed into the operational business environment.
Although the deliverables were handed over into the operational business environment, the primary objective was to handover documentation to the PCI DSS Qualified Security Assessor (QSA) of a sufficiently high standard such that it could be used to grant PCI DSS v3 Compliance – an objective that was achieved first time, on time and on budget.
The client became PCI DSS compliant on the 20th February 2015.
The Auditor, CNS Group remarked they were:
“particularly impressed with the approach to compliance taken, as it is very much founded in strong operational processes and an approach to security that stresses the day to day operations and capabilities.”
Kevin Dowd, QSA
Becoming PCI DSS compliant for the client is not just about governance anymore, it’s a marketing tool as well. With Cyber crime on the rise, companies that issue tenders are putting a higher value on risk, with questions such as “Is your company PCI DSS compliant?” being prominent.
The travel industry’s stock answer for this has been “We are working towards compliance”, but the client recognised this was not acceptable from a Commercial, Governance or Security perspective. Differentiation within the market place means future business can now be won because they have a PCI DSS advantage over the competition.
Using The OBASHI Methodology the client to map out its System Components, Business Processes and people in a simple and flexible way so everyone could participate and add value to the project, regardless of their domain expertise.
With the interdependencies of people, process and technology mapped in context, the Cardholder Data Environment was identified and the flows of data mapped.
As such, OBASHI acted as the spine that related all the critical business assets, the people the process and technology together. So is this why the client succeeded in achieving PCI DSS compliance where many other global travel organisations failed?
We think OBASHI gave the client the mechanism to create the best environment for success, but it comes down to three key things:
Communication – Good old fashioned teamwork centred around documentation that both business and IT professionals could easily understand.
Architecture – CDE Cardholder Data Environment – The ability to actually understand how all parts of the business relate to each other to make it work.
Outputs – Accurate analysis of the facts at architecture, service and dataflow levels – delivering business critical documents that can be used and updated as part of day to day operations, governance and cyber security business activities.
“ Cyber Security policy is one thing… the practical operational delivery is something else. ”