Measuring black boxes

1,296 views

Published on

A short presentation (20 minutes) I gave to an internal audience on the use of attack surface and complexity / coupling metrics in analysing system architectures.

Published in: Business, Technology
  • Be the first to comment

Measuring black boxes

  1. 1. PracticalArchitecture Analysis 1 Internal Presentation, September 2013, V1 Phil Huggins
  2. 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. 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. 4
  5. 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. 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. 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. 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. 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. 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. 11
  12. 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. 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. 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. 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. 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. 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. 18
  19. 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. 20

×