Minimum Viable Security – Design Monday

Minimum Viable Security – Design Monday

My focus on IT security began in 1997 with a malware outbreak. To get a sense of how much has changed, I checked out the (ISC)² website as it existed back then. Whoa. It’s ugly. The website and the views on cyber security have drastically improved since the nineties.

These days I regularly get asked, “where do we begin?” Privileged Access Management is supposed to look like this. Zero Trust Architecture is supposed to look like that. We only have a these two things, a paperclip, some duct tape, an overworked staff, and an intern. Where do we even start?

Borrowing from the product design world, take a Minimum Viable Product (MVP) strategy. Take a limited number of security controls. Take a limited scope of people and systems. Design a security capability, implement it, and get feedback on what works and where improvements are needed. Then, rinse and repeat with refined controls and in a new area of the organization.

A concern is that this process may lead to a patchwork of controls assembled from a tangle of point solutions. Valid concern. We’ve all seen such environments. A few of us have been lucky enough to build such mistakes, and learn from them. The way to avoid this is to use a consistent set of architecture patterns and project templates. Each sprint begins with these patterns and plans. Each one ends with updating the architecture and PMO libraries. It’ll be ugly, but with a controlled process, it’ll improve rapidly.

Criminals don’t care that we got the capability perfect. Adversaries aren’t impressed with the beauty of our control framework. So toss out the textbook.

Start where you are. Dare to be ugly. Iterate and improve.

The (ISC)² CISSP webpage from 1997, courtesy of The Internet Archive.

This article is part of a series on designing cyber security capabilities. To see other articles in the series, including a full list of design principles, click here.

Posted by