Policy Main Use-Cases
Enso’s policy rules allow users to automate essential processes and tasks. In this article we review the main use-cases
Last updated
Enso’s policy rules allow users to automate essential processes and tasks. In this article we review the main use-cases
Last updated
Policy rules can be applied on assets, defects or tasks. For each object type there are different use-cases. See below some of the main use-cases per object below:
Scanning schedule Enso can be connected to customers' scanners and/or use Enso built-in scanners. All of Enso built-in scanners have a default scanning schedule, however the user can replace this default schedule by a self-configured scanning policy. This is especially relevant when you would like to scan only certain assets with specific controls.
New assets handling Scan and notify when new assets are discovered. Helps to surface vulnerabilities of new assets earlier while increasing the team's awareness about changes in the inventory.
Impact classification Classify assets according to their business criticality and make sure efforts are invested in the more sensitive assets first. You can auto-classify assets based on a predefined business logic or simply use Enso's out-of-the-box classification policy.
Tagging Categorizing and labeling assets come in handy in multiple scenarios. It essentially helps to recognize or handle assets differently according to mutual properties. Once the assets are tagged, they can be filtered according to their tags in the inventory or when creating new policy rules.
AppSec routines AppSec programs usually include different repeatable activities. For example, periodic pentesting, security reviews or threat analysis sessions. Some of those activities are done in fixed cadence while other activities are done when specific events occur (product milestones, etc.). Building a policy to generate tasks or Jira tickets on certain assets can help automate such workflows.
Mitigation automation Generating new Jira tickets automatically for high priority defects is a common use-case. To pinpoint relevant defects, we recommend considering the following fields: severity, source (control) and status.
Noise reduction One of the most common challenges for AppSec teams is the massive amounts of findings. That said, usually there's a large portion of irrelevant defects that interrupt focusing on what's really important. Building a policy rule that identifies defects that you don't want to handle and mark them as such, can help mitigating this challenge. To reduce the noise you can either change the status of the defect to dismiss or just lower their severity.