1. FIT3056 Secure and Trusted software systems Lecture 4 & 5 Design principles and practice

2. 2 Outline n Software engineering and security. n Why do we have to look ahead when designing secure and trusted software? n Issues related to secure and trusted software design. n Secure and trusted software design considerations. n Secure software design principles. n Trusted software design principles.

3. 3 Software Engineering n Software engineering is the use of engineering principles to develop quality software in a predictable way. n Important considerations of software design are: èSoftware is a logical system. èSoftware tends to evolve. èSoftware needs testing, verification and maintenance. n Software engineering involved with: èa framework for software design. èmethods for construction software. ètools for automated support for the framework for software development and the methods for software construction. èApproaches and methods for software testing and verification

4. 4 Secure and trusted software n Generally secure and trusted software is that cannot be intentionally forced to perform unintended functions. èSince security incidents can result from defects in software requirements, design, implementation, installation, etc., traditional software engineering methods have to change for secure software. lsecure software design requires many important considerations. ¥Eg; do I need to know security before I change a secure application? ¥E.g; why lean IPSec?, SSL?, etc. èDeveloping secure software needs support from all aspects of software development and security processes, methods and tools. lWhy do I have to know cryptography to be able to design applications for sensitive information? lWhy do I need to know if my client-server application communication can be hijacked?

5. 5 Software security tasks n The tasks for design and implementation of secure and trusted software includes many things: èClearly defined aims: protect application and its data. èUnderstanding security: designers should assume that security flaws exist. è Understanding secure software design principles such as least privilege and fail-safe defaults. èSecure deployment: provide documentation and tools for users and administrators to allow easy to install security updates and to do maintenance. èNo design, implementation and deployment secrets: designers should communicate openly and responsibly with end users and/or administrators to help them take protective action.

6. 6 Secure software design principles n Design principles Least privilege Compartmentalise Other approaches. n Evaluate threat Identify assets. Identify entry points. Logically analyse threats. n Write software security policy

7. 7 Software design with security in mind Before designing secure software, designers need to: 1. understand threats to guard against during the analysis. - if a software designer does not understand access control, it will be a disaster to design software for high privileged users. - if a software designer does not understand access control, it will be a disaster to design software for high privileged users. 2. understand basic security mechanisms to include during design. - you cannot design a secure payment system without understanding SSL and Digital Identity Systems. - you cannot design a secure payment system without understanding SSL and Digital Identity Systems. 3. know how to verify the security of the design. - a secure wireless application needs to be verified by wireless security approaches and tools. It is very bad to verify it using the same approaches and tools for the wired environments. - a secure wireless application needs to be verified by wireless security approaches and tools. It is very bad to verify it using the same approaches and tools for the wired environments.

8. 8 Software design with security in mind (con’t) 4. know the basis for secure implementation. - programming language features - programming language features - system privileges - system privileges - memory handling - memory handling - system calls, - system calls, - etc. - etc. 5. be able to work out basis for testing system security after implementation. - how do you test if the implementation of the integrity of the message works or not? - how do you test if the implementation of the integrity of the message works or not? 6. to be able to write security documentation for update, modification and maintenance. - how can you write a policy for future programmers to follow so that your software will continue to securely do what you design it to do? - how can you write a policy for future programmers to follow so that your software will continue to securely do what you design it to do?

9. 9 Understand thread model before designing any secure software 1. Understand adversary’s view of system. - Secure software designers need to understand how potential attacks can happen. Traditional software designers could think this as the least significant. 2. Characterise security of system. - Describe the possible security issues (holes) that your system does have and the software to be built will be affected by those security holes. 3. Evaluate threats. -Logical security model: based on your system architecture. -Formal approach: for evaluating security and performance; algorithms and security; etc. -Practical approach: create real scenarios to evaluate threats. -Tools and policy: employ available tools to find possible vulnerabilities and write security policy for updates and maintenance.

10. 10 Understand business nature and related operations before designing any secure software 1. Identify valuable system assets. èSystem resources and important data that your program(s) will access. lEg: CPUs, memory, network bandwidth, user access. lE.g: a platform for launching attacks on other systems. lEg: sensitive information that can be used for other purposes. 2. Identify critical entry points that your programs(s) will use. èAny location where data or control transfers between the system being modeled and another system. èEx: network sockets, RPCs, web forms, files, are critical entry points. 3. Determine trust levels that your program will be provided and can provide. èPrivileges to external entities (normally much less). èPrivileges to legitimate users (normally the majority that the program is designed for). èPrivileges your program gains when it is executed.

11. 11 View your software as a component of the system rather than a stand alone software Your software Client Other parts of The System Database Wise designers always view their software as an important component of the system

12. 12 Evaluate threats Identify possible threats èFor each entry point, determine how an attacker may attempt to affect an asset. èBased on your company’s asset, predict what an attackers would try to do and what her/his goals would be. Logically analyse threats. èDecompose threats into individual, testable conditions using techniques like attack graphs or trees.

13. 13 Identify possible threats with questions before design (e.g) n Can an unauthorised network user view confidential information such as system accounts, system files, disk space, etc? n Can someone modify data like payments or purchases in the database, even they are legitimate users? n Can someone deny authorised users access to the application? n Can a user exploit a feature to raise their privileges to, eg., administrator level? n Can a user get further access to the system using your program?

14. 14 Identify possible threats before design (e.g) There are possibilities that your software may compromise your system security. Tampering: eg: Modifying authentication files to add new a privileged user and later to log on the system, modification of system files and programs, ect. Information disclosure eg: Obtaining a list of customer credit card numbers, sensitive information from database, etc. Denial of service eg: Consuming CPU time with multiple processes or causing many unnecessary I/O. Elevation of privilege eg: Subverting a privileged program to run your commands or code.

15. 15 Logically analyse threats n Decompose threats into individual, testable conditions using some structure, eg. attack graphs, trees. n Eg: using an attack tree to analyse possible attacks èRoot of tree is the attack èEach level below root decomposes the attack into finer approaches (hierarchically decompose a threat into nodes of the tree)

16. 16 Logically analyse threats: eg Attack using our C Program or script tempering Insert a new privilege user Make root’s passwd blank Run packet sniffing Program to monitor Your network Start a new program /script Open ports and close them after attack Flush out firewall rules At certain time

17. 17 Secure design principles: code separation n Technique to separate the code in different parts, so that each part runs with least privilege. èif a part is compromised, others should still be OK èExample: separating a user interface from the program running with special privileges (e.g., root) lGood eg: implementation examples in Linux user interface and many applications run with user space. lOld bad eg: Old windows task bar tray icons running with system privileges ¥tray icon launching help with higher privileges can be exploited to execute arbitrary code with higher privileges

18. 18 Secure design principles : code secrecy The design should not allow security secrecy: the security of the project should not depend on the secrecy of its design or implementation. The design should not allow security secrecy: the security of the project should not depend on the secrecy of its design or implementation. If the details of the security leaks (through reverse or social engineering), then it is a catastrophic failure. If the details of the security leaks (through reverse or social engineering), then it is a catastrophic failure. For example: if your design allows secrets to be hard-coded as part of your software for simplicity or because a technical difficulty, then security leaks can happen (e.g., hardcode a key, then leakage of a key only affects one user). For example: if your design allows secrets to be hard-coded as part of your software for simplicity or because a technical difficulty, then security leaks can happen (e.g., hardcode a key, then leakage of a key only affects one user).

19. 19 Other principles: least common consideration n Mechanisms used to access resources should not be shared unless there is no alternative. èE.g: if we have two different services of different priorities provided to two different sets of users, they can influence each other: lEg: one service may allow transmitting forbidden data of another service. lEg: one service may limit availability of another service and can cause denial of service.

20. 20 Case study (1) n An internet based shop, called B-Products, that sells beauty products. The shop needs a software application that allows its customers to view and order products via their computers across networks and allows staff to update their product data. Customers will obtain the client program from B-Products and run it on their computers. B- Products IT people will run the server program on a computer at B-Products computer room. Each shop assistant will run a special client program on her/his computer to update the product data maintained by the server program or possibly to communicate with a customer

21. 21 Evaluate threats on this project n Code injection? n Denial of service? n potential installation risk? n Etc.

22. 22 Apply design principles to this project n Least privilege Compartmentalise Other approaches.

23. 23 Secure code implementation Secure code implementation n Designing secure code is only the first step to have secure software. n Implementing the design is another important step. èWill you use RPC (is more portable software layer built on the top of socket layer for heterogeneous distributed applications) or sockets to implement your network applications? èSome RPC facility really has security holes in itself. Sockets are at lower level therefore programming at this layer is more error-prone than at RPC layer. n There can be several possible implementations from one final design. èThe design of project-1 (case study 1) can be implemented in several ways. lUsing object-oriented approach and programming language such as C++ or Java lUsing modular approach and programming language like C. lThe user interface can be implemented in Java for several platforms or one interface for each platform.

24. 24 Secure code implementation: practice n Implementation has to support the design security. èE.g: If code separation was used in the design, then implementation should not allow code of different privileges to be shared. n Compiler optimisation may affect the security of the software è èSome compiler built with optimiser may remove some code sections of your software if the compiler determines that doing so will not alter the behaviour of the program l lCheck compiler documentation for information about this compiler specific behavior. l lCheck assembly code using a debugger to ensure proper behaviour – who can do this? Maybe GOD can.

25. 25 Secure code implementation: practice n OS security must be considered. èTraditional software implementation is more concerned about its portability rather than OS security. However, a piece of software can function surely on one OS but behave dangerously on another. n Library security consideration. è èCode in the library of a system can be vulnerable and your software invoking functions from such a library will have security problems.

26. 26 Implementation considerations to this project (case study) n Sockets or RPC? n Object oriented programming language or procedural? n Database access facility as part of your software? n Independent web based interface or interface is part of your software?

27. 27 Secure code design, implementation and maintenance Secure code design, implementation and maintenance n Designing secure code is only the first step to have secure software. n Implementing the design is another important step. n Maintenance of secure code is even more important. èSoftware is often modified from time to time. èChanges to the existing software can add vulnerabilities and remove security that has been expensively done at the design and implementation steps.

28. 28 Secure code maintenance n To be able to have secure software over a period of time a complete software security policy has to be in place and strictly followed. n Make sure who will maintain the code understand what have been done to achieve the security. èHow do we do this? èHow can we modify the code and still have the same level of security?

29. 29 Testing and Verification (more details later) n Normal software engineering testing with random and/or dummy data normally will not help find security holes. n software security tests must be based on threat model, most important assets, and entry points. n More software security testing based on: èapplication risks by technologies changes. èapplication risks by other systems.

30. 30 Verification (more later) n Secure software verification is difficult because it is extremely difficult to invent a formal or informal approach to verify if a piece of code meets security requirements. èE.g: a process can damage the system if it has a high privilege however we cannot verify this when it is a program (a sequence of lines of code).