FIT3056 FIT3056 Secure and Trusted software systemsSecure and Trusted software systems

Lecture 4 & 5Lecture 4 & 5

Design principles and practice Design principles and practice

2

OutlineOutline

Software engineering and security.Software engineering and security. Why do we have to look ahead when Why do we have to look ahead when

designing secure and trusted software?designing secure and trusted software? Issues related to secure and trusted Issues related to secure and trusted

software design.software design. Secure and trusted software design Secure and trusted software design

considerations.considerations. Secure software design principles.Secure software design principles. Trusted software design principles.Trusted software design principles.

3

Software EngineeringSoftware Engineering

Software engineering is the use of engineering principles to develop Software engineering is the use of engineering principles to develop

quality software in a predictable way. quality software in a predictable way.

Important considerations of software design are:Important considerations of software design are:

Software is a logical system .Software is a logical system .

Software tends to evolve.Software tends to evolve.

Software needs testing, verification and maintenance.Software needs testing, verification and maintenance. Software engineering involved with:Software engineering involved with:

a framework for software design.a framework for software design.

methods for construction software.methods for construction software.

tools for automated support for the framework for software tools for automated support for the framework for software development and the methods for software construction.development and the methods for software construction.

Approaches and methods for software testing and verificationApproaches and methods for software testing and verification

4

Secure and trusted softwareSecure and trusted software

Generally secure and trusted software is that cannot be intentionally Generally secure and trusted software is that cannot be intentionally forced to perform unintended functions.forced to perform unintended functions. Since security incidents can result from defects in software Since security incidents can result from defects in software

requirements, design, implementation, installation, etc., traditional requirements, design, implementation, installation, etc., traditional software engineering methods have to change for secure software.software engineering methods have to change for secure software.

secure software design requires many important considerations. secure software design requires many important considerations. Eg; do I need to know security before I change a secure application?Eg; do I need to know security before I change a secure application?

E.g; why lean IPSec?, SSL?, etc.E.g; why lean IPSec?, SSL?, etc.

Developing secure software needs support from all aspects of Developing secure software needs support from all aspects of

software development and security processes, methods and tools.software development and security processes, methods and tools.

Why do I have to know cryptography to be able to design applications Why do I have to know cryptography to be able to design applications

for sensitive information?for sensitive information?

Why do I need to know if my client-server application communication Why do I need to know if my client-server application communication

can be hijacked?can be hijacked?

5

Software security tasksSoftware security tasks

The tasks for design and implementation of secure and The tasks for design and implementation of secure and trusted software includes many things:trusted software includes many things: Clearly defined aims: protect application and its data.Clearly defined aims: protect application and its data. Understanding security: designers should assume Understanding security: designers should assume

that security flaws exist.that security flaws exist. Understanding secure software design principles Understanding secure software design principles

such as least privilege and fail-safe defaults.such as least privilege and fail-safe defaults. Secure deployment: provideSecure deployment: provide documentation and documentation and

tools for users and administrators to allow easy to tools for users and administrators to allow easy to install security updates and to do maintenance.install security updates and to do maintenance.

No design, implementation and deployment secrets: No design, implementation and deployment secrets: designers should communicate openly and designers should communicate openly and responsibly with end users and/or administrators to responsibly with end users and/or administrators to help them take protective action.help them take protective action.

6

Secure software design principlesSecure software design principles

Design principlesDesign principles

Least privilegeLeast privilege

CompartmentaliseCompartmentalise

Other approaches.Other approaches. Evaluate threatEvaluate threat

Identify assets.Identify assets.

Identify entry points.Identify entry points.

Logically analyse threats.Logically analyse threats. Write software security policyWrite software security policy

7

Software design with security in mindSoftware design with security in mind

Before designing secure software, designers need to:Before designing secure software, designers need to:1. understand threats to guard against during the analysis.1. understand threats to guard against during the analysis.

- if a software designer does not understand access control, - if a software designer does not understand access control, it will be a disaster to design software for high privileged it will be a disaster to design software for high privileged users.users.

2. understand basic security mechanisms to include during 2. understand basic security mechanisms to include during design.design.

- you cannot design a secure payment system without - you cannot design a secure payment system without understanding SSL and Digital Identity Systems.understanding SSL and Digital Identity Systems.

3. know how to verify the security of the design.3. know how to verify the security of the design. - a secure wireless application needs to be verified by - a secure wireless application needs to be verified by

wireless security approaches and tools. It is very bad to wireless security approaches and tools. It is very bad to verify it using the same approaches and tools for the wired verify it using the same approaches and tools for the wired environments. environments.

8

Software design with security in mind Software design with security in mind (con’t)(con’t)

4.4. know the basis for secure implementation.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.5. be able to work out basis for testing system security after be able to work out basis for testing system security after implementation.implementation.

- how do you test if the implementation of the integrity of the - how do you test if the implementation of the integrity of the message works or not?message works or not?

6.6. to be able to write security documentation for update, to be able to write security documentation for update, modification and maintenance. modification and maintenance.

- how can you write a policy for future programmers to - how can you write a policy for future programmers to follow so that your software will continue to securely do follow so that your software will continue to securely do what you design it to do?what you design it to do?

9

Understand thread model before designing Understand thread model before designing any secure softwareany secure software

1.1. Understand adversary’s view of system.Understand adversary’s view of system.- Secure software designers need to understand how potential attacks - Secure software designers need to understand how potential attacks

can happen. Traditional software designers could think this as the can happen. Traditional software designers could think this as the least significant.least significant.

2.2. Characterise security of system.Characterise security of system.- Describe the possible security issues (holes) that your system does - Describe the possible security issues (holes) that your system does

have and the software to be built will be affected by those security have and the software to be built will be affected by those security holes.holes.

3.3. Evaluate threats.Evaluate threats.- Logical security model: based on your system architecture.Logical security model: based on your system architecture.- Formal approach: for evaluating security and performance; Formal approach: for evaluating security and performance;

algorithms and security; etc. algorithms and security; etc. - Practical approach: create real scenarios to evaluate threats. Practical approach: create real scenarios to evaluate threats. - Tools and policy: employ available tools to find possible Tools and policy: employ available tools to find possible

vulnerabilities and write security policy for updates and vulnerabilities and write security policy for updates and maintenance.maintenance.

10

Understand business nature and related Understand business nature and related operations before designing any secure softwareoperations before designing any secure software

1.1. Identify valuable system assets.Identify valuable system assets. System resources and important data that your program(s) will System resources and important data that your program(s) will

access.access. Eg: CPUs, memory, network bandwidth, user access.Eg: CPUs, memory, network bandwidth, user access. E.g: a platform for launching attacks on other systems.E.g: a platform for launching attacks on other systems. Eg: sensitive information that can be used for other purposes.Eg: sensitive information that can be used for other purposes.

2.2. Identify critical entry points that your programs(s) will use.Identify critical entry points that your programs(s) will use. Any location where data or control transfers between the system Any location where data or control transfers between the system

being modeled and another system.being modeled and another system. Ex: network sockets, RPCs, web forms, files, are critical entry Ex: network sockets, RPCs, web forms, files, are critical entry

points.points.3.3. Determine trust levels that your program will be provided and can Determine trust levels that your program will be provided and can

provide.provide. Privileges to external entities (normally much less).Privileges to external entities (normally much less). Privileges to legitimate users (normally the majority that the Privileges to legitimate users (normally the majority that the

program is designed for).program is designed for). Privileges your program gains when it is executed.Privileges your program gains when it is executed.

11

View your software as a component of the View your software as a component of the system rather than a stand alone softwaresystem rather than a stand alone software

Your software

Client

Other parts ofThe System

Database

Wise designers always view their software as an important component of the system

12

Evaluate threatsEvaluate threats

Identify possible threatsIdentify possible threatsFor each entry point, determine how an For each entry point, determine how an

attacker may attempt to affect an asset.attacker may attempt to affect an asset.Based on your company’s asset, predict Based on your company’s asset, predict

what an attackers would try to do and what what an attackers would try to do and what her/his goals would be.her/his goals would be.

Logically analyse threats.Logically analyse threats.Decompose threats into individual, testable Decompose threats into individual, testable

conditions using techniques like attack conditions using techniques like attack graphs or trees.graphs or trees.

13

Identify possible threats with questions Identify possible threats with questions before design (e.g)before design (e.g)

Can an unauthorised network user view Can an unauthorised network user view confidential information such as system accounts, confidential information such as system accounts, system files, disk space, etc?system files, disk space, etc?

Can someone modify data like payments or Can someone modify data like payments or purchases in the database, even they are legitimate purchases in the database, even they are legitimate users?users?

Can someone deny authorised users access to the Can someone deny authorised users access to the application?application?

Can a user exploit a feature to raise their privileges Can a user exploit a feature to raise their privileges to, eg., administrator level?to, eg., administrator level?

Can a user get further access to the system using Can a user get further access to the system using your program? your program?

14

Identify possible threats before design (e.g)Identify possible threats before design (e.g)

There are possibilities that your software may compromise your There are possibilities that your software may compromise your system security. system security.

TTampering:ampering:eg: Modifying authentication files to add new a privileged eg: Modifying authentication files to add new a privileged

user and later to log on the system, muser and later to log on the system, modification of system odification of system files and programs, ect.files and programs, ect.

IInformation disclosurenformation disclosureeg: Obtaining a list of customer credit card numbers, eg: Obtaining a list of customer credit card numbers,

sensitive information from database, etc.sensitive information from database, etc.DDenial of serviceenial of service

eg: Consuming CPU time with multiple processes or causing eg: Consuming CPU time with multiple processes or causing many unnecessary I/O. many unnecessary I/O.

EElevation of privilegelevation of privilegeeg: Subverting a privileged program to run your commands eg: Subverting a privileged program to run your commands

or code.or code.

15

Logically analyse threatsLogically analyse threats

Decompose threats into individual, testable Decompose threats into individual, testable conditions using some structure, eg. attack conditions using some structure, eg. attack graphs, trees.graphs, trees.

Eg: using an attack tree to analyse possible Eg: using an attack tree to analyse possible attacksattacksRoot of tree is the attackRoot of tree is the attackEach level below root decomposes the attack Each level below root decomposes the attack

into finer approaches (hierarchically into finer approaches (hierarchically decompose a threat into nodes of the tree)decompose a threat into nodes of the tree)

16

Logically analyse threats:Logically analyse threats: eg eg

Attack using our CProgram or script

tempering

Run packet sniffingProgram to monitor

Your network

Start a new program /script

Insert a new privilege user

Make root’s passwd blank

Open ports and close them after attack

Flush out firewall rulesAt certain time

17

Secure design principles: code separationSecure design principles: code separation

Technique to separate the code in different parts, Technique to separate the code in different parts, so that each part runs with least privilege.so that each part runs with least privilege. if a part is compromised, others should still be OKif a part is compromised, others should still be OK Example: separating a user interface from the Example: separating a user interface from the

program running with special privileges (e.g., root)program running with special privileges (e.g., root) Good eg: implementation examples in Linux user Good eg: implementation examples in Linux user

interface and many applications run with user space.interface and many applications run with user space. Old bad eg: Old windows task bar tray icons running Old bad eg: Old windows task bar tray icons running

with system privilegeswith system privileges tray icon launching help with higher privileges can be tray icon launching help with higher privileges can be

exploited to execute arbitrary code with higher privilegesexploited to execute arbitrary code with higher privileges

18

Secure design principles : code secrecySecure design principles : code secrecy

The design should not allow security secrecy: the The design should not allow security secrecy: the security of the project should not depend on the security of the project should not depend on the secrecy of its design or implementation.secrecy of its design or implementation.

If the details of the security leaks (through reverse If the details of the security leaks (through reverse or social engineering), then it is a catastrophic or social engineering), then it is a catastrophic failure.failure.

For example: if your design allows secrets to be For example: if your design allows secrets to be hard-coded as part of your software for simplicity hard-coded as part of your software for simplicity or because a technical difficulty, then security leaks or because a technical difficulty, then security leaks can happen (e.g., hardcode a key, then leakage of a can happen (e.g., hardcode a key, then leakage of a key only affects one user).key only affects one user).

19

Other principles: least common Other principles: least common considerationconsideration

Mechanisms used to access resources Mechanisms used to access resources should not be shared unless there is no should not be shared unless there is no alternative.alternative.E.g: if we have two different services of E.g: if we have two different services of

different priorities provided to two different different priorities provided to two different sets of users, they can influence each other:sets of users, they can influence each other:Eg: one service may allow transmitting Eg: one service may allow transmitting

forbidden data of another service.forbidden data of another service.Eg: one service may limit availability of Eg: one service may limit availability of

another service and can cause denial of another service and can cause denial of service.service.

20

Case study (1)Case study (1)

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

21

Evaluate threats on this projectEvaluate threats on this project

Code injection?Code injection? Denial of service?Denial of service? potential installation risk?potential installation risk? Etc.Etc.

22

Apply design principles to this projectApply design principles to this project

Least privilegeLeast privilege

CompartmentaliseCompartmentalise

Other approaches.Other approaches.

23

Secure code implementation Secure code implementation

Designing secure code is only the first step to have secure software.Designing secure code is only the first step to have secure software. Implementing the design is another important step.Implementing the design is another important step.

Will you use RPC (is more portable software layer built on the top of Will you use RPC (is more portable software layer built on the top of socket layer for heterogeneous distributed applications) or sockets socket layer for heterogeneous distributed applications) or sockets to implement your network applications?to implement your network applications?

Some RPC facility really has security holes in itself. Sockets are at Some RPC facility really has security holes in itself. Sockets are at lower level therefore programming at this layer is more error-prone lower level therefore programming at this layer is more error-prone than at RPC layer.than at RPC layer.

There can be several possible implementations from one final There can be several possible implementations from one final design.design. The design of project-1 (case study 1) can be implemented in several The design of project-1 (case study 1) can be implemented in several

ways.ways. Using object-oriented approach and programming language such as Using object-oriented approach and programming language such as

C++ or JavaC++ or Java Using modular approach and programming language like C.Using modular approach and programming language like C. The user interface can be implemented in Java for several platforms The user interface can be implemented in Java for several platforms

or one interface for each platform.or one interface for each platform.

24

Secure code implementation: practiceSecure code implementation: practice

Implementation has to support the design security. Implementation has to support the design security. E.g: If code separation was used in the design, then E.g: If code separation was used in the design, then

implementation should not allow code of different implementation should not allow code of different privileges to be shared.privileges to be shared.

Compiler optimisation may affect the security of the Compiler optimisation may affect the security of the softwaresoftwareSome 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 Check compiler documentation for information about this

compiler specific behavior.Check assembly code using a debugger to ensure proper

behaviour – who can do this? Maybe GOD can.

25

Secure code implementation: practiceSecure code implementation: practice

OS security must be considered. OS security must be considered. Traditional software implementation is more Traditional software implementation is more

concerned about its portability rather than OS concerned about its portability rather than OS security. However, a piece of software can security. However, a piece of software can function surely on one OS but behave function surely on one OS but behave dangerously on another.dangerously on another.

Library security consideration.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

Implementation considerations to this Implementation considerations to this project (case study)project (case study)

Sockets or RPC?Sockets or RPC? Object oriented programming language or Object oriented programming language or

procedural?procedural? Database access facility as part of your Database access facility as part of your

software?software? Independent web based interface or Independent web based interface or

interface is part of your software?interface is part of your software?

27

Secure code design, implementation and Secure code design, implementation and maintenancemaintenance

Designing secure code is only the first step Designing secure code is only the first step to have secure software.to have secure software.

Implementing the design is another Implementing the design is another important step.important step.

Maintenance of secure code is even more Maintenance of secure code is even more important.important.Software is often modified from time to time.Software is often modified from time to time.Changes to the existing software can add Changes to the existing software can add

vulnerabilities and remove security that has vulnerabilities and remove security that has been expensively done at the design and been expensively done at the design and implementation steps. implementation steps.

28

Secure code maintenanceSecure code maintenance

To be able to have secure software over a To be able to have secure software over a period of time a complete software security period of time a complete software security policy has to be in place and strictly policy has to be in place and strictly followed.followed.

Make sure who will maintain the code Make sure who will maintain the code understand what have been done to achieve understand what have been done to achieve the security.the security.How do we do this?How do we do this?How can we modify the code and still have How can we modify the code and still have

the same level of security?the same level of security?

29

Testing and Verification (more details later)Testing and Verification (more details later)

Normal software engineering testing with Normal software engineering testing with random and/or dummy data normally will random and/or dummy data normally will not help find security holes.not help find security holes.

software security tests must be based on software security tests must be based on threat model, most important assets, and threat model, most important assets, and entry points.entry points.

More software security testing based on:More software security testing based on:application risks by technologies changes.application risks by technologies changes.application risks by other systems.application risks by other systems.

30

Verification (more later)Verification (more later)

Secure software verification is difficult Secure software verification is difficult because it is extremely difficult to invent a because it is extremely difficult to invent a formal or informal approach to verify if a formal or informal approach to verify if a piece of code meets security requirements.piece of code meets security requirements.E.g: a process can damage the system if it E.g: a process can damage the system if it

has a high privilege however we cannot has a high privilege however we cannot verify this when it is a program (a sequence verify this when it is a program (a sequence of lines of code). of lines of code).