The document discusses a framework for thinking about security in software architecture, emphasizing the need to ask critical questions regarding what needs to be secured, who the security is for, and what 'secure' means in terms of confidentiality, integrity, and availability. It also outlines the importance of a common vocabulary and highlights the continuous nature of managing security, suggesting the establishment of an information security management system for ongoing compliance and risk management. The author advocates for a structured approach to identify and protect information assets while simplifying the design process.

1. Chris F Carroll
Software Technical Design
for Security
Software Architecture for Security

2. Requirements
Threats
vs.
All requirements have edge cases, but with security they expand into a
whole second way of seeing the issue. Threats get all the news! But our
understanding of threats remains piecemeal if we don’t understand the
core requirements they are threatening. So we start here.

3. Software Architecture for Security Chris F Carroll
How can we think
about security?
Software Architecture claims to help us THINK about software
systems. To get security right, we want a framework for thinking about
it: What are the questions we should ask, and what concepts will help
us to answer them?

4. Software Architecture for Security Chris F Carroll
① Ask the Right Questions
② Have a “Domain Model”

5. How Can We Think About Security? Chris F Carroll
✤ WHAT are we trying to secure?
✤ WHO are we securing for or from?
✤ WHAT does “secure” mean anyway?
If we can answers these 3 questions then we have done much of
the work of thinking about security. To help us answer them, we
want some vocabulary, or a domain model.

6. A Typical Information Security Policy (extract from a UK company policy)
“We strive to protect the group’s critical information assets against all
internal, external, deliberate or accidental threats throughout its lifecycle
We protect against unauthorised access threatening the
Confidentiality of our information and ensure that the Integrity and
Availability of critical information is maintained.
Our Information security policy is to ensure business continuity of the
Group, minimising the risk of damage by preventing security incidents and
reducing their potential impact. We are committed to continuous
improvement, ongoing compliance with legislative and regulatory
requirements and to ensuring our employees receive appropriate
information security awareness training.”
But

7. fi
ned in
ISO27000, the basis for many company’s
Security Management. For software
development to match the security policy
it might help to have—at least—a
common vocabulary?!
Chris F Carroll
(you can get the same
vocabulary from wikipedia
or a security or software
architecture textbook).

8. Chris F Carroll
WHAT do we want to secure?
Information Assets, typically:
1. Data Stores
2. Systems that let you do things
WHO are we securing for/from?
(Un)/Authorised users
WHAT does secure mean anyway?
Con
fi
dentiality
Integrity
Availability
Security : Just 3 Questions
Grounds for
deciding we should
secure an asset
might include:

9. Information Assets, typically:
1. Data Stores
2. Systems that let you do things
WHO are we securing for/from?
(Un)/Authorised users
WHAT does secure mean anyway?
Con
fi
dentiality
Integrity
Availability
Security : Just 3 Questions
Divide the world
into two groups of
people: The
Authorised and

10. Information Assets, typically:
1. Data Stores
2. Systems that let you do things
WHO are we securing for/from?
(Un)/Authorised users
WHAT does secure mean anyway?
Confidentiality
Integrity
Availability
Security : Just 3 Questions
And we get a grip
on what “secure”
means with the
“3 dimensions”
de

12. Information Assets, typically:
1. Data Stores
2. Systems that let you do things
WHO are we securing for/from?
(Un)/Authorised users
WHAT does secure mean anyway?
Con
fi
dentiality
Integrity
Availability
Security : Just 3 Questions
Now we have 3 Questions and the Vocabulary to answer them

13. Architecture for Information Security Chris F Carroll
Questions So Far?

14. ISO 27000 Vocabulary for Secured Assets Chris F Carroll
Access Control
User, Groups, Roles
Authentication & Authorisation,
Principals, Claims
IAM, OAuth2, JWT
Uptime, Reliability, Backups
Discussion: How do our 3 questions and 5 core concepts relate to
these other things you might hear about when discussing security?

15. Chris F Carroll
Access Control: “to ensure that access to
assets is authorised & restricted based on
business and security requirements”
ISO 27000 Vocabulary for Secured Assets
Controlling Read-Access sounds like Con

20. Grant-Read
Grant-Write
Uptime, backups, connectivity, resilience
to attack
How does
C.I.A
map back
to other
vocabularies?
Security includes both functional and non-functional requirements

21. Security : Just 3 Questions Chris F Carroll
✤ WHAT are we trying to secure?
➡ Assets: Data Stores & Systems
✤ WHO are we securing for & from?
➡ (Un)Authorised Users
✤ WHAT does secure mean anyway?
➡ C.I.A.
Thinking about security: Our 3 questions and 5 core concepts are enough
to state and analyse security requirements for many software
systems.

22. Architecture for Information Security Chris F Carroll
Questions So Far?

23. 2 Questions about Secured Assets Chris F Carroll
About these Assets we are securing…
✤ Where are they?
✤ What paths access them?
Thinking about security: When we get to Technical Design, two more
questions about assets may simplify our design enormously

24. Architecture for Information Security Chris F Carroll
Exercise: www.my
fi
rst startup.com
Discussion Exercise: Let’s do a security design & review for a small startup

25. Architecture For Information Security Chris F Carroll
www.wesculptitforu.com
Send us a Photo and we’ll
send you a sculpture!
Only £0.99 per cm³ + p&p!
Discussion Exercise

26. Architecture For Information Security Chris F Carroll
www.wesculptitforu.com
Send us a Photo and we’ll
send you a sculpture!
Only £0.99 per cm³ + p&p!
Discussion Exercise
Let’s do a security design for this
startup!

28. Information Assets, typically:
1. Data Stores
2. Systems that let you do things
WHO are we securing for/from?
(Un)/Authorised users
WHAT does secure mean anyway?
Con
fi
dentiality
Integrity
Availability
Discussion Exercise
Step1 : Use our 3
questions and 5
core concepts to
state and
understand our
requirements

29. Where Are the Information Assets? Chris F Carroll
Discussion Exercise
1) Where are the
Assets?

30. Where Are the Information Assets? Chris F Carroll
Discussion Exercise
Oh no, they’re
everywhere!

32. fi
rewall)
• 3 Gateways
• HTTPS for external
communication
Discussion Exercise
https
https
firewall Start the design by
imposing a simplifying
structure on the
physical system

33. Simplify The Challenge Chris F Carroll
Not My
Problem
Not My
Problem
Not My
Problem
Discussion Exercise
The point is to make
everything outside
your structure Not
Your Problem
https
https
firewall
Simplify!
• 1 Border (e.g. a
fi
rewall)
• 3 Gateways
• HTTPS for external
communication

34. Simplify The Challenge Chris F Carroll
Not My
Problem
Not My
Problem
Not My
Problem
- Your Code
- Frameworks &
Dependencies
- OS or Platform
- Network
- Cloud Platform
Discussion Exercise
https
https
firewall
Simplify!
• 1 Border (e.g. a
fi
rewall)
• 3 Gateways
• HTTPS for external
communication
Then, list all the
things inside the
structure that are
your problem

35. Simplify The Challenge Chris F Carroll
Not My
Problem
Not My
Problem
Not My
Problem
- Your Code
- Frameworks &
Dependencies
- OS or Platform
- Network
- Cloud Platform
Discussion Exercise
Simplify!
• 1 Border (e.g. a
fi
rewall)
• 3 Gateways
• HTTPS for external
communication
https
https
firewall Finally, for each item on
the reduced list,

37. 1) A list of Assets & Users; then a table of CIA requirements
for each Asset-User pair (or e.g. asset-role pair)
2) A Deployment View that
❖ Shows where the Assets are
❖ “proves” (well, claims) they are only reachable through the
System in an authorised way.
3) A list of assumptions which must hold, and/or
procedures which must be followed, for (2) to be true.

38. Architecture for Information Security Chris F Carroll
✤ You may be a little disappointed that the last item is not,
“Fo
ll
ow
th
is procedure and Lo! It sha
ll
be secure.”
✤ The last item can only be, “These are the assumptions
& procedures which give us acceptable confidence it
is secure.”

39. Discussion Exercise: Your Review of my Design

40. Discussion Exercise: Feedback on my Design
-
Load Balancer
Systems which you use may be
your problem under GDPR — you
need legal dept to advise, and to
review the contract

41. Actions after a Security Design Review Chris F Carroll
My response to design review might typically be:
1) Updating or correcting one or more of the lists I made
2) Adding or clarifying assumptions
3) Agreeing with IT Operations and/or CIO if any changes to
security procedures may be needed
4) Agreeing with IT Operations any other changes needed
NB even in a micro-startup where I was a 1-person IT department,
I would get someone to review security design

42. Architecture for Information Security Chris F Carroll
Questions So Far?

43. Chris F Carroll
✤ How do we Know it’s secure?
✤ WHY do we care about security?
A Fourth Question 😲

44. fi
nd an insecurity?
Security: the further you go, the more complicated it gets …
Thinking Even More About Security

45. Security: Not a Hobby, a Way of Life Chris F Carroll
✤ So we need audit, monitoring, reviews …
✤ Managing security becomes an entire,
never ending, management system & set
of processes. Hence “ISMS”
✤ We must understand risk
Security: the further you go, the more complicated it gets …

46. Risk Management—the 1-slide Intro A Typical Risk Matrix
Why Do We Care?
Because we are
managing Risk

47. fi
ne An Information Security Management System With
Policies and Processes To Assess and Manage Risk
Train Sta
ff
in Policies and Processes
Get Certi
fi
cation For Your Trained Sta
f
Get Your System Audited
Join An Expert Community Of Practise
Know Where To Look For Reference Materials
Know Where To Look For News
Find out what the Tools are
Learn Standard Patterns
Do Technical Design
Get Technical Design Reviewed
Do It All Again
So Information
Security usually
starts with a
Management
System

48.
We protect against unauthorised access threatening the
Confidentiality of our information and ensure that the Integrity and
Availability of critical information is maintained.
Our Information security policy is to ensure business continuity of the
Group, minimising the risk of damage by preventing security incidents and
reducing their potential impact. We are committed to
continuous improvement, ongoing compliance with legislative and
regulatory requirements and to ensuring our employees receive appropriate
information security awareness training.”
Earlier, I ignored the bo

49. fi
ne A Management System …
Train Sta
ff
…
Get Certi
fi
cation …
Get Audited …
➡ Join An Expert Community Of
Practise
✓ https://owasp.org
Join the Slack Channel
➡ Know Places you can look for
Reference Materials
✓ https://portswigger.net/web-security
✓ https://www.nist.gov/cyberframework
✓ https://www.microsoft.com/en-us/
securityengineering/sdl
✓ https://www.edx.org/professional-certi
fi
cate/
linuxfoundationx-secure-software-development-
fundamentals
➡ Learn Standard Patterns
https://cheatsheetseries.owasp.org
Do Technical Design
Get Technical Design Reviewed
Do It All Again
What are
developer team
responsibilities?

50. ✤ WHO are we securing for or from?
✤ WHAT does “secure” mean anyway?
✤ HOW do we know it’s secure?
✤ What RISKS are we managing?
If we can answers these 5 questions then we have
done much of the work of thinking about security.

51. Chris F Carroll
Software Technical Design
for Security
Software Architecture for Security