How to lock down a ServiceNow app *very* securely (Part 1 of 3)

[Grant Hulbert]

Part 1 (you are here)

Part 2

Part 3

The CEO of your company asks you to write a ServiceNow app. Cool. “Fame and fortune await me, because I love writing apps on the platform”, you say. CEO says it needs to be secure. “No problem” you say, “I know how to protect tables with roles.”

Then your CEO drops the bombshell: she wants the app to be so secure that not even ServiceNow admins are able to inspect your app’s tables.

You see, this app will contain very sensitive corporate data: mergers and acquisitions, meetings with heads of state, private phone numbers of celebrities. To make things even harder on you, dear developer, the app will be used by lots of different departments in your company, and the data cannot be shared between departments, but must be easily shared within a department.

This is starting to sound tougher than expected.

What’s the solution? We’re going to borrow a technique called “Application Administration” that the developers of ServiceNow’s HR Service Management app used to solve very similar requirements (as you can imagine, HR deals with lots of highly private information about employees). In part 2 of this series, we’ll lean on another technique from Domain Separation.

There are two key takeaways for this blog series:

1. The app is locked down so hard that even other admins can't see the data.
2. Row-level security, so multiple groups can use the app without data leaking across teams (see part 2 of this blog series).

Prerequisites

You must have admin access to an instance, and you must have the role “security_admin”. You're building a very secure app, which means you need elevated privileges to do so. You will also need to have experience with Studio: writing apps on the platform, creating and assigning roles, changing form layouts, etc.

Let's get started!

1. Log in to your ServiceNow instance as an admin so that you have the necessary rights to create apps.
2. Open Studio and create a new app called “Secure Data”. Click the [Create] button to begin.
3. On the next page, click the link in the lower-left corner that says “Continue in Studio (Advanced)”.
4. Configure Application Administration:
   1. In Studio, start to create a role, but before entering any information, choose Configure > Form Layout.
   2. Click edit this section in Global and add “Application Administrator” to the form layout.
   3. Now you can finish creating the special role on this form. Enter suffix “admin”, and tick [x] Application Administrator, then click [Submit] to save the role.
   4. Edit your own sys_user record (you are probably logged in as “admin” right now) to give yourself the role you just made. The role name begins with “x_”, so you can type that to help you find it. (This is a very special requirement that is important for secure apps). Also make sure you have the role “security_admin”.
5. Log out, and then log back in as admin. This step is very important!! If you don't, you won't be able to accomplish the next steps.
6. Open Studio again, and open the “Secure Data” app you created earlier.
7. Choose File > Settings, tick [x] Application administration, then click [Update].
8. Create a table in the app, name it “Secure Data”.

9. Add a simple string column named “comment”.

10. Click [Submit] to create the table.
11. Add one or two sample records to the table.

That's it! You've created an app with table data that other admins cannot see

...but I'm sure you'd like to test it out, just to be sure. Let's try to break the security by seeing what other admins can view:

1. Create a whole new user “Normal Admin” and give that user both “admin” and “security_admin” roles.
2. Log out and back in as that new “Normal Admin” user; notice you cannot see the app in the left nav. Why not? Normally, admins can see everything, but in this case, because this app is locked down with “[x] Application administration” only admins with the special app admin role you created earlier can see the data.
3. Enter <your_table_name>.list in the left nav, and press return. Notice you cannot see any records in the secure table.
4. Let's get tricky for a second: impersonate System Administrator (or whichever admin user you were logged in as when you created the app). Still can't see the app's data? Good! ServiceNow engineers made sure you can't sneak around protections easily.
5. Impersonate Abel Tuter; notice you cannot see the app module or any of its records. Why not? This one's simpler to explain: regular old-fashioned role-based access prevents normal users from seeing data. We'll delve deeper into this in part 2 of this blog series.

What's next?

In part 2 of this series, we'll implement row-level security, so users from different groups can only see data from their own group. Let's go check it out now!

Part 1 (you are here)

Part 2

Part 3

[Claude DAmico]

What's stopping another admin from adding the new application admin role to themselves?

[Grant Hulbert]

@Claude DAmico The platform prevents this! Other admins do not have the special role for application administration that is attached to this specific app. If they try to add that role (even with elevated security_admin role), the platform will prevent them from giving themselves that role. Other admins can't even see the role when they attempt to add new roles to themselves. App artifacts are just invisible to them.

[-O-]

What should be done in case the person who is the "original" administrator/owner of the application leaves the organization?

Can the right to manage application administration/ownership be transferred?

If yes, how?

[Grant Hulbert]

Yes, in the instructions we tell you how to give a special role to yourself when building the app. You can assign the same role to as many other people as desired. In an emergency, Maint can assign that role to others, if for some reason the original author is unable to log in.

[digitaldillon]

Thanks for sharing this solution, Grant! Keeping sensitive information secured should always be a priority. 👍

[Balaji MR]

Thank you for the detailed steps and procedure!

[Henalu]

Sweet! Thank you for the detailed info and insights 👏

[Trishule]

Thank you for the detailed info and insights

[Rohith11]

Thanks for sharing this solution

[Mohamed Magdy]

Thank you for the detailed info and insights

[Sarvari K]

Thank you for the detailed steps and procedure!

[fawadalam4514]

In this first installment of our three-part series, we delve into the essential steps to achieve an exceptional level of security for your ServiceNow app. By following these best practices, you can create a robust fortress of protection, ensuring the utmost security for your valuable data and operations.

[Grant Hulbert]

@izzah_7 Parts 2 and 3 are up; click the green links to visit them!

[petarB]

Thank you! Very well structured and useful info! 

[jonsan09]

Very interesting stuff, this important topic as the platform gains adoption within an organziation concerns might arise about PII and other sensitive information.

[hanimi9623]

It was interesting information.

Thanks, 

[george46]

Securing a ServiceNow application involves a multi-faceted approach, encompassing various layers such as access controls, data encryption, and system configurations. Below is the first part of a three-part guide on how to lock down a ServiceNow app securely.

Part 1: Access Controls and User Permissions

1. User Roles and Groups:

• Leverage ServiceNow's role-based access control (RBAC) system. Clearly define user roles based on their responsibilities and grant permissions accordingly.
• Assign users to groups and roles, ensuring that each user has the minimum necessary access to perform their job functions.

2. ACLs (Access Control Rules):

• Implement Access Control Rules to restrict data access at the record and field levels. Create ACLs that enforce the principle of least privilege, allowing users to access only the data they need.

3. Conditional Expressions:

• Use conditional expressions in ACLs to dynamically control access based on specific conditions. For example, limit access to sensitive data during non-business hours or from certain IP ranges.

4. Security Roles:

• Assign security roles to control access to specific features and functionalities. This ensures that users can perform only authorized actions within the ServiceNow instance.

5. Session Management:

• Configure session management settings to control the duration of user sessions. Enforce regular logouts and implement mechanisms to detect and prevent session hijacking.

6. Password Policies:

• Enforce strong password policies, including requirements for length, complexity, and regular expiration. Educate users about the importance of maintaining secure passwords.

7. Multi-Factor Authentication (MFA):

• Enable MFA for an additional layer of security. Require users to authenticate using multiple factors, such as a password and a temporary code sent to their mobile device.

8. IP Restrictions:

• Implement IP restrictions to allow access only from trusted IP ranges. This helps prevent unauthorized access from external sources.

9. Audit Trails:

• Enable audit logging to track user activities. Regularly review audit trails to identify any suspicious or unauthorized actions. This can aid in incident response and forensic analysis.

10. Integration with Identity Providers:

• Integrate ServiceNow with your organization's identity provider (IdP) for centralized user authentication. This ensures that user credentials are managed securely outside the ServiceNow instance. akcombo

11. Role-Based Home Pages:

• Customize home pages based on user roles. Users should see only the modules and data relevant to their responsibilities, reducing the risk of accidental data exposure.

12. User Training:

• Conduct regular security awareness training for users. Ensure they understand the importance of secure practices and recognize potential security threats, such as phishing attempts.

By focusing on access controls and user permissions in this first part, you establish a foundation for a secure ServiceNow application. In the subsequent parts, we will delve into additional security measures, including data encryption, platform configurations, and best practices for development and testing.

[Zhenhua_Yu]

Thank you! Good sharing.

[KathleenMG]

This is good information to have from the newest user to the most veteran.

[hassanh]

Thank you for this solution.

[gregory krason]

Thank you! Very well structured and useful info! 

[Jack Treiman]

Thanks for sharing

[tylerhummel]

Will be coming back to this once I know what I'm doing.

[ucsammy]

Thanks for the deep dive down the security lane, with me being interested in cybersecurity this is a great way to both practice security practices and make sure my SNOW app is locked down.

[spotiflyera]

To lock down a ServiceNow app very securely (Part 1 of 3), follow these initial steps:

1. User Access Controls
- Role-Based Access Control (RBAC): Assign roles based on least privilege, ensuring users have only the necessary permissions.
- User Authentication: Implement strong authentication methods, such as Multi-Factor Authentication (MFA).
- User Provisioning: Regularly review and update user access, removing inactive users promptly.

2. Data Security
- Encryption: Ensure all sensitive data is encrypted both in transit and at rest.
- Access Controls: Use ACLs (Access Control Lists) to restrict data access based on roles and permissions.

3. Application Security Settings
- Instance Security Center: Regularly review the recommendations and follow best practices for securing your instance.
- Security Plugins: Enable and configure security plugins such as the High Security plugin to enhance security.

4. Audit and Monitoring
- Activity Logs:Enable detailed logging of all user activities and changes within the application.
- Monitoring Tools: Use monitoring tools to track and respond to suspicious activities in real-time.

Next Steps (Part 2 and 3)
Continue securing your application by implementing advanced security configurations, regular security audits, and staying updated with the latest security patches and best practices.

Stay tuned for Part 2, where we'll cover advanced configurations and additional security measures!