1. September 2023
Security-by-Design and -Default
Mehdi Tarrit Mirakhorli
University of Hawaiʻi at Mānoa
mehdi23@hawaii.edu
1
Laboratory of Software Design
and Productivity

2. Standing on the
shoulders of giants
Orion was the son of the sea-god Poseidon and Euryale,
daughter of Minos, King of island Crete. Orion could walk on the
waves because of his father; Once he walked to the island of
Chios where he got drunk and made troubles. As a punishment,
the ruler of the island blinded Orion and drove him away.
Orion stumbled to Lemnos where Hephaestus—the smith-god—
had his forge. Hephaestus told his servant, Cedalion, to guide
Orion to the uttermost East where the Sun, healed him; Orion
carried Cedalion around on his shoulders to act as the giant's
eyes.
Credit: METROPOLITAN MUSEUM OF ART, FLETCHER FUND, 1924 (24.45.1)
2

3. Standing on the
shoulders of giants
If I have seen further it is by standing on the shoulders of
Giants.
- Isaac Newton
Credit: METROPOLITAN MUSEUM OF ART, FLETCHER FUND, 1924 (24.45.1)
3
We use the understanding gained by major
thinkers who have gone before in order to
make intellectual progress.

4. On whose
Shoulders We
Stand to Solve
Software Security
Crisis?
4

5. NY Times Article: April 10, 1981
“The space shuttle Columbia will be ruled by majority
vote - not of its astronauts and ground crews but of
its computers.”
On whose
Shoulders We
Stand to Solve
Software Security
Crisis?
5
Learning from the past software crisis!

6. 6
We have learned so much from
building certified and regulated
software.
We have done a lot better in safety
critical software compared to
secure software
On whose
Shoulders We
Stand to Solve
Software Security
Crisis?

7. I will discuss some of my work in Software Security that
leveraged the lessons learned from Regulated, Certified,
and Transparent domains to enhance software security.
7
On whose Shoulders We Stand to
Solve Software Security Crisis?

8. 8
Pricing Security: Economics of Software Security
Cost of
Identifying and
Correcting
Defects, 1997
We did shift-left in
1997 to address
software reliability

9. 9
0 x
5 x
10 x
15 x
20 x
25 x
30 x
Production,
PostRelease
System,
Acceptance
Testing
Integration,
Component
Testing
Coding
SW Design
$14000
$139 Secure by Design: Shift Left
Secure by design shifts the main focus of software
assurance from finding security bugs to identifying
flaws and weaknesses in the design.
Pricing Security: Economics of Software Security
$ Penetration testing
$$ Bug-bounty testing
$$ Firefighting fixes
$$$ Downtime
$$$ Patching without interrupts
$$$ DAST/SAST/FUZZ
$ Code Review
…..
Cost of Identifying
and Correcting
Security Defects,
2023
https://www.darkreading.com/perimeter/the-economics-of-software-security-what-car-makers-can-teach-enterprises

10. Software Design: A Working Definition
Master
Slave
HB
Decision # 1:
Use Master-slave Architectural
Style where slave processes are
replicated
Decision # 2:
Checkpoint updated data, and
bundle replicas (send every 2
seconds) – in order to meet
performance goals.
Decision # 3:
Use heartbeat tactic to monitor
availability of task trackers and data
nodes. Heartbeat must beat every
.25 seconds to balance availability
and performance.
Decision # 4:
Use proxy handles failure pattern to
shield clients from failures, and to
support fault tolerance (i.e. service
continues in the face of transient
failure.
Requirements# 1:
highly available system, where
hardware failure can be the norm
rather than the exception
Decision # 1:
Mutual Authentication with
Kerberos RPC (SASL/GSSAPI) on RPC
connections
Decision # 2:
Maintain an Audit Trail
Decision # 3:
Data Encryption on RPC
Data Encryption on Block data
transfer
Data Encryption on HTTP
Decision # 4:
Secure DataNode: DataNodes must
authenticate themselves
Requirements# 2:
Provide secure services for the
client
More Decisions:
A non-trivial architecture is likely
to be composed of hundreds, if
not thousands of architectural
decisions.
10

11. Software Design: A Working Definition
Master
Slave
HB
Decision # 1:
Use Master-slave Architectural
Style where slave processes are
replicated
Decision # 2:
Checkpoint updated data, and
bundle replicas (send every 2
seconds) – in order to meet
performance goals.
Decision # 3:
Use heartbeat tactic to monitor
availability of task trackers and data
nodes. Heartbeat must beat every
.25 seconds to balance availability
and performance.
Decision # 4:
Use proxy handles failure pattern to
shield clients from failures, and to
support fault tolerance (i.e. service
continues in the face of transient
failure.
Requirements# 1:
highly available system, where
hardware failure can be the norm
rather than the exception
Decision # 1:
Mutual Authentication with
Kerberos RPC (SASL/GSSAPI) on RPC
connections
Decision # 2:
Maintain an Audit Trail
Decision # 3:
Data Encryption on RPC
Data Encryption on Block data
transfer
Data Encryption on HTTP
Decision # 4:
Secure DataNode: DataNodes must
authenticate themselves
Requirements# 2:
Provide secure services for the
client
More Decisions:
A non-trivial architecture is likely
to be composed of hundreds, if
not thousands of architectural
decisions.
Decision # 1:
Use GN&C model, separate each of
these domains and run them on
different threads..
More Decisions:
A non-trivial architecture is likely
to be composed of hundreds, if
not thousands of architectural
decisions.
Decision # 29:
Separate data busses should be used
for data or command operations.
Each buss should utilize a different
scheduling mechanisms.
Decision # 101:
Utilize heartbeat, voting and
simulation to detect faults. FDIR
module responsible for all these.
Decision # 1:
Keep primaries together, and
replicas together at all times to
meet redundancy goals.
Decision # 2:
Checkpoint updated data, and
bundle replicas (send every 2
seconds) – in order to meet
performance goals.
Decision # 3:
Use heartbeat tactic to monitor
availability of track manager
primaries and secondaries.
Heartbeat must beat every .25
seconds to balance availability and
performance.
Decision # 3:
Use heartbeat tactic to monitor
availability of track manager
primaries and secondaries.
Heartbeat must beat every .25
seconds to balance availability and
performance.
Decision # 32:
GN&C flight system must use active
redundancy with graceful
degradation to achieve maximum
availability.
More Decisions:
A non-trivial architecture is likely
to be composed of hundreds, if
not thousands of architectural
decisions.
More Decisions:
A non-trivial architecture is likely
to be composed of hundreds, if
not thousands of architectural
decisions.
Decision # 91:
Utilize heartbeat, voting and
simulation to detect faults. FDIR
module responsible for all these.
Decision # 1:
Use thread pooling to execute
recurrent mission operations.
Decision # 21:
Active redundancy is implemented
to achieve minimize mean time
between failures.
Decision # 19:
Separation of concerns: Each tasks
must run as a separate process on a
separate processor.
Decision # 52:
Platform Diversity plus N-Version
programming must be used to
maximize the reliability.
Decision # 4:
Use proxy handles failure pattern to
shield clients from failures, and to
support fault tolerance (i.e. service
continues in the face of transient
failure.
Decision # 151:
Utilize heartbeat, voting and
simulation to detect faults. FDIR
module responsible for all these.
Decision # 81:
Voting mechanism is used to recover
from failure of any of the sensors.
Decision # 101:
Utilize heartbeat, voting and
simulation to detect faults. FDIR
module responsible for all these.
Decision # 113:
Semantic based scheduling and task
sequencer is used to provide real-
time performance.
More Decisions:
A non-trivial architecture is likely
to be composed of hundreds, if
not thousands of architectural
decisions.
Decision # 3:
Use heartbeat tactic to monitor
availability of track manager
primaries and secondaries.
Heartbeat must beat every .25
seconds to balance availability and
performance.
Decision # 121:
Keep primaries together, and
replicas together at all times to
meet redundancy goals.
Decision # 3:
Use heartbeat tactic to monitor
availability of track manager
primaries and secondaries.
Heartbeat must beat every .25
seconds to balance availability and
performance.
Decision # 66:
Check pointing is utilized to recover
non-mission critical operations.
11

12. Building Blocks of Secure by Design and Default
In Secure by Design, architecture is the main step to secure a system, it starts
from identifying misuse and abuse cases, performing threat modeling and
then making appropriate design decisions to mitigate threats.
Detect
Attacks
Resist
Attacks
Prevent
Attacks
React to
Attacks
Security as
Default
Verify Message Integrity
Detect Intrusion
Detect Service Denial
Anomaly Detection
Detect Message Delay
Exception detection
Runtime Attestation
Sanity checking
Identify Actors
Validate Inputs
Manage User Sessions
Authenticate Actors
Authorize Actors
Limit Access
Limit Exposure
Encrypt Data
Separate entities
Change default settings
Removal from service
Predictive model
Increase competence set
Transactions
Exception prevention
Process Monitor
Lock Computer
Revoke access
Inform actors
Audit
Use software redundancy
Rollback (Checkpointing)
Reconfiguration
Shadow
State resynchronization
Escalating restart
Degradation
Roll Forward
Recover from
Attacks
Eliminate default passwords
Multifactor Authentication (MFA)
Single sign-on (SSO)
Secure Logging
Software Authorization Profile
Track& reduce “hardening guide” siz
Usable Security
Secure by Design and Default Tactics

13. What are Common
Design Weaknesses?
13
For other quality attributes such as
performance, availability, maintainability we
know all patterns and anti-patterns, but for
security we had limited resources on these.
J. C. S. Santos, K. Tarrit and M. Mirakhorli, "A Catalog of Security Architecture Weaknesses," 2017 IEEE International Conference on
Software Architecture, Gothenburg, Sweden, 2017, pp. 220-223, doi: 10.1109/ICSAW.2017.25.

14. What are Common
Design Weaknesses? 224 security
issues rooted in
the software
architecture:
Empirical Studies:
• Let’s learn from vulnerabilities in real
systems.
• Study focused on top 20 vulnerable
systems.
Existing Knowledge-Bases
• DHS/MITRE CWE Collection
National Vulnerability Database
• NIST/DHS database of known
vulnerabilities.
OMISSION
Decisions that were never
made
COMMISSION
Poor design decisions
REALIZATION
Incorrect Implementation
Ex: Password stored
without encryption
Server
Attacker
Client
Ex: Client-side
authentication
Ex: Authenticity Check
Missing
14

15. Best Paper Award, 2017, International Conference on Software Architecture
Adoption by the
Industry, U.S. &
Canadian Governments
What are Common
Design Weaknesses?
15

16. How Common Are CAWEs?

17. How Common Are CAWEs?
From the vulnerabilities that we
analyzed, 42.5% of vulnerabilities in
Chromium were architectural (403
CVEs), 38.7% for PHP (43 CVEs) and
38.2% for Thunderbird (255 CVEs).
Vulnerabilities in the three studied
systems are mostly related to the tactics
“Validate Inputs” and “Authorize Actors”,
used for resisting attacks.

18. How Common Are CAWEs?
The PLCs, RTUS etc.
communicate with SCADA
server using industrial
communication protocols
(Fieldbus)
2
HMIs are used by Humans to
configure the plant, troubleshoot
problems, run/stop/update
programs, and recover from
failures
3
The Data Historian logs
daily operational data used
for analysis & diagnosis
4
Programmable Logic
Controllers (PLCs) &
Remote Terminal Units
(RTUs) connect to sensors
& actuators
1
In Collaboration with U.S. DHS, NIST
and U.S. Cyber Emergency Response
Teams (CERT) for Industrial Control
Systems
Results & Implications
Most Vulnerable ICS Components
62.86% (540) of ICS Advisories studied were associated with 1 or more architectural weakness (CAWE)
18

19. How Common Are CAWEs?
Results & Implications
Most Vulnerable ICS Components
62.86% (540) of ICS Advisories studied were associated with 1 or more architectural weakness (CAWE)
19
In Collaboration with U.S. DHS, NIST
and U.S. Cyber Emergency Response
Teams (CERT) for Industrial Control
Systems

20. How Common Are CAWEs?
Results & Implications
Most Vulnerable ICS Components
62.86% (540) of ICS Advisories studied were associated with 1 or
more architectural weakness (CAWE)
20
In Collaboration with U.S. DHS, NIST
and U.S. Cyber Emergency Response
Teams (CERT) for Industrial Control
Systems

21. Secure by Design and -
Default, what it takes!
21
K-12 Technology

22. Security Requirements Engineering First
Secure by Design, What it Takes!
We can learn from 30+ Years Worth of methods,
models, tools and approaches on early assessment
of (safety) requirements in avionic, medical and
other safety and mission critical systems.
Safety Cases

23. Security Requirements Engineering First
Celeste Gambardella
Viktoria Koscinski Estey Gerstner
Secure by Design, What it Takes!
Safety Cases

24. Security Requirements Engineering First
Celeste Gambardella
Viktoria Koscinski Estey Gerstner
Secure by Design and Default, What it Takes!
Safety Cases
From Safety Cases to Misuse and Abuse
Cases and Identification of attack
scenarios!
Threat Modeling

25. Supported by DARPA
Towards an Automated Approach for Detecting Architectural Weaknesses in Critical
Systems, The 1st International Workshop on Engineering and Cybersecurity of Critical
Systems (EnCyCriS), 2020.
Security Assurances: Learning from safety
critical systems, we developed Assurance
Cases for Architecture Models, to Check if
the Secure by Design Claims are Met.
25
Secure by Design and Default, What it Takes!
Tooling to Help Developers Detect Design Flaws
Leasons Learned from Architecture First Approach to
Resiliency!

26. How to Detect Design Flaws?
Supported by DARPA
Towards an Automated Approach for Detecting Architectural Weaknesses in Critical
Systems, The 1st International Workshop on Engineering and Cybersecurity of Critical
Systems (EnCyCriS), 2020.
Develop Assurance Cases for
Architecture Models, and Check if the
Resilient by Design Claims are Met.
System has (i) at least one Validator, and (ii) at least one Target, which is
a component that perform security-critical operations.
This top-level claim invokes a subclaim (target components only receive
external data (from outside trust boundary) that is validated. This check
if at some point the data goes through interception validator or data
validator.
26

27. How to Detect Design Flaws?
Supported by DARPA
Develop Assurance Cases for
Architecture Models, and Check if the
Resilient by Design Claims are Met.
role::Entrypoint
role::CriticalComponent
role::Target
role::Target
role::Target
role::Target
role::Target
role::SensitiveDataSource
No Validation
Achilles::role:SensitiveDataSource
No Encryption
CAWE-319 TRANSMISSION OF SENSITIVE DATA WITHOUT ENCRYPTION
CAWE-306 MISSING AUTHENTICATION FOR CRITICAL FUNCTION
27

28. Software Change Cycle: Ideal World
Ideal World: Architectural
information is documented during
the Architectural design phase and
is updated regularly to reflect the
current system architecture.
28
Secure by Design and Default, What it Takes!
Design Erosion and Drift

29. Software Change Cycle: Ideal World
Ideal World: Architectural
information is documented during
the Architectural design phase and
is updated regularly to reflect the
current system architecture.
29
Software Change Cycle: Real World
Real World: Architectural
information is outdated and does
not reflect the current architecture
of the system.
Secure by Design and Default, What it Takes!
Design Erosion and Drift What is in the code is the software
design in use!

30. Implementing a Software Design is Difficult
Intended
Architecture
Implemented Architecture
An Observation: developers have
difficulties implementing design
solutions (tactics/patters/styles). They
keep refactoring…
More Facts : We studied five large
scale software systems, and
architecturally significant
classes had significantly more
bugs than non-architecturally
significant ones (p-value< 0.001).
30

31. A big ball of mud: Apache Hadoop architecture
Master
Slave
HB
Implementing a Software Design is Difficult
31

32. Roles and Impacts of Hands-on Software Architects in Five Industrial Case Studies, 40th International Conference on Software Engineering (ICSE), 2018.
An Empirical Study of Software Degradation
32

33. Roles and Impacts of Hands-on Software Architects in Five Industrial Case Studies, 40th International Conference on Software Engineering (ICSE), 2018.
Architecture Savvy Developers
33

34. Roles and Impacts of Hands-on Software Architects in Five Industrial Case Studies, 40th International Conference on Software Engineering (ICSE), 2018.
Architecture Savvy Developers
34

35. Roles and Impacts of Hands-on Software Architects in Five Industrial Case Studies, 40th International Conference on Software Engineering (ICSE), 2018.
Architecture Savvy Developers
35
• Non-Architecture Savvy Developers tend to introduce more bugs in Design
Fragments of the system. (p-value< 0.01)
• Design fragments owned by the Architecture Savvy Developers are less likely to
have bugs.
• In open-source projects you can’t dictate architectural decisions, it’s all persuasion
and communicating how things should work out.
• We constantly make changes in software in firefighting situations (Hadoop crashes
in U.S. bank or Facebook).
• We write functional tests but we don’t even have test cases for design decisions.

36. Bring Security Design Thinking into
Developers Daily coding Activities
36

37. What are Software Attack
Surfaces?
37
Secure by Design and Default, What it Takes!
Reduce Software Attack Surfaces
Attack Surface—the critical points on the
boundary of a software system:
- Accessible from outside
- Contain valuable content for attackers
Attack surface analysis :
The process of identifying applications’
attack surface components.
Not very well understood in the
literature! We also lack of tools!

38. What are Software Attack
Surfaces?
38
Secure by Design and Default, What it Takes!
Reduce Software Attack Surfaces
Our Goal: Analyze
thousands of CVEs to
capture commen attack
surfaces abused in the wild.

39. What are Software Attack
Surfaces?
39
Secure by Design and Default, What it Takes!
Reduce Software Attack Surfaces

40. What are Software Attack
Surfaces?
40
Secure by Design and Default, What it Takes!
Reduce Software Attack Surfaces

41. What are Software Attack
Surfaces?
41
Secure by Design and Default, What it Takes!
Reduce Software Attack Surfaces

42. What are Software Attack
Surfaces?
42
Secure by Design and Default, What it Takes!
Reduce Software Attack Surfaces

43. What are Software Attack
Surfaces?
43
Secure by Design and Default, What it Takes!
Reduce Software Attack Surfaces
• The proposed model covers previously studied
attack surface components and introduces 254 new
concrete components that did not exist int the
literature
The literature covers:
- A small percentage of Code level entry
points targets and mechanisms
- On average at the Code level only 8 of the 119
concepts (6.7%)
- In the best case only 50% of the Network level
mechanisms

44. R&D in Support of President Biden’s EO
44
44
Secure by Design and Default, What it Takes!
Secure Software Supply Chain

45. Landscape of Emerging Tools
45
Secure by Design and Default, What it Takes!
Secure Software Supply Chain
SBOM Generation:
- Interoperability Use Cases:
- Converting
- Merging
- Signing and Notary
- Diff
- Add
Strengthening Software Supply Chain
- Vulnerability Management
- Detect Dependency Misuses
- Unpinned dependency allowing range of
versions
- Dynamically loading dependencies
- et.c
SBOM Quality Checking
- Schema Checking
- SBOM Content Validation
and SBOM Scoring
- Authenticity Verification
Information Sharing Across Supply Chain
- SBOM Sharing
- Vulnerability Exploitability eXchange (VEXs)

46. Landscape of Emerging Tools
46
Secure by Design
and Default, What it
Takes!
Secure Software Supply Chain
Major Issue:
- Interoperability of tools
- Inconsistency of Fidnings
- Missing components
- Missing vendor info
- Versions
- Transient Dependencies

47. We can learn from well established software engineering
practices in Regulated, and Certified domains
On whose Shoulders
We Stand?
47