Secure Software Engineering

1. Secure Software Engineering Fangzhou Lin Charles McClendon

2. Introduction Building software is hard Security is hard Secure software engineering is a very difficult problem

3. Introduction • Why is building secure software hard? • Software systems have become increasingly complex • Several phases of development are required • Breakdowns in any phase of engineering lead to an insecure product • Attacker has the advantage; Only one vulnerability must be found to compromise the system while the engineer must stop all leaks

4. Introduction • Additional problems for securing software • There are fundamental problems in Computer Science such as the “Halting Problem” • There may be competing economic factors such as whether or not it is cost effective solve a particular security problem • Few software systems are islands; typically systems are installed on top of existing software infrastructures, libraries, and operating systems that have their own security vulnerabilities

5. Introduction What can we do? Treat security as a “first class citizen” in your development process Ignore security at your peril Throughout each phase of development think critically and have the goal of lessening your “attack surface” We will examine problems and solutions in secure software engineering from perspective of a traditional “Waterfall” model of development

6. Requirements Phase The requirements phase is perhaps the most crucial aspect of the secure software engineering process The property of “traceability” requires that any behavior described in the requirements phase be present in the final product and vice versa This means we must not insert security behaviors ad hoc; we must beginwith security in mind

7. Requirements Phase The first order of business should be to establish a security team, or “task force” This team could either be formed from a group of in-house employees or a third party consultancy could be contracted The members of this team should be well versed in security topics and undergo regular training They will be involved in all aspects of development

8. Requirements Phase The security team will also determine what level of security is required by the system owners Perhaps the system will be used in situations where there are regulatory bodies and standards such as Sarbanes-Oxley and the Health Insurance Portability and Accountability Act (HIPPA)

9. Requirements Phase Avoid the Maginot Line approach A typical anti-pattern is simply to secure the perimeter with firewalls and network devices without spending much effort securing the system itself This technique is fundamentally flawed as attacks have become increasingly more complex and the security demands of applications have become more sophisticated

10. Design Phase The design phase is the next most critical phase of development Remember, no behavior must be added that is not accounted for in the specifications document There are several tools and techniques that we may use in developing secure software designs For instance SecureUML is an extension of UML that allows us to explicitly specify security considerations into our diagrams

11. Design Phase • Strategies and considerations • Defense in Depth – we should layer our security measures so that if one piece fails, the risk can be avoid by a lower level of security. Thus we can avoid the Maginot Line by having perimeter security AND other defenses • Compartmentalization – similar to “defense in depth,” we should isolate modules such that if one is compromised, it does not lead to rest of the system being vulnerable • Least Privilege – perhaps the most straightforward, a user should not have more authority than is necessary

12. Design Phase - Threat Modeling If you don't understand the threats, how can you build a secure system? Analyse possible attacks and how to mitigate them assess the probability, the potential harm, the priority etc. of attacks Determine the highest security risks try to minimize or eradicate the threats Decompose application Determine threats Rank threats by decreasing risk Choose how to mitigate the threats

13. Implementation Phase • Most important: Threat model – guidance for coding and testing • Best coding practice • Follow rules that prevent security-related coding errors • Use safer string handling and buffer manipulation constructs to avoid buffer overrun • Robustness: check all inputs. • Don’t suppose something will not happen.

14. Implementation Phase • Static-analysis code-scanning tools • Detect common coding flaws • Buffer overruns, integer overruns, uninitialized variables • Advantages • Find bugs early; Save manual audit; Unexperienced coder • PREfix, PREfast • Rice’s theorem – any nontrivial question about a program can be reduced to the halting program • Static analysis problems are undecidable • Aim for good, not perfect • Output examined by human

15. Implementation Phase • Common Security-related Code Flaws • Buffer overflow • password in memory • Password is unencrypted in memory • URL manipulation • SQL injection • session hijacking • Obtain session IDs to gain unauthorized control

16. Implementation Phase • Buffer overflow • Attempt to store data beyond the boundaries of a fixed-length buffer  extra data overwrites adjacent memory locations. • Designed inputs can execute malicious codes. • Overwrite a local variable • Overwrite a function pointer • Overwrite the return address in a stack frame

17. Buffer overflow – an example void foo (char *bar) { char c[12]; memcpy(c, bar, strlen(bar)); } int main (int argc, char **argv) { foo(argv[1]); } Before bar is copied to c

18. "AAAAAAAAAAAAAAAAAAAA\x08\x35\xC0\x80" "hello" When foo() returns, it jumps to the return address (corrupted by the attacker)

19. Stack buffer overflows • The Morris worm spread in part by exploiting a stack buffer overflow in the Unix finger server. • The Slammer worm spread by exploiting a stack buffer overflow in Microsoft's SQL server. • The Blaster worm spread by exploiting a stack buffer overflow in Microsoft DCOM service • The Twilight hack was made for the Wii in The Legend of Zelda: Twilight Princess • give a very long character name for the player’s horse,causing Wii to crash, and run any unofficial program named “boot.elf” on the SD card • Nintendo released Wii Menu update 3.3 to prevent this,but within 8 hours, two bugs was found in the update,need only minor modification for the hack to operate.

20. Prevent Buffer Overflows Always validate all the inputs Even if you will never overflow the buffer that is used internally, other people who maintain the code may not be so careful. While C, C++ provide no built-in boundary checking... Use standard C++ libraries (STL), avoid gets, scanf, strcpy Use Java, .Net, … Use safe string-handling libraries like Strsafe.h Tradeoff: Safety vs. Performance

21. SQL injection User input is not filtered for escape characters and is then passed into a SQL statement http://xkcd.com/327/ The school lost a year's student records in the database because of a student named"Robert'); DROP TABLE Students;--" statement = "SELECT * FROM Students WHERE name = ('" + studentName + "');" SELECT * FROM Students WHERE name = ('Robert'); DROP TABLE Students; --';

22. Implementation Phase • Why good people write bad code? • Underlying complexity of the task itself • Psychological reasons that make it hard for human to “think” like the computers do • Budget and time constraints

23. Static-analysis tool – PREfast Buffer Overrun Warnings: Precedence Warnings: HRESULT Warnings, Typo Warnings, …

24. Implementation Phase • Code reviews • Supplement to automated tools • Crucial step • Facts: • Critical flaws may not be revealed • It makes the programmers more careful • Opportunity to learn

25. Testing phase • Key Difference • Specification-based testing: focus on testing the presence of correct behaviour • Security-testing: focus on testing the absence of additional behaviour • Testing based on published attack patterns • Works for novice attackers • But not for determined ones.

26. Testing phase • Test cases are planned before coding starts, derived from the design • Test against threat model • Each threat  at least one test case • Act like the attacker • Know the security vulnerabilities and attack patterns • Security-testing tools: Fuzzing tools (data mutation) • Supplies structured but invalid inputs to APIs and network interfaces • Make sure that code correctly handles all data entering the interfaces

27. Release Phase • Final Security Review • Independent review by the central security team • Penetration testing • evaluating the security by simulating an attack by a malicious user • Black box testing – the role of outside hacker • White box testing – the role of insiders • Independent external security review • Provide an overall picture, not feasible to find all security vulnerabilities

28. Support and Servicing Phase • Respond to new attacks • Learn from errors, understand the root causes of the reported vulnerabilities • Accountability: the person who wrote the flawed code should fix it • Eliminate further vulnerabilities

29. Results of SDL at Microsoft Security Bulletin the number of security bulletins issued

30. Effectiveness Complementary • Highest priority – Threat Modeling • Then • code reviews • Use of automated tools • Fuzz testing • Penetration testing before release– least effective to find and fix security bugs

31. Summary and future work Consider security early – not as an add-on feature Threat Modeling is important Rely on best practices Further research on formal methods for software security is needed.