foundations of software engineeringckaestne/17313/2018/...• human factors • often the weakest...
TRANSCRIPT
![Page 1: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/1.jpg)
Foundations ofSoftware Engineering
Lecture 11: Architecture & SecurityEunsuk Kang
![Page 2: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/2.jpg)
Leaning Goals• Understand key elements of security architecture
and analysis• Understand the major challenges of achieving
security in practice• Understand implications of architectural decisions
on security• Apply architectural principles & mechanisms to
build security into the design of a system
![Page 3: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/3.jpg)
Key Elements of Security• Security requirements (policies)• What needs to be protected?
• Threat model• What are capabilities & intents of an attacker?
• Attack surface• Which interfaces are exposed to an attacker?
• Protection mechanisms• How do we prevent an attacker from
compromising a security requirement?
![Page 4: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/4.jpg)
Security Analysis Question
• Security requirements• Threat model • Attack surface• Protection mechanisms
Does my system deploy sufficient protection mechanisms to establish its security requirements in the presence of an attacker who may attempt to compromise the system through its attack surface?
Having identified:
![Page 5: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/5.jpg)
What is security so hard?• Security requirements• Often implicit, conflicting views of security
• Threat model• Uncertain, evolving attacker model
• Attack surface• Multiple interfaces across system layers
• Protection mechanisms• Human factors; no foolproof mechanisms
![Page 6: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/6.jpg)
Examples of Security Failures
![Page 7: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/7.jpg)
Wrong Threat Model
![Page 8: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/8.jpg)
Wrong Threat Model
Maginot Line (1930s)Built by France to deter invasion; state-of-the-art engineeringGermans reformulated plans after WWI; cut across Belgium
![Page 9: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/9.jpg)
Unidentified Attack Surface
Château Gaillard (1200s, Normandy, literally “Strong Castle”)Impervious; under siege for 6 months by Phillip II (France)Conquered by entering through toilet chute
![Page 10: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/10.jpg)
Insufficient Protection Mechanism
Trojan Horse (Greeks vs Troy; 12th BC?)Disguised as a harmless trophy; hidden payload insideLesson: Treat all system inputs as potentially malicious
![Page 11: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/11.jpg)
Wrong Security Requirement
Hollywood Presbyterian ransomware attack (2016)Computer systems frozen; patients transferredAvailability of critical services, not data exposure
![Page 12: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/12.jpg)
Strategies for Secure Design• Security requirements• Elicitation & precise documentation
• Threat model • Principle of least privilege: Assume the worst
• Attack surface• Isolation: Separate the critical components
• Protection mechanisms• Defense in depth: Mitigate the weakest link
![Page 13: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/13.jpg)
Security Requirements
![Page 14: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/14.jpg)
Security Requirements• Confidentiality• Sensitive data accessible to authorized parties only
• Integrity• Sensitive data modifiable by authorized parties only
• Availability• Services made available when needed by clients
• (Non-repudiation)
“CIA triad”
![Page 15: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/15.jpg)
Machine vs Environment• Requirements are about phenomena in the environment• Machines (software) are built to act on shared
phenomena• Same for security; must start from the
environment!
![Page 16: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/16.jpg)
Example: Hospital
Patients
Doctors
Medical Records
AttackerMedical Device
Patient DB UI
Device HMI
SoftwareEnv
Critical Req. Patients must be given timely treatments by doctors based on their medical conditionsQ. What kind of security guarantee should software provide? Confidentiality? Integrity? Availability?
DB
Device controller
![Page 17: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/17.jpg)
Exercise: Graduate Admission System
![Page 18: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/18.jpg)
Exercise: Graduate Admission System
Q. What are key security requirements of the CMU graduate admission system?
![Page 19: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/19.jpg)
Architectural Design for Security
Slides adapted from: John Mitchell, Stanford
![Page 20: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/20.jpg)
Architectural Strategies for Security• Principle of Least Privilege• A component should be given the minimal
privileges needed to fulfill its functionality.• Goal: Minimize the impact of a compromised
component.• Isolation• Components should be able to interact with
each other no more than necessary.• Goal: Reduce the size of trusted computing
base (TCB)
![Page 21: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/21.jpg)
Trusted Computing Base (TCB)• Components responsible for establishing a
security requirement(s)• If any compromised => security violation• Conversely, a flaw in non-TCB component =>
security preserved• Design goal: Minimize TCB • Smaller TCB, less software to inspect & verify• In poor designs, TCB = entire system
![Page 22: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/22.jpg)
Monolithic Design
John Mitchell
Monolithic design
System
Network
User input
File system
Network
User device
File system
![Page 23: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/23.jpg)
Monolithic Design
John Mitchell
Monolithic design
System
Network
User input
File system
Network
User device
File system
![Page 24: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/24.jpg)
Monolithic Design
John Mitchell
Monolithic design
System
Network
User input
File system
Network
User display
File system
Flaw in any part of the system => Potential security failure!
![Page 25: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/25.jpg)
Component Design
John Mitchell
Component design
Network
User input
File system
Network
User display
File system
![Page 26: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/26.jpg)
Component Design
John Mitchell
Component design
Network
User input
File system
Network
User device
File system
![Page 27: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/27.jpg)
Component Design
John Mitchell
Component design
Network
User input
File system
Network
User device
File system
Flaw in one part of the system => Limited impact on security!
![Page 28: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/28.jpg)
Example: Mail Agent• Requirements• Receive & send email over external network• Place incoming email into local user inbox files
• Sendmail• Traditional Unix• Monolithic design• Historical source of many vulnerabilities
• Qmail• “Security-aware” mail agent• Compartmentalized design
![Page 29: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/29.jpg)
Qmail Design• Isolation based on OS process isolation• Separate modules run as separate “users” (UID)• Each user only has access to specific resources
(files, network sockets, …)• Least privilege • Minimal privileges for each UID• Mutually untrusting components• Only one “root” user (with all privileges)• In comparison, entire sendmail runs as root
![Page 30: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/30.jpg)
Qmail Design
John Mitchell
Isolation by Unix UIDsqmail-smtpd
qmail-localqmail-remote
qmail-lspawnqmail-rspawn
qmail-send
qmail-inject
qmail-queue
qmaild userqmailq
qmailsqmailr
qmailr
root
usersetuid user
qmailq – user who is allowed to read/write mail queue
For more details: “The Security Architecture of qmail”, Hafiz, Johnson, Afandi (2004)
![Page 31: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/31.jpg)
Qmail Design
John Mitchell
Isolation by Unix UIDsqmail-smtpd
qmail-localqmail-remote
qmail-lspawnqmail-rspawn
qmail-send
qmail-inject
qmail-queue
qmaild userqmailq
qmailsqmailr
qmailr
root
usersetuid user
qmailq – user who is allowed to read/write mail queue
Receives incoming external emailsEven if compromised, limited power(vs. sendmail: runs as root)
![Page 32: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/32.jpg)
John Mitchell
Isolation by Unix UIDsqmail-smtpd
qmail-localqmail-remote
qmail-lspawnqmail-rspawn
qmail-send
qmail-inject
qmail-queue
qmaild userqmailq
qmailsqmailr
qmailr
root
usersetuid user
qmailq – user who is allowed to read/write mail queue
Qmail Design
< 500 LOC (vs. ~67K LOC in sendmail)
![Page 33: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/33.jpg)
Another Example: Android• Isolation: Each app runs with its own UID & VM• Memory protection provided by OS• Inter-component communication: Permissions
checked by reference monitor• Least privilege • Application announces necessary permissions• User grants at install time
![Page 34: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/34.jpg)
John Mitchell
![Page 35: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/35.jpg)
John Mitchell
App
Isolation: different apps under different UIDs
Isolation: Different apps under different UIDs
![Page 36: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/36.jpg)
John Mitchell
Isolation: different apps under different UIDs
AppUID1 App UID2
Isolation: Different apps under different UIDs
![Page 37: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/37.jpg)
John Mitchell
Privileges set at install time
AppUID1, priv 1, priv 2, … App UID2, priv 3, priv 4, …
Privileges set at install time
![Page 38: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/38.jpg)
Summary: Architectural Design for Security• Monolithic vs compartmentalized design• Principle of Least Privilege• A component should be given the minimal
privileges needed to fulfill its functionality.• Isolation• Components should be able to interact with
each other no more than necessary.
![Page 39: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/39.jpg)
Questions during Architectural Design• What are the major components of my system?• What happens if a particular component is
compromised?• What is the TCB (i.e., components that are
responsible for a security requirement)?• Does any component have more privileges than
needed?• Is there sufficient isolation between critical & non-
critical components?
![Page 40: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/40.jpg)
Architectural Security Analysis
![Page 41: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/41.jpg)
Security Analysis Question
• Security requirements• Threat model • Attack surface• Protection mechanisms
Does my system deploy sufficient protection mechanisms to establish its security requirements in the presence of an attacker who may attempt to compromise the system through its attack surface?
Having identified:
![Page 42: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/42.jpg)
Case Study: Water Treatment Plant
Fully functional plant (SUTD, Singapore)Highly safety-critical! Failure may mean catastrophe
![Page 43: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/43.jpg)
Physical Architecture
Six different treatment stages (P1 – P6)Each stage monitored by sensors for water quality
![Page 44: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/44.jpg)
SCADA Human-Machine Interface
![Page 45: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/45.jpg)
SCADA Human-Machine Interface
![Page 46: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/46.jpg)
Industrial Control System (ICS)
Physical Processes: Water tanks, pumps, valvesController: SCADA issues various actuator commands based on sensor readingse.g., “Turn off pump to stop flow if tank level too high”
Controller
Actuator
PhysicalProcess
Sensor
M
![Page 47: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/47.jpg)
Safety Monitor
Safety method in traditional ICS: Expect random failures in sensors & actuatorsMonitor for irregular behavior & alert operatore.g., ”If water is flowing into tank, its level should rise”
Controller
Actuator
PhysicalProcess
Sensor
M
![Page 48: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/48.jpg)
Safety vs Security
Traditional ICS retrofitted with modern network technologyDifferent failure models in security!e.g., multiple sensors compromised at a time (not random)Drop/inject/modify packets, bypass detection by monitor
Controller
Actuator
PhysicalProcess
Sensor
M
A
![Page 49: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/49.jpg)
Ingredients of Security Analysis• Security requirement• Integrity: Information presented to the operator
accurately reflects the status of the plant. • Threat model• Has access to the building; intent to physically
damage the plant to interrupt its operations• Attack surface• Wireless network; open to eavesdrop & packet
injection• Protection mechanisms• Safety monitor to detect unusual water
properties & tank levels
![Page 50: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/50.jpg)
Security Analysis
Does the safety monitor (protection mechanism) ensure accurate transmission of the plant status to the operator (integrity requirement) even when an intruder (threat) attempts to sabotage the plant through the wireless network (attack surface)?
![Page 51: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/51.jpg)
Automating Security Analysis
SystemModel
AnalysisEngine
SecurityReq
AttackerModel
Attack Scenarios Testbed
AttackConfirmed
Invalid
Build formal models of system & attacker (e.g., state machines)Specify security req. using a formal notation (e.g., temporal logic) Analyzer exhaustively explores all possible sequences of attacker actions (model checking)
Risk: But what if the models aren’t accurate?
![Page 52: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/52.jpg)
Example Attack Scenario
![Page 53: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/53.jpg)
Example Attack Scenario
![Page 54: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/54.jpg)
Example Attack Scenario
![Page 55: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/55.jpg)
Example Attack Scenario
t = actual sensor readings; t’ = readings seen by the monitor
![Page 56: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/56.jpg)
Example Attack Scenario
![Page 57: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/57.jpg)
Example Attack Scenario
![Page 58: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/58.jpg)
Example Attack Scenario
Monitor believes everything is OK!
![Page 59: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/59.jpg)
Example Attack Scenario
![Page 60: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/60.jpg)
Example Attack Scenario
Water level high: Flow must be stoppedBut monitor fails to act, since it believes plant status is OK
![Page 61: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/61.jpg)
Example Attack Scenario
![Page 62: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/62.jpg)
Lessons• New environment, new threats• Legacy ICS: Isolated, mostly physical failures• Modern cyber-physical system (CPS): Connected to
the web, diverse threat models (e.g., Stuxnet)• Traditional safety methods are insufficient!• Ideally, redesign the system with security as a goal
(but difficult to do in general)• Analysis• Recent development in formal techniques for
automated analysis & attack generation• But must still get the system & threat models right!
![Page 63: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/63.jpg)
What I haven’t talked about today• Protection mechanisms• Access control, capability-based models• Information flow control
• Human factors• Often the weakest link in the design!• Include users & operators as part of
requirements elicitation & environment model• Clearly define user roles & their privileges• Treat all user inputs as potentially malicious
![Page 64: Foundations of Software Engineeringckaestne/17313/2018/...• Human factors • Often the weakest link in the design! • Include users & operators as part of requirements elicitation](https://reader034.vdocuments.mx/reader034/viewer/2022042307/5ed2f3f53e92a05e0d15d5f2/html5/thumbnails/64.jpg)
Summary: Strategies for Secure Design • Security requirements• Elicitation & precise documentation
• Threat model • Principle of least privilege: Assume the worst
• Attack surface• Isolation: Separate the critical components
• Protection mechanisms• Defense in depth: Mitigate the weakest link