I used Wardley mapping this morning to explore ideas I have for improving the development and review of AWS Identity and Access Management (IAM) policy changes. I’d like to share the internals of that mapping process with you to give you an illustrated example.
The purpose of this process improvement effort is to help people implement the IAM policies that the organization’s engineers, managers, and governance policies intend. The process should provide quick feedback and trustworthy information to engineers in the middle of making decisions about the correctness of a complex system and its compliance to policy.
This is important because it’s a real problem if you’ve accidentally opened access to a set of critical actions or resources that you didn’t intend, and this can occur easily.
Let’s start with users and their needs:
- Authors: an engineer who develops changes to IAM entities (policies, roles, etc) needs to enable a use case of AWS safely
- Reviewers: an engineer who reviews IAM changes to check correctness for use case and adherence to the organization’s security standards; they are principally interested in managing the risk associated with any given IAM change
- External users such as Auditors, Regulators, and Customers that we’ll skip for now
Setting a Baseline
First, I sketched-out a landscape for IAM development and review on a whiteboard, thought about the current solutions, and then replaced key activities with ones that created more value for users. I preserved the messy, version 1 of the map for posterity with a photo.
What was great about this initial mapping exercise is how quickly I was able to:
- identify the components where enhancements will likely benefit user needs the most
- clearly see dependencies between activities, features, and components
Next, I transferred that map into an electronic form using RealtimeBoard. The landscape underwent a number of changes resulting in v2:
Current: IAM Dev & Review Process
Most of the changes were clarifying and adding to the activities that support user needs like ‘Enable Use Case’ and ‘Manage Risk of IAM Change.’ The most important clarification was noticing that in most cases engineers have to imagine the effects of the proposed changes. Needing to imagine the effects of security critical changes sounds perilous and exactly the kind of activity that needs replacement.
Mapping a Better System
From the current state of the system I mapped out a target state with new or enhanced activities represented in gold:
Target: IAM Dev & Review Process
Notice that the (proposed) activities in gold provide more, higher-value support to the key activities of reviewing changes and assessing risk.
The complicated-yet-critical activity of reviewing a difference in IAM policy code has been replaced with one that also reports the net change in AWS actions. Instead of forcing a reviewer to imagine the new effective API actions permitted by the change, the system can provide an enumerated list, for example.
The other big addition is a ‘review computed risk assessment for change’ activity. If you’ve already enumerated the net change in actions, there’s a good chance you can estimate the net change in risk with a weighted metric that accounts for the power of different APIs. This metric could warn people that a policy now permits the principal to take control of IAM because it, e.g. allows both the create and attach policy actions.
Summary
I hope this example has grounded some specifics of using Wardley mapping to help develop strategy around an abstract problem like making an activity safer. I’d love to hear your thoughts on the mapping process or improving the safety of IAM policy development and review via email or LinkedIn.
Have a great weekend!
Stephen
#NoDrama
