The agile approach to PCI DSS
implementation in SDLC area
Jakub Syta, CISA, CISSP, CRISC
Warszawa 15 grudnia 2011 © 2011 IMMUSEC Sp. z o.o. 1

Adapted from Mike Cohn presentation:„Introduction to scrum”
mike@mountaingoatsoftware.com
Project 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

Adapted from Mike Cohn presentation:„Introduction to scrum”
mike@mountaingoatsoftware.com
The Agile Manifesto –
a statement of values
Individuals and
over Process and tools
interactions
Comprehensive
Working software over
documentation
Customer
over Contract negotiation
collaboration
Responding to
over Following a plan
change
Source: www.agilemanifesto.org
© 2011 IMMUSEC Sp. z o.o. 3

10 Key Principles of Agile Development
1. Active User Involvement Is Imperative
2. Agile Development Teams Must Be Empowered
3. Time Waits For No Man!
4. Agile Requirements Are Barely Sufficient
5. How Do You Eat An Elephant?
6. Fast But Not So Furious
7. 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

Adapted from Mike Cohn presentation:„Introduction to scrum”
mike@mountaingoatsoftware.com
Putting scrum all together
Image available at www.mountaingoatsoftware.com/scrum
© 2011 IMMUSEC Sp. z o.o. 5

Adapted from Mike Cohn presentation:„Introduction to scrum”
mike@mountaingoatsoftware.com
Scrum framework
Roles
•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

XP values
Simplicity
Communication
Feedback
Respect
Courage
http://www.extremeprogramming.org/values.html
© 2011 IMMUSEC Sp. z o.o. 7

XP pracitices
© 2011 IMMUSEC Sp. z o.o. 8

PCI DSS requirements
Build 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 parameters
Protect Cardholder Data
• Requirement 3: Protect stored cardholder data
• Requirement 4: Encrypt transmission of cardholder data across
open, public networks
Maintain 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

PCI DSS requirements
Implement 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 data
Regularly 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

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

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

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

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

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

IMPLEMENTATION
© 2011 IMMUSEC Sp. z o.o. 16

Segregation of IT environmnets
Development Test Production
Solely for development and Purposed for formal Purposed for maintaining
initial testing purposes application testing purposes production systems and
application
No CHD No CHD
CHD present but strictly
controlled
© 2011 IMMUSEC Sp. z o.o. 17

Documentation
1. D1 User story
2. D2 Release backlog
3. D3 Project sheet
4. D4 Sprint backlog
© 2011 IMMUSEC Sp. z o.o. 18

SDLC major roles
1. Product Owner 8. Programmer
2. Client 9. Tester
3. Scrum Master 10. Migration specialist
4. Project Manager 11. System admin
5. Head of Development 12. Database admin
6. Architect 13. Network admin
7. Analyst 14. Security officer
© 2011 IMMUSEC Sp. z o.o. 19

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, tests
Developent
(plus daily scrum, retrospective meetings)
• Preparation for the implementation phase, definition of done
Implementa-
tion
© 2011 IMMUSEC Sp. z o.o. 20

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

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

Conclusions
Benefits
• 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

IMMUSEC Sp. z o.o.
Knowledge Village
ul. Wiertnicza 141
02-952 Warszawa-Wilanów
Tel. +48 22 3797470
Fax. +48 22 3797479
email: biuro@immusec.com 24
© 2011 IMMUSEC Sp. z o.o.