Sask 3.0 Summit Pci dss presentation Bashir Fancy

© 2010 Grant Thornton International. All rights reserved.

How do you achieve security for your enterprise and in turn achieve effective Compliance?

Saskatchewan Summit 3.0

Payment Card Industry

“Compliance does not equal to security”

Bashir Fancy, MD, Corporate Solutions & Services Inc.

Special Advisor,

Grant Thornton LLP

April 25, 2012

1

Corporate Solutions & Services Inc.

Corporate Solutions & Services

Objectives

This session will focus on:

1. A quick review of what the problem was and is

2. How we are approaching the PCI Compliance standard in the last few years

1. The reason for limited success

3. How to approach PCI Compliance as part of your overall security compliance effectively and achieve sustainability

2

Challenges that Organizations face

Without an effective data protection policy/process in place, your Organization

runs the potential risk of sensitive data loss, which can impact:

– Brand reputation

– Fraud Losses and financial impact

– Breach notification costs

– Costs to manage fraud

– Possible fines from credit card companies

– Loss of customer confidence

– Undesired regulatory attention

Your Organization may not be taking advantage of the opportunity to improve

efficiency, cost savings and improved bottom-line

PCI compliance would not have been required in the first place, if all the

Organization had been doing the right thing to protect the sensitive

information

3

Background to the development of PCI

Significant Fraud losses have been occurring in Canada & Globally in both card present (swiped) & card not present (online) environment

• Stored data not protected by acquirers/merchants/3rd Party Processors

• Sensitive data easily accessible, was not protected by processors

• Transmission of credit card data in clear text, making it easy to compromise

• Organized crime infiltrated major organizations and continue to do so today

• High proportion of compromise had a major internal component

• Lot more information continues to be stored than needed to conduct business

Brand impact can be significant with loss of confidence by consumers being impacted by the compromise.

Significant costs to handle customer service issues including card replacement costs, credit monitoring fraud losses and eventually resulting in loss of business

Visa was concerned that fraud losses were becoming acceptable as “cost of doing business”

4 Grant Thornton LLP - Achieving compliance and security Corporate Solutions & Services Inc.

Data: asset and liability

Data is both an asset and a liability. As organizations grow, the volume and complexity of data increases to support the business. Sensitive data within the enterprise must be protected against theft, loss, and misuse, assuming there are legitimate reasons to store it in the first place.

This data includes:

• customer's information

• patent or trade secrets

• corporate information

• personally identifiable information

• credit card data

5

Without an effective method to:

• Discover data, it is difficult to apply the appropriate

security controls to protect it

• Classify data, it is difficult to understand the importance

and sensitivity of the data and what should be

protected

• Control data, it is difficult to restrict access to data,

prevent misuse of it, and secure it at rest and in transit

• Audit data and its usage, it is difficult to enforce the

security controls

As a result, it is difficult to adequately protect data

throughout its life cycle across the Organization

Challenges that Organizations face

• Initially there was a lack of support from the corner suite as not all

Organizations truly understand the value of PCI standards

• Today many Organizations adopt it as a compliance issue, primarily to achieve

the certification paper

• Organizational silos prevent a holistic view to the magnitude of the problem

that create subsequent losses and costs

• Worse, these costs and inefficiencies have become part of our infrastructure

• Fraud is seen by many organizations as a “cost of doing business” and these

losses have been normalized

• Organizations track only the dollars they write off on the books and NOT costs

to manage fraud that are distributed across the organization

6

Lessons Learnt (Observations)

• Organizations are doing the bare minimum to comply- putting their brand at

risk

• PCI is NOT part of broad regulatory/audit/compliance with no ongoing

oversight or program/strategy in place to sustain compliance

• Remediation efforts have been undertaken using the letter of law. No

“enterprise wide owner” – lack of stakeholder involvement

• Widespread access to critical data – “grandfather rights” -reluctance to change

• PCI still seen as a “Credit Card” mandate only

• Lack of effective access controls, including the Point of Sale

• Communication and awareness has been lacking or has been selective

• There are a lot of make work projects that neither produce security or

enhance the operations!

• We still see misunderstanding of the requirements and/or collusion

7

Lessons Learnt (Observations)

• Organizations continue to store data that is not required to conduct the business.

• Some Organizations have opted for tokenization, but the benefits of this approach

have been minimized because the whole project was not thought through.

• For example the ability to translate exists in many parts of the Organization.

• Some credit card processing has been outsourced without due diligence to whether

the outsourced organization is in fact PCI compliant or secure. Outsourcers do

outsource some of the work further down the stream compounding the problem

• Lack of an enterprise-wide owner and done on a one time effort – NOT SUSTAINABLE

• Organization have not done the mapping and as such duplicate the work instead of

“do it once and satisfy many”

• Some Organizations have embarked upon remediation without first doing data

classification/discovery - Lack of Strategy

8

Going Forward

• Contracts managing third parties have not keep pace with changing business

needs and in some instances, have not stipulated the right to audit the third

parties – need to review contracts

• Many of the processes have been derived from the paper based business and

do not necessarily reflect the current environment or need

• Utilize “compensating controls”. This has significant impact where legacy

systems are involved or where organizations may have invested in a different

approach/technology to secure themselves

• The road to PCI compliance crosses many departments - Must have buy-in

from the top; otherwise organizations risk failure and/or continued exposure

• Take into account the original problem (fraud, data loss, data breaches, brand

impact) that the PCI-DSS standard was developed to address, thereby taking a

broader perspective, so that organizations can get a return on their investment

9

Going Forward

• A carefully thought through, holistic and risk-based approach is required to take

advantage of the synergies that exist between PCI-DSS, SOX, AML etc.) – “Do Once

and Satisfy Many”

• Take a “risk based approach” – not all risks have to addressed, but they must be

understood

• First and foremost understand the data flows fully. Review, justify and rationalize

what you really need to conduct your business. There will be resistance but

Organizations must enforce the discipline of streamlining and managing who has

access to what, why with proper oversight.

• This approach will help reduce the overall effort, optimize operations and produce a

“return on investment”

• Review access controls and limit access

• Build a value proposition beyond just compliance

• Technology, Process and People must be aligned

10

© 2010 Grant Thornton International. All rights reserved. 11

COSO - Overview

12

COSO Objectives and Components

© 2010 Grant Thornton International. All rights reserved. 13

COSO Principles


Frameworks for IT 'GRC'

ITIL

IT Infrastructure Library – collection of best practices in IT service management

ISO 27001/ ISO27002

Code of practice for Information Security Management

Guidelines for the Management of IT Security

NIST 800 series

Generally Accepted Principles and Practices for Securing IT Systems

CobiT

Control Objectives for Information and related Technology

IT processes defined

controls framework

stresses linking IT to business requirements

layered

• orientation

• detail

• can be mapped to the other standards and practices

14

Various IT Internal Control/Process Models Exist


IT Governance in COBIT

• IT delivery must enable the

organization to achieve its

objectives.

• Promotes process focus and

process ownership.

• Looks at fiduciary, quality and

security needs of enterprises.

• 7 information criteria to define

business requirements.

• Supported by 300+ control

objectives.

1. Effectiveness

2. Efficiency

3. Availability

4. Integrity

5. Confidentiality

6. Reliability

7. Compliance

1. Planning

2. Acquisition &

Implementation

3. Delivery & Support

4. Monitoring

15

IT Governance in COBIT

Corporate Solutions & Services

Going Forward

• Making PCI an integral part of the compliance building blocks throughout the

organization, PCI should be a subset of your overall Security Strategy

• Making Education & Awareness corner stone of this strategy, not just as one time

but ongoing and part of performance review

• Adopt best practices

• Hold accountable employees that violate/breach the process

• Ensuring that a dynamic security policy exists, or is developed to complement

your technology and operational efforts

– Ensure that the staff understand the policies and that the communication is

very clear

• Technology/Process and People must be aligned

16

Addressing Compliance

The Sustainable Approach

Step 1:

Identify, review and assess all of your security requirements (including the PCI of course). Rationalize your requirements into a single enterprise security “framework” and manage as part of your overall security program.

Key Factors:

• The framework should be built on industry standards (e.g. ISO17799, 27001, NIST, OWASP, etc.) and incorporate relevant requirements (PCI, etc.).

• Track the source of the requirement!

• Use the framework as the basis for measuring and monitoring security for your enterprise.

17



Step 2:

Embed your security framework (requirements) into relevant business processes.

Key Factors:

• Not all of these processes will be owned by IT or Information Security.

• Your framework must be practical in order to succeed.


18



Step 3:

Conduct a data flow analysis and system ‘inventory’ effort to understand the complete lifecycle of the (cardholder) data you wish to protect. That includes:

• Acquisition

• Processing

• Storage

• Usage

• Destruction

Key Factors:

• Do not assume you know where the data is – many of the issues we have seen involve data that was not supposed to “be there”. Be systematic, don’t accept the easy answer.

• Data is an asset and a liability – if you don’t need it, get rid of it!

• Do not store full track, CVV2, etc. post authorization – challenge the teams that tell you it is necessary.

19



Step 4:

Conduct a security risk assessment. Prioritize (risk rank) systems, applications and infrastructure components.

Key Factors:

• Work with relevant stakeholders to define the risk factors/criteria.

• This is a risk based approach – it does not need to be an exercise in mathematics.

• Not all systems present significant risk.

• For most companies, protecting everything perfectly is not a realistic goal. Make risk based, strategic choices about where to apply your investment.

20



Step 5:

Systematically assess the critical systems, applications and components in your environment using your security framework. Identify gaps, develop solutions appropriate to the risk and remediate.

Key Factors:

• Look beyond the individual requirements and across the environment. Address issues from a enterprise security perspective where appropriate.

• Leverage other functions where possible (e.g. Internal Audit)

• Automate assessment tasks where possible. Sample where appropriate.


21



Step 6:

Make this an ongoing process. Repeat.

Key Factors:

• This should be an ongoing process. The initial effort will be the most significant but it should greatly reduce the effort going forward.

• The data flow analysis and system inventory should return value across multiple initiatives. It should be incrementally updated on a regular basis.

• As new requirements are devised, add them to your framework and continue moving forward.


22


Benefits of The Sustainable Approach

• Reduced Effort

- One program as opposed to multiple programs

- Streamline compliance validation going forward

- Leverage technology and process improvements to meet multiple requirements

• Improved Security

- Risk based approach allows for investment in the most critical areas

- Systematic, consistent assessment against the enterprise security framework allows for a holistic approach to security

23


Level 3 and 4 Merchants

The same process should work for you:

• Simplified framework

• Fewer systems to inventory, risk rank, assess, etc.

Other Factors to consider:

• Focus on security when dealing with key service providers: web design and hosting companies, payment processors, POS systems integrators, etc.

- Ask about their security strategy and design as it relates to the product/service they offer.

- Are they are PCI compliant? Do they store track data? What safeguards do they have in place to protect your customers?

• To the extent possible, understand your entire payment chain.

• Ensure you legal contracts reflects your needs and protects you.

• You don’t have to be big to be a target. Criminals are opportunistic.

24

Remediation

I

� Approach

� Compensating Controls

� Common Compliance Issues

� Scope Reduction

� Other Items to Consider

� Tactical Fraud Prevention

� Be Prepared - Incident Response

� What To Do If Compromised

25

Remediation

Approach

As a general framework to approaching remediation of compliance issues, an organization should consider the following:

• What constitutes compliance (i.e., mandatory versus addressable requirements)?

• Is the issue isolated or pervasive?

• What is the priority of the issue?

• Is the issue already being addressed? If not, can it be incorporated into an existing effort?

• Can you do it now, how much will it cost and what is the impact?

- Solve it now, or

- Interim solution plus long-term strategy

• What is the complexity of remediation?

• What retroactive remediation needs to be done?

• What are the on-going operational costs and resource requirements required to sustain the solution in the long-term?

• What governance and controls are needed?

- How do you manage compliance?

- Not just PCI problem

- Managing compliance across the organization

26

Remediation

Compensating Controls

• The PCI DSS allows for compensating controls “…when an entity cannot meet a technical specification of a requirement, but has significantly mitigated the associated risk.”

• Compensating controls must:

1. Meet the intent and rigor of the original stated PCI DSS requirement

2. Repel a compromise attempt with similar force

3. Be "above and beyond" other PCI DSS requirements (not simply in compliance with other PCI DSS requirements) and

4. Be commensurate with the additional risk imposed by not adhering to the PCI DSS requirement

• Compensating controls may be considered for all requirements EXCEPT storage of prohibited data (i.e., full track data, CVV2, PIN) post-authorization (Requirement 3.2).

27

Production data directly produced (“pulled”)

1

2Production data “pushed” using a Technology Intermediary

Production data “pushed” without using a Technology Intermediary

4Production data restored to the non-production technology environment

Data leaves Organization’s production environments through many Channels. Outlined below are some of the ways data does leave production.

How data leaves production (Data discovery)

28

PCI remediation & compliance methodology

29

Risk Assessment

& Prioritization

Development of

Remediation Strategy & Solutions

Remediation & Testing

CertificationData

Discovery & Analysis

Leverage Example 1: Establishing common controls/ processes

30

General Computer Controls

CobIT 4.1PCI Data Security Standard

ISO 17799 / ISO 27001

Achieving compliance does not necessarily mean

becoming secure.

However, achieving security does translate into

compliance.


Questions


Thank You

Bashir Fancy,

Special Advisor

Grant Thornton LLP

E [email protected]

[email protected]

T: 905 232 9191

C (416) 716-3418


Date post:	24-Jun-2015
Category:	Technology
Upload:	sasksummit
View:	878 times
Download:	2 times