Skip to main content




Systems Engineer by training, InfoSec Consultant by trade focussing on pragmatic security risk assessment and treatment, I lead the InfoSec engagement on high risk, high impact projects that shape large organisations and which you *will*, unknowingly, use! I've worked across a range of sectors in InfoSec from defence, media and Government, and currently focus on AppSec and DevSecOps; developing and implementing AppSec strategies across big organisations by:

  • creating organisation wide networks of security champions.
  • teaching threat modelling and leading threat modelling sessions with development teams.
  • left shifting the implementation of security risk management via security architecture surgeries.
  • developing modern, practical, automated and economically sensible approaches to security assurance testing (i.e. not pen testing).

Being able to teach threat modelling to developers is a skill based on many years of InfoSec risk management across a number of industry sectors and frameworks, such as ISO 27001, NIST and HMG IAS1&2, and my background in systems engineering, working with frameworks such as UML and MODAF/TOGAF.

My approach to InfoSec is built on my systems engineering background and, as such, I'm a huge advocate for InfoSec becoming data driven, measurable and value adding. After all, "user experience is everything, security only needs to be good enough".

Things that currently pique my interest:

  • defining Audience personal data usage and associated security controls.
  • C4 architectural modelling for threat models.
  • advanced threat modelling and the use of LINDDUN.
  • Kubernetes (and other container orchestration service) security.
  • zero trust networks and Attribute Based Access Controls (ABAC).
  • Content-Security-Policy (CSP) strategy for the enterprise.
  • Single Page App/Progressive Web App (SPA/PWA) security.

Popular posts from this blog

Threat modelling this website

My previous post looked at producing a C4 model for my (simple) website. This post takes that a step further and looks at how we can use C4 modelling to elicit security and privacy threats using two frameworks: STRIDE . Most people know STRIDE, it’s derived from the Microsoft security threat modelling process from the early 2000s and represents Spoofing, Tampering, Repudiation, Information leakage, Denial of service and Elevation of privilege. LINDDUN . This is not so widely known but I first came across it in one of the Application Security Podcasts on  Privacy Threat Modelling . “ LINDDUN  was created in 2010 as a collaboration between the DistriNet and COSIC research groups of KU Leuven, Belgium”. It is a framework, not unlike STRIDE, which represents Linkability, Identifiability, Non-repudiation, Detectability, Disclosure of information, Unawareness and Non-compliance. However, both STRIDE and LINDDUN base themselves around classical threat modelling techniques which, in my opinion

Smart home equipment

My home is relatively smart in that I run a Home Assistant server with quite a few integrations with lighting, motion sensors, door/window sensors, CCTV, temp/humidity, energy and heating so I figured I'd list out my tech choices and any good/bad points that I've found while in use. My tech choices are now pretty stable after a few iterations over a few different types which means I have time to write a blog about it rather than play with Home Assistant all the time! Home Assistant This is the brains of the operation - it sits in the garage running on an old Shuttle PC with a DeConz Conbee II Zigbee stick in the back and is exposed to the internet so that the associated Android phone app can communicate with it at all times. That's pretty useful as I have a bunch of geo based automations hooked in but means that I have to be on top of my security model. Home Assistant has been rock solid for many years now. It's consumed A LOT of time in configuration and maintenance b

C4 modelling this website

This site has been around for a few years now and has changed significantly, mainly from an infrastructure perspective, over that time. That can be done as the site gets very few hits so I can use it to test features and experiment without worrying about outages.‌ In a work context, I very much promote the use of  C4 modelling  as a consistent and clear means of expressing a system architecture. C4 modelling struck a chord with me when I first came across it as it takes the best bits from UML and structured systems engineering, which is my background, but allows them to be used in a more agile (with a small ‘a’) software development context. Consistency is also the key; on a daily basis I review a handful of threat models which have historically been drawn using  any  drawing method (logical, physical, software based, high level, low level, etc) and tooling that you can imagine. Such a lack of consistency brings with it a time burden; it takes time to understand how each of the varying