/build/static/layout/Breadcrumb_cap_w.png

Discovered a security weakness/issue with Roles.

When we first implemented our helpdesk, we had one queue and we set granular permissions to access different tiers of access via roles (assets, licenses, inventory, etc) and we allowed write access to our helpdesk in the admin console.

As our company grew and other ticket systems were spun up for more departments (safety, compliance, test lab, etc), I filtered ticket managers by labels, as we discovered was best practice, however, our original IT helpdesk operators were still handling their duties all in the /admin login so they could manage assets while watching our IT Helpdesk queue.

I learned yesterday that one of our Tier 1 IT Helpdesk employees manipulated a ticket in one of the other queues. I became aware of the fact that because he was able to see tickets via the /admin console, he could see EVERY queue.  In order to eliminate that access, I had to remove the Ticket system access from the Admin console while leaving the other functions as part of his duties, i/e; asset and inventory management, etc and then add him to a "helpdesk operators" label so he could access and manipulate tickets only in our IT Helpdesk.  Now he has to maintain two windows open one with /adminui and one with /userui so he can work both tickets and handle assets since he is in our PC Deployment department.

I know it's just an issue with having 2 tabs/windows open, but it's still a cumbersome workaround.   Am I utilizing the best practice here or am I overlooking another option?

Thanks very much,
-brady

0 Comments   [ + ] Show comments

Answers (1)

Posted by: chucksteel 5 years ago
Red Belt
0
Does the technician need to be a submitter, owner or approver in the other queues? If not, then he can be removed those labels for those queues and he won't be able to access them, even in the admin interface. Even as the administrator of my SMA there is a queue that I can't normally see unless I change the queue configuration first.

My other reaction is that this might be a "people problem" and not a technical issue. Working in IT you often are granted access to areas that you should not abuse. In this case your technician violated that trust and at the very least needs to be reminded that even though he has the power to perform certain tasks he does not have the permission to do so.

Comments:
  • No, he doesn't need access to the other queues, but that's the issue. If I disallow helpdesk 'write' access in the /admin side of kace, then he has to have a tab open in the /user space to operate tickets in our queue but when he needs to edit or add assets or inventory, he has to flip back over to the /admin space.

    Basically, I just discovered that the /admin side is global. We do trust the offending employee not to make the same mistake again and we've decided to leave things as is but if we hire any new Tier 1 IT techs who need access to just our helpdesk AND access to inventory/assets, they'll have to use the 'multi tab/window' solution because I'm sure as hell not going to give the new guy keys to all desks, as they may contain sensitive data. I keep racking my brain to see if there's a better solution than what I'm coming up with. I want to minimize confusion by not having to say, "use the /admin switch on the url for assets and don't use the /admin switch for tickets" - Brady Williams 5 years ago
    • and yes, I use labels to isolate other techs for the other queues.
      I can use the it helpdesk owner label and remove helpdesk visibility in the admin section of the role for our guy but, as I said, he then has to use multiple windows to function. - Brady Williams 5 years ago
      • If a user isn't included in any of the labels for the queue (Submitters, Approvers or Owners) then they won't see the queue at all, not even in /admin.

        For example, we have an internal department queue for our Academic Technology department. The queue is configured with the label "Academic Technology" for submitters, owners and approvers. I am not in any of those labels, and therefore cannot see that queue when I view all queues or make a new ticket. Even if I have the ticket ID I can't view tickets in that queue. - chucksteel 5 years ago
  • Are you set up as multiple orgs? That's the only way I could imagine you would have total isolation.

    We're not using Orgs and I have full visibility of all queues simply because the role applied has Help Desk access applied in the admin console. - Brady Williams 5 years ago
    • in fact, I'm using a test user account and it has no labels applied at all but it has the "IT Help Desk Level 3" Role applied (the Role that our offending user has applied to his account) and I can get into, manipulate, even delete, any ticket in any queue. - Brady Williams 5 years ago
      • What are the labels on an example queue that shouldn't be accessible? - chucksteel 5 years ago
  • CFD-REQUEST-OWNER
    COMPLIANCE-OWNER
    FAC-DESK-OWNER
    etc. this allows the departmental users to assign a ticket owner role. I apply that to the users designated to handle tickets in their respective queues. - Brady Williams 5 years ago
    • And what about the submitter and approver settings? - chucksteel 5 years ago
      • no approvers on those desks. The Facilities desk is open to all submitters. The CFD and Compliance are -USER instead of -OWNER for ticket submission permissions. - Brady Williams 5 years ago
      • Interesting. For the Facilities desk the user will be able to interact with the queue by virtue of being a submitter. For the other queues they really shouldn't be viewable. - chucksteel 5 years ago
  • Very. I guess I'll go ahead and submit a ticket on this to see if any of the engineers have any thoughts on the matter. I appreciate the time you've invested :) - Brady Williams 5 years ago

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ