Quickstart: Creating Effective Policies

Introduction

SGNL policies have been designed from the ground up with a goal to be human-readable, easy to understand, and simple to audit and maintain. With SGNL, we want to enable those that set organizational policies within an enterprise to have a seat at the table when policy is applied across applications and services.

The purpose of this quickstart guide is to provide a framework for establishing effective policies in your organization with SGNL. You can watch the video below for an overview of this quickstart guide.

Step 1: Define and Prioritize Your Goals

The modern enterprise faces a broad range of challenges associated with authorization. Before embarking on any project to improve your organization’s security posture and accelerate business processes, defining a clear set of goals and objectives for the project is critical. You’ve probably already got some idea as to why you’re taking this project on, but it’s worth being intentional about what you’re working towards.

Common goals associated with rethinking your Enterprise Authorization strategy may include:

• Eliminating excess and/or stale permissions for users to sensitive data to reduce the risk of account compromise or misuse (or recovering afterwards)
• Achieving regulatory compliance in new or existing markets through the introduction of new controls and policies
• Reducing the time, cost, and confusion spent on access reviews by centralizing policy and giving control back to policymakers and compliance teams
• Improving business agility, through:
  • Automated provisioning/deprovisioning of access when it’s needed, eliminating waiting time for business users spent waiting for access
  • Implementing an extensible platform for fine-grained authorization, instead of assigning teams of engineers to build custom, homegrown solutions that doesn’t drive your core business forward

Once you’ve defined your goals, create a short, prioritized list of the top 2 or 3 that will dictate your success criteria.

Step 2: Gather and Prioritize Your Use-Cases

With a clear set of goals in-hand, it’s time to determine the use-cases that will be most impactful to your business. When thinking about your use-cases, we recommend thinking about the Who (who is in scope of this use-case), What (what data does this use-case affect), Where (in what systems/apps/services do this use-case apply), When (when would this use-case be allowed or disallowed).

Let’s say your goal was:

To reduce the risk associated with any one of our employees or extended workforce having their account compromised.

You might have a few different, high priority use-cases:

• Our Customer Support team should only be able to access a Customer’s orders in our CRM solution if they have business justification
  • Who: Customer Support team
  • What: Order records
  • Where: CRM Solution
  • When: With appropriate business justification
• Our Sales team should only be able to apply discounts to Customer invoices in our Billing platform if they are the assigned account owner and the discount is less than an allowed value
  • Who: Sales team
  • What: Invoices
  • Where: Billing Platform
  • When: Assigned Account Owner, < specific value
• Our Engineering team and service accounts should only be able to access a Customer Bucket in our Cloud Services Provider if it’s during an approved change window and the customer has granted consent
  • Who: Engineering team, Service accounts
  • What: Bucket
  • Where: Cloud Provider
  • When: During change window, following customer consent
• Accounts in our organization should not be able to access our product’s source code in our Cloud-hosted repositories if they are in an embargoed country
  • Who: Everyone
  • What: Source Code
  • Where: Cloud Repo Hosting Provider
  • When: In embargoed countries

Step 3: Determine the characteristics that describe each part of your use-case

It’s now time to describe each characteristic of your use-case in simple terms. Think about all of the systems in your environment that contain context about your business. Which of them would be authoritative for describing a specific characteristic of your use-case?

Taking the use case:

• Our Customer Support team should only be able to access a Customer’s orders in our CRM solution if they have business justification

Step 4: Structure your first SGNL Policy

SGNL Policies can contain snippets of different types, including principals, assets, actions, and conditions. Policies are intended to be human-readable and transferable from how you would describe the policies within your organization.

The next step is to describe your use-case in the format that SGNL uses to express policy.

Taking the use case:

• Our Customer Support team should only be able to access a Customer’s orders in our CRM solution if they have business justification

Principal Snippets:

• What do they do? Describes the cohort of identities (users, services, robots, etc) that are relevant to this policy
• What is it in this example? “Customer Support”

Policy Type:

• What does it do? Defines whether the policy will result in an allow or deny decision
• What is it in this example? “Can” - an Allow Policy Type

Action Snippets (Optional):

• What do they do? Defines which actions (if applicable) are covered in this policy
• What is it in this example? “access”

Asset Snippets (Optional):

• What do they do? Defines which assets (e.g. resources, services, infrastructure) are in scope of this policy
• What is it in this example? “Customer orders”

Condition Snippets (Optional):

• What do they do? Defines the conditions that would cause evaluation to give the decision dictated by the Policy Type
• What is it in this example? “an active customer case is assigned”

Resulting in:

Step 5: Describe each of your snippets

Now that you’ve successfully described each part of a SGNL policy, you can get into the details about what each of your Snippets mean, and how SGNL can get the data to enable them to be evaluated, the table below is a handy way to structure your discovery.

In the table, detail how you might define each of the snippets, where the data comes from (data sources), and what attributes or relationships to look at (both within data sources and across them)

Step 6: Create your Policies and Snippets in SGNL

Now that you’ve formulated how your policies and snippets are going to look, you need to onboard the required Systems of Record, the protected systems you want to protect (i.e. your apps/services), and start building your snippets and policies inside of SGNL.