Cloud Security Policy

Overview

The Cloud Security Policy is a collection of policies, each of which contains rules defining the access or communication channels that should and/or should not be allowed to and from your assets. Together they constitute a baseline against which the configurations of your security controls and other settings are measured giving you an up-to-date picture of how the configuration of your vendor security controls, such as security groups, comply with your cloud security policy. Instances of non-compliance with your cloud security policy are considered violations.

New SecureCloud accounts come with a default Cloud Security Policy consisting of a single policy, allowing https access from the internet to any destination in your cloud. Modify or delete as needed.

Cloud Security Policy Structure

The cloud security policy can contain any number of policies and each policy can contain any number of rules. The components of a rule are:

  • Scope: Each rule has a scope. This is the relationship between the 'from' and 'to' entities (source / destination), where entity is a logical collection of assets based on their properties, similar to Asset Grouping in the Cloud Graph. Scope doesn't specify whether the access should be allowed or blocked. In the cloud security policy, asset properties constituting an entity can be account, virtual network, subnet, region or a single tag key. The tag key entity works a little differently to the other entities; every tag key is considered an entity in itself so if you select tag key, you must specify the desired key. Scope has three possible values:

    • Within each: Access between assets with the same value for the selected asset property. This generic scope will automatically apply to any future additions or changes in the selected asset property's values. See examples.

    • Between any: Access between assets with different values for the selected asset property. This generic scope will automatically apply to any future additions or changes in the selected asset property's values. See examples.

    • Explicit: The 'from' and 'to' asset properties/values are specified.

  • Action: Each rule has an action that specifies whether traffic should be allowed or blocked. There are four possible values:

    • Allow all: All traffic defined by the scope should be allowed.
    • Block all: All traffic defined by the scope should be blocked.
    • Customized allow list: All accesses defined for the scope should all be allowed. Access is explained below.
    • Customized block list: All accesses defined for the scope should all be blocked.

    If Allow all or Block all are specified, there are no additional definitions to be made. If however one of the customized options are specified, then at least one access must be specified as well.

  • Access: An access is a definition of one or more traffic flows and consists of three components - 'From', 'To' and 'Service', all of which can contain multiple values. When one of the customized options is specified for Action, at least one access must be defined. Examples:

    • From: Tier:app, To: Tier:DB, Service: TCP 27017

    • From: CIDR 188.147.22.01/24, To: account:Bank-DC1-apps, service:https,ssh

    • From: Account 'Azure-Central' and Region 'North' to Tags 'Environment:Test' and 'Environment:Dev' and Application:'Sales', Service: Domain-UDP and Domain-TCP, and IMAP

Cloud Security Policy Examples

Example of scope 'Within Each' / Allow List

Rule scope: Within each Virtual Network

Action: allow list

Access: 

  • From: Tier:Web, To: Tier:App, Service: Any

  • From: Tier:App, To: Tier:DB, Service: Any

If there are three virtual networks: vnetA, vnetB, vnetC, this single rule avoids the need to define the three separate rules below and avoids the need to define new rules for additional virtual networks added:

  1. From: Virtual Network: vnetA , To: Virtual Network: vnetA,

    Action: allow list

    Access:

    • From: Tier:Web, To: Tier:App, Service: Any

    • From: Tier:App, To: Tier:DB, Service: Any

  2. From: Virtual Network: vnetB , To: Virtual Network: vnetB,

    Action: allow list

    Access:

    • From: Tier:Web, To: Tier:App, Service: Any

    • From: Tier:App, To: Tier:DB, Service: Any

  3. From: Virtual Network: vnetC , To: Virtual Network: vnetC,

    Action: allow list

    Access:

    • From: Tier:Web, To: Tier:App, Service: Any

    • From: Tier:App, To: Tier:DB, Service: Any

Additional Examples of Scope 'Within each'

Example: Within each region

Applies to:

  • access from any other asset in region 'North' to any asset in region 'North'

  • access from any other asset in region 'South' to any asset in region 'South'

  • and so on..

It does not apply to:

  • access from assets in region 'South' to assets in region 'North'

Example: Within each tag key 'Department'

Applies to:

  • access from any asset with a tag key:value of 'Department:Dept1' to any asset with a tag key:value of 'Department:Dept1'

  • access from any asset with a tag key:value of 'Department:Dept2' to any asset with a tag key:value of 'Department:Dept2'

  • and so on..

It does not apply to:

  • access from assets with a tag key:value of 'Department:Dept1' to assets with a tag key:value of 'Department:Dept2'

  • access from assets with a tag key:value of 'Department: ' (i.e. blank) to assets with a tag key:value of 'Department:Dept2'

Example of scope 'Between Any' / Allow List

Rule scope: Between any tag key 'Environment'

Action: Block all

This single rule avoids the need to define the six separate rules below and avoids the need to define new rules for additional values added for tag key 'Environment', or make changes following changes in existing 'Environment' tag key values:

  1. From: Environment:Dev, To: Environment:Prod, action: block all

  2. From: Environment:Dev, To: Environment:QA, action: block all

  3. From: Environment:Prod, To: Environment:QA, action: block all

  4. From: Environment:Prod, To: Environment:Dev, action: block all

  5. From: Environment:QA, To: Environment:Prod, action: block all

  6. From: Environment:QA, To: Environment:Dev, action: block all

Additional Examples of Scope 'Between Any'

Example: Between any region

Applies to:

  • access from any asset in region 'South' to any asset in region 'North'

  • access from any asset in region 'East' to any asset in region 'North'

  • and so on..

It does not apply to:

  • access from other assets in region 'North' to assets in region 'North'

Example: Between any tag key 'Department'

Applies to:

  • access from any asset with a tag key:value of 'Department:Dept2' to any asset with a tag key:value of 'Department:Dept1'

  • access from any asset with a tag key:value of 'Department:Dept1' to any asset with a tag key:value of 'Department:Dept2'

  • and so on..

It does not apply to:

  • access from assets with a tag key:value of 'Department:Dept2' to assets with a tag key:value of 'Department:Dept2'

  • access from assets with other tag keys such as 'Subdept:Dept2 to assets with a tag key:value of 'Department:Dept2'

Example of scope 'Explicit'

  • Explicit: From 'any region' to region 'North'

    Applies to:

    • access from any asset in region 'South' to any asset in region 'North'

    • access from any asset in region 'East' to any asset in region 'North'

    • and so on..

    It does not apply to:

    • access from any other assets in the monitored cloud networks to assets in region 'South' .

Cloud Security Policy Violations

Every case of an vendor's asset security rule not complying with your cloud security policy is a violation, except when there is no network connectivity and effective connectivity is set to consider network connectivity. If there is a case where the vendor rule complies with one cloud security policy access but does not comply with another, the vendor rule will be in violation of the cloud security policy. Violations may appear in a number of places in SecureCloud, including Dashboard, asset details and Cloud Graph.

If a vendor rule exists that specifies Source=Any, Destination=Any, Service=Any, Action=Deny, then all rules below it are ignored when checking compliance with the cloud security policy.

Example 1:

  • Definitions:

    • SecureCloud policy Policy1 contains a rule Rule1 with an access defined as blocked from RegionA to RegionB.

    • The same SecureCloud policy contains another rule Rule2 with an access defined as allowed from RegionA to RegionB.

    • Asset1 exists in RegionB.

    • Vendor security group SecurityGroup1 contains a rule that allows access to Asset1 from RegionA.

  • Result:

    • One violation exists for Asset1. The SecureCloud rule in violation is Rule1 in Policy1.

Example 2:

  • Definitions:

    • SecureCloud policy Policy1 contains Rule8 with an access defined as allowed from any subnet to Subnet2

    • SecureCloud policy Policy2 contains Rule23 with an access defined as blocked from RegionA to RegionB

    • Asset1 exists in Subnet2 which is in RegionB

    • Vendor security group SecurityGroup1 contains a rule that blocks access from Subnet1 to Subnet2

    • Vendor security group SecurityGroup2 contains a rule that allows access from RegionA to RegionB

  • Result:

    • Two violations exist for Asset1. The SecureCloud rules in violation are Rule8 in Policy1 and Rule23 in Policy2.

What Can I See Here?

All defined policies appear in the list with their name, description and severity. Initially there is a single default policy.

What Can I Do Here?

Add a Policy

  1. Click Add policy.

    The Create Policy window appears.

  2. Enter the policy name and optional description.

  3. Select a severity (High, Medium, or Low). This value represents the default severity for rules in the policy.

  4. Click Create.

    The rules page appears for the new policy

  5. Continue with adding policy rules.

Edit a Policy

  1. Hover over the desired policy and select > Edit policy. The Edit Policy window appears.
  2. Make changes as necessary and click Save.

Delete a Policy

  1. Hover over the desired policy and select > Delete policy. A warning appears.
  2. Click Delete policyto confirm. The policy and all of its rules will be deleted.

How Do I Get Here?

Main Menu > Cloud Security Policy