Skip to content

Policy and Configuration

Admin Console

The Nullafi Shield Admin Console provides a graphical user interface for configuring policy, viewing status, and examining event data. It is a web application which can be accessed using any web browser. The Admin Console is available after the Shield container is started. Access is governed by the defined container options (see above). In the simplest case, browsing to the container host’s IP address on the mapped NULLAFI_HTTP_PORT will open the Admin Console login screen, and using the NULLAFI_USERNAME and NULLAFI_PASSWORD will allow the administrator to log in.

Policy

The policy engine is at the heart of Nullafi Shield. It does the work of examining the data being accessed, classifying it, and deciding whether it should be passed through to the user. The Policy section of the Admin Console is where rules are created to control the engine’s behavior.

Rules

Rules are the highest level expression of Policy in the Admin Console. Each rule is built using a series of policy objects (Mask Formats, Applications, etc.) which are in turn defined on their own pages of the Policy section.

Rule Order

The main Rules page displays all the configured rules on a table, listing attributes of each rule. Because rule order affects how policy is implemented, this table cannot be sorted but rather will always represent the prioritization or rules relative to each other. If a transaction from an end user matches more than one rule, the last matching rule in the table will take precedence.

New Rule

To define a new rule, click on the Add New Rule button in the upper right hand corner. The rule editing window will slide out from the right. To create the rule: 1. Type the Name and (optionally) Description into the text fields 2. Select at least one Application from the Applications list. If the rule should apply to multiple Applications, use the list again to select them. 3. Select at least one Obfuscation from the Obfuscations list. Like Applications, the rule can apply to more than one. 4. If directory integration is configured, filtering the rule by User or Group is an optional component of the rule. See below for more information on configuring Users and Groups in Rules, and the Integrations section for how to attach data from your directory to transactions for Nullafi Shield. 5. Click on Save in the lower right

Edit Rule

To edit an existing rule, hover your mouse over the Rule Name, click on the three-dot menu that appears, and choose Edit Rule Details. The rule editing window will slide out from the right.

Delete Rule

To delete a rule, hover your mouse over the Rule Name, click on the three-dot menu that appears, and choose Delete.

Enable or Disable Rule

To temporarily disable a Rule without deleting it, mouse over the Rule Name, click on the three-dot menu that appears, and choose Turn Off. The Status of the rule will switch to Inactive. To re-enable the rule, choose Turn On from the menu and the Status will become Active.

Users and Groups in Rules

In order to apply Policy to specific users or groups in your organization, Shield must have some way of receiving identity information from your directory. See the Integrations section for more information on how to transmit this data to Shield. Once you have completed directory integration, you may include user identity in rule evaluation. On the Rule creation page, below Applications and Obfuscations, click on Users and Groups to add criteria:

  • Group definition is expanded by default. To apply rules to specific users, expand the Username section by clicking on the title.
  • There are four methods of matching groups and user names
    • “is equal” and “is not equal” are for exact matches. Use these to specify an individual user or group. Case sensitive?
    • “contains” and “does not contain” are for matching multiple users or, more likely, groups. If your directory has group names like Marketing-East and Marketing-West, you can use Group contains “Marketing” to write a rule that applies to both groups.
  • Multiple entries in the Users and Groups section operate as a logical OR If you specify both Group equals “Sales” and Group equals “Support” in a single Rule, that Rule will apply to a user if they are in either Sales or Support.

Applications

Applications are the first consideration when Shield applies policy to a connection. They allow Rules to understand the source of the data when deciding how to behave. The Applications page of the Admin Console displays a list of defined applications along with some basic information about each one.

Applications are made up of three components: - Name (required) – Any name you wish to give. This will be used in Rule creation and will appear on the Activity screen when viewing connection history. - Description (optional) – Any text you would like to record alongside the Application definition to help with recordkeeping or context for future reference - Definitions (required; one or more) – This is where you tell Shield how to identify the Application.

New Application

To define a new application, click on the Add New Application button in the upper right hand corner. The application editing window will slide out from the right. To define the Application: 1. Type the Name and (optionally) Description into the text fields 2. For each Definition, choose a type from the dropdown box and fill in the required text field (see below for further detail on the Definition components), then click on the Add button. 3. Click on Save in the lower right

Edit Application

To edit an existing application, hover your mouse over the Application Name, click on the three-dot menu that appears, and choose Edit. The application editing window will slide out from the right.

Delete Application

To delete an application, hover your mouse over the Application Name, click on the three-dot menu that appears, and choose Delete.

Application Definitions

To determine the Application being accessed by the user, Nullafi Shield examines the browser request URL. Application Definitions can be of various types. Domain and Hostname definitions are by far the most common. The following types are available: - Domain - Matches against the domain portion of the URL. For example, “company.com” matches both https://www.company.com and https://app.company.com - Full URL - Matches the entire URL being accessed by the browser. Full URL is unlikely to be useful by itself, but can be used to fine tune an Application Definition using the advanced settings (see below) - Hostname - Matches against the entire hostname rather than just the domain. For example, “app.company.com” will match https://app.company.com but not https://www.company.com - Object Part - Matches against the object being requested by the browser, regardless of the server, domain, or path involved. - Path - Matches against the folders or subfolders being accessed on the server. - Query String - Matches against any part of the URL that comes after a “?” - Regex - Allows full use of regular expressions to allow for very fine grained control over URL matching

Wildcard usage in definitions

All data types allow the use of wildcards in their definitions. In fact, Object, Path, and Query String definitions would rarely be used without them. Some examples: - For Domain definitions, “company.com” matches www.company.com, www.my-company.com, and www.your-company.com - For Hostname definitions, “server.company.com” matches server1.company.com and server2.company.com, but not www.company.com - Combined with the bypass capability (see Advanced Options below), an Object type of “.jpg” can be used to avoid wasting resources on images. - “data=*” in a Query Path definition would include every query that includes a “data=” statement regardless of what comes before or after it

Advanced Options

By default, each Definition is a matching rule. Once a Definition has been created, it can be edited by hovering over the line item on the Edit Application window, clicking on the three-dot menu that appears, and choosing Edit. Under Advanced Settings in the Edit Definition window, a Definition can be changed from a matching rule to a bypass rule. Fine tuned Application behavior can be achieved by combining match and bypass Definitions. For example, a domain match definition for “company.com” could be combined with a hostname bypass definition for “blog.company.com” to avoid applying rules to the blog section of an App.

Data Types

In the same way that Applications tell Shield where to look, Data Types define what to look for. For most organizations, Shield’s built-in data type definitions cover all detection requirements. Administrators simply refer to these Data Types when creating policies to enforce.

The Data Types policy page in the Admin Console lists each type of data Shield can identify. Data Types are given both a Type, designed to be machine-readable for any automated processes that consume Shield’s log data, and a friendlier Name, which is easier for people to work with. The items displayed on the Data Type page can be sorted by clicking on each column title. Click on the column title a second time to switch between ascending and descending order.

New Data Type

On rare occasions, a company may need to create their own Data Type definition to match company-specific data to which they would like to control access. To define a new data type, click on the Add New Data Type button in the upper right hand corner. The editing window will slide out from the right. To define a Data Type: 1. Input the Type, Name and (optionally) Description into the text fields 2. For each Definition, compose the regular expression for matching in the required text field, then click on the Add button. - Some applications require special consideration of formatting (e.g. JSON), and so Nullafi Shield offers Advanced Settings which can be associated with the regular expression matching for a Definition. Please contact Nullafi Customer Support for help with complicated data types. 3. Click on Save in the lower right

Edit Data Type

To edit an existing data type, hover your mouse over the type’s row in the Data Type listing, click on the three-dot menu that appears, and choose Edit. The application editing window will slide out from the right. Only customer-created data types can be edited. The Edit option will not appear for Shield’s built-in data types.

Mask Formats

Mask Formats define how Shield should protect data that it finds. US Social Security numbers are commonly shown in redacted form, hiding the first five digits but displaying the last four. Some data should be hidden entirely, including not just the information itself but also how much of it is there.

New Mask Format

To define a new mask format, click on the Add New Mask Format button in the upper right hand corner. The editing window will slide out from the right. To define a Mask Format: - Type the Name for the new mask format into the text field - Setup the mask format: - Mask Character: The placeholder character for the obfuscated value (eg. "*" will turn "example" into "**")
- Stop Character: The character to stop the obfuscation, to allow partial obfuscation (eg. "@" will turn "example@domain.com" into "*@domain.com"). - *Characters to Ignore: The characters you want to ignore when obfuscating (eg. "@." will turn "jhon.doe@domain.com" into "****.***@*****.***) - Number of Characters: The amount of characters you want to obfuscate or to keep depending on the Behaviour - To Mask: Number of Characters 2 will turn "jhon.doe" into "on.doe" - To Keep: Number of Characters 2 will turn "jhon.doe" into "jh*" - *Reverse Masking Order: This option defines if you want to keep/mask the number of characters from the start of from the beggining of the value. On the example above if you choose to reverse the order it would bevahe as bellow: - To Mask: Number of Characters 2 will turn "jhon.doe" into "jhon.d" - To Keep: Number of Characters 2 will turn "jhon.doe" into "****oe"

Edit Mask Format

To edit an existing mask format, hover your mouse over the Mask Format Name, click on the three-dot menu that appears, and choose Edit. The editing window will slide out from the right.

Delete Mask Format

To delete a mask format, hover your mouse over the Mask Format Name, click on the three-dot menu that appears, and choose Delete.

Obfuscations

An Obfuscation combines Data Types and Mask Formats into a reusable policy object that can be referenced when building Rules. For example, an Obfuscation can tell Shield “If you find an email address (Data Type), replace the username with asterisks but leave the domain visible (Mask Format), and if you find an IP address, replace it with its MD5 hash.”

New Obfuscation

To define a new obfuscation, click on the Add New Obfuscation button in the upper right hand corner. The editing window will slide out from the right. To define an Obfuscation: 1. Type the Name and (optionally) Description into the text fields 2. For each Definition, choose a Data Type and Mask Format from the dropdown boxes, then click on the Add button. 3. Click on Save in the lower right

Conditional Maching (JSON and CSV responses only)

Right next to the definitions tab you can click on the Conditional Matching for an advanced use of the Obfuscation mechanism, from there you can configure filters based on the data types to either Match or Bypass a piece of data from the obfuscation allowing a flexible configuration on top of the data type definitions. You can configure multiple conditional matchings, for each one you need to follow the steps below:

  • Select a Data Type from the dropdown, to ensure we're going to apply the condition for the correct data type.
  • Select a Filter Type from the dropdown.
  • Set the Parent Level (a number or min. 1) of the data to apply that filter. This configure the level of parents from where the filter matches that will be start to apply. For JSON objects that has a hierarchical structure this defined the scope of impact of this filter.
  • Depending on the Filter type (Date, String or Number) we'll support different filter configurations:
    • Date: For this filter you can setup a filter based on range of dates or relative date/time (eg."Within the last 3 days" or "More than 5 hours")
    • String: Similar to a Custom Data Type you can write a regex that will be used as a filter for this String Value.
    • Number: You have the option to set a range of numbers (eg. "Lower or equal than 10" or "Greater or equal 5")
  • Select the Behaviour for this condition
    • Match: Similar to Application Configuration this options set this filter as a requirement for the obfuscation of the data to happen, any piece of data (JSON object or CSV line) that applies that filter will obfuscate it's siblings and child data according to what is configured on the Definitions Tab.
    • Bypass: Has the exact opposite behaviour than Match, which means that if a piece of data matches this filter configuration it won't obfuscate even in the case that a data type included on the obfuscation definition matches a data type detect on any of it's siblings or child data.

A use-case example of this filter is when you have Hubspot configured to receive your e-mails you might want to only obfuscate the e-mail messages that where received more than 3 days ago, so that you can still read any recent e-mail activity but protect PII data of older e-mails that might have already been read. For this you can use a configuration bellow:

  • On the Definitions Tab you can select "Hubspot Email" Data Type and the Mask Format as "Fully Obfuscate"
  • Click Add to finish the definitions configuration.
  • Click on the Conditional Matching tab to configure your filter.
  • Select the Data Type "Hubspot Object Timestamp" from the Data Type Dropdown
  • Select the Type "Date" from the Filter Type Dropdown.
  • Keep the Parent Level as 1 (most of scenarios keeping the parent level as 1 should be fine)
  • On the Data Filter Dropdown select "More than" option
  • On the input you can type the number 3
  • On the dropdown right next to it you can select the "days" option
  • Click Add than Click Save down the sidebar to save this obfuscation.
  • With this Obfuscation you can replicate the use-case described above to obfuscate Hubspot Email Messages that are older than 3 days.

Edit Obfuscation

To edit an existing obfuscation, hover your mouse over the Obfuscation Name, click on the three-dot menu that appears, and choose Edit. The editing window will slide out from the right. Within the editing window, a similar three-dot menu is available for each Definition and Conditional Matching configured.

Delete Obfuscation

To delete an obfuscation, hover your mouse over the Obfuscation Name, click on the three-dot menu that appears, and choose Delete.