Too many staff have privileged work accounts for no good reason, reckon IT bods Around 40 per cent of staff in British and American corporations have access to sensitive data that they don't need to complete their jobs, according to recent research. In a survey commissioned by IT security firm Forcepoint of just under 900 IT professionals, 40 per cent of commercial sector respondents and 36 per cent …
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!
This is exactly why there are issues, and you obviously don't work in finance or accounts.
FX Rates are needed for far more business activity than FX Trading - any payment/receipt that is not in your companies base/accounting currency needs converted, so need FX Rates.
The result of you deciding only FX Traders need access is every other department or user that needs FX Rates go and source there own and we now have lots of Excel spreadsheets with different FX Rates being used.
Yes data needs to be secured and controlled but you need to understand the actual requirements and uses of the data, to make accurate decisions on the controls needed.
I do (or did) work in finance in fact. For your example: no, you don't need access to FX rates, you need access to a system that lets you say 'for this thing, convert it to our base currency, and leave an audit trail. In other words you need extremely restricted, and audited, access to FX rates.
@tfb I'm not sure you worked in finance. It isn't enough to just be confident the computer does something right all the time. How do you check? How do you project the future? How do you revalue assets? How do you do that one calc outside the system that every company has many of? How do you deal with joint venture.
FX rates are one of the basic tools here.
Also most users dont have access or ability to read audit trails - auditors would laugh at you for suggesting that as a business op.
I might forgive you if you confused market fx rates and operational company FX rates, but you work in finance so should know.
I have worked in finance and IT designing finance systems and most of them require FX exposure or it is so obvious what the rates are that securing them (beyond RO) is pointless
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.
I'm sure all, well, I'd like like to say all, but let's settle for most, most of us here are that sort of trusted people, but how can you tell whether someone is that sort of trusted person until after you have employed them?
Bit of a catch-22, hence you either need logging (and auditing), or you need more restricted permissions and only a subset of people able to grant higher permissions to others and only when a necessary reason is provided?
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.
Once, when I was teaching computer science, I told the head of IT that if I needed root I would just ask for it. He said he probably wouldn't give it to me. They had reasonably good security in the computer science department.
Then I was trying to debug a suid root program with dtrace or strace (I forget which one) and told the head of IT I needed root. He thought for awhile and opened up a root shell on my machine. Then I discovered that the shared file server didn't trust root credentials from a remote machine. I couldn't even access my own files from the root shell!
So I transferred the relevant files to /tmp and proceeded to successfully debug the suid root program. Good security.
Well, someone I know rather well has a job a major part of which is controlling privileged access (largely but not only in the form of sudo rule control). The amount of time this person spends explaining, repeatedly and in depth, to people why they can't have all the access they ask for and why such access would be a really, really bad idea is astonishing. In fact I've just asked them and they say perhaps 20% of their job is this. I think, based on the amount of time we spend talking about it in the evenings and the amount of stress it causes, that it's more.
People simply don't understand what the implications of the access they want are, or what the difference is between the access they want and the access they need, or what the audit requirements of the organisation are or many other things.
I think we're seeing this in comments here as well. People are good at working out what will make their job easy, but becoming good at working out what will both make their job possible and not expose the organisation they work to to undue risk turns out to be hard. And by 'hard' I don't mean 'people are too stupid to understand it', I mean hard: I think that thinking about the implications of various sorts of privileged access is a genuinely hard problem in the mathematical sense.
However I think a lot of people are still living in the world I lived in in, say, 1995, and I don't think that's excusable. In 1995 I would have been upset if I didn't get root access pretty quickly after starting a new job doing sysadmin. Today I would be equally upset if I, or anyone, ever had unconstrained root access.
I'm the lead of a CAB, and you wouldn't believe the amount of grief I get when I push back on changes that don't meet the security requirements - including bullying, complaints to management, escalations to VPs - you name it.
Some of their favorite replies:
- We've always done it this way and nobody has ever pushed back.
- Chicken Little
- It's been vetted and approved by the Engineering Council.
- You're going to cause us to miss our deadline.
I often wonder why I don't just give in (as are the change requesters!) and approve such changes, but since my job requirements include safeguarding the integrity of the systems I don't see how I could.
"you wouldn't believe the amount of grief I get when I push back on changes that don't meet the security requirements" I think we all would! I feel sorry for people working in change as IT is generally hated by users for being seen as getting in the way, and change is hated by IT staff as its seen to get in the way! Its all a balance. Where I worked until the turn of the year for an enterprise MSP we made as many changes as we reasonably could in to standard changes that didn't have to go to CAB for approval and only had to be peer reviewed, this reduced the delays on stuff that really didn't need CAB approval. Also what didn't help was the fact that the people in CAB weren't that technical and didn't have a clue what half the changes entailed!
Ah yes - the standard/template changes. No peer review was needed for those until recently.
One of them accidentally ended up in our review queue recently and we started scrutinizing it before we realized we weren't supposed to.
Turned out the change itself far exceeded the scope the template was approved for, was missing required supporting documentation, and so forth.
The engineer was hopping mad (still is) when we hit the "reject" button on it. She still doesn't realize that we could have reported her for falsification of record, I think.
We did bring it up with the coordinator, who promptly put the kibosh on all standard/template changes until proper controls can be implemented (i.e. peer review).
Now the engineer is even more mad at us... Of course, it doesn't seem to dawn on her that she brought this on herself.
As for non SMEs reviewing changes, that's often a real problem. In a previous job our changes had to be approved by close to 40 (!) people - about 50% of the entire IT-staff.
Just to prove the point I once wrote a change in such technical jargon that I was certain that I was the only one who could understand what I was even going to do.
Only one reviewer objected and demanded clarification.
Not long after that I wrote another change and deliberately added some PROD network devices in it that were managed by another team and that I was not allowed to touch.
As I expected, it sailed right through the CAB. Even the owners of those devices signed off. There was one reviewer who objected and refused to approve it: the same guy who had asked questions about my earlier change.
To this day I often sneak what I call a "control bug" into work that has to be peer-reviewed. Serious enough to cause harm, obvious enough that it is spotted easily, but obscure enough that anyone who rubber-stamps it will miss it.
I've been the person who had to explain that no, we are not going to authorize `sudo vi /etc/hosts` for a dev on production or QA (not a made up example) because that gives unrestricted root. You are absolutely correct that many times, the requester does not understand the implications of what they are asking for.
On the other hand, I've also been the person filing an access request. At one client recently, I was appointed the unofficial access requester, because mysteriously, my access requests were always approved. Maybe it was the fact that I spelled out explicitly what the business justification was, and crafted the access request to be the minimum necessary to meet that business justification. It added value to the client, and made them happy, so I was happy to take home the paycheck...
Years ago we had a developer who needed a lot of code releases to Prod to get things right. We flagged it to management and the situation became a bit tense.
Then one day he happily submitted a change and said that this would be the last one for sure - he guaranteed it.
Suspicions duly awakened, I scrutinized his code even more than usual and discovered that he had cleverly changed his code to include a reference to an external file that resided in a repository that he had write-access to.
If we had promoted his "last and final version" he would have been able to self-deploy future changes with that one include statement...
And Developers wonder why Production Engineers don't trust them...
There is a very big risk in giving too much access, but there is also a risk in giving too little. The risk usually shows itself in people doing extra work to get around the restrictions. Here's a basic story of a situation that is all too common:
I once did a short job writing some code with a small team who all started at the same time. After figuring out the specs of the task and how development would work, we decided we needed a database server to store data needed for development. Local IT agreed and quickly provided us a box to run that on. It was set up the same day. Then we tried to set up a repo on the default code system. That took longer because our accounts didn't have permissions to do anything with it and it was run by a larger site of the company. We sent email there, waited several hours, were told that someone else handles this, sent email to them, waited until the next day, got an email saying we needed to prove our need for the permission, brought in our managers, waited a few hours, got an email right before we left that the permission was granted, discovered that we now had read but not write or create, sent another email, waited until the next day, asked again, finally got write permission and they created a repo for us, and finally we could exchange code. During this annoying process, we had frequently discussed using our database server to run a basic git server. We didn't, but we considered it because we would be more productive if we could use a version control system; our only other option would have been to email code around, which wouldn't have been very secure either. Later in this job, we wanted to send a very large file containing data to another team. They asked us to place this file (approximately 35 GB) in our git repo. Why? They didn't have anything else to which both teams had access and they didn't want to waste days to get one.
The same can happen with other types of jobs. If people need (or think they need) to have certain kinds of data or take certain kinds of actions, they'll do what they have to to do this. If security is slow to respond to this kind of access request, fails to consider whether people actually need things, or doesn't provide necessary tools, they run the risk that users will try to circumvent them. Based on the way security is run, some of the more dangerous ways this can show itself may be caught and more egregious offenses can be disciplined. Even if that's the case, the landscape of threats is probably worse and productivity will be impaired. These concerns are probably most relevant to small companies. Large ones have the resources to have a dedicated security team and lots of systems so people can quickly be given access to things they need. Smaller companies probably put all this on IT. If IT isn't sufficiently fast or organized about granting permissions, expect users to take the route of less effort which will cause us to have to take the route of damage control.
" The amount of time this person spends explaining, repeatedly and in depth, to people why they can't have all the access they ask for and why such access would be a really, really bad idea is astonishing"
Write it out once and give them a copy instead of spending time explaining.
Sounds like an ad hominem attack to me. It really doesn't matter what this company sells; it matters whether they're right.
Quite frankly, the percentage of people with too much access that they found is an average. From experience I can tell you that some companies are much closer to 100%...
As for your statement that "locking everything down is rarely a good idea", that's simply misguided. Access should be based on "default deny", not on some expectation.
Regarding your complaint about "systems are so locked down that you really struggle to do your job", you may be surprised that such an approach is not considered to be secure.
Security has three requirements: Confidentiality, Intergrity, and Availabliity. If you can't get to the stuff you truly need to get to it cannot be considered secure.
Unfortunately, and you are right in this, too many people think that full security means locking everything and throwing away the key.
Oh, how I wish companies would require everyone (including the brass!) to take basic cyber security training. Just an hour or to convey the basic principles would put an end to a lot of the issues.
"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."
So which bit did Morrissons get wrong? It was the trust bit, I suppose?
The threat is NOT from the employee, but from whomever is controlling the interactions between the employee's computer and the rest of your network.
In a world of company-issued laptops that we are encouraged to take home, that's the real threat.
Try reworking the balance of costs with that in mind.
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.
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).
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.
There should be three levels of access:
1) no access
2) permanent access
3) "on-demand" access
For #3 you have an automated procedure set up where access can be requested to something you've already been approved for on a time-limited basis. You input that you need the access starting Wednesday at 9AM until the following Monday at 5PM, and why you need the access, and the system enables it for you without human intervention, and automatically disables it at the specified cutoff time.
That prevents people from having permanent access to something they only occasionally need, and maintains logs so you can you go back and see who is requesting access, what they say it is for, and so on. Maybe you have 50 people who might need access to sensitive HR data at one time or another, but only 5 who need that access at all times, so you limit the scope for potential breaches and if something happens it is easier to figure out.
This would also help for phishing type schemes as someone having to put in a reason to enable access to something might make them think a bit more about that email they received and become suspicious enough to start asking questions first.
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.)
"'Employ people you trust, trust people you employ' "
I don't disagree with this, but it's easier if you're running a startup and can choose your employee from scratch. If I'm a lowly IT Security director of a company with thousands of employees, some of which are absolute donkeys (me included), I can't just go out and terminate or train all the people I don't trust. I have to have some kind of systems controls to limit the damage.
And the person who you trust clicks a booby-trapped email and their excessive access lets the destruction spread.
Then you start to wonder whether open access was a good idea. Experience is a dear teacher. Do you really want to learn lessons like that the expensive way?
My experience with git repos is that there is a culture in many developers of "give the world access", even to those individuals who have no legitimate reason to access the repo in question. It's a battle I'm currently fighting, that I do not need access to the git repos. My boss agrees with me. But devs repeatedly try and give me access in an effort to make me do their job for them. All because I "might need" access to the repo.
DPA , GDPR and SOX are very clear that trust is not a defensible plank of security provision.
You have to prove people have the minimum amount of access to fulfil their role and that access to sensitive data is logged where possible.
I am so glad I no longer have responsibility for granting access because so few companies understand that it is a business problem.
Now if the business finds this restrictive then they need to get on board and define what access they need. Most businesses if asked could not tell you what access they need to their data.
After SOX I started an annual review of roles and had a lot of push back taking rights off users until the CFO realised they were eligible to share a cell with BUBBA if it went wrong. From then on I just supplied the data and finance did the restricting, for those feeling the pain can I recommend this option?
Data and access are a business problem administered by IT. Not an IT problem, we can help fix it if you want.
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 <Trello> then delete" . Work then continued as normal.
"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."
How not to do that - and anything else.
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.
And in fact, access to all files is not required even if you are a sysadmin. What is required is the ability to submit a request which, when suitably approved, grants you access to all files on a given set of systems for a given time, and then removes it again, during which time you will perform the actions detailed in the request. This is not the same as having access, because there is an approval process and an audit trail.
(Just to be clear: I agree with your comment, I'm just clarifying.)
Access is not required.
But the POTENTIAL for access is necessary. Which is no different in the law as actual access. So I may as well have actual access.
It all comes back to the same definitions.
However when I have to deal with anything sensitive, even if I have rights to the data as part of my job, I carefully record what I'm doing and why and on whose authority. Because you don't want that stuff coming back to bite you.
Generally speaking, IT people are either REALLY slack about this, through ignorance of it, or REALLY hot on this, because they don't want to go to jail. It's very much either "don't know/don't care" until they learn the consequences, and then it very quickly becomes "no way am I getting into trouble for that".
I am not a lawyer, but the stuff I dealt with was very clear that 'access after filling in a form, that form being checked by a colleague and signed off by an approved authoriser, only after which process was whatever process granted (and then automatically revoked) the access' was very different than having the access but not using it. Without going through that process, access was simply not possible at all. Obviously if you could find a suitable number of people who were willing to check and sign the form then you could compromise the process, but no individual could and without yet further levels of compromise there would still be an audit trail of who did compromise it.
The people who action privileged access don't have any access at all to the systems on which the privileged access is being allowed: they can only allow privileged access for other people.
This is pretty much the same for the authorisation process: if you can authorise privileged access to system x you must yourself not have any access to system x so there is no[*] possibility of authorising such access for yourself.
(In the places I worked there have often been historical defects in this division of responsibilities, but people got significantly closer to it while I was there.)
[*] Not really 'no' in the sense of zero, but 'no' in the sense that it would require other people's help, and those other people would understand that what they were doing was deliberately compromising safeguards. That's all you can really achieve.
You've reminded me of a former boss I had when I was a day to day sysadmin.
Near direct quote from said manager of sysadmins:
"If you give me an account on the servers, you get written up. If you give me root to the servers, you're fired."
The manager pointed out, they were the manager, not the sysadmin. They also didn't have the training to be safe as a sysadmin. One of the two best managers I've ever had.
My old boss actually was a domain once (now he mostly "manages") - he knew why he didn't want access and rather rely on a change process.
On a few of our (production...) machines he actually did still have admin privileges (well, local admin plus a small local OU), and his team members got handed out those accounts with stern warning of being careful _and_ fessing up when things went wrong (so we - ok, he - could repair the damage). We were all very nervous, and anything that looked dangerous was checked over by at least one additional pair of eyeballs. I'm still scarred by that, I think he did it on purpose to train us in the art of "how much access do we really need?". And this plan worked extremely well.
Yeah, those changes we prefer to use now might need a day or five (depending on how urgent it really is and how much other work they have), but at least those guys and gals implementing our requests have proper training (and call back to tell us when we are wrong / stupid - great!).
I currently need access to a particular server at work for HPC. As I am the only authorized user of this computer, and I only need it for HPC, and it does not need access to the rest of the work network, I suggested that that server be disconnected from the work network, so that I don't need to perform achingly slow TFA to do some work on it.
While things need to be locked down, we also have to think imaginatively about how to allow effective working while maintaining security. It doesn't matter if this particular machine gets pwned. There's no sensitive data on it, and it can be wiped and reimaged in less than an hour. It's better to put the firewall between it and the rest of the network than slow my access down. (An ideal solution would be to put the machine under my desk at home, but amazingly that wasn't an option.)
"I suggested that that server be disconnected from the work network"
Better still - it should never have been connected in the first place.
One client has a completely separate network for production data which included a lot of PII, some of it quite sensitive, which was being processed for their clients. In fact it was a condition of the contracts for the services they provided. Yes it was a little inconvenient to have to go - escorted - to the server room to find out what the problem was on incoming data* but it was just the way things had to be done and quite right too. (The same client also had pen-testing to see if staff could be inveigled into spilling data over the phone. They couldn't.)
* Thanks to the tame software house used by one of The Usual Suspects who rotated freshly qualified but untrained developers in on a 6 monthly cycle to make the same mistakes the last lot made.
i'm currently trying to short out the shambles of an IT environment at a small Defence contractor, we're a small manufacturer of military equipment so basically most of the employees are engineers and the IT systems were run by said engineers. They ALL run their devices with local admin, the trouble I'm having trying to roll this back to least privilege is driving me insane!
So don't do it then. Let them admin their own devices. Just make sure that it is clearly documented that they are responsible for the admin of that device not you. Many engineers are experienced and capable people who don't need their hands held when operating a computer. There's no need to jump on the bandwagon of "all users are idiots, we must lock away all the sharp and pointy objects so they don't hurt anyone".
My machine has a nice compromise. I have admin access but any time I need to use admin powers, it asks me what acceptable use category it comes under and logs that action. I can do what I like to my machine, and there is a record of whenever I have used admin privileges that could be audited if need be.
of course every user is an "expert" I don't tell the engineers how to do their stuff (I did engineering at Uni) so no need for the engineers to fiddle with their client device. If they NEED admin as part of their job that's fine they can have a seperate local admin account and use elevated privilege NOT run their normal domain account as a local Admin with all the risk to the business that that gives.
Trying to get managers to document what anyon should have access to is a futile task.
They don't want to, and if they did they wouldn't stay on top of it.
All you get is "give them the same as xyz"
Except XYZ has come form their old department carrying permissions.
It gets cleaned up every time the shit hits the fan I suppose.
As the security guy I have to fight IT to stop getting access to things. I'm continually finding drives and apps I shouldn't have and don't want.
Over the years I've accrued doman admin, desktop admin, access to every building, server room codes pretty much everything.
In the one hand, it's hard to believe that only 40% have access to sensitive data they dont need to do their job.
OTOH, the degree of sensitivity also matters. If I'm a programmer with r+w access to marketing shared directory, sure that's more access than I need, but it's less of an issue than if I have read access to an HR directory with addresses, dates of birth, and social security numbers for all the employees.
Continuous deployment is all the rage now. It's trendy, all the cool kids, do it, and it makes it easy to eliminate costly test environments. I can say that many software companies develop and test with live personal data from production systems. I've even seen offshore development agencies with incredibly high turnover rates get full access to live banking data just so that they have a database to code against.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
