- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-05-2017 12:50 PM
Hi,
Our company has been moving to a security model in which sys admins have a separate admin login from which they perform only admin-level tasks while their regular SSO sign on is used for everything else. I'm being asked if we should implement this model for ServiceNow and am being asked what the risks are if we don't vs. the risks if we do. Since I'm a sys admin as well as an ITIL user, I'm assuming I'm already using two licenses, so that shouldn't be an issue - I'll keep my regular sign on as ITIL and create a new sys admin account for my admin activities. However, if feels like this could cause confusion/complexity. I'm still pretty new at this though, so I'm looking to the community here to give me concrete reasons/examples of how this would be a great or terrible idea.
Thanks in advance for your help!
Solved! Go to Solution.
- Labels:
-
Security Operations
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-05-2017 12:54 PM
Its to support compliance around separation of duties. It *is* a little more friction for admin users like you and I, but much much much better from a GRC standpoint. Among other things, it ensures that you can't use your admin privilege to alter data for your own benefit. By separating the admin account from the regular account its easier to track the activities performed by the admin capability.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-05-2017 02:37 PM
Thanks to both of you, Chuck and Robert! I love how responsive this community is. I hope to one day be able to provide my own expertise.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-15-2018 02:33 PM
Good Evening Folks - how can we address separation of duties for privileged users on the ServiceNow SAAS solution while at the same time enforcing mandatory 2 factor authentication (w/ PIV) for system admins?
A normal workflow would be that the system admin authenticates using PIV and then is placed directly into the session. However this workflow does not allow the system admin to select a regular user account or an elevated priv account. Thus breaking the security control.
Currently going through ATO and trying to respond to the following NIST SP 800-53 r4 controls: AC-2, AC-3, AC-5, AC-6, AC-16. This question is specific to AC-6 and the following policy objectives:
1) Components shall divide and separate duties and responsibilities of critical information system functions among different individuals to minimize the possibility of any one individual having the necessary authority or system access to be able to engage in fraudulent or criminal activity.
2) All individuals requiring administrator privileges shall be reviewed and approved by the appropriate Authorizing Official (AO). The AO may delegate this duty to the appropriate System Owner or Program Manager.
3) Individuals requiring administrator privileges shall be assigned administrator accounts separate from their normal user accounts.
4) Administrator accounts shall be used only for performing required administrator duties. Individuals shall use their regular user accounts to perform all other functions not directly tied to administrator duties (checking email, accessing the Internet).
In my view there should be a way in the SN/SAAS configuration to present a system admin with the choice of accounts to log into after being authenticated using dual factor PIV.
I really really really need some help here answering these controls. Any guidance or recommendations welcome!
Paul Zedeck, CISSP
Information System Security Officer
