Access Controls Auditor checks
Summarize
Summary of Access Controls Auditor checks
The Access Controls Auditor checks enable ServiceNow customers to evaluate and enhance the security of their instances by auditing Access Control List (ACL) rules. ACLs are essential for restricting data access, ensuring users meet specific requirements before interacting with data. This tool assesses your instance against eight critical security criteria to identify potential vulnerabilities related to ACL configurations and user roles.
Show less
Key Features
- CSRF Protection for Script Processors: Detects script processors that lack Cross-site Request Forgery (CSRF) token protection, ensuring scripts cannot be exploited via CSRF attacks.
- Knowledge Base Contribution Criteria: Verifies that each knowledge base has defined "Can Contribute" or "Cannot Contribute" user criteria to prevent unauthorized content contributions.
- Empty ACL Detection: Identifies ACL records without security attributes, roles, or those using the public role, which might unintentionally allow open access.
- ACLs on Client-Callable Script Includes: Checks that client-callable script includes are secured with appropriate ACLs requiring specific user roles.
- ACLs on UI Pages: Ensures UI Pages are protected by ACLs to prevent unrestricted access by all logged-in users.
- ACLs on Tables: Confirms that tables have ACLs in place to restrict data access to authorized users only.
- User Role Assignments: Detects user accounts assigned both internal and external roles, which should be mutually exclusive to maintain proper access boundaries.
- Public Accessibility of Knowledge Bases and Articles: Finds knowledge bases and articles accessible to all users, encouraging limitation of visibility to intended audiences.
Key Outcomes
By leveraging the Access Controls Auditor checks, ServiceNow customers can:
- Identify and remediate security gaps in ACL configurations to prevent unauthorized data access.
- Ensure proper protection of scripts, UI pages, and tables through role-based ACLs.
- Maintain clear separation between internal and external user roles to uphold security policies.
- Control knowledge base contributions and visibility, minimizing risks associated with open content management.
Implementing the recommendations from these checks helps maintain a secure ServiceNow environment, reducing the risk of data exposure and unauthorized actions within the instance.
Learn about the checks available in the default Access Controls Auditor Suites, what criteria they evaluate, and how they can be used to improve the security of your instance.
| Check Name | Check Criteria | Description |
|---|---|---|
| All Processors of type - SCRIPT must be protected with CSRF Token | Checks for Processors with the SCRIPT type that aren’t protected with a CSRF token. | All Processors with the SCRIPT type should be protected with a Cross-site Request Forgery (CSRF) token. These processors should have the CSRF option checked, which prohibits the processor from running unless the instance uses a CSRF token. |
| Can Contribute / Cannot Contribute user criteria to be defined on each knowledge | Checks for knowledge base records that don’t have Can Contribute or Cannot Contribute user criteria defined. | Each knowledge base should have either Can Contribute or Cannot Contribute user criteria defined. Otherwise, any user can contribute content to a knowledge base with no Contribute criteria defined. |
| Empty ACLs | Checks for Access Control List (ACL) records that have no security attribute, no role, or the public role. | Leaving ACLs empty or using the public role may provide open access to any content protected by this ACL. |
| Access Controls on Client callable Script Includes | Checks for client-callable script includes that aren’t secured by ACLs. | All client callable script includes should be secured with an ACL using required roles. |
| Access controls on UI Pages | Checks for UI Pages that aren’t secured by ACLs | Without an ACL securing access to a UI Page, that UI Page is accessible to all logged-in internal users. Without any restrictions logged-in users can potentially make unauthorized changes. |
| Access controls on Tables | Checks for tables without ACLs | Tables should be secured with ACLs. Access to data stored in tables should be limited only to users that need it. |
| User Account shouldn’t have both Internal and External roles | Checks for user records with both Internal and External roles assigned | Internal user roles are intended for users within your company. External user roles are intended for external personnel, such as customers and partners. |
| Publicly accessible knowledge base and articles | Checks for publicly accessible knowledge bases and knowledge base articles | Publicly accessible knowledge bases and articles are visible to all users in the instance. Increase security by limiting knowledge bases and articles to the specific audience that needs them. |