Making a List and Checking it Twice: Configuring Advanced Lists

2 Likes

In this post, we’ll learn about securing access to Advanced Lists in SAS Fraud Decisioning. Keep reading to learn how you can use Environment Manager to customize your Viya environment and control which users can view and configure data for each Advanced List.

What is an Advanced List?

Let’s begin with a brief discussion of Advanced Lists in SAS Fraud Decisioning. Advanced Lists are tabular data that stores information relevant to processing transactions.

Advanced Lists can be updated as needed and then referenced in rules, so that rules can be written to be more versatile, and don’t require an update and re-deployment to add changes. Instead, the rule references the list.

For example, you could create an Advanced List to include known stolen credit card details and then create a rule that generates an alert if the card number from an incoming transaction matches an entry on the list.

In this case, we’ll be using the North Pole as our example scenario. We’ll use the “Nice List” – an Advanced List that is used to keep track of who gets gifts instead of coal Christmas morning.

Advanced List Management & Usage

In SAS Detection Definition, an administrator can configure and manage lists in the Advanced Lists tab. Users must have the capability sda.navigation.advanced.lists to be able to see this tab, and by default, this capability is given to a group called Access Advanced Lists. The SAS Detection System Administrators group is a member of this group.

Other users may not be able to manage advanced lists, but they can still use them in rules. For example, a user being in the Rule Authors group does not necessarily give them access to manage lists, only use them in rules. This gives administrators specific control over who is altering lists, while still allowing rule writers the ability to reference lists.

Advanced lists are associated with an organization, and within an organization, with one or more projects. On the Rules tab, rule writers can see the Advanced Lists which have been associated with a project available to write rules within that project. This gives administrators specific control over who is altering lists, while still allowing rule writers the ability to reference lists.

On the Advanced Lists tab, administrators can configure different properties of Advanced Lists. For example, you can redact sensitive data, such as obscuring a Social Security number or all but the last four digits of a credit card number. In our example Nice List, the address column is redacted. You can also configure row content to expire after a certain amount of time.

Behind the scenes, Advanced Lists are managed through a Redis instance that is connected to SAS Fraud Decisioning. Advanced Lists are stored in the SAS Detection Repository, in a folder called Lists. With users and group membership, the content folder settings, and the authorization rules in Environment Manager, you can precisely customize list access to meet your security needs.

Who can access list contents?

Advanced Lists are created in the Lists folder in the SAS Detection Repository folder. Lists must be in this directory or in a subfolder for SAS Fraud Decisioning to be able to reference them.

By default, any authenticated user can review the lists in these folders. Sometimes, a list might contain data that is especially sensitive, and you might need to specially configure your Viya environment to restrict the access to certain lists.

You can configure the permissions on individual lists in the Content tab of Environment Manager. This example shows the Lists directory under SAS Content, Detection Repository. The Nice List is selected. I can click the lock icon and select View Authorization to view the access details.

Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.

The first column is the principal – this is the user or group being granted a particular ability. The abilities Read, Update, Delete, and Secure are listed.

The head elf user has read privileges, but is prohibited from updating, deleting, or modifying the authorization of the Nice List. If the Head Elf user tries to add an entry to a list or update the list, Fraud Decisioning will prevent this and show a message indicating that the Head Elf cannot modify this list. However, Head Elf can still view the list and its contents. Notice that Santa Claus can still update and delete the Nice List.

Another way to customize list security is by creating subfolders in the Lists directory in Environment Manager and changing the authorization on the subfolders. Lists can then be moved into these folders to secure them appropriately. Keep in mind that the lists must still be in SAS Content > Detection Repository >Lists or a contained subfolder, or SAS Fraud Decisioning won’t be able to use them.

For example, you could move the Naughty and Nice lists to a subfolder of Lists called High Security Lists. Then, you can configure the authorization so that only a few users have update and delete permissions on that folder, which applies to all the lists in that folder.

When you are customizing access, make sure you don’t accidentally prevent any of the users in a particular project who need to use the list to write rules from having Read access. Removing a user’s read access will cause a syntax error in any rules they create that reference the list. Rules with syntax errors cannot be promoted from coding.

Who can unmask list values?

Authorization rules in environment manager allow even more granular control over list access. I’ll navigate to the Rules tab of Environment Manager.

Like content folder security, Authorization rules have a principal that describes the user identity or group that is being afforded privileges. They have a uniform resource identifier, or URI. The setting is either to grant or deny access, and there are types of permissions, like Read, Write, Access, Delete, Secure, etc. Finally, the description summarizes the resource or feature the URI controls.

For example, let’s say you would like to control who has permission to unmask data in lists. You could create this authorization rule to grant Santa the ability to un-redact sensitive data in lists.

The principle is Santa. Creating this authorization rule means that only Santa is granted this ability.

The URI is /listData/lists/*/privilegedContents. The setting is Grant. All the available permissions are selected.