Transcript ppt - Computer Secrity Classes

INF526:
Secure Systems Administration
Composition of Systems
And Protection Domains
Prof. Clifford Neuman
Lecture 3
25 January 2017
OHE100C
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.
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+1PM) on Tuesday January 24th)
• Submit as email to [email protected]
• 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 TightVNC 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 IPv6 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 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?
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/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
INF526:
Secure Systems Administration
Adversarial Security Planning
(advance slides)
Prof. Clifford Neuman
Lecture 4
1 February 2017
OHE100C
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 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.
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 DoSes 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;
ForgedPacketSend:
FPS;
PreventPacketSend: 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
Interactors Process Data Data
Store Flow
Spoofing
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 DoS the collectionRepudiation
service
Information
Data
Flow
x
x
disclosure
Denial of Service
Elevation of
Privilege
80
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/cc307404.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