Если вас взломали, то это еще не значит, что вам нельзя помочь!

Если вас взломали, то это еще не значит, что вам нельзя помочь!
Вчера Group-IB выпустила инструкцию по реагированию на инциденты, связанные с системами дистанционного банковского обслуживания, созданную для обучения основам реагирования на случаи мошенничества в системах интернет-банкинга и нацелен на минимизацию рисков при подобных инцидентах.Мне посчастливилось быть рецензентом этого документа и поэтому я решил про него написать. Но не про сам документ, а про его область применения.

В Facebook началось активное обсуждение инструкции и практически все критические замечания скатываются к двум вещам - бизнес встанет и рекомендации слишком неконкретны и с инцидентами не позволяют бороться. Позволяю себе прокомментировать оба момента. Для начала, советую если не прослушать мой курс по управлению инцидентами (ближайшая дата - 23 ноября в Москве ), то хотя бы посмотреть презентацию с этого курса. Вопросы реагирования на инциденты и сбора доказательств - это 5-я часть презентации. Но перед ней есть еще 4 части, которыми нельзя пренебрегать.

Возьмем жизненный цикл инцидента, как его Алексей Волков описал . То, о чем говорит инструкция Group-IB, - это 5-й или даже 6-й этап. Не первый, не второй и даже не 4-й. Тут поздно пить Боржоми и корить себя, что в компании не выстроена система защиты (а у многих клиентов банков - целевой аудитории инструкции - это так). Тут надо либо забить болт на возврат денег, либо идти в суд и правоохранительные органы. Но для этого надо знать, с чем идти. Инструкция и говорит про это.

Мне можно возразить, что многие вещи в инструкции не описаны. Во-первых, это не финальный пошаговый документ "взял и сделал". В введении написано, что его цель - повысить осведомленность. Во-вторых, в том же введении написано, что инструкция может выступать основой для разработки собственных документов. Очевидно, что в 37-ми страницах сложно рассказать все. Там только вопрос обесточивания (п.2 мероприятий) можно раскрыть на пару страниц. Ведь свособ обесточивания зависит от множества факторов. Например, есть у ПК ИБП или нет. А если есть, то мы говорим о ПК или лэптопе? А если лэптоп, то чей? У Lenovo, например, вытаскивание аккумуляторной батареи даже при наличии шнура питания приводит к мгновенному отключение лэптопа, а у Apple MacBook - нет. У него надо и батарею и шнур вынимать. А что делать с сетевым оборудованием? А с планшетником iPad? Кто-нибудь знает как аккумулятор у iPad вытащить? Вопросов немало. И так по многим пунктам.

Значит ли это, что документ плохой? Нет. Просто, чтобы расследовать инциденты, реагировать на них, необходимо иметь некоторую квалификацию. И получать ее надо до появления инцидентов, а не после и не во время.

Другой вопрос связан с остановкой бизнеса, которая происходит, если выполнить  все требования по отключение, копированию и т.д. Надо понимать (в презентации это есть), что существует две стратегии управления инцидентами. Одна - найти причину и устранить ее, возвратив систему в предатакованное состояние как можно скорее. Это "айтишный" подход. А есть второй подход - найти преступника и покарать его. В первом ни о каком возврате денег и речи не идет (хотя иногда на семинарах мне рассказывают о том, что в банке создается "группа на выезд" из мальчиков-шкафов, которые выбивают деньги своими методами). Во втором на возврат денег есть надежда. При условии возбуждения дела и доведения его до конца, конечно. Но инструкций по тому, как прием заявления о возбуждении дела успешным на 100% не существует ;-)

Стоило ли все эти ограничения и неопределенности описать в документе? Непростой вопрос. Стоило ли раскрыть, что расследование инцидента - это только часть процесса управления инцидентами? Тоже непростой ;-) В преамбуле написано, что документ говорит только о реагировании и ни о чем больше. Видимо не все читают введение, сразу переходя к пошаговым рекомендациям. От этого и происходит недопонимание и критика. Но это не значит, что на нее не надо реагировать. Возможно кто-то возьмется и напишет инструкцию по тому, как создать CSIRT, как обрабатывать инциденты, как эскалировать их и приоритезировать... Не исключаю, что такие документы появятся. Свято место пусто не бывает, а требования 382-П и ПП-584 в части наличия методик выявления и реагирования на инциденты никто не отменит.

Сама инструкция может загружена отсюда...
Alt text

Цифровые следы - ваша слабость, и хакеры это знают.

Подпишитесь и узнайте, как их замести!