“Hey man, simple ain’t easy.”
Thelonious Monk, Jazz Pianist and Composer
Reading Time: 4 minutes
I hope yesterday’s post didn’t discourage you from building more secure or reliable systems.
My intent was to challenge and inspire you to improve security using the same well-worn approaches we use for other aspects of system quality.
We can improve the world’s software by transforming ‘complicated’ and ‘complex’ into something simper, even boring. But this transformation isn’t easy.
There’s (still) No Silver Bullet.
Systems grow and evolve by the march of progress and accretion of little things.
Like a pearl.
A Way
There is a way to build our system’s security faster and maintain that level of security by reshaping the software delivery process and organizational culture to our advantage.
‘Specialties’ such as user experience, security, and database engineering/administration (to name a few) often miss the moments in the delivery process to affect change and realize their desired vision. Fortunately, these happen regularly so you probably have more opportunities next week.
The figure above depicts some of the most common and powerful methods for detecting defects in software delivery (1). Change flows from left to right through the stages of design, implementation, testing, and operations. This is intentionally depicted independent of software delivery process. Note: I do strongly advocate an incremental change delivery processes (agile) with the big implication you’ll be running through that cycle 10x or more of most non-agile methods (or maybe you won’t…gotta patch security vulnerabilities no matter what your process, right?).
I consider Security as one aspect of a system’s Quality (2) alongside Correctness, Usability, Availability, Performance, and more.
The bones on this diagram point to a quality practice you can use within a stage of delivery to detect a defect. These are further segmented by whether the practice is an inspection or a test.
Inspections are usually performed by a person in order to leverage that person’s ability to do what only a person can do: call upon that knowledge, experience, and intuition to identify flaws, misalignment to culture or brand, and surface things that automated mechanisms can’t find. This is especially helpful for identifying Unknowns.
Tests codify institutional knowledge and verify the existence or non-existence of some attribute of the system. Capturing this knowledge in written form scales your organization’s memory. When you automate these tests, they can be executed an order of magnitude or more than if you don’t automate that same test. This increases the volume and feedback by a large amount. This is especially helpful for cementing Knowns in place or being aware of when they change.
Back to scaling your specialty…
If you want to get broad adoption of your specialty, it’s helpful to shift the economics of those practices to the point where it is economically attractive for your change delivery process to adopt that practice. This helps the specialty compete for the finite resources that every organization has available to allocate to system development and operations at the highest level. Think Profit & Loss statement.
If you want people to adopt a practice, commoditize it.
Let’s return to security practices. I strongly believe that Security should be integrated at least the following points in the delivery process depicted above:
- Design Review
- Code Review for security critical features
- Static Analysis to identify vulnerabilities in
- Application and system dependencies
- Artifacts built by the organization
- Functional tests that verify positive and negative access control cases of security critical features
- Monitoring
- usage of security critical APIs, especially failed requests
- of active attacks using WAF/IDS or similar tech (throw in prevention, too)
- All the control planes: Infra APIs, delivery processes, secret usage, and a bunch of stuff I’m skipping
Each of these security assurance practices needs to be made:
- known (and reminded) that the practice is available
- easy for non-experts to use on-demand or in an automated delivery pipeline
- affordable to use
Let’s explore what happens when you commoditize specialty practices.
Efficiency
Over time, you’ll notice that there are many common problems and solutions across your business units and delivery teams. Some of these solutions can be extracted into a ‘standard’ implementation with a dedicated build and delivery pipeline that assures the quality of that component. This component can then be shared across the organization as a composable module offered in a Service Catalog or a shared service owned by the specialty team. When an implementation can’t be extracted to code, it may be possible to document as a pattern instead. Efficiency.
Scalability
You’ll also notice that you can accomplish more by training interested individuals around the organization (ideally each delivery team) with the knowledge and and giving them the authority to handle common security matters. These extended security experts can execute and handle the majority of the load created by the delivery process in addition to ensuring deep expertise is brought in at the right time. Scalability.
Culture
You can make security boring by commoditizing the most important practices into services and components that are easily adoptable and usable components by all the teams in your organization. I assure you this is a challenge in and of itself. But as each practice achieves wide adoption, you put a reminder into each delivery team’s daily work to think about and address security. Culture
Architecting broadly adoptable, scalable, efficient (security) processes is as much product management as it is technical know-how. But making these processes ‘simple’ is the work, and you need it to Go Fast, Safely.
#NoDrama
1. From my Delivery Quality 'X' Using Language 'Y' workshops 2. Quality as in Zen and the Art of Motorcycle Maintenance or Dan Norman's "Everyday Things"
