Cyber security risk is a big worry for many people, leading to sleepless nights and baggy eyes. Your security is only as strong as your weakest link and the amount of connectivity and technology involved in an end-to-end payment chain is staggering. Some of this technology you may have under your own control, some of it may come from third parties.
You train your developers, you lay requirements on your third parties and inspect their processes. You monitor your external websites and do penetration testing. However, there is one gaping hole in your approach. For native, non-web applications in your infrastructure, mobile devices, point-of-sale systems and the like, you use third party binaries that you have no control over. It is impossible to get a good measure of the security of these applications, or is it?CodeSonar for Binaries Decompiler
CodeSonar has recently added a decompiler to the binary analysis capability which makes it easier for security researchers to understand the warnings presented by the static analysis tool and rank them based on the Common Vulnerability Scoring System (CVSS). Static analysis helps find many different problems in the native binary that makes up the application. It reports these in textual descriptions, with a score to indicate how dangerous a particular problem could be. The decompiler part to the tool then explains the functionality around the warning site in C code, to make it easier for the assessor to understand the problem at hand.
See the video below for a short demonstration.
CodeSonar for Binaries provides a prioritized list of warnings based on the guidelines in the Payment Card Industry Data Security Standard (PCI DSS). The analysis and risk management of third party software is recommended in the PCI DSS. For example, in Requirement 6: Develop and maintain secure systems and applications:
Security vulnerabilities in systems and applications may allow criminals to access PAN and other cardholder data. Many of these vulnerabilities are eliminated by installing vendor-provided security patches, which perform a quick-repair job for a specific piece of programming code. All critical systems must have the most recently released software patches to prevent exploitation. Organizations should apply patches to less-critical systems as soon as possible, based on a risk-based vulnerability management program. Secure coding practices for developing payments applications, change control procedures and other secure software development practices should always be followed.
In particular, requirement 6 calls out:
6.2 Establish a process to identify newly discovered security vulnerabilities, such as by subscribing to alert services, or using a vulnerability scanning service or software. Update the process to address new vulnerability issues.
6.3 Develop software applications in accordance with PCI DSS based on industry best practices and incorporate information security throughout the software development life cycle.
NIST SP 500-83 / IOS/IEC 27001
Both of these standards describe various different type of controls that can be applied to critical software systems. Static analysis is mentioned in a number of sections in these standards. Using NIST SP 500-83 as the baseline, it is clearly mentioned in control SA-11, which covers 'Developer Security Testing and Evaluation'. Static analysis, including binary analysis, is mentioned in many more places in the standard:
- Control RA-5 talks about 'Vulnerability Scanning"
- Control SA-12 talks about 'Supply Chain Protection' and refers to static analysis under enhancement 7 'Assessments prior to Selection / Acceptance / Update'
CodeSonar for Binaries' unique capability to detect security vulnerabilities in binary code without the need for source code or debug information is well suited for the requirements expressed in these standards. What was once almost impossible to do without extensive black box testing, is now available by analyzing the binary code before it's even in the concept and evaluation stage of a project. The new decompilation capability makes understanding of binary code easier leading to better analysis of found issues. Performing this sort of analysis early in the software lifecycle greatly reduces the risk of late stage security vulnerabilities which are expensive - both in time and reputation - to fix.
DFARS 252.235-7010 Acknowledgement of Sponsorship: This material is based upon work supported by the Office of Naval Research under Contract No. N68335-17-C-0454. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the AFRL.