1112 agile approach to pci dss development

2,824 views

Published on

Combination Agile SDLC methodologies and PCI DSS

Published in: Business, Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,824
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

1112 agile approach to pci dss development

  1. 1. The agile approach to PCI DSS implementation in SDLC area Jakub Syta, CISA, CISSP, CRISCWarszawa 15 grudnia 2011 © 2011 IMMUSEC Sp. z o.o. 1
  2. 2. Adapted from Mike Cohn presentation:„Introduction to scrum” mike@mountaingoatsoftware.comProject noise level Source: Strategic Management and Organizational Dynamics by Ralph Stacey in Agile Software Development with Scrum by Ken Schwaber and Mike Beedle. © 2011 IMMUSEC Sp. z o.o. 2
  3. 3. Adapted from Mike Cohn presentation:„Introduction to scrum” mike@mountaingoatsoftware.com The Agile Manifesto – a statement of valuesIndividuals and over Process and toolsinteractions ComprehensiveWorking software over documentationCustomer over Contract negotiationcollaborationResponding to over Following a planchangeSource: www.agilemanifesto.org © 2011 IMMUSEC Sp. z o.o. 3
  4. 4. 10 Key Principles of Agile Development1. Active User Involvement Is Imperative2. Agile Development Teams Must Be Empowered3. Time Waits For No Man!4. Agile Requirements Are Barely Sufficient5. How Do You Eat An Elephant?6. Fast But Not So Furious7. Done Means DONE!8. Enough Is Enough!9. Agile Testing Is Not For Dummies!10. No Place For Snipers! http://www.allaboutagile.com © 2011 IMMUSEC Sp. z o.o. 4
  5. 5. Adapted from Mike Cohn presentation:„Introduction to scrum” mike@mountaingoatsoftware.com Putting scrum all togetherImage available at www.mountaingoatsoftware.com/scrum © 2011 IMMUSEC Sp. z o.o. 5
  6. 6. Adapted from Mike Cohn presentation:„Introduction to scrum” mike@mountaingoatsoftware.com Scrum frameworkRoles•Product owner•ScrumMaster•Team Ceremonies •Sprint planning •Sprint review •Sprint retrospective •Daily scrum meeting Artifacts •Product backlog •Sprint backlog •Burndown charts © 2011 IMMUSEC Sp. z o.o. 6
  7. 7. XP values Simplicity Communication Feedback Respect Couragehttp://www.extremeprogramming.org/values.html © 2011 IMMUSEC Sp. z o.o. 7
  8. 8. XP pracitices© 2011 IMMUSEC Sp. z o.o. 8
  9. 9. PCI DSS requirementsBuild and Maintain a Secure Network• Requirement 1: Install and maintain a firewall configuration to protect cardholder data• Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parametersProtect Cardholder Data• Requirement 3: Protect stored cardholder data• Requirement 4: Encrypt transmission of cardholder data across open, public networksMaintain a Vulnerability Management Program• Requirement 5: Use and regularly update anti-virus software or programs• Requirement 6: Develop and maintain secure systems and applications © 2011 IMMUSEC Sp. z o.o. 9
  10. 10. PCI DSS requirementsImplement Strong Access Control Measures• Requirement 7: Restrict access to cardholder data by business need to know• Requirement 8: Assign a unique ID to each person with computer access• Requirement 9: Restrict physical access to cardholder dataRegularly Monitor and Test Networks• Requirement 10: Track and monitor all access to network resources and cardholder data• Requirement 11: Regularly test security systems and processes.Maintain an Information Security Policy• Requirement 12: Maintain a policy that addresses information security for all personnel. © 2011 IMMUSEC Sp. z o.o. 10
  11. 11. PCI DSS requirements for the development process• 6.3 Develop software applications (internal and external, and including web-based administrative access to applications) in accordance with PCI DSS (for example, secure authentication and logging) and based on industry best practices. Incorporate information security throughout the software development life cycle. These processes must include the following:• 6.3.1 Removal of custom application accounts, user IDs, and passwords before applications become active or are released to customers.• 6.3.2 Review of custom code prior to release to production or customers in order to identify any potential coding vulnerability. © 2011 IMMUSEC Sp. z o.o. 11
  12. 12. Change control process• 6.4 Follow change control processes and procedures for all changes to system components. The processes must include the following:• 6.4.1 Separate development/test and production environments.• 6.4.2 Separation of duties between development/test and production environments.• 6.4.3 Production data (live PANs) are not used for testing or development.• 6.4.4 Removal of test data and accounts before production systems become active. © 2011 IMMUSEC Sp. z o.o. 12
  13. 13. Change control process• 6.4.5 Change control procedures for the implementation of security patches and software modifications. Procedures must include the following:• 6.4.5.1 Documentation of impact.• 6.4.5.2 Documented change approval by authorized parties.• 6.4.5.3 Functionality testing to verify that the change does not adversely impact the security of the system.• 6.4.5.4 Back-out procedures. © 2011 IMMUSEC Sp. z o.o. 13
  14. 14. Basic assumptions• Restrictions of PAN processing• Ensuring safe work environment• Usage of trusted software• Logging and monitoring• Safekeeping of cryptographic material• Formal change management and acceptance testing• Security policy and user awareness• Physical security• Accurate and updated documentation © 2011 IMMUSEC Sp. z o.o. 14
  15. 15. Safe work environment• Hardened accordingly to formally accepted standards, for example – Center for Internet Security (CIS) – International Organization for Standardization (ISO) – SysAdmin Audit Network Security (SANS) Institute – National Institute of Standards Technology (NIST)• Protected networks, separated from insecure environments (including WLAN)• Only one primary function per server, protected integrity of key files• Secured workstations• Separate development/test/production environments• Penetration tests done accordingly to best practices (OWASP Guide, SANS CWE Top 25, CERT Secure Coding)• Quarterly vulnerability scans © 2011 IMMUSEC Sp. z o.o. 15
  16. 16. IMPLEMENTATION © 2011 IMMUSEC Sp. z o.o. 16
  17. 17. Segregation of IT environmnets Development Test ProductionSolely for development and Purposed for formal Purposed for maintaininginitial testing purposes application testing purposes production systems and applicationNo CHD No CHD CHD present but strictly controlled © 2011 IMMUSEC Sp. z o.o. 17
  18. 18. Documentation1. D1 User story2. D2 Release backlog3. D3 Project sheet4. D4 Sprint backlog © 2011 IMMUSEC Sp. z o.o. 18
  19. 19. SDLC major roles1. Product Owner 8. Programmer2. Client 9. Tester3. Scrum Master 10. Migration specialist4. Project Manager 11. System admin5. Head of Development 12. Database admin6. Architect 13. Network admin7. Analyst 14. Security officer © 2011 IMMUSEC Sp. z o.o. 19
  20. 20. SDLC phases • Presentation of clients idea of needed development tasks and initial Initiation analysis • Identfication of workload and identyfication of non-development tasks Planning required to complete the task • Developing accordingly to PCI DSS requirements, documentation, testsDevelopent (plus daily scrum, retrospective meetings) • Preparation for the implementation phase, definition of doneImplementa- tion © 2011 IMMUSEC Sp. z o.o. 20
  21. 21. Definition of Done• Finished code• Commented code• Independent code review• Unit tests completed• Integration tests completed• Version infomation prepared• Documentation prepared/updated• Risks were identified and managed appropriately• … © 2011 IMMUSEC Sp. z o.o. 21
  22. 22. Secure coding guidiance• 6.5.1 Injection flaws, particularly SQL injection. Also consider OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws.• 6.5.2 Buffer overflow• 6.5.3 Insecure cryptographic storage• 6.5.4 Insecure communications• 6.5.5 Improper error handling• 6.5.6 All “High” vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.2).• 6.5.7 Cross-site scripting (XSS)• 6.5.8 Improper Access Control (such as insecure direct object references, failure to restrict URL access, and directory traversal)• 6.5.9 Cross-site request forgery (CSRF)• Note: The vulnerabilities listed at 6.5.1 through 6.5.9 were current with industry best practices when this version of PCI DSS was published. However, as industry best practices for vulnerability management are updated (for example, the OWASP Guide, SANS CWE Top 25, CERT Secure Coding, etc.), the current best practices must be used for these requirements. © 2011 IMMUSEC Sp. z o.o. 22
  23. 23. ConclusionsBenefits• Isn’t that difficult as it may seam• Developers do what is really needed, business sees progress in key areas, relationships are established• Business takes responsibility about priorities• Formal frameworks do exist but does not limit anyone• Consider process as ally not an enemy• Creative approach to paperwork• Business first (with security included) © 2011 IMMUSEC Sp. z o.o. 23
  24. 24. IMMUSEC Sp. z o.o.Knowledge Villageul. Wiertnicza 14102-952 Warszawa-WilanówTel. +48 22 3797470Fax. +48 22 3797479email: biuro@immusec.com 24 © 2011 IMMUSEC Sp. z o.o.

×