The document discusses the challenges of security architecture in large, complex systems involving multiple stakeholders and diverse projects. It emphasizes the importance of measuring attack surfaces and system complexity, as well as the risks associated with tightly-coupled components. The analysis introduces concepts like attack surface contributions, coupling, and connectivity to identify high-risk areas in such complex systems.

1. PracticalArchitecture Analysis
1
Internal Presentation, September 2013, V1
Phil Huggins

2.  Security Architect for large
delivery programmes:
 Multiple projects
 Challenging stakeholders
 Large, complex systems
 Multi-year delivery
 100+ people customer
delivery teams
 200+ people supplier delivery
teams
 Security mattered
 Government
 Commercial
 AirportTerminal New Build
 Smart Metering for a Big6 UK Energy
Supplier
 7x UK Airports security refresh.
 UK Banking ecommerce
infrastructure
 Cloud Software as a Service Provider
2

3.  Many sub-systems
 Multiple stakeholders and connecting parties
 Multiple COTS products
 Multiple unsupported OSOTS products
 System-specific glue code and configuration
 Business-specific logic and processes
 Shared data models
 SDLC doesn’t help for the majority of the vulnerabilities in
the systems
3
Trust
Issues
Design
Flaws
Software Bugs
Configuration Errors
Most Vulnerabilities

4. 4

5.  A measure of attackability NOT of vulnerability.
 Doesn’t look inside the box.
Michael Howard at Microsoft (2003)
Michael Howard & JeanetteWing at Carnegie Mellon (2003)
 Relative Attack Surface Quotient
 20 AttackVectors (open sockets, weak ACLs, guest
accounts etc)
 Channels
 ProcessTargets
 DataTargets
 Process Enablers
Pretty informal model
Needs an expert to apply to software not previously analysed
5

6.  Pratyusa Manadhata & JeanetteWing at Carnegie Mellon (2004 –
2010)
 Positively correlated severity of MS Security Bulletins
vulnerabilities with the following indicators:
 Method Privilege
 MethodAccess Rights
 Channel Protocol
 ChannelAccess Rights
 Data ItemType
 Data Item Access Rights
 Attackers use a Channel to invoke a Method and send or receive a
Data Item
6

7. Methods
Privilege Value Access Rights Value
System 5 AuthNAdmin 4
Admin 4 AuthN Priv User 3
Priv User 3 AuthN User 2
User 1 UnAuthN 1
7
Attack Surface Contribution = Method Privilege Value / Method Access Rights Value

8. 8
Channel
Protocol Value Access Rights Value
Raw Stack Access 5 AuthN Admin 4
Constrained Protocol Access 4 AuthN Priv User 3
Encoded MessageAccess 3 AuthN User 2
SignalOnly 1 UnAuthN 1
Attack Surface Contribution = Channel Protocol Value / Channel Access Rights Value

9. 9
DataType
Type Value Access Rights Value
Persistent Executable 5 AuthN Admin 4
Persistent File / Data Item 1 AuthN Priv User 3
AuthN User 2
UnAuthN 1
Attack Surface Contribution = Data Type Value / Data Type Access Rights Value

10.  Attack Surface Measurement = Sum of all Attack Surface
Contributions
 Assumes probability of a exploitable vulnerability in a Method,
Channel or Data Item is 1
 Comparing two boxes against each other or against differently
configured versions of themselves is relatively easy.
 Beware: Similar attack surface scores may hide boxes with a small
attack surface but a very high damage potential!
 Only considers attackability no consideration of the impact of the
attack
 This is not risk
10

11. 11

12. “The worst enemy of security is complexity.”
Bruce Schneier
“Connectedness and complexity are what cause security
disasters.”
Marcus Ranum
"Risk is a necessary consequence of dependence“
Dan Geer
“Left to themselves, creative engineers will deliver the
most complicated system they think they can debug.”
Mike O’Dell
12

13.  Coupling
 How fast cause and effect propagate through the system.
 Time dependent
 Rigid ordering
 Single path to successful outcome
 Complexity
 Number of interactions between components.
 Branching
 Feedback loops
 Un-planned sequences of events.
 Multiple component failures cause systemic cascade failures or
accidents.
 Accidents are inevitable in complex, tightly-coupled systems.
13

14. Also a common solution architecture concern.
14
Simple Component Complexity
Fan-In Complexity Sum of all possible protocol connections to the
component
Fan-Out Complexity Sum of all possible protocol connections from the
component
Total Component Complexity Sum of Fan-In & Fan-Out Complexity
Complex Component Complexity
Fan-In Complexity Sum of all Methods offered by the component on
each Channel
Fan-Out Complexity Sum of all Methods used by the component on
each Channel
Total Component Complexity Sum of Fan-In & Fan-Out Complexity

15.  Closely-coupled in security is analogous to highly-trusted.
 I propose that measuring the trust of connections has the
following aspects:
15
Connection
Channel
Privilege
Value Channel
Privacy
Value Channel Access Rights Value
System 5 PlainText 4 AuthN Admin 4
Admin 4 Binary 4 AuthN Priv User 3
Priv User 3 Obfuscated 3 AuthN User 2
User 1 Encrypted 1 UnAuthN 1
Coupling = Channel Privilege Value x (Channel Privacy Value / Channel
Access Rights Value)

16.  The coupling and connectivity of the system can be
represented by a graph:
 Components = Nodes
 Connections = Edges
 Number of Methods = EdgeWeighting
 Coupling = EdgeWeighting
This doesn’t need special tooling, you can represent a graph in a
matrix
(A spreadsheet for example).
Graphs can be clustered using complexity or coupling to identify
structurally related components in a system
16

17.  A good example representing system graphs matrices in system engineering
is a Design Structure Matrix (DSM)
 http://www.dsmweb.org
 These are easy to knock up while you’re working to aid your analysis.
Simple complexity DSM example:
17
WWW APP DB MESSAGE1 MESSAGE2 Fan-Out Total
WWW 1 1 1 0 3 3
APP 0 1 1 0 2 3
DB 0 0 0 0 0 2
MESSAGE1 0 0 1 1 4
MESSAGE2 0 0 0 0 0 1
Fan-In 0 1 2 3 1

18. 18

19.  Components can have
 A relative attack surface measurement
 A relative total component complexity measurement
 Connections between components can be relatively weighted by
 Complexity
 Coupling
 These are all indicators you can use to identify high risk areas of large
complex systems that you can then focus to address.
 More testing
 Re-Design
 This has previously highlighted an interesting situation where a firewall
HA pair between two logical networks that routed a closely-coupled
application protocol connection with a high level of privilege between
two components was effectively useless as a security control and was
removed.
19

20. 20