Setting up customized security rules

The Coronet SecureCloud console comes with a set of built-in security rules to make sure your corporate cloud service is monitored and protected at all time (see the Default security rules guide).

Once you switch from the initial Visibility mode to Protection mode (see the Visibility Mode and Protection Mode guide) you can add and apply your own security rules.

 

Working with security rules

To add a new security rule:

  • Go to CONFIGURERules in the console’s menu
  • Select from the list of rule categories (User access, Device access, etc.)
    This will show you the list of existing rules in this category, their status (e.g. built-in, disabled, high-priority, etc.) and the details of the currently highlighted rule.
  • Click the Add [rule category] Rule button

Once added, the new rule is added to the list of rules in this category.
You can duplicate, delete, or disable the rule by clicking the three-dots icon () at the right-hand side of each rule block (note that Built-in rules can be disabled but they cannot be deleted).

To edit the rule, click the rule in the list, then point to the pencil icon at the top-right corner of the section you would like to edit. When done editing, click the green check icon at the top-right corner of the edited section.

 

General security rule structure and functionality

All rules follow a similar structure:

  1. Rule name: We recommend using a name that reflects the use case or scenario you would like to monitor and mitigate. This will assist you when you look at events that were triggered by this rule.
  2. High Priority Rule: this checkbox is used to mark rules that should get more attention from your team. The Events screen has a Priority filter that allows you to focus on events of high priority rules.
  3. Scopes: The scope parts of the rule define the context in which the rule took place – specific users or user groups, specific locations, specific services, etc.
  4. Trigger: This is the actual risks that the rule would like to monitor and mitigate.
    Often, rule triggers allow you to play with their sensitivity layer, to best fit your risk/alerts balance.
  5. Actions: The action parts describe what should be done if the rule is triggered. Typical actions include notifying the end-user, sending notification emails to the admin team, and taking preventive measures.

 

If the Coronet SecureCloud system detects that all the conditions of the rule (i.e. its trigger and scope definitions) have been fulfilled, the rule will be triggered, an event record will be added to the Console (you can see it at INVESTIGATE à Events), and all defined actions will take place.

User Access security rules

These rules refer to abnormal user behavior during service login, including access from “risky areas” (which you define in the Rule scopes section – see the Configuring rule scopes guide), abnormal login patterns such as impossible travel and sudden activity in an inactive account, and multiple failed login attempts.

You can narrow the context (scope) of your rule to specific service, users or user groups.

If abnormal behavior was detected, you may terminate the user’s session and require her to sign in again to the service or suspend her service account until you figure out what is the problem.

You can also get immediate or daily email notifications.

 

Device Access security rules

These rules refer to vulnerabilities in your users’ devices, including older OS, missing device password protection, rooted or jailbroken devices, disks that have no encryption, disabled Anti-virus or Firewall, etc.

You can narrow the context (scope) of your rule to specific users or user groups. You can also define to trigger the rule only if the user is at some specific location (e.g. outside the US, or in China) you define specific locations in the Rule scopes section – see the Configuring rule scopes guide.

If a vulnerable device was detected, you may alert the user, or – if you fear the vulnerability poses a risk to your corporate cloud services – suspend the user’s access to corporate services.

You can also get immediate or daily email notifications.

 

Network Access by List security rules

These rules allow you to define white lists and black lists of Wi-Fi networks to which your users can connect to, or, more specifically, from which your users can access your corporate cloud services.
You can define the networks by security level or by network name (SSID).
You may also tag your frequently-used networks (like Office-employees, Office-guests, Public-transportation, etc.) in the Rule scopes section (see the Configuring rule scopes guide) and define the white/black lists using those tags.  
Typical use cases include preventing access to corporate cloud services from open (or WEP) networks, and requiring users to use secure corporate networks while they are at the office.

You can narrow the context (scope) of your rule to specific users or user groups, to device type – setting different rules for laptops and for smartphones, or you can define to trigger the rule only if the user is at some specific location (e.g. open networks outside the US, or in China). You define specific locations in the Rule scopes section (see the Configuring rule scopes guide).

If a user connected to a non-compliant network, you may alert the user, or – if you fear the vulnerable network might pose a risk to your corporate cloud services – suspend the user’s access to corporate services, until he switches to a compliant network.

You can also get immediate or daily email notifications.

 

Network Access by Threat security rules

These rules allow you to prevent users from connecting to risky Wi-Fi networks, or, more specifically, to prevent them from accessing your corporate cloud services from a risky network.

The Coronet client continuously monitors the networks your users connect to, looking for malicious activities on these networks, and evaluates their threat level.

You can narrow the context (scope) of your rule to specific users or user groups, to device type – setting different rules for laptops and for smartphones, or you can define to trigger the rule only if the user is at some specific location (e.g. risky networks outside the US, or in China). You define specific locations in the Rule scopes section (see the Configuring rule scopes guide).

If a user connected to a non-compliant network, you may alert the user, or – if you fear the vulnerable network might pose a risk to your corporate cloud services – suspend the user’s access to corporate services, until he switches to a compliant network.

You can also get immediate or daily email notifications.

 

Service activity security rules

These rules refer to abnormal user behavior after he already connected to your corporate cloud service, including admin activity from outside your corporate IP range (which you define in the Rule scopes section – see the Configuring rule scopes guide), abnormal burst of file download, and sudden activity in a dormant account.

You can narrow the context (scope) of your rule to specific service, users or user groups.

If abnormal behavior was detected, you may terminate the user’s session and require her to sign in again to the service or suspend her service account until you figure out what is the problem.

You can also get immediate or daily email notifications.

 

Service threats security rules

These rules refer to threats on your corporate cloud services. Specifically, it refers to the spread of ransomware and malware in your cloud file storage.

You can narrow the context (scope) of your rule to specific service, users or user groups.

If a risk was detected on one of your user accounts, you may terminate this user’s session and require her to sign in again to the service or suspend her service account until you figure out what is the problem.

You can also get immediate or daily email notifications.

 

DLP by File security rules

These rules allow you to monitor the sharing of sensitive types of files (like certificates, source code, general documents, or any other type you would like to track), with unauthorized targets to prevent data leakage.

You can narrow the context (scope) of your rule to specific service.
You can also define by whom and to whom files can or cannot be shared. For this you can use specific users, user groups, or domains.
You may also tag your “Collaborators” – frequently-used users, user groups and domain (like Internal-employees, Sales, 3rd-party partners, etc.) in the Rule scopes section (see the Configuring rule scopes guide) and define the sharing rules using those tags.  

If an unauthorized sharing of sensitive file in your cloud file storage is detected, you may notify the file editor, or restrict file’s collaboration - remove the shared link that was created for this file, restrict sharing to users on your domain, or remove all sharing of this file.

You can also get immediate or daily email notifications.

 

DLP by Content security rules

These rules allow you to improve your compliancy and detect the presence of sensitive data in the files in your cloud storage like Personally Identifiable Information (PII), Payment Card Information (PCI), Protected Health Information (PHI), or files that contain any keyword you would like to track.

You can narrow the context (scope) of your rule to specific service.

If a file with sensitive data was detected on your cloud file storage is detected, you may notify the file editor, or restrict file’s collaboration to mitigate leakage of sensitive data - remove the shared link that was created for this file, restrict sharing to users on your domain, or remove all sharing of this file.

You can also get immediate or daily email notifications.

0 out of 0 found this helpful

Comments

0 comments

Please sign in to leave a comment.