Chetan Shridhar

Web Security Rule Builder

The Web Policy rule builder is a rule-based web gateway security configuration app. Web Security Administrators (InfoSec teams) configure rules to control and monitor web traffic between an enterprise boundary and the internet. These rules control and filter web traffic originating from users accessing the web and block or allow, for example, downloads from the web. This ensures protection against web threats such as viruses and other malware, data exfiltration, etc., which can arise from uncontrolled web access.

Web Policy in focused view: a Web Filtering ruleset with nested Category, Reputation and Geo and Category and Domain Coaching rulesets, each holding rules to skip, block or coach traffic by lists, countries, categories, media types and site reputation

The problem

The Web Security Administrators are currently provided with a configuration UI that is mostly switch-based (on/off or enable/disable).

  • Limited control via the user interface (mostly switches)
  • For complex rules, customers need to learn the product’s proprietary code language OR spend money on PS (professional services) hours.

Proposal

To build a tabular rule-builder that enables Security Administrators to write complex rules via the user interface, without letting go of:

  • The existing simple UI, which works very well for simple use cases and is an easy out-of-the-box (plug-configure-play) solution.
  • Complex code insertion for complex use cases.

The idea was to create a “Standard” interface where users can write complex rules in the comfort of a usable UI.

The trifecta

We worked as a trifecta consisting of UX, PM, and Engineering.

Within the UX team, we had an internal trifecta consisting of a UX Researcher, a UX Designer (Interaction Designer), and the Design System lead. Although I led the UX efforts for this product, I took timely help from UX researchers to conduct research sessions and document findings. My collaboration with the Design System lead helped us work on new component requirements, assessing and reusing existing components.

The trifecta The trifecta: UX Designer (me), Product Manager and Engineering Lead. Within UX, the UX Researcher and the Design System lead work with me, as satellites. UXResearcher DesignSystemLead UX Designer(Me) ProductManager EngineeringLead Trifecta

Discovery

Approach evaluation

We built a high-level wireframe to conduct user research sessions, to understand whether this direction was apt for users and which key issues they would like the solution to address.

Wireframe used to verify the approach A Balsamiq-style wireframe of Web Policy. A policy tree on the left. On the right, a top-level ruleset holds a library ruleset with preset rules in sections, hooks to add custom rules via the rule builder or policy code, a custom rule with configurable criteria and action, a custom policy code row, and a nested ruleset. A second top-level ruleset holds its own rules and a copy of the nested ruleset. Web Policy Toplevel RulesetLibrary RulesetAdam’s RulesetToplevel Eve’s RulesetCopy of Adam’s RulesetTop level Ruleset Eg. Global BlockEntry Criteria/ScopeCyclesLibrary Ruleset Eg. Global Block ListEntry Criteria/ScopeCyclesPreset Rules (Simple View)Section 1Rule 1Rule 2Section 2Rule 1Rule 2Add Custom Rule via Rule BuilderAdd Custom Rule via Policy CodeHook present between Section 2 & 3Section 3Rule 1Rule 2Section 4Rule 1Rule 2CustomRule1IF Criteria {param}matchesvalueAction{Config}EventOn/OffCustomPolicyCode1Policy code DescriptionOn/OffAdd Custom Rule via Rule BuilderAdd Custom Rule via Policy CodeHook present after section 4Adam’s RulesetEntry Criteria/ScopeCyclesJayIF CriteriamatchesvalueActionEventOn/OffAdam’s PolicyCodePolicy code DescriptionOn/OffTop level Eve’s RulesetEntry Criteria/ScopeCyclesKaleIF CriteriamatchesvalueActionEventOn/OffEve’s PolicyCodePolicy code DescriptionOn/OffCopy of Adam’s RulesetEntry Criteria/ScopeCyclesJayIF CriteriamatchesvalueActionEventOn/OffAdam’s PolicyCodePolicy code DescriptionOn/Off
Swipe to see all of it.

Research

Separate research sessions with 7 customers (around 23 participants) were conducted with the following goals:

  • Feedback on the proposal
  • Identifying key pain points
  • Prioritizing features

Based on the outcome of the research sessions, Product Management and UX together identified the features for the MVP.

Information design

Dependency

Security Policy (application) is positioned within a suite of other security applications under one platform. It depends on the Configurations and Lists repositories, so I first needed to understand how they work and how they are built.

Where a rule’s parts come from Configurations and lists are kept outside Web Policy. Certificate Verification checks Domains/Hosts against the Certificate Bypass List and skips. Custom Rule checks User Agent against UA_list and blocks, showing the default template from the notification pages. Defined and maintained elsewhere,then used in rules. Configurations SAML settings HTTPS settings Notification pages URLs, IPs, certificate authorities,curated elsewhere, used in rules. Lists Certificate Bypass List WebEx IP Ranges (23) UA_list Security policyrules that block or allow traffic Certificate Verification Skip IF Domains/Hosts is in Certificate Bypass List Custom Rule Block IF User Agent is not in UA_list Default template shown when blocked
Swipe to see all of it.

Structure/hierarchy

Irrespective of whether we are building a product from scratch or adding features to an existing app, it is important to understand the information design so that we cater to the contextual placement of:

  • Information
  • Actions
  • Indicators (/messaging)
How traffic moves through the policy tree The policy tree holds rulesets. Web traffic reaches a ruleset’s scope; traffic in scope goes on to its rules and to its child, a nested ruleset with its own scope, and the rest moves on to the next ruleset. A rule joins IF conditions with AND or OR and ends in one action, such as allow or block. A condition matches a criteria to a value and returns true or false. Policy tree web traffic the restmoves on scope Ruleset Rule Condition AND/OR Condition Action scope Nested ruleset Rule Condition Action scope Next ruleset Policy treeHolds every ruleset and rule. RulesetOnly traffic in its scope enters. Rule and actionIF conditions with AND/OR, thenone action, such as allow or block. ConditionA criteria matched to a value,returning true or false. Nested rulesetA child of the ruleset. It sees onlythe traffic its parent let in. Next rulesetThe traffic left over moves herefor evaluation.
Swipe to see all of it.

Anatomy of a condition

In this app, a condition is the basic unit that constructs a rule, so defining all the combinations that make up a condition unfolds the underlying interactions.

Anatomy of a condition A condition reads: IF User Agent is not in UA_list, then Block. Logical operators are AND and OR. Criteria come with or without parameters. Operators depend on the criteria: is, is not; is in, is not in; matches, does not match; is greater than, is lesser than, is in range. Values depend on the operator: a value such as location, IP or URL; lists; regular expressions; numerical values and ranges. A rule ends in one action: allow, coach, isolate, block or skip. Logical operatorjoins conditions Criteriawhat is checked Operatordepends on the criteria Valuedepends on the operator Actionone per rule IF User Agent is not in UA_list Block sets the options sets the options AND OR With parameters Without parameters is, is not is in, is not in matches, does not match is greater than,is lesser than,is in range Location, IP, URL Lists Regular expressions Numerical valuesand ranges Allow Coach Isolate Block Skip
Swipe to see all of it.

Workflows/interactions

Due to the complex nature of this application, we had to carefully stitch multiple interactions to help users (security administrators) build rules.

Rule library

Since the existing app had predefined rules that could be configured, we planned to provide these rules in a library, from which they could be imported into the policy along with custom-created rules.

Web Policy with the Add ruleset from library panel open: curated rulesets such as SAML Authentication, Global Bypass, Web Filtering and Threat Protection, each with a checkbox to import

Adding rules

We defined three types of rules:

  • Library Rules
  • Custom Rules – via UI
  • Custom Rules – via Code
A SAML Authentication ruleset with preset rules to skip by lists, a custom rule built in the interface, and custom policy code open in a code editor

Nested rulesets

Since the entire security policy works on the basis of filtering/scoping web requests and responses, an interaction to add nested rulesets was prepared.

A top-level ruleset containing a child ruleset and a grandchild ruleset, each indented one level further

Scoping rules

Scoping was based on numerous factors, such as source and destination ports, user groups, location and many more.

Criteria picker listing client port, destination IP, destination port, IP protocol, HTML attribute and user group, with settings for the selected HTML attribute

Many more workflows were created as part of the MVP to make the app functional; they are not documented in this case study.

Prototypes

Multiple prototypes were created to communicate the interaction flows. They helped explain the flows in customer validation sessions and to the front-end dev team, SMEs, etc.

Key views

The root of the web policy, offering three starting points: add a top-level ruleset, write custom policy code, or view policy code
Global bypass ruleset with preset bypass rules for domains, IPs, user groups and processes, and an update server bypass for Windows Update traffic
Settings for a block action: a list of notification templates, and the chosen template’s language, collection and block reason
End user notification pages: customisation fields on the left and a list of preset pages to preview on the right

Appreciation

Some of the team members I collaborated with voluntarily sent me appreciation for the approach and ownership I showed on this project.

Note: The comments below are backed by emails sent to me.

  • “Appreciate the efforts you have put in collaborating with stakeholders, research, organizing tasks and designing the Std View wireframes.”

    Swetha Thandava MurthyUI Engineering Lead · Bravo! award, March 2022

  • “Thanks for coordinating and working with the team on all UX activities for UCE and providing information in a timely manner.”

    Sumithra DhandayuthapaniDirector, Engineering · Bravo! award, March 2022

  • “Chetan, I’d like to thank you for your relentless support, guidance, expertise and work. You are an expert in UX and have the ability to listen and transform technical details into high fidelity UX screens and guidance for your engineering counterparts. I do very much appreciate you and all you are doing. Your work, diligence, support and your friendly, calm and professional attitude in our day 2 day interaction but also in difficult situations make a difference - for us as team and for us as business. You are a valued member of our team. Your work makes it is possible for us to advance and growing sky high...and beyond.”

    Michael SchneiderSr. Director, Product Management · Bravo! award, June 2022

  • “You are now a pillar of the team”

    Jim BenoDirector, User Experience · June 2022This comment is special to me, as it came from my reporting manager.

Thanks for your time

This rule builder is pretty complex in nature, and the UX effort ran for 7–8 months, including all the customer validation sessions. I couldn’t explain everything here, but we could set up a call, and I’d be glad to walk you through the entire process.