Software Infrastructure for Electronic Commerce Computer Security Principles

1. Software Infrastructure forElectronic CommerceComputer Security Principles Professor Fred B. Schneider Dept. 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. 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 Principles What should the lock do? Must distinguish policy from mechanism. Desire mechanisms that implement many policies. certificate revocation lists digital signatures access control lists capabilities public key cryptosystem

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 Control Allows a subject to: • Read less-classified document. • Write more-classified document. Requires declassification! topsecret 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 Principles Principle 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 Principles Corollary 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. Deployment Strategies • [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.

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)