13

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?

  • 14
    How much involvement did the users have in reviewing and testing the policies before they went live? – Patricia Shanahan Nov 7 '17 at 4:39
  • 1
    What's the actual problem? Non-compliance? Grumbling? The latter is to be expected when policies change. How you can sell something like this depends on details you haven't provided, specifically the actual reasons you're implementing changes. – Lilienthal Nov 7 '17 at 7:53
  • 1
    @Lilienthal - yes end users are complaining that the new policies are cumbersome and slowing down users work. I only used one new policy as an example. I also added more description on the reasoning for implementing such policies as you had requested. – Anthony Nov 8 '17 at 1:05
  • 1
    @Anthony Thanks for clarifying. Are these policies motivated by legal requirements or is it simply a matter of increasing operational security in an era of leaks and highly visible public security scandals? And has either reason been clearly comunicated to your end users? What I mainly wanted to ask in my first comment is what your main goal right now is. I assume that given your description there's no real way for users to not comply and you're just trying to find a strategy to mitigate the grumbling and get users to see why you're making things more complicated for them? – Lilienthal Nov 8 '17 at 9:24
  • 4
    "the new security measure are getting in the way of them performing their jobs" - What about finding a technical solution to specific problems? "Getting in the way" is not specific. Example: "I didn't need to supply my password every time on this page before; now it is slowing down my work." Solutions: password-less logins using private/public key pairs, use a password manager, etc. – Brandin Nov 8 '17 at 12:00
6

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.

  • You almost lost me at 'a bunch of crying from the engineers because "it's different."'. As an engineer that comes across as very condescending. The rest of your post is spot on, but this one phrase got me hackles up. We don't mind different - what we don't want is changes that now make our jobs harder. – tddmonkey Jan 4 at 14:19
  • We are moving to DevSecOps model so this is helpful. Can you expand on the aspect of WireGuard being more secure? In your opinion, how easy is the product to use? – Anthony Jan 4 at 22:36
  • It protects all ports by default and you don't have to expose e.g. port 22. From an end user perspective it's super easy, it's install wireguard from the App Store and then import the config file you give them, then it's all-ports transparent access. Of course you have to set up the vpn endpoint, we use algovpn and it's add a user, run the script, it re-spins an AWS instance, done and done. Can do IPsec and ssh tunneling and stuff with it if you really want to as well. – mxyzplk Jan 4 at 23:25
10

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.

  • 2
    It also might be helpful when defending the new security measures to emphasize that there is no chance of the changes being reversed as they are driven by external requirements. This might stop the grumbling quicker when people realize their complaints are fruitless. – David K Nov 30 '17 at 13:27
  • 1
    @DavidK Any sane person will find a thin veiled lie in such a statement. While security requirements can come from outside, the interpretation and implementation is internal. And if security chose the most user-abusive way of implementing requirements, the people will quickly find out and they'll lose even more trust. Trust is critical for security and without it, people will go behind your back. – Mavrik Jan 4 at 11:57
  • The most common cause of backlash is that security engineers poorly implemented the change. If you didn't know just how you were going to inconvenience the affected users, you failed to properly understand your change. If you did know, and you didn't take available steps to mitigate the inconvenience, you are now needlessly costing your company money (in lost productivity) and, worse yet, you are developing a hostile attitude toward security in your users, which can only hurt your overall security. – cjs Jan 10 at 8:01
  • (cont.) Ideally, you should be able to minimize inconvenience enough that users won't be hostile to the change. When you can't, you should be able to present a clear and convincing argument as to why the users should pay the price for the particular security feature. – cjs Jan 10 at 8:02
  • @cjs I have a lot of experience implementing security, the number one most common cause of backlash is people being crybabies. Not the security being poorly implemented or anything else. It fades away when they get over themselves. – Kilisi Jan 10 at 9:41
8

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).

8

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.

  • Just please don't turn into one of those people who think "Yes, this bad thing could happen, but it would be to other people, so whatever." because we have too many of those already. – Erik Nov 30 '17 at 8:21
  • 1
    @Erik, that would be precisely the opposite of what I'm saying here. Something bad happening to other people is something that has a non-zero chance of coming back to you in a bad way. This could be via making others resent you and reducing their cooperativeness towards you or problems with their systems causing you trouble in some way. To some degree, everybody dealing with IT security is in it together with everybody else. – cjs Mar 18 '18 at 3:12
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.

1

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .