1. CSCE 522 Secure Software Development Best Practices

2. CSCE 522 - Farkas2 Reading This lecture: Pfleeger Chapter 3.1 G. McGraw, Software [In]security: Software Security Zombies, 07/2011, http://www.informit.com/articles/article.aspx?p=173 9924 http://www.informit.com/articles/article.aspx?p=173 9924

3. CSCE 522 - Farkas3 Application of Touchpoints Requirement and Use cases Architecture and Design Test Plans Code Tests and Test Results Feedback from the Field 5. Abuse cases 6. Security Requirements 2. Risk Analysis External Review 4. Risk-Based Security Tests 1. Code Review (Tools) 2. Risk Analysis 3. Penetration Testing 7. Security Operations

4. CSCE 522 - Farkas4 Misuse Cases Software development: making software do something – Describe features and functions – Everything goes right Need: security, performance, reliability – Service level agreement – legal binding How to model non-normative behavior in use cases? – Think like a bad guy

5. CSCE 522 - Farkas5 Software Vendor Accountability Proper implementation of security features Looking for known security flaws Passing third party validation Source code analysis

6. CSCE 522 - Farkas6 Checking for Known Vulnerabilities Need tool Possible attacks and attack types How the software behaves if something goes WRONG What motivates an attacker?

7. CSCE 522 - Farkas7 Misuse Cases Extends use case diagrams Represent actions the system should prevent Represent together – Desired functionalities – Undesired actions Security: emergent property  must be built in from the ground up Making explicit trade offs

8. CSCE 522 - Farkas8 Misuse Cases Analyze system design and requirements – Assumptions – Failure of assumptions – Attack patterns Software that is used also going to be attacked What can a bad guy do and how to react to malicious use

9. CSCE 522 - Farkas9 Misuse Case Development Team work – software developers and security experts Identifying and documenting threats Creating anti-requirements: how the system can be abused Creating attack model – Select attack pattern relevant to the system – Include anyone who can gain access to the system

10. CSCE 522 - Farkas10 Application of Touchpoints Requirement and Use cases Architecture and Design Test Plans Code Tests and Test Results Feedback from the Field 5. Abuse cases 6. Security Requirements 2. Risk Analysis External Review 4. Risk-Based Security Tests 1. Code Review (Tools) 2. Risk Analysis 3. Penetration Testing 7. Security Operations

11. CSCE 522 - Farkas11 Software Testing Application fulfills functional requirements Dynamic, functional tests late in the SDLC Contextual information

12. CSCE 522 - Farkas12 Security Testing Look for unexpected but intentional misuse of the system Must test for all potential misuse types using – Architectural risk analysis results – Abuse cases Verify that – All intended security features work (white hat) – Intentional attacks cannot compromise the system (black hat)

13. CSCE 522 - Farkas13 Penetration Testing Testing for negative – what must not exist in the system Difficult – how to prove “non-existence” If penetration testing does not find errors than – Can conclude that under the given circumstances no security faults occurred – Little assurance that application is immune to attacks Feel-good exercise

14. CSCE 522 - Farkas14 Penetration Testing Today Often performed Applied to finished products Outside  in approach Late SDLC activity Limitation: too little, too late

15. CSCE 522 - Farkas15 Late-Lifecycle Testing Limitations: – Design and coding errors are too late to discover – Higher cost than earlier designs-level detection – Options to remedy discovered flaws are constrained by both time and budget Advantages: evaluate the system in its final operating environment

16. CSCE 522 - Farkas16 Success of Penetration Testing Depends on skill, knowledge, and experience of the tester Important! Result interpretation Disadvantages of penetration testing: – Often used as an excuse to declare victory and go home – Everyone looks good after negative testing results

17. CSCE 522 - Farkas17 Quality Assurance External quality: correctness, reliability, usability, integrity Interior (engineering) quality: efficiency, testability, documentation, structure Future (adaptability) quality: flexibility, reusability, maintainability

18. CSCE 522 - Farkas18 Correctness Testing Black box: – Test data are derived from the specified functional requirements without regard to the final program structure – Data-driven, input/output driven, or requirements-based – Functional testing – No implementation details of the code are considered

19. CSCE 522 - Farkas19 Correctness Testing White box: – Software under test are visible to the tester – Testing plans: based on the details of the software implementation – Test cases: derived from the program structure – glass-box testing, logic-driven testing, or design-based testing

20. CSCE 522 - Farkas20 Performance Testing Goal: bottleneck identification, performance comparison and evaluation, etc. Explicit or implicit requirements "Performance bugs" – design problems Test: usage, throughput, stimulus-response time, queue lengths, etc. Resources to be tested: network bandwidth requirements, CPU cycles, disk space, disk access operations, memory usage, etc.

21. CSCE 522 - Farkas21 Reliability Testing Probability of failure-free operation of a system Dependable software: it does not fail in unexpected or catastrophic ways Difficult to test (see later lecture on software reliability)

22. CSCE 522 - Farkas22 Security Testing Test: finding flaws in software can be exploited by attackers Quality, reliability and security are tightly coupled Software behavior testing – Need: risk-based approach using system architecture information and attacker’s model

23. CSCE 522 - Farkas23 Behavior in the Presence of Malicious Attack What happens when the software fails? – Safety critical systems Track risk over time Security relative to – Information and services protected – Skills and resources of adversaries – Cost of protection System vulnerabilities

24. CSCE 522 - Farkas24 Malicious Input Software: takes input Trust input? – Malformed or malicious input may lead to security compromise – What is the input? Data vs. control Attacker toolkit

25. CSCE 522 - Farkas25 Application of Touchpoints Requirement and Use cases Architecture and Design Test Plans Code Tests and Test Results Feedback from the Field 5. Abuse cases 6. Security Requirements 2. Risk Analysis External Review 4. Risk-Based Security Tests 1. Code Review (Tools) 2. Risk Analysis 3. Penetration Testing 7. Security Operations

26. CSCE 522 - Farkas26 Traditional Software Development No information security consideration Highly distributed among business units Lack of understanding of technical security risks

27. CSCE 522 - Farkas27 Don’t stand so close to me Best Practices – Manageable number of simple activities – Should be applied throughout the software development process Problem: – Software developers: lack of security domain knowledge  limited to functional security – Information security professionals: lack of understanding software  limited to reactive security techniques

28. CSCE 522 - Farkas28 Deployment and Operations Configuration and customization of software application’s deployment environment Activities: – Network-component-level – Operating system-level – Application-level

29. CSCE 522 - Farkas29 Deployment and Operations Configuration and customization of software application’s deployment environment Fine tuning security functionality Evaluate entire system’s security properties Apply additional security capabilities if needed

30. CSCE 522 - Farkas30 Who are the attackers? Amateurs: regular users, who exploit the vulnerabilities of the computer system – Motivation: easy access to vulnerable resources Crackers: attempt to access computing facilities for which they do not have the authorization – Motivation: enjoy challenge, curiosity Career criminals: professionals who understand the computer system and its vulnerabilities – Motivation: personal gain (e.g., financial)

31. CSCE 522 - Farkas31 Attacker’s Knowledge Insider – Understand organizational data, architecture, procedures, etc. – May understand software application – Physical access Outsider – May not understand organizational information – May have software specific expertise – Use of tools and other resources

32. CSCE 522 - Farkas32 Vulnerability Monitoring Identify security weaknesses Methods: – Automated tools – Human walk-through – Surveillance – Audit – Background checks

33. CSCE 522 - Farkas33 System Security Vulnerability Software installation – Default values – Configurations and settings Monitoring usage – Changes and new resources – Regular updates Tools – Look for known vulnerabilities

34. CSCE 522 - Farkas34 Red Team Organized group of people attempting to penetrate the security safeguards of the system. Assess the security of the system  future improvement Requested or permitted by the owner to perform the assessment Wide coverage: computer systems, physical resources, programming languages, operational practices, etc.

35. CSCE 522 - Farkas35 Next Class Malicious code