[searchandfilter taxonomies="search"]

Solving Complex Security Challenges with Dynamic SAP Data Masking

It’s been a period of unprecedented change and adaptation for organizations of all sizes and in every industry over the past 18 months. During this time, I’ve had the opportunity to speak with many of our SAP customers about how they are managing their business risks and protecting their sensitive data. While the topics vary, I’ve noticed a recurring theme: there is a growing—and urgent—interest in using SAP dynamic data masking to strengthen data protection and enforce governance and compliance policies.

But what exactly do we mean by SAP “dynamic” data masking, and what are the best practices for using it to manage business risks and increase data security?

Dynamic Data Masking in SAP Starts with Attribute-Based Access Controls (ABAC)

Data masking is used to protect various types of sensitive and personal data stored in ERP applications, including intellectual property, personally identifiable information (PII), financial data, such as credit card, bank account information, and more. As traditional security perimeters dissolve and compliance requirements increase, protecting your ERP data is of growing importance. This is where dynamic data masking shines. Focused on protecting data at the UI-level in production systems, dynamic data masking can significantly reduce your risk exposure.

A Quick Clarifier: Often, data masking is used in non-production environments to protect ERP data copied from production. This technique is also known as data obfuscation, data scrambling, or data anonymization – and modifies the data itself – meaning it does not work for production systems. Dynamic data masking obfuscates information at the presentation layer (UI-level) without affecting the underlying data (at the database level).

Before dynamic data masking, traditional data masking policies used a static, role-based approach. For example, you include the role(s) and the field(s) in your rules – and a mask is always applied in all circumstances. While it minimized exposure, the static nature limited adoption as it would create barriers to data, and policies would have to be continually updated as users changed roles.

Dynamic data masking extends this policy logic by incorporating attribute-based access controls (ABAC), allowing flexible and wide-reaching rules to be created that incorporate identifiers such as role and other user, data, and access attributes. For example, user’s residency or security clearance, org code, IP address, location, and much more.

Static data masking versus dynamic data masking seems cut and dry. However, my conversations with SAP customers revealed two distinct approaches to using dynamic data masking: One focused on user attributes, and the other focused on the dynamic attributes of access and data itself. While the former allows simple, wide-reaching data masking that addresses functional risk, the latter enables a contextual, risk-based approach that truly balances data security with the needs of the business to access data.

Data Masking Approach #1: Wide-Reaching Policies Based on User Attributes

Many organizations start their data masking journey by analyzing how necessary it is for specific users to see specific data. Focused on functional risk, this approach aligns to least privilege and sets out to mask data that is unnecessary for a user’s job. For example, does a customer service rep need to see the full bank account info on an order? In most cases, no. Or should an HR manager be able to view the PII in a user’s profile from another business unit they are not responsible for? Certainly not.

Using dynamic data masking in these scenarios can deliver wide-reaching policies that incorporate user attributes such as role, business unit, org code, or country of residency. The ABAC technology allows data masking to be enforced “dynamically” when any activity that matches the defined conditions is present. (Meaning there is no need to make changes when users change roles, new users are created, etc.)

This approach is superior compared to the legacy approach that relies on static, role-based policies. Data exposure can quickly be minimized, and from a lifecycle management perspective, ownership is much simpler. However, data is still masked at all times for users, which means the practical scope of usage is still limited.

Data Masking Approach #2: Risk-Based Policies Based on Access Attributes

I’ve recently noticed a shift in thinking from policies based on user attributes towards those based on access attributes. Organizations might be realizing, thanks to the growing number of data privacy regulations and enforcement fines, that their data is now a liability, and they need to implement more risk-based masking policies based more on access attributes than user attributes.

Now an organization can leverage context-aware access controls to mask data in high-risk scenarios and show data in trusted scenarios. For example:

Masking unpublished financial data from unknown IP addresses/locations
Masking sensitive business data outside regular working hours 
Masking data for emergency access sessions

A recent use case for this approach to SAP dynamic data masking is on display at a Canadian rail company that needed to provide secure access to sensitive data to a hybrid workforce while also allowing access to self-service SAP modules on mobile devices for their remote workers traveling from city to city and connecting from wherever they have a Wi-Fi connection. They were able to enforce risk-based data masking policies based on access attributes such as location, IP address, time, data sensitivity, and more.

Protecting Data with SAP Dynamic Data Masking Solution

The more I speak with our SAP customers, the more I realize the different “definitions” they have about dynamic data masking. The more accurate definition is that SAP dynamic data masking uses risk-based policies based on access attributes. Without ABAC, companies must enable data masking with extensive customization, resulting in an unscalable ad-hoc solution.

Fortunately, the Appsian Security Platform’s (ASP) dynamic data masking leverages ABAC capabilities to provide fine-grained control over which sensitive data fields can be masked for any specified user in the context of any situation.

I invite you to contact the SAP experts at Appsian to learn how for yourself how we can improve SAP data security and reduce compliance risk with a fully dynamic data masking solution.

Put the Appsian Security Platform to the Test

Schedule Your Demonstration and see how the Appsian Security Platform can be tailored to your organization’s unique objectives

How to Reduce SoD Conflicts in SAP for Effective SOX Compliance

With several large public companies deploying SAP applications for their financial and accounting operations, ensuring SOX compliance within the SAP ecosystem is crucial for a successful audit. Segregation of Duties (SoD) in SAP plays an important role in managing roles and authorizations among SAP users to prevent conflicts and mitigate the risk of fraud.

However, user access to SAP systems is dynamic in nature due to constantly changing roles, making it challenging to track, detect, and prevent SoD conflicts. Unfortunately, SAP’s security/access management capability is static, preventing a risk-adjusted adaptive security approach recommend by Gartner. In the context of SAP, SOX compliance demands that organizations also implement an effective monitoring, alerting, and prevention mechanism for fraudulent activity arising from SoD conflicts.

How SOX Affects Internal Reporting and Controls

The Sarbanes-Oxley Act has two sections that address requirements for evidence of effective internal controls over accounting and financial reporting – sections 302 and 404. Section 302, titled: Corporate Responsibility for Financial Reports, states that the CEO and CFO are directly responsible for the accuracy, documentation, and submission of all financial reports as well as the internal control structure to the SEC. That act mandates the CEO and CFA to confirm that they accept personal responsibility for all internal controls and have reviewed these controls in the past 90 days.

While SOX section 302 defines the internal controls affecting accounting and financial reporting, SOX section 404, titled Management Assessment of Internal Controls, specifies requirements for monitoring and maintaining internal controls related to a company’s accounting and financials. Section 404 is the most complicated, most contested, and most expensive to implement of all the Sarbanes Oxley Act sections for compliance.

The Role of Access Controls for SOX 404 Compliance

Access Controls are intended to effectively manage the inherent risks associated with managing access to systems and data. These risks include segregation of duty security violations, granting excessive access, ineffective access change management process, ineffective access termination process, ineffective access review and recertification process, and poor password enforcement, to name a few.

According to Audit Standard # 5, if these types of access risks are not effectively controlled, the external SOX compliance audit will report a control issue. Control issues are ranked as a control deficiency, significant control deficiency, or worst of all, a material level control weakness. Appsian ProfileTailor GRC helps organizations effectively manage the entire SAP access management lifecycle to monitor and manage the internal control requirements of SOX sections 302 and 404.

What is SoD Conflict in SAP?

Segregation of duty conflicts and SoD security violations are associated with inappropriate access at the SAP transaction workflow level. For example, an SAP user may have access to create a new vendor, create a vendor payment, and authorize that vendor payment. These three access functions should be appropriately segregated between different people because it can lead to fraud. SoD conflicts in SAP arise when user roles and the authorisations associated with those roles are not clearly defined. This leads to user over-provisining with users gaining more authortizations than required as per company policies and compliance regulations.

Overcoming SoD Conflicts in SAP for Effective SOX Compliance

To avoid access risks like SoD security violations and achieve SOX compliance in SAP, organizations need to implement the following layers of controls:

Establish effective governance and oversight of the SAP security administration process, which includes defining roles, responsibilities, policies, processes, procedures, etc., and monitoring the performance of SAP security to identify and correct performance variances quickly. Governance is often one of the most overlooked processes, and often significant SAP security administration issues occur that could have been avoided.

Establish an effective SAP security administration process for adding new users, modifying access of existing users, terminating user access in a timely manner, and performing periodic reviews of all user access for recertification. Leveraging automation, analytics, and artificial intelligence can dramatically improve the operating efficiency of the SAP security administration process. Leveraging an attribute-based access control (ABAC) security model provides more effective and adaptive security than the role-based access control model native to SAP. Additionally, ABAC can automate your SAP policy enforcement at the business process, transaction, and data level.

Internal auditors should perform an independent audit of SAP security to verify the design and effectiveness of all SAP access controls after the business unit and IT department perform their own self-assessments.

Appsian ProfileTailor GRC is a comprehensive compliance platform that enables greater control over user access risks, segregation of duties, compliance, and audit. The platform leverages embedded AI, machine learning, and predictive analytics to continuously identify potential risks and provide optimized suggestions to resolve conflicts. With Appsian, your organization can achieve SAP SOX compliance by:

Establishing effective layers of control in governance and oversight
Automating security administration procedures
Implementing AI and ML empowered access risk analysis & recommendations
Automating policy enforcement with ABAC
Effectively monitoring and reporting with real-time analytics
Addressing SAP security challenges with self-assessment and independent audit capabilities

Get in touch with our SAP Compliance Experts to achieve and maintain a clean SAP security environment.

Put the Appsian Security Platform to the Test

Schedule Your Demonstration and see how the Appsian Security Platform can be tailored to your organization’s unique objectives

Data Loss Prevention: 7 Best Practices for SAP Security

A constantly evolving threat landscape and compliance environment with inconsistent standards have made data loss prevention (DLP) a vital component of an organization’s SAP data security strategy. The global cost of data breaches hit a record-high in 2021 ($4.2 million per incident), highlighting the importance of a robust DLP strategy to protect organizations from financial, legal, and reputational damages.

What Is Data Loss Prevention?

Data Loss Prevention is the practice of identifying and preventing data breaches, exfiltration, or unwanted loss or destruction of sensitive data. Businesses use DLP solutions for SAP and PeopleSoft applications mainly to:

Secure Personally Identifiable Information (PII)
Comply with data security and privacy regulations
Protect intellectual property critical to the organization
Prevent unauthorized transfer of data outside the organization

Seven Data Loss Prevention Best Practices

For any DLP strategy, you need to understand which organizational data to secure, where that data resides, who has access to that data (and when), and how the data should be used. Unfortunately, data loss is difficult to spot because data routinely moves in and out of an enterprise and closely resembles normal traffic. Let’s take a look at a list of data loss prevention best practices that have helped our customers achieve their data security goals and meet compliance standards.

Configure Dynamic Data Loss Prevention Policies
Preventing unauthorized exposure of sensitive information and protecting against insider data leakage begins by configuring contextual, attribute-based DLP policies that restrict transactions based on user and data attributes. Unfortunately, traditional role-based access controls (RBAC) can’t completely safeguard data in dynamic environments as static roles fail to leverage contextual attributes such as time of the day, geolocations, IP address, transaction type, etc.

Establish Clearly Defined Rulesets for Segregation of Duties
Establishing a clearly defined ruleset for segregation of duties that divides business processes between multiple users helps limit the risk of fraud and error while ensuring that a user’s access privileges do not conflict or violate business policies.

Deploy Policy-Based Data Masking and Redaction
Companies can enable dynamic data masking to reduce unnecessary exposure of sensitive information while allowing employees to do their jobs. For example, masking specific fields on a page an employee is accessing. Or using click-to-view masking to unmask data or require an MFA challenge before data is revealed to log access to a particular field. And don’t forget to protect non-production environments where dynamic data masking ensures development or testing teams can only access the data they need and nothing more.

Continuously Monitor Data Access And Usage
Monitoring user behavior around data access and usage in real-time at a granular level provides visibility into how users interact with sensitive data, triggering security event alerts for high-risk access and abnormal activity at the field level. (Native application logging capabilities cannot tell the difference between malicious user activity and normal usage.)

Increase The Levels Of Access Control & Monitoring for High-Privilege Users
Because privileged user accounts are magnets for hackers, companies should isolate activity and access data by these accounts to ensure integrity and alignment with current business policies. For example, an employee from the HR department needs access to payroll information to do their job, but do they need that access outside of office hours or from an unknown IP address?

Closely Monitor Report and Query Downloads
Monitor instances of query running and download attempts, ensuring that sensitive queries are not being downloaded onto unauthorized devices, from suspicious locations, or outside business hours.

Leverage DLP Solutions to Automate As Much As Possible
For all the features and value ERP systems provide, they lack the functionality to provide a dynamic, automated data loss prevention solution. Automating DLP processes across the organization allows you to enforce dynamic policies to identify and protect data before it exits the organization. In addition, automating compliance audits allows you to constantly monitor data access and usage and alert security teams to abnormal activities.

How Appsian Security Helps Enable Your SAP Data Loss Prevention Strategy

Whether careless or malicious, employee, partner, or contractor, it can be difficult to tell the difference between a user’s regular activity and activity intent on causing harm or theft. The Appsian Security Platform (ASP) helps SAP customers deploy these data loss prevention best practices, and many more, to prevent unauthorized exposure and exfiltration of sensitive data, PII, and intellectual property.

By configuring dynamic access controls, you can uniformly enforce policies that restrict transactions based on user and data attributes. In addition, you can deploy policy-based data masking that help you comply with data security and privacy regulations by reducing the exposure of high-risk data.

Contact us today for a demonstration and see for yourself how Appsian Security can help with your data loss prevention strategy.

Put the Appsian Security Platform to the Test

Schedule Your Demonstration and see how the Appsian Security Platform can be tailored to your organization’s unique objectives

How Appsian Approaches Cross-Application SoD for SAP, Oracle & More

The concept of segregation of duties for SAP and other ERP applications is simple to understand: ensure that a user’s access privileges do not conflict or violate business policies and divide business processes between multiple users to limit the risk of fraud and error. However, the streamlining, managing, and enforcing of segregation of duties is far more complex. These days, organizations are turning to technology to help them automate tedious manual processes and reinforce internal controls—technology like Appsian.

Enforce Cross-Application SoD Rulesets from A Single Control Point

Appsian is a single control point that enforces cross-application SoD rules – allowing auditors and security managers to implement one SoD ruleset and enforce it on multiple applications simultaneously. They can also create rulesets for specific systems or change, activate, or deactivate SoD rules that can influence all systems together or only particular systems. Essentially, ProfileTailor GRC unifies all applications into one “language” so auditors and security managers do not have to try to understand each application’s jargon while giving them complete control over their SoD compliance, helping them comply with SOX regulations.

Maintain, Upload, and Download Rulesets in Multiple Schemas to Fit Different Scenarios

Ruleset maintenance is a focal point of any SoD implementation. ProfileTailor GRC includes various methods to create and maintain SoD rulesets easily and effectively to maximize the level of control over segregation of duties. For example, auditors can prepare a ruleset, upload it using a built-in mechanism, and then maintain the rules inside the application.

Alternatively, they can create rules in the application and then maintain, download, and upload them to Excel sheets. Further, auditors can lock specific rules for editing while allowing others to be opened. Business units can edit their own ruleset while being able only to view the organization’s global ruleset. Additionally, ProfileTailor GRC comes with a predefined ruleset that is ready for customization so organizations can be up and running almost immediately.

Resolve SoD Conflicts in Seconds

The best way to handle SoD violations is to solve them clearly and quickly. ProfileTailor GRC analyzes user behavior and usage data paired together with vast amounts of hands-on experience in the field of risk assessment to resolve SoD conflicts in just a few seconds. ProfileTailor GRC can audit violation events in real-time because it assesses SoD risks and violations based on users’ actual usage, not only on their given authorizations, and recommends the best solution for solving the violation and up to 5 additional possible solutions

Make ProfileTailor GRC a Critical Part of Your Compliance Strategies

ProfileTailor GRC can be used as a stand-alone solution for streamlining, managing, and enforcing SoD or as part of a suite of compliance products. This means that enforcing an SoD ruleset will influence other workflow processes. For example, provisioning/de-provisioning user accounts, requesting new authorizations and preventing SoD conflicts, opening new user accounts automatically without SoD violations, and business rules for granting or revoking authorization roles.

ProfileTailor GRC is compatible with all leading ERP applications, including SAP, Oracle E-Business Suite, Oracle PeopleSoft, Microsoft Dynamics, and more. It can be installed as an on-premise solution for continuous protection or in the cloud as a continuous inspection solution.

For more information on how ProfileTailor GRC approaches segregation of duties for SAP and Oracle ERPs or to receive a customized demonstration, please go HERE.

Put the Appsian Security Platform to the Test

Schedule Your Demonstration and see how the Appsian Security Platform can be tailored to your organization’s unique objectives

SAP Access Controls: How RBAC & ABAC Work Together

To ensure employees remain productive in a dynamic and hybrid work environment, organizations use SAP access controls to allow their workers remote and secure access to ERP data, transactions, and self-service modules. Unfortunately, the existing SAP role-based access controls (RBAC) have reached their limitations in a dynamic workplace because static roles do not leverage contextual attributes.

Understanding SAP Access Control Using RBAC

Functionally, role-based access control (RBAC) is a policy-neutral approach to granting (or restricting) SAP access based on the roles of individual users in the company. Since RBAC was intended for on-premises data access from behind a corporate firewall, it creates a very strict, static set of permissions. You either have access or you don’t.

RBAC has always provided a strong foundation for setting SAP access controls. However, the way people are interacting with data resources is constantly evolving and RBAC is struggling to keep up.

Enhancing RBAC by Using Attribute-Based Controls in SAP

Organizations are looking for more flexible and secure ways to grant users access to only the information and resources they need to perform a particular task. This dynamic approach to SAP access controls enhances RBAC by considering different “attributes,” enabling security policies to be dynamic and “data-centric” and leveraging a user’s context of access to determine access to data. By incorporating these attribute-based access controls (ABAC), organizations can control user access more precisely, and better balance policy and security requirements.

The more attributes you can incorporate, the more precisely you can define what, how, and when a user or group of users can access data. Unlike RBAC, ABAC allows you to use contextual information such as project ID, company code, IP address, location, device type, and more to authorize access.

The RBAC + ABAC Hybrid SAP Access Control Model

Appsian Security extends and enhances existing SAP access controls by combining RBAC security capabilities with attribute-based policies. Starting with RBAC, organizations set the foundation of their access policies. ABAC begins the moment users start to access data and transactions and considers the context of access (who, what, where, when, and how) before allowing a user to access transactions or data.

The key benefits of the RBAC + ABAC hybrid model from Appsian Security include:

Reducing Attack Surface
Organizations can reduce their amount of accepted risk by applying granular business policies and contextual access controls to strengthen data-level and transaction-level security.
Dynamic Data Masking
You can dynamically enforce data masking or outright restriction policies to any field in SAP when using real-time contextual policies that balance security and usability.
Reinforcing SoD Policy Violations
Adding ABAC to RBAC allows you to apply preventive controls in segregation of duties (SoD) exception scenarios. By doing so, you can prevent SoD violations while still allowing the flexibility of conflicting roles to be assigned (when necessary) and reinforces role-based policy to mitigate over-provisioning.

Without a solution like Appsian Security, the closest organizations can come to granting policy-based access to SAP is through customization or adding role derivations to a user for each attribute. Both options are costly and add complexity and overhead to role management in the long run.

Contact us today and schedule a demo to see how Appsian can help you enforce SAP access controls beyond the standard RBAC model.

Put the Appsian Security Platform to the Test

Schedule Your Demonstration and see how the Appsian Security Platform can be tailored to your organization’s unique objectives

How to Protect Your ERP With an Adaptive Security Model

Agility is the name of the game in today’s ERP data security landscape. Organizations are being challenged to detect threats as they happen, quickly address vulnerabilities, and continuously improve their security posture while protecting crucial ERP data as well as their overall business. One strategy that is helping organizations become more proactive is aligning to an adaptive security model.

Focused on operationalizing agile, context-aware, and adaptive technologies, an adaptive security model enables organizations to strengthen security and leverage automation for continuous improvement.

What is Adaptive Security?

Adaptive security is an approach to managing security that analyzes behaviors and events to protect against and adapt to threats before they happen. With an adaptive security architecture, an organization can continuously assess risk and control effectiveness monitoring and automatically provide proportional enforcement that can be dialed up or down to fit its need.

Figure 1: Adaptive Security Architecture

You’ll note that there are four stages of an adaptive security architecture: Prevent, Detect, Respond and Predict. These stages help organizations transform the old static, roles-based approach to ERP data security to a continuous monitoring and risk-adaptive approach. Zero trust is a core concept to adaptive security, which promotes continuous monitoring and analysis as a starting point, enables rapid detection of behavioral anomalies, and permits rapid responses to quickly stop and resolve security incidents.

Seven Imperatives for an Adaptive Security Architecture

According to Gartner, supporting digital business transformation in an environment of advanced threats requires a new approach for all facets of security. Security and risk management leaders can use these seven imperatives of an adaptive security model to embrace the opportunities and manage digital business risks. Each imperative is Gartner’s recommended capability required of your ERP security, risk & compliance solution to enable the security model.

Replace One-Time Security Gates with Context-Aware, Adaptive, and Programmable Security Platforms
Organizations need to replace the initial one-time, yes/no risk-based decision at the main gate to their systems (typically managed by a static authentication and authorization process) with a continuous, real-time, adaptive risk and trust analysis of user anomalies with context-aware information across the platform. Context-aware security (also known as attribute-based access controls or ABAC) uses situational information, such as identity, geolocation, time of day, or type of endpoint device.
Continuously Discover, Monitor, Assess and Prioritize Risk — Proactively and Reactively
Risks events are fluid and require constant identification, analysis, prioritization, monitoring, and response after the initial login assessment. This should include a combination of proactive and reactive capabilities. For example, if a user attempts to download a large amount of sensitive data, you need the ability to detect and prevent this action if it’s considered inappropriate. Again, the use of ABAC can provide organizations with preventative controls at the business process, transaction, and master data level.
Perform Risk and Trust Assessments Early in Digital Business Initiatives
This imperative focuses on early risk assessment, meaning performing risk and trust assessments early in the process execution.
Instrument Infrastructure for Comprehensive, Full Stack Risk Visibility, Including Sensitive Data Handling
This is a continuous risk assessment recommendation across the full tech stack and data handling to enable adaptive security decisions.
Use Analytics, AI, Automation and Orchestration to Speed the Time to Detect and Respond, and to Scale Limited Resources
This imperative recommends using artificial intelligence, machine learning, analytics, and automation to increase the efficiency and effectiveness of risk detection, analysis, and response capabilities.
Architect Security as an Integrated, Adaptive Programmable System, Not in Silos
Avoid silos! Organizations shouldn’t perform risk assessments in individual isolated silos. Instead, aggregate continuous risk assessments provide a more accurate view of the organizations’ risk exposure.
Put Continuous Data-Driven Risk Decision Making and Risk Ownership into Business Units and Product Owners
This imperative encourages better transparency and decision-making through better data-driven risk visibility to the business unit leaders for their own decision-making.

How Appsian Security Helps Organizations Achieve Adaptive Security

The problem we help companies overcome: In its current form, the static data protection approach utilized by most organizations lacks the effectiveness required to manage today’s complex challenges. Without an accurate picture of risk exposure in their organization, security administrators protect data the only way they can – with restrictive measures under the principle of least privilege and zero trust.

Here’s how Appsian Security’s capabilities align to the Gartner adaptive security model. The Gartner adaptive security model is illustrated with the Appsian Security solution capabilities aligned with their Predictive & Discovery Requirements, Preventative & Adaptive Access, Detective & Monitor Usage, and Respond & Manage User capabilities.

Five Ways Appsian Security Helps Improve ERP Data Security

Organizations are being challenged to protect access to sensitive and confidential data while improving their ability to analyze security data and detect attacks in progress. Here are five ways that Appsian Security can help your organization meet these challenges:

The capabilities of the Appsian Security solution align with Gartner’s Seven Adaptive Security Imperatives.
Appsian offers context-based access controls that can prevent, detect, and respond to user anomalies at the business process, transaction, and data level.
Appsian enables continuous monitoring and real-time reporting of user anomalies.
Appsian offers artificial intelligence, machine learning, and automation to increase the efficiency and effectiveness of your risk detection, analysis, and response capabilities.
Appsian can automate the enforcement of your policy requirements at the business process, transaction, and data level.

Contact Appsian today to learn how our zero trust solutions can anchor your adaptive security architecture and improve your ERP data security.

Put the Appsian Security Platform to the Test

Schedule Your Demonstration and see how the Appsian Security Platform can be tailored to your organization’s unique objectives

SAP Data Security Best Practices for ITAR Compliance

You know how vital SAP data security can be in the age of data privacy and compliance regulations such as GDPR, CCPA, SOX, and others. If you’re a company involved with any part of the defense supply chain—from direct contracts on defense projects to independent upstream suppliers of parts, components, services, and software that are ultimately used in defense products—you’re likely subject to ITAR compliance.

The International Traffic in Arms Regulations, or ITAR, is a set of government rules that control the export and import of defense-related articles, services, and technology on the U.S. Munitions List (USML) and ensure that sensitive materials (i.e., data) don’t fall into the hands of foreign parties and U.S. enemies. Put another way, if your company’s product, software, technical data, or services are identified on the USML, you’re going to be subject to ITAR requirements.

What Is ITAR Compliance?

Answering this question is a bit tricky because there is no formal certification process to become “ITAR Compliant” or “ITAR Certified.” Instead, companies are expected to understand the regulations and take the appropriate steps to comply with these requirements. We’re not in the business of offering legal advice, but the U.S. Department of State is an excellent place to start to learn more.

Ensuring that your SAP data security practices comply with ITAR mandates is essential from a security and consequence standpoint. You never want to compromise your data, but you also don’t want to face the risks of high fines and possible jail time for failing to comply with ITAR. The penalties for ITAR infractions are severe, including civil penalties up to $500,000 per violation and criminal fines of up to $1 million and/or ten years imprisonment per violation. (A California electronics company was recently fined $6.6 Million for multiple ITAR export violations)

What’s on the U.S. Munitions List?

There are 21 categories of Defense Articles in the USML as well as related technical data. For your reference, here are the categories (emphasis mine for #21):

Firearms, Close Assault Weapons, and Combat Shotguns
Guns and Armament
Ammunition/Ordnance
Launch Vehicles, Guided Missiles, Ballistic Missiles, Rockets, Torpedoes, Bombs, and Mines
Explosives and Energetic Materials, Propellants, Incendiary Agents and Their Constituents
Surface Vessels of War and Special Naval Equipment
Ground Vehicles
Aircraft and Related Articles
Military Training Equipment and Training
Personal Protective Equipment
Military Electronics
Fire Control, Laser, Imaging, and Guidance Equipment
Materials and Miscellaneous Articles
Toxicological Agents, Including Chemical Agents, Biological Agents, and Associated Equipment
Spacecraft and Related Articles
Nuclear Weapons Related Articles
Classified Articles, Technical Data, and Defense Services Not Otherwise Enumerated
Directed Energy Weapons
Gas Turbine Engines and Associated Equipment
Submersible Vessels and Related Articles
Articles, Technical Data, and Defense Services Not Otherwise Enumerated

Regarding category 21, technical data refers to any data stored in your SAP ERP application containing information related to items or services designated on the USML. ITAR compliance centers on ensuring this data is not accessible by non-U.S. citizens, including employees, or inadvertently distributed to foreign persons or nations.

Add ITAR Compliance Items to Your Data Classification List

To comply with GDPR, SOX, and other compliance regulations, you probably have already classified which data in your organization is sensitive and subject to your data security, privacy, and governance policies. Further, with technical data, it’s also a good idea to tag each page with an ITAR notification. This prevents employees with legitimate access from accidentally sharing controlled information with unauthorized users.

Apply Policy-Based Access Controls

Now that you’ve identified and categorized your data, it’s time to establish who has access to it, when they can access it, from where, on what device, and how often. This is critical but challenging as any company with employees who are non-U.S. citizens or work with non-US subcontractors must prohibit them from accessing ITAR technical data. Adding to the challenge is SAP’s static role-based access controls (RBAC) for governing access because they do not leverage contextual attributes.

Appsian Security can help you create a more policy-based and robust data security program by enabling attribute-based access controls (often called policy-based access controls) that incorporate additional contexts, such as citizenship (nationality), certification, geolocation, network, time of day, and transaction type. Combining contextual attributes with your standard roles-based attributes, you can establish policy-based rules that grant access to ERP applications, technical data, and transactions only if the person meets certain contextual criteria while still allowing them full access to everything they need to do their job.

Leverage Policy-Based Controls to Configure Preventative Controls with Appsian Security

Once policy-based access controls are in place, Appsian Security can enable you to easily configure preventative controls at the SAP process, transaction, and field level to prevent unauthorized activity, enhance your data privacy, and increase the efficiency of your ITAR compliance program.

Avoid Unnecessary Data Exposure with Dynamic Data Masking:

An essential requirement of ITAR is ensuring that users accessing SAP applications, either in an authorized or unauthorized manner, do not have needless access to sensitive technical data through various pages, reports, or queries. Appsian can reduce the exposure of technical data with dynamic data masking while still allowing employees to do their assigned work.

Add Stepped-Up Multi-Factor Authentication at the Transaction Level:

Adding MFA at the transaction level ensures that users are not only authorized to access and view the data but perform the actual transaction based on their current context of access and not just their role. This should be applied to highly sensitive transactions like editing a direct deposit account number, accessing compensation data, or anything involving the USML.

Strengthen Data Loss Prevention:

Using context-aware data loss prevention policies, Appsian can prevent users from executing transactions that download technical data in high-risk scenarios, such as: citizenship, after business hours, from untrusted locations, networks, or devices. This prevents employees from downloading and accidentally sharing data they shouldn’t and prevents malicious insider threats from causing damage beyond non-compliance.

Enhance Visibility into ERP Data Access and Usage:

A critical component of ITAR compliance often lacking in SAP is real-time visibility into user behavior around data access and usage. Native SAP logging capabilities were not designed with data security in mind. Appsian360 allows organizations to continuously monitor data access and usage and proactively alerts security teams to anomalous activity, particularly useful for ensuring non-U.S. citizens are not accessing data they shouldn’t.

Learn How Appsian Helps You Enforce Controls in a Single Policy for Better ITAR Compliance

What makes ITAR unique from other data privacy regulations is the importance it places on citizenship, certifications, and network/location attributes. Appsian can help your organization capture these and other attributes and provide the tools for enforcing them in a single policy.

Contact the SAP data security experts at Appsian Security to find out how we can help you leverage policy-based controls to eliminate the complexities required with RBAC alone and more efficiently achieve ITAR compliance.

Put the Appsian Security Platform to the Test

Schedule Your Demonstration and see how the Appsian Security Platform can be tailored to your organization’s unique objectives

Managing Third-Party Risks with Continuous Controls Monitoring

Third-Party Risk Management (TRPM) is the process of analyzing and controlling risks presented to your company, your operations, your data, and your finances by Third Party Service Providers (TPSP). Most companies rely on a network of third-party vendors, suppliers, and service providers to support their business. As an integral part of the overall business operations, third-party entities end up storing, collecting, uploading, and accessing data as needed.

However, adding TPSP users to your ERP applications also increases the risk of data exposure and the possibility of breaches. Though most businesses have access controls in place and undertake periodic audits to assess and mitigate this risk, TPSPs are still one of the major causes of data breaches, and typical static access controls are not enough. According to Gartner’s Continuous Adaptive Risk & Trust Assessment (CARTA) model, organizations need to move away from the initial one-time, yes/no risk-based decision at the main gate to their systems (managed by a static authentication and authorization process) to a continuous, real-time, adaptive risk and trust analysis of user anomalies with context-aware information across the platform. (Context-aware security is the use of situational information, such as identity, geolocation, time of day, or type of endpoint device, found in Attribute-Based Access Control (ABAC) models.)

Additionally, with roles and authorizations constantly changing across your ERP applications, keeping track of changes manually at the transaction, process, and application level is virtually impossible, and with the hundreds or even thousands of TPSPs you may have, it’s difficult to monitor user activities with traditional role-based access management solutions to quickly detect and stop threats. This is where ABAC and Continuous Controls Monitoring (CCM) are making huge strides to change the overall approach to continuously identifying, detecting, protecting, and responding.

The Third-Party Risk Landscape

Before diving into the need for CCM, it is crucial to understand the gravity of the security situation when it comes to third-party access. Digital relationships with third-party providers have become a necessity today. Collaboration with third-party vendors increases opportunities for business growth, capturing market share, and cost reduction, but the flipside is an increase in security breaches.

A 2018 Opus & Ponemon Institute survey of more than 1,000 CISO’s revealed that 61% of U.S. companies had experienced a data breach caused by one of their third-party providers – up 12% since 2016. Furthermore, 22 percent of respondents admitted they didn’t know if they had a third-party data breach during the past 12 months, and more than three-quarters of companies think third-party security breaches are increasing.

On average, organizations spend more than $10M responding to third-party security breaches each year. However, information security is not the only area impacted. Third-party relationships can introduce strategic, financial, operational, contractual, credit, compliance, business continuity, and reputational risks.

Research conducted by Gartner in 2019 found that third-party risk was identified as a top threat by compliance leaders, and 71% of organizations report their third-party network contains more third parties than it did three years ago. Furthermore, the same percentage reports their third-party network will grow even bigger in the next three years.

What is Continuous Controls Monitoring?

Gartner defines continuous controls monitoring (CCM) as “a set of technologies to reduce business losses through continuous monitoring and reducing the cost of audits through continuous auditing of the controls in financial and other transactional applications.”

In simpler terms, CCM is shifting from the traditional audit and assessment approach of randomly sampling a portion of the data over regular intervals to monitoring 100% of the transactions and controls continuously 24/7, 365 days a year.

A core objective of CCM is to ensure that those controls operate as designed and that transactions are processed appropriately. If done right, CCM not only increases the reliability of the controls but also improves the management oversight, policy enforcement, and operational efficiency for critical financial processes, often producing hard-dollar savings.

How Continuous Controls Monitoring Reduces Third-Party Risk

The risk posed by providing access to third-party vendors makes it imperative for businesses to ensure that third-party access to applications and data is controlled and audited. Unfortunately, despite having access control mechanisms in place, third-party data breaches have been on the rise. One of the key reasons for this is the lack of effective monitoring of user anomalies. Roles and authorizations are never static. As new vendors are added, granted varying degrees of authorizations, and terminated from the system, there is a need to continuously monitor access controls and user behavior associated with critical data.

Current auditing practices are primarily manual and time-consuming, with auditors only looking at a sample of the data logs. As a result, a significant part of the process and transaction-level data is still going entirely under the radar. By implementing tools and technologies that enable Continuous Controls Monitoring (CCM) at the access, transaction, and master data level, businesses can automate the risk and control assessment and monitoring process needed to observe control effectiveness for audit, risk, & compliance management programs.

Enabling Continuous Controls Monitoring with Appsian Security

The list of third-party vendors your business is working with is only going to grow over time. In addition to managing the security risk, companies must also comply with regulations like GDPR, SOX, CCPA, etc., which adds additional burden and cost. CCM technologies offered by Appsian help provide real-time, context-based monitoring within your ERP applications at the access, transaction, and data level to enable you to be audit-ready.

Appsian 360 helps you detect and respond to fraud, theft, and errors by employees and third parties by capturing granular data at multiple levels. Through a visually rich dashboard, you will be able to identify data access and usage trends at the business process, transaction, and data level that reflect suspicious activity by any third-party vendors. In addition, the continuous monitoring and detailed log data eliminate much of the manual work required for performing audits and ensures that you remain compliant with new data privacy regulations.

Appsian’s Identity and Access Management (IAM) simplifies and elevates user access management in dynamic multi-vendor ERP environments. It enforces the zero-trust principle, enables content-based, real-time, dynamic risk and trust analysis of user anomalies, and configures preventative controls at the business process, transaction, and field levels. Finally, it allows policy enforcement through the use of the ABAC security model.

ProfileTailor GRC enables you to automate user provisioning to ensure effective role assignments to third-party vendors. The solution allows auditors and security managers to perform periodic user access reviews and recertification to maintain compliance and security within your ERP applications. With ProfileTailor GRC, a single SoD ruleset can be enforced across multiple ERP applications, simultaneously ensuring third-party vendors across your organization have controlled authorizations. In addition, the real-time monitoring capabilities of ProfileTailor GRC is an AI and machine learning empowered solution that conducts an impact analysis to alert you to violations as they happen while providing mitigating controls to prevent future violations.

Connect with our ERP security experts to learn more about how Appsian can enable Continuous Controls Monitoring to mitigate your third-party risk. Schedule a Demo.

Put the Appsian Security Platform to the Test

Schedule Your Demonstration and see how the Appsian Security Platform can be tailored to your organization’s unique objectives

Why You Should Avoid Customizing PeopleSoft to Enable Single Sign-On (SAML/ADFS)

Don’t Risk the Security of your Data with Customized SSO SAML/ADFS Integration for PeopleSoft

I was on a recent discovery call, and the Senior Software Engineer shared how they’re “ripping out” a custom-built PeopleSoft single sign-on solution (SSO). After acquiring an enterprise SSO, they attempted to build a custom integration with PeopleSoft that presented far more challenges than benefits – especially when users attempted to access with a deep link. Now they’re looking to remove the solution along with the additional infrastructure that was required.

And here’s the sad part: they’re not the first organization I’ve encountered that are experiencing the same challenge. Across all verticals including healthcare, higher education, government, retail and more – PeopleSoft customers are rethinking their decision to enable their enterprise SSO solutions with custom coding, external gateway agents, and reverse proxies. Alternatively, implementing solutions that feature native SAML/ADFS authentication handlers.

Your Custom Single Sign-On Integration Was Not Designed with ERP Data Security in Mind

These projects often start with the IT department recognizing that it can solve a business requirement by building the solution themselves or by using a generic gateway with copy-and-paste code off an internet forum. The main motivation? They possibly save the company some money, bypass the need for approvals or budget, and check a project off their list. Easy-peasy, right? As highlighted in the example above, it’s not always that straightforward.

Often, these projects lack a thoughtful mindset and instead leverage code that is many years old, unsupported, and public to developers and hackers alike. Here lies one of the biggest problems with customizing PeopleSoft for SSO authentication. Getting the integration to work “well enough” is often the goal, and since developers are not information security professionals – they may not have considered the ramifications of using code that hackers can reverse engineer, potentially exploiting loopholes to gain unauthorized access. As a former PSAdmin who personally retrofitted a custom PeopleSoft SSO solution in my past life, I can tell you that security implications are not at the forefront. Between IT wanting to be a good partner to the business and drowning in long-haul projects, “good enough” was often the goal.

The “Typical” Custom PeopleSoft Single Sign-On Approach

There are a few ways to approach building a custom SSO solution. You could try linking SAML open-source code libraries, using reverse proxies, or having an external agent handle it. These solutions seem relatively simple at the outset, but the introduced vulnerabilities are often not obvious or ignored. The end result is that the SSO “works” but is plagued by technical, functional, and security issues once in production.

Linking SAML Open Source Code Libraries

A custom coding project typically begins with a review of PeopleBooks and a Google search to find a relatively quick way to write the code. PeopleCode allows you to link external open-source java libraries inside PeopleSoft. This is code that you’re literally pulling from an old blog and has not been reviewed since the author first published it. Imagine using code from 2007 to secure your custom PeopleSoft single sign-on project. It would never pass a security review!

Secondly, developing a solution yourself is tricky. It isn’t easy to write software that deals with passwords, identity, and authentication. Reputable IdPs spend tens of thousands of man-hours designing, coding, and testing, then supporting their solutions. The lone developer who built your custom solution is now responsible for supporting, maintaining, and upgrading the code. That’s excellent job security for him but a security liability for you.

Reverse Proxies, Gateways, and External Authentication Agents

This one is probably a favorite with system administrators who want to support a multitude of non-SAML apps with a one-size-fits-all solution. I’ve also implemented SSO like this in the past, so I can speak from experience about how this works and its risks.

The short version of how this works is that the authentication is offloaded to a reverse-proxy, an agent, or a gateway, that sits outside PeopleSoft. Once the authentication process is successfully completed, only then is a connection made to PeopleSoft, and the authenticated user-ID passed to the HTTP header. Then that request has to be trusted by a custom Sign-on PeopleCode.

Aside from the risky firewall configuration, another issue here is that it needs to be scaled carefully for bandwidth because all of the requests will now go through a new server and several new applications to complete the process. Now you have additional hardware, software, and customizations to maintain and patch in addition to your regular PeopleSoft duties.

Why a Native SAML/ADFS Handler is Best Practice

SSO is critical to help you increase your security posture within your organization while keeping your customers happy, so I don’t want to sound negative, and I’m not trying to put you off on installing an SSO solution in your environment. Instead, I want to make sure you do it correctly and aligned to security best practices.

My advice is to use a solution that natively supports a SAML/ADFS authentication handler and seamlessly and securely passes the token to PeopleSoft built-in authentication without customizations. The term “native” is extremely important here! The lack of native support is a critical issue that plagues custom solutions, creating more hoops to jump through to complete the project.

Fortunately, Appsian delivers the SAML/ADFS integration layer required to connect PeopleSoft, an IdP (Okta, Azure AD, Ping Identity, etc.), and your enterprise Single Sign-On. This solution is natively installed right into the PeopleSoft Internet Architecture (PIA) and does not require the use of proxy servers, agents, or gateways. Furthermore, there are zero customizations, simple configuration with extensive support for SAML/ADFS attributes, user-mapping, and the support and maintenance is offloaded from your team.

There is Beauty in Customization but Comfort in ERP Data Security

Part of PeopleSoft’s beauty and power is that you can customize the system to improve your business processes. However, one thing you shouldn’t take into your own hands is authentication, and indirectly, security. Your IT team, system admins, and developers should spend their time supporting and customizing your system to provide outstanding service to the business units and keeping the system running smoothly. Why add more hardware, software, applications, and customization than necessary?

Request a demo today to learn how Appsian solves the SAML/ADFS integration challenge by providing the only configurable SSO for PeopleSoft.

Put the Appsian Security Platform to the Test

Schedule Your Demonstration and see how the Appsian Security Platform can be tailored to your organization’s unique objectives

Request a Demo

Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.

Necessary

Always Enabled

Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.

Cookie	Duration	Description
cookielawinfo-checkbox-analytics	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional	11 months	The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance	11 months	This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy	11 months	The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.

Functional

Performance

Analytics

Others

Platforms

Features

Register for an Upcoming Webinar

SAP

PeopleSoft

Appsian360

Review

Webinars

Persona

Register for an Upcoming Webinar

Customers

Video Testimonials

Featured Case Studies

Why Appsian

Management Team

Careers

Press Releases

Partners

Contact Us

Customers

Partners

Home / Blog / Solving Complex Security Challenges with Dynamic SAP Data Masking

Solving Complex Security Challenges with Dynamic SAP Data Masking

Dynamic Data Masking in SAP Starts with Attribute-Based Access Controls (ABAC)

Data Masking Approach #1: Wide-Reaching Policies Based on User Attributes

Data Masking Approach #2: Risk-Based Policies Based on Access Attributes

Protecting Data with SAP Dynamic Data Masking Solution

Related Articles.

Put the Appsian Security Platform to the Test

Home / Blog / How to Reduce SoD Conflicts in SAP for Effective SOX Compliance

How to Reduce SoD Conflicts in SAP for Effective SOX Compliance

How SOX Affects Internal Reporting and Controls

The Role of Access Controls for SOX 404 Compliance

What is SoD Conflict in SAP?

Overcoming SoD Conflicts in SAP for Effective SOX Compliance

Related Articles.

Put the Appsian Security Platform to the Test

Home / Blog / Data Loss Prevention: 7 Best Practices for SAP Security

Data Loss Prevention: 7 Best Practices for SAP Security

What Is Data Loss Prevention?

Seven Data Loss Prevention Best Practices

How Appsian Security Helps Enable Your SAP Data Loss Prevention Strategy

Related Articles.

Put the Appsian Security Platform to the Test

Home / Blog / How Appsian Approaches Cross-Application SoD for SAP, Oracle & More

How Appsian Approaches Cross-Application SoD for SAP, Oracle & More

Enforce Cross-Application SoD Rulesets from A Single Control Point

Maintain, Upload, and Download Rulesets in Multiple Schemas to Fit Different Scenarios

Resolve SoD Conflicts in Seconds

Make ProfileTailor GRC a Critical Part of Your Compliance Strategies

Related Articles.

Put the Appsian Security Platform to the Test

Home / Blog / SAP Access Controls: How RBAC & ABAC Work Together

SAP Access Controls: How RBAC & ABAC Work Together

Understanding SAP Access Control Using RBAC

Enhancing RBAC by Using Attribute-Based Controls in SAP

The RBAC + ABAC Hybrid SAP Access Control Model

Related Articles.

Put the Appsian Security Platform to the Test

Home / Blog / How to Protect Your ERP With an Adaptive Security Model

How to Protect Your ERP With an Adaptive Security Model

What is Adaptive Security?

Seven Imperatives for an Adaptive Security Architecture

How Appsian Security Helps Organizations Achieve Adaptive Security

Five Ways Appsian Security Helps Improve ERP Data Security

Related Articles.

Put the Appsian Security Platform to the Test

Home / Blog / SAP Data Security Best Practices for ITAR Compliance

SAP Data Security Best Practices for ITAR Compliance

What Is ITAR Compliance?

What’s on the U.S. Munitions List?

Add ITAR Compliance Items to Your Data Classification List

Apply Policy-Based Access Controls

Leverage Policy-Based Controls to Configure Preventative Controls with Appsian Security

Learn How Appsian Helps You Enforce Controls in a Single Policy for Better ITAR Compliance

Related Articles.

Put the Appsian Security Platform to the Test

Home / Blog / Managing Third-Party Risks with Continuous Controls Monitoring

Managing Third-Party Risks with Continuous Controls Monitoring

The Third-Party Risk Landscape

Register
for an Upcoming
Webinar

Register
for an Upcoming
Webinar