Chapter 14 Resilience
14.1 Cybersecurity 
14.2 Sociotechnical resilience 
14.3 Resilient systems design

Resilience Engineering
	Being able to continue even with disruptions
	(errors, attacks, failures)

Some services are critical
 Some events are disruptive
Resilience is a judgement

Assumes failures WILL occur
Be flexible and adaptable

Desired:
Want to be sure system does not fail
Limit cost of failure
Recover from failure
Focus more on external events/attacks

Recognition (ideally before failure occurs)
Resistance (detect early, strategies to reduce damage/failure)
Recovery
Reinstatement

Resilience cannot be programmed in
Need flexibility and adaptability
(increased costs)
(How much does this investment help?)
Reluctance to invest in resilience

14.1
Be wary of:
Organizational ignorance of importance
(poor design, lax security, carelessness. Inappropriate tradeoffs)
Purchase systems, browsers, operating systems,…
Layered protection
(increased security can decrease performance)
Redundancy and diversity

Assets
Threats
Attacks

Confidentiality (peek)
Integrity (damage)
Availability (denial of service)

Minimize shared storage
Multi-stage diverse authentication
Over provision servers (excess capacity)

Stages
	Asset classification
	Threat identification
	Threat recognition
	Threat resistance
	Asset recovery
	(have a cyber-resilience plan)

Resilience and security can conflict
	Emergency mode
	(track what is done and by whom)

14.2 
Sociotechnical resilience
	Not just hardware and software
	Humans and business processes
	Don’t have too rigid processes
	People are creative in a crisis

Ability to respond
Ability to monitor
Ability to anticipate
Ability to learn from experience

Human error
	Is the person to blame?
	Include safeguards
	Find out why problem was not stopped
	Conflict alert: collision
	Formalize recording
	Collaborative checking

Strategy:
	Reduce the probability of a (bad) external event
	Train, monitor workload, reduce permissions
	Increase (diverse) defensive layers
	Minimize bugs

Operational and management processes
	Most systems do not have trained operators (users)
	System users can be unpredictable
	Go for flexibility
	Automated systems can go wrong
	Problem solving needs collaboration
	(need to know can reduce resilience)

14.3
Resilient system design
	Identify critical
	Design to support 	recognition, resistance, recovery, reinstatement
Survivable systems analysis
	System understanding
	Critical service identification
	Attack simulation
	Survivability analysis
Identify resilience requirements
Plan to reinstate
Identify what can be compromised
Recover services quickly

What quality must be maintained?
How can services be protected?

TEST

might have to duplicate system for testing