CCM4350 Security Architecture and Engineering Lecture 2 Security - PowerPoint PPT Presentation

CCM4350 Security Architecture and Engineering Lecture 2 – Security Design Principles 15.10.2012 1

Content of Today’s Lecture • Summary and Wrap up on Security Terminology • The Fundamental Dilemma of Security • Five Design Principles for Engineering Secure Systems (Lecture follows D. Gollmann. Security Engineering , Section 2.1-2.6, 2 nd edition, Wiley 2006)

Last Lecture • Security can be defined as (CIA) C onfidentiality I ntegrity A vailability • Sometimes Prevention of security attacks fails • Then we need to rely on Accountability and Non-repudiation.

Accountability and Non-Repudiation • Accountability: Keep auditing to trace responsible party — Necessitates identification and authentication — Trail security relevant events in audit • Nonrepudiation: Provide unforgeable evidence for actions — Nonrepudiation of occurrence and — Nonrepudiation of delivery

Relationship to other areas of computing Dependability • Dependability (according to Laprie): Availability (point in time) Reliability (time interval) Safety Confidentiality Integrity Maintainability Σ CIA = Security

Safety versus Security • Security always begins at the host • Safety: protection against catastrophic impact by the environment (protect human lives and economic values) • Security: protect the computer/network systems against threats Safety Security

Conclusions on Terminology • There is no single definition of security • When reading a document, be careful not to confuse your own notion of security with that used in the document • A lot of time is spent (and wasted) in trying to define unambiguous notations for security Definition: Computer Security deals with the prevention and detection of unauthorised actions by users of a computer system. 7

0 th Step: Analysis of Goals and Attacker • Security Engineering has two parallel activities • Analysis of Protection (Security) Goals — CIA: specify which ones are important for which user — Multilateral Security: resolve security conflicts • Attacker Model: — There is no protection against the a skillful attacker — Hence quantify attacker (e.g. Attack trees, Misuse cases) 8

The Fundamental Dilemma of Security • In the past, only few organisations (DoD) relied on security • Today, everyone connected to the Internet relies on computer and network security Fundamental Dilemma: security-unaware users have specific security requirements but no security expertise. 9

Principles of Security (Gollmann) • Horisontal axis: focus of security policy • Vertical axis: layer of computer system to place protection mechanism

Focus of Control: 1 st Design Decision 1 st Fundamental Design Decision: (horisontal) Should the focus of security control be on — Data — Operations, or — Users? Example: rules for integrity of accounts database — Data rule: internal consistency of balance of account — Rules for operations that may be performed on a data item — Rules specifying the users allowed to access a data item

2 nd Fundamental Design Decision: In which layer of computer system should we place security controls? 1 2

The Man-Machine Scale: 3 rd Design Decision • Visualise security mechanisms as concentric protection rings: generic data mechanisms in the centre; mechanisms addressing user requirements at the outside. 1 3

The Man-Machine Scale • Scale balances Information with Data 1 4

3 rd Fundamental Design Decision • Location of a security mechanism on the man- machine scale is related to its complexity. — Right: Generic mechanisms are simple, — Left: User applications clamour for feature-rich security functions. • 3 rd Design Decision: Do you prefer simplicity – and higher assurance – to a feature-rich security environment? — These two do not match easily — High assurance requires adherence to systematic design — Security adopted formal methods early for highest assurance levels: e.g. Orange book (A1/2), CC (EAL5-7)

4 th Design Decision: Central or Distributed Control • Central entity in charge of security: —Easy to achieve uniformity… — But central entity may become a performance bottleneck • Distributed solution —May be more efficient… — But difficult to ensure that policy is enforced consistently 4 th Design Decision: should the tasks of defining and enforcing security be given to a central entity or should they be left to individual components in a system.

The Layer Below • So far, we only explored means to express security policies but what about the attacker? • The attacker may try to bypass our protection mechanism to reach their “soft underbelly”. • Example: if attacker gains system privileges in the OS he can change the control data for security mechanisms in the services and application layers.

Security Parameter • Every protection mechanism defines a security perimeter (boundary). — The parts of the system that can malfunction without compromising the mechanism lie outside the perimeter. — The parts of the system that can disable the mechanism lie within the perimeter. • Note: Attacks from insiders are a major concern in security considerations.

Exercise • Identify suitable security perimeters for analysing personal computer (PC) security. — Consider the room the PC is placed in, the PC itself, or some security module within the PC when investigating security perimeter. • Questions you should ask to answer the question above: 1. Physical security: Is the PC in a protected room, a room shared with colleagues, a room in a public place? 2. What are the options for input? Keyboard, data carrier (CD, USB stick, floppy), Internet? 3. Can users take the PC home or open it?

5 th Design Decision: Blocking Access to the Layer Below!!! Attackers try to bypass protection mechanisms. • There is an immediate and important extension to the 2 nd design decision: • 5 th Design Decision: How can you prevent an attacker from getting access to a layer below your protection mechanism?

Physical and Organisational Security Measures Control Access to Layer Below

The Layer Below – Examples • Recovery tools restore data by reading memory directly and then restoring the file structure. Such a tool can be used to circumvent logical access control as it does not care for the logical memory structure. • Unix treats I/O devices and physical memory devices like files. If access permissions are defined badly, e.g. if read access is given to a disk, an attacker can read the disk contents and reconstruct read protected files.

More examples – The Layer Below • Object reuse: In single processor systems, when a new process is activated it gets access to memory positions used by the previous process. — Avoid storage residues, i.e. data left behind in the memory area allocated to the new process. • Backup: Whoever has access to a backup tape has access to all the data on it. — Logical access control is of no help and backup tapes have to be locked away safely to protect the data. • Core dumps: same story again; if internal state contains sensitive information, like keys, they can be read from core dump. Attacker can intentionally crash system.

Summary • Security terminology is ambiguous with many overloaded terms. • Fundamental Dilemma: — Too many security-unaware users due to Internet — They cannot understand security evaluations (orange book etc) • The resolution of this Fundamental Dilemma is currently the most pressing challenge in computer security. • Five Design Decisions help to define security policy and security perimeter – and to address the dilemma?

Outlook: Aspects of Network Security • Distributed systems: computers connected by networks • Communications (network) security: addresses security of the communication links • Computer security: addresses security of the end systems; today, this is the difficult part • Application security: relies on both to firewall provide services securely to end users • Security management: how to deploy security technologies 2 5