<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=523033&amp;fmt=gif">

NetSuite Security and Controls, Part 6: NetSuite Security Concepts

There are a number of different security concepts within NetSuite, and it would be instructive to highlight these security components in terms of permissions, global permissions, and data access. To illustrate this, we will make use of an imaginary user and how this user gets access to a role.

In this example, the imaginary user will be a GL accountant. This GL accountant gets assigned a specific Subsidiary access to some geographical area, limiting what he can “see” to just that geographical territory. It is easier to envision if concrete examples are used, so assume in this example that the user’s subsidiary access is North America. This data access affects all the other transactions the GL accountant can see. When this user logs in to the system and creates journals or searches for journals, that user would only see the ones related to North America.

This illustration can be extended to highlight the various permissions and limitations involved in designing system security. Presume that this user, in the role of GL accountant, has been assigned the permission “Make Journal Entry”. Under this “Make Journal Entry” permission, the user can make a journal entry and search for journal entries as well. In this fictional model, it is important to note that the user may additionally be assigned a “Global” permission, giving the accountant the authority to “Approve Journal Entries”. This would be a permission given outside the user’s role as GL accountant, which adds extra access to what the user can do. In other words, because of the global permission assignment, the user can both create and approve a journal, even though this user, in the role of GL accountant, cannot create and approve a journal.

This is a risk to companies if they do not monitor the use of global permissions. An additional concern is that when a report is run of users and roles globally, global permissions do not show up in the report. When reviewing users and roles based strictly on that report, it is possible to miss that elevated level of access. A user with global permission might very well slip through undetected.

There are other ways users might gain access to powerful privileges that the company may deem undesirable. One way to protect the system from such unwanted intrusions would be to hard-code user roles into scripts and workflows. Remember that if a report of users and roles is generated, the report will not show that higher level of permission. It might be advisable for something to be hard-coded into a workflow. For instance, it might be advantageous to hard-code a journal entry workflow to route journal approvals to the GL accountant role. It can be prudent to take this precaution since this would otherwise never show up in a roles and permissions report.

Core administrator permissions are another way of giving some elevated access to a role. This is a setting on a role to break up some of the functionality associated with the administrator role. The administrator role cannot be modified, but the core administrator privileges essentially elevate whatever permissions already exist in that role to the admin level.

As NetSuite explains it: Core Administration Permissions is a feature that can be enabled for a role and gives the role access to a functionality that is currently only accessible to the standard Administrator role. You can use Core Administration Permissions to customize a role so that it behaves almost like the Administrator role, while also restricting access to other areas of NetSuite using role permissions and restrictions. For example, with Core Administration Permissions you can create a role specifically for an IT administrator who is responsible for the general administration of the system, but who should not have access to sensitive employee information.

The audience setting for reports is also an excellent way to restrict access. If there is specific information that not everyone should see, this access can be restricted at the audience level.

In discussing the issues concerning the administrator role, the fact remains that at least one person must have access to this role. However, there are potentially some problems inherent here.

If finance and accounting personnel in the company have administrator access, it might be wise to question whether they need that access. Often when users inherit that elevated access, they don’t want it taken away because they can see many things in the system using that access, even though they are not using these capabilities for the purposes for which they were intended. They are not using these powerful privileges to create workflows, for example. Therefore, it is important to balance the authority a user has with the need to have that authority. Removing elevated access, like an administrator, and replacing it with a role tailored for the user’s purpose is generally the best security option.

It is important to get this correct. The administrator has all the SOD conflicts and the threats found within Change Management, where a single user can potentially develop and deploy changes. So then, it is obvious there is a great deal of risk associated with this role.

If too many administrators or people can do everything in the system, it is almost certain that this will represent a significant material weakness in an audit. Many of the items discussed here are specifically designed to address this risk.

The bottom line is to know who your Admins are and justify why these individuals have this level of access.