MidTerm Question 5

1. MidTerm Question 5 • Given the following security architecture, specify ways that the use of firewalls and/or intrusion detection systems might be used to improve the architecture. Due to cost constraints, you are limited to acquiring no more than two additional devices to support your security policy. Be specific on the use of filters and proxies. State any assumptions with regard to security policy and justify how the improved architecture supports your security policy. (20 points) • You are the security manager for a company site consisting of 50 technical staff and a number of support and temporary staff. Most staff use Windows 2000 and/or Linux systems on their desktops. You have an Internet connection through a T-1 line into a two-port router that provides some packet filtering of ports recommended in previous CERT advisories. Your site is about to begin a new electronic ordering service to its customers through a web interface that will store and process customer credit card information. The current Beta test web site is on the desktop of one of your technical staff. There are no other specific security products in place at the site. While your technical staff has a lot of computer programming expertise, you have no one on staff that is familiar with current security products or their configuration.

2. 5 Part Answer • Define the (delta) Threat • Refine the policy • Structure the architecture • Address staff/training issues • 5. Maintain the system

3. Initial Architecture PC with web Server and DB PC PC Office LAN PC PC PC Router PC T-1 Line to Internet PC PC PC PC PC PC PC PC PC PC

4. Improved Architecture PC PC Office LAN PC PC PC Router PC T-1 Line to Internet PC PC PC PC Firewall PC PC PC PC PC IDS PC PC with web Server and DB

5. Question 8 • You are the security manager of the web site for a major corporation. After the introduction of a controversial product, your web site is flooded with web traffic from all over the Internet, and the system supporting the web server crashes, destroying a full day’s cache of product ordering transactions. How would you determine whether this was simply an increase in normal traffic versus an attack on your company? How would you respond to ensure the survivability of your company? What steps would you take to ensure that future events of this type were handled more smoothly? (10 points)

6. PKI • CERT Coordination Center • Software Engineering Institute • Carnegie Mellon University • Pittsburgh PA 1521 Tom Longstaff SM • The CERT Coordination Center is sponsored by the Advanced Research Projects Agency (ARPA). The Software Engineering Institute is sponsored by the U.S. Department of Defense.

7. Types of Encryption Systems • Two basic types: • Shared (or symmetric) key encryption • Public (or asymmetric) key encryption • Shared: use of a single key for both encryption and decryption that both parties must share • Tends to be more efficient • Used for block ciphers • Public: different keys used for encryption and decryption • Most popular form is based on RSA or Diffie Helman • More computational intensive (uses exponentiation) • Frequently used for symmetric key exchange

8. Using Public Key for Signatures • A digital signature is a cryptographically strong hash of a longer data set • E.g., MD5 used by tripwire and others to verify the integrity of the information • If you create a digital signature to a document, then encrypt it with your private key, anyone can verify two properties of this information: • Integrity (through the MD5 checksum) • Source (only the owner of the private key could have encrypted the signature) • A digital signature, signed with a private key on a public key becomes a trust verifier for that key

9. Signed Keys • Example: • Alice has an asymmetric key pair - creates an MD5 checksum of the key and encrypts it with her private key • Alice: K{public},(K[MD5]{public})K{private} • Bob (K’) verifies the authenticity of the key, then encrypts the MD5 with his private key as well • K{pubic},(K[MD5]{public})K{private} },(K[MD5]{public}) K’{private} • And so on

10. Other properties in signed keys • In addition to the MD5, other properties may be included in the private encrypted part of the public key record • Level of trust • Relationship with the key owner • Link to other CA information • K{pubic},(K[MD5]{public},owner,email)K{private} },(K[MD5]{public},moderate trust,email,authoritative CA) K’{private}

11. Web of trust • From these building blocks, a web of trust can be built: • Two users cross-sign each other’s public keys • Alice signs Bob who signs Charlie who signs Dain who signs Alice • A particularly trusted user signs many keys • If you have a small number of individuals you trust, you can build a bridge to a new recipient • This is the principle behind pgp

12. Other pgp attributes • Trust of a key you are signing • Trust of a key you receive • Key rings • Key servers • PGP designed to sign static documents, not live transactions but the PKI built up with PGP can be used to exchange a session key for a live block cypher • E.g., pgp phone.

13. PKI • Mechanism to distribute and trust public keys • Two types in common use: Hierarchical and the Web of Trust • Modified Hierarchical combines distinct Hierarchical PKIs with cross-realm authentication • Common use of PKI refers to Hierarchical, but also covers Web of Trust and Modified Hierarchical

14. Key and signature revocation • What if a private key is compromised in the web of trust? • First of all, need a mechanism to distribute this information • Secondly, need to invalidate all signatures under this key • May be able to limit the extent of revocation based on date of the revocation certificate

15. Building up a hierarchy of keys • In a hierarchical PKI, you need a root certificate who’s security is above reproach • Why? • ROOTPublicKey,(ROOTPublicKey[MD5])ROOTPrivateKey • CAPublicKey,(CAPublicKey[MD5])CAPrivateKey,(CAPublicKey[MD5])ROOTPrivateKey • UserPublicKey,(UserPublicKey[MD5])UserPrivateKey,(UserPublicKey[MD5])CAPrivateKey

16. Distribution of Hierarchical Public Keys • The root public key must be widely distributed in a variety of paths to everyone in the hierarchy • Why multiple paths? • What is the primary vulnerability here? • If the root key is secure, the system can be consistent • Root key is used to sign all revocation certificates for Cas • Root servers do not need to sign keys lower in the hierarchy • Why not?

17. One versus Multiple Hierarchies • What are the problems with a single root server for all PKI systems? • If you want to trust users across hierarchies, you need cross-realm certification • Combines Web-of-Trust with Hierarchical PKI • Means that some root or CA public key is signed by one in the other hierarchy

18. Problems in cross-realm certification • Naming • Different policies for inclusion in the hierarchy • Different uses of keys • Compatibly of algorithms and key records

19. What does this have to do with operating system security architectures? • Application-level architecture • Trust of users within the operating system • Basic tool for linking users with processes • Kerberos and related systems make use of these concepts to implement OS trust

20. Kerberos • Based on symmetric key encryption • Solves the problems: • Untrusted client machines need to authenticate users • Need data protection for applications • Provides authentication and authorization for services • Once the infrastructure is in place, applications must be instrumented to use kerberos • Examples of Kerberoized applications: • Telnet • BSD Rtools • Email • NFS, AFS, etc.

21. The Key Distribution Center (KDC) • Must be a physically secure host in the system • Stores a shared key with each principal (each user and service that uses kerberos) • The main job of the KDC is to create session keys and distribute them based on the shared secret key of the user • Also known as an authentication server in the Kerberos documentation

22. KDC Example • Alice requests a session with Bob • KDC encrypts a session key with Alice’s key and sends to Alice • Also sends the session key and some info on Alice encrypted with Bob’s key • Now Alice can talk to Bob, Bob can decrypt the session key and open a comm with Alice KDC (Request Alice to Bob)Ak (session key)Ak,(Alice, session key)Bk Alice Bob Open comm, (Alice, session key)Bk (data)SessionKey

23. TicketGrantingServer (TGS) • Really does the same job as the KDC, but in theory provides another layer of security • Alice gets a ticket (session key) to talk to a TGS from the KDC • Uses this ticket to request tickets to talk to Bob • In practice, the KDC and TGS are the same system as the TGS has to have the same database of shared keys to create tickets for Bob

24. Logging in to a Network • You need to get a session key and a ticket-granting-ticket [AS_REQ], Alice need TGT Alice Workstation Name, password KDC [AS_REP] {Sa,TGT}Ka Asks for Alice’s uid Gets the tgt Uses password to decrypt the TGT If successful, discards Ka and uses only the TGT to gain more tickets Invents Sa Finds Alice’s master key TGT={Alice,Sa}Ktgs

25. Using the TGT and Sa • After logging into the network, Alice asks to talk to Bob (e.g., rlogin to Bob the workstation) [TGS_REQ] Alice rloign bob, TGT, {timestamp}Sa Alice Workstation Sa and TGT rlogin bob TGS [AS_REP] {bob, Kb, Tb}Sa [AP_REQ] Tb {timestamp}Sb Invents Sb Decrypts TGT to get Sa Decrypts timestamp to verify authenticity Finds Bob’s master key Creates ticket to bob Tb= {Alice, Sb}Kb [AP_REP] {Timestamp+}Sb Bob Decrypts Tb to get Sb Decrypts timestamp Encrypts new timestamp

26. Kerberos V5 • In principle, the same as V4 but with a major overhaul of the implementation and addition of features. • Allows for delegation of rights, • renewable and postdated tickets, • other cryptographic algorithms (V4 used only DES and Jueneman), • allowed for a hierarchy of realms