What is the Role Based Access control?
Strike Graph's default control language is: "Role-based security is utilized to grant user access and to segregate access to sensitive data in production and supporting tools. Transactions and functions have been defined for each role. Changes to roles follow the change management process."
This language should be customized to reflect the specific process that your organization has defined. It's important that your stated control description accurately reflects how your organization implements this control.
If your organization does not implement Role Based Access (which would be typical for companies of smaller size), please deactivate the Role Based Access control and the Role Access Management evidence item in your organization’s Strike Graph platform.
Who’s involved with this control?
Typical control owner: CISO or Head of IT
Typical parties involved: Asset owners (for defining the role) and Help Desk (for provisioning).
How often should I perform this control?
Typical frequency: Continuous
Which framework is this for?
SOC 2 - typically used by larger, more mature organizations
PCI - Required
ISO 27001 - General concept
NIST 800-171 - General concept
Why is this control important?
The role-based access control is a security model used to grant specific groups of users a set of access rights based on their job function. Role-based access is used to reduce the risk of a breach or other inappropriate access, or misuse of data by enforcing the concept of least privilege. Roles are a grouping of permissions and access rights (read, write, edit) that the user is allowed to utilize. Roles can get quite complex and may require deep business knowledge to set up, maintain, and administer.
For example, if all users on your network need access to email and the company intranet, everyone will be assigned a basic user role. The collection of permissions for this role may include email user and the viewer permissions on Confluence. In addition to this basic user role, a software engineer may also be granted access to the ticketing system, as well as the tools and software needed for their job via the software developer role. Someone in HR, on the other hand, may only need access to the HRIS software, so would be granted the basic HR role.
How to demonstrate this control:
Role Access Management - Describe the organization's approach to role based access within a stand-alone document, or as a section within a Logical Access Policy.
Role Library - A document that includes a list of each role, what access rights the user will have when assigned the roles, who can approve changes to the role, who can approve granting access to the role.
Role Review - Role permissions can morph over time. Showing the last time that roles were reviewed is helpful. For SOC 2, a role review is only "required" if you include it as part of your control language.