INF 526 Secure Systems Administration Composition of Systems

INF 526: Secure Systems Administration Composition of Systems And Protection Domains Prof. Clifford Neuman Lecture 3 25 January 2017 OHE 100 C

Announcements • First mid-term exam next Friday – – In class, 2 PM to 3 PM 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 inf 527 advisors. – Will get copy of announcements already sent to enrolled students. 1

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 2

Initial Homework Assignment (due last night (11: 59+1 PM) on Tuesday January 24 th) • Submit as email to inf 526@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. 3

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 policies to internal machines. 4

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

Connecting to VMs • VNC – Virtual Network Computing – Install Tight. VNC or other Client on machine from which access 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. 6

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. 7

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

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 9

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? 10

From Last week Network Administration • Creation of network protection domains – – Firewalls VLANs VPNs for access Ipsec • Define required characteristics – Where is encryption required 11

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

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 13

Containment Technologies • System Containment – Encryption Based – Guards – Object Encryption 14

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. 15

Controlling Access to Data by Protection Domains • General Containment – System Boundaries • Data exists in memory (V or Non. V, 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? 16

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 17

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. 18

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) 19

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. 20

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 21

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. 22

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

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) 24

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

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

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

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

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

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

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

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

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

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. 34

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. 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. 35

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. 36

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

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

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

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

INF 526: Secure Systems Administration Adversarial Security Planning (advance slides) Prof. Clifford Neuman Lecture 4 1 February 2017 OHE 100 C

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 42

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 43

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 be followed to reach sensitive data. 44

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. 45

Threat Modeling (from INF 523) • 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. 46

Purpose of Threat Modeling • Identify threats against a system – Identify deficiencies in security requirements 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. 47

Attack Trees • Intended to be a “formal” way of modeling attacks – Tree-like representation of an attacker’s goal recursively refined into conjunctive or disjunctive sub-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 48 (Foundations of Attack Trees [ICISC’ 05], http: //www. win. tue. nl/~sjouke/publications/papers/attacktrees. pdf)

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 49 I=U

Attack Trees • Knowledge and creativity needed by analysts – Think like an attacker – All sorts of vulnerabilities in different sub-systems – Analysts must understand all parts of the system well • Often highly subjective 50

Countermeasures • Once tree “complete”, use it to identify countermeasures • Bring value of node below threshold to “deactivate” – E. g. , a countermeasure that makes a leaf “impossible” – Or that makes too expensive • Do that for all “or” leaves or any “and” leaf to deactivate parent • Recurse up the tree to root 51

Attack Trees, Pros and Cons • Pros – Conceptually simple – Scalable – Reusable • Cons – Only considers attacker’s point of view – No countermeasures in the graph • How do you show attacks on the countermeasures? – No attacker/defender interactions – Simple signatures or single-point exploits – Weak or no explicit link between steps • How are they related? Ordering? 52

Attack-Defense Trees • Introduced by Kordy et al. (Foundations of Attack–Defense Trees [FAST’ 10], http: //satoss. uni. lu/members/barbara/papers/adt. pdf) • Includes countermeasures, so can show attacks on countermeasures 53

Attack-Only Tree Example 54

Attack-Defense Tree Example 55

A-D Trees • Pros – Conceptually simple, but not as simple as plain trees – Scalable (assuming you don’t go hog-wild with the countermeasures) – Reusable – Consider defender’s POV as well as attacker’s – Incorporates countermeasures and attacks on countermeasures • Cons – Simple signatures or single-point exploits – Weak or no explicit link between steps • How are they related? Ordering? 56

Requires/Provides Model • Templeton and Levitt, 2000 57

Single Exploits vs. Sequence • Single exploit – Short term goal – May or may not violate some part of the security policy – E. g. , a port scan • Sequence of single exploits (scenario) – Has an end goal in mind – Explicitly violates security policy – E. g. , port scan followed by buffer overflow followed by installation of back door … – Very dangerous 58

Generalized Sequences of Attacks • Port scan followed by buffer overflow followed by installation of back door is very specific • More general, recon followed by exploit followed by penetration – Exploit depends on knowledge gained by recon – Penetration depends on capability gained by exploit • Want to abstractly model attacks based on – the requirements of the abstract components, – the capabilities provided by the abstract components, and – the method of composing the components into complete attacks 59

Requires/Provides Model • To successfully launch an attack, certain properties must hold – These are the requires properties • After a successful attack, a new set of properties hold – These are the provides properties • The attack “goal” is a property that holds after a sequence of attack events 60

Example Attack Sequence • Kafka has rsh access on sartre • Spock wants to run code on sartre 1. Spock Do. Ses kafka with flood 2. Spock probes sartre for TCB seq num 3. Spock sends spoofed SYN packet (as kafka) 4. Sartre sends to kafka, which is blinded 5. Spock sends rsh packet to sartre 61

Connection Spoofing R/P • Requires: – – – “Trustor” running active service (Sartre) Trusted partner (pretend to be trusted partner) (kafka) Ability to prevent trusted partner from receiving Ability to probe trustor for TCB sequence number Ability to send a forged packet • Provides: – Ability to send data to trusted channel – Ability to have data remotely executed • These are general properties • Instantiate for rsh or other protocols 62

Similarity to Attack Trees • Goal: Get Sartre to execute commands from untrusted host Spock • Sub-goal: Get Sartre to believe trusted host Kafka is sending the commands – Must prevent ACK from Sartre from reaching Kafka – Must determine what sequence number Sartre would use, so Spock can use that in “response” to blocked ACK • But different from attack trees in specifying order 63

Creating Variant Attacks • Different events can cause the same effects • Different orderings of events can cause the same effects • Want to reason in terms of the effects of an event, not on the details of an event itself – E. g. , instead of SYN-flood, the attacker on Spock could have use a packet storm, ping-of-death, or even physically disabled the network cable to Kafka – Each of these would have had the same effect of blocking Kafka from receiving ACKs from Sartre 64

Concepts and Capabilities • Capabilities are the (generalized) information or situation required for an attack to proceed – E. g. , User login requires access, user name, password – System requires access to password validation database – Atomic elements of the model – Generalized capability is template for instantiations • Concepts map required capabilities to provided capabilities and instantiate capabilities • Attacks are defined as the composition of abstract concepts 65

Inherent Implication • Existence of a capability implies existence of another – E. g. , A prevented from sending a packet to B B is prevented from receiving a packet from A – B is prevented from receiving a packet from A B is prevented from sending reply packet back to A • Don’t depend on implication • Must explicitly state concepts that define each implication 66

Example Concept (abbreviated) Concept RSH_Connection_Spoofing requires Trusted_Partner: TP; Forged. Packet. Send: FPS; Prevent. Packet. Send: PPS; … with TP. service is RSH, PPS. host is TP. trusted, FPS. dst. host is TP. trustor, … end; 67

Example Concept (abbreviated)(cont. ) Concept RSH_Connection_Spoofing, continued provides push_channel: PSC; remote_execution: REX; with PSC. from <- FPS. true_src; PSC. to <- FPS. dst; PSC. using <- RSH; REX. from <- FPS. true_src; … end; 68

Power of Model • Ordering and relationship of attack steps implicit in that provides must precede requires – Compare to attack trees – Capabilities essentially form edges of R/P attack graph • Multiple events can provide equivalent capabilities • Attack scenarios can have many variants – instantiate different events/protocols that provide same capabilities • Exploits can be combined in new ways to create previously unexpected attacks – Just have to satisfy capabilities 69

Microsoft’s Software Security Properties Property Description Confidentiality Data is only available to the people intended to access it. Integrity Data and system resources are only changed in appropriate ways by appropriate people. Availability Systems are ready when needed and perform acceptably. Authentication The identity of users is established (or you’re willing to accept anonymous users). Authorization Users are explicitly allowed or denied access to resources. Nonrepudiation Users can’t perform an action and later deny performing it. 70

STRIDE • Acronym for categories of threats: Threat Spoofing Tampering Repudiation Information disclosure Denial of service Elevation of privilege Security Property at Risk Authentication Integrity Non-repudiation Confidentiality Availability Authorization 71

Meaning of Each Threat Class • Spoofing : Impersonating something or someone else • Tampering : Modifying data or code • Repudiation : Claiming to have not performed an action • Information Disclosure : Exposing information to someone not authorized to see it • Denial of Service : Deny or degrade service to users • Elevation of Privilege : Gain capabilities without proper authorization 72

STRIDE Steps • Decompose system into components – May need to recurse down to necessary level of detail • Analyze each component for susceptibility to each relevant type of threat • Develop countermeasures until no component has susceptibility • Is system secure? – Maybe, but probably not – Due to emergent properties of composition • Does this give higher assurance? – Yes, because flaw in one component affects entire system 73

Data Flow Diagram (DFD) • Used to graphically represent a system and its components • Standard set of elements: – – Data flows Data stores Processes Interactors • One more for threat modeling: – Trust boundaries 74

DFD Symbols Element Shape Description Process Any running computations or programs Interactor A user, service, or machine that interacts with the application and is external to it – either as a data producer or consumer Data Store Any data “at rest” on some form of storage (e. g. , files, DBs, registry keys, etc. ) Data Flow Any transfer of data from one element to another (via network, pipe, RPC, etc. ) Trust Boundary Border between “trusted” and “untrusted” elements 75

Relevant Threats for Elements Spoofing Interactors Process Data Store Flow x x Tampering x x x * Information disclosure x x x Denial of Service x x x Elevation of Privilege x Repudiation x x * Logs held in data stores are usually the mitigation against a repudiation threat. Data stores often come under attack to allow for a repudiation attack to work. 76

STRIDE Process • Create DFD of system – Represent all key components – Represent all data flows – Identify trust boundaries • Repeat, adding more details to the diagram if required • Recurse on each component as required 77

Example: First Cut Data store Useless details Data Sink! 78

Example: Second Try 3 data flows 79

Analysis: Data Flow 1 • Sales to Collection • Someone could tamper with Spoofing the data in transit • Someone could sniff the data Tampering • Someone could Do. S the collection Repudiation service Information disclosure Denial of Service Elevation of Privilege 80 Data Flow x x x

MS Threat Modeling Tool 2014 • Software for applying STRIDE model – Build DFD directly in program – Automatically finds STRIDE threats 81

Mitigate Threats • Tool has places to specify status of mitigation: – – Not Started Needs Investigation Not Applicable Mitigated • If you say Mitigated or Not Applicable, must enter Justification • Also can select priority (Low, Medium, High) – Used for the “bug bar” (ranking of threats by priority) – E. g. , see http: //msdn. microsoft. com/enus/library/windows/desktop/cc 307404. aspx 82

Controls to Mitigate Threats • Remove vulnerable feature • “Fix” with technology, e. g. : – Spoofing • Strong authentication – Tampering • Strong authorization (restrict modify access) – Repudiation • Digital signatures, timestamps – Information Disclosure • Encryption – Denial of Service • Packet filtering – Elevation of Privilege • Restrict admin privilege 83

Mitigation Choices in Reality • Redesign – Change the design to eliminate threats – E. g. , reduce elements that touch a trust boundary • Use standard mitigations – Firewalls, validated authentication systems, … • Use custom mitigations – If you are a gambling sort of person • Accept risk – If you think risk is low, or too expensive to mitigate 84

Summary • Consider the goals and mindset of an attacker. • Script kiddie, bottom up (opportunistic) and top down (APT or goal oriented) • Use system diagram and configuration management databases (software and hardware catalog) to exhaustively examine all vulnerable components. – All components are vulnerable • Minimize the implications of compromise for the most readily reached components. 85