INTRODUCTION TO NETWORK SECURITY
EN.600.424
Spring 2015
Lecture Notes
PRIMARY CLASS OBJECTIVE
•
Know how to engineer secure networked systems
• Understand core elements
• Understand what the bad guys are after
• Understand how the bad guys get it
• Understand why it’s hard to engineer secure systems
SECURITY ENGINEERING
•
Much of the lecture material comes from “Security Engineering” by Anderson
•
The book is broader than just network security
•
We will focus on those chapters most applicable to our more narrow domain
•
You are encouraged (not required) to read the whole book
WHAT IS SECURITY ENGINEERING?
•
As per Anderson,
• “[It] is about building systems to remain dependable in the face of …”
• Malice
• Error
• Mischance.
• “As a discipline, it focuses on the…”
• Tools
• Processes
• Methods
THE GOAL
•
Again, from Anderson
• For new systems:
• Design
• Implementation
• Testing
• For existing systems:
• Adapt them for increased security
• Adapt them as their environment evolves
THE PROBLEM
•
Most systems “have” security (whatever that means)
•
Why, then, do they fail?
•
Anderson again: “many systems fail because…”
• “…their designers protect the wrong things”
• “…or protect the right things but in the wrong way.”
ANDERSON’S FRAMEWORK
•
Good Security Engineering requires a combination of four things:
• Policy: What the system should achieve
• Mechanism: Ciphers, access controls, etc
• Assurance: The amount of reliance on any one component
• Incentive: The motivations of the actors involved
•
We will focus primarily on policy and mechanism with a smattering of the other two
ANDERSON’S DEFINITIONS
•
Be familiar with Anderson’s definitions for:
• System, principal, person, subject, identity, trust, etc.
• I will try to stick to his definitions more-or-less (ask if not sure)
•
However, we will use the following terms as used in most applied crypto literature
• Confidentiality – preventing the disclosure of information (e.g., encryption)
• Integrity – ensure that data cannot be undetectably altered (e.g., hashing)
• Authenticity – ensures that messages are from the correct principal (e.g., signatures)
• Non-repudiation – proves that the parties were involved in the transaction
PRACTICAL SECURITY ENGINEERING
•
Figure out what to protect and how
•
Threat modeling
•
Requirements engineering
•
Risk versus reward
•
Anderson:
• Most security is too tight already
• What is needed is refocusing
AVOID “SMALL THINK”
•
Security isn’t actually the end goal for most problems
• Most of the time in the corporate world, the end goal is “profit”
• Security that saves a buck but costs a fortune isn’t appropriate
INCENTIVES
•
Everybody should learn a little about Economic Game Theory
•
I recommend understanding “Prisoner’s Dilemma” at the very least
•
Understand the concepts of rational, irrational, payouts, choices, etc.
•
“Mechanism Design” – Creating a system that incentivizes cooperation
• Let’s talk about “Iterated Prisoner’s Dilemma”
•
In a security context
• Who are the people in your system?
• Are the incentives stacked for or against them?
• (See Anderson’s concept of “Moral Hazard”)
LEGAL PROTECTIONS
•
As Anderson discusses, sometimes it isn’t financially worth it to fix a vulnerability
•
Also of note, sometimes the legal (civil/criminal) protections are sufficient
• Anderson mentions banks that go after criminals with vigor
• You could add the recording industry going after file sharers
•
Sometimes, “tamper evident” is almost as effective as “tamper resistant”
•
(Note that this requires identifying the attacker and having legal teams in their
jurisdictions)
GRASP THE CONTEXT
•
SECURITY IS ABOUT CONTEXT (Repeat after me)
•
What does it mean when you say “system X is secure”?
• Secure against whom?
• Secure under what conditions?
• Are we even protecting what matters?!
•
Take voting security
• Who are the potential attackers?
• How does the context change if a nation decides to be the attacker?
PROTECT THE RIGHT THING
•
Key principle from “Avoid Small Think” and “Grasp the Context”
•
If you have to protect something, it’s not enough to solve some problem
•
See http://xkcd.com/538/
ADVERSARY EXAMPLES
•
Outsiders
• Individuals
• Loose groups
• Organized groups with resources
• Criminal
• Corporate
• Governmental
•
Insiders
• Individuals
• Colluding
THREAT MODEL EXAMPLE #1
•
Threat Model for a technical questions/answers website
•
Who are the attackers likely to be?
•
What do the attackers want?
•
What types of attacks do you have to protect against?
•
How bad is it if the attacker succeeds?
THREAT MODEL #2
•
Voting Security
• Let’s hypothetically assume Internet voting for the President of the United States
•
What kind of attackers do you have to worry about now? What kind of resources?
•
What about insiders?
• Can you identify all the insiders? (Hint: it’s larger than you think)
• Can you identify all the ways an insider might be compromised?
•
What kind of attacks do you have to prevent?
• (Hint: This is a lot more complicated than you might imagine)
SECURITY BEGINS WITH QUALITY
•
Many contemporary “Attacks” use bugs as the vector for delivering the malware
•
This is the most obvious example of how quality (reliability) affects security
• Anderson: “…investment in software quality [reduces] security problems, regardless
of whether security was a target of the quality program or not”
•
What good is a security policy if the software that enforces it is unreliable?
•
We’ll return to this in a special lecture in a couple of weeks
• Will incorporate software design, lessons from critical systems
SECURITY REQUIRES ADVERSARIAL DESIGN
•
Software engineers are artists at heart
• They love their software like a painter loves their paintings
• They are very hesitant to really try to break it
•
You have to design with the worst possible outcomes in mind
•
Starting from the worst outcomes, you can trace much of the security of the system
ATTACK TREES
•
Attack (or Threat) Trees are depictions of the exercise we just described
•
Start with the security failure, then trace backwards to previous causes iteratively
•
The idea is originally from Bruce Schneier (go read the original paper!)
•
Here’s an example
SECURITY GOALS
•
Eliminate security failures whenever possible
• For example, if you don’t have to store the data, DON’T STORE THE DATA
•
Minimize the parts of your system that must be secure (trusted)
•
Fail safely whenever possible
• For example, C++ exceptions are safer than a lot of C failures
•
Enforce sufficient logging and auditing to trace down failures after-the-fact
UNDERSTAND ATTACK SURFACES
•
The attack “surface” is the part of the system that can be attacked
•
Obviously, this depends on your threat model
• Insider attacks often deal with a much larger attack surface!
• Other examples:
• Open TCP ports
• System that is completely disconnected from the Internet
• Computer with a static IP on the public Internet
• How about mobile code (you should all care about this!)
• Why PySandbox Failed
REDUCING THE ATTACK SURFACE
•
This is an important part of Security
•
Example #1:
• Many companies have ultra-secure networks not connect to the Internet
•
Example #2:
• Computers with ports disabled
•
Similar to the principle of LEAST PRIVILEGE
•
May require working with requirements engineering for the whole product
• Are some features not that important?
• Losing a low-priority feature for eliminating a significant attack surface may be useful
UNDERSTANDING THE TARGETS
•
What will the “attacker” want?
•
Acquire?
• Steal information (eavesdropping or unauthorized access)
• System control (to use, for example, in a bot net?)
•
Disrupt?
• Denial of service
•
Corrupt?
• Send falsified or corrupted messages
IDENTIFYING TARGETS
•
Some targets are obvious:
• Hard drive (especially encrypted partitions…)
• Network channels
• Root access or privilege escalation
• Software vulnerabilities
•
The bigger problems are the not-so-obvious
• Clipboard, other places in RAM
• Network configuration files (e.g., change where to go for auto-updates)
• Misconfigured privileges
• Misconfigured software
SECURITY REQUIREMENTS
•
From Anderson:
• Threat model: attacks and failures that the system must handle
• Security policy model: concise statement of the system’s protection properties
• Security target:
• detailed description of the protection mechanisms a specific implementation
provides
• how these mechanisms relate to the control objectives
• forms the basis for testing and evaluation of a product
• Requirements engineering: developing the model/target with the system owner
SECURITY REQUIREMENTS ENGINEERING
•
This is the hardest part
•
It is also the most critical
•
It’s not just the technical problems, but also the bureaucratic blunders, etc.
•
It’s also ongoing
• The system will change
• The environment will change
• Unpredicted attacks will emerge
PARALLELIZE THE SECURITY ENGINEERING
•
Consider Anderson’s example of a class creating a security policy for a lottery
•
This is related to open system design
• Kerckhoffs's principle
• Security of open source projects
•
How will you apply this to PLAYGROUND?
MANAGING YOUR SOFTWARE TEAMS
•
Anderson discusses the trade-off between specializing and generalizing
• A key principle is the incentives and what he calls the “moral hazard”
• Another key principle is how the specialist interacts with the generalists
• Things “everyone” should know
• Tools that reduce/prevent bugs and classes of bugs
• Use good libraries (CANT DO THIS FOR PLAYGROND! <Evil Laugh>)
• Various “team management styles” that depend on the nature of the problem
• In your team, what role are you? What roles do your colleagues take?
• In your team, which role should take the lead to be the most successful?
•
Anderson also suggests standardizing styles. I also suggest it
THE CURRENT STATE OF SECURITY
•
It’s not good.
• CERT’s analysis of network security
•
Why is it so hard?
• The deck is stacked and the dice are loaded
• The Halting Problem is NOT our friend
• Development is feature driven
PHILOSOPHICAL: THE FUTURE?
•
Why shouldn’t development be feature driven?
• Why do we recommend that people use viewers instead of applications?
•
Why do we spend so much on security? How much more can be spent?
•
Are we really going to assume that compromised is the new normal?
•
What happens if this trend continues?