1.0 Purpose
The purpose is to detect events, analyse them and determine an appropriate control action.This is to ensure that:
- Operational activities are performed as required and scheduled
- Operations are monitored, measured, reported and remediated
- All significant changes of information security is detected
- Appropriate control actions are determined for events and these are communicated to the appropriate
functions. - Provide the trigger, or entry point, for the execution of service operation processes and operations management activities.
2.0 Scope
The scope includes detection and management of all critical services and IT infrastructure in XXX. The scope predominantly includes, but not limited to the following infrastructure and any services provided via these.
- Servers
- Desktops/ Laptops
- Applications
- Databases
- Backup
- Storage
- Network Devices
- Security Devices
3.0 Process
3.1 Event Generation
- Requirements for events generation shall be established based on a risk assessment exercise.
- Systems and network infrastructure shall have the capability to capture and store security events based on the business / legal / regulatory / security requirements.
- Adequate and appropriate logging shall be enforced to ensure that security events / details related to the user / system activity are maintained.
3.2 Fault Logging
- Faults reported by Staff / Users or through an automated process related to problems with technology resources shall be logged, maintained and action taken by XXX
- Automated real-time alerts when faults / errors occur shall be enabled for infrastructure where feasible and required. Restricted or confidential information shall be masked from logging in the logs.
3.3 Contents of Audit Trails / Records
- Requirements for Audit Trails and Records shall be established based on a risk assessment exercise.
- Systems and network infrastructure shall have the capability to capture and store Audit Trails / Records based on the business / legal / regulatory / security requirements.
- The audit trail shall include sufficient information to establish ‘what activity occurred when and who (or what) caused them’.
3.4 Audit Log Reviews
- Audit trails shall be monitored and reviewed to detect suspicious or malicious activities and noncompliance to policies.
- Any activity that falls into these categories shall be investigated and the results of this analysis shall be recorded.
3.5 Time Synchronization
The time for all devices shall be configured to be synced / retrieve time from a centralized source to establish the time frames of the event generated / performed within the IT systems and infrastructure.
3.6 Audit Trail Security
- Access to audit logs shall be controlled.
- Audit logs shall be protected from intentional or unintentional deletion or modification.
- Adequate segregation of duties between staff performing the administration / review of audit trails and operational activities shall be enforced.
3.7 Log Rotation and Storage / Archiving
Logs shall be backed-up or archived regularly to a log management system or media to prevent alterations based on the business / legal / regulatory requirements and shall be stored in a physically secure environment.
3.8 Monitoring and Log Review
- Regular monitoring and review of audit logs shall be implemented to detect any suspicious activities / potential breach such as recurring failed logon attempts.
- Information security events detected because of the monitoring and review procedures shall be reported as stipulated by the XXX’s incident management policy.
3.9 Event Management Inputs & Outputs
3.9.1 Process Main Inputs
Alerts and events generated by the monitoring tools. While designing event management process, decision is taken on events need to be generated and how this can be done.
3.9.2 Process Main Outputs
3.9.2.1 Managed Events
Each type of event trigger will initiate actions prior to closure.
- Informational events do not require any actions to be taken
- Warnings are used to notify the appropriate teams/ processes so that corresponding actions can be
taken - Exceptional events get triggered when a service or application fails and when a CI doesn’t function
normally.
3.9.2.2 Trigger to incident management
For those incidents that arise out of Exception events, the monitoring group assigns them to the appropriate resolver group in and informs the stakeholders and the Incident Manager .
3.9.2.3 Trigger to availability and capacity management
As a part of preventive and corrective actions taken to resolve exceptions which caused incidents,Availability and/or Capacity Management processes get triggered.
3.10 Define event logging criteria
- XXX Information security manager will define and identify the following:
- Identify and document the criteria for logging events considering risk and performance impact;
- Identify the event logging thresholds; and
- Define rules to report threshold breaches and event conditions.
3.11 Define what needs to be monitored
- XXX IS manager prepares a list of infrastructure assets that need to be monitored based on service criticality.
- Procedure documents are created to log events based on the rules defined.
- The duration for retention of event logs to meet legal/regulatory requirements and assist future investigations, is also defined at this stage.
3.12 Detect, filter events and create event logs
<Name the tool you are using>are monitoring tools which trigger the event management process. The monitoring tools are configured to monitor the critical and non-critical applications and servers. In the course of monitoring, three different types of events are generated: • Informational • Warning • Exceptional
3.13 Manual monitoring
Manual monitoring (wherever monitoring tools are not configured) is done for certain applications or servers on continuous basis in order to capture the events.
3.14 Gather monitoring data
The IS manager gathers the entire data with regard to manual monitoring for consolidation purpose.
3.15 Manual consolidation of events
Based on the Events occurred through manual monitoring, the IS Manager does manual consolidation.
3.16 Trigger alerts
Whenever an event occurs, the monitoring tools generate alert notifications. Separate monitoring tools are
configured to generate alerts for critical and non-critical systems
3.17 Correlate events
- All the events arising out of monitoring tools (for both critical and non-critical applications and servers) and manual monitoring are correlated.
- The decision on the significance and what actions need to be taken to deal with the events based on business rules is determined as a part of correlation.
- Correlation will take into account previous occurrences of the similar or related events, the CIs involved, component involvement in the event to arrive at the decision.
3.18 Enrichment process
- Event Management tool/team uses industry standard activities such as event correlation, suppression and
aggregation; collectively known as “Event Enrichment”: - Event Suppression: Event suppression is about ignoring events that are generated due to a higher-level
event, thus significantly reducing the number of events that the monitoring team will handle. - Event Correlation: The event correlation activity automatically clears active and related events,
resulting in monitoring staff not having to manually clear all the related events. - Event Aggregation: Event aggregation activity, also known as event de-duplication, is where duplicates
of the same event are merged.
3.19 Type of event
Based on the event type ,XXX monitoring teams will transfer to the respective resolver groups. Events can be classified into:
3.19.1 Informational:
- An Informational event refers to an event which does not require any action. These events are the results of status checks of devices or services or confirmation of an activity.
- As the incidents created through the informational events do not affect the service, the Monitoring Group closes these incidents with “Status Reason” as “No action required”.
3.19.2 Warning:
- Warnings are generated when a service or device is approaching a predefined threshold. These are used to notify the appropriate person, process or tool so that corresponding action can be taken.
- As the incidents created through warnings may or may not impact the service, the Monitoring Group alerts the respective Resolver Group for appropriate action.
3.19.3 Exception:
An Exceptional event gets triggered in case an application service fails, or configuration item does not function normally. They may represent total failure, impaired functionality or degraded performance.
3.20 Inform the right resolver group
For those incidents that arise out of exception events, the monitoring group assigns them to the appropriate resolver group in service desk and informs the stakeholders/ incident manager.
3.21 Initiate preventive action
The Resolver Group will take the appropriate actions to prevent incidents from occurring. The action taken may trigger the availability and/or capacity management processes.
3.22 Update event log
- The preventive action initiated by the Resolver Group may or may not be effective.
- If it is not effective treat the event as an Incident and trigger the predefined Incident Management process.
- If the type of incident is either an exception or the actions taken in response to the warning event are
not effective, then the predefined Incident Management process is triggered. - The outcome of Incident Management may trigger Problem Management or Change Management. The
output from all this process will be checked for effectiveness. - If the action taken is effective, the event ticket is updated with actions taken
3.23 Close the event
The event related incident will be updated and closed
