Maintaining a state of audit readiness has become more critical than ever for organizations using PeopleSoft and other ERP systems in general. Today’s complex business environments, combined with the constantly increasing number of compliance regulations, require the audit to be dynamic, adaptable, and insightful to meet changing needs and expectations of investors, consumers, and regulators.

Unfortunately, what’s missing for most organizations is the lack of effective internal controls and policies that leads to compliance loopholes exposed during audits. So, before a deep dive into the success factors that prepare PeopleSoft teams for audits, let’s take a look at the basics.

What Is An Audit? What Makes PeopleSoft Teams Audit-Ready?

An audit is an official examination by a third party (independent auditor) to verify an organization’s adherence to reporting requirements (e.g., financial, operational, compliance, security, etc.). This verification is achieved by an auditor’s opinion on whether the entity’s reports are accurate and reliable. Typically, publicly traded companies, contractors to federal or state agencies, companies requiring bonds or insurance, private companies, and entities receiving government funding (e.g., universities, federal, state, and government agencies) undergo audits.

PeopleSoft teams should always log and monitor user activities to identify key risk indicators that could potentially lead to fraud. Establishing that your existing capabilities, internal controls, and policies are effective is the most significant step toward being audit-ready.

PeopleSoft Logging & Monitoring Are A Barrier To Audit-Readiness

When it comes to audits, PeopleSoft teams face certain challenges that make them unprepared for audits –

• User activity information crucial to mitigating user-centric threats is often missing
• Incident response for PeopleSoft is labor-intensive and time-consuming
• Incomplete audit trail of application-level user activity
• Auditing access and update activity require customization

Often, this brings to light some of the internal control deficiencies the organization being audited is grappling with, such as –

• Ineffective Access Controls
• Ineffective Data Field Level Controls
• Ineffective Transaction Controls

The results produced by your business units, internal auditors, and external auditors will officially conclude if your internal controls and policies are effectively mitigating risks.

8 Key Factors To Set You Up For A Successful PeopleSoft Audit

PeopleSoft teams always need internal controls to effectively mitigate significant IT risks relevant to financial reporting in and around business systems. Listed below are some of the key success factors that help organizations minimize financial risks in terms of systems, transactions, and data.

1. Companies implementing ABAC can enable automation of policy enforcement into their access controls and prevent violation of policy requirements.
2. A risk-based approach to identifying and classifying PeopleSoft data helps improve regulatory compliance and reduces costs by eliminating unnecessary control measures.
3. An effective regulatory change management process helps PeopleSoft teams keep pace with new regulations and avoid ineffective policies and internal controls that lead to excessive compliance costs.
4. Your company should be able to monitor authorization usage and user activity in PeopleSoft to detect SoD violations in real-time.
5. An effective vulnerability detection and remediation program helps organizations understand security weaknesses, assess risk exposure, and implement policies and controls to reduce the possibilities of a breach.
6. Deploying a Common Control Framework across all applications minimizes the need for ineffective and manual controls that result in increased audit, risk, and compliance costs in PeopleSoft.
7. Implementing step-up MFA for sensitive PeopleSoft transactions adds preventative and detective controls at the transaction level. This helps security teams flag suspicious transaction activities by users and improve audit readiness.
8. To comply with regulatory and audit requirements, organizations need to understand their residual risk levels (residual risk = inherent risk – control effectiveness). Continuously monitoring these risk levels ensures the operating effectiveness of their internal controls and helps mitigate overall risk.

Ace Your Audits With Appsian’s PeopleSoft Capabilities

An investment in additional PeopleSoft capabilities such as logging, monitoring, and policy enforcement, among others, is an opportunity to improve your audit readiness. With the Appsian Security Platform, you can implement, verify, and maintain effective controls to achieve your annual financial statement and compliance audit requirements in a more cost-effective manner with the following features –

• Adaptive Attribute-Based Access Controls to enable the enforcement of policy requirements into the access controls at the transaction and data level.
• Multi-Factor Authentication at the login, transaction, and data field levels to minimize risk exposure.
• Layered security, also known as defense-in-depth, protects against threats while incorporating compensating controls in the event of a control failure.
• Periodic Control Assessments to validate the effectiveness of existing controls.
• Continuous User Behavior Analysis to detect and report anomalies and threats.

Schedule a demo with our PeopleSoft experts to understand how you can implement effective controls and policies to stay audit-ready.

Increased compliance regulations and the rising number of internal threats have forced organizations to tighten application access and adopt the principle of least privilege. However, when ERP applications like JD Edwards have thousands of users accessing them to perform their daily tasks, managing user access requests while adhering to compliance requirements can be challenging. The technical staff needs to put a considerable amount of time and effort into managing the provisioning process. And for auditors, providing audit reports showing appropriate approvals requires going through extensive paperwork. However, a majority of these problems can be solved through automated user provisioning. Here are three key areas where automation can significantly improve your JD Edwards provisioning process.

Streamlines User Provisioning With Configurable Workflows

Traditionally, granting access to JD Edwards users has been a manual process, with emails moving back and for between business owners and security/application admins. The large number of requests received by admins means there is little done in terms of manual checks. Essentially, the process is inefficient and allows risk to creep in due to overprovisioning. For auditors, this means going through volumes of paperwork to verify compliance and highlight risk.

However, automating your access provisioning process reduces much of the manual tasks, eliminates paperwork, and provides a streamlined process to grant access. An efficient provisioning solution allows you to tailor the workflow based on your company’s processes and hierarchy, with defined steps at each stage. Automation makes routine user and role administration and clean-up tasks faster. It also enables the setting up of a large number of users during implementation or acquisition projects.

Performs Segregation of Duties Checks Before Role Assignment

One of the biggest fallouts of manual user provisioning is over-provisioning, which leads to data security threats and increases the risk of fraud. Granting users new roles without checking for conflicts can provide users with more access than necessary. This could lead to segregation of duties violations and audit failures resulting in hefty fines.

This challenge can easily be overcome by deploying an automated user provisioning solution that also does SoD checks before granting roles. This allows approvers and admins to immediately identify SoD conflicts and program the process flow to allow or deny role assignments. Another significant benefit of automation is that the entire process is documented, providing a complete audit trail as evidence for your auditors.

Maintains a Detailed Audit Trail Of The Entire Process

Documenting and logging all access requests is a critical requirement for audit and compliance. However, tracking access changes through paperwork and tables is a tedious process. Not only does it increase the burden on your internal audit teams, but it also allows violations to go unnoticed. Apart from this, manual processes make it challenging for auditors to dig out information and provide evidence to external auditors.

Automation enables you to log all provisioning activity with a date and time stamp, allowing you to see exactly who requested, approved, and assigned what and when. This provides evidence for auditors who are testing that role assignments are authorized appropriately. It also provides evidence for internal inquiries or escalations if incorrect roles are assigned or if people perceive that undue delays have occurred.

Automated User Provisioning With Appsian

Appsian’s User Admin Manager (UAM) is an automated user provisioning solution that provides a configurable workflow that automates the process of requesting, approving, and provisioning roles, reducing the workload and paperwork involved. In addition, it can prevent unintended SoD violations by checking for conflicts before roles are assigned and keeps a full audit trail as evidence for auditors.

Download the Appsian User Admin Manager Data Sheet to learn how automation can simplify your JD Edwards EnterpriseOne user provisioning process and help you achieve better compliance.

When it comes to preventing fraud, segregation of duties is a key component of any compliance and risk strategy. However, enforcing SoD policies within your Oracle EBS applications can be riddled with several challenges, especially if you’re a large organization with thousands of users. From overprovisioning of users due to ill-defined roles to lack of visibility into user activity to tedious audit reporting, the entire SoD exercise can be a compliance nightmare. Ultimately leading to undetected violations, failed audits, and potential fraud.

Here’s how intelligent automation can help you streamline your SoD efforts, prevent fraud, and provide data to validate your compliance measures.

Detecting SoD Conflicts Before They Happen

Oracle EBS admin teams deal with requests every day to grant new roles and authorizations to users either because they are new or assigned new responsibilities. Every time this happens, manually verifying if the new roles result in SoD conflicts is practically impossible. The result? Overprovisioning and SoD conflicts that remain undetected and lead to an increase in fraud risk and audit failures. However, a simulation tool that provides a testing platform for potential violations can detect these conflicts immediately and send alerts to the admin/security teams. When integrated into your Oracle EBS systems, the simulation tool can also enable you to enforce SoD directly into your live environment.

[Tip: Look for a solution that not only alerts you to SoD conflicts but also offers possible solutions to remediate the conflicts so that business operations are not impacted.]

Automated SoD Analysis and Remediation

Automation helps you go beyond static rules that are built into preconfigured libraries. An advanced solution equipped with dynamic modeling and analysis can detect SoD risks based on risk patterns not just within your Oracle EBS environment but across multiple applications. With intelligent automation, you will be able to detect SoD conflicts, sensitive access, and potential policy violations for existing users immediately upon deployment.

Real-Time Auditing and Conflict Resolution

If you’re still using manual processes, conflicts and violations are usually detected after the fact. Automated SoD solutions can analyze user behavior and usage data paired together with vast amounts of historical data in the field of risk assessment to resolve conflicts as they happen. The continuous monitoring of user activity enables you to detect risky user behavior, even within the scope of user’s authorizations. This allows the auditing of specific violation events in real-time.

For example: A buyer who usually issues POs for $5000 suddenly starts to issue $10,000 POs. Even though the buyer in question has the authorization to perform the transaction, this could be a potential fraud risk. An automated solution enables you to flag this behavior for real-time for auditing and validation. Security and admin teams can also use the analysis to focus only on user activities. This allows them to remove redundant authorizations that are not in use, effectively de-provisioning users and mitigating risk.

Effortless Audit Reports

Auditing Oracle EBS roles and authorization can be tedious and time-consuming for internal and external auditors. Manually cross-referencing user activity against role conflicts to identify SoD violations is a huge auditing challenge. The process is inefficient, unscalable, and could lead to mistakes. Failure to detect SoD violations could have serious compliance ramifications for the company.

Automation helps eliminate a large part of manual data collection and analysis. Auditors can instantly access pre-defined risk reports, while security teams can receive automated reports on all roles containing an SoD violation. Users who have performed activities that violate SoD can be identified easily to initiate preventative and remediation measures.

Automate Oracle EBS Segregation of Duties with Appsian

The implementation of segregation of duties as a fraud prevention control is essential for any enterprise; however, detecting SoD conflicts, remediating them, and preventing violations is a whole other game. Appsian enables you to effectively implement SoD across your Oracle EBS applications with an automated solution that works in real-time to detect and prevent SoD violations. It continuously monitors all Oracle EBS user activity and authorization usage to deliver key insights and reports that enable your security and audit teams to implement SoD with significant savings in cost and time.

Schedule a demo with Appsian’s Oracle EBS specialists to understand how you can simplify your SoD journey with automation.

In the first article of our material weakness series, we addressed what a material weakness is and how an ineffective access control weakness can be resolved. This article will look at another critical control weakness that can occur at the data field level. 

What are Data Field Level Controls? 

Field-level security settings, or field permissions, are intended to control whether a user can see, edit, and delete the value for a particular field on an object. These are the ERP data security capabilities that allow organizations to protect sensitive fields such as a candidate’s social security number without having to hide the candidate object. However, when these field-level controls are not configured correctly, users may be able to see sensitive personally identifiable information required by compliance regulations like CCPA and GDPR to be safeguarded.  

How to Resolve Data Field Control Weaknesses 

Protecting data at the field level is crucial from a data integrity and data privacy point of view. Here are six steps you can take to enhance field-level controls within your ERP applications: 

1. Implement the Zero-Trust security model that enforces the principle of never trust, always validate. 
2. Effectively using Multi-Factor Authentication (MFA) and enforcing MFA at various layers – login, critical transaction level, and critical data field level to enable layers of security. 
3. Implement layered security, also known as defense in depth (DiD), in overlapping layers of controls that typically provide the three control capabilities needed to secure assets: prevention, detection, and response. While no individual security control is guaranteed to stop 100% of the cyber threats, layered security provides mitigations against a wide variety of threats while incorporating redundancy or compensating controls in the event of a control failure. 
4. Transition from static security found in Role-Based Access Control (RBAC) security models to a dynamic security model like Attribute-Based Assess Control (ABAC) that enables the enforcement of policy requirements into the access controls at the transaction and data level.   
5. Design dynamic security controls capabilities to improve their ability to identify, detect, prevent, and respond to anomalies and threats. 
6. Perform periodic control assessments to validate the effectiveness of the existing controls. 

Protecting Data Fields with Appsian Security 

The Appsian Security Platform has been designed specifically to address security and governance challenges that companies face within their ERP ecosystem. Appsian offers a range of solutions that enable you to implement Zero Trust security. From multifactor authentication at the login level to masking of sensitive data fields with the ability to reveal data only after authentication, Appsian provides complete control over data access and data exposure that goes beyond the initial access.  

Appsian’s attribute-based access control also ensures that authorizations are not absolute. It considers the context of access when allowing or restricting data access even at the field level. For example, the click-to-view feature provides access to data while also maintaining a log of what sensitive data was accessed when and by whom. The Appsian Security Platform takes a layered approach to security within your ERP ecosystem to enable field-level controls that prevent, restrict, and monitor access and modification of any field data. 

Take a first-hand look at how Appsian can enable field-level controls in your ERP applications without disrupting business operations. Schedule a demo with our ERP experts.  

Next in the Series: Ineffective Transaction Level Controls 

This is the first article of a multi-part series featuring material weaknesses. Each piece will focus on one critical internal control weakness and provide solutions on how to resolve the weakness with granular security controls. 

The purpose of an independent audit of a company’s financial reports, called a Financial Statement Audit, is to form an opinion by the independent auditor if the current and potential investors can rely upon the accuracy and completeness of the company’s financial statement. During this audit, the auditors will evaluate the design and operating effectiveness of the internal controls intended to manage the risks relevant to maintaining the accuracy and completeness of the financial reports. The auditor may identify deficiencies in the company’s internal control over financial reporting, which will be ranked from lowest to highest impact as Control Deficiency, Significant Deficiency, or Material Level Weakness.   

What is a Material Weakness? 

According to the PCAOB, a material weakness is “a deficiency, or a combination of deficiencies, in internal control over financial reporting, such that there is a reasonable possibility that a material misstatement of the company’s annual or interim financial statements will not be prevented or detected on a timely basis.” Companies with material weaknesses are required to report them in their public SEC filings in the period in which they were identified. There are multiple types of internal control weaknesses that could lead to a material weakness.  

Access Control Weakness 

Segregation of duty (SoD) security violations are among the most common examples of an access control issue in ERP applications that lead to an auditor reporting a material-level control weakness. The principle of SoD is based on appropriately segregating critical duties to more than one person. For example, a single person should not have the ability to create and approve vendors, nor should that same person have the ability to create and approve payments. These four access rights could easily lead to fraudulent activity.   

Resolving SoD Security Violations with Appsian 

The avoidance of SoD security violations within your ERP application starts with an effective user-provisioning process that enables organizations to proactively analyze the role assignments to verify that no SoD violation exists before authorizing the access assignment. Unfortunately, most organizations use manual user provision processes that are tedious and error-prone.  

Appsian automates your user-provisioning, de-provisioning, and access recertification process and enables real-time detection and prevention of SoD violations. The Appsian Security Platform also continuously monitors user behavior and authorization usage. This allows organizations to de-provision unused authorizations and flag sudden deviations in user activity, thereby reducing the overall risk and enhancing threat detection. 

Some of the other leading practices offered by Appsian to prevent SoD violations include: 

Policy-Based Access Control
With policy-based access, organizations can go beyond roles to implement controls based on contextual attributes. A policy-based access control security model improves your policy enforcement capability at the SoD level.  

Identity & Access Management (IAM)
Authorization, being an integral part of IAM, allows you to increase the effectiveness of your user-access management lifecycle process. By implementing dynamic MFA at the login, page, and data field level, you can ensure sensitive data and transaction changes are logged and protected. 

Identity Governance & Administration (IGA)
With real-time user monitoring, you can remove unnecessary authorizations while gaining governance and oversight of all user access to increase your ability to detect and prevent SoD violations.  

The Appsian Security Platform gives you complete visibility and control of your ERP applications from the inside to resolve critical material control weaknesses. See the Appsian Security Platform in action by scheduling a demo. 

I helped some folks the other day with an issue that had the potential to be very serious for them; exposure of production data without someone needing to login to the production system. Not good.

The Problem

For testing purposes they have copies of their production PeopleSoft databases; one for Financials and one for HCM. These copies are refreshed regularly and there are scripts run against them to handle some cleaning/sanitizing of the production data, so that the database can be used for testing.

They have some people that they allow to login to these test environments with any account so that they can confirm the results of basic processes. The accounts don’t have default passwords, so this access was limited to the people that they authorized to do testing, but testers with access to these cloned environments could login as anyone.

One of the testers (we’ll call him Fred) was logged in to the Financials test environment as some other user (we’ll call her Sally) to test some process that would normally be initiated by Sally in the production system.

While doing this testing, Fred wanted to enter his timesheet data so he clicked on a link to go to the production HCM system for time entry. Much to his surprise, he was logged in to HCM as Sally! So Fred goes back to the test Financials environment, logs in as a different user, clicks the link into production HCM and sure enough he is logged in as that user in production HCM. To Fred’s credit, Fred alerted the PeopleSoft support team there instead of snooping around in HCM.

How did that happen?

The problem comes from the fact that the production environments were configured to trust each other for PeopleSoft Single Signon, but the node names and node passwords were not changed as part of the environment cloning logic.

So when Fred signed on to the cloned Financials environment, the PS_TOKEN cookies generated are identical to what the production environment would generate (the details of PS_TOKEN cookie are documented in PeopleBooks, but the node name and node password are the important pieces here).

How could this be prevented?

There are several different ways of preventing this from happening. Let’s take the pragmatic ones first.

1) Change the node password as part of the refresh script.

This is the easiest, most expedient thing to do. It is the absolute minimum way to solve this problem.

Although this solves the security problem, it introduces a headache for security auditors because the app server logs in the production environment will be full of warnings about failed logins from bad node passwords. That means that testers accessing production while logged in to the test environment will be indistinguishable from someone trying to break in by generating their own PS_TOKEN cookies.

It’s not nice to annoy your security auditors by purposely creating log entries that look like break-in attempts, but are actually OK 🙂

2) Change the node name.

Changing the node name when you clone environments will also solve the problem (because then the production environments will no longer trust the cloned nodes since they don’t recognize the new names). This also solves the log problem mentioned in the previous item.

Changing the node name can have an impact on Integration Broker testing, but that just means that your integration test scripts need to be aware of this. Not a huge drawback in my opinion.

3) Use distinct passwords for each account in the test environment.

This is easy enough to do, it’s mainly a question of distributing the passwords to the testers so that they can get in and do their jobs. Depending on your organization, this may or may not be easy.

4) Don’t provide passwords to the testers, but allow them to reset them on demand.

Similar to the previous item, but gets around the distribution issue by making it an after the fact auditing issue. If Fred requests the CEO’s password in the test system, it’s very easy to audit for that and force Fred to explain why he felt that was necessary.

Computer security is typically focused on preventing people from doing things, but in some cases this model of auditing and disciplining after the fact may be OK.

This model reminds me of when we took our dog to a dog trainer a long time ago that recommended leaving a steak or something else on the kitchen counter for the dog to find. This was in conjunction with hiding around the corner so that at the moment the dog put his paws up to grab the steak, you would jump out and impress upon the dog that it wouldn’t be wise to do that again. A real-time security audit if you will 🙂

What are some of the less pragmatic options?

5) Have a new version of PeopleTools that can detect when a database is copied, and automatically scrub key information like node passwords, GUID, etc.

The implementation of this would be platform specific, but do-able. It would complicate things like having a hot database backup server though. I’m sure those sorts of issues could be addressed though.

6) Embed additional information beyond just node name and node password (like database name) in the PS_TOKEN cookie.

One issue that I can think of with this is that older PeopleTools versions would not be able to interoperate with this, but it could be a flag on the node definition as to whether interoperability with earlier versions of PeopleTools is required. If interoperability was required, then the existing PS_TOKEN format would be used, otherwise the newer format would be used.

Why didn’t they know about this?

PeopleSoft Single Signon is documented in PeopleBooks, but there aren’t any great writeups out there on the implications of it when cloning a PeopleSoft environment.

There are lots of writeups out there on “How to Clone a PeopleSoft Environment”, and some discuss the importance of getting the node configuration correct, but they typically come at from the perspective of just making sure the environment works; not the security implications of it.

PeopleSoft Single Signon is well documented in PeopleBooks, but it just doesn’t seem to jump out at people when thinking about cloning. I will give a shout-out here to Brent Martin of ERP Associates. Brent’s writeup on cloning a PeopleSoft database is the only one out there that I could find that mentions this issue at all.

Labels: 2009, Audit, Security, Sysadmin

Internet Explorer manages a whole host of security settings through the concept of security zones. Security zones have names such as Internet, Intranet, Trusted Sites. There’s also the concept of a Custom zone, which just means that you’ve gone in and set one of the lower level security settings specifically.

Each time you load a web page, you can see on the bottom right hand status bar in IE, which zone that it thinks that it is in. One thing that catches some people is that IE does not have any sort of automatic facility to detect what is your corporate domain. Even though you may have done Windows level authentication to “mycompany.com”, you’ll still notice that when you visit “psft.mycompany.com”, IE will flag that as an Internet site.

You can manually change these settings for particular sites/domains through Internet Explorer (Tools -> Internet Options -> Security), but if you have lots of machines to update, it’s probably better to use some automation.

Microsoft provides some tools for doing this, but in the case of just adding a single site or domain, you can also go through and just push out updates via .reg files. If you’ve never pushed out any registry changes via a .reg file, it’s not hard, but you definitely want to be careful because if you screw up the registry in Windows you can cause a lot of damage. There are probably people within your organization that can handle this though.

So, with that caveat out of the way, what does a .reg file look like for adding your PeopleSoft servers to the Intranet zone? Assuming that the server names are psfthr, psftfin, psftcrm and are all in the mycompany.com domain and just running http, then this is what you’d have.

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionInternet SettingsZoneMapDomainsmycompany.com]

[HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionInternet SettingsZoneMapDomainsmycompany.compsfthr]
“http”=dword:00000001

[HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionInternet SettingsZoneMapDomainsmycompany.compsftfin]
“http”=dword:00000001

[HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionInternet SettingsZoneMapDomainsmycompany.compsftcrm]
“http”=dword:00000001

Not too bad. How about if we just want to flag the entire mycompany.com domain as the Intranet?

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionInternet SettingsZoneMapDomainsmycompany.com]
“*”=dword:00000001

Before making changes like this, you’ll want to check that you don’t already have any custom settings for your standard workstations. If so, then you’ll need to merge these changes in with however those settings get deployed in your organization.

If not, then you can save your own versions of these files with a .reg extension, and they’ll be ready for importing. You can use the /quiet flag for regedit to add this as part of your user’s Windows login scripts.

Labels: Microsoft Windows Browser