1 / 19

PCI COMPLIANCE - Lessons Learnt

PCI COMPLIANCE - Lessons Learnt. Greg Swedosh HP NonStop Security & PCI Compliance Consultant Knightcraft Technology. Lessons Learnt from Recent PCI Projects. Two Tier 1 Organisations

althea
Download Presentation

PCI COMPLIANCE - Lessons Learnt

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. PCI COMPLIANCE - Lessons Learnt Greg Swedosh HP NonStop Security & PCI Compliance Consultant Knightcraft Technology

  2. Lessons Learnt from Recent PCI Projects • Two Tier 1 Organisations • Knightcraft recently was involved in the PCI DSS Compliance projects of two large Australian Tier 1 organisations. • Both started with non-compliant methods, system configurations and documentation. • Both had directive from senior management that PCI Compliance was a non-negotiable for the organisation. • Here are some lessons learnt by the organisations during the process.

  3. The Path to PCI Compliance

  4. PCI DSS – A Corporate Priority • PCI Compliance must be a strategic priority • PCI Compliance is not just about ticking a few boxes and getting a pass. It is about mitigating the risk of credit card fraud. • Achieving and maintaining PCI compliance must be a directive from senior management within the organisation. When conflict arises (which it will), somebody needs to have the power to ensure PCI compliance remains a top priority. • The card acquirers (i.e. the banks) are now starting to help focus the minds of corporate executives by imposing multi-million dollar fines, if sufficient progress is not being made.

  5. Appropriate Budget • Allocate sufficient budget • You will need appropriate budget for: • Extra resources. The existing staff probably already have a large workload. You will need more people. • Extra tools • Software to satisfy security/audit requirements • Compliance monitoring tools to track progress • Expertise • Provide required PCI training to internal security staff • Bringing in appropriate expertise will provide direction. Compliance will be achieved in a quicker and more cost effective way. • Liaise closely with your QSA • The cost of fraud is far greater than the cost of compliance

  6. Run as a Program • PCI Compliance is not a “one off” Project • Initial compliance needs to be set up as a defined project with end date, appropriate budget and resources to do the job, • BUT… • there needs to be an ongoing PCI compliance plan • Once compliant, an organisation must remain compliant. There is a PCI DSS assessment every year. • Tools to track compliance from one year to the next make the annual effort easier and more accurate e.g. RSA Archer • Each requirement is documented as to how it complied this year, so same documentation, procedures, config can be easily identified and verified next year

  7. Common Obstacles

  8. Competing Priorities • The Business v PCI DSS • In both organisations PCI was labeled as top priority, but issues arose where the business forced PCI to the back seat • Software Upgrades • Hardware Upgrades • Other planned projects causing delays

  9. Resistance to Change • Old dogs, New tricks • Changes to existing procedures • Different commands and different screens • Reduction in the use of privileged userids • Entrenched use of super.super/root and application userids on a day to day basis • The concept of “least privilege required” • Changes to access rights • The “need” to access and modify critical files • Lack of willingness to embrace change management • Blame the security • If something doesn’t work, blame the new security

  10. Lack of Resources • Too much work to be done by too few • Systems managed by very small teams • Project scheduled with disregard for how much work systems/application teams already do • Lack of continuity as staff dragged off for support or other implementation work • Many managers, not enough workers • Too many meetings, not enough work • With so many people “managing”, too much time can be spent keeping them “up to date”, rather than actually doing the work

  11. Lack of Separation of Duties • The one stop shop • In-house system tools that have been used for years, now questioned as to their acceptability • Designed, coded, implemented and used by same person • Security monitoring by system manager • Those with greatest power and access to the system responsible for monitoring their own access • Security managed by application support team • Those with knowledge and access to modify application also responsible for managing security around the application

  12. Documentation • There’s so much… where do I start? • The most time consuming work effort required is documentation. • Despite knowing it needs to be done and having it up front in the plan, it still gets pushed to the back of the queue. • There is no shortcut. Most requirements have a documentation component and it must be satisfied for the requirement to be “In Place”.

  13. Lack of Security Ownership • Who decides who can access what? • Security managed by system adminstrators • Access provided on request without questioning whether it is really required • The use of “trust” as a mechanism for ensuring that no unauthorized actions are taken • Nobody ultimately responsible for system security

  14. Security Report Analysis • Who will read the reports? • Setting up auditing and session capture is easy, but who will read the reports? • If reports and session logs are sent off box, the technical knowledge may not be there to really determine what has happened on the system. • If use of privileged userids is excessive, reading through user sessions is an onerous task. • This job is boring. Nobody wants to do it. • The answer is to try and minimize the amount of reports to be analysed as much as possible • Minimize use of privileged userids • Automate report analysis as much as possible

  15. Steps to PCI Compliance

  16. Steps to PCI Compliance • A checklist for success • The following will help you achieve and maintain PCI compliance • Set ownership of PCI compliance with very senior management • Approach PCI DSS as an ongoing program, not just a finite project • Use appropriate tools to track compliance going forward • Communicate clearly and often to all staff of the importance of PCI compliance • Educate staff on how changes will affect them in their daily job • Allocate appropriate budget • Ensure you have appropriate resources for the job • Make documentation a high priority - It is the biggest job • Bring in expertise to help you in your task – QSA, Consultants, Staff Training • Identify personnel for critical roles – security ownership, report analysis • Make realistic schedules - factor in other projects and unexpected delays • Expect the path to be bumpy

  17. Steps to PCI Compliance • The Definitive Resource • PCI Compliance for HP NonStop Servers – Technical white paper • Download the latest version from www.knightcraft.com • Technical white paper written by Knightcraft Technology with Witham Laboratories (QSA) • Details what you need to do for EVERY requirement of PCI DSS and what a QSA will look for • Internationally recognised as the leading resource on PCI compliance for the NonStop • Includes section on evaluating security software to meet your PCI compliance needs

  18. Knightcraft Technology • HP NonStop Security and PCI Compliance Specialists Knightcraft Services PCI DSS Consultancy • Achieve compliance in a fast, reliable and cost-effective manner Security Implementation • Best practices HP NonStop Security configuration • Safeguard, OSS and XYGATE specialists Documentation • PCI DSS required documentation. We know what’s required. PCI Compliance Email: greg.swedosh@knightcraft.com See our website: www.knightcraft.com

  19. Thank you

More Related