News: 1601284032

So, a company that sells tools for locking down data, commissions a survey that show companies need to lock down their data more? No surprises there.

In the real world however, locking everything down is rarely a good idea. People often do need more access than you might expect in order to do their jobs efficiently. Implementing "work to rule" always causes productivity to plummet.

I have worked at places where the systems are so locked down that you really struggle to do your job. Such companies have such strict access policies that projects can be delayed for weeks while you chase up the only person who has access permissions (and yet not the skills or intelligence) to do the five minute fix you need. On several occasions I have had to resort to other methods of gaining access to systems just to get the job done.

What I am trying to say is, rather than trying to lock down everything and contrain your employees into narrowly defined processes of what management thinks is their job; hire competent people, give them all the access they ask for, and trust them to use that access appropriately. That is how you get work done.

all too often the data you need, but aren't authorised to have is something very trivial (my company locks down FX rates because the guy who set it up didn't think) or is something that can easily be worked out - I can't see company set up in our ERP - but have table access in dev to see the same and it only shows things like company code currency and hierarchy which are public information anyway!

If you're not an FX trader you don't need access to FX rates. If you have such access then you could, for instance, trade on your own account using data supplied by the company. The company might not like that. The company might, indeed, not be allowed to let you do that.

We have everything locked down. You only get access to what you need. Occasionally people will need additional access. The owner of the affected data gives their okay and access to the data is added to that user's rights.

It works just fine. Even as IT administrators, we don't have admin privileges on our standard accounts and we only have access to IT related areas or to projects in other departments that we are working on.

We could give ourselves access, but we don't.

Also, since GDPR, giving the users access to more data than they need is a problem and our DPO is very strict about ensuring people don't get access to sensitive information that they don't need access to.

It depresses me that, in 2020, after who knows how many leaks of sensitive data, someone can post a comment like this. I mean, seriously, when was it that people worked out that this kind of approach was a really bad idea if data mattered at all? And yet presumably this person has a job: I just hope it's not in an organisation that holds any data I care about.

(What is even more depressing is that I'll now get downvotes from people who also think this is a good approach. What kind of educational failure leads to this?)

tfb:

Agree that some controls are needed. But the AC said " ...all the access they ask for... " and that isn't the same as unlimited . Actually it could be a lot less than broad-brush permissions given out by IT or management without thinking what individuals actually need.

It shouldn't be what they ask for, it is what they need to perform their job.

They can ask, but the data owner still has to okay the access.

Who, when why records are altered are not far more important that the actual data the records contain. Metadata rules.

It's also about creating permanent billable professionally credentialed positions at this point. We're finding one or two administrative assistants with data entry instructions thicker than a phone book rather than applications tailored to help them complete their jobs because the developers and business analysts are all about security, using the latest developer tools and creating more and more roles that will constantly need ever increasing granularity. Then the developing bods create uet another 'administrative' role management 'tool' and force it back on the customer (user) because IT bods don't do data entry. I've so many conflicting 'role management tools that do not talk to one another, IT is aware of the issue so the policy becomes 'it's the customers responsibility'. All to prevent one or two people from seeing something they "should not" in an organization. I just turned down a request to create a read only role in one of our projects when I realized the development and implementation cost exceeded the project itself by a factor or around 2. IT was all in for all that sweet billing time. Four IT pros watching 1 to 2 end users doing actual work at the end.

Oh, and each apps role management tool is the most important one on the planet and should be intuitively obvious to everyone. I've at least 16 to maintain at the moment. Good luck when a password expires. The end user cannot differentiate between their portal password going belly up and calls the application support to reset passwords. We spend more time solving portal security issues and training than how to use our app on that portal!

IT ends up blaming the admin assistant with not reading the instructions or following procedures (not written by IT either, also offloaded) so their apps and portals are blameless.

This does not surprise me. Has anyone ever seen the blood bath that follows a permissions reset to ensure everyone has only the permissions they need? I've seen it happen twice, not a pretty site and many an arse kicked because of it.

We just went through this with each department head.

We actually listed out all of the access the users in that department had, checked what was actually necessary and put that into roles, as opposed to individual users within a department having differing access.

Apart from 2 overseen access groups in one department, the roll-out went smoothly with no complaints. A few users received more rights than before, many had rights taken away (E.g. had moved departments and still had access to the old departments data, which they shouldn't).

That good sir is the right way to do it.

The problem is, well loads of problems, you get one person with power saying Im important and so is this team so we need access. Any new members automatically get the access, the function of the team changes/person moves on but you still get the same access. It happened to me and I was thinking I should not have access to this i.e. it was HR data and I did nothing with it (in case you are wondering).

Another thing, users will hold onto their access because its 'sods law in action' when you rescind it and an urgent job comes in that requires you to have that access. Its then the joys of having to go through all the hoops to get it back again.

If you have a team that have been there for a while then access is easier to manage, since it becomes part of their job and can be split amongst team members. However, I've seen this personally, largescale changes cause teams to be split up, moved to other functions and you lose the experience. Nobody and I mean nobody wants to become the person who creates access/rescind for other users, soooooo boring.

Our managers need to review and sign a sheet annually which details the access rights their staff have.

They also have to ensure their staff are trained annually in data protection and record keeping.

If they fail to do either of these they are destined for a disciplinary within 3 months if not rectified.

Access permissions are audited annually at random within the organisation and several times managers have been caught out as staff have left, moved etc and the list hasn't been updated.

Companies waste so much time limiting access to the bear minimum. I'm not suggesting everything should be open but broad classes of information should be open to those who need, or might need it. My company has a need-to-know policy for code and it really stifles innovation. If you can't trust someone, don't employ them - once you've employed them then trust them to a reasonable extent with the data that they need or might need.

While I agree with almost all of what you say for non-sensitive data, the key thing is to separate that which is legitimate access (and yes, it is annoying when you are blocked from something you need for no good reason) and having staff with too much access just in case. Any organisation which does not take this seriously is likely to be a news headline some day.

'Employ people you trust, trust people you employ' is a nice theory. But it's a disastrously bad one.

Let's say you have a hundred people you need to trust. How do you make those trust decisions? Remember that every decision to trust someone you make must be correct : it only takes a single person who you trusted when you should not have trusted them to cause very bad trouble indeed. And, you know, there have been a number of fairly well-known occasions where these trust decisions were not made correctly with very bad consequences: Barings trusted Nick Leeson, when they should not have, for instance, and it killed them; there are quite a number of other examples.

Th trust problem is one of a number of related problems which all follow the same pattern: you have to make n decisions: in order for you to succeed every decision must be correct; your opponent succeeds if any one of the decisions you make is wrong.

Well, OK, let's say you have access to a magic trustometer: it will tell you, completely reliably, if someone is trustworthy. And let's say you have an employee, say me, you have decided that you can trust. So you give that employee access to sensitive data. Unfortunately that employee has a family. Even more unfortunately bad people know they have a family. Most unfortunately of all the bad people are now posting bits of that employee's family to them. Can you still trust that person? What should the magic trustometer read now? Should the magic trustometer ever read true?

(But, of course, you say, that sort of scenario never happens. Because there are no bad people who might think that, well, this person who has access to the account database for a large bank might be persuaded to do interesting things with that access if we put suitable pressure on them. Of course there are not people like that. Because, you know, you can trust people not to think like that.)

Sometimes it’s not all bad when someone adjacent to the dev team can see their changes on their trello board and give a heads up that systemic failure events dovetail perfectly with said trello board timeline.

It’s not all bad when someone organically discovers your code in GitHub enterprise and recognizes that they can become a consumer of your APIs/services.

Lock it all down, but expect less of “You weren’t supposed to see that, but thank the gods you did.”

At a previous organisation Trello was rolled out by means of an unexpected mass-emailing from an external organisation inviting one to follow a URL and log in at an external website with one's company credentials.

After being enrolled about a week or so, increasing rate of spam emails from Trello, & finally I set a new email rule "if contains then delete" . Work then continued as normal.

1) No, you're not getting local admin.

2) No, you're not getting domain admin, either.

3) No, unless you are required to have it for your job, you're not getting access to an account, data, or a system.

4) If you require it for your job, I want that in writing, because then it exonerates me.

GDPR and the DPA are very, very, very clear on this and always have been.

If you don't NEED access then you should not have it.

And the POTENTIAL for access is considered identically to actual access. So if you're even *able* to access that file, as far as DPA/GDPR are concerned, you have access to that file. If you have admin and are able to access all files, you have access to all files. That might be necessary for your job if you're actually an IT admin. It's not necessary for your job if you're just the boss.

My boss has LESS access to the system than I do. Because he's not IT, and I'm the IT Manager. That's how it should always be. If it's not, you are literally in breach of the DPA and/or GDPR, whether or not anything actually ever happens or even if that data is NEVER accessed. Just the potential is enough for a fine / conviction.

And GDPR / DPA has PERSONAL LIABILITY now, too. So it's not a case that if I slip up, the company gets a slap on the wrist. I can be personally fined or charged for allowing it. So I'm taking no chances whatsoever. And will consider any bypass of that a deliberate breach.

If you do not know all this, and you work in IT, I suggest you seek legal advice and/or immediately cease and desist from such actions.

Now, could someone explain to me why a call center worker "needs" access to my home address and telephone number (and that of every single customer they have), when they could just press a button marked "Dispatch to Customer" or "Ring Customer" and never actually see those details, unless I request a change to them or there needs to be a security check?

Don't even get me started on credit checks.