In most companies security is driven by compliance regulations. The policies are designed to contain the security vulnerabilities each company is interested to comply with. These vulnerabilities can be measured only at the end, after the software has been developed, which is way too late. The result of this approach is a high number of insecure applications are still produced and injection is still King. Is there another way to create a more secure the software from the start? This presentation will look at security vulnerabilities from a different angle. We will decompose the vulnerabilities into the security controls that prevent them and developers are familiar with. We will flip the security from focusing on vulnerabilities (which can be measured only at the end, after the software has been developed) to focus on the security controls, which can be used from beginning in software development cycle. Recommended to all builders and security professionals interested to build a more secure software from the start.

1. Security Vulnerabilities
Decomposition:
Another way to look at Vulnerabilities
Katy Anton

2. @KatyAnton
OWASP Top 10

3. @KatyAnton
Application Security Team
After Report

4. @KatyAnton
Software Development Team
After Report

5. @KatyAnton
• SQL Injection: mentioned in 1998 in Phrack magazine
• XSS: Described in 1999 by Microsoft
Injection
2004 2009 2010 2013 2017
Injection A6 A2 A1 A1 A1

6. @KatyAnton
• Software development background
• Project co-leader for
OWASP Top 10 Proactive Controls
(@OWASPControls)
• OWASP Bristol Chapter Leader
• Principal AppSec Consultant
Katy Anton

7. @KatyAnton
Common Weakness Enumeration
A formal list of software security weaknesses in:
- architecture
- design
- code
Source:cwe.mitre.org

8. @KatyAnton
Source: https://nvd.nist.gov/vuln/categories/cwe-layout
NVD - CWE Categories

9. @KatyAnton
Injection

10. @KatyAnton
CWEs in Injection Category
CWE-93: CRLF Injection
CWE-74
Injection
CWE-943:Improper Neutr. of Special El in Query
CWE-94: Code Injection
CWE-91: XML Injection
CWE-79: XSS
CWE-77: Commmand Injection
CWE-89: SQL Injection
CWE-90: LDAP Injection
Source: NVD
CWE-78: OS Cmd Inj
CWE-88: Argument Inj

11. @KatyAnton

12. @KatyAnton
Another way to look at Vulnerabilities

13. @KatyAnton
Decompose the Injection
Data interpreted as Code
Input Parser Output
Get / Post Data
File Uploads
HTTP Headers
Database Data
Config files
SQL Parser
HTML Parser
XML Parser
Shell
LDAP Parser
SQL
HTML
XML
Bash Script
LDAP Query

14. @KatyAnton
Extract Security Controls
Vulnerability Encode Output Parameterize Validate Input
SQL Injection ☑ ☑
XSS ☑ ☑
XML Injection ☑ ☑
Code Injection ☑ ☑
LDAP Injection ☑ ☑
Cmd Injection ☑ ☑
Primary Controls Defence in depth
InputParserOutput

15. @KatyAnton
Intrusions
(or lack of Intrusion Detection)
“If a pen tester is able to get into a system without being detected,
then there is insufficient logging and monitoring in place“

16. @KatyAnton
The security control developers can use to
log security information during the runtime
operation of an application.
Security Controls: Security Logging

17. @KatyAnton
Good attack identifiers:
1. Authorisation failures
2. Authentication failures
3. Client-side input validation bypass
4. Whitelist input validation failures
5. Obvious code injection attack
6. High rate of function use
Source: https://www.owasp.org/index.php/AppSensor_DetectionPoints
Best Types of Detection Points

18. @KatyAnton
Request Exceptions
• Application receives GET when expecting POST
• Additional form/URL parameters submitted
Authentication Exceptions
• POST request with only the username variable. The
password variable has been removed.
• Additional variables received during an authentication
request (like ‘admin=true’')
Input Exceptions
• Input validation failure on server despite client-side validation
• Input validation failure on server side on non-user editable
parameters (hidden fields, checkboxes, radio buttons, etc)
Source: https://www.owasp.org/index.php/AppSensor_DetectionPoints
Examples of Intrusion Detection Points

19. @KatyAnton
Secure Data Handling: Basic Workflow
Application Server
Operating System
Software Application
Param
Queries
Encode outputValidate Data
Log Exceptions

20. @KatyAnton
Sensitive Date Exposure
Data at Rest and in Transit

21. @KatyAnton
Storage by Data Types
Data Types Encryption Hashing
Data at Rest: Requires initial value
E.q: credit card ☑
Data at Rest: Does not require
initial value
E.q: user passwords
☑
Data in Transit ☑

22. @KatyAnton
How Not to Do it !
Data at Rest: Design Vulnerability Example
encryption_key = PBKF2(pwd, salt, iterations, key_length);
In the same folder - 2 file:
The content of password.txt:

23. @KatyAnton
Encryption
Cryptographic Storage
Strong Encryption Algorithm: AES
Key Management
• Store unencrypted keys away from the encrypted data.
• Protect keys in Key Vault (Hashicorp Vault/Amazon KMS)
• Keep away from home-grown key management solutions.
• Define a key lifecycle.
• Build support for changing algorithms and keys when
needed
• Document procedures for managing keys through the
lifecycle
Source: https://www.owasp.org/index.php/Cryptographic_Storage_Cheat_Sheet
Security Controls: Data at Rest

24. @KatyAnton
Security Controls: Data in Transit
TLS TLS
Application Server
Operating System
Software Application
Application Server —> Non-browser
components
Client —> Application server

25. @KatyAnton
Third Party Components
Using Software Components with Known Vulnerabilities

26. @KatyAnton
The type of software with vulnerable components:
• Difficult to understand
• Easy to break
• Difficult to test
• Difficult to upgrade
• Increase technical debt
Root Cause

27. @KatyAnton
Sum of the total different points
through which a malicious
actor can try to enter data into
or extract data from a system.
What is Attack Surface?

28. @KatyAnton
Minimize the attack surface.
Source: https://www.owasp.org/index.php/Security_by_Design_Principles
Fundamental Security Principle

29. @KatyAnton
Examples of external components:
1. Open source libraries - for example: a logging library
2. APIs - for example: vendor APIs
3. Libraries / packages by another team within same
company
Components Examples

30. @KatyAnton
• Third-party - provides logging levels:
FATAL, ERROR, WARN, INFO, DEBUG.
• We need only:
DEBUG, WARN, INFO.
Ex1:Implement a Logging Library

31. @KatyAnton
Simple Wrapper
Module
Module
Interface
Module
Module
Module
Library
Module
Module
Helps to:
• Expose only the functionality required.
• Hide unwanted behaviour.
• Reduce the attack surface area.
• Update / replace libraries.
• Reduce the technical debt.

32. @KatyAnton
Scenario:
• Vendor APIs - like payment gateways
• Can have more than one payment gateway in
an application
• Required to be inter-changeable
Ex2: Implement a Payment Gateway

33. @KatyAnton
• Converts from provided interface to
the required interface.
• A single Adapter interface can work
with many Adaptees.
• Easy to maintain.
Adapter Design Pattern
Your Code
Third-party code
Adapter

34. @KatyAnton
• Libraries / packages created by another team
within same company
• Re-used by multiple applications
• Common practice in large companies
Ex3: Implement a Single Sign-On

35. @KatyAnton
• Simplifies the interaction with a
complex sub-system
• Make easier to use a poorly
designed API
• It can hide away the details from
the client.
• Reduces dependencies on the
outside code.
Façade Design Pattern

36. @KatyAnton
Secure Software Starts from Design!
Façade Pattern
To simplify the
interaction with a
complex sub-system.
Adapter Pattern
To convert from the
required interface to
provided interface
Your Code
Third-Party Code
Adapter
Wrapper
To expose only the
required functionality and
hide unwanted behaviour.
Third-Party Library
Your code
Module
Module
Module
Module
Module
Module
Module
Interface

37. @KatyAnton
Environment
Misconfiguration

38. @KatyAnton
• During Development:
• Use dedicated users with same privileges as in production
• Follow the “Least privilege” security principle
• During Deployment: Check for privileges
• Infrastructure-as-Code (IaC)
• After Deployment: Adopt configuration management
• Provide continuous configuration scanning across servers
to identify and remediate misconfigurations
Configuration Hardening

39. @KatyAnton
Final Takeaways
CWEs

40. @KatyAnton
Final Takeaways
CWEs
Focus on
Security
Controls
which prevent

41. @KatyAnton
Final Takeaways
Verify Early and
Often CWEs
Focus on
Security
Controls

42. @KatyAnton
Security Controls for Secure Development
Application Server
Operating System
Software Application
Param
Queries
Encode
output
TLS
Validate
Input
TLS
TLS
OS CommandLogs
Log Exception Param Data
Secure Date Key
Management
Solution
Encapsulation
Harden
Parser
XML
Configuration
Hardening

43. Thank you
Katy Anton
@KatyAnton