Most customers come to Netwrix in anticipation of going public or in preparation for audit after an IPO. Recently, however, an increasing number of public companies are purchasing our products after failing an audit or receiving a warning of material deficiencies. The good news is that, in all cases, the main challenges are entirely avoidable without a great deal of work.
We are noticing that companies are being written up by their auditors for a very common issue in NetSuite accounts: scripts executing as Administrator. This isn’t a coincidence — as auditors become more familiar with NetSuite security, they are starting to ask more probing questions.
For example, an auditor recently asked our customer for a list of all scripts executing under the Administrator role, and an explanation for how they were managing the risk associated with each of them. Prior to working with Netwrix Strongpoint, this customer was unable to produce this list, resulting in difficult conversations for all concerned.
In this post, we explain the root of the problem and the reasons why auditors are concerned. Then, we’ll demonstrate the steps you can take to avoid material deficiencies being raised on audit. While it will be much easier to complete these steps with Netwrix Strongpoint, the process can be followed whether or not you have our software.
If, however, you just want to see an elegant way to resolve this, skip to the end of the article for a video demonstration of Netwrix Strongpoint’s capabilities.
What Does ‘Executing as Administrator’ Mean?
When a script is deployed in NetSuite, the Administrator or developer can set or change the User Role that it is executing under by changing the Execute as Role field on the Script Deployment record. Instead of executing under the same role as the user, it executes under a different role.
For auditors, the Administrator role is of most concern. A script executing under this role can do anything that the NetSuite API supports, which is almost everything you can do in NetSuite. We will refer to scripts with these broad permissions as Admin Scripts.
Admin Scripts are quite common since they greatly simplify testing. Rather than testing against all possible roles, a developer can guarantee that a script will work as designed by giving it the rights of the Administrator. However, this also means that the script can enable users to do things they could not normally do.
One important note before we continue: all bundle installation, scheduled and map reduce scripts execute as Admin. This makes sense, since they have no user role context. This does not mean, however, that your auditors won’t expect you to be on top of them.
Why Are Your Auditors Concerned? Why Should They Be?
Auditors are concerned with scripts executing in the Administrator role for two reasons. The first is that a lack of awareness of this very important situation is an indicator of the overall level of control of the system as a whole. An auditor from E&Y once put it this way:
“We aren’t worried about the things you know about. We are worried about what you don’t know about.”
The second, and most significant, is the potential for of segregation of duties violations. Segregation of duties (SoD) is a critical control for SOX, 21 CFR Part 11 and other regulatory regimes. It stipulates that the same person should not be able to complete multiple parts of the same transaction chain. It is primarily a fraud control to prevent people from covering their own tracks. For example, a person who accepts payments or writes checks should not be able to reconcile a bank account, since they could hide a fraudulent payment.
SoD is primarily managed at the User Role level to ensure that no user has a role, or combination of roles, that would violate this principle. Netwrix Strongpoint, the only native Segregation of Duties module for NetSuite, includes a methodology for rapidly implementing SoD.
In theory at least, Admin Scripts can go right around these controls. Moreover, scripts can cover their tracks by creating system notes without an identified user, or even by deleting data. For example, a script could be deployed that created an approved expense report or bill on a scheduled basis, causing the company to overpay or pay the wrong person and then deleting the record to hide the data trail. Alternatively, a script could be created to change the commission due on a sale, or even change the date of the sale and cause it to be double-counted.
This last example is not theoretical. Manipulations of transaction dates have been at the root of huge accounting scandals and, Enron and WorldCom aside, are some of the main concerns behind SOX and various accounting standards such as ASC 606. So yes, your auditors will and should expect you to have a handle on this.
Managing the Risk, in Two Simple Steps
Manage the risk requires creating and maintaining a list of all Admin Scripts. Then, once you have a list, you need to check if these scripts are doing anything that would concern anyone.
If you don’t have Netwrix Strongpoint, this will involve reviewing the code in every script to see what it does. If you have Netwrix Strongpoint, however, you can do this review in a single simple search, described below.
Step One: Finding the Admin Scripts
You can do this simply in Netwrix Strongpoint by searching the Customization Library for scripts with a related Script Deployment where ‘Execute as Admin’ is True. If you are looking more broadly, you can look anywhere the User Roles field is not empty. This will show any other roles that have been set for the context or audience of a script. However, most auditors are focused on ‘Execute as Admin.’
You will want to exclude scripts that have no fraud/SoD risk, such as:
- Any scripts from managed bundles (since your auditors will normally not be concerned about these)
- Any scripts that don’t touch standard, custom transaction body or column fields (since these will not normally impact your financials and therefore will not affect SoD rules. If you have critical custom records involved in financial processes, reach out to us to help you define the search appropriate to your account.)
In our production account, these two filters eliminated 90% of the scripts.
Without Netwrix Strongpoint or our free documentation app, Flashlight, it’s not possible to do this. However, with either program, the process is easy — simply build and run a search with the following settings:
Step Two: Clearing the Scripts
Now that you have the list of Admin Scripts, you need to demonstrate that you have reviewed them and established that they are not violating segregation of duties rules or doing anything else that would cause concern.
The Netwrix Strongpoint EAAS Search brings all the information you need together in one view:
- Script Date Last Used (see notes below on interpretation)
- Deployment Log Level
- Standard and Custom Field Dependencies
- Related Library script files, Scripts and Workflows
There is nothing inherently wrong with Admin Scripts. The risk comes from what each script touches. Using this approach, we have already excluded both scripts you do not control and scripts that do not impact financials.
We will now use Netwrix Strongpoint’s documentation to analyze the remaining scripts. However, you may still need to review the script logic to fully determine the issue.
The first thing you are going to want to look at is the Date Last Used. If the script is not running, then you may be able to resolve the concern by disabling it.
NOTE: Date Last Used is based on execution log data and requires the script to be run in Debug or Audit mode as shown in the Deployment Log Level.
If the script is running or if you are unsure, you will be able to see all of the fields that the script touches in the Data Sources column. This will often resolve the issue, since, in many cases, it will be clear that the script does not touch any sensitive fields (ie those that have direct or indirect GL impact). You may well end up needing to review the logic of the code to establish that the code doesn’t create or change transactions in a way that violates segregation of duties.
What about Workflows?
Workflows can also execute as admin. We have a similar search for workflows called Execute as Admin Workflows. The selection criteria are different but the concept is the same.
.png)