INF526: Secure Systems Administration Composition of Systems And Protection Domains

1. INF526: Secure Systems Administration Composition of Systems And Protection Domains Prof. Clifford Neuman Lecture 3 25January 2017 OHE100C

2. Announcements • First mid-term exam next Friday • In class, 2PM to 3PM • Followed by Lecture on Adversarial Security Planning • Exam will be closed book • We will review for exam at end of this lecture • For those monitoring this class • Visit ml.zmbx.com and add yourself to inf527advisors. • Will get copy of announcements already sent to enrolled students.

3. Preliminary Presentations 2/8 Miles Wright-Walker - Developing adversarial security plan 2/15 Matthew Jackoski - Red Teaming / Pen Testing Tools 2/22 Abdulla Binkulaib- Developing a response plan 3/1 Jikun Li - Linux security administration 3/8 Daniel Dmytrisin - Network security components & Tech 3/22 Haibo Zhang - Network Security administration 3/29 Mariam Fahad Bubeshait - Configuration Management 4/5 Mohammed Alsubaie– SIEM and Intrusion Detection 4/12 Vishnu Vadlamani - Network Monitoring/Attack Forensics 4/19 Andrew Gronski - Accreditation and acceptance testing

4. Initial Homework Assignment(due last night (11:59+1PM) on Tuesday January 24th) • Submit as email to inf526@csclass.info • System Structure for Banking Case Study • Consider the description of the banking system to be used for the first exercise – as discussed in class on 1/25. • Enumerate the classes of data • Enumerate the classes of users • Identify the protection domains • Enumerate the systems (hardware) • Enumerate the systems (software components) • This write-up is expected to be about 3 pages in length(could be more or less) • It will be shared later with your group members to begin discussion for the group architecture.

5. Banking • Your organization must: • Maintain a database of account holders • A database of account balances • Enable web access by customers who: • Can update their personal information • Check their account balance • Transfer funds to another account (by number) • View transactions on their account • Submit an image of a check for deposit • (check should be viewable, but you do not need to scan it or process it) • Access is needed • Via web from the open internet • Outbound email confirming transactions • All other interactions may be limited by information flow policiesto internal machines.

6. Preparation for Lab Activities • Install free version of vmplayer or virtualbox on your own machine • Configure some version / dist of Linux as a guest OS. • Run two instances simultaneously • Configure to allow network communication between the two VMs. • Install a web server on one of the VMs. • Configure Dynamic DNS (e.g. no-ip.com) to enable connection to the server from the internet. 16

7. Connecting to VMs • VNC – Virtual Network Computing • Install TightVNC or other Client on machine from whichaccess is attempted. • Install and configure VNC server on Virtual Machine • A VNC Server can be run inside your VM, or in the hypervisor • Inside the VM is likely easier • Portmapping a must • Find the IP using dynamic DNS • But multiple VM’s on a shared NAT need to be mapped manually to different ports. • We are trying to gain access to a server under which you can run VM’s which you would connect to the same way you would here, via VNC • Address mapping would be easier.

8. Group Exercise One • Decide on the software components to be deployed to implement software requirements on next slide. • Custom development should be simple scripts. • Use packages for database and other components. • Decide on the VM’s to be created to run those software components. • You can run more than one software component within a VM if you choose. • Decide on the methods you will use to contain access to those software components, and to the information managed by those components. • Configure communication between VM’s and to the outside • Install packages • Write scripts and demonstrate basic flow through system. • Report on progress as group by email on Tuesday.

9. Group Assignments • Group 1 for Exercise 1 • Muaz Alkhalidi • Abdulla Binkulaib • Daniel Dmytrisin • Edward Guerrerobognoli • Jikun Li • Miles Wright-Walker • I will send an email to each group with the emails of other students in your group. • Group 2 for Exercise 1 • Mohammed Alsubaie • Mariam Fahad Bubeshait • Andrew Gronski • Matthew Jackoski • Vishnu Vadlamani • Haibo Zhang 16

10. What are you Securing • The System as a Whole • Comprised of Software Components • Components have access to information • The Composition Problem • System must be evaluated as a whole • Can only reason about complete encapsulation • In which case you are reasoning about the effectiveness of containment. • Guard example • Firewall example

11. Banking Example Discuss Assignment • Already Discussed Data • What has access to the data • Software components • Users – through software components running with identity of particular users or groups • Software components run on systems • Ideally in their own protection domain • But systems have administrator/root access • What does this mean for your containment architecture?

12. From Last weekNetwork Administration • Creation of network protection domains • Firewalls • VLANs • VPNs for access • Ipsec • Define required characteristics • Where is encryption required

13. Containment Technologies • Network Containment • Firewalls • Virtual Lans (VLANS) • Virtual Private Networks (VPNs) • Encryption • SSL, TLS, IPSec, and IPv6 Security • End to End • Application encapsulation • Trusted Computing Key Management • Guards • Network Administration

14. Containment Technologies • Containment Within a Computer • OS Enforced Access Control • MAC or DAC • Application Enforced Access Control • Database access policies • Web access policies (e.g. .htaccess) • Specific Technologies • Virtual Memory or Segment Architectures • Reference Monitory / Access Control • User mode vs System Mode • Trusted Computing • System Administration

15. Containment Technologies • System Containment • Encryption Based • Guards • Object Encryption

16. Protection Domain • The set of objects and operations on those objects that may be performed by a process. • If access is dynamic, then the concept is amorphous. • Generally, if two processes share the same access to objects, we think of them as being in the same protection domain. • An object, or collection of information, will usually be part of more than one protection domain. • Granularity usually not smaller than that of a process (at a particular point in time) since the process is the only entity capable of accessing data.

17. Controlling Access to Databy Protection Domains • General Containment • System Boundaries • Data exists in memory (V or NonV, Primary or Secondary) of a system. • It can only be accessed from outside that system with: • Physical Access to the peripheral • Assistance by a process running on that system • Does this apply to NAS? • Does this apply to cloud storage?

18. Processes and Concentric Protection Domains • Process Boundaries • Managed by OS • Limits access by processes to their own memory • Limits access to storage according to permissions (DAC,MAC) • May assign labels to data based on processes protection domain (labels) • System has full access, Administrator might have full access • MAC and Trusted computing can control admin access

19. Network Containment • When data is sent across a network • It should be considered accessible by all computer on the network segments traversed • Unless that data is encrypted • When a process on a system can communicate with a process in the network. • It should be considered subvertable by any process with which it communicates. • A subverted process can not control access to information within its protection domain. • Network Containment • Controls the segments of which data can traverse (outbound) • Controls communication (inbound) that is capable of subverting a process or accessing data.

20. Host Administration Guidance • Create multiple protection domains • Don’t run anything as root (or as little as possible) • Configure access to resources carefully • Use Host Based Firewalls as added barrier to communications • Reduce the attack surface • Consider iptables (packet filters)

21. Network Administration Guidance • Use firewalls to contain access • Distributed Host Based may be okay and more effective for some environments – embedded even better. • Disallow by default • Open a flow only when defined by application and system architecture. • VLAn’s good, but unless enforced by network hardware or encryption, subverted hosts can circumvent.

22. Administering Encryption • Encryption can provide containment independent of the integrity of the systems connected physically to the stored or transmitted data. • Reduces protection of data to protection of the key • Still circumventable when access to plaintext exists. • Key Management issues • Can leverage trusted hardware • Smartcards, Secure Elements, TPM’s, Intel’s Trusted Execution Technology (TXT) • Often too complex to manage at level of authorized users

23. Review for Mid-Term 1 • In Class – One Hour – More of a Quiz than mid-term • Closed Book • Focus will be on materials and discussions from first three lectures • Key Approach to secure administration • Reduction of attack surface • Go through slides and discussion and ask yourself how each approach discussed reduces (or expands) the attack surface.

24. Course Outline Through Quiz 1 • Introduction to Secure System Administration • Generation of Security Requirements • Composition of systems and protection domains • Adversarial Security Plan

25. Role of Admnistrator • Administration • Selection of components (purchases of products) • Architecture – how the pieces fit together • Installation and configuration • Security Testing • Operation • Monitoring • Repair and Maintenance • Threat response • (Think in terms of minimization)

26. Application Architecture • What are the functional requirements of the system? • This guides equipment needs • Processing, Storage, and Network. • What are the functional goals of the system. • This defines the meaning of availability • What constitutes a breach of availability – the system no longer meets its functional goals. • Critical Infrastructure • Critical for you • (what can be done here in terms of minimization) 16

27. Positive and Negative Requirements • Functional requirements are positive. • This is what most developers focus on • And why are systems are not secure. • Functionality over security • Security requirements tend to be negative • What should not be possible (conf and integ) • But availability is a positive requirement • How do we test for negative requirements • absence of evidence is not evidence of absence 16

28. Information Flow and Containment • Understand your applications Information Flow: • What is to be protected • Against which threats • Who needs to access which apps • From where must they access it • You will minimize allowed flows, reducing attack surface. 16

29. Classes of Users • Decide on classes of users • Based on the access needed to the different classes of data. • You will architect your system and network to enforce policies at the boundaries of these classes. • You will place data to make the mapping as clean as possible. • You will manage the flow of data • To minimize what is authorized 16

30. Component Selection • What systems do you need • System or VM for different classes of protection domains. • Network Components • To interconnect • To Segregate • Management Components • Special tools for management and security • You will manage the flow of data • Competing issues to balance in terms of minimization. 16

31. Identity Management • Interrelation of identity with policy • Selection of authentication technology • Enrollment issues • Balancing cost with security • What is needed for strong audit capability • Not just intrusion detection • Regulatory and recovery/remediation • Allows us to implement least privilege 16

32. Configuration Management • Catalog of systems • What is approved for connection • Catalog of software • What is approved for use • Patch management • Configuration checkers • Change detectors • E.g. tripwire, AFIK • Ensure continued minimization 16

33. System Administration • What must be administered: • User accounts – Least Privilege • Software • Servers • Storage • Network (next slide) • Keys • Monitoring • Logs and Audit • Core principles • Minimization

34. Network Administration • Creation of network protection domains • Firewalls • VLANs • VPNs for access • Ipsec • Wireless Management • Network Monitoring • Network Admission Control • Reduction of attack surface

35. Administration vs Development • Different stages in system life cycle • Administration is concerned with installation, interconnection, configuration, operation, and decommissioning • Administration is concerned with the environment • Development addresses the idea architecture of the system • Depends on assumptions • Security fails when environmental assumptions are violated. • Let’s brainstorm on examples of such assumptions that led to security failures when they no longer held.

36. Your Oganizations Security Policy • First step – Establish an Organization Security Policy • Generally accepted Principles and Practices – NIST 800-14 http://csrc.nist.gov/publications/nistpubs/800-14/800-14.pdf • Guidance in writing a security policy www.GIAC.org/paper/gsec/734/system-security-policy/101613 • First question for security auditors • It will guide you in creating categories of data and user • Reduction of attack surface is one way to think of the security policies that are effective.

37. Your Oganization’s Security Policy Guidance in writing a security policy www.GIAC.org/paper/gsec/734/system-security-policy/101613 • First question for security auditors • It will guide you in creating categories of data and user and the kinds of access authorized • It provides specific guidance for security requirements necessary to meet the principles just discussed. • It will define responsibilities • It will provide the basis for evaluating your organizations ability to meet the principals discussed earlier.

38. Security Requirement's • Information Access • Mandatory Policies • Discretionary Policies • Requirements on Security Technology • Personnel Security • Including training • Physical Security • Monitoring and Audit • Vendor Requirements • Accreditation 16

39. Information Access • Decide on multiple data classes • Public data • Customer data • Corporate data • Highly sensitive data • Access to each class of data • Can you support mandatory policies • Otherwise what discretionary policies apply. • Domain boundaries • Based on users and locations 16

40. Technological Requirements:Information Access • Identity Management • Factors / Basis for Authentication • Enrollment, Exception Handling • Other policy conditions • Containment • Firewalls, VLANs • Encryption • Policy • Decision points • Specification point (or administration) • Enforcement point 16

41. Points of Policy • By Axiomatics - Axiomatics, CC BY 3.0, https://commons.wikimedia.org/w/index.php?curid=48397652 16

42. INF526: Secure Systems Administration Adversarial Security Planning (advance slides) Prof. Clifford Neuman Lecture 4 1 February 2017 OHE100C

43. Plan Your Attacks • It is important to think like an attacker to best assess your defenses. • Look for the overlooked • Attackers seek out the weakest links,the forgotten window • Weak systems may be used as stepping stones • That forgotten system that is unpatched is compromised, then the attacker pivots and attacks from within. • Check the integrity of your defenses • Attackers may disable defensive measures

44. Attackers: The One Trick Hacker • Attacker has specific tools • Casts the tool widely to see what can be caught. • Sometimes described as script-kiddies • Gets them into systems or with specific vulnerabilities • Gets them account access to susceptible employees • The gather what they find, exfiltrate or modify, and stop there • Strong security posture is effective • Sound security practices • Systems up to date • Least privelege

45. Attackers: Opportunistic or Bottom Up • Looks for the weak link • Uses tools to scan for vulnerabilities • Once in, repeats the process • This time starting with elevated access because of the system or user ID already compromised. • Your containment architecture is critical against such adversaries. • You need to be aware of the paths that might befollowed to reach sensitive data.

46. Attackers: Goal Oriented Top Down • Learns about your organization and system • Goal is to compromise some component of your system or access specific data. • Learns precursor activities that must be achieved to meet that goal. • Often applies APT – Advanced Persistent Threat tactics • Will wait for threat vector to propagate • Defenses require all of: • Strong security posture • Training of privileged employees • Containment Architecture • Strong defenses to subversion.

47. Threat Modeling (from INF523) • In Informatics 523 we discussed threat modeling in terms of systems that are being developed. • In this class we are focusing on administration of systems that have already been developed. • The same techniques must be applied, but the things you can change may be more limited. • In administering the system you are constrained by the implementation. • But you still configure components and networks, and must do so in a way that mitigates the threats you identify.

48. Purpose of Threat Modeling • Identify threats against a system • Identify deficiencies in securityrequirements and design • Identify threat countermeasures • Include, but not limited to, technical mechanisms • May include administrative and physical controls • Must also consider threats to the countermeasures! • Process should be repeatable, methodical • Fix one vulnerability and you have a new weakest link • New threats appear and reassessment becomes necessary.

49. Attack Trees • Intended to be a “formal” way of modeling attacks • Tree-like representation of an attacker’s goal recursively refined into conjunctive or disjunctivesub-goals • Attacker’s “goal” is root of tree • For top-down attacker, this may be their target • For bottom up, there are many goals • These are their first steps • Top down attacker will have leaves • Called “refinements” of the parent goal • Formalized by Mauw and Oostdijk in 2005 (Foundations of Attack Trees [ICISC’05], http://www.win.tue.nl/~sjouke/publications/papers/attacktrees.pdf)

50. Attack Trees • Schneier’s safe example: • Mark leaves as “possible”or “impossible”. • “Or” nodes and “and” nodes • When is goal possible? Banking System Example P= L I=U