1. INF526: Secure Systems Administration
Policy Driven Administration
Principles of Protection
Generation of Security Requirements
Prof. Clifford Neuman
Lecture 2
18 January 2017
OHE100C

2. Course Identification
INF 526
Secure Systems Administration (4 units)
Website with Class Material
Class communication

3. IoT Home Inspector Challenge
The Federal Trade Commission (FTC) is hosting a prize competition that challenges the public to create a technical solution (“tool”) that consumers can use to guard against security vulnerabilities in software found on the Internet of Things (IoT) devices in their homes.
The tool would, at a minimum, help protect consumers from security vulnerabilities caused by out-of-date software. Contestants have the option of adding features, such as those that would address hard-coded, factory default or easy-to-guess passwords.
The prize for the competition is up to $25,000, with $3,000 available for each honorable mention winner(s). Winners will be announced on or about July 27, 2017.
The deadline for registering and submitting entries is May 22, 2017 at 12:00pm EDT. For full details, refer to Registration & Submission.

4. Pre-Initial Homework Assignment (due before class today)
Submit as to
System Structure for Home Network with IoT devices.
Enumerate the classes of data
Enumerate the classes of users
Identify the protection domains
Enumerate the systems (hardware)
Enumerate the systems (software components)
Discussion of submissions

5. Initial Homework Assignment (due by midnight (11:59+1PM) on Tuesday January 24th)
Submit as to
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.

6. Banking Your organization must: Access is needed
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 confirming transactions
All other interactions may be limited by information flow policies to internal machines.

7. Ungraded Lab Work for this week
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

8. Initial Reading Assignment (due before todays class)
(ANON) Anonymous. (2002). Maximum Linux Security: A Hackers Guide to Protecting Your Linux Server and Workstation. SAMS Publishing.
Chapters 1, 2, 3, 4
Added readings to follow the lecture (not due before)
Generally accepted Principles and Practices – NIST
Guidance in writing a security policy

9. Your Oganizations Security Policy
First step – Establish an Organization Security Policy
Generally accepted Principles and Practices – NIST
Guidance in writing a security policy
First question for security auditors
It will guide you in creating categories of data and user

10. Your Oganization’s Security Policy
First step – Establish an Organization Security Policy
Generally accepted Principles and Practices – NIST
Principles
Computer Security Supports the Mission of the Organization
Computer Security is an Integral Element of Sound Management
Computer Security Should Be Cost-Effective
Systems Owners Have Security Responsibilities Outside Their Own Organizations
Computer Security Responsibilities and Accountability Should Be Made Explicit .
Computer Security Requires a Comprehensive and Integrated Approach
Computer Security Should Be Periodically Reassessed
Computer Security is Constrained by Societal Factors

11. Your Oganization’s Security Policy
Guidance in writing a security policy
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.

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

13. Information Access Access to each class of data Domain boundaries
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

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

15. Points of Policy
By Axiomatics - Axiomatics, CC BY 3.0, 16

16. Network Administration
Creation of network protection domains
Firewalls
VLANs
VPNs for access
Ipsec
Define required characteristics
Where is encryption required
This is policy and administrations

17. Personnel Security
Requirements on credentials and vetting processes for employees with access to different domains.
Relates to identity management
More as a precursor
IM about who the user is, PS about vetting and physical access and issuance of ID’s. 16

18. Physical Security
Virtual containment of data to domains is useless if access to protected machines can be achieved by failures of physical security. Define controls on placement of hardware and protection of cables, etc. 16

19. Monitoring and Audit
This is how you will know that you have been attacked.
It is critical to consider these technologies when designing your deployment.
The monitoring function is part of administrations.
Responding to alerts
False positive vs false negatives
Volume of alerts and what is of interest. 16

20. Vendor Requirements
Concern with supply chain subversion, and physical access by vendors on site.
Apply personnel security constraints to vendors.
Restrict access by vendors and visitors. 16

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

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

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

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

25. Containment Technologies
System Containment
Encryption Based
Guards
Object Encryption

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

27. Controlling Access to Data by 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?

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

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

30. Host Administration Guidance
Create multiple protection domains
Don’t run anything as root (or as little as possible)
Configure access to resources carefully

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

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

33. INF526: Secure Systems Administration
Adversarial Security Planning
Prof. Clifford Neuman
Lecture 4
1 February 2017
OHE100C

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

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

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

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

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

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

40. 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 (Foundations of Attack Trees [ICISC’05],

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

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

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

44. Attack Trees, Pros and Cons
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?

45. Attack-Defense Trees
Introduced by Kordy et al. (Foundations of Attack–Defense Trees [FAST’10],
Includes countermeasures, so can show attacks on countermeasures

46. Attack-Only Tree Example

47. Attack-Defense Tree Example

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

49. Requires/Provides Model
Templeton and Levitt, 2000

50. Single Exploits vs. Sequence
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

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

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

53. Example Attack Sequence
Kafka has rsh access on sartre
Spock wants to run code on sartre
Spock DoSes kafka with flood
Spock probes sartre for TCB seq num
Spock sends spoofed SYN packet (as kafka)
Sartre sends to kafka, which is blinded
Spock sends rsh packet to sartre

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

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

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

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

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

59. Example Concept (abbreviated)
Concept RSH_Connection_Spoofing requires Trusted_Partner: TP; ForgedPacketSend: FPS; PreventPacketSend: PPS; … with TP.service is RSH, PPS.host is TP.trusted, FPS.dst.host is TP.trustor, end;

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

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

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

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

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

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

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

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

68. Relevant Threats for Elements
Interactors
Process
Data Store
Data Flow
Spoofing x
Tampering
Repudiation *
Information disclosure
Denial of Service
Elevation of Privilege
* 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.

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

70. Example: First Cut
Data store
Useless details
Data Sink!

71. Example: Second Try
3 data flows

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

73. MS Threat Modeling Tool 2014
Software for applying STRIDE model
Build DFD directly in program
Automatically finds STRIDE threats

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

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

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

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