Critical alerts

What’s a Critical Alert?

A critical alert is typically an alert placed at a higher priority level than an alert that comes into the service desk. These alerts are dispatched when there’s an issue that requires immediate attention. Critical alerts, when not responded, can bring an organization’s business process to a standstill, impacting their revenue and bottom line.

How OnPage prioritizes a critical alert:

A high priority message triggers a loud, intrusive, hard to ignore Alert-Until-Read tone. OnPage alerts mimic the pager urgency but also enables a rich, full text message with voice or picture attachments. Designed for critical, time-sensitive situations, the OnPage alert assures the sender that the message has reached its destination and was read. A good use of the high priority feature is to use it for time-sensitive messaging, urgent messaging, medical emergencies, and critical alerts coming in from monitoring tools.

Low Priority Messaging can be regarded as continuous messaging, with replies that go back and forth. Unlike other casual messaging apps, however, users can track the messages that are being sent. Users have the ability to see when the messages is SENT, RECEIVED, and READ. Every reply appears as a new message in your inbox, accompanied by the Alert Tone. Our customers use Low Priority messaging for non-urgent messaging, casual communications, practice updates and non-critical status updates. If you send a Low Priority Message:

• The recipient will not receive the persistent alert tone
• The recipient will not get the big red exclamation mark that signifies High Priority
• The recipient will be able to send back a reply. The sender will know that it is a message.

Critical alerts are reserved for severe issues like complete system failure or an attack. Here are some examples:

• In 2015, nearly 300 million records were leaked and over $1 billion stolen
• Last year, 2500 cases of ransomware occurred and cost $24 million in the US alone
• Companies saw an average of 160 successful cyberattacks per week last year
• Kaspersky Lab reports that the average direct costs of a security breach on a small business is $38,000. This total includes the costs of downtime, lost business opportunities and the professional services small businesses hire to mitigate the security breach.
• Reports show that when a breach occurs, it’s often because an employee left the gate unlatched. Inside employees are the largest culprit of security breaches

How are critical incidents typically handled

To handle the impact of time-sensitive events, IT centers develop robust policies to handle these incidents. The companies develop playbooks and procedures. Yet when an inside employee enables an attack and the breach occurs, rather than receiving a persistent and immediate alert, the on-call engineer simply receives an email or a phone call. Some monitoring systems may also send out text messages. How well do you think an alert through one of these channels performs in getting the attention of the on-call engineer?

Using OnPage critical alerting and playbooks

If an IT organization has intelligently designed their principle of least privilege (POLP) whereby they provide only the access an individual needs to perform their job, the organization will have a strong sense of what privileges are enabled and who has what access. The organization will also have a strong knowledge of what is considered normal and what is considered anomalous behavior on their network.

POLP enables preemption of both malicious and accidental breaches by narrowing the list of possible points of vulnerabilities –which in turn narrows the list of possible users that might be suspected or held accountable. When an alert occurs because someone has improperly accessed a point on the network, OnPage will notify to the right IT professional, accelerating the process of incident triage and resolution.

• Persistent alerting
• Alerting of the right individual rather than alerting to the whole team
• Escalation when the primary responder is not available
• Insight into the site and exact nature of the breach
• Audit trails to enable follow up on response time

• Articulate normal operating parameters and what constitutes anomalies
• Identify the nature of the alert
• Understand network baselines and how to handle situations that deviate from it
• Identify roles and responsibilities within the organization and what must be done when anomalies are detected
• Include contact information
• Design eradication and recovery procedures
• Conduct a post mortem when events occur

After the attack has been alerted to and resolved, it is important to implement a post-mortem to review how well the team performed. As part of the post-mortem, teams should look at how long it took them to recognize the attack; how long it took them to alert to the attack; how long it took them to respond to the attack; and how long it took them to resolve the attack. By knowing these metrics, teams can minimize their Mean Time Til Resolution (MTTR).

Additionally, by reviewing MTTR, teams will have a metric by which they can review their response time to other incidents and see what impeded or improved their response time. Only through acknowledging the importance of this metric and bringing it into the IT wheelhouse, can teams respond effectively.