Security (and IT) Obstructionism

Kolide recently posted an article - End Security Obstructionism with Security Automation Orchestration, where they discuss some of the common issues with legacy thinking with enforcing security in an onerous, monolithic way.

I think it’s pretty common for organizations to feel like IT and the rest of the organization are adversarial, and that it is always a battle between what most of the company is trying to do, and what IT is trying to force you to do.

For a long time I’ve thought that most of this was a combination of communication problems, and in many cases, IT teams just being lazy. They just want to get something done, and don’t want to put the effort in to making the experience for the organization better. There are, of course, exceptions but they seem to be pretty rare.

Unfortunately, it doesn’t take much time looking on Reddit in IT or system administrator forums to realize that many IT people also feel like it’s an adversarial relationship, and that users are just there to battle the IT team. No, Reddit is definitely not representative of real life, but you do see the same sentiment to some degree in lots of organizations.

Kolide offers several examples of what they are calling “Security Obstructionism” (I think it’s a good term, and a useful concept to really think about), which they are referencing another blog by Kelly Shortridge, and I think it is worth reading both blogs in more detail, but some examples include forcing a user to restart their computer without warning, using phishing simulations to “trap” users in to clicking on links, then forcing them to go through training because they fell for some trick, or really anything that is purposely getting in the way with someone doing their job.

Why would we want to put in more effort, when we can force these things anyway?

I strongly believe that if you can put in the effort to align IT with the business and the user, it will pay off in several really big ways.

First, you get buy in from the users. Despite what some IT professionals may believe, it’s actually pretty uncommon for a user to actually want to mess things up, or do something that is not secure. Typically when they do something they shouldn’t, it’s because it’s easier than doing the “right” thing. They also often don’t really understand why they need to do something a certain way, and the “legacy” way of forcing them to do trainings doesn’t always work.

This is where automation and orchestration can come in. When you design your IT infrastructure and processes to be user first, and have automatic actions that include the user, you can help them understand and do the right things without making them feel like they are being punished, or that they have done something wrong, or even making them feel stupid.

When I design systems, I am trying to make it as seamless as possible. If there is something that can be done silently in the background with no interruptions, we’ll do that. If something needs to be disruptive for a bit (an update that needs a restart, or something like that), we try to prompt the user that it’s going to happen and give plenty of time for them to do it themselves. We strive for zero touch deployments, with screens that prompt the user with what exactly is happening on their system, to help them understand and feel included in the process, but also to keep friction to a minimum.

Another huge benefit of this method is that if you can get the buy in from the users, and even put in the effort to understand the business, and how IT can help, then IT starts to become part of the conversation about business goals and initiatives, instead of being an afterthought expected to “just make it work” after decisions have already been made.

Conclusion

I think it is critical to think about this concept in IT, and it is key modern IT management. Companies are starting to expect this level of service from IT, whether it’s internal IT or Managed Service Providers. Technology has to be a key part of business strategy any more, and if IT wants to be included in those conversations (and they do need to be!) then achieving these principles are going to be vital.

Kolide makes a wonderful product that can help with many of these areas. Their guide on Honest Security outlines their company philosophy, and is well worth reading. We mix in the Honest Security principles with how we do things, and I think it’s great to see a different methodology on how to effectively manage users in an organization.