Introduction

• Asset (tillgång)
  • hardware, software, data, information, reputation...
• Vulnerability (svaghet)
  • weaknesses in design/implementation/procedure which may be exploited to cause loss/harm to assets
  • eg default passwords, NFS, ...
  • rated by impact (level of criticality)
• Threat (hot)
  • set of circumstances/actions which potentially cause loss/harm to assets
  • eg tapping the cable to see NFS traffic
  • Not the same as vulnerabilities: we may be invulnerable to threat (a vulnerability may not be a threat (we don't care))
• Attack
  • exploit of vulnerability
• Control
  • action, device, procedure, technique which removes or reduces vulnerability
  • eg network construction

A threat is blocked by control of a vulnerability

Four basic threats:

• interception: unauthorised access to information
• interruption: unavailability of authorised access (delete destruct etc)
• modification: unauthorised (or not)
• fabrication: unauthorised, (inject data, falsifications, etc)

Example attacks:

• Trojan horse: pretends to be nice, isn't
• virus: "infects" other programs
• worm: moves by itself
• trapdoor/backdoor: Wargames
• brute force password cracking
• bound/syntax checking: gets/fgets
• exploit information leaks (see information flow later; data vs information)
• denial of service (DoS)
• identity spoofing
• social engineering

2.1.1. Risk analysis

• quantitative: calculate expected losses by threat probability, asset values
• qualitative:
  • asset rating (critical, very important, important, not important)
  • vulnerability criticality (fix immediately, fix soon, fix sometime, fix if convenient)
  • threat rating (very likely, likely, unlikely, very unlikely)

Informally: Risk = Assets x Threats x Vulnerabilities

• Prevention (locks),
• Detection (alarms),

  detect damage occurred, how it's damaged, and who caused the damage

• Reaction

  recover from the damage (minimise damage, make it not happen again)

(We deal only with technical, not social aspects, risk analysis/management etc)

• Confidentiality: prevent unauthorised disclosure of information
• Integrity: prev. unauth. modification of info
  • clark/wilson: no modification even by authorised users
  • data integrity - external consistency,
  • networking: detection/correction of modif/insert/delete/replay, intentional/transmission err
• Availability: prevent unauthorised withholding of info (or resources)
  • accessible when needed, without undue delay
  • accessible & usable when authorised entity needs
  • cf DoS
• More aspects
  • accountability: record audit info wrt security, for tracing responsible party
  • authenticity (peer entity and data origin),
  • trust, risk, privacy, anonymity
• Reliability; DEPENDABILITY
  • should be able to depend on the computer system

Should protection mechanisms focus on data, operations or users?

• Focus of Control - data, operations, or users
  • data: internal consistency, type control - irrespective of user/operation
  • operations: only certain operations can access data - depending on user/data
  • users: only certain users can access certain data

Traditionally OS focused on data (resources), more recently operations/users.

In which layer should a security mechanism be placed?

• Man-machine scale - applications to hardware
  • application programs
  • services of software package
  • operating system (controls file, memory mgmt, devices/resources)
  • OS kernel (controls accesses to processor, memory etc)
  • hardware: processor, memory, etc

lower: more generic, resource oriented, hardware
higher: application specific, user requirements

"1+2 gives man-machine scale"

Dimensions:

        application
          ^
          |
user <----+------>    resource/data
          |
          v
        hardware

Simplicity and higher assurance, or lots of features?

• Complexity vs assurance
  • complex systems are powerful, but hard to use, manage, and analyse
  • simpler systems may match requirements poorly, but be easier use, manage and analyse