If your organization is developing a payment app or even just using one in your product, then this webinar is for you.
The Payment Card Industry (PCI) Security Standards Council recently released a new security framework to replace the previous standard (PCI PA-DSS). The new framework is set to better address the changes that the software development industry has seen in the past few years. Agile and DevOps methodologies, cloud and containerized environments and widespread open source usage have become the new normal and with this, present new AppSec challenges. To ensure that users of payment apps remain safe, the new framework aims to lay a substantial value on continuous application security.
Join Alexei Balaganski (Lead Analyst at KuppingerCole) as he discusses:
the new framework and standards, and the difference between them and the previous version
the practical steps organizations need to take in order to follow the new framework
how organizations can leverage automated vulnerability management tools to ensure application security and compliance with the new standards
Demystifying PCI Software Security Framework: All You Need to Know for Your AppSec Strategy
1. 1
Demystifying PCI Software Security Framework:
All You Need to Know for Your AppSec Strategy
Alexei Balaganski
Lead Analyst
KuppingerCole Analysts
2. 2
Everything is Connected
On-prem Cloud
Big Data
Plant
API
Big DataMainframe
File Server Cloud storage
DB
Connected vehiclesWearables
Machines IoT
SCADA IoT Gateway
Mobile devices
Employees
Application Website SaaS
Partners Contractors Customers
3. 3
Modern Software Development
• Driven entirely by business requirements
• Security must be an integral part of any business process
• Business policies define security practices, not vice versa
• Policies apply uniformly across heterogeneous environments
• Changes are driven by workflows involving multiple business units and IT
teams
• Intelligent automation throughout the whole lifecycle
Business-driven Collaborative Intelligent
DevOps API Economy DataOps Microservices DevSecOps …
5. 5
PCI Software Security Framework
PCI SSF
PART I
Secure Software Standard (SSS)
PART II
Secure Software Lifecycle (SSLC)
• Addresses modern software development practices and technologies
• Implements new, objective-focused approach towards security
• Two separate standards to cover different aspects of common secure
software functions and development processes
• Expands coverage from PCI DSS compliance to all aspects of secure
software development
• Introduced in January 2019, assessments will launch in Q3 2019
• Three years period to transition from PA-DSS
6. 6
Part I: PCI Secure Software Standard
A set of security requirements and associated test procedures to help ensure payment software
adequately protects the integrity and confidentiality of payment transactions and data
Subjects Coverage Objectives
• Vendors of payment software that’s
sold, distributed or licensed
• Vendors of “as a service” payment
solutions
• Companies developing in-house or
custom payment software
(recommended)
• Any software development company
(as a general guidance)
• Processes to identify software
security controls
• All payment software functionality
• Data flows, interfaces and
connections
• Platforms and execution
environments
• Third-party libraries, components,
services incorporated into the
product
• Any other software required for full
implementation of the product
• Guidance for customers to
implement and operate securely
• Minimize the attack surface
• Implement software protection
mechanisms
• Establish secure software operations
• Ensure full software lifecycle
coverage
7. 7
Part II: PCI Secure Software Life Cycle Standard
A set of security requirements and associated test procedures for software vendors to validate
how they properly manage the security of payment software throughout the software lifecycle
Subjects Coverage Objectives
• Vendors of payment software that’s
sold, distributed or licensed
• Vendors who wish to perform their
own software “delta” assessments as
a part of SSS
• Any company (additional guidance
for developing a security strategy)
• Processes and policies governing the
secure software lifecycle
• Development tools and technologies
used throughout SSLC
• Software testing methods and
testing results
• Personnel involved in SSLC
management (own and 3rd party)
• Change management, vulnerability
management, version tracking, etc.
• Guidance for customers
• Communications to stakeholders
• Secure Software engineering
• Secure Software and Data
Management
• Software Security Governance
• Security Communications
8. 8
Part I: Secure Software Core Requirements
01
04
02
03
Attack Surface Minimization
Ensure that all sensitive assets are protected,
and unneeded functions are disabled
Software Protection
Implement controls for protecting integrity and
confidentiality of critical assets
Secure Software Lifecycle
Controls and practices that ensure security of
software throughout the whole lifecycle
Secure Software Operations
Measures that facilitate security of operating the
software in production
9. 9
10 Recommendations
Compliance as an enabler, not burden
There is always more than one way
Assess risks, identify gaps
and capabilities
Do not reinvent the wheel
Think about the future, avoid
quick wins
… repeat
Learn from others
Think beyond your own code
Shift left AND shift right
Involve everyone in the company
01
02
03
04
05
06
10
07
08
09
10. 10
#1: Attack Surface Minimization
Critical Asset Identification
Identify all sensitive assets: payment data,
credentials, encryption keys, system
settings, …
Identify all sensitive resources: functions,
interfaces, APIs, configurations, …
Inventory and classify all critical assets
Secure Defaults
Identify all interfaces and APIs that are exposed by
default and provide justification
Eliminate any hardcoded or default credentials and
keys
Enforce least privilege principle for all system and
admin accounts
Sensitive Data Retention
Ensure that only the data needed for
processing is retained and removed
immediately after use
Ensure data protection in transit and in use
Ensure automated and secure deletion of
data after use
11. 11
#2: Software Protection
Authentication and Access Control
Implement a role-based access model based
on access type and asset classification
Implement strong (MFA), policy- and
context-based authentication
Avoid any shared accounts
Justify each required access Sensitive Data Protection
Secure all sensitive data at rest
Secure all sensitive data in transit
Secure all cryptographic material
Critical Asset Protection
Identify and document possible attack
scenarios against the software
Create the threat model to address all
identified risks
Document all mitigation controls: design
choices, mitigation methods, scope and
period,…
Use of Cryptography
Only use approved encryption and key
management methods
Control all aspects of cryptography in use,
including random value generation
12. 12
#3: Secure Software Operations
Activity Tracking
Implement comprehensive recording of all access
to and usage of sensitive assets
Ensure that tracking captures accurate details of
activities, including scope, time and identity
Ensure that activity records are securely stored
and tamper-proof
Ensure that integrity of tracking data is protected
against failures
Attack Detection
Implement basic detection of anomalous
behavior in software: executable integrity,
configuration changes, brute force login
attempts, etc.
Ensure that these checks are at least
periodic, ideally real-time
Justify the scope and limitations of
implemented checks
Alert and stop sensitive data processing
when attacks are detected!
13. 13
#4: Secure Software Lifecycle Management
Threat and Vulnerability Management
Identify all vulnerabilities and threats in software
and assess their exploitability and risk impacts
Cover full software lifecycle: architecture design,
coding practices, runtime testing, operations
Cover all 3rd party components as well
Ensure that each identified threat is assigned to
skilled personnel, evaluated and mitigated before
release
Maintain full history of evaluation and mitigation
of past vulnerabilities
Secure Software Update
Define a clear policy for delivering security updates
Ensure that updates are delivered in a way that
maintains their integrity and security
Maintain full history of communicating known
vulnerabilities and patches to users
Cover all 3rd party components as well
Vendor Security Guidance
Provide clear and thorough guidance to
users on ensuring secure deployment and
operation of software
Cover all configurable options, 3rd party
integrations and general best practices
14. 14
Part II: Secure Software Lifecycle Core Requirements
01
04
02
03
Software Security Governance
Formal governance program for software
security and sensitive data protection
Secure Software Engineering
Formal proof that the software is designed to be
resilient against attacks and data breaches
Secure Communications
Proof that vendor has established policies for
communicating security issues and guidance to all
stakeholders: customers, partners, etc.
Secure Software and Data Management
Proof that confidentiality and integrity is maintained at
every phase of the software lifecycle
15. 15
#1: Software Security Governance
Security Responsibility and Resources
Assign formal responsibility for overall security to an
individual or a team
Define responsibility and accountability for each
phase of software lifecycle: design, development,
testing, maintenance…
Ensure that assigned personnel possesses required
skills and knowledge
Define processes for maintaining and evaluating
these skills on regular basis
Have clear evidence to demonstrate any of these
Software Security Policy and Strategy
Identify and document all regulatory security and
compliance requirements applicable to your company
Establish a company-wide software security policy with
clear rules and goals
Define a formal security strategy that defines methods
and rules for implementing security in every phase of
software lifecycle
Implement software security assurance processes that
validate how software design meets all strategy and
compliance requirements
Collect evidence to demonstrate how each process
contributes to security outcomes – KPIs, reports,…
Identify and address failures and weaknesses in security
assurance
16. 16
#2: Secure Software Engineering
Threat Identification and Mitigation
Establish formal processes for identifying and classifying
sensitive assets
Establish formal processes to identify, assess and monitor
weaknesses in software design and implementation that
cover all own and external components
Establish formal policies for security requirements and
appropriate controls to mitigate software threats
Establish formal process for collecting and documenting
failures and weaknesses from internal and external sources
Demonstrate that weak or ineffective controls are updated
or replaced when needed
Vulnerability Detection and Mitigation
Establish mature processes for regular security testing
to detect existing and new vulnerabilities in a timely
manner
Demonstrate that discovered vulnerabilities are fixed in
a timely manner and their reintroduction in future
releases is prevented
For vulnerabilities that cannot be fixes, ensure that
stakeholders are provided with appropriate guidance
for risk mitigation
17. 17
#3: Secure Software and Data Management
Software Integrity Protection
Have processes and mechanisms in place to maintain
integrity of all software code, including 3rd party
components
Ensure that software updates are delivered in secure
manner, protecting their integrity
Sensitive Data Protection
Establish processes that record and authorize
collection and retention of any sensitive data
Establish processes to approve, justify and record all
vendor decisions regarding sensitive data use
Establish clear policies to ensure sensitive data
retention, protection and secure deletion
Maintain full, detailed and tamper-proof audit trail
for these activities
Change Management
Establish formal processes for identifying, assessing and
approving all changes to software
Establish clear roles and responsibilities for personnel
to authorize, approve and justify changes
Track all software versions throughout the whole
lifecycle
18. 18
#4: Secure Communications
Software Update Information
Demonstrate that for each update, a detailed
summary of changes is provided to stakeholders
Ensure that potential impacts on existing functionality
is clearly communicated
Stakeholder Communications
Establish clear bi-directional communications channels with
all stakeholders
Demonstrate that security updates are communicated to
all stakeholders in a timely manner
Demonstrate that security notifications include actionable
instruction for risk mitigation
Vendor Security Guidance
Ensure that communications to stakeholders
regarding security guidance and documentation
follow an established process
Demonstrate that full, detailed instruction for
installation, configuration and operation of
software is provided
Demonstrate that security guidance is updated
along with software releases
19. 19
The Big Picture
Execution environments
Interfaces and APIs
3rd
party components
Own code
3rd party tools and services
Partners & Customers
20. 20
Open Source Management
Stakeholder Communications
Keeping all parties informed with tailored reports for
DevOps, security, executives, auditors…
Vulnerability Management
Keeping track of known exploits,
identifying security gaps
Risk Management
Identifying and prioritizing
mitigation options beyond just code
DevOps integrations
Shifting left AND right, covering the
whole software lifecycle
License Compliance
Detect potential legal problems early
Software Hardening
Get recommendations and guidance with
new security components and tools
21. 21
Key Takeaways
Explain further how you plan to turn the interested
potential customer into paying customers
• Get started today
Even before concrete procedures, core recommendations should help
you evaluate your current stand and identify major gaps
• Think about risks, not compliance
Understand your threats, evaluate business risks, then choose
appropriate defenses, not the other way around
• Start with people and processes
Security culture begins with awareness, training, defining
responsibilities, establishing communications, etc.
• Shift in all directions
Embed security processes and controls into every phase of the
software lifecycle – from design to production
• Cover all bases
Software isn’t just code – data, configuration, environment,
communications, even people must be a part of a continuous
security loop
• Software composition management
3rd party components are your responsibility now, especially the open
source libraries: inventory, risk analysis and mitigation controls
25. Company Presentation Slide 3
We’re Here To Serve You
Overview:
• Over 1500 Associates
• 100,000+ Current Customers
• 50 Locations Nationwide
• Over 1 million sq. ft. of
warehouse space
26. Company Presentation Slide 4
Custom Development
• Custom Ecommerce Solution
• Integrated with 3rd Party Payment Gateway
• Following DevSecOps Best Practices
o Continuous Integration
o Continuous Deployment
o Continuous Automated Testing
• Using Open Source Packages as well as Custom Code
• Over 15 Deployed Applications
• Development Team of 25 People