Automation isn’t just about replicating an existing manual processes. Yes we want the same end results, but the process will have to be different because it’s a dumb computer doing it and not a human.
Humans are really good at spotting patterns, including ones we’ve never seen before. A human operator will be able to say “this looks right”, and also “this doesn’t look right, I’d better tell someone”. We can’t realistically design IAM solutions to do that for all possible permutations of “looks right” and “doesn’t look right” – so our designs must include the expectation that bad data will come through, the IAM solution will have no way to “know” the data is bad, and undesired results may ensue.
I’m not trying to say one should be excessively paranoid. It’s like driving – if you go out there with the expectation that every other road user has no idea about the rules, and that every pedestrian is just waiting to leap in front of you, you’d be driving in such a state of stress and anxiety you may well cause an incident yourself. Good drivers drive with the expectation that no-one wants to be in accident, but just in case you keep track of other road users around you, and you leave enough space to stop or avoid should something unexpected happen.
In our IAM solution we can’t possibly protect against all types and causes of bad data, but we should look to minimise bad effects. Some suggestions:
- Anything the IAM solution does it should also be able to reverse when the correct data comes through.
- However, if the IAM solution must take actions it cannot reverse there must first be a suitably long grace period. (eg., clean-up actions following account disablement – we can reverse disabling the account but anything destructive must only happen after a suitable wait).
- Monitor for bulk changes – excessively large numbers of changes should be checked. (Yes IAM solutions do need to be proactively managed.)
- Not all bulk changes are bad, but if possible detect and prevent large numbers of deletions or changes to active/inactive status.
- If you implement change blocking, you must also implement a way to alert this has happened, and a way to check the changes and allow if they are fine.
In general we must design with the expectation that source data is good but also with a way to minimise the damage if source data is bad.
I guess you could call this Defensive Design.
