Getting software security Right

Transcription

1 Getting software security Right Haiyun Xu, Theodoor Scholte April

2 Table of contents 2 I Who is SIG? 2. SIG software maintainability model 3. Getting software security Right: security by design 4. SIG ongoing security research 5. Potential research topics for student projects

3 Software Improvement Group 3 I 23 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.

4 Introduction myself 4 I 23 Dr. Haiyun Xu Chief Security Officer / Researcher Main security activities Research on Software Security Model Information Security Management Security analysis of Software Defined Networking Supervising master students on security research projects

6 Introducing SIG maintainability model The ISO standard for software quality 6 I 23 Usability Compatibility Reliability Performance Efficiency Software Quality ISO Security Functional Suitability Maintainability Portability

7 Introduction to SIG maintainability model The SIG/TÜViT quality model for software maintainability 7 I 23 System properties Component independence Component balance Unit interfacing Unit complexity Module coupling Duplication Volume Unit size Analysability x x x x Modifiability x x x Testability x x x Modularity x x x Reusability x x

8 Introduction to SIG maintainability model From measurements to risk categories to ratings 8 I 23 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 Example RISK CATEGORY PART OF SYSTEM Low risk 65% Moderate risk 15% HHHII High risk 15% Very high risk 5%

10 Four different types of security verification They work best when applied together 10 I 23 All security risks Penetration tests Automated static code analysis Design/code reviews Build quality analysis

11 Security by Design Embedding software security in client organisation 11 I 23 Risk management and acceptance Environmental factors Legal requirements, policies, constraints Accountability Internal (risk dashboard), external (certification, compliance) Risk analysis Inventory of threats, measures and risks Threats, reqs, risks Design review Code review Security Test Pentest Req ments Design Build Test Accept Deploy Training & Guidelines QA Advice & Tuning Risk management steps Development phases SIG offer

12 Security by Design SIG services 12 I 23 Step 1. How can I get How Risk can management I make secure and acceptance How secure is my software? secure software? software? Security Risk Assessment Environmental factors Accountability Security compliance check (with Security governance Security requirements review maturity Legal scan requirements, (based on Grip policies, constraints Secure design review Internal (risk dashboard), whatever external standard) (certification, compliance) on SSD) Secure coding training & Security inspection Security requirements guidelines Security sample assessment (one usecase) Risk analysis review Inventory Secure development of threats, measures process and risks review Threats, reqs, risks Design review Code review Security Test Pentest Req ments Design Build Test Accept Deploy Training & Guidelines QA Advice & Tuning Risk management steps Development phases SIG offer

13 SIG security inspection methodology How SIG broke down security 13 I 23 System-level security Confidentiality & Integrity Non-repudiation & Accountability Authenticity Access Management Strength Session Management Strength Security User Management Authentication Method Strength Authentication Implement Strength Authentication Enforcement

14 SIG security inspection methodology The SIG ISO25010 Quality Model for security 14 I 23 System properties Access management strength Input and output verification Session management strength Final result: HHIII Secure user management Identification strength Secure data transport Authorized access Evidence strength Secure data storage Confidentiality & Integrity Non-repudiation & Accountability HHIII HIIII HHIII HHHHI HIIII HHIII HHHHI HHIII HHIII X X X X HHIII X X HHIII Authenticity X X X HIIII ISO Security sub-characteristics The model is applied using a mix of tooling and expert review, from four perspectives

15 SIG security inspection methodology Example findings from a software security inspection 15 I 23 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 Impact (3+) 5 manmonths high med low low med Probability high Diameter of circle represents indication of effort

17 Ongoing Security Research Metric-based Security Model 17 I 23

18 Ongoing Security Research Automated Security Web Scanners 18 I 23 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?

19 Ongoing Security Research Security Analysis of Software Defined Networking (SDN) Figure 9: Attack tree overview 19 I 23 The sub-attack trees represented in Figure 9 are addressed in the following sections Attack trees 1 and 2: Denial of Service Attacks Apply STRIDE and Attack tree for threat modeling Design test cases and perform using SDN tools... SDN SECURITY TESTING FRAMEWORK 62 7) Stop arpspoof; 8) Verify that the ping starts working again, as the real controller is connected again. Security assessment approach Threat Modeling DoS attacks are usually performed by generating a very large number of packets that likely generate 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 33: ARP spoof controller form a malicious system Assessment 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 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 (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 modify sent and received messages, and for that we use the ettercap filter script shown in Figure 34. SDN Security Research Testing Figure 10: Denial of service attack on the forwarding devices (e.g., switch). Mitigation CONFIDENTIAL Mitigation solutions and best practices Security application 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:

21 Potential Topic For Student Projects Cyber Security: Software Security Code Review 21 I 23 By accident or by design? Security Code Review oftware security How to perform security code review Software Improvement Group e Improvement effectively Group (SIG)/ specializes efficiently? in measuring software aintainability, reliability, performance) and provides actionable to improve design, source code and the development process. Are the security standards / guidelines be helpful (e.g., OWASP ASVS)? security? urity Model Will it be helpful if we group code Secure data transport Identification strength Access management strength Finding security risks Session maangement strength Penetration tests Authorized access Input and output verification Secure data storage All security risks Evidence strength Secure user management Make sure your client signs an indemnity waiver ( vrijwaringsverklaring ). This document waives any damages the test may cause; the test cannot start with- Haiyun Xu, Theodoor Scholte, April , Radboud Rating University Nijmegen HHHHI HHHHI HHIII HHHHI HHHHI HHIII HHHHI HHHII HHIII out this. Confidentiality SIG does & not need to be a party in this agreement, but you will need to Overall rating 29 I 5 Automated security code analysis Are the static analysis tools helpful (e.g., IR-funded research SIG further develops its method for finding es using a mix of design/code review, Including build quality a penetration analysis, code test etration tests, in order Are to the assess penetration the level of testing security tools in 1-5 helpful? stars. ves 20 pilots with various organizations. We do not perform penetration tests ourselves, but hire external experts instead. Pene- dwide security incidents are tration caused testers by mistakes one in software. or multiple SIG s URLs of a working system as a starting point for their a thorough, structured, Fortify)? consistent and repeatable way to have Security design/ Build quality test, and attempt various known attacks code within reviewsa time box (usually 1-2 weeks). analysis & The reviews Security to prevent the Practice code making can reviewer software assist strategy? you mistakes. in finding a penetration tester, but account manager and t in software security, from the very start of development. It sis of build quality How in to order design Requirements consultant on need code to review address expertise the following: on 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 (typically in level? number of pages). Either way, the systems and URLs to test need to be reviewers by skill clearly demarcated. Confidentiality: Balance is only visible to the owner 19

22 Potential Topic For Student Projects Patching and Security 22 I 23 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

23 Potential Topic For Student Projects More open projects online 23 I 23 Open projects:

24 Haiyun Xu h.xu@sig.eu GETTING SOFTWARE RIGHT