To ensure critical data can only be accessed by authorized personnel, it is paramount to integrate security best practices during development. It’s equally important to protect deployed systems, especially in CI/CD (continuous integration and deployment) and DevOps environments.
Attend this webcast to learn techniques to define, design, develop, test, and maintain secure systems. Particular focus will be paid to software-dependent systems.
Topics include:
• Identifying and risk-rating common vulnerabilities
• Applying practices such as least privilege, input/output sanitation, and system hardening
• Implementing test techniques for system components, COTS, and custom software
2. 2
• Securing software in all the challenging places….
• ….while helping clients get smarter
Assessment: show me the gaps
Standards: set goals and make it easy
Education: help me make good decisions
Over
3 Million
Users
Authored
18
Books
Named
6x
Gartner MQ
About Security Innovation
3. 3
Agenda
Identifying and preventing critical vulnerabilities
Restricting Access to Cardholder Data – “need to know”
Test and Threat Mitigation techniques
4. 4
Injection
Occurs when an
Interpreter confuses
input as commands
Successful attack can
allow an attacker to:
Steal data from tables
Modify content
Steal content from files
Gain complete access
Chain exploits
Gain access to other networked
servers
There are many types of
injections:
Command Injection
SQL Injection (SQLi)
LDAP
Could happen when using ANY
interpreted language
5. 5
Testing for SQL Injection
Two most common initial tests of a SQL application are
Adding a single quote ('), which terminates a string in SQL
syntax
Adding a semicolon (;), which terminates a SQL statement
Test each field separately and then in combination if possible.
Identify all input fields used to craft SQL queries within the application, including hidden fields
of POST requests
6. 6
Testing for Command Injection
Identify code capable of passing user supplied data
Identify request parameters extracted
Create a fuzz list – payloads to fuzz OS command being used
Use a fuzzer to determine if payloads cause application to behave differently
Confirm possibility of OS command injection
7. 7
How to Test for Command Injection
• Approach is similar to testing for SQL Injection, but tools used (fuzzers), might
differ from those used during development and are the same used by attackers
• Typically, focus is the server-side scripting engine run by the web server, such as
ASP or PHP, and the information entered by the tester is processed either as
dynamic code or as an included file.
• To defend against these attacks, use input validation and secure coding practices.
8. 8
Checking for LDAP Injection
Create Fuzz List Payloads to fuzz LDAP query
Identify
Metacharacters
Identify the search filter metacharacters
Determine
Interaction
Determine if feature interacts with an LDAP database and if
it uses input to form the query
10. 10
Protecting Applications from Injection Vulnerabilities
• Keep untrusted data separate from commands and queries
• Use a safe API and validate your assumptions about the APIs you use
• If parametrized API is not available, carefully escape special characters for
the context
• Use whitelist input validation with appropriate canonicalization
• Most web frameworks provide API functions to easily address injection
attacks, including character escaping and whitelist validation.
Note: You cannot use this technique as a complete defense against an
injection attack, because many applications require special characters in
their input. For example: User’s last name
11. 11
Cross-Site Scripting (XSS) Attack
• Execute malicious script in the
user’s browser
• Can perform actions on behalf
of user within the application
and abuse user’s browser
• Example: can force browser to
request a web page containing
exploit code that will execute
malicious code on user’s system
12. 12
Preventing XSS
• Use a secure framework
• Encode data
• Understand the context in which your data will be used
• Especially important when transmitting data between different components
• For data that will be output to another web page use the appropriate encoding on
all non-alphanumeric characters
• Parts of the same output document may require different encodings, which will vary
depending on where the output resides.
MicrosoftAnti-XSS Library provides excellent encoding functionality for the .NET
platform. Other platforms have their own similar functionality
14. 14
“Need to Know” Access Rights
• Ensure critical data can only be accessed by authorized personnel
• Define the data to mitigate developer assumptions
• Systems and processes must be in place to limit access based on job
responsibilities
• Access rights are granted to only the least amount of data and privileges needed
to perform a job
• System components, processes, and software should be tested frequently to
ensure security controls reflect a changing environment
15. 15
Principle of Least Privilege
• Accomplishes two things:
• Reduces the attack surface
• Limits capabilities after a successful attack
• Common implementation techniques:
• Using a limited-user account context
• Removing write privileges for the web application’s user
• Configuring firewall to only allow HTTP or HTTPS
• Setting file permissions that prevent modification of web content files
16. 16
Least Privileged Best Practices
• Start with nothing
• Segment your application for a role-based approach
• Consider granting temporary privilege and revoke upon completion
• Have stakeholder buy-in
17. 17
Security Misconfiguration
Improperly secured operating
systems, web server applications,
and databases all contribute to the
overall attack surface
Most misconfiguration mistakes
are common and are the preferred
attack vector due to ease of
exploitation
18. 18
Defending the Operating System (OS)
Keep the system up-to-date with the latest OS, web server, database, and other software patches.
(more details to follow)
Install only what is necessary for your purpose
Strictly limit user accounts and disable/rename default accounts.
Establish strong password policies for the OS and all installed applications
Set file and directory permissions to the least necessary to run the required applications.
19. 19
Defending the OS (cont’d)
Review OS settings that can improve system security.
Ensure that proper system auditing and log file management is in place.
Avoid installing software development and debugging tools on a production server.
Install antivirus and other security software as appropriate
Consider using a hardening guide or tool appropriate for your OS
Ensure that the server is physically secure.
20. 20
Security Patching Process Document
• Platform Application Update Procedures and
Anticipated Delays
• Non-Technical Procedures
• Application Security Bug Bar
• Third-Party Code and Services Used by Applications
• Alternative Patch Delivery Methods
• Escalation Paths
• Availability of On-Call Support Resources
22. 22
Techniques to Identify Vulnerabilities and Mitigate
Risk
Vulnerability
Scanners
Penetration
Testing
Threat Modeling Fuzzing
23. 23
Vulnerability Scanning
• Many standards require regular scanning to maintain compliance.
• Scanners are pre-programmed to detect known patterns, syntax and vulnerabilities
• Scanners are great at finding common vulnerabilities and misconfigurations faster
than humans, but are prone to:
• False positives - scanners can only flag potential issues, so findings still need to be
validated which is time consuming
• False negatives – scanners often miss business logic or complex vulnerabilities, leading
to a false sense of security
24. 24
Penetration Testing
Penetration tests differ from vulnerability scans in that attacks are performed and vulnerabilities are
actually exploited
Regular penetration tests are often legally required to maintain regulatory compliance
Penetration tests are performed by actual security experts who use both custom and off-the-shelf
tools and manual techniques.
Unlike vulnerability scanners, penetration testers can adapt to custom protocols and business logic.
Because penetration testers are human, they cannot scale to the same degree as automated scanners
25. 25
Threat Modeling
• Secure software starts by thinking about threats
• Threats are NOT vulnerabilities; they live forever
• Think about the attacker’s goals
• Threat model guides secure coding, test, and deployment efforts
Threat
Mitigation
Vulnerability
Attacker
Vulnerabilities are
unmitigated threats.
Here’s our opportunity!
26. 26
Fuzzing
• Fuzzing is a testing technique that consists of finding implementation
bugs by using malformed input injected into an application in an
automated fashion.
• The tool that performs this action is called a fuzzer.
• The randomized approach used by fuzzers allows them to find
vulnerabilities that may be missed by human inspection.
27. 27
Types of Fuzzers
Application Fuzzers
Generate random inputs for all
visible and non-visible input
fields
Protocol Fuzzers
Generate random protocol data
inside of network packets. For
example, an HTTP fuzzer
File Format Fuzzers
Generate malformed files and
attempt to open/parse the files.
For example, a PDF file fuzzer
28. 28
Summary
Becoming PCI compliant and maintaining the compliance is a
continual process.
All applications have risk. Our goal is to mitigate the risk to an
acceptable level by using the techniques discussed.
All phases of the software development lifecycle must include
security tasks to achieve the desired risk mitigation.
29. 29
How Can We Help?
Software Security
Consulting
• Security Testing
• SDLC Gap Analysis
Computer Based Training
• All major roles and technologies
• PCI, NIST, OWASP, CWE, ISO, etc
PCI Specific Courses
• Protecting Stored Cardholder Data
• Encrypting Transmission of Cardholder Data
• Develop & Maintain Secure Systems and Apps
• Regularly Test Security Systems and Processes
• Fundamentals of the PCI Secure SLC Standard
Cyber Range
• Authentic, turn-key, fun
• Reports map to courses
• Identify champions
• Meet PCI Compliance
30. 30
Want More on PCI?
Check out the other webinars in our PCI webinar series:
• On-Demand: Protect Sensitive Data (and be PCI Compliant too!)
https://bit.ly/PCI2020-1
• The PCI Secure Software Life Cycle Standard (SLC)
https://bit.ly/PCI2020-3
June 3, 2020 @ 2pm ET