×
[searchandfilter taxonomies="search"]
Home / Blog / Data Security: What Steps Can You Take?

Data Security: What Steps Can You Take?

By Scott Lavery • June 20, 2019

We’ve talked extensively about Segregation of Access (SoAx) and how data security threats have evolved to include a range of application authentication attacks. These include sophisticated phishing campaigns, automated brute force password attacks and the targeting of legacy applications that were not designed or implemented with these modern threats in mind.  In addition, the increasing demand from users to extend application access, from both inside and outside the network, is opening up a variety of potential entry points for bad actors to exploit.

And it is frequently these legacy applications, such as ERP systems, that maintain an organization’s most sensitive data including user personal and financial information, corporate proprietary data and financial accounting records.

How is an organization that maintains these legacy applications supposed to combat these modern security threats?

It all comes down to data protection. And not only keeping bad actors away, but also limiting access to sensitive data for legitimate users that don’t need to access it – until they do.

Let’s talk about some capabilities that can help bolster the data security of your applications. Let’s talk about how Appsian’s ERP Security Platform can provide many of those capabilities.

And let’s talk about it in the form of a hypothetical business justification in which Acme Industrial Dynamite (yes, I’m a big Road Runner fan) recognizes the vulnerabilities in their legacy ERP applications and is evaluating solutions.

Challenge

Acme Industrial has been struggling with bringing their legacy ERP platform into alignment with both the current access threat landscape and the evolving compliance environment, where regulations like GDPR and the CCPA are expanding the need to support data privacy well beyond the historical breach notification responsibilities.

Acme has identified some key areas where supplementing built-in ERP security capabilities will be required to meet these evolving challenges. These key areas fall into the following capability sets and all should be evaluated:

Multi-Factor Authentication (MFA)

The traditional application security mechanism of requiring a user name and password to authenticate is dated and increasingly insecure. Why?

1. Phishing schemes have become very sophisticated. Most recent studies show that between 4%-10% of phishing targets will click on that fraudulent link and give up their credentials for the targeted application. Result: there is a better than decent chance that any given user login that relies on user name and password is coming from a bad actor. Data such as bank account numbers and PI for that user are now exposed. And if it is a high privileged user, data for multiple users is exposed and the integrity of business operations could be compromised.

2. Typical users are expected to maintain access to multiple applications in a corporate environment. Remembering user names and passwords for all of them can be onerous. So, post-it notes under the keyboard, or worse, simple-but-easy-to-remember passwords lead to insecure authentication controls.

3. With the increase in computing power capabilities and the sophistication of current hacking tools, brute force attacking user names and passwords has become an effective mechanism for bad actors to gain access to sensitive applications.

How does MFA mitigate these risks?

By requiring an additional layer of identity validation before allowing access to sensitive data and processes. With an effective MFA implementation at the application level, stolen credentials would limit what a bad actor could see or do.

Appsian’s MFA capabilities allow for a variety of use cases to match an organization’s definition of risky behavior. Whether it’s to protect sensitive data, such as bank account numbers or PII, at the field or navigation level, or to restrict access to privileged functionality, such as Query Manager, MFA can provide that additional level of identity validation.

Application Activity Logging

Legacy ERP logging typically focuses on system operations and can be very performance intensive. Because the application was designed in a time when internet access and exposure and data privacy were not a major concern, access management and logging capabilities were not built into the core functionality.

In the current threat and compliance environments, being able to track who has accessed sensitive data and processes is critical. And it is not just about breaches anymore. It’s also about being able to respond to audit requests that require you to show reports on who has accessed any given user’s sensitive data.

Appsian’s logging capabilities supplement PeopleSoft’s system logging by providing a wide range of additional transactional tokens that can be captured and provide a very granular and contextual capability to track and report on what users are doing in the system.

Data Masking

As described above, it is critical to implement a multi layered security approach to the accessing of sensitive data and processes. It is not just about keeping that data from bad actors, but also limiting access to legitimate users to only those individuals who need to see it, and only when they need to see it.

Data masking allows for the ability to redact sensitive data.

Appsian’s approach to data masking allows for that redaction to be very dynamic and customizable based on use case. It also expands static masking to include the ability provide selective hyper-link enabled masking to limit access to sensitive data or processes to only those individuals who make a conscious (and logged) decision to access it.

And like MFA, Appsian’s masking can be applied in a variety of use cases:

  • What can a user access or see if they, regardless of role, are coming in from outside the network versus inside?
  • Should a high privileged user be allowed to high privileged data or process access if they are coming in at midnight from an IP registered in China?
  • Should lower test and development environments, which depend on real data to be effective, be allowed access to the sensitive data fields in those environments?

The keys to maintaining an effective data protection strategy are:

  • Catalog and classify your sensitive data and process across all applications
  • Apply controls around that data and those processes to limit access to only those who need to see it.  And only when they need to see it.
  • Implement an effective logging strategy that provides granular access activity reporting and alerting.

Contact us to see how Appsian can help inventory and address your sensitive data exposure in ERP applications.

Related Articles.

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

Home / Blog / Sensitive Data Security: It’s All About the Logging

Sensitive Data Security: It’s All About the Logging

By Scott Lavery • April 19, 2019

Well, in today’s post it is all about the logging.  In a future post it will be all about the alerting. 

Sensitive data.  What is it?

While there are some obvious types of data that should be considered sensitive (bank account information, social security numbers, dates of birth, private health records), most companies are expanding that population of classified sensitive data to include financial information, intellectual property records and other designated data that would represent a risk if exposed.

Sensitive data is typically managed and stored in applications.  In our new connected world, users are connecting to those applications from a variety of devices that may or may not be inside the corporate network.  And they are typically connecting via a web browser.  Literally the most common application available in our internet driven world.

Bottomline, those applications are now open to a much larger population of users . They are also exposed to any potential bad actor with a web browser.

And adding to the challenge, many of those applications that house sensitive data were designed and deployed back in the pre-internet days, when access was limited to a few select individuals behind the walls of the corporate network.  Security controls back then didn’t account for opening those applications to the world.

But the end goal hasn’t changed. Data needs to be protected. Sensitive data really really needs to be protected. 

The key to protecting that population of sensitive data is applying controls that limit access to that data to only those individuals that need to see it, and only when they need to see it.

The question becomes, how do you monitor the effectiveness of those controls?  And how do you respond in a timely manner when those controls are subverted or bypassed?

This is where effective logging comes into play.  And by effective, I mean comprehensive and tailored to formats that enable easy searching and investigation.

Let’s focus on access activity logging.  What are some key components of an effective application access logging strategy?

  • Utilize an easily configurable logging framework that 1) contextually understands all components of the access transactions, and 2) offers a comprehensive set of capturable tokens representing all those components.
  • Utilize a framework that offers flexible output options that allows for specific and granular logging around definable access activities such as high privilege logins, failed login attempts and sensitive data exposure.
  • Utilize a framework that allows for log storage in customizable formats to support designated SIEM (Security Information Event Manager) platforms such as Splunk, ArcSite and/or QRadar.  In the absence of a SIEM, the framework should support storage in SYSLOG or CSV formats.

Introducing an effective logging framework is a key component in an application security strategy.  It is especially critical when dealing with legacy applications where the built-in logging capabilities are limited and not very configurable.

Reach out to [email protected] and let us show you how Appsian can help bolster your application logging capabilities.

Related Articles.

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

Home / Blog / ERP Data Security Assessments: Then and Now

ERP Data Security Assessments: Then and Now

By Scott Lavery • April 12, 2019

This is a long one and gets techie in areas, but bear with me.  There’s a moral to the story.

As regular readers of this blog know, I frequently talk about my experiences performing security assessments.   These assessments typically cover an organization’s network infrastructure and application portfolio, and are driven by both regulatory requirements (SOX, PCI, HIPAA, etc) and internal requirements arising from governance, risk and compliance policies.

The scope and approach to these assessments has changed over the years, especially for legacy ERP systems.

In the olden days, when cellular devices were “dumb” and flip phones were cool, organizational networks were fairly insular and protected by a battery of network firewalls.  Key business applications were installed and accessible from inside those walls.  And only from inside.

Access to many of these applications was only permitted via what used to be called “thick clients”.  These were dedicated client applications installed on a user’s desktop whose sole purpose was to facilitate point-to-point interactions with a given server-based application platform.

These thick clients, which allowed managed access to the ERP keys to the kingdom, were typically only installed on the select few users needed to use and administer the platform.  HR applications, for example, were only accessible to data entry clerks and select approvers of HR related transactions.  Financial platforms were even more limited as to who was permitted to install and use the thick client required for access.

In this environment, security assessments (aside from policy reviews, etc) focused on a few key tactical areas:

  • Penetration testing against the network walls that were protecting the applications. Penetration testing is the attempted hacking of a network or an application by trying to maliciously connect to any ports that are “open” (or listening) to enable connectivity to that network or application.  Kind of a technical intro to how digital platforms communicate. For those interested in learning more, there are a ton of resources that can be googled to learn more about penetration testing and network communication protocols.
  • Penetration testing against the application port(s) that would be open to support the connectivity of the dedicated thick client.
  • Segregation of Duty driven audits of the organization’s databases that typically supported the ERP and other applications. We’ve talked extensively about the Segregation of Duty concept in previous blog posts. It’s basically an assessment of users, roles and permissions for any given application.
  • And if the organization wanted to be comprehensive, they would supply us with a copy of the thick client to enable a manual exercise around brute force user account testing against the ERP application to try and find easily guessed account ids and passwords.  This was rarely a focus point of the assessment because most companies operated under the belief that their ERP systems, accessible only from inside the network and only via a thick client that few people had installed, were pretty secure black boxes.

The primary takeaways from most of those assessments were 1) companies got really good at securing those single-point-of-entry firewalls that protected the network, and 2) those ERP thick client access applications were deployed to only those employees who needed them. 

What has changed since these “olden” days?

Well, we now have “smart” cellular and wireless devices.  And flip phones are nostalgic, but definitely not as fun as they used to be. 

These smart devices have led to the new connected world we live in.  We play games on our devices.  We watch movies on our devices.  And we can do it from pretty much anywhere.

So, why wouldn’t we also want to manage our work life on our devices?

Remember those thick clients people used to access ERP platforms?  Well, with an expanding user base wanting to access those platforms via the various mobile devices they may be carrying, thick clients just don’t make much sense anymore.  Imagine an ERP company trying to develop and maintain dedicated client applications that replicate desktop functionality for all the different device types (iOS, Android, Windows, etc.).

Adding to the challenge, imagine trying to control and support who would be able to download and use those ERP client applications.

So, how to support that expanded and mobile user base?  You make use of what is already available – a web browser.

By adapting ERP platforms to utilize a web browser to deliver functionality, those systems were now accessible to anyone running Chrome, Safari, IE or any of the multitude of browsers available.  Usability challenges aside, it did open the door for ERP systems to be available to that evolving mobile workforce.

But it also opened the door for anyone with a web browser to try and get access to those ERP systems.  And as web browsers are frequently used to access various back end applications, there is an entire black market for scripting tools that can automate login attempts. 

Makes it real easy for bad actors to hammer a system trying to guess legitimate account-password combinations.

So, those once insular, black box ERP applications are now accessible by the masses, good actors and bad.  And as they frequently manage a wealth of sensitive data about a company, its employees and its customers, they are a prime target for compromise.

Security assessments now have to pay attention to these systems. 

And with the evolving compliance regulations that provide users with the right to demand to know who has viewed their private data, internal auditors will also be getting involved to assess the organization’s ability to meet those demands.

The moral to the story I promised?

Protect your sensitive data.  And limit access to that data to only those who need to see it when they need to see it. 

And log those access activities, because, as these new regulations evolve, those auditors will be knocking on the door soon.

Appsian can help with protecting sensitive data and provide controls that can limit access to data to the select users that need to see it. We also provide robust logging capabilities to make it easier to respond to compliance requests and investigate incidents.

Shoot us an email at [email protected] to learn more.

Related Articles.

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

Home / Blog / ERP User Experience: Managing Back Office in a Mobile World (Part One – The Challenges)

ERP User Experience: Managing Back Office in a Mobile World (Part One – The Challenges)

By Scott Lavery • April 3, 2019

We live in a connected economy.  We live in a connected world.

We want our games, our movies and our friendships to be accessible on our phones and tablets.  Why wouldn’t we also want to be able to manage our work life on those mobile devices as well?

Answer: we do.

Most modern applications are designed from the ground up with mobile support in mind.  For these applications, security is designed around the idea that identity is the new perimeter (check out our Security blog entries for more about that). 

And, to meet today’s consumer expectations, modern applications invest a lot of dollars in the development of mobile-friendly user interfaces that utilize modern technologies, such as HTML 5 and other responsive technologies that provide a smooth and efficient user experience.

But, what about legacy applications? What about ERP systems released in the 90’s? 

These applications were usually designed to be accessed only from within the network, and typically only by a select few users using tailored client applications running on the desktop.

Those legacy systems are still being used by many companies to handle critical operations including human capital management, financials and supply chain. 

How can these applications meet the demands of the new connected world, where managing my work life via mobile is just as important as managing my personal life?

Before we talk about solutions, let’s talk about some of the usability challenges of exposing those applications to a mobile world.

Mobile Devices

Smartphones, tablets and all of the other evolving mobile device footprints vary in their features and specifications. And typically, their capabilities fall well short of the routine desktop computer sitting in your office or home.

How?

  • Drastically reduced screen size
  • Limited power and processing capabilities
  • Challenging data entry methods (virtual keyboard, etc)
  • Range of operating systems (iOS, Android, Windows, etc)
  • Lack of standard security models

Mobile Connectivity

Desktop computers typically rely on wired connections to a network. Those connections have historically been stable and reliable.

Mobile connectivity is far more more dicey and depends on local conditions that dictate reliability, bandwidth and consistency.

We’ve all had a game of Candy Crush crash because we moved into a cellular dead zone – haven’t we?

Don’t judge me.

And, like the phone games we love to engage in, ERP systems also typically rely on long-lived sessions and multi-step transactions that depend on stable connectivity and session persistence.

The End User

Historically, applications had been designed around technology-oriented interfaces. We get back to the old model of legacy applications being implemented for selected users via a dedicated user interface that maximized the user’s ability to get their job done.

Modern applications, with mobility in mind, take a user-oriented approach to interface development. When you push connectivity out to the mobile world, you need to be able to support end users with different levels of skills (self-service, admins, etc).

How do you provide a user experience that supports retirees, many that may have accessibility challenges, trying to access benefits information via a phone? How do you support students that want quick and easy access to course scheduling and performance reports? How do you provide a mobile user experience that allows managers and administrators to access application functionality required to perform back office tasks?

More to come on this topic. 

After all, challenges breed solutions.

In the meantime, please reach out to [email protected] (or just click on our little onsite chat helper that tends to hang out at the bottom right) to get more info on how Appsian can help bring ERP into the connected world.

Related Articles.

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

Home / Blog / How Establishing Strong Segregation of Access Policies are the Keys to Protecting your ERP Applications from Access via the Wild West (aka the internet)

How Establishing Strong Segregation of Access Policies are the Keys to Protecting your ERP Applications from Access via the Wild West (aka the internet)

By Scott Lavery • March 18, 2019

In the years I’ve been architecting and assessing organizational information security approaches; the typical focus of any effort was on the perimeter protection offered up by network infrastructure.  Primarily on the firewalls that typically separate the organization’s internal network and applications from the wild, wild west that is the Internet.  The goal was to ensure that those firewalls were hardened doors that only allowed very specific traffic through.  And that traffic was typically limited to requests going out of the organization door to allow employee access to websites and other publicly available resources.

Aside from supporting those outgoing connections, very little, if any traffic was allowed in through the door.  Digital attacks on the organization were usually focused on breaking through that door via exploiting vulnerabilities or mis-configurations in the firewall.  With a focused point of entry to defend, security people got really good at locking down firewalls.

Things have changed. 

Mobile devices and applications.  5g cellular networks.  User expectations.

“I want my games, my videos and my music available to me 24-7, wherever I am.  And, oh yeah, I also want to be able to manage my life and job from my phone or tablet.” 

How do companies support these expectations?

They start making plans to poke holes in that firewall door to allow access to applications that were previously not accessible from outside the network.  Let’s focus on those applications that typically allow a user to manage their life and job.

Let’s focus on legacy ERP applications.  These are the systems that companies have used for years to manage employees and the associated personal data required to support their employment and job responsibilities.  ERP systems were designed to operate in an assumed secure environment where access was limited, and exposure to the wild, wild west (the Internet) was never envisioned.

The challenge becomes clear.  How do organizations allow users to access a legacy ERP system from outside the network?  Technically it’s relatively easy.  Open a few network ports, create a mobile friendly user interface, expose a few web services and voila, your in-house application is now accessible from everywhere.   Along with the data that it manages and maintains.

So, it’s not about technically enabling the access.  It’s about securely controlling the access.  Because that hardened network door is now evolving into a swinging screen door that has a great big “come on in” sign.

It’s not just about protecting the perimeter any more.  Because that wall, or door (or whatever you want to call it), is not the barrier it used to be.  Actually, identity is the new perimeter.  Because being able to get into those applications is no longer dependent on me being in the corporate network.  That internal access, being behind that hardened door, was always a somewhat controlled environment.   Compare that to today.  Now I can get in from anywhere and it’s solely about who I am – or at least who I claim to be.

So, how do we secure these legacy ERP systems that were never designed to provide the access control security required to support exposure to the wild, wild west? 

How do we limit the exposure of sensitive data to bad actors that might access those systems via stolen credentials obtained via phishing campaigns or post-it notes left in a university’s shared computer lab?  And in the evolving compliance environment, where GDPR and U.S state driven regulations are now requiring organizations to be able to report who has seen a user’s sensitive data, how can we get that data from those legacy systems in a timely manner?  And finally, with the current focus on data privacy, how do we limit the visibility of sensitive data, even for legitimate users, to only those users that need to see it to do their job?

The key is to establish good policies and practices around Segregation of Access (SoAx).  Segregation of Access essentially involves protecting sensitive data.  Not only from malicious bad actors, but also limiting access to that data to only the people that actually need to see it.  And another key component is logging that access to sensitive data to ensure traceability in case of an incident or a compliance request.

How much sensitive data is exposed when a typical manager accesses an employee record in an ERP system?  Pretty much everything related to that employee.  Does the manager really need to see social security numbers, dates of birth, etc.?  Probably not.  So, why not reduce your risk exposure by masking that data? 

How about high privileged users?  Should they have the same access capabilities if they are coming into the system from outside the network versus inside?  Probably not.   That is the definition of a risky transaction, because it could involve compromised credentials for a high-powered account.

Anyone accessing an application from the wild, wild west is, by definition, a high-risk user.  And controls should be implemented to establish additional layers of identity validation (via multi-factor authentication, etc.) for those types of risky transactions.

SoAx needs to become a part of any organization’s security posture.

What constitutes an effective SoAx approach?  It involves an effective use of dynamic data masking based on the conditions from which a user may be entering the system (role, location, etc) and the use of additional layers of identity validation for those specific areas of the system where sensitive data is exposed.

How do you start?  We can help.  Please contact us to see how Appsian can help control and report on ERP data access and help secure your sensitive data. 

Want to learn more about SoAx? Join us for a webinar on Thursday, March 28th at 1 PM cst.

Related Articles.

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

Home / Blog / Making Sense of MFA, SSO and Other Session Baby Sitters

Making Sense of MFA, SSO and Other Session Baby Sitters

By Scott Lavery • March 7, 2019

I was at the Alliance conference in Orlando this past week, and in the course of presenting and listening to multiple institutions in the higher education space, I picked up on a common thread. There is a lot of confusion on how modern access-level security measures such as Single Sign On (SSO) and Multi Factor Authentication (MFA) work, and more importantly, how they can work together to bolster an organization’s application security posture.

So, let’s start with the basics. I’m going to stay at a high level for this post. If there’s interest, I can dive into the technical nerd-stuff in a follow on. And yes, please encourage me, as I love the technical nerd-stuff.

Single Sign On

Single Sign On (SSO) is essentially an authentication mechanism that allows a user to access multiple applications with a single set of login credentials. Typically, these centralized credentials are maintained in an identity store (LDAP, ADFS, or another provider) and are incorporated into a token standard, such as SAML, that allows for the mapping to the user’s credentials stored in each participating application.

SSO provides a measure of security in that 1) a user does not have to remember (or store on post-it notes) the multiple user names and passwords associated with each application, and 2) it provides a single point to disable a compromised account.

Multi Factor Authentication

Multi Factor Authentication (MFA) is a mechanism where more than one form of authentication is required before allowing a user access to an application, or in the case of granular MFA, to designated sensitive processes or data within an application. Text book MFA dictates that there are three forms of authentication: something you know (user name and password, typically), something you have (a phone that can receive app-based or SMS confirmation requests, for example) and something you are (the rapidly evolving arena of biometrics).

MFA requires the use of at least two of these authentication methods before allowing access. It’s the current standard for securing authentication beyond the use of the standard user name and password method that has become much less secure in these days of phishing attacks and other means of stealing credentials.

MFA is becoming really common these days. Think of anytime you try to access your bank account from a new computer or an atypical location (you’re on vacation in China, for example). You will typically be sent a text with a code to your cell phone that you have to input before you’re allowed access. Again, you start with the something you know, but are additionally required to meet the something you have-based challenge.

It’s not perfect and needs to be implemented securely (which is a moving target), but it is a mechanism that helps prevent many of the common breach vectors that have plagued applications that store sensitive data such as SSNs, bank account numbers and other private information.

Both SSO and MFA utilize the concept of a web “session”.

What Is A Web Session?

Let’s start with what web interactions would be without the concept of a session. We would be in a world where every request made by a web browser would have to include whatever authentication credentials might be required to support the request to the site/application. And, even then, every request would be a one-off request-response without the ability to support multi-step transactions. There would be no persistence that we take for granted when we access online shopping sites or key business applications.

A session is commonly defined as a web server-side storage of information that is designed to maintain information throughout a user’s interaction with a web site or web application. The stored information around the ongoing interaction has a key that is passed between the site/application and every HTTP request that the browser makes. Thus, knowledge of what has transpired in the interactions is maintained and updated and allows for a site or application to respond based on what you did before. And it eliminates the need to re-authenticate with every web request.

How Does SSO Work?

SSO typically involves a user logging into a centralized Identity Provider (Okta, ADFS, LDAP, etc).

And as I’m discussing at a high level, I’m going to stop using the word “typically”, as the various Identity Providers for both SSO and MFA can operate differently under the covers.

Once a user logs into an Identity Provider (IdP), a token (a piece of code usually maintained in a browser) is created.

OK – “usually” is the same as “typically”, so I just have to stick to the most common scenarios.

When the user clicks to access an application that is under the SSO umbrella, the token is used to map the IdP login to the application credentials associated with that user. The IdP does not store the application credentials, but does map the central IdP credentials to an individual application account.

In a perfect SSO world, a user would be assigned application accounts that would have credentials (user name and password) that they would never need to use or know. They would be able to seamlessly traverse the applications they need to do their job based solely on the authentication to the IdP.

The token generated by the SSO IdP can have various parameters that dictate the life of the session that has been established. Timeouts can be specified that would dictate logouts from all SSO-based applications based on inactivity or specified durations.

How Does MFA Work?

SSO is fairly straightforward and adheres to stringent standards such as ADFS, Shibboleth and SAML.

MFA is a little more custom and implementations differ widely between providers.

Common approaches include the use of physical security tokens (key fobs, smart cards, etc), soft tokens (device-based apps that receive challenge requests, etc), mobile authentication (SMS, phone calls, etc) and biometric authentication (retina scans, facial recognition, etc).

The underlying commonality between these mechanisms is that, upon a successful response to the MFA challenge, a token is generated that allows access to the requested resource. The life of that token can be dictated via configuration within the MFA provider profile. Like SSO, this setting can be driven by inactivity or a dictated period of time.

How Do SSO And MFA Work Together?

This is where life gets dicey because cooperation between the tokens generated by SSO and MFA is really dictated by the provider capabilities and the associated configurations.

In general – yes, I found an alternative to “typically” and “usually” – the expiration of an SSO token will block access to all SSO enabled applications if users are prevented from directly logging in. Re-logging into the SSO IdP will be required.

The expiration of an MFA token will block access to subsequent requests for the MFA protected resource, but won’t necessarily block access to other parts of the application.

SSO is a fairly established standard, offering both security and productivity benefits. MFA is still evolving and, while implementations vary greatly, the technology is evolving rapidly to provide that additional layer of identity validation that SSO doesn’t support.

Contact us to learn how Appsian can help bolster your application security posture via SSO and MFA access controls.

Related Articles.

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

Home / Blog / Privacy Versus Security in a Connected World

Privacy Versus Security in a Connected World

By Scott Lavery • February 25, 2019

There’s an interesting story from a few years ago.  An angry father marched into the corporate office of Target and demanded to know why they were sending unsolicited advertisements for baby supplies to his teenage daughter.

Well, he ended up with egg on his face because, yes, his daughter was pregnant.  And, yes, Target knew about it before he did (Father is last to know).  All those coupons for baby food, cribs and child clothing were sent directly to his daughter because Target determined her buying and search history made her a likely expectant mother.

Aside from the obvious creepiness factor, it also demonstrates that, in a connected world, much of our digital and financial privacy is gone.  Between Internet search engines, online advertisers and, especially, mobile application developers, the wealth of data we willingly give up about ourselves is tremendous.

Why is Facebook free?  Why are all those cute games and apps you use on your phone free?  Why aren’t you charged to use your favorite web browser that some company spent millions to develop?  I think you get the picture.  I like to use the phrase:

If you’re not a paying customer, you’re the product that’s being sold.

I could go on, but let’s just acknowledge that much of what you do, who you are and what drives your buying decisions is out there and being used to target your opinions, dollars and time.

Let’s talk about data security.  Yes, while I acknowledge that there is data about me that is not private (more that I care to think about), there are certain pieces of information about me that I should be able to expect are secured and unavailable for public consumption or viewing.

Data such as:

  • My social security number
  • My private health information
  • My bank account details

Why do I have more stringent expectations around the security of this data?  Because this ever-evolving population of personal data can be used to compromise me.  If it represents direct access or threats to my financial posture, my reputation or my safety, certain data is now viewed as ‘sensitive’.

And while multiple regulations (GDPR, HIPAA, etc) are coming out and evolving in support of the protection of ‘sensitive’ data, we still see many companies that are turning a blind eye to their exposure to sensitive data breaches, especially in legacy applications such as ERP systems and decades old data storage platforms.

And even the companies that are trying to address the security of this sensitive data, are typically focusing on the back-end storage systems (databases, etc) and working to implement ‘Segregation of Duty’ (SoD) controls.  SoD controls focus on the permissions granted to roles in an application, and the roles that are granted to the users of that application.  In essence, no role should be over powered in that it has too much control over any given business process.  And no user should be granted multiple roles that give them too much power over any given business process.  SoD is all about checks and balances.  The lack of which brought down companies such as Enron and Lehman Brothers.

SoD is important.  But these days, with the advent of mobile and the increased attack surface – i.e. access points – of these legacy applications, access controls are also key.  And with the success that modern phishing attacks seem to be having (approximately 4% of targets will fall for any given phishing campaign), application credentials cannot be considered as secure as when just a few select users inside the corporate network were utilizing the application.

Segregation of Access (Soax) is now just as key as SoD.  Being able to manage and report on access to sensitive data, even if it is just the viewing of that data, should be a critical component in any company’s security posture. 

  • Mitigating the risk of malicious access via additional identity verification
  • Limiting access to sensitive data to only those who need to see it to do their job
  • Logging that access to ensure traceability and effective audit support

These are all key pieces of an effective SoAx program.

Contact us to learn how Appsian can help implement an effective SoAx plan.

Related Articles.

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

Home / Blog / Data Privacy and the Evolution of Segregation of Duties

Data Privacy and the Evolution of Segregation of Duties

By Scott Lavery • February 18, 2019

In my years of performing organizational security assessments, application level vulnerability testing usually included an evaluation of the application’s ability to support the “segregation of duties”.   Especially assessments driven by regulatory or compliance requirements, such as PCI DSS, HIPAA or SOX.

What is the concept of segregation of duties (“SoD”)? 

According the AICPA, SoD is “a basic building block of sustainable risk management and internal controls for a business.”  Essentially SoD seeks to ensure that key business processes incorporate sufficient checks and balances to ensure that critical touch points are distributed to various people and/or departments.

Think of a nuclear weapons system. 

What if the keys, locks and codes were all controlled by a single individual?  A recipe for a literal disaster.  In the corporate world, SoD seeks to protect against fraud, business disruption and other forms of malicious activities.

At the application level, an SoD assessment focuses on the Roles the application defines, the Permissions attached to those roles and the Users that assume one or more of those roles.  Simply put, no single role should have permissions that grant to much control over a business process.  And no single user should have multiple roles that allow that user to subvert the checks and balances associated with the process.

Think about a company that does business with multiple vendors – allowing a single individual (or even department) to have the power to do all of the following: A) set up a new vendor B) create payments to that vendor C) and then approve those payments can be a recipe for corporate malfeasance.

SoD has been a key component of security assessments for quite a while and was a key finding in audits of companies like Enron and Lehman Brothers.  Hint:  Both are no longer around due to massive corporate malfeasance.

But SoD is evolving.  In our changing regulatory environment, laws such as GDPR and the California Consumer Privacy Act are not just focusing on what people do, but also on what they see.  These new regulations are introducing user rights around who is accessing personal data – especially their sensitive data, such as social security number, bank account information, etc.

I like to use the example of me not receiving a scheduled paycheck. 

I don’t know where the funds went or how the bad actors potentially got in, but chances are, my second call (the first being to the bank) will be to my employer.  My bank account information is typically stored in a work system, typically an ERP application, to enable direct deposit.  In the new regulatory environment, I have the right to go to my employer and demand to see who has accessed my bank account information.  This would include legitimate users as well potential bad actors.  Ultimately, I would want to know if that account information was changed to facilitate a theft of my paycheck, but determining who has accessed the account data is a necessary first step.

SoD is about trying to manage what people can and can’t do. 

I’m coining the phrase “Segregation of Access”, or “SoAx”, to now add the requirements around being able to enforce what people are able to see.  Who needs to be able to see my bank account data?  Probably just me and maybe a couple of designated Payroll employees.  Yet, that data, as well as other sensitive items about me are typically in full view in a system – on screens with other innocuous data that system users may need to see to do their jobs.

For example, if my manager accesses my employee record to review my role or department settings, typically my date of birth and social security number are on display.  Data my manager doesn’t need to see to do their job.  The principle of SoAx should ensure that sensitive data is only accessible by the people that need to see it to accomplish their job.  And maybe adding controls around access that ensure those legitimate users are only able to access that data while working onsite, reducing the risk of stolen credentials, etc.

By limiting the access to a “need to see it” posture, companies will be much better prepared to meet regulatory and compliance driven mandates to report on the access of sensitive information. 

Contact us to learn how Appsian can help bolster your SoAx (yes, I’m hoping the acronym catches on) efforts.

Related Articles.

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

Home / Blog / CISO Survival 103: The Importance of Classifying Sensitive ERP Data

CISO Survival 103: The Importance of Classifying Sensitive ERP Data

By Scott Lavery • February 5, 2019

This will be the final entry in our current CISO Survival series.  And we’re taking a step back.  We’ve talked about the role of the CISO in protecting an organization’s sensitive data.  We’ve also discussed how a CISO can lead the charge to identify where data resides and how to best assess the associated risks.

However, we have (somewhat) put the cart before the horse.  A key step in any data risk assessment is initially defining what information your organization will classify as “sensitive.”

In its broadest context, sensitive information is defined as data that should be protected against intentional or unintentional disclosure outside of legitimate business processes.  Protection of such data may be required for compliance or regulatory reasons.  Or it may be driven by the need to safeguard the personal privacy of customers, employees or partners.  Or it could be in the interest of protecting proprietary information.

Some examples of sensitive data and the scope of protection required are:

  • Protected health information as defined by the Health Insurance Portability and Accountability Act (HIPAA).
  • Credit card data as defined by the Payment Card Industry (PCI) Data Security Standard.
  • Student education records as defined by the Family Educational Rights and Privacy Act (FERPA).
  • Customer data as defined by the Gramm Leach Bliley Act (GLBA).
  • Personal information as typically outlined in state-specific data privacy and identity theft regulations.
  • Confidential data that is usually covered in state-specific public records regulations.

An effective first step to an organization’s data risk analysis strategy is to first define the types of data you are dealing with. Do you support direct deposit capabilities for your employees? Do you maintain individual health information in any systems? Do you manage credit card information?

You have to then prioritize that data into buckets defined by the level of risk and liability associated with the exposure and/or loss of that data. A typical risk and liability bucket breakdown might look like this:

Confidential Data

Typically, the most sensitive classification – this bucket will include:

  • Financial records
  • Health records
  • Credit card data
  • Social security numbers
  • Student records

Private Data

A step below Confidential in terms of risk and liability, but reasonable efforts should still be taken to secure data in this bucket.

  • Personal contact data (non-student related)
  • Trade secrets
  • Company generated user identifiers

Public Data

  • Publicly accessible financial data
  • Publicly accessible company contact data

These are guidelines to assist an organization in efforts to define what constitutes sensitive data in their business environment.  Every company is different, so be sure to fully understand the nature of the information flowing in and out and being stored before focusing on how to classify it.

Please contact us to learn how Appsian can help in assessing the risk associated with your ERP data.  This exercise is especially critical for legacy ERP systems, where years of use can lead to a myriad of data being stored.

Related Articles.

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

  1. Pages:
  3. 1
  4. ...
  5. 12
  6. 13
  7. 14
  8. 15
  9. 16
  10. 17
  11. 18
  12. ...
  13. 34
Request a Demo

Start your free demo

"Learn how you can reduce risk with rapid threat protection, audit response and access control. All from a single, comprehensive platform"

Trusted by hundreds of leading brands