Author Bio: Ken Fitzpatrick

I’ve been working in the security industry for over 15 years and always struggled in finding clear processes for defining security design.

Most of the architecture frameworks that I’ve worked with in the past provide the building blocks for good design without actually defining what it is or how to get started.

I spent several years continuing to better understand these frameworks to only realise that most frameworks don’t actually provide a process for writing good security designs.

I’ve often seen poor security designs that attempt to incorporate every aspect of an architecture framework into their design without actually thinking about the security problem that they are trying to solve.

This is what inspired me to write SecurityPatterns.io.

It’s an opinionated view on how to write security patterns, but that is the intent. It’s a baseline that you can work from and mature over time. You can change whatever parts of the process to meet your own needs, and in fact I encourage you to do so. Understand however the rationale for the process and the principles behind developing security patterns in this way.

The purpose of this site is to help other security professionals who are also on a similar path or looking at better ways to write security design.

I’ve worked and used security patterns for a number of years, and across a variety of different projects. Despite the upfront investment of time and effort in the design, security patterns have always paid off over time due to their adaptability and reusability for different requirements.

I hope you enjoy the guides and look forward to any feedback (whether it’s the good, the bad or the ugly).

Principles to SecurityPatterns.io

These are the principles to which I look to defined the work published in this site, and fundamentally to any security design.

1. Keep It Simple

Minimise complex terminology and stick to terms understood by the industry. Don’t create ‘special’ proprietary words or labels, it just confuses people.

2. Pragmatic In Approach

Use tangible examples to explain concepts rather than academic theory.

3. Learn In A Day

Material shouldn’t be any more than what can be consumed in a single day by someone with moderate experience in security, architecture or engineering.

4. Opinionated On The Solution

Be opinionated to the process, approach and solution rather than generic statements. Allow others to adapt or change to meet their own needs.

Contact Me

Looking to get in touch or want to share your own experience in writing security patterns. See below for best options for reaching out.

Linkedin: ken-fitzpatrick-me

Linkedin is the best way to get in touch and where I’m most active. Feel free to connect, send me a message or comment on any posts.