At my current job, some of my duties are related to security.

I know security and usability are inversely proportional, and because of that I have tried very hard to find the proper balance.

I have also taken care of documenting everything properly, both for the end user to whom these policies may apply and for future systems administrators that may work in the same position.

The problem I am having and failing at solving is the following:

Some coworkers whose access privileges are equal to mine, can disable these security policies at will if they feel uncomfortable with them - or, more frequently, if they do not know how to work under such restrictions. I have repeatedly elevated my concerns to my supervisors with regards to this issue, but the problem persists, basically because management is failing at enforcing their own security policies and raising the staff's security awareness.

The question is: what do I do? It seems wrong to me that management is less worried about this than I am.

This problem is important enough for me that I am thinking about quitting this job.

  • 12
    Why are you posting this question under your own name? Your profile lists your present employer, so you may be held liable for diffamation. Please consider re-posting anonymously. May 5, 2014 at 8:25
  • 7
    From the wikipedia article on defamation: "In Spain, the crime of calumny (Article 205 of the Penal Code) consists of offending one's reputation knowing the falsity of the offense". Emphasis in "falsity". Even my supervisors are aware of this situation, there's no falsity involved whatsoever. The question is related to the lack or responsibility in enforcing a critical aspect in our industry. So, thanks, but I'd rather stay by my words.
    – dawud
    May 5, 2014 at 10:11
  • 2
    Some users might find quite unusable to need to use both an RSA key and a Kerberos ticket to login to a machine, just to find out they can only issue commands using sudo.
    – dawud
    May 5, 2014 at 15:12
  • @Chad I can't go into details of our whole security infrastructure, take it as what it is: an example.
    – dawud
    May 5, 2014 at 17:52
  • 2
    This question appears to be off-topic because it is a rant not a real question. Whether or not to quit is off topic. May 5, 2014 at 18:20

5 Answers 5


You've done everything you should.

You've followed the proper procedures, documented them, and escalated your concerns (I presume in writing/email) to your superiors.

I suggest this is where your responsibility ends and that of management begins.

However, if you wish to act beyond your responsibility, then speak with your coworkers about why they feel the need to bypass security. Offer to research effective ways to work within the system for them. Be a resource for them.

Remove their arguments in favor of bypassing security.

For every reason someone presents in favor of bypassing, have an in-system solution available.

  • I should add that I brought this my supervisors attention in a meeting where the rest of the operations team was present. The problem is they are aware of what they do. I've already voice my concerns, and explain/documented what would be a security-conscious way to operate the systems. I may have not been clear about this point: security measures are bypassed only because it's easier than operating correctly.
    – dawud
    May 5, 2014 at 13:54
  • Dan is right. You've met your responsibility as a security professional, very well indeed. You have made your co-workers and the management of the company aware of the risks of allowing some exceptions to security procedures. That's what you need to do.
    – O. Jones
    May 6, 2014 at 13:29
  • 3
    One other thing that should be done: keep electronic and paper copies (dated) of these communications about your concerns offsite so that you have your own proof that you've escalated them.
    – alroc
    Mar 26, 2017 at 11:32

At one location I was responsible for a large amount of PII data. Development felt that they needed direct access to the web servers in order to debug issues that came up. However this meant that all of the developers also had access to this data and routinely attached their debuggers to the production servers...

To fix this we established staging servers which were identical in hardware, software and patch levels to production. The DBA setup a few jobs which regularly moved data from production to staging while scrambling the PII data in such a way it was impossible to reconstruct the original data but maintained the associations necessary to debug problems. Networking was responsible for ensuring all hardware, patch and software levels were consistent between the environments...and I mean everything: routers, network cards, etc.

We then completely cut off development from production. To get management buy in I only had to describe what those devs could potentially do with the data and the cost the company would bear if/when someone leaked it. Therefore it was in their long term best interest to ensure that only a couple of highly vetted people had full access.

To get developer buy in, we made changes to our bug reporting/verifying procedures. When a bug report was escalated by support it would go to QA first. They would reproduce it on the Staging servers. Once it was reproducible then it was assigned to dev to fix. If they couldn't reproduce it in staging then QA would work with the production team to see if it was just a specific data issue.

This did increase the amount of time between identifying a problem and fixing it; however it resulted in a far more robust and secure system while limiting the amount of developer time spent trying to figure out a problem. The devs grumbled at first but later agreed that it was better that they weren't spending all their time trying to figure out every little problem.

This resulted in a decreased cost per problem (dev's are a LOT more expensive than QA people), which, again, was a good thing as far as management was concerned.

  • This is a problem within the operations team. I get your point, though, and in fact, these kind of separation is implemented here: we have three different environments: DEV, QA and PROD. Developers are granted a quite restricted role-based access to the DEV/QA machines.
    – dawud
    May 5, 2014 at 14:36
  • @dawud: So, now my curiosity is up. Why would ops ever side step security? That seems completely anathema to their job.
    – NotMe
    May 5, 2014 at 14:55
  • Indeed. Not all operators here have the same set of skills, arguably, some of them have a subset of the skills, but I digress. Read my comment to @Dan Pichelman's answer, it should make it a little more clear.
    – dawud
    May 5, 2014 at 15:05
  • @dawud: As it's the ops team themselves and without more detailed information about what it is they are bypassing (not that I'd want you to post that anyway), Dan's answer is probably the best one here.
    – NotMe
    May 5, 2014 at 15:09

It seems to me that you have 4 basic options here.

  1. Push harder on the issue, in the hopes that management will start caring.
    • Given that they don't seem to care now, making more noise about it doesn't really sound like a recipe for success.
    • You could try a demonstration, exposing their vulnerabilities, and why they should care about security, but this will probably end badly. (I've seen it end badly for the person in question every time.)
  2. Ignore the problem.
    • You've already brought it to their attention, they don't seem to care, and they're paying you either way, so... I don't see any particular reason you should care, to be honest.
    • Make sure you to CYA and all, but all you can do is do the work and tell management there's a problem; you can't make them care about what they ought to be caring about.
  3. Quit.
    • You say the problem is serious enough to consider quitting over, and although I don't understand why, that's always an option. You can find a new job, if you feel that strongly about it.
  4. Profit!
    • If security is lax, you can always use this for mutual gain between you and your employer. For instance, finding security consultants to help out, where you get a finders fee for getting the security consultants some business and your employer gets better security with increased usability so people are less likely to want to disable it.

Given your industry, and greater-than-normal job mobility, I'd go with 2 or 3. I'd favor just shrugging my shoulders and ignoring the fact that management doesn't care about not having any security, but if you feel strongly enough about it that it's impacting your job satisfaction, getting a more satisfying job sounds like a good option too, since it sure doesn't seem like the situation at your current job is going to change to where you'll be satisfied.

  • 2
    #4 is does not belong on this site period. Any suggestion that someone should act in a manner that is illegal is not appropriate here. May 5, 2014 at 16:02
  • 3
    @Chad Not all actions that would fulfill #4 are, in fact, illegal. The fact that you assume the only way to profit from lax security is to break the law says more about you than it does about me, in fact. May 5, 2014 at 16:45
  • @Chad "Completely legal" is a degree of legality. May 5, 2014 at 16:55
  • @Chad [sale of/commission on/finder's fee for] Security services. May 5, 2014 at 17:07
  • @Chad If you consider those refer-a-friend hiring bonuses to be kickbacks and graft, you might have a point. Otherwise, there's nothing wrong with providing your employer an additional service and getting fairly compensated for your role in it. May 5, 2014 at 17:23

I don't like giving "just cover yourself" advice, but people are going over your head and around the system. You know it and more importantly they know it.

Make sure you have documentation on security requests. If someone in charge wants to make "UserX" and admin, it's not your job to question - apparently.

Also, I would create user/access reports, run them periodically and archive. Feel free to submit such a report to management and see if they want to change their mind.

If any breaches or data corruption occur, make sure you can identify if these broken rules are the culprit. You don't have to say "I told you so." but that doesn't mean you have to take the blame either.

I know security is important but policies like creating powerful passwords and changing them often might need a better strategy.


You have done very well in fulfilling your responsibilities as a IT security professional. Effective documentation and appropriate escalation are the first steps in making management aware of this issue.

As to how to gain momentum in changing situation, does your company undergo independent audits either from external parties or internally through an internal audit function?

If yes, does your company maintain a security policy guiding the actions and expectations of end users? Depending on the size and maturity of your company, a documented information security policy should be in place.

If the answer to both of the above questions is yes, then a competent and independent assurance / compliance function should document the non-compliance issue during the next audit done. The report will be an additional source of leverage for management to change, as such reports are often required to be seen and acknowledged by senior management.

A major issue with your current policy I see working in the IT security profession as an IT auditor, is that users at a lower level of authority can override a restriction given by a higher level of authority, which violates the principle of least privilege. This problem poses major risk to your company in terms of liability.

more frequently, if they do not know how to work under such restrictions

Therefore, educate the remaining users on how to remain secure without compromising productivity. In other words, help your colleagues work within the security constraints. Help them learn why these security controls are in place, and what the end goal of cybersecurity is.

As an former IT auditor and current IT security analyst, I have found that non-cooperation with the IT security mission of a company to almost never be intentional. Rather, user resistance is almost always due to ignorance or productivity decline that compliance with the security controls brings with it. Therefore, if cooperation is to be sought from end users, enhancing user awareness is key.

You must log in to answer this question.

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