Что нас может не устраивать? Аналитик не справляется с работой в заданное в SLA время? Извините, но тут не может быть никакой эскалации. Это неприятно, это требует внимания со стороны руководителя дежурной смены, но это ни в коем случае не должно быть причиной эскалации. А вот если масштаб инцидента оказался больше, чем предполагалось изначально? Например, предполагалась утечка 100 записей о клиентах, а потом оказалось, что утекало 100 тысяч или 10 миллионов? Это, безусловно, причина для эскалации, что потребует привлечения внимания более высокого руководства, чем предполагалось изначально и принятия немного иных мер. В данном случае у инцидента еще и приоритет повысится. Но эскалация — это не всегда повышение приоритета. Оно может сопровождать эскалацию, но не обязательно следует за ней.
А что еще нас может не устраивать, что повлечет за собой эскалацию? Допустим вас не устраивает, как проводятся работы над вашим инцидентом. Недавно у меня была история. Потребовалась помощь службы поддержки — и я открыл соответствующий кейс. Мне назначили инженера, который пытался связаться со мной в нерабочее время, о чем я ему и сообщил, попросив позвонить с 10 до 18 по Москве. Он сказал «ОК» и пропал. День его нет, второй, третий, При этом в истории кейса появляются записи, что он никак не может со мной связаться. Ну бывает 🙂 И хотя ситуация была некритичная, я все-таки в какой-то момент эскалировал ее на руководителя дежурной смены, который «дал пинка» моему инженеру и тот быстро разрешил стоящую передо мной задачу. Иными словами, причиной эскалации стало недовольство тем, как разбирался мой инцидент. И никакой приоритет у него не изменялся — просто мне потребовалось как-то обратить внимание на него. Но тут важно отметить, что причиной эскалации стало не просто мое необоснованное желание («я хочу»), а мотивированный запрос с объяснением причин эскалации.
Многие советские детективы начинаются с того, что происходит незначительное происшествие, которое затем раскручивается в нечто более серьезное. Какая-нибудь авария в начале фильма разворачивается в убийство или хищение в особо крупном размере, что требует привлечения больших ресурсов и большего внимания от доблестных сотрудников советской милиции. Вот и в ИБ — если изменились существенные обстоятельства инцидента, может потребоваться его эскалация и, возможно, изменение приоритета. Причем изменение приоритета может произойти и в обратную сторону. Например, СМИ написали про утечку у вас 10 миллионов записей о клиентах со всех регионов, где у вас есть точки присутствия, что привело к установке максимально возможного приоритета для этого инцидента. Но в результате расследование выяснилось, что СМИ немного приукрасили и реальное число утекших записей составило всего 1000 и только из одного региона. Приоритет такого инцидента должен быть снижен, но решение об этом может принять не руководитель дежурной смены, а, например, руководитель SOC/CSIRT или руководитель всей ИБ, что и потребует эскалации, то есть привлечения их внимания.
Что еще? Допустим с личного ноутбука сотрудника по компании стал распространяться вредоносный код, который при этом не поразил большого количества компьютеров в сети. Вроде бы рядовая ситуация, и приоритет не очень высокий. Но так получилось, что этим сотрудником оказался генеральный директор компании (кстати, реальная ситуация). В этом случае может потребоваться эскалация инцидента, чтобы привлечь к нему внимание руководителя ИБ, которому, возможно, придется объясняться перед генеральным директором о произошедшем. Кстати, вместо генерального директора может быть и рядовая секретарша, у которой слишком тесные отношения с генеральным, что ставит ее в немного привилегированное положение и требует (такова уж внутренняя политика) немного иного внимания, чем к рядовым сотрудникам.
Представим, что аналитик SOC получил в работу кейс, но в процессе выясняется, что ему не хватает знаний и кейс выходит за рамки полномочий аналитика. У него нет инструментов для обогащения данных, у него нет доступа к дополнительным инструментам расследования. Что ему остается? Расписаться в собственном бессилии или передать кейс дальше, например, аналитикам следующего уровня (линии)? Второй вариант тоже можно назвать эскалацией, хотя это будет достаточно условно. На мой взгляд это скорее обычный режим работы SOC/CSIRT, чем нечто необычное, что требует привлечения внимания.
При эскалации одной из важнейших задач является обоснование для нее. Я, как, думаю, и многие люди, не всегда объясняю причины своих поступков, считая, что «все же и так очевидно». Вот в эскалации такая фигня не работает — чтобы эскалация прошла успешно, должна быть веская причина. «Я так хочу», «Это же очевидно», «Я же босс» к таковым не относятся. Интересно, но когда пытаешься внятно сформулировать, зачем тебе нужна эскалация, часто получается, что она и не нужна 🙂 Если же верно все-таки обратное, то обоснование для эскалации должно быть бизнес-ориентированным. «Данный инцидент может стать достоянием СМИ и надо подготовиться», «Несмотря на стандартные двое суток на решение данного типа инцидента, нам надо его решить к завтрашнему совету директоров», «По результатам расследования стало известно, что утекло не 1000 записей о клиентах, а 1 миллион записей», «Шифровальщик заразил компьютеры бухгалтерии и они не успевают сдать отчетность в налоговую, что может привести к штрафам» и т.п.
Инициация эскалации не всегда приводит к тому, что она происходит. Исполнитель запроса на эскалацию или иное лицо, обладающее соответствующими полномочиями, может принять решение, что эскалация была излишней и инцидент будет разруливаться в том же режиме. Если эскалация верна, то получивший запрос проводит анализ ситуации и готовит соответствующий план действий, который может быть спущен инициатору запроса, ответственному за кейс или переадресован иным, более подходящим лицам. Главное, помнить, что эскалация — это не жалоба, а нормальный режим работы любой группы расследования инцидентов, который не является какой-либо внештатной ситуацией. Просто она заставляет нас обратить внимание на нечто необычное, неукладывающееся в обычные рамки.
