Skip to main content

Lacework Edge Policies

Policies and workflows govern how, and whether, your users can access your organization's privately hosted applications, SaaS apps, and web sites in general. There are several types of policies and policy elements, as described here.

App Control​

App Control policies allow administrators to disable actions like copy, paste, print, upload, and download for specified websites or domains. App Control policies require the use of the Lacework Edge browser plugin and only apply to users who are accessing resources or websites via a browser with the plugin installed.

Security Policies​

Security Policies match actions to the traffic and activity characteristics that you define. They provide flexible matching rules on user sessions and traffic destinations, and support a diverse range of actions, giving you precise control over users' traffic. For instance:

  • Allow access to a privately hosted app.
  • Block all user traffic to phishing sites.
  • MITM inspect traffic to all privately hosted apps.
  • Trigger admin approval workflow for sales people accessing GitHub.

Routing Policies​

Routing Policies apply routing rules to application traffic, and allow you to specify whether to route traffic through Lacework Edge, through a specific connector, or bypass Edge and flow directly to the application target. For example, a routing policy is useful for defining rules that cause traffic to be routed directly to trusted applications, such as Zoom. A more advanced use of Routing Policies might be when a engineering team is testing a service in a pre-production environment but making calls to it using its production domain name.

Workflows​

Workflows present actions to end users when attempting to access private and Internet resources protected by Lacework Edge, and they are customizable both in content and in logic. Employing workflows reduces the burden on the IT or security team, who typically do not have the context for the many actions and requests that occur across the whole organization.

Some examples of workflows are:

  • For websites marked as malicious with low confidence, instead of blocking the user, you can trigger a workflow that warns the user of the potential danger, and ask the user to acknowledge (self-approve) to continue to the site. This kind of workflow allows you to be more aggressive in terms of when to intervene, without jeopardizing your users' day-to-day work.
  • When a user's device is active from a new location, trigger a workflow that asks the user to confirm via Okta MFA.
  • Sales person's attempt to access an engineering resource (e.g., Jira, GitHub) triggers a workflow that requires the admin's approval. The person trying to access the resource will be prompted to provide a justification.
  • Contractors' access to GitHub goes through a workflow that requires the Engineering Manager's approval. The access expires after 30 days.

Together these policies and workflows protect your business applications, keep the bad actors out, and keep your users secure. Configuring them properly to reflect your business needs is very important.

[Legacy] Access Policies​

Access Policies are the simple policies that describe who can access what. For instance, users in an Engineering group can access the build server.

caution

Access Policies have been deprecated in favor of PERMIT Security Policies.