I’ve been watching Amish Mafia lately (a guilty pleasure). That got me to thinking about the role of shunning in good risk management (because this is how my mind works, apparently). We want our leadership to take good, appropriate levels of risk, which is a way of saying there are good behaviors to which we would like them to adhere. There are many theories on the psychology of behavior, but I want to focus today on shunning and public ridicule. (Quick note: yes, I know that the Amish and Mennonites don’t practice shunning sadistically and also don’t use a pillory; I took some artistic license here.)
Many security and risk professionals take the security of their systems personally. A hack against their firm is a personal failure. In other words, until everything is secure, many people leave work thinking that there is yet work to be done and their day is incomplete. This can be very stressful. Working in security with a risk-based focus is a little different. Instead of feeling accountable for the configuration of systems, the goal is to inform the resource owners about the state of their systems, allow them to make a decision, and then report on the outcomes. It works something like this: in most organizations, the security team doesn’t own the servers (there is usually some IT production services team that does). Whether something gets patched or a config setting gets changed (as an example) is usually a function of keeping the owner informed as to good practice and then letting them choose what they want to do. This is where the shunning and shaming techniques come into play.
We could feel personally accountable for the patching that needs done, or we can feel that once we’ve delivered the message about what “secure” looks like, our work is complete. After that, it’s a matter of reporting and follow-up. The shaming comes in the reporting: delivering reports to the head CIO that shows which areas aren’t as secure and then comparing the different teams to one another. This works well in organizations that have multiple lines of business (LOBs). We can compare company area A’s servers to company B’s which begs comparison of one to the other. The various CIOs/CTOs, etc. that own responsibility for the servers in each area will compete and/or be shamed by their relative performance. We can also develop policies/standards that encourage “shunning.” For example, we can declare that only servers/applications/etc. that meet certain risk criteria are allowed to be used for high-risk transactions; effectively “shunning” insecure systems from high-risk roles in the organization.
Regardless of what happens next, you’ve done your job of keeping everyone well-informed. First, everyone knows what is expected of them and second, everyone knows how they are performing against those expectations. This doesn’t need to be antagonistic either: it’s merely informational. No need to pillory your CIOs at the next staff meeting ;-)
The Risk Dr ® 