Designing NetSuite ERP Application Security – Leveraging Fastpath Assure Access Monitoring Solutions

PROTIVITI • DESIGNING NETSUITE ERP APPLICATION SECURITY | 1

Introduction

Defining netSuite Security requirementS in the early phaSe of an implementation, upgraDe or re-implementation project can help enSure efficiency anD a “clean Slate” with regarD to mitigation of Security riSkS prior to go-live. management of Segregation of DutieS (SoD) riSkS iS an important conSiDeration for companieS implementing an internal control framework aS part of their roaD map to becoming a public company.

There’s an art to designing effective security in NetSuite. A bad security design exposes an organization to a number of risks, including unauthorized system access, increased potential for fraud, inefficient user access provisioning, and frequent projects to mitigate security exposure.

There are two main approaches when building application security in NetSuite. The first is the top-down or proactive approach described in detail in this white paper. It starts by defining security requirements up front during the analysis and configuration phase. The second is the bottom-up or reactive approach, which starts with developing NetSuite security roles as a subsequent step after business processes have been defined and set up in the new system.

Organizations choosing the latter approach do not address security risks or compliance requirements during the initial design of their NetSuite systems. Instead, they assess security risks and requirements after security has been built into the sys-tem. This method may appear to be efficient in the shorter term, but it tends to be more time-consuming over the long term because security often must be re-evaluated due to excessive access and potential SoD conflicts.

The bottom-up approach is also particularly inefficient when a high number of SoD conflicts must be resolved or security roles need to be changed to comply with financial regulations and audit requirements, and to minimize the roles that need to be maintained.

Access Monitoring With

Designed by auditors, Fastpath Assure allows NetSuite users to analyze their security design for potential SoD conflicts quickly and easily. The workflow in Fastpath Assure allows users to propose, approve and implement SoD resolutions and mitigations throughout the audit process. Fastpath Assure provides a comprehensive, interactive tool for small to large organizations to help identify all of the conflicts within NetSuite, better understand security, and provide the necessary reports to both internal and external audit teams.

PROTIVITI • DESIGNING NETSUITE ERP APPLICATION SECURITY | 2

Defining security requirements in the early phase of a NetSuite implementation (“NetSuite project”) can help ensure efficiency and achievement of a clean slate with regard to mitigation of security risks prior to go-live. It is also important to leverage access management technology, such as Fastpath Assure, to monitor whether security design requirements and SoD restrictions are properly maintained throughout the system build, deployment and go-live phases.

Top-Down or Proactive Approach

Define SoD Policies &

Rule Design

Initial Role & User Design

Role Build & User Assignment

Role & User Access

Risk Analysis

Security Testing & Go-Live

Preparation

Production Readiness& Support

Bottom-Up or Reactive Approach

Initial Role & User Design

SoD Remediation

SecurityTesting

Production Readiness& Support

Role & User

Access Risk Analysis

Role Build & User Assignment

NetSuite Project Phases

Initiate Analyze Configure OptimizeDeploy

Go-Live

Repeat steps untilsecurity risks are mitigated

Figure 1: Approaches to Building NetSuite Application Security

TOP-DOWN APPROACH FOR NETSUITE SECURITY DESIGN

1. Define SoD Policies and Rule Design

The first step in implementing NetSuite application security using the top-down approach is to work with business process owners (BPOs), NetSuite functional leads and compliance organizations to identify business processes and applications in the scope of the NetSuite project and determine how the different modules (e.g., Payments, Transactions) will be utilized for each business process.

A series of meetings and validation workshops should be conducted to establish an agreed-upon and written SoD management framework, including policies with respective risk descriptions, risk ratings, and compliance and audit requirements.

PROTIVITI • DESIGNING NETSUITE ERP APPLICATION SECURITY | 3

Applications, systems or modules where financial information is entered or processed

Payments, TransactionsIn-Scope NetSuite

Applications

Definition Example

Definition of overall risk that drives the SoD rule and security controls

Fraud: Acts committed by internal or external sources, intentional and concealed, causing loss of funds, value, reputation or unauthorized benefit

Business Risk

Definition of what a user could do if allowed certain access in the NetSuite system

Cut fraudulent or unauthorized checks

Risk Description

Job functions that represent or increase risk if provided to a user without proper monitoring

Access to create or change accounting records and master data maintenance

SoD-Sensitive Access Policies

Tasks assigned to a specific user Create vendor master account, post payments, etc.

Job Function

NetSuite objects and permissions related to conflicting job functions

Vendors vs. payment methods

SoD Rule

Figure 2: Key Components of an SoD Management Framework

As part of the framework definition process, SoD policies should be outlined and classified into risk levels, such as critical, high, medium and low, as described in the example below. This will help management prioritize areas of focus during role build or security remediation phases:

• Critical risk:

– Represents significant impact to company operations or company value

– Risk cannot be mitigated; it requires remediation

• High risk:

– Represents a direct financial misstatement risk or significant profit and loss (P&L) impact

– Affects corporate image

– Represents a deviation on standard best-practice processes or noncompliance with laws and regulations

– Generates inconsistencies on master data governance or transactional data

– Causes loss or theft

– May be mitigated with an effective management-level report, or may require remediation

PROTIVITI • DESIGNING NETSUITE ERP APPLICATION SECURITY | 4

• Medium risk:

– Causes a financial statement reclassification risk

– Represents medium P&L impact (e.g., percent of revenue, materiality, potential loss)

– Disrupts an operational process (no impact to financial statements)

– Causes noncompliance with internal policies

– Can be mitigated with a management-level report

• Low risk:

– Costs more to mitigate than the cost of the risk to the business

These definitions vary by company based on the organization and industry-specific criteria. After these SoD policies and risks are defined, NetSuite permissions should be evaluated to identify those that provide the ability to create, edit or delete data related to any of the identified risks.

Ultimately, NetSuite permissions should be configured in an automated security monitoring solution, such as Fastpath Assure, as “rule sets,” which are used to analyze SoD conflicts at the role or user level.

2. Initial Role and User Design

After establishing the SoD policies and rule sets in Fastpath Assure, the next step is to design NetSuite security roles. The first task is to review “to-be” business processes and conduct a preliminary analysis of individual tasks to be performed once the new system goes live. NetSuite provides a set of out-of-the-box roles that can serve as a template for these selections. At this point, the NetSuite implementation team will group permissions into the beginning stages of NetSuite custom roles.

The next step is to conduct workshops with BPOs to validate that the respective group permissions are aligned with the “to-be” business processes in the NetSuite environment. At this stage, “role templates” will be doc-umented; they consist of the role’s name, a brief description of the role, the permissions assigned to that role, and the access level of each permission.

Role Name Role Description Permission Access Level

A/P Clerk Accounts Payable Clerk

Inventory View

Vendors Edit

Contacts Full

A/R Clerk Accounts Receivable ClerkInventory View

Contacts Full

Figure 3: Example of a NetSuite Security Design

Also, “role owners” must be defined for each role template. Role owners are typically part of the functional implementation, or business teams, and usually “own” or are responsible for managing and reporting on the data being updated by the NetSuite permissions and roles they own. For instance, a corporate controller would own finance-related roles. Responsibilities for role owners include review and approval of NetSuite permissions to be included in the role and ongoing maintenance of the role (e.g., permission additions, deletions and approval of mitigation controls if conflicts occur).

PROTIVITI • DESIGNING NETSUITE ERP APPLICATION SECURITY | 5

NetSuite Security Design ConsiderationsRole Types

The first decision to make during the actual design of NetSuite security concerns the type of roles that should be created. The following are the most commonly used role types:

Job-Based or Functional Roles

The purpose of job-based roles is to give each user one role (e.g., Accounts Payable Manager) that encompasses all of that person’s job activities. This approach utilizes fewer roles, but also gives users access to transaction codes they might not need. Also, the roles themselves might have SoD conflicts due to the large number of transactions assigned.

Task-Based Roles

The intention of task-based roles is to give each user multiple roles, each representing one job task (e.g., Release Purchase Requisition). This approach utilizes more roles, but will limit user access to the respective tasks performed. The choice of approach will depend on the consistency of job positions and the maturity of human resources (HR) departments in relation to the integration between NetSuite access requests and employee hiring, transfer and termination processes.

HR or Position-Based Design Roles

Another consideration when designing NetSuite security is the level of integration with HR processes (e.g., hiring, termination) and overall consistency with job descriptions and positions. In an ideal scenario, NetSuite roles should reflect job responsibilities, but if HR departments and positions are not mature or consistent, an independent security design based purely on job functions may be the best option. For organizations to apply a position-based design, HR job descriptions would have to be well defined and consistent across the company. Also, “hire-to-retire” processes would need to be in a mature stage to enable integrated provisioning.

Custom vs. Pre-Delivered NetSuite Roles

It is important to note that each NetSuite system comes pre-delivered with out-of-the-box roles. An organization can decide initially to implement these roles instead of tailoring security design. It is not recommended, however, that out-of-the-box roles be used as a long-term security strategy. These roles are designed as one-size-fits-all roles. This means they have a wide range of job activities combined in a single role, which makes it nearly impossible to provision roles to a user without granting excessive access. Also, out-of-the-box roles may not meet all business access requirements and control restrictions.

Global Permissions vs. Personalized Roles

Global permissions provide a powerful way to modify a particular user’s security without affecting a user’s roles or permissions. The assignment of a global permission to a user will give that user permission at the specified access level for all roles assigned. This global permission overrides any role permission assigned to a user. In designing roles, it may be possible to use this functionality to alleviate the need to make specialized roles for individuals who have specific tasks not covered by a current role.

3. Role Build and User Assignment

Once the initial NetSuite role templates have been designed and approved, the roles can be built in NetSuite and subsequently assigned to end users. The technical design phase starts with building “master roles” or “template roles,” including the grouped permissions. Building master roles requires close coordination with the systems integrator and BPOs so that all NetSuite permissions being used as part of the role design are understood in terms of functionality (e.g., create master data, update financial statements) and are also properly incorporated into the template roles.

Designing roles that are free from SoD conflicts early in the NetSuite project can lead to increased granularity and more restrictive access, as well as increased transparency in user authorizations. In addition, it can reduce ongoing security maintenance because it makes it easier to respond to changes in user responsibilities resulting from the implementation of new NetSuite functionality and/or organization realignment.

End user role assignment is a critical step due to the different restrictions that must be applied to users (e.g., some users may need access to one or multiple subsidiaries, departments, classes or locations). The end user assignment process includes assigning new roles to users based on their job responsibilities.

During these steps, it is important to leverage Fastpath Assure to confirm roles are SoD conflict-free before assigning them to end users. If a master role has inherent SoD conflicts, all users assigned to that role will also have SoD conflicts.

PROTIVITI • DESIGNING NETSUITE ERP APPLICATION SECURITY | 6

User

Role Group of Permissions

Permission Information and Level of Access Granted

Within a Role (e.g., Update Vendor)

Global Permissions

Figure 4: NetSuite Role Build and User Assignment Process

4. Role and User Access Risk Analysis

At this stage, Fastpath Assure should be leveraged to perform periodic role and user analyses to determine if the newly designed NetSuite roles are in compliance with SoD policies. This is achieved by simulating and monitoring changes affecting NetSuite security design and providing timely feedback to BPOs in case poten-tial conflicts arise. Risk analyses should be run on a periodic basis, especially after unit and integration testing, which is when the NetSuite system design will be updated to accommodate process improvements.

It is important to note that the defined NetSuite rule set in Fastpath Assure is customizable and can change during the course of the NetSuite project, given that new NetSuite permissions may be added to “to-be” processes.

To ensure a NetSuite environment is “clean” or “conflict-free” post-go-live, a sound NetSuite security provision-ing process must be designed and implemented. This includes procedures that require NetSuite security teams to perform a risk simulation in Fastpath Assure prior to granting user access or modifying a role. This simulation will determine if role or user changes are posing SoD or excessive access security risks.

In addition, continuous monitoring procedures must be established and followed as the project go-live date approaches. Detective NetSuite security monitoring processes also should be established, including generating periodic SoD violation reports reviewed by BPOs and role owners to validate security changes. Both of these security provisioning processes can be implemented and executed within Fastpath Assure.

The data export/import process from a NetSuite environment to Fastpath Assure is accomplished by exporting the required reports from the NetSuite environment to the designated local computer and then importing them using the Fastpath Assure application. This way, NetSuite application integrity is assured because the Fastpath Assure application never has direct contact with the NetSuite environment.

5. Security Testing and Go-Live Preparation

NetSuite security Unit Testing (UT) and User Acceptance Testing (UAT) are critical steps to ensure users experience minimal access issues prior to go-live. NetSuite security testing includes executing all NetSuite permissions within a role to confirm the role has the required permissions to complete the process (e.g., view and create a financial transaction).

These steps should be performed in conjunction with project functional testing (during NetSuite implementa-tions or upgrades) or before assigning the new roles in the production environment (during security redesign or remediation projects). Security testing should also include formal SoD and sensitive access reviews to confirm the newly created or updated NetSuite roles are as SoD conflict-free as possible and that access to key func-tions (e.g., update vendor, update customer accounts) is properly restricted.

PROTIVITI • DESIGNING NETSUITE ERP APPLICATION SECURITY | 7

Involving security in the early stages of functional testing allows the discovery of potential security issues before it is too late – or costly – to modify roles. It is also very important for the final UAT process to create test users in the quality assurance (QA) environment, with the NetSuite roles to be used in the production environment (i.e., users with accurate NetSuite role assignments). This will allow proper identification and remediation of security changes, including verification of “authorized conflicts” and resolution of “unauthorized conflicts” prior to go-live.

Be sure to work closely with BPOs, role owners and the NetSuite implementation team to remediate unau-thorized conflicts by regrouping the permissions within the conflicting role(s) or reassigning the role(s) for the conflicting user. For SoD conflicts that cannot be resolved for a business-approved reason, such as limited headcount, mitigating controls should be identified and documented. Fastpath Assure provides a process for documenting mitigating controls that have been put into place.

6. Production Readiness and Support

Once testing is complete, the newly designed roles and global permissions can be assigned to end users. It is very likely that access issues will be encountered during go-live, stabilization and the post-go-live periods due to the overall complexity of implementing or changing enterprise resource planning (ERP) systems and pro-cesses in an organization. As such, it is critical to establish a support team specifically assigned to address any access issues during go-live and stabilization activities. This team not only can help resolve access issues on a timely basis, but also can run access risk reports to determine if security changes will result in SoD or other access risks. Also, a communication plan should be established to ensure affected users are aware of any changes and support protocols related to go-live of the system.

A common practice during NetSuite implementation projects is to allow for temporary broader access for “power users” (administrator role) during the go-live and stabilization periods. This is to help with stabilization of the new system and to ensure users are capable of performing job functions during and after go-live. It is important to review and remove this temporary broader access after the new implementation is stable.

CONCLUSION

Companies should consider their approach to building NetSuite application security in the early stages of their implementation project. Embedding proper security requirements during the system analysis and configuration stages helps to avoid the need for redesign or remediation later. Using automated security monitoring solutions, such as Fastpath Assure, and applying best practices to security design can increase efficiency and accelerate the security design and implementation of conflict-free roles. It also can help dramatically reduce remediation of security issues in the future.

Organizations that meet any of the following criteria should consider assessing their security design and the implementation of security monitoring solutions in order to “clean” and “maintain” their NetSuite ERP security environment:

• Organization-specific SoD policies have not been defined, approved by the business or are outdated.

• Creation of new roles and/or new role assignments generates new SoD conflicts requiring remediation or mitigation.

• A significant number of SoD conflicts exist within roles.

• The NetSuite environment consists of more roles than users.

• SoD checks are performed manually (or not performed).

• Automated security monitoring solutions, such as Fastpath Assure, are not in place to support ongoing monitoring of the environment.

• There is a lack of business involvement in the SoD risk management process.

PROTIVITI • DESIGNING NETSUITE ERP APPLICATION SECURITY | 8

ABOUT PROTIVITI

Protiviti (www.protiviti.com) is a global consulting firm that helps companies solve problems in finance, technology, operations, governance, risk and internal audit, and has served more than 60 percent of Fortune 1000® and 35 percent of Fortune Global 500® companies. Protiviti and our independently owned Member Firms serve clients through a network of more than 70 locations in over 20 countries. We also work with smaller, growing companies, including those looking to go public, as well as with government agencies.

Named one of the 2015 Fortune 100 Best Companies to Work For®, Protiviti is a wholly owned subsidiary of Robert Half (NYSE: RHI). Founded in 1948, Robert Half is a member of the S&P 500 index.

About Protiviti’s Application Security and Segregation of Duties Practice

Protiviti’s Application Security and Segregation of Duties professionals provide NetSuite Security guidance and implementation support to ensure organizations better understand and manage risks around their ERP and supporting systems. Our consultants help companies identify and manage security and application access risks effectively across the organization’s enterprise architecture.

Contacts

Ronan O'Shea Tom Luick+1.650.678.0260 +1.773.531.4837ronan.oshea@protiviti.com thomas.luick@protiviti.com

© 2015 Protiviti Inc. An Equal Opportunity Employer M/F/Disability/Vet. Protiviti is not licensed or registered as a public accounting firm and does not issue opinions on financial statements or offer attestation services. PRO-0815-103068

* Protiviti Member Firm

THE AMERICAS

UNITED STATES

AlexandriaAtlantaBaltimoreBostonCharlotteChicagoCincinnatiClevelandDallasDenverFort LauderdaleHouston

Kansas City Los Angeles Milwaukee Minneapolis New York Orlando Philadelphia Phoenix Pittsburgh Portland Richmond Sacramento

Salt Lake City San Francisco San Jose Seattle Stamford St. Louis Tampa Washington, D.C. WinchesterWoodbridge

ARGENTINA*

Buenos Aires

BRAZIL*

Rio de Janeiro São Paulo

CANADA

Kitchener-WaterlooToronto

ASIA-PACIFIC

AUSTRALIA

BrisbaneCanberraMelbourneSydney

CHINA

BeijingHong KongShanghaiShenzhen

INDIA*

BangaloreHyderabadKolkata MumbaiNew Delhi

JAPAN

Osaka Tokyo

SINGAPORE

Singapore

CHILE*

Santiago

MEXICO*

Mexico City

PERU*

Lima

VENEZUELA*

Caracas

EUROPE/MIDDLE EAST/AFRICA

FRANCE

Paris

GERMANY

Frankfurt Munich

ITALY

Milan Rome Turin

THE NETHERLANDS

Amsterdam

UNITED KINGDOM

London

BAHRAIN*

Manama

KUWAIT*

Kuwait City

OMAN*

Muscat

SOUTH AFRICA*

Johannesburg

QATAR*

Doha

SAUDI ARABIA*

Riyadh

UNITED ARAB EMIRATES*

Abu Dhabi Dubai