Bdtyktl

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.

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.

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.

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.

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.