600.436: High-Assurance Systems

David M. Chizmadia, Promia, Inc., dchizmadia@srl.cs.jhu.edu

Jonathan S. Shapiro, Johns Hopkins University, shap@srl.cs.jhu.edu

Course website: http://srl.cs.jhu.edu/courses/cs436.html

Time/Place: M 4-5, Tu 3-5, NEB 12

Required Texts:

Anderson: Security Engineering

DeMarco & Lister: Peopleware (2^nd Ed.)

ISO: Common Criteria, Common Evaluation Methodology

Papers as distributed in class

Recommended (Strongly)

Schneier: Secrets & Lies

Course Plan

Weeks 1-3: Groundwork for Assurance

Weeks 4-12:

Assurance Track: Learning how assurance works (David)

Practice: Learning how EROS (supposedly) works (Jonathan)

Weeks 13-15: Wrap-up and Integration

Grading Policy

Class participation (15%)

Reading should be done before the relevant class session.

Homework: (50%)

Producing certain documentation artifacts required by CC/CEM

Analyzing the current documentation and features provided by the EROS system (code reading)

Performing certain parts of the evaluation process using these documents and artifacts.

Except as noted in assignments, homework is to be done individually.

Final exam (35%)

May replace this with a manageable final project.

Late-Breaking Book Info

The Schneier book is going to paperback, and is unavailable until October.

While it is not required, it is strongly recommended. It’s $20 in hardback and likely to be less in paper.

Since the bookstore cannot get it, please order through Amazon or such.

Caveats

This is a new, experimental course

We literally are making it up as we go along!

David:

Has done evaluations in two countries under three standards

Project lead and primary author: Guide to writing the Security Features Users Guide (part of the rainbow series)

Technical Editor for the Federal Criteria

Current member of CORBA Security standards committee

Jonathan:

Has designed and built an allegedly secure system: EROS

Has shipped three “set new bar” products grossing > $250M (lots of production reality to check against)

These delivered on time

We both:

Detest process qua process

Understand some of what works in practice

Informal Definition: “Assurance”

Assurance is the process by which one obtains confidence in the security that a software system will enforce when operated correctly.

This includes the policies enforced, the degree of confidence in the enforcement, and an assessment of the appropriateness of those policies for the context in which the system will be used.

Reasons for Assurance

The purpose of assurance is to establish confidence that you can protect things of value.

Many types of value:

Protect because you think valuable

Protect because your customer thinks valuable

Protect to meet legal requirements (HIPPA, EU Privacy, DMCA)

Protect because of contract requirements

Each of these introduces different requirements, different types of exposure, and different “remedies” for failure.

Protection is a cost/benefit tradeoff

There is no such thing as perfect protection; only reasonable dilligence.

Comments on Assurance Process

Assurance process is important, because it will shortly define accepted professional standards of practice, and therefore liability

Professional standards happen with you or to you.

Click-wrap will lead to software liability

No more: “if it breaks, you get to keep both pieces” licenses!

Process is never a substitute for competence

We don’t have a science here yet

Guideline, not requirement

Problem:

No team of sufficient size to satisfy the nominal documentation requirements for a high assurance system has ever succeeded in producing such a system under any standard using the recommended process – all successful efforts to date have built the evidence post hoc.

The Basic Questions of Assurance

How should “secure” be defined?

How can a user, customer, or third party go about evaluating a vendor security claim?

What confidence does the user or customer have that it is true (or false)?

On what can/should such confidence be founded?

Basic Questions of Assurance (Again)

What are the (security) requirements?

How can satisfaction of these requirements be tested?

How to ensure appropriateness and comprehensiveness of the test process?

What is the evidence that the testing was competently and thoroughly done?

About the Requirements

Some of the requirements are testable:

“The system shall enforce a clearly defined authentication policy.”

Some are contextual:

“The system may assume that physical access to the machine is restricted by external (human) controls.”

Some may be process-oriented:

“No code change shall be committed to the source base until it has been examined and approved by someone other than the developer.”

Caveat About “Security”

Security is filled with terms that are not rigorously defined.

This is easy to overlook – people assume common meanings that do not really exist.

As a result, these terms are undefined in real practice.

Usually, this signals a failure of rigor in the threat model.

Defining these terms is inherently context dependent.

For example:

Secure from whom, and under what assumptions, and in what context, and at what cost to the attacker?

What exactly is to be secured? Information? Access? Resources?

Process, not Technology!

Security is defined relative to a context and a set of assumptions.

Both context and assumptions change frequently

SECURITY IS A PROCESS,

NOT A SOLUTION!

The statement “X is secure” is at best incomplete, and is more commonly just wrong.

Example 1: PGP

A reasonably careful claim:

“PGPfile encrypts, decrypts, signs and verifies files for either email or secure storage on your computer...” – www.pgp.com, September 3, 2001

Assumptions:

Your machine is not otherwise compromised

Actions to Compromise:

Penetrate the machine

Run standard password cracker against the private key

Better still – install a Trojan horse in front of the password capture dialog box…

Example 2: SSL

Claim:

“SSL secures communications between applications and services...”

Assumptions (and confidences):

Client is not otherwise compromised (0%)

Server is not otherwise compromised (15%)

Server is properly installed (< 30% are)

No “back door” into the server (< 2%)

Certificate authority (CA) has not been compromised (99%)

CA issued crypto keys to the right party (~80%)

Server handles authentication correctly (< 15%)

Server does not expose sensitive information when hacked (0%)

DNS infrastructure intact (85% and falling)

Mother’s maiden name is not in a genealogy database somewhere. (0%)

Actions to Compromise:

Hack either machine…

Example 3: Windows™

Claim: None

Assumptions (confidences):

All code is trusted code (0%)

Attacker has sub-20 I.Q. (0%)

Actions to Compromise:

Run the installer

[ This is done by the user, which saves the potential hacker a great deal of time. ]

Turn the machine on.

Well, at least the claim is right…

Definition of Security (Classical)

Security is usually divided into:

Confidentiality: preventing disclosure to unauthorized users

Integrity: Ensuring that no one can tamper with good information.

Availability: Ensure that access to information can be promptly obtained by authorized users.

Informally, people generally use security to mean confidentiality.

Note the context-dependent value judgments!

Security Policies

Provide definitions for terms like “authorized”, “prompt”, “good information” and “disclosure”

Preferably in a way that can be automated

This is a critical failing of most computer security policies

In this course, we will restrict our scope of attention to computer security policies.

We will assume, for example, that physical access to sensitive portions of the machine has already been restricted by external mechanisms.

We will assume that authorized users are ``well behaved.’’ This is a questionable assumption, and sometimes inappropriate.

Limitations on Security Policies

If it cannot be enforced, it’s a fantasy, not a policy!

Unenforceable:

Prevent disclosure of sensitive information to unauthorized users

(Possibly) Enforceable:

Ensure that all information flows only to (or from) authorized programs.

Ensure that all disclosure of information to entities outside the control of the system (including users and their agents) is via trusted software.

Ensure that when information crosses a multiplexed protection boundary, it does so via trusted software

Where “trusted software” means: “has been verified to comply with the applicable provisions of the security policy.”

Positive vs. Negative Policies:

Compare:

Prevent disclosure to unauthorized users

Ensure that disclosure occurs only to authorized users, and only in a fashion consistent with the security policy.

The second can be tested:

Show that there exists no communication path to any unauthorized user agent.

Show that the last link in each remaining path is trusted software.

Verify that each piece of trusted software enforces the appropriate security policy.

The first cannot!

Policy Realization

Just as a policy is stated in context, implementations are built under assumptions

These assumptions are:

Administrative (e.g. logins will not be given out at random)

Environmental (e.g. physical access to machine is restricted)

Threat model: the attack scenarios you anticipated

As opposed to the nuclear attack that you didn’t prepare for

Threat Models are not Perfect

1986: 5ESS: 5mins downtime in 25 years

Including routine maintenance

Included backup batteries, power fail detection, and “scream for help” facilities for unattended (switching bunker) operation.

Mother’s Day, 1988, Hinsdale Illinois

Switching center fire disrupts service to 35,000 customers

This was a triple failure: ambiguous alarm design, simultaneous low probability alarms (power, fire), failure of alarm circuits to reset correctly.

Threat model was (needless to say) revised…

SECURITY IS A PROCESS,

NOT A SOLUTION!

Threat Modeling and Risk Analysis

Identify the possible compromises (threats)

Identify the scope of the analysis

What is “outside the system”

What assumptions are made about the environment in which the system is operated?

For each, scope out the perpetrators, the likelihood, and the expense if this threat becomes real.

Based on this, perform a prioritization of risks so that limited development $$$ maximize cost/benefit.

Threat Enumeration Techniques

Fault Trees:

Enumerate the undesired behavior

For each, enumerate the possible causes (recursively)

FMEA (Failure Modes and Effect Analysis)

Enumerate all the individual things that could go wrong

Recursively work upwards to understand the effects on the mission

Risk likelihood depends on the objectives of the attacker (Fame? Money? Publicity?)

None of the currently known techniques are particular rigorous when applied to software.

The Problem of “Systems”

Systems provide a tool for dealing with complexity by inducing layered “scopes” (components) on the problem structure.

This component structure is defined by the designed behavior of the respective pieces.

Underlying assumption: the components are not hostile.

When we combine components in software, these scopes are not preserved (no containment boundaries)

Failure propagation therefore does not observe the architected component structure.

Neither does hostile behavior

Current language runtimes exacerbate the problem.

Understanding failures is hard in mechanical systems, but software systems have many more (and more highly interdependent) states.

To the developer, a critical need is to limit the scope of each failure by making these states more independent.

Focus for This Course

Current state of the art in assurance incorporates reasonable front-end (specification) and back-end (validation) mechanisms and processes

There are large holes: CC makes no provision for networking!

In this course, we will focus on assurance as seen by the developer.

This is a large hole in the current practices and standards

No texts, few guidelines, no mature and established tools, few tools of any sort at all.

Most relevant work has been in conventional Q/A

Most of that is focused on post-hoc assurance and on development-time testing techniques

Developer’s Point of View

More and more software is components

No single context of use

No single policy context

Policies are global, but (successful) design is (hierarchically) decomposed

The overall security policy must be reduced to something can be locally applied and understood at each component.

There are too many levels of abstraction to remember at once.

This leads to a fundamental problem of “focus of attention.”


	David M. Chizmadia, Promia, Inc., dchizmadia@srl.cs.jhu.edu
	Jonathan S. Shapiro, Johns Hopkins University, shap@srl.cs.jhu.edu
	Course website: http://srl.cs.jhu.edu/courses/cs436.html
	Time/Place: M 4-5, Tu 3-5, NEB 12
	Required Texts:
		Anderson: Security Engineering
		DeMarco & Lister: Peopleware (2^nd Ed.)
		ISO: Common Criteria, Common Evaluation Methodology
		Papers as distributed in class
	Recommended (Strongly)
		Schneier: Secrets & Lies


	Weeks 1-3: Groundwork for Assurance
	Weeks 4-12:
		Assurance Track: Learning how assurance works (David)
		Practice: Learning how EROS (supposedly) works (Jonathan)
	Weeks 13-15: Wrap-up and Integration


	Class participation (15%)
		Reading should be done before the relevant class session.
	Homework: (50%)
		Producing certain documentation artifacts required by CC/CEM
		Analyzing the current documentation and features provided by the EROS system (code reading)
		Performing certain parts of the evaluation process using these documents and artifacts.
		Except as noted in assignments, homework is to be done individually.
	Final exam (35%)
		May replace this with a manageable final project.


	The Schneier book is going to paperback, and is unavailable until October.
	While it is not required, it is strongly recommended. It’s $20 in hardback and likely to be less in paper.
	Since the bookstore cannot get it, please order through Amazon or such.


	This is a new, experimental course
		We literally are making it up as we go along!
	David:
		Has done evaluations in two countries under three standards
		Project lead and primary author: Guide to writing the Security Features Users Guide (part of the rainbow series)
		Technical Editor for the Federal Criteria
		Current member of CORBA Security standards committee
	Jonathan:
		Has designed and built an allegedly secure system: EROS
		Has shipped three “set new bar” products grossing > $250M (lots of production reality to check against)
		These delivered on time
	We both:
		Detest process qua process
		Understand some of what works in practice


	Assurance is the process by which one obtains confidence in the security that a software system will enforce when operated correctly.
	This includes the policies enforced, the degree of confidence in the enforcement, and an assessment of the appropriateness of those policies for the context in which the system will be used.


	The purpose of assurance is to establish confidence that you can protect things of value.
	Many types of value:
		Protect because you think valuable
		Protect because your customer thinks valuable
		Protect to meet legal requirements (HIPPA, EU Privacy, DMCA)
		Protect because of contract requirements
	Each of these introduces different requirements, different types of exposure, and different “remedies” for failure.
	Protection is a cost/benefit tradeoff
		There is no such thing as perfect protection; only reasonable dilligence.


	Assurance process is important, because it will shortly define accepted professional standards of practice, and therefore liability
		Professional standards happen with you or to you.
		Click-wrap will lead to software liability
		No more: “if it breaks, you get to keep both pieces” licenses!
	Process is never a substitute for competence
		We don’t have a science here yet
		Guideline, not requirement
	Problem:
		No team of sufficient size to satisfy the nominal documentation requirements for a high assurance system has ever succeeded in producing such a system under any standard using the recommended process – all successful efforts to date have built the evidence post hoc.


	How should “secure” be defined?
	How can a user, customer, or third party go about evaluating a vendor security claim?
	What confidence does the user or customer have that it is true (or false)?
	On what can/should such confidence be founded?


	What are the (security) requirements?
	How can satisfaction of these requirements be tested?
	How to ensure appropriateness and comprehensiveness of the test process?
	What is the evidence that the testing was competently and thoroughly done?


	Some of the requirements are testable:
			“The system shall enforce a clearly defined authentication policy.”
	Some are contextual:
			“The system may assume that physical access to the machine is restricted by external (human) controls.”
	Some may be process-oriented:
			“No code change shall be committed to the source base until it has been examined and approved by someone other than the developer.”


	Security is filled with terms that are not rigorously defined.
		This is easy to overlook – people assume common meanings that do not really exist.
		As a result, these terms are undefined in real practice.
		Usually, this signals a failure of rigor in the threat model.
	Defining these terms is inherently context dependent.
	For example:
		Secure from whom, and under what assumptions, and in what context, and at what cost to the attacker?
		What exactly is to be secured? Information? Access? Resources?


	Security is defined relative to a context and a set of assumptions.
	Both context and assumptions change frequently
	SECURITY IS A PROCESS,
	NOT A SOLUTION!
	The statement “X is secure” is at best incomplete, and is more commonly just wrong.


	A reasonably careful claim:
		“PGPfile encrypts, decrypts, signs and verifies files for either email or secure storage on your computer...” – www.pgp.com, September 3, 2001
	Assumptions:
		Your machine is not otherwise compromised
	Actions to Compromise:
		Penetrate the machine
		Run standard password cracker against the private key
		Better still – install a Trojan horse in front of the password capture dialog box…


	Claim:
		“SSL secures communications between applications and services...”
	Assumptions (and confidences):
		Client is not otherwise compromised (0%)
		Server is not otherwise compromised (15%)
		Server is properly installed (< 30% are)
		No “back door” into the server (< 2%)
		Certificate authority (CA) has not been compromised (99%)
		CA issued crypto keys to the right party (~80%)
		Server handles authentication correctly (< 15%)
		Server does not expose sensitive information when hacked (0%)
		DNS infrastructure intact (85% and falling)
		Mother’s maiden name is not in a genealogy database somewhere. (0%)
	Actions to Compromise:
		Hack either machine…


Claim: None
Assumptions (confidences):
	All code is trusted code (0%)
	Attacker has sub-20 I.Q. (0%)
Actions to Compromise:
	Run the installer
		[ This is done by the user, which saves the potential hacker a great deal of time. ]
	Turn the machine on.
Well, at least the claim is right…


	Security is usually divided into:
		Confidentiality: preventing disclosure to unauthorized users
		Integrity: Ensuring that no one can tamper with good information.
		Availability: Ensure that access to information can be promptly obtained by authorized users.
	Informally, people generally use security to mean confidentiality.
	Note the context-dependent value judgments!


	Provide definitions for terms like “authorized”, “prompt”, “good information” and “disclosure”
	Preferably in a way that can be automated
		This is a critical failing of most computer security policies
	In this course, we will restrict our scope of attention to computer security policies.
		We will assume, for example, that physical access to sensitive portions of the machine has already been restricted by external mechanisms.
		We will assume that authorized users are ``well behaved.’’ This is a questionable assumption, and sometimes inappropriate.


	If it cannot be enforced, it’s a fantasy, not a policy!
	Unenforceable:
		Prevent disclosure of sensitive information to unauthorized users
	(Possibly) Enforceable:
		Ensure that all information flows only to (or from) authorized programs.
		Ensure that all disclosure of information to entities outside the control of the system (including users and their agents) is via trusted software.
		Ensure that when information crosses a multiplexed protection boundary, it does so via trusted software
		Where “trusted software” means: “has been verified to comply with the applicable provisions of the security policy.”


	Compare:
		Prevent disclosure to unauthorized users
		Ensure that disclosure occurs only to authorized users, and only in a fashion consistent with the security policy.
	The second can be tested:
		Show that there exists no communication path to any unauthorized user agent.
		Show that the last link in each remaining path is trusted software.
		Verify that each piece of trusted software enforces the appropriate security policy.
	The first cannot!


Just as a policy is stated in context, implementations are built under assumptions
These assumptions are:
	Administrative (e.g. logins will not be given out at random)
	Environmental (e.g. physical access to machine is restricted)
	Threat model: the attack scenarios you anticipated
		As opposed to the nuclear attack that you didn’t prepare for


	1986: 5ESS: 5mins downtime in 25 years
		Including routine maintenance
		Included backup batteries, power fail detection, and “scream for help” facilities for unattended (switching bunker) operation.
	Mother’s Day, 1988, Hinsdale Illinois
		Switching center fire disrupts service to 35,000 customers
		This was a triple failure: ambiguous alarm design, simultaneous low probability alarms (power, fire), failure of alarm circuits to reset correctly.
	Threat model was (needless to say) revised…
	SECURITY IS A PROCESS,
	NOT A SOLUTION!


	Identify the possible compromises (threats)
	Identify the scope of the analysis
		What is “outside the system”
		What assumptions are made about the environment in which the system is operated?
	For each, scope out the perpetrators, the likelihood, and the expense if this threat becomes real.
	Based on this, perform a prioritization of risks so that limited development $$$ maximize cost/benefit.


	Fault Trees:
		Enumerate the undesired behavior
		For each, enumerate the possible causes (recursively)
	FMEA (Failure Modes and Effect Analysis)
		Enumerate all the individual things that could go wrong
		Recursively work upwards to understand the effects on the mission
	Risk likelihood depends on the objectives of the attacker (Fame? Money? Publicity?)
	None of the currently known techniques are particular rigorous when applied to software.


	Systems provide a tool for dealing with complexity by inducing layered “scopes” (components) on the problem structure.
		This component structure is defined by the designed behavior of the respective pieces.
		Underlying assumption: the components are not hostile.
	When we combine components in software, these scopes are not preserved (no containment boundaries)
		Failure propagation therefore does not observe the architected component structure.
		Neither does hostile behavior
		Current language runtimes exacerbate the problem.
	Understanding failures is hard in mechanical systems, but software systems have many more (and more highly interdependent) states.
	To the developer, a critical need is to limit the scope of each failure by making these states more independent.


	Current state of the art in assurance incorporates reasonable front-end (specification) and back-end (validation) mechanisms and processes
		There are large holes: CC makes no provision for networking!
	In this course, we will focus on assurance as seen by the developer.
	This is a large hole in the current practices and standards
		No texts, few guidelines, no mature and established tools, few tools of any sort at all.
		Most relevant work has been in conventional Q/A
		Most of that is focused on post-hoc assurance and on development-time testing techniques


	More and more software is components
		No single context of use
		No single policy context
	Policies are global, but (successful) design is (hierarchically) decomposed
		The overall security policy must be reduced to something can be locally applied and understood at each component.
		There are too many levels of abstraction to remember at once.
		This leads to a fundamental problem of “focus of attention.”