Advanced Acceptance Rules for Risks

Finely control and automate risk acceptance in our risk management system

What are advanced acceptance rules for risks?

Not all risks are threatening, in fact, some risks are acceptable. Port 80 and port 443 are frequently open by design for any webserver. A timestamp disclosure in a piece of javascript may not matter at all. It's in these cases that you might want to mark a risk as acceptable.

HostedScan provides two ways of marking a risk as acceptable:

  1. You can accept a specific risk for a specific target. This is the easiest and simplest way to accept a risk.
  2. You can craft a condition that spans across targets, across risks, to specify a whole class of risks as acceptable.

This second case is where advanced acceptance rules are created. These rules let you control the fine-grained criteria for when a risk might be accepted, or even automatically accept potential risks that may be discovered so long as they meet your criteria.

Example advanced acceptance rules for risks

To get an idea of when you might want to do this, here are some good examples we have seen:

  • Accept ephermal open port risks generated on a load balancer
  • Automatically accept ports 80 and 443 on any target tagged as a webserver
  • Automatically accept low threat risks generated by a particular scanner as not priority
  • Accept certain instances of a cookie having a less than ideal configuration

How to setup an advanced acceptance rule for risks

  1. 01

    Choose a risk to start crafting a rule

    Visit the risks page and click the Accept Risk button.

    Step 1. Install Selenium Extension and Record
  2. 02

    Accept risk, or expand editor

    With the accept risk rule editor, you have a choice to make:

    1. Accept the current risk and target pair.
    2. Expand the editor to create an advanced rule.

    If you're fine with choice one, hit the Accept button. If you would like to do something more advanced expand the Advanced Rule Editor section.

    Step 2. Upload Selenium script and associate with Target.
  3. 04

    Understanding the acceptance conditions

    The code editor allows crafting any arbitrary query to match against your total set of risks. The query is structured in a JSON format. The query is composed of Mongoose like operators, formatted similarly to a mongoose query.

    Try these three steps to familarize yourself

    1. Click on the matched risk in the left hand pane to expand it and view the various properties you can match against.
    2. Click on one of properties in the value of one of the properties, like MEDIUM for the threat level. This will be automatically added the property and value as a condition in the editor.
    3. Modify the query in the editor to use an operation, in this case we have added the $in operator and chosen two values
    Click New Scan
  4. 03

    Craft a risk acceptance rule

    With advanced rule editor open you will see a couple of options:

    1. On the top row Edit buttons appear next to the risk and target
    2. On the left side of the pane, a code editor is populated with the specific risk definition and target ids corresponding to the current risk and target selected.
    3. On the right side of the pane, a list of risks that match the criteria in the editor pane is shown.

    The edit buttons along the top row help to quickly change the risk selected, and the targets selected. Try using these buttons, and see how the code in the editor changes, along with the Matched Risks list.

    Click New Scan
  5. 04

    Operators the acceptance condition rule accepts

    The operators roughly match what is available for MongoDB queries

    The following operators are available to use for writing a query to match risks for acceptances:

    OperatorTypeDescription
    $allarrayrequires all values in the array to be values in the property as well. Used on properties that are also an array. { "$all": ["prod", "webserver"] }
    $andarrayrequires an array of expressions to all be true
    $elemMatchobjecttakes an expression and checks that an element on the property matches the expression. I.e. { "$elemMatch": { "port": } }
    $eqanythe property matched equals the value in the query
    $existsbooleanthe property checked needs to exist if "true", otherwise reject values that do not exist using "false"
    $gtnumber or stringthe property checked needs to be greater than the value in the query
    $gtenumber or stringthe property checked needs to be greater than or equal to the value in the query
    $inarraythe property matched needs to be one of the values $in the array for the query
    $ltnumber or stringthe property checked needs to be less than the value in the query
    $ltenumber or stringthe property checked needs to be less than or equal to the value in the query
    $modarraythe modulus of the property is equal to the value. I.e. [4, 0] means "the property modulus 4 equals 0"
    $neanythe property matched does not equal the value in the query
    $ninarrayopposite of $in, the property matched must not be one of the values in the array for the query.
    $norarrayopposite of OR: { $nor: [{ _id: "12345" }, { _id: "67890" }] }
    $notobjectNot a given expression. I.e. { "$not": { "$size": 3 } }
    $orarrayOR array of expressions
    $sizenumberthe property array matches the length specified in the value in the query
    $regexstring or regular expressionthe property matches the given regular expression

Sign up to get started

HostedScan is 100% read-only, and will never make any modifications to your servers.

Trusted by these companies and 1000s more