Handling fallout due to new security policies

Question

I am an InfoSec professional working as an IT auditor. For several months now, I have working closely with our information security team to strengthen the security controls governing our PCI and SOX compliance efforts. Last week, new security policies went live in the production environment. In response to a comment by @Lilienthal, we are implementing these safeguards to better safeguard the production environment containing card holder data, customer PII data, and non public financially sensitive data from unauthorized access / use by employees without a need to access this information. The new controls came about both due to compliance requirements (i.e: PCI) and also to strengthen our security due to customer security being necessary and the right thing to do.

@Brandin, the new policies were communicated through joint emailing between our team and the IT Security team.

@JAB, developers either have no access or R- only access to the production servers. However, other teams such as the IT Security and DBA do have frequent needs to access the production environment, which somewhat prompted such a process change.

As examples, the following requirement is now in effect: (among others)

1. Access to production servers must be through a jump box proxy.

Before these new changes became effective, as long as an employee had logical access to a production server, he / sh could directly access the server from his / her end point machine. Now access to sensitive company and customer data is centrally controlled through a proxy rather than individual end point user computers.

This week, our team has been getting complaints from IT and non-IT users that the new security measure are getting in the way of them performing their jobs. It seems that the end users don't really see the purpose of the new policies, although it was explained to them through a joint effort of both our teams.

As monitoring security and internal controls compliance is part of my job, I don't to go to my manager unless absolutely necessary as it seems I am unable to do my job. I also do not to alienate coworkers as I will most likely need their cooperation in the future.

When faced with resistance from other employees in implementing what is ultimately necessary and beneficial to the company, how can one best explain the situation diplomatically and effectively?

Answer 1

I find that there are two things you can do when this happens - one, certainly explain the need and represent the underlying requirements driving the change, but also, be looking for input and ways to accomplish the security goal with less disruption.

I've done the exact thing you've done before - implemented mandatory bastion servers for production access. And just as you've found, there was a bunch of crying from the engineers because "it's different." We put together a bunch of guides on how to SSH tunnel through bastions and helped people automate it and that solved some of the problems - not everyone knows how to do that and a lot of the end complaint is not being able to use desktop tools to interact with the remote host with a jump box in the way (e.g. I need to use mysql command line to the remote host, it's not on the bastion...). With a little SSH and .profile setup work you can somewhat transparently use local tools on a remote host behind a jump box. So a little education and providing scripts can go a long way. Ask them what their problems are and figure out how to ease them. But it's still a pain point for people that do it occasionally and have to remember a bunch more steps to go through to do their potentially urgent tasks.

Beware of claiming 'this is how it has to be' however - you lose credibility when you say there's only one way of accomplishing a security/audit goal because everyone knows it's not true.

It's important to always be looking for lower friction ways of accomplishing your goals (controlling and tracking access). In my newest gig we obsoleted bastions in favor of using Wireguard via an AlgoVPN host in production - it looks the same as a jump box on a 'box and line' diagram and serves the same function of control and audit but is both more secure and easier for people to use (they just run the wireguard client on their desktop and done, you can then hit the remote host transparently), though it does require more implementation (you still also need the ssh keys on the remote hosts, of course).

If everything is always set up as security versus usability, sometimes security will win but sometimes usability will win. I was at a company where we got rid of our head of IT security - at my urging - because he was unacceptably out of tune with what we needed our engineering environment to be like. The new head of compliance and audit we selected was much more collaborative in finding ways to accomplish audit requirements while not impeding productivity - the thing that actually makes our company money.

This is unfortunately common and security books and industry research bear out that often our "necessary security controls" aren't making us much more secure but are certainly impacting our productivity, this blog post links to a bunch of good sources. If you can work towards a DevSecOps model where you are continuously collaborating with those organizations to solve problems instead of imposing solutions on them, will in general make this challenge of both minimizing the impact and maximizing buyin of necessary controls.

Answer 2

As with any security additions that limit end users, you get backlash. Usually this passes quickly as they get used to it, the more mature (mentally) and professional the group, the less time it takes.

You don't have to do anything except politely defend the new security measures whenever needful. But, even if you personally disagree with some of the measures, do NOT let people know that. Just be professional.

Answer 3

Security isn't an "on" or "off" thing. Each individual measure you take in the hope of improving security also has a cost, and the value of the improvement in security needs to be weighed against that cost.

As an extreme example, turning off your servers and locking them in a vault will make them considerably more secure. Yet, if your customers can't access your servers to buy things from you and you can't access them to sell things, your company won't have any revenue and the overall benefit will be (very) negative.

So as a security engineer you need to to consider not just how to make things more secure but do risk analysis and risk management: understand what risks you're taking, why, what bad things could happen and their probabilities, and the cost of those bad things should they happen. You should regularly find yourself saying, "yes, this bad thing could happen with some probability, but it's more cost effective to run that risk than to try to mitigate it further."

For your jump host, if you're surprised by the reaction of the people who need to access that server you missed something in your analysis. (You can't do a risk-benefit analysis if you don't know how much implementing a particular measure will make the users' jobs easier or more difficult.) You need to try to find out before you implement a security measure how much harder it will make users' lives. And once you've worked that out, and why it makes things harder, you're also in a better position to implement mitigating measures.

Using the example of a jump host, not allowing direct login might mean not only that users have to type an ssh command twice but also that copying files back or forth (say, to pull a backup out of the system) becomes more difficult. You might be able to mitigate this by preparing an entry for their SSH config files that uses ProxyCommand to set things up so they can still use a single SSH command just as they used to do.

Showing that you're considering how your changes affect other people's jobs will probably go a long way toward making your changes more acceptable to them.

Answer 4

When faced with resistance from other employees in implementing what is ultimately necessary and beneficial to the company, how can one best explain the situation diplomatically and effectively?

Most changes take time. Also, most people are reluctant to change at first for several reasons, mostly due to the fact that they are already used to the current procedures and the new ones result unfamiliar to them.

A way to make those people stick to the change process is to make them aware of the benefits it will have after they have learned the new way.

People may get frustrated at first because things are different than they were used to (sometimes meaning they have a temporal drop in efficiency while they are learning), so telling them "hey, bear with me, after you handle the new policies this will be even easier than before" may help them take the process with a better attitude.

In short, they will eventually come to like it with time (that is, if the changes were not a failure), so a bit of patience from your side is also recommended.

As a side note, it is important to keep in mind that "what is necessary and beneficial to the company" may not be the case for the final users or employees. This could be one reason why those people are not comfortable with the changes, as usually changes in policies are made with the company's benefit as a whole (income, metrics, standards, regulations, etc.) rather than being beneficial to the employee/user directly (like a UX redesign for example).

Answer 5

"When faced with resistance from other employees in implementing what is ultimately necessary and beneficial to the company, how can one best explain the situation diplomatically and effectively?"

I think this is the wrong approach. Of course you can try and explain again. But that will not help the users.

So, what I would like to suggest is:

1. Find out what they are trying to do when security measures get in the way.

2. Find a way for them to be as productive as before. Maybe with the help of other departments.

Understanding the necessity for the measure is only one tiny part. That part is what matters to you. But to them it matters how to do their job efficiently without having to bother with those measures. So, I feel this is where you can get them on board.

Answer 6

The bottom-line question asks how to explain... effectively...

In Advance!

SOX and the like are the law. Thou Shalt Comply and the users will eventually get over that fact, but the acceptance-clock starts when they get the message.

Collaboratively!

To wit, the roll-out needs more process than clench-teeth, flip-switch. It's not enough to announce changes. Give end-users a sense of agency in making sure the transition goes smoothly, and discuss the issues in their language. You want to implement technology X but end-users care about performing process Y for which they use tool Z. You might not have a UML diagram for everything, but at least the major day-to-day activities should probably have an interaction diagram that will help you figure out what subjects to bring up with which user populations. (In your scenario, one of those

To comply with $REGULATION, we are required to secure $SERVICE because it contains information about $TOPIC. We predict an impact to $TOOLS. Since this may touch on how you perform $TASK, we'd like to speak with $PERSONNEL to help minimize any disruption as we deploy these changes. You should hear more details about this by $DATE.