Trupti Shiralkar presented on the importance of evaluating third-party libraries for security issues. She explained that applications are often built using libraries, so vulnerabilities in libraries can affect many applications. Shiralkar proposed a process for security evaluation of libraries that includes reviewing architecture, threat modeling, static code analysis, and security testing. As an example, she discussed evaluating the OpenSSL library and finding any implicit security controls, explicit controls, vulnerabilities, or risks of misuse. The goal is to provide guidance to help secure usage and default secure configurations of libraries.

1. Trupti Shiralkar
LASCON 2017
Security Evaluation of Libraries

2. Disclaimer
This disclaimer informs readers that the views, thoughts, and opinions expressed in the presentation
belong solely to the author, and not necessarily to the author’s employer, organization, committee or other
group or individual.

3. About Me
Application Security Life
Cycle Management Software Security
Practical
Cryptography Sr Security Technical Security Manager
Certified Yoga
Alliance Instructor

4. Agenda
• Why should we evaluate libraries?
• Overview of Application- centric security evaluation process
• Libraries vs Applications
• Security evaluation process for Libraries
• Library Review: OpenSSL
• Conclusion

5. Why should we evaluate Libraries
• Applications are built on top of third-party or homegrown libraries
• Application review focuses on custom code and externally faced interfaces
• Libraries have unknown risks
• Single vulnerability in a library gets replicated in all the products

6. Open SSL Usage Trend
Ref: https://trends.builtwith.com/Server/OpenSSL

7. OpenSSL Vulnerability Trend
http://www.cvedetails.com/product/383/Openssl-Openssl.html?vendor_id=217

8. OpenSSL Vulnerability Trend
Ref: http://www.cvedetails.com/product/383/Openssl-Openssl.html?vendor_id=217

9. OpenSSL Vulnerability Categorization

10. Application Security Review
Process

11. Application-centric Security Evaluation Process

12. Application-centric Security Evaluation Process
Secure DevOps Pipeline

13. Full Stack Security Evaluation

14. What is missing ?
• Known Vulnerabilities
• Dependency Issues
• Licensing Risks
• ?
• ?

15. What is missing ?
• Known Vulnerabilities
• Dependency Issues
• Licensing Risks
• Unknown risks related
to custom code
• Misconfigurations

16. Libraries vs Applications
• Why can’t we have same review process?
Attack
Surface
Threat
Agent
Data
Flow

17. How to evaluate Libraries ?
Design
Architecture
review
Threat
Modeling
Static code
scan
Manual
code review
Security
Testing

18. Security Review of Libraries: Input
•API
Documentation
•Source Code
•Design
Documents•Product
Documentation
(wiki pages)
Implicit
Security
Controls
Explicit
security
Controls
Custom
Code
Entry/End
Points

19. Architecture Design Review
• Analyze functionalities to determine:
1. Implicit security controls
2. Explicit security control
3. Custom code containing modification to
the third party Library

20. Threat Modeling
Traditional Threat Modeling vs Threat Modeling for Libraries
How App can be hacked?
How the Library can be misused?
Output: Misused scenarios with potential risks

21. Code Analysis
Automated and Manual Code Review
No Change
Output: Implementation bugs (risks)

22. Security Testing
Dynamic & Manual Security Testing/ Automated Security Test Scripts
No Change
Output: security defects/bugs/risks

23. Security Review of Libraries: Output
•One click ready
to use secure by
default
implementation
•Security defects,
implementation
bugs
•Implicit Security
Controls •Explicit Security
Controls
Secure-by-
Default
Library
Configuration
Guidance on
Secure Usage of
Library
(wiki page)
Implementation
of secure-by –
default
(CF template)
Anvil Risks

24. Library Evaluation: OpenSSL
Input
• Open SSL user guide
• API Documentation
• FIPS 140-2 security Policy
• source code
Output
• Implicit Security Control (Example: Ciphers, key sizes, modes)
• Explicit Security Control (Example: Self test, Authentication)
• Known vulnerabilities
• Unknown vulnerabilities (J)
• Security Guidance
• Secure-by-default implementation of Library

25. Formal Verification of Cryptographic Libraries
Summary of security requirements, FIPS 140-2 Standard

26. Open SSL Block Diagram

27. OpenSSL Vulnerability Trend
Ref: http://www.cvedetails.com/product/383/Openssl-Openssl.html?vendor_id=217

28. “Unfortunately, the computer security and cryptology communities have drifted apart over the last 25
years. Security people don’t always understand the available crypto tools, and crypto people don’t always
understand the real-world problems.”
- Ross Anderson

29. Conclusion
• Assessing security posture of third party and homegrown libraries is crucial
• Libraries must be evaluated to avoid replicating vulnerabilities
• Data classification and flow is irrelevant
• Focus on security controls provided by the library
• Every bug in a security-focused library could turn a security bug
• Provide libraries with secure-by-default configuration to scale

30. Question?
Contact: s.trupts@gmail.com