Getting software security Right
Haiyun Xu, Theodoor Scholte
2I 23
Table of contents
1.
Who is SIG?
2.
SIG software maintainability model
3.
Getting software security Right: security by design
4.
SIG ongoing security research
3I 23
Software Improvement Group
SIG Background
•
Spin-off from CWI in 2000, self-owned, independent
•
Management advisory, fact-based
•
Accredited software analysis lab employs analysis tools and models
SIG Service Examples
Software Risk Assessment
Reduce or eliminate technical and operational issues by identifying software
system risks.
Software Risk Monitor
Monitor systems under development and maintenance to improve the
processes involved in delivering high-quality software systems
Security Risk Assessment
Gain control over IT security and prevent security incidents by identifying the
root causes of weak spots in code, design and process.
4I 23
Introduction myself
Dr. Haiyun Xu
Chief Security Officer / Researcher
Main security activities
•
Research on Software Security Model
•
Information Security Management
•
Security analysis of Software Defined Networking
5I 23
Table of contents
1.
Who is SIG?
2.
SIG software maintainability model
3.
Getting software security Right: security by design
4.
SIG ongoing security research
6I 23
The ISO 25010 standard for software quality
Introducing SIG maintainability model
Software
Quality
ISO 25010
Usability Maintainability Portability Reliability Functional Suitability Security Performance Efficiency Compatibility7I 23
The SIG/TÜViT quality model for software maintainability
Introduction to SIG maintainability model
Volume
Duplication Unit sizeUnit complexityUnit interfacingModule coupling
Component balance Component independence Analysability
x
x
x
x
Modifiabilityx
x
x
Testabilityx
x
x
Modularityx
x
x
Reusabilityx
x
System properties
8I 23
From measurements to risk categories to ratings
Star ratings are relative to hundreds of systems in the SIG benchmark
•
Ratings are between 1 and 5 stars, where 3 stars is market average maintainability
Introduction to SIG maintainability model
Example
RISK CATEGORY PART OF SYSTEM Low risk 65% Moderate risk 15% High risk 15% Very high risk 5%HHHII
9I 23
Table of contents
1.
Who is SIG?
2.
SIG software maintainability model
3.
Getting software security Right: security by design
4.
SIG ongoing security research
10I 23
They work best when applied together
Four different types of security verification
Penetration
tests
Automated static
code analysis
All security risks
Design/code
11I 23
Risk management and acceptance
Req’ments
Design
Build
Test
Accept
Deploy
Code
review Security Test Pentest
Environmental factors
Legal requirements, policies, constraints
Risk analysis
Inventory of threats, measures and risks
Accountability
Internal (risk dashboard), external (certification, compliance)
Embedding software security in client organisation
Security by Design
Design review
Training & Guidelines QA Advice & Tuning
Threats, reqs, risks
Risk management steps Development phases
12I 23
Risk management and acceptance
Req’ments
Design
Build
Test
Accept
Deploy
Code
review Security Test Pentest
Environmental factors
Legal requirements, policies, constraints
Risk analysis
Inventory of threats, measures and risks
Accountability
Internal (risk dashboard), external (certification, compliance)
SIG services
Security by Design
Design review
Training & Guidelines QA Advice & Tuning
Threats, reqs, risks
Risk management steps Development phases
How can I
make
secure
software?
• Security requirements review
• Secure design review
• Secure coding training &
guidelines
• Secure development process
review
Step 1. How can I
get
secure software?
• Security governance
maturity scan (based on Grip on SSD)
• Security requirements
review
How secure
is
my software?
• Security Risk Assessment
• Security compliance check (with
whatever standard)
• Security inspection
• Security sample assessment (one
13I 23
How SIG broke down security
SIG security inspection methodology
System-level security
Confidentiality &
Integrity
Non-repudiation &
Accountability
Authenticity
Authentication
Method Strength
Implement Strength
Authentication
Authentication
Enforcement
Access Management
14I 23 Se cu re d ata tr an sp ort Ide nti fic ation str en gth Acce ss m anag em en t s treng th Se ss ion m anag em en t s tre ngth Auth orize d a cces s Inp ut an d o utp ut ve rifi catio n Se cu re d ata sto rage Ev idenc e s treng th Se cu re u se r m an ag em ent
HHIII HIIII HHIII HHHHI HIIII HHIII HHHHI HHIII HHIII
Confidentiality &
Integrity X X X X HHIII
Non-repudiation &
Accountability X X HHIII
Authenticity X X X HIIII
The SIG ISO25010 Quality Model for security
SIG security inspection methodology
ISO 25010 Security
Final result:
HHIII
System properties
15I 23
Example findings from a software security inspection
SIG security inspection methodology
high med low high low med Probability Impact
1
6
4
5
3
2
7
8
Finding
1. Missing certificate check by mobile app is abused with “man in the middle attack”
2. Passwords leak because passwords are stored in database and can be decrypted
3. IAM is hacked since URL and version are exposed
4.Password leak from registration log
5.Developers create data leak because of complexity in website architecture
6. Backdoor in application interface is abused 7. Injection attack abuses browser-only input for validation of data of birth
8. Attack is not identified because logging/monitoring of key processes is not in place
HHHII
3 manmonths
HHHHI
(3+)5 manmonths
16I 23
Table of contents
1.
Who is SIG?
2.
SIG software maintainability model
3.
Getting software security Right: security by design
4.
SIG ongoing security research
17I 23
Metric-based Security Model
18I 23
Automated Security Web Scanners
Ongoing Security Research
Why are the tools not used in
development process?
•
Many vulnerability scanners exist yet
they are rarely being used!
•
What are important features needed
by companies?
•
Do the tools provide these features?
•
What needs to improved to make
tools usable?
PUBLIC © SOFTWARE IMPROVEMENT GROUP
19I 23
Haiyun Xu, Theodoor Scholte, April 24 2015, Radboud University Nijmegen
Security Analysis of Software Defined Networking (SDN)
Ongoing Security Research
Threat Modeling
Mitigation
Testing
Assessment
SDN Security
Research
• Mitigation solutions and
best practices
• Security application • Security assessment approach
SDN SECURITY TESTING FRAMEWORK 62
7) Stop arpspoof;
8) Verify that the ping starts working again, as the real controller is connected again.
Figure 33: ARP spoof controller form a malicious system
Notice that this attack can also be formed on the northbound interface of the controller, i.e., by spoofing either the controller or the SDN applications.
5.3.5 Modifying northbound API
In this section we demonstrate a tampering attack on the northbound API. It corresponds to the attack described in the attack tree in section 3.3.6 (Branch 2 of Figure 15). The attack uses the same infrastructure as the previous attacks, but now we are attacking the Northbound interface of Floodlight. Notice that it will work equally well on the Southbound API. We use ettercap to mod-ify sent and received messages, and for that we use the ettercap filter script shown in Figure 34.
Figure 34: Ettercap filter “of-attack.filter”
To perform the attack, we start the network as before. First we need compile the filter file using the command:
etterfilter of-attack.filter –o of.attack.ef
and after that, we start ettercap by executing the following command:
ettercap –T –M ARP –i eth1 –q –F of-attack.ef /192.168.56.1// ///
Note that in this example the host is connected to the Northbound API on the eth1 interface, and the controller is listening at IP 192.168.56.1. The changed MAC address is also specific for this situation.
The first part of the filter modifies the MAC address of one of the switches to “Changed:Mac:address”. It is easy to see that the MAC address have changed by looking into: http://192.168.56.1:8080/wm/device/
SDN SECURITY BY DESIGN 31
CONFIDENTIAL © SOFTWARE IMPROVEMENT GROUP
3.3.3 Attack Tree: General SDN Attacks
From the analysis performed in the previous sections on the vulnerabilities of data flows and pro-cesses of SDN we concluded that the most common and important attack types (according to STRIDE methodology) to SDN infrastructures are the ones represented in the attack tree of Figure 9.
Figure 9: Attack tree overview
The sub-attack trees represented in Figure 9 are addressed in the following sections.
3.3.4 Attack trees 1 and 2: Denial of Service Attacks
DoS attacks are usually performed by generating a very large number of packets that likely gener-ate new flows. The attack trees of Figure 10 and Figure 11 define how this type of attacks can be performed when considering the switch and the controller, respectively.
Figure 10: Denial of service attack on the forwarding devices (e.g., switch). § Apply STRIDE and Attack tree for
threat modeling
§ Design test cases and perform using SDN tools
20I 23
Table of contents
1.
Who is SIG?
2.
SIG software maintainability model
3.
Getting software security Right: security by design
4.
SIG ongoing security research
PUBLIC © SOFTWARE IMPROVEMENT GROUP
21I 23
Haiyun Xu, Theodoor Scholte, April 24 2015, Radboud University Nijmegen
29 I 5
Finding security risks
Penetration
tests Automated security code analysis
All security risks
Security design/
code reviews Build quality analysis & reviews
Cyber Security:
By accident or by design?
Se cu re d ata tr ansp ort Identi ficati on str ength Acce ss m anag em ent s treng th Se ss ion m aang em ent s treng th Auth orize d acc ess Inp ut an d outp ut verifi catio n Se cu re d ata sto rage Ev idenc e s treng th Se cu re u ser m an agem ent O ve rall ra tingRating HHHHI HHHHI HHIII HHHHI HHHHI HHIII HHHHI HHHII HHIII
Confidentiality &
Integrity X X X X HHHII
Non-repudiation &
Accountability X X HHHII
Authenticity X X X HHIII
The SIG software security model is based on the ISO/IEC 25010 standard ‘System and Software Product Quality Model’.
Measuring software security
Software Security Model
Security Risk Assessment Process
Risk Based Roadmap
H. Xu, J. Heijmans and J. Visser.
A Practical Model For Rating Software Security.
The 7th International Conference on Software Security
and Reliability.
Washington, D.C., USA, June 2013.
Our partner is Radboud University Nijmegen and the project is funded by Netherlands Enterprise Agency.
Publication and Partners
Who: The Software Improvement Group (SIG) specializes in measuring software
quality (security, maintainability, reliability, performance) and provides actionable recommendations to improve design, source code and the development process.
What: Through SBIR-funded research SIG further develops its method for finding
security weaknesses using a mix of design/code review, build quality analysis, code scanning and penetration tests, in order to assess the level of security in 1-5 stars. The research involves 20 pilots with various organizations.
Why: 75% of worldwide security incidents are caused by mistakes in software. SIG’s
approach provides a thorough, structured, consistent and repeatable way to have continuous insight in software security, from the very start of development. It
includes the analysis of build quality in order to prevent making software mistakes.
SIG looks at the design, code, software developmentprocess and optionally at the system in operation (penetration test). Findings on design, code, process and operation are summarized in a star rating and lead to recommendations. A Security Risk Assessment follows a well defined process to establish to what extent a software system is protected against security issues and defines what steps are necessary to get security at the right level. high med low high low med Probability Impact 1 1 6 4 5 3 2 8 Risks
1. Missing certificate check by mobile app abused 2. Passwords in database get decrypted by code in
database and leak
3. IAM is hacked since URL and version are exposed
4. Password leaks from registration log 5. Developers create data leak because of high
complexity in website architecture 6. Backdoor in API is abused
7. Injection attack abusing browser-only input validation for date of birth
8. Attack is missed because logging/monitoring of key process is not in place
HHHII
3 manmonths HHHHI (3+) 5 manmonths
7
Software Improvement Group
19
© Software Improvement Group
4.1.5 Including a penetration test
We do not perform penetration tests ourselves, but hire external experts instead. Pene-tration testers take one or multiple URLs of a working system as a starting point for their test, and attempt various known attacks within a time box (usually 1-2 weeks). The Se-curity Practice can assist you in finding a penetration tester, but account manager and consultant need to address the following:
• Get scope and pricing clear. The testers need to have some idea of the size of the
system to test to base their pricing on. This can be accomplished by arranging access to a testing environment or by having the client indicate the size (typical-ly in number of pages). Either way, the systems and URLs to test need to be clearly demarcated.
• Make sure your client signs an indemnity waiver (‘vrijwaringsverklaring’). This
document waives any damages the test may cause; the test cannot start with-out this. SIG does not need to be a party in this agreement, but you will need to make sure the agreement is signed to prevent any delays during the project.
4.2 The delivery process
The delivery process of a SecRA follows the regular SRA process, with the addition of the optional penetration test. Figure 8 shows how the five steps of SIG’s security analysis map to the SRA process.
Figure 8: Mapping of security analysis steps to the SRA process.
The remainder of this section lists best practices and specific points of attention regard-ing security for each session in the typical SRA process. This section is not meant to give an exhaustive description of the SRA process
4.2.1 Kick-off session
In addition to the regular SRA stakeholders, the people responsible for security need to be identified and present, if possible (e.g. Chief Information Security Officer (CISO), (Op-erational) Security Officer, Security architect).
3. Analyze and rate security measures (e.g. HHHII) Kick-off and strategy session Technical
session Validation session Risk validation session
Final presentation Analysis in SIG Lab + (optional) penetration test
2. Assess Threats 1. Define assets & business impact 4. Assess Risks: Threats - Measures 5. Develop a roadmap to mitigate risks 3. Analyze and rate security measures
Analysis in SIG Lab + (optional) penetration test
Final presentation Kick-off and strategy session Technical session Validation session Risk validation session Risks
1. Missing certificate check by mobile app is abused 2. Passwords in database get descrypted by code in
database and leak
3. Access management is hacked since location and version are exposed
4. Passwords leak from registration log
5. Developers create a data leak because of high complexity in website architecture
6. Backdoor in the application interface is abused 7. Injection attack abuses browser-only input for
validation of date of birth
8. Attack is missed because logging/monitoring of key process is not in place
Confidentiality: Balance is only visible to the owner Integrity:
Only the owner can change the cash
balance (data)
Non-Repudiation: It can be proven that a transaction took place
Accountability: It can be tracked who made a transfer Authenticity:
The user is in fact ‘Hr A. van Dijk’
Software Security Code Review
Security Code Review
•
How to perform security code review
effectively / efficiently?
•
Are the security standards / guidelines be
helpful (e.g., OWASP ASVS)?
•
Are the penetration testing tools helpful?
•
Are the static analysis tools helpful (e.g.,
Fortify)?
•
How to design the code reviewer strategy?
•
Requirements on code review expertise on
security?
•
Will it be helpful if we group code
reviewers by skill level?
22I 23
Patching and Security
User aspect
•
Does patching faster improve security?
•
Maintainability of library, known vulnerabilities
Vendor aspect
•
Do we want a policy that skips patching in favor of rolling software fast enough to
make it a moving target?
•
When patching, is that better to disclose or keep the fix secret?
Design a cost model for patching
23I 23
