Software Infrastructure for Electronic Commerce Computer Security Principles

Preview:

DESCRIPTION

Software Infrastructure for Electronic Commerce Computer Security Principles. Professor Fred B. Schneider Dept. of Computer Science Cornell University. Goals. Develop a framework for thinking about computer security. Introduce the vocabulary used by practitioners. - PowerPoint PPT Presentation

Citation preview

Software Infrastructure forElectronic Commerce

Computer Security Principles

Professor Fred B. SchneiderDept. of Computer Science

Cornell University

2

Goals

Develop a framework for thinking about computer security.

Introduce the vocabulary used by practitioners.

Understand what existing computer security technology can and cannot accomplish.

3

Security: Pre-Cyberspace

Security is all about ... value locks police and courts

Locks must be good enough to prevent the “bad guys” from breaking in too often.

Some “bad guys” are caught. Police and courts convict often enough to

discourage break-ins.

4

Locks in the “real world”

Must not be annoying or they won’t be used.

All locks aren’t the same. They are: Scaled for what they are protecting. Scaled for their environment.

Police and courts are central---not the locks! We expect security breaches.

Tracking down the “bad guys” is what’s central. Locks reduce temptation and reduce workload on

police and courts.

5

The big picture People only pay for security that they think they

need.… need is based on personal experience & others

experiences. People avoid annoying locks by buying insurance.

– Risk avoidance versus risk management.– Externalities is a wrinkle!

Security is holistic…– Security is only as strong as the weakest link.– Making any link stronger than the weakest link doesn’t

much improve security.

6

Security: In Cyberspace

Terminology:vulnerability: Weakness that can be exploited

to cause damage.attack: Method of exploiting a vulnerability.threat: Motivated capable adversary who will

mount attacks.

All systems have vulnerabilities. We must understand the threats and defend against

attacks they can mount.

7

Cyber threats Operator/user blunders. Hackers driven by intellectual challenge (or boredom). Insiders: employees or customers seeking revenge. Criminals seeking financial gain. Organized crime seeking gain or hiding criminal activities. Organized terrorist groups or nation states trying to

influence national policy. Foreign agents seeking information for economic, political, or

military purposes. Tactical countermeasures intended to disrupt military

capability. Large organized terrorist groups or nation-states intent on

overthrowing the US government.

8

What do we protect in cyberspace?

Attacks compromise: Secrecy (confidentiality) causing

improper disclosure of information.… But what constitutes a secret, anyway?

Integrity causing improper alteration of information.

Availability causing service outages.

9

Security: In Cyberspace (con’t)

Security is all about ... value locks police and courts

Locks: authorization or access control mechanisms.– Locks have keys.– Keys are authentication mechanisms

… something you have, know, or are. Police and courts: same as before.

– Need authentication for audit information.

10

Computer Security Gold Standard

Authentication Authorization Audit

(N.B. Au is the chemical symbol for Gold.)

11

Lock Design

Security mechanisms are an integral part of your systems software.– Difficult to improve or to change.– Technical details are boring.

We discuss principles that underlie all:– Assurance Principles.– Functionality Principles.

12

Lock Design: Assurance

Economy of Mechanism: Use small and simple mechanisms where possible.

Consequences: Fewer errors in implementation because simpler. Easier to analyze for yourself.

13

Lock Design:

Assurance Principles

Open Design: Security of a mechanism should not depend on an attacker’s ignorance of the design.A. Kerckhoffs Principle (1883): The security of a cryptosystem

must not depend on keeping the algorithm secret.

No security by obscurity.No security by obscurity.

Consequences: Increased assurance if many critics. Reduced cost of recovering from key compromise.

14

Lock Design:

Assurance Principles: Open Design?

Open Design is controversial.With open design:

– Attackers job is easier because design is available.

– Analysis tends to concentrate on certain “main code”. Vulnerabilities off the beaten path remain.

– Flaws are not always revealed.

15

Lock Design:

Functionality PrinciplesWhat should the lock do?

Must distinguish policy

from mechanism.

Desire mechanisms that implement many policies.

access control listscapabilities

certificate revocation lists

public key cryptosystem

digital signatures

16

Some Security Policies

Discretionary access control:– Owner controls access to objects.– E.g, Windows NT:

Properties>Security>Permissions

Does not rule out “trojan horse” attacks.

17

Some Security Policies

Mandatory Access ControlAllows a subject to:

Read less-classified document. Write more-classified document.

Requires declassification!secret

top secret

classified

unclassified

18

Some Security Policies

Clark-Wilson Commercial Policies– Well-formed Transactions:

E.g. double-entry bookkeeping E.g. log all shipments

– Separation of Duty: E.g. auditor vs controller

19

Lock Design:

Functionality PrinciplesPrinciple of Least Privilege: A task/process/user is

accorded the minimum set of privileges needed to get the job done.

Consequences:– Limits Damage that can result from attack or

error.– Limits number of programs that can be

compromised to effect an attack.– Helps with debugging.

Example: super-user or admin privileges.

20

Lock Design:

Functionality Principles

Corollary of Principle of Least Privilege:

Complete Mediation: Every access to every object is checked.

Some implicit assumptions:– Some interface is being monitored.– Mediation mechanism cannot be

compromised.

21

Lock Design:

Functionality Principles

Corollary of Principle of Least Privilege:Failsafe Defaults: Access decisions are based

on the explicit presence of permissions rather than their absence of explicit prohibitions.

Safe way to tolerate administrative oversight.

22

Lock Design:

Functionality PrinciplesCorollary of Principle of Least Privilege:

Separation of Privilege: Each “lock” should require a separate “key”.

Consequences:– Allows fine-grained control and therefore

supports PoLP with higher fidelity.– Can be a sys admin nightmare.

23

Where to Deploy Locks

Axiom: Every system has vulnerabilities!

Consequently… – Employ multiple lines of defense.

… this is just Separation of Privilege!– Employ diversity of mechanism.

… diverse mechanisms are unlikely to share vulnerabilities.

24

Deployment Strategies

[Isolationism] Keep everyone out.– Cyber-security (hard) reduced to physical

security (easy).– But… no sharing of information or

services.

25

[Exo-security] Keep bad guys out. – Firewalls.– Code signing.

Perimeter defense… but no internal defense: Insider attacks possible. B2B e-commerce difficult. Precludes foreign code/extensible systems.

Deployment Strategies

26

Deployment Strategies [Pervasive Security] Prevent anyone who

gets in from doing damage.– Need PoLP mechanisms.– Must manage access rights---admin nightmare.

[Retaliatory Security] Let anyone in; recover from any damage.– Need audit:

Intrusion detection.– Need recovery.

27

Intrusion Detection

Monitor for:– Activity/code that matches attack

behavior.– Activity that does not match

“normal” behavior. Flawed in theory. Useful in practice.

28

In summary …

Q: What’s security all about? A: Value, locks, police & courts! Vulnerabilities allow Attacks by Threats Gold Standard: authentication, authorization, audit. Policy versus Mechanism! Important Principles:

– Economy of Mechanism (=Keep it simple)– Open Design (=Keep it public)– Complete Mediation (=Keep holding the reins) – Least Privilege (=Keep the reins tight)

Recommended