2010 07 BSidesLV Mobilizing The PCI Resistance 1c


Published on

Properly Mobilizing the PCI Resistance: Lessons Learned From Fighting Prior Wars (SOX-404)"

I have noticed that there is a growing wave of discontent and disenchantment from information security and compliance practitioners around the PCI DSS. Josh Corman has been an effective voice for these concerns, providing an intellectually honest and earnest analysis in his talk “Is PCI The No Child Left Behind Act For Infosec?”

The problem are well-known and significant: too much ambiguity in the PCI DSS, Qualified Security Assessors (QSAs) and consultant using subjective interpretations, existing guidance either too prescriptive or too vague, scope missing critical systems that could risk cardholder data, overly broad scope and excessive testing costs, excessive subjectivity and inconsistency, poor use of scarce resources, no meaningful reduction in risk of data breaches, and so forth.

For years, I have been studying the PCI DSS compliance problem, as well. I have noticed many similarities to the PCI compliance challenges and the “SOX-404 Is The Biggest IT Time Waster” wars in 2005. I was part of the leadership team at the Institute of Internal Auditors (IIA) where we did something about the it. We identified inability to accurately scope the IT portions of SOX-404 as the root cause of the billions of dollars of wasted time and effort, while not reducing the risk of financial misstatements.

I propose to present the two-year success story of the IIA GAIT project and how we changed the state of the IT audit practice in support of SOX-404 financial reporting audits. We defined the four GAIT Principles, which could be used to correctly scope the IT portions of SOX-404. We mobilized over 100K internal auditors, the SEC and PCAOB regulatory and enforcement bodies, as well as the external auditors from the 8 big CPA firms (e.g, Big Four and other firms doing SOX advisory work). In short, we made a difference, in a highly political process that involved many constituencies.

I am attempting to do something similar with the PCI Security Standards Council, through my work as part one of the leaders of the PCI Scoping SIG (Special Interest Group). My personal goal is to find a “third way” to better enable correct scoping of the PCI Cardholder Data Environment, and create a risk-based approach of substantiating the effective controls to ensure that cardholder data breaches can be prevented, and quickly detected and corrected when they do occur.

My desired outcome is to find fellow travelers who also see the pile of dead bodies in PCI compliance efforts, and work with those practitioners to catalyze a similar movement to achieve the spirit and intent of PCI DSS.

Published in: Business
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • There are many ways to react to this: like, fear, horror, trying to become invisible… All understandable, given the circumstances…
  • 2010 07 BSidesLV Mobilizing The PCI Resistance 1c

    1. 1. Mobilizing The PCI Resistance:Lessons Learned From Previous Wars (SOX-404)<br />Gene Kim, CISACTO, Tripwire@realgenekim, http://www.realgenekim.me#BSidesLV 2010<br />
    2. 2.
    3. 3. Problem Definition<br />Success of any PCI DSS compliance initiative is very dependent on accurate definition and scoping of the Cardholder Data Environment. <br />There is a wide variance in practice, experience and guidance in merchant and QSA community.<br />These contribute to scoping errors that result in:<br />Overly narrow scope that jeopardizes cardholder data<br />Overly broad scope that adds unnecessary cost and effort for compliance <br />Decreased confidence in and frustration with the PCI DSS standard<br />
    4. 4. What This Really Means<br />Incredible amount of discontent and growing disenchantment with PCI DSS<br />Complaints that DSS is too specific or too vague<br />Like Michelle Klinger, I have a love/hate relationship with PCI DSS<br />The reach of PCI DSS is awesomely breathtaking, and is relevant to all PII<br />But in the worst case, it's a total waste of time, at enormous cost to the organization<br />
    5. 5. Agenda<br />Describe the problems around SOX-404 <br />What we did about it at the Institute of Internal Auditors<br />The GAIT concepts, politics, tools and outcomes<br />Show how we can use this as a model to change the state of the practice around PCI DSS<br />Share with you the best formulation of the plan I have<br />Get your help improving the plan<br />And ideally…<br />Share my biggest a-ha moments the GAIT experience<br />Excite you enough to do something about it<br />Tell you some interesting stories<br />
    6. 6. Holy Crap. This Looks Familiar!<br />
    7. 7. The Problem<br />The IT portions of SOX-404 compliance has frustrated auditors and management<br />Significant key controls reside inside IT and IT processes as well as in the business processes<br />No well-established guidance for scoping IT work results in inconsistency and the process being overly subjective<br />Sometimes result in overly broad scope and excessive testing costs<br />Significant risks to financial assertions may be left unaddressed<br />Suboptimal use of scarce resources<br />
    8. 8. Why Is There A Problem?<br />No clear guidance exists to define how IT processes and activities can invalidate financial application processing or financial assertions<br />COSO provides an accepted construct for defining overall internal control objectives, assertions, risks and controls, but its application to the IT environmet is ambiguous<br />COBIT doesn’t provide a clear mechanism to scope IT processes and controls to the achievement of specific internal control objectives (e.g., COSO objective for internal control over financial reporting)<br />Something else is needed…<br />
    9. 9. “OMG. 952 IT Deficiencies?!?”<br />
    10. 10. Vision: Create Equivalence to Nine Firm Document on IT Control Exceptions<br />GAIT takes the approach used in the nine firm document.GAIT represents the upfront scoping exercise to appropriately identify the IT controls work relevant to overall internal controls objectives<br />Chart 3: Evaluating Information Technology General Control (ITGC) Deficiencies, “A Framework for Evaluating Control Exceptions and Deficiencies” (December 20, 2004)<br />
    11. 11. What were/are people worried about?<br />Holy cow!!! Enron wasn’t caused by a DBA. So, why are the auditors digging here?? --gk<br />IT controls dominate the deficiencies, significant deficiencies, and material weaknesses identified through the S-O 404 assessment.<br />The estimated percentage of deficiencies identified show IT controls accounting for the most (34 percent), followed distantly by revenue (13 percent), procure to pay (10 percent), and fixed assets (10 percent). <br />The estimated percentage of significant deficiencies identified again shows IT controls leading the way (23 percent), followed by financial reporting and close (14 percent), procure to pay (13 percent), and revenue (12 percent).  <br />The estimated percentages of material weaknesses identified include IT controls (27 percent), revenue (18 percent), taxes (11 percent), and financial reporting and close (10 percent).  <br />It is important to note that the results presented here are based on self-reporting by the companies that participated in the survey. Conclusions may be affected by the differing methods companies use to report on various elements of Sarbanes-Oxley compliance.<br />
    12. 12. February 2006<br />Corporate Finance<br />12<br />PROBLEMS & CHALLENGES<br />Again, holy cow!!! If the risk isn’t in IT, then auditors are not only generating efforts, but finding deficiencies that don’t matters… --gk<br /><ul><li>Disproportionate Share:
    13. 13. Compliance effort.
    14. 14. Deficiencies.
    15. 15. Non Finance Apps.
    16. 16. Financial Statement Impact:
    17. 17. Indirect linkage
    18. 18. Least likely impact
    19. 19. Business & IT integration.</li></li></ul><li>Why We Knew There Was A Better Way<br />All the work using Chart 3 is linking controls to risks that actually mattered<br />COSO describes objectives, risks, controls and assertions<br />COBIT is an exhaustive list of controls<br />This is called scoping, which is critical to getting the right outcomes<br />Comes before control design, implementation and testing<br />
    20. 20. Thought Experiment<br />Auditors vs. Management<br />We can agree that there are two extremes in spectrum of financial reporting risk<br />eBay auction settlement business process<br />Grain elevators<br />Extremes are easy… Middle is hard…<br />
    21. 21. PCI Scoping Exercises (Show Your Work!)<br />Question 1: Is the Cardholder Data Environment (CDE) equivalent to the PCI Scope of Assessment?<br />Question 2: Is a domain controller (e.g., Windows Active Directory server) that is being relied upon by CDE applications for authentication and security services in the PCI Scope Of Assessment?<br />Question 3: How about a domain controller (e.g., Windows Active Directory server) that is not relied upon by any CDE applications?<br />Question 4: Is a network attached stapler that happens to be on the same network segment as a CDE system component always also in the CDE?<br />Question 5: Does it matter if a workstation that a customer service representative uses a thin- or thick-client?<br />Question 6: When should it be acceptable that if a virtualization hypervisor hosting a production application in the CDE be also able to host another VM without it being part of the CDE, as well?<br />Question 7: If you have a domain controller that is not in the CDE, but in the scope of PCI assessment, is a print server on the same network segment as that domain controller also in the scope of PCI assessment?<br />Bonus Exercise: For each of the questions where you answered "in scope of the PCI assessment," describe a strategy to contain the scope, such that systems connected to that system are not in scope. (See Michelle Klinger's great post on the "PCI Contagion Dilemma.")<br />
    22. 22. SOX-404 Value Network: Primary Constituencies<br />
    23. 23. What Does PCI Value Network Look Like?<br />
    24. 24. Language Is Often An Obstacle<br />In Newton’s time, there were not concrete terms for several critical concepts:<br />Force, acceleration, mass, inertia<br />In the following slide, note how difficult it was for Newton to frame the “three laws of motion” without these concepts…<br />
    25. 25. Early Drafts Of Three Laws Of Motion<br />1. If a quantity once move it will never rest unless hindered by some externall cause.<br />2. A quantity will always move on in the same straight line (not changing the determination nor celerity of its motion) unless some externall cause divert it.<br />3. There is exactly so much required and no more force to reduce a body to rest as there was to put it upon motion.<br />Axiom 100: A body once moved will always keep the same celerity, quantity and determination of its motion<br />Axiom 103: ...as the body (a) is to the body (b0), so must the power of efficacy vigor strength or virtue of the cause which begets the same quantity of velocity<br />Source: Isaac Newton, James Gleick.<br />
    26. 26. Benchmarks<br />Pythagorean theorem: 24 words<br />Archimedes' Principle: 67 words<br />Newton’s Three Laws Of Motion: 91 words<br />The 10 Commandments: 179 words<br />GAIT Proposed Principles v3.0: 168 words<br />The Gettysburg Address: 286 words<br />The Declaration of Independence: 1,300 words <br />GAIT Principles v1.3: 6,856 words <br />GAIT Methodology v2.2: 11,348 words<br />The US Government regulations on the sale of cabbage: 26,911 words<br />
    27. 27. Solution: GAIT…<br />Released in Feb 2007, Establishes four principles that<br />Defines the relevance of IT infrastructure elements to financial reporting integrity<br />Define the three types of IT processes that can affect them: change management and systems development, operations and security<br />Defines an end-to-end process view of these three processes<br />Defines an approach to defining objectives and key controls within those three processes<br />Provides a methodology and thinking process that continues the top down, risk based approach started in AS2 to scope IT general controls<br />Provides a common context for management and auditors to support and test management’s assessment that the necessary IT controls exist and are effective<br />Initial target is internal control objectives for financial reporting, but should extend to operating effectiveness and complying with laws and regulations (as defined by COSO)<br />
    28. 28. GAIT Principle #1<br />The only IT infrastructure elements (e.g., databases, operating systems, networks) relevant to ITGC assessment are those that support financially-significant applications and data.<br />(“What are the relevant IT infrastructure elements?”)<br />
    29. 29. GAIT Principle #2<br />The IT processes primarily relevant to ITGC assessment are those that directly impact the integrity of financially-significant applications and data:<br />Change management and systems development: the processes around developing, implementing, and maintaining financially significant applications and supporting IT infrastructure <br />Operations management: the processes around managing the integrity of production data and program execution <br />Security management: the processes around limiting access to information assets <br />(“What are the relevant end-to-end IT processes?”)<br />
    30. 30. GAIT Principle #3<br />Implications to the reliability of financially-significant applications and data, including controls, are based upon the achievement or failure of IT process objectives, not the design and operating effectiveness of the individual controls within those processes. <br />(“What are the relevant objectives of those IT processes? In other words, we shouldn’t get carried away when reaching a conclusion when testing a control.”)<br />
    31. 31. GAIT Principle #4<br />The basis for identifying key controls in the three IT processes is based on:<br />Inherent risk of not achieving the IT process objectives<br />IT process risk indicators<br />(“How do we select key controls within those IT processes?”)<br />
    32. 32. GAIT Scoping: Step By Step<br />AS2 begins here<br />GAIT Starts Here<br />
    33. 33. GAIT Tools<br />Scenarios<br />Online auction settlement process (high IT)<br />Rebate approval process (med IT)<br />Option expensing process (low IT)<br />Ask Dr. GAIT<br />
    34. 34. GAIT Evolution<br />GAIT-R for Business Risk<br />
    35. 35. Conclusions and Lessons Learned, Continued<br />Improved audit comment wording helps to connect to things management cares about:<br />“We noted poor change control procedures and were unable to obtain comfort that all changes were authorized and tested as required” <br />-- vs. -- <br />“Poor change control practices introduced the risk of unauthorized or untested changes to key data such as annual threshold amounts for toxic chemical releases. Given the level of precision applied to reviewing the final report downstream, it is unlikely management would detect such errors. Our testing disclosed numerous “break/fix” changes had been made to code or data without supervisory review and approval or notifying the users.” <br />
    36. 36. GAIT Evolution<br />Elements of GAIT was incorporated into PCAOB AS-5<br />GAIT-R for Business Risk<br />To me, it's the first really well thought out way of linking IT to any COSO internal control objective<br />Unlike ITIL, COBIT: it helps focus on what matters<br />Which is very much unlike PCI…<br />The Integrated Auditing Project (“Magic Glasses”)<br />
    37. 37. Wait, You’re Lowering The PCI Bar!<br />Until you get scoping right, you can't raise the bar<br />Unless you correctly identify the scope of PCI assessment correctly, any work on the controls is potentially wasted<br />
    38. 38. My PCI Mission And Crusade<br />Create guidance to be able to scope correctly<br />Enable a risk based way to not only scope, but to evaluate controls<br />Prioritized PCI DSS is a disappointment<br />What controls for the PCI Scope of Assessment?<br />First, to earn the right to do all of this, we must enable correct scoping first<br />
    39. 39. Participants<br />Leads<br />Kent Fox (Intermountain Healthcare)<br />Brandon Green (T-Mobile)<br />Gretchen Forsyth (Southwest Airlines)<br />Mike Dahn (Verizon)<br />Tabitha Greiner (Verizon)<br />Ian White (Verizon)<br />James Summers (Nike)<br />
    40. 40. Extend Concepts In PCI DSS<br />Page 4: DSS 1.2: “System components” are defined as any network component, server, or application that is included in or connected to the cardholder data environment. <br />
    41. 41. Before vs. After<br />Before: Prior to creating a structured method, we needed over 40 hours to come to a scoping conclusion.<br />After: With the model under development, we generated consensus on 15 scoping conclusions in less than 2 hours.<br />
    42. 42. Proposed Deliverables<br />Define and deliver the following, in a manner that clarifies and supports the spirit and intent of protecting cardholder data:<br />Scoping principles<br />A structured scoping methodology<br />A library of scoping scenarios demonstrating its usage for educational and clarification purposes<br />Create useful tools and guidance that will assist in the scoping effort for both merchants and QSAs.<br />
    43. 43. Decision Tree<br />
    44. 44. Proposed Timeline<br />Submit a set of guidance to the PCI SSC for approval before the PCI Community meeting in September 2010<br />Desired outcome:<br />PCI SSC and Board of Advisors agree with problem and its significant, have confidence in the approach<br />Assign a staff member to validate guidance and integrate it into the PCI practice<br />
    45. 45. Also TODO<br />Identify attributes of effective segmentation to contain PCI contagion<br />Encrypted PIN device<br />Citrix Thin Client<br />Virtualization<br />Where necessary, fix the words, "segment", "connected to,"<br />
    46. 46. Next Up: Scoping Category vs. Control Consideration<br />?????<br />ControlConsiderations<br />
    47. 47. Next: Alternate Control Procedures<br />Create a framework to evaluate alternate control procedures -- for that you need risk<br />Right now, PCI is 220+ control activities: create the framework to state what the control objectives are, so you can evaluate whether the objective is being met<br />COSO construct<br />Objective, risk, control objective<br />THEN control activities and controls!<br />
    48. 48. Top A-Ha Moments<br />Auditors rock: they have a comprehensive vocabulary that we need – otherwise, we’re stuck in Flatland<br />We need more people who can see the sphere<br />Auditors have seen the dead people longer than anyone<br />These auditors will eventually go crazy, and need friends<br />After a long detour into IT operations and audit, I’m returning to information security, in the guise of compliance<br />
    49. 49. We Can Change The State Of The Practice<br />It’s an important problem<br />There are models we can replicate<br />Do you want to get involved?<br />
    50. 50. My New Twins<br />
    51. 51. My Last Day At Tripwire<br />
    52. 52. What I’m Working On<br />50% with my family<br />50% on<br />When IT Fails: The Novel<br />Figure out the methods, procedures and tools needed to enable the transformation<br />Collaborate with communities of practice to help mobilize these transformations<br />BSides, DevOps, ITIL, IIA, SEI<br />
    53. 53. When IT Fails: The Novel: Day 1<br />Steve Masters, CEO<br />Dick Landry, CFO<br />Parts Unlimited$4B revenue/year<br />
    54. 54. When IT Fails: The Novel: Day 2<br />Bill Palmer, VP IT Operations (new)<br />Wes Davis, Director, Distributed Systems<br />Patty McKee, Director, Support and Process Improvement<br />
    55. 55. When IT Fails: The Novel: Day 3<br />Norman Merz, Chief Audit Executive<br />John Kirkland, CISO<br />
    56. 56. When IT Fails: The Novel: Day 4<br />Chris Anderson, VP Application Development<br />Sarah Moulton, SVP Retail Products<br />The outsourcing sales rep<br />
    57. 57. When IT Fails: The Novel: Day 10<br />The Deployment<br />
    58. 58. When IT Fails: The Novel: The Two Critical Projects<br />Project Phoenix: designed to close the gap with the retail competition: $20M project<br />Project Argo: designed to integrate POS systems with accounting systems to reduce time to close books, manufacturing order-to-cash, restock intervals<br />