When on-boarding new teams and people to ServiceNow one key issue that you will have to confront is that of confidentiality . Who sees what will be a key question of every new team bringing their daily work life to ServiceNow.
In ServiceNow every user with the ITIL role can search, view, and modify any ticket in the system. First-time users of ServiceNow unaccustomed to such openings will find it discomforting.
Before ServiceNow, they were used to controlling the visibility of their communications and issues in mailboxes shared only with their close-knit team. Now that their work to-dos, their messages with customers and partners (and their spelling mistakes) are open to browsing scrutiny by anyone in the organization (with an ITIL role) can be discomforting.
Even if you have the leverage to impose ServiceNow, or if some teams are already used to publicly searchable tickets, you need to consider confidentiality more seriously as you bring more people and teams on-board. The more teams you bring, and the more you expect them to use ServiceNow, the more confidentiality will be important. Not acknowledging this may subtly hinder the adoption of ServiceNow.
In other cases, there will be articulate reasons as to why expanded access to ticket information is not acceptable. The reasons can be that the tickets handle confidential user information (such as the personal security number) or other technical details that could be leaked to outsiders.
If you decide that you want to have confidentiality in ServiceNow, how should you do it? Do you just make all tickets assigned to HR visible only to HR? What about the other teams? And cross-team collaboration? And outsiders?
This chapter provides you with two solutions for your confidentiality requirements:
Domain separation : Rigidly separates tickets, users, and configuration
Access Control (ACL) rules : Enables teams to flexibly extend or restrict access to their tickets on a ticket-by-ticket basis
Scope of data protection
So what data exactly are we trying to protect? In ServiceNow, data can be essentially be categorized as:
tickets data, emails, and attachments;
users profile data;
other records for assets and equipment.
Arguably only tickets data and attachments are exposed in ServiceNow, whereas access to assets , contracts and other types of records in ServiceNow are more tightly controlled and require users to be granted specific access roles. For this, the focus of the confidentiality model here proposed is to protect access to tickets data, emails, and attachments.
As for Users data, it too is exposed to everyone with an ITIL role in ServiceNow; but the same user information is also available to everyone in the organization in the global address book (see Figure 9-1), and so it would not be a breach if it is also available in ServiceNow.
Figure 9-1. Global address book in Outlook can show all user profiles in your organization
You can, however, restrict what user information is available in ServiceNow by selecting what data is imported in ServiceNow from your directory server and, within ServiceNow, make certain fields only visible to certain groups. For example, you could make visible who is checked as a VIP in ServiceNow (see Figure 9-2) only to the service desk (see Chapter 3).
Figure 9-2. How the incident caller field changes for VIP users
Ticket data
For each ticket in ServiceNow , there are several layers of information that you may want to protect from access by people unrelated to the ticket:
User-visible communication : Those are the messages of the caller and the user-visible replies she got on the ticket. They may sometimes contain sensitive details about the customer, or of things described in the reported issue.
File attachments: The file attachments made to a ticket either by the caller or by people from the resolver team. Attachments can include screenshots that reveal sensitive information.
Internal notes: The technical details and internal work notes about a ticket typed in by members of the resolver team and not shared with the customer because of their internal nature
Ticket headers: The high-level details about a ticket that don’t reveal the content of the ticket but give an indication about its status (see Figure 9-3). Ticket headers can be:
Figure 9-3. Without getting into details of the issue , header fields give information about the ticket and its status
ticket number, caller and location;
status, assignment group, and assigned-to person;
timestamp of the ticket creation, and last update;
short description, category, and priority.
Protection from ServiceNow
ServiceNow as a company will also have access to all of your data, hosting it on its own infrastructure. In fact, there is in ServiceNow a special access which ServiceNow HI support can use to log with administrative privilege into any instance; this special access is called “maint”.
Going on the cloud, you trust ServiceNow not to eavesdrop on your data.
For this, Al Jazeera is among the ServiceNow customers that are not on the ServiceNow cloud, self-hosting their instances. But even self-hosting is not enough; so long as the instance is publicly accessible on the Internet, ServiceNow could access it also. The instance needs to be accessible only through VPN for maximum security.
ServiceNow also makes it possible to encrypt data, but if both the encrypted data and the keys to decrypt are with ServiceNow, they could again access this data.
ServiceNow’s Edge Encryption also allows you to encrypt some data fields and host the keys to decrypt this data in your corporate network so that, although the data is hosted by ServiceNow, it would not be able to decrypt it without the keys hosted on your infrastructure.
Not all fields can be encrypted, however, and together with several limitations1 and complexities Edge Encryption may be virtually impractical.
Domain separation
Domain separation in ServiceNow, also known as multi-tenancy, lets you co-host many independent ServiceNow environments in the same instance. The concept is very similar to virtual servers co-hosted in isolation but in the same physical server, and goes beyond data protection.
Such separation is intended for Managed Service Providers (MSP) , who could then have a completely separate environment for each of their clients, all in the same instance (see Figure 9-4).
Figure 9-4. Domain separation in ServiceNow nests data and configuration
Under Domain Separation , the MSP starts with one ServiceNow environment, with all users in it. This is called the “global domain .” The MSP can then create new sub-domains under the global domain, and assign users to each sub-domain. This way, the people in the sub-domain will only be able to see the tickets and data in their domain and not the ones in other sub-domains or in the parent domain. It will also be possible to customize forms and workflows in the sub-domain to be different from those in other domains.
Users in a parent domain (typically the support teams of the Service Provider) and ServiceNow administrators will have access to all data, in all sub-domains.
It is worthwhile to note that Domain Separation complicates things significantly. The official ServiceNow documentation warns: “Before activating domain separation, consult your ServiceNow representative to verify that it is suitable for your environment. Domain separation adds a level of administration overhead. Although it can be disabled, it cannot be removed from an instance.” 2
As Mark Stanger, author of the ServiceNow Guru blog puts it: “the challenge with domain separation is that it’s a very dramatic shift in how the system needs to be handled and generally introduces much more complexity than is necessary.” 3
There are simpler but equally powerful alternatives as we shall later see in this chapter.
Examples
Domain separation is applicable if the users you have in one domain will have no need to collaborate with the users in another domain, whatsoever. They will be completely segregated.
But if, for example, your IT servicedesk and your HR teams need to collaborate on on-boarding new members or off-boarding terminated employees, keeping each in a separate domain will hinder them from collaborating on the same tickets and data. If you domain separate HR and IT, for example, HR will need to raise a ticket for IT in the segregated IT domain in ServiceNow.
Such segregation within an organization is not consistent with the general corporate orientation of breaking silos, and is generally not the level of collaboration that organizations hope to achieve from ServiceNow.
For example, ServiceNow quotes Kevin Barnard from GE Capital describing their ServiceNow implementation as: “By teaming with the business, we’ve changed the way that people think about IT. There’s no ‘us and them’—we’re all playing on the same side.”4
Domain separation puts everyone on a separate side, providing rigid splits of data and users that are normally not suitable for collaborating divisions of the same organization, but may be suitable for co-hosting multiple independent organizations under the same instance.
Domain separation could be suitable to segregate “legal cases” in the legal department, for example. It can be assumed that lawyers and staff in the legal department will work in isolation on most of their tickets, need strict separation and control of the data and can treat other users from within the organization as external users with limited access (until they sign a Non-disclosure agreement)!
But if you can avoid it, do. Even for legal, there many simpler solutions that can keep their data completely separate and confidential, without the complexity and, as ServiceNow called it, “level of administration overhead.”
At Al Jazeera, for example, we do not use domain separation and have built new types of tickets for the legal department, with custom access roles. So only users from the legal department can see and work on legal cases in ServiceNow.
Other support teams at Al Jazeera use the standard Incident tickets in ServiceNow, and a lot more often collaborate and re-assign tickets across teams. They are also reassured of the confidentiality of their tickets, which they can control from within the ticket , as described below.
Access on a need-to-know basis
Besides the rigid option of Domain separation, you can customize ServiceNow to control access to tickets much more tightly, while also maintaining the flexibility needed to collaborate with other teams and users.
Access on a need-to-know basis means that only the people that need the access are granted such access by those that already have it, and is regarded as one of the tightest security mechanisms, making it difficult to leak information and browsing of sensitive data.
This need-to-know access model can be implemented in ServiceNow by restricting access to tickets to only the people that need to collaborate on them and letting them extend it to others as they deem necessary on a ticket-by-ticket basis. More precisely, there would be three levels of access to a ticket (see Figure 9-5):
Read-only access to the ticket’s basic headers available to all ITIL users
Full-access to the ticket granted only to members of the ticket’s assignment group or those listed in the work notes lists
The caller and those listed in the ticket’s watch list can download and add file attachments, as well as participate in the customer-visible comments.
Figure 9-5. Different sections of the ticket are accessible to different groups of people
Put more simply, people in the assignment group of a ticket have full access to the ticket, and they can extend the same access to other people by adding them to the work notes list.
Adding people to the ticket’s watchlist enables them to participate in the user communication of the ticket without seeing the internal messages.
In this way, confidentiality is tightly but flexibly controlled for every ticket, providing maximum flexibility to extend access to all the people that need it to collaborate on the ticket.
Variations
When proposing the need-to-know confidentiality model, questions may be raised about what access the servicedesk has. They may claim that they need to know more about every ticket.
As described above, the servicedesk and every ITIL user can preview all of a ticket’s basic details so that they can report on the status of tickets to inquiring callers, reach the team to whom the ticket is assigned, or report to management.
Because of the specialized nature of tickets assigned to different teams, the servicedesk would rarely be able to support enquiring callers about the ticket, even if they had full access to the ticket. Otherwise, they would not have escalated the ticket to another team in the first place. So it is assumed that restricted access to the basic ticket headers is sufficient even for the central servicedesk.
At CERN5 they have also proposed an interesting twist to this model by allowing service desk and other people that do not have access to view the comments on a ticket. They can, however, add a comment to the ticket that they themselves will not be able to see after submitting.
This should enable the servicedesk, for example, to leave a message on a confidential ticket by another team, without being able to view what else has been said on the ticket.
Sister teams
If you examine the actual patterns of collaboration, you will find that certain teams always collaborate more amongst each other than with any other team. Those teams are usually within the same department and share common resources, for example, network and IT system teams working closely together on maintaining the back end IT infrastructure, or various ERP teams working together on HR and finance issues.
Call these collaborating teams “sister teams” as in sister companies. An extension to the need-to-know model that enables more collaboration between sister teams would grant members of sister teams not only access to all tickets assigned to their team, but also to those assigned to their sister teams (Figure 9-6).
Figure 9-6. Sister teams tend to have a lot in common, and are much more likely to share secrets, or tickets
Confidential checkbox
So far the need-to-know model assumed confidentiality for all tickets. That is, every ticket in ServiceNow is elevated to confidential status and is by default only accessible to those that need to collaborate on the ticket. But if this is not necessary, you could also make confidentiality optional.
If tickets confidentiality is not so critical in your organization, you may make confidentiality optional with a checkbox in each ticket so that only when the checkbox is checked does the need-to-know confidential model apply.
When unchecked, the default access model in ServiceNow applies (that is, the ticket is public to all ITIL users).
Confidential scenarios
Below is a walk-through of real-world example tickets that illustrate the dynamics of a confidential ticket.
Personal ERP issue
Omayma , a member of staff, calls the servicedesk about an issue with her ERP details. She is forwarded to discuss the matter with the dedicated ERP support team.
Dina, dedicated to ERP support, logs an incident for Omayma’s issue and assigns the ticket to the ERP HR team that specializes in such issues.
At this point, Omayma (the caller) receives a copy of her incident by email. Logging in, she can also see the user-visible side of the ticket, while the ERP HR team has full access of the ticket.
But, also, other sister ERP teams have access to the ticket, if it comes their way, while the Servicedesk and other ITIL teams can only see basic details about the ticket.
Saud of the ERP HR team fixes the issue and notifies Omayma about the solution of her issue .
Omayma receives the notification about her issue but, upon checking, she still has the issue and so she calls the Servicedesk again. The Servicedesk looks up her ticket and forwards her back to the ERP team.
This time, Sara from the ERP team receives the call from the Servicedesk and, although she is not from the ERP HR team, she has access to the ticket since she belongs to an ERP team, the sister of ERP HR.
Upon reviewing the issue with Omayma on the call and reviewing the feedback Saud left on the call, she attempts to troubleshoot the issue with Omayma on the phone. Lo and behold, they manage to fix the issue now.
For future reference, Sara writes a note about the issue and solution in the ticket and Saud is notified.
In this scenario, the Servicedesk received the call and forwarded the call to the specialist section, which in turn solved the issue.
For new tickets received via email, the ticket will not be confidential until it is assigned to a group . If you want all tickets to be confidential from the start, you need to ensure that every new ticket is either automatically assigned to a specific team based on certain criteria (refer to Chapter 4 for email-based assignment), or that it’s by default assigned to a central Servicedesk team that then reroutes the ticket to the appropriate team.
Information security work
Consider a within-IT ticket opened for investigation by the Security team. The workflow would be something like this:
Barbarossa, from the Internet Security team, identifies a potential threat and logs a ticket for it under his name. He sets himself as the caller and assigns the ticket to his team.
At this point, only his team has details of the ticket, while other ITIL users can merely find out that there is an open ticket logged for Security.
After internal discussion, Security decides to request changes to the network firewall and apply a security patch to desktop computers.
So Barbarossa opens two new tickets (change requests), one for the network team and another for technical support citing “security concerns” as the motivation for the changes.
When opening the tickets for the network team and for technical support, Barbarossa made sure to be added to the work notes of the ticket, and so gained full access to the tickets. He had access over all three tickets opened about the issue, while each team had default access only to their ticket.
Note how Security is not expected to reassign its tickets to other teams. It instead should request action from other teams in new, dedicated tickets, and disclose as little as necessary about potential threats or compromises .
Confidential vs. Out-of-box
Out of the Box in ServiceNow , all ITIL users have full access to all tickets. Here is how (Table 9-1) the need-to-know access model described above (without sister team or service desk twists) differs from the defaults in ServiceNow .
Table 9-1. Who sees what in Out-of-box configuration versus need-to-know model
Acccess to ticket data | ||||
|---|---|---|---|---|
Assignment group members | Other ITIL users | Caller | Other people | |
Ticket headers | ||||
Out-of-box | Full access | Full access | Limited access | Can view some fields if added to watch list, or the ticket was opened by you |
Need-to-know | Full access | Limited access | Limited access | Limited access |
File attachments | ||||
Out-of-box | Full access | Access only if in the work notes list | Full access | View-only access is added to watch list |
Need-to-know | Full access | Full access only if added to work notes list | Full access | Full access only if added to watch list |
User comments | ||||
Out-of-box | Full access | Full access | Full access | No access* |
Need-to-know | Full access | Access only if added to work notes list (or watch list) | Full access | Full access only if added to watch list |
Work notes | ||||
Out-of-box | Full access | Full access | No access | No access (must have ITIL) |
Need-to-know | Full access | Access only if added to work notes list | No access | No access |
When changing your access control rules, it’s important that you also consider how those rules apply, or can be circumvented, via email or ServiceNow Connect.
Arguments against confidentiality
As said before, the servicedesk may resent the limitations of confidentiality and request special access to all tickets. Other arguments may also be raised against confidentiality, such as those listed below.
“It’s unnatural and complicates things”
Access on a need-to-know basis is consistent with what teams are used to already. When receiving a user inquiry, teams normally discuss it internally with their email group only and don’t expect others to have access to the conversation, unless someone already with access shares it.
Further, with the reassurance that the information exchanged is only accessible by the people you see listed in the ticket, people are more likely to engage in personalized and detailed conversations. This should lead to better outcomes.
“Confidentiality discourages collaboration”
It is very unlikely that a person from the Network team finds on his own accord a ticket from the ERP team in ServiceNow, and proposes a solution to it. Most collaboration happens between related sister teams and upon invitation from those with access .
“It’s still possible to have a data breach”
Just like a trusted person with access could still leak emails to outsiders, so it can be with ServiceNow tickets. But at least ServiceNow will log who shared access with whom.
“When reassigning to another team, they can see all previous conversations”
When reassigning tickets, once-confidential communication is now shared with the new assignment group . In practice , however, it’s rare for a ticket to be reassigned to a group with whom the previous information needs to be hidden. When this is not desired, a new ticket should be opened with only the details necessary to share with the new team.
Tweet-ready takeaways
Domain Separation in ServiceNow complicates things significantly and cements silos.
Access on a need-to-know basis means that only the people that need the access are granted such access by those that already have it.
You can use Access control rules in ServiceNow to implement a need-to-know access model to tickets that is both tight and flexible.
Security shouldn’t reassign its tickets to other teams. It should request action in new dedicated tickets disclosing as little as necessary.
Footnotes
1 https://docs.servicenow.com/bundle/helsinki-servicenow-platform/page/administer/edge-encryption/concept/c_EdgeEncryptionLimitations.html
2 https://docs.servicenow.com/bundle/helsinki-servicenow-platform/page/administer/company-and-domain-separation/concept/domain-separation.html
3 The challenge with domain separation is that it’s a very dramatic shift in how the system needs to be handled and generally introduces much more complexity than is necessary.
5 Z. Toteva, et al. “Service management at CERN with Service-Now,” International Conference on Computing in High Energy and Nuclear Physics, 2012