Security Control Definition

Once you have created a Security Control you need to define how it is identified, the security protocols to which it must adhere, the events that need to be selected to meet these protocols, the severity of the threat posed and the notifications that are generated and to whom they are sent. There are four tabs that are used for the entry of these parameters:

  • Definition - Specifies the name, description, instructions, security area and protocol
  • Event Selection - Specifies the rules which select the security events of importance
  • Classification - Specifies the severity of the threat
  • Notifications - Specifies who should be notified of any threat and the point at which the notification is triggered

Definition

This is the first tab and as such is open by default when you start to define the Security Control. The following parameters can be defined.

  • Name: Enter a name by which this Security Control can be identified within Powertech Event Manager.
  • Description: The entry in this parameter should provide a meaningful insight about this control. For example, what is this control checking? Why is it important? And what could happen if there is a security breach?
  • Treatment Instructions: This describes what the security administrator should do for events raised by this security control. Which are the tasks a reviewer need to do to ensure the events of these control are actually under control? For example, the process of user creation/deletion may have an entry similar to the following: “When a user creation/deletion is detected you have to check if there was a ticket on the HR ticketing system asking for the user creation/deletion. If it does not exist, it may be a security incident.”
  • Security Area: This specifies the general area under which this security control falls. From the drop-down menu select one of the following areas that Powertech Event Manager can support:
  • Administrator Users’ Activity - Any activity relating to the use of administrator user profiles
  • Special Users’ Activity - Any activity relating to the use of special user profiles
  • System Management - Any activity relating to system actions (Create Directory, Delete Audit Log etc.)
  • Users’ Activity -Any activity relating to the use of any user profile
  • Users’ Management - Any activity relating to user actions (Create/Delete profile etc.)
  • Regulations: Specifies the Security Regulations to which this Security Control must adhere. Therefore, if you have an internal regulation that requires you to perform a security check on any user profile being created or deleted, you can select Internal Regulation in this section. Multiple selections can be made for a single security control.
TIP: A full list of all the Security Protocols and Regulations supported by Powertech Event Manager can be found in the document Powertech Event Manager Detailed Scope.

Event Selection

The Event Selection tab allows you to define specific rules which control the flow of information to your security administration team. Put another way, this process allows you to distinguish between the events that are important from the multitude that are just standard information messages.

NOTE: Some audit events should be compulsorily controlled due to security regulations (Public or Internal) and require configuring here.

Click the Event Selection tab to begin the process.

Click ‘+’ next to Selection Rules to add a new rule to this Security Control.

Single Event Rules

The new rule parameters are displayed allowing you to input the selection criteria that control the events reported by this Security Control.

  • Rule Name: Enter a meaningful and specific name for this rule so its purpose can easily be identified within this Security Control. Multiple rules can be set for a single security control. These rules may be based on different criteria and/or assets and event timings. For example, you might want one rule to monitor for all users created on a specific asset during working hours and another rule to monitor for all users deleted outside working hours.
  • Actions to Audit: This parameter is used to select the audit actions that are used by this rule. Click Edit Actions to Audit to display a pop-up window from which the audit actions can be selected.

This window displays a list of all the possible audit actions that are available for monitoring events for this rule. Use the vertical scroll bar to view the full list of actions. Enable an audit action by clicking on the relevant switch. The switch color changes from gray to blue to show that it is enabled.

Enabling a parent action (indicated by a ‘>’ to the left), also enables all the child actions in the group.

Take care to enable only those actions that are relevant to the rule you are creating and the settings you are using otherwise unexpected results may be received.

TIP: To save time scrolling through the entire list of actions each time, you can enter keywords into the Filter search bar at the top of this display. For example, typing Creation into the search bar restricts the returned actions to just those that contain the word ‘Creation’ in their title.

When your selection is complete, click OK. The window closes and the selected audit actions are now displayed in the Actions to Audit parameter.

  • Assets: Select the asset against which you want this rule to run. Use the search bar to enter an asset name. Use the filter search, available from the drop-down menu in the search bar, to be able to enter asset characteristics on which a search can be conducted.
  • Calendar: The calendar parameter defines when this rule is run. You can elect to run the rule either Inside or Outside of the chosen calendar settings. Under normal conditions, the Inside setting uses working hours, Outside would be any time other than working hours. Pre-defined calendars can be selected using the drop-down menu in the Calendar parameter. Click Manage Calendars to open the Manage Calendars window from where you are able to define a new calendar, range sets and exclusion ranges which can then be applied to this rule.
  • Event Filters: These are used to apply defined category rules to the Security Control to allow events that have pre-exisitng rules applied to them at category level. For example, for a Security Control of 'Successful Login - Non-interactive login', the existing rule 'Operator Category is Security Administrators' is already applied as a filter to allow the event to be accepted. Therefore, only administrators logging on to the selected asset will pass through the security control for which the event filter is set. See Categories Management for more information.

Event Repetition Rules

Event Repetition events are events that frequently occur in a given period of time, such as a Denial of Service attack, for example. These types of rules use the same parameters as a Single Event but include additional controls for the management of the repetition behavior. See Single Event Rules for more information on the identical parameters.

Repetition Behavior

An event repetition is determined by a succession of a given amount of similar events in short span of time. Enter the number of times the event must occur in the specified number of minutes (or hours), in order for a repetition event to be triggered.

To prevent the generation of numerous repetition warning being issued, activate the Ignore further repetitions within the next xx minutes setting, specifying the number of minutes over which this should be enforced.

You then decide whether you want to use the Default or Custom set of fields to indicate when a repetition event is occurring. If using the default set of fields, events are considered the same if Operator Name, Source Machine Name, User Name and Object Name have the same value. If using Custom fields, enter the details of these fields, that determine if a repetition event is occurring.

When you start typing data into the Custom Fields text box, entries that match the entered text become available for selection.

Event Summary

When a repetition is found and selected as a security event, a new event is created summarizing the behaviour. These fields allow you to customize the Subaction and Complete Message of the event.

  • Event Action: This is always defined as Event Repetition and cannot be amended.
  • Event Subaction: Use the drop-down menu to select the nature of the event repetition. This could be a DoS or Brute Force Attack, for example. If the Repetition event is not listed, click Add New to define a new event.
  • Complete Message: This field is used to generate the message that is generated whenever this repetition event is triggered. Click to display a list of Event variables that can be used to build the message.

Event Pattern Rules

An event pattern rule consists of two separate rules which normally happen in sequence to create a given event. For example, a User Creation pattern rule may contain two rules; the first being the creation of the user profile, the second being an attempted login to a system with the new profile. By combining the rules you can build a pattern of events that you expect to occur, or more importantly, need to be aware of if one of the named events does not occur as expected.

Use the fields as described in Single Event Rules to create the first and second events expected to occur for the Event Pattern definition. For example, the first event may be User Creation and the second event may comprise of Logon Failure and Successful Login actions. This would detect if a user profile has been created and then attempted to sign-on to the selected asset.

Once the two events have been defined, specific actions can be applied to the rule to determine the specific pattern behavior.

Pattern Behavior

An expected pattern is a sequence of two events. This sequence can tell you there's a problem that needs human validation, or it may be the expected behavior, making the lack of any of the events the cause of the issue.

  • Timespan between events: Set the time period, in minutes or hours, between which the two events are considered to be part of a sequence.
  • Does the order of events matter?
Select Yes if you’d expect the first and second events to occur in the order that they are defined.
 
Select No if the events can occur in any order.
  • When is this pattern selected?
When both events occur: Select this option if both events are required to create the expected event pattern
 
When one of the events is missing: Select this option if you would expect both events to occur but one of the events is missing.
 
When the first event is missing: Select this option if you would expect both events to occur but specifically the first event in the pattern has not occurred.
 
When the second event is missing: Select this option if you would expect both events to occur but specifically the second event in the pattern is missing.
  • What fields should be the same in both events to be considered a pattern?
Enter the details of the fields that should be the same in both events. For example, if the rule was determining User Creation, the Destination Machine Name would need to be the same in both events (i.e. the machine on which the profile was created and the one on which access was attempted.
  • Which one of the following fields should be different in both events to be considered a pattern?
Enter the details of the fields that should be different in both events in order for it to be considered a pattern event.
  • What fields should be crossed in both events to be considered a pattern? These specialist fields determine specific, yet common occurrences of events that must occur in both events to be considered a pattern.
The Affected User in the first event is the Operator in the second one: - This covers the scenario where an operator creates a user profile and then uses that profile to access a machine and change a policy. For example, The user created as a result of the first event, becomes the profile used to logon in the second event.
 
The Destination Workstation in the first event is the Source Workstation in the second one: - This covers scenarios where, for example, an operator remotely changes all of the audit policies on a machine and then logs on to it and deletes all the sensitive files. The machine used in the first event is also used in the second event.
Event Summary

When a repetition is found and selected as a security event, a new event is created summarizing the behaviour. These fields allow you to customize the Subaction and Complete Message of the event.

  • Event Action: This is always defined as Event Pattern and cannot be amended.
  • Event Subaction: Use the drop-down menu to select the nature of the event pattern. This could be a Login Test or Suspicious User Usage. If the Pattern event is not listed, click Add New to define a new event.
  • Complete Message: This field is used to generate the message that is generated whenever this event pattern is triggered. Click to display a list of Event variables that can be used to build the message. The Event variables can be comprised of Event 1, Event 2 and General Pattern Event variables.

Filtering

Event Filters: Event filters are used to ‘fine-tune’ the rule by including or excluding certain conditions in the rule, such as administrators creating new user profiles. Click Edit Filter to open the Edit Filters window.

  • Inclusion Filters: Events are accepted if the criteria specified in any of these filters applies.
  • Exclusion Filters: Events are discarded if the criteria specified in any of these filters applies.

Click either Add Inclusion Filter or Add Exclusion Filter to be able to enter filter criteria.

Whichever option is selected, the New Filter is created under the chosen filter mechanism.

  • Filter name: Enter a unique name by which the event filter is identified
  • Field to evaluate: Use the drop-down menu to select the field which will be part of the inclusion or exclusion filter.

Once the field has been selected, it is displayed on the Event Filter page ready for input of the criteria that will be included or ignored in this rule. In the example below: Any entry of Administrator will be ignored in the User Category event field for this rule. (Selecting None instead of Any would have the opposite effect and no entry of Administrator would be ignored.).

Classification

Security classifications allow you to specify the level at which security events that meet the selection criteria are classified for this security control.

The events filtered by at least one selection rule are classified as Highlighted Events or Threats depending on their potential security impact.

Click the Classification tab to begin the process.

Setting the Default Classification

Set the Default Classification parameters for this Security Control. Only one classification can be made per Security Control so all selected security events in the control must be of the same level of importance, otherwise key events could get overlooked.

Event Classification
  • Set event type to: This setting specifies whether the events that match the selection criteria for this Security Control. Use the toggle switch to select the appropriate setting for this Security Control:
    • Highlight: Events that a security administrator should be looking out for as part of their duties.
    • Threat: Events that are out of the ordinary and could cause a serious risk to your business if they go unchecked.
    • Assign to a reviewer: Use the drop-down menu to assign a user or user group as a reviewer of all events raised by this classification rule. Users and Groups must have already been defined. Click Users and Groups Management to add users and groups as required. See Users and Group Management for more information.
  • Revision Period: The revision period defines the maximum period of time in which the event should be reviewed after it has occurred. The shorter the revision period specified, the more important the Security Control. The following options are available:
    • Daily - The event should be reviewed within 24 hours of its occurrence
    • Weekly - The event should be reviewed within 7 days of its occurrence
    • Fortnightly - The event should be reviewed within 2 weeks of its occurrence
    • Monthly - The event should be reviewed within a month of its occurrence
    • Quarterly - The event should be reviewed within 3 months of its occurrence
    • Biannual - The event should be reviewed within 6 months of its occurrence
    • Annual - The event should be reviewed within 1 year of its occurrence

Adding a New Classification Rule

To create a new classification rule, click the ‘+’ symbol in the Classification Rules heading bar, in the left hand navigation panel.

  • Rule name: Enter a unique name for the new rule
Event Selection

Fields in this sections determine the actions, assets, calendar and filters to be applied to this classification rule.

  • Actions to Audit: Use the Edit Actions to Audit button to select the actions that form this classification rule. The available actions are pre-filtered from the selection rule specified in the Event Selection tab. See Event Selection for more information.
  • Assets: Select, or use the Search option to find, the assets to which this classification rule applies.
  • Calendar: Determine the Calendar to use for this classification rule and whether the rule is active Inside or Outside the time period set by calendar.
  • Event Filters: Select the filters used to fine-tune the rule by determining which conditions are applicable to this rule. See Filtering for more information
Event Classification

See the Event Classification section in Setting the Default Classification for details on these fields.

Order of Classification Rules

Classification rules are run in the sequence order that they are listed, but because threats are far more important than highlighted events, it is not possible to run a highlighted event rule before any rules that are deemed to be a threat, without changing the Event Type from Highlight to Threat.

To change the sequence order of the classification rules, drag and drop a rule into its new position in the list, remembering the rule structure configuration above.

Notifications

The Notifications tab is used to specify email addresses to which real-time notifications are sent regarding any possible threat or security breach.

Click the Notifications tab to begin the process.

Default Notification

In the current version of Powertech Event Manager, there is a single default notification, which sends alerts to specified email addresses. Use the toggle switch to enable the sending of emails through the Default Notification method.

  • Who Should be Notified? - Enter the email address(es) of all the people who should be notified in the event of a security breach or threat being raised as a result of the selection criteria being met in this Security Control. Multiple email addresses can be entered if separated by a comma.

Filters

Filtering can be used, in the same way as it is for Event Selection, to ‘fine-tune’ the point at where a notification is sent. So, for example, you may only want to notify certain people when critical assets are potentially threatened or if an unusual pattern of events begins to unfold on a specific device.

Click Edit Filters to begin assigning filters to this Notification. Both Inclusion and Exclusion filters can be set. See Filtering for more information on how to complete these parameters.

 

Copyright © HelpSystems, LLC.
All trademarks and registered trademarks are the property of their respective owners.
1.0.1 | 201808100902 | August 2018