Как не довести до форензики и что делать, если этого не избежать

Подводка ведущего

Итак, коллеги, а мы с вами двигаемся дальше. Обычно получается такая ситуация, что дыма без огня не бывает. Но на самом деле, когда горит, тушить уже поздно. В целом у нас с ИБ ситуация примерно такая же. Итак, как не доводить до пожара и что делать, если все-таки он произошел? Об этом расскажет наш следующий спикер Константин Титков. Давайте поддержим его аплодисментами.

Константин, вот кликер. Перелистывай слайды вот сюда. А вот микрофон включен.

Доклад и вопросы

Спасибо. Коллеги, здравствуйте. Наши организаторы разумно чередуют доклады разного характера. Я фактически продолжил логический доклад, который до этого Никита Вьюгин рассказывал. Дам вам много инструментов, которые вам могут пригодиться при общении с вашим руководством, с владельцами бизнеса, с клиентами. Поэтому, пожалуйста, не стесняйтесь фотографировать, записывать, подсаживаться ближе, если, конечно, у вас не суперобъектив. Иначе можете много упустить. В конце будут ссылки на материалы с QR-кодами. Рекомендую сфотографировать, унести с собой. Так, мы будем говорить о том, что делать, если все те подготовительные мероприятия по EDR, антивирусам, межсетевому экранированию не дали должного результата, и у вас реализовался риск кибербезопасности, ваша инфраструктура зашифрована, данные украдены или просто все вайпнули.

Что будем с этим делать? Два слова обо мне. Я руковожу центром кибербезопасности дочерних компаний «Газпромбанка». Также являюсь амбассадором «Кибердома», то есть помогаю важную информацию о кибербезопасности доводить до российского бизнеса. О чем сегодня пойдет речь? Что не так с нашими типовыми IT-планами реагирования на инциденты? Какие экстренные действия можно предпринять? Кто чем может помочь? Забегая вперед, конечно же, компания, которая качественно умеет в DFIR. Этапы реагирования на инцидент, что делать после него, специфика при утечке персданных и самое главное, что может бизнес делать заранее, чтобы быстрее восстановиться и было не так больно.

Несколько примеров, которые имели место буквально в июле этого года. Крупный федеральный производитель напитков, сеть магазинов. Поражение вирусом-шифровальщиком, остановка отгрузки, остановка продаж. Что сделали клиенты? Клиенты пошли за угол в другой магазин, купили все там. Там им выдали карту лояльности, сказали, приходите к нам еще, мы вам еще продадим. То же самое с федеральной сетью аптек. Прямая потеря клиентов. Это только вершина айсберга. Крупная авиакомпания восстанавливалась. Через две недели читаю новость. Мы до сих пор продолжаем осуществлять расчет количества топлива для заправки наших самолетов не с помощью специального программного обеспечения, а на основе статистики расхода топлива на рейсах по аналогичным направлениям за последние годы. То есть что можно из этого вынести? Не весь бизнес удалось восстановить даже спустя две недели.

Двигаемся дальше. А собственно, что бизнес, подвергшийся шифрованию или вайпу, пытается делать в первую очередь? Пытается восстановиться, восстановить основные процессы. При этом забывают найти злоумышленника, как он попал в систему, все его точки закрепления, туннели, закладки, веб-шеллы, скомпрометированные учетные записи для удаленного доступа, созданные учетные записи для удаленного доступа, которые маскируют под технологические и так далее. Вот пытаются что-то восстанавливать, злоумышленники это смотрят, удаляют, уничтожают, видят безуспешность действий, повышают стоимость выкупа. Ну, если они финансово мотивированы. Хотя в первую очередь, конечно, надо же сначала злоумышленника из инфраструктуры выгнать и только потом ее чинить и поднимать.

То есть IT-инцидент. Обычно у нас что? Сбой программы. Разовый или повторяющийся. Сбой аппаратуры. Человеческая ошибка. Иначе говоря, косяк. Тот что-то не там ввел, удалил, сломал. Мы восстанавливаем из бэкапа, меняем аппаратуру, откатываем версию программного обеспечения, обращаемся в техподдержку. У нас для этого есть персонал, потому что это ожидаемые инциденты, мы ждем, что они произойдут. Мы для этого сотрудников обучаем, мы для этого закупаем техническую поддержку, у нас есть инструкции по эксплуатации и так далее, даже какие-то планы восстановления. Даже бэкапы. Может быть даже среди вас есть те, кто бэкапы хоть раз пробовал восстанавливать и проверять, что это работает.

Если вы это не делали, пожалуйста, сделайте, это крайне важно. Как та история с GitHub, когда они легли, у них было 6 бэкапов, они их не смогли поднять. Окей, что такое ИБ-инцидент? Это целенаправленное вредоносное воздействие на вашу инфраструктуру, всю целиком и любой ее элемент, на ваш персонал, на ваших работников, причем адаптивно, с учетом того, как вы пытаетесь сопротивляться, ее восстанавливать. И если правильное действие в этой ситуации – это работа по заранее разработанному плану реагирования на киберинцидент, которая составляется из предположения, что вот мы в понедельник пришли на работу, и все, что нам с вами доступно, и то, что у нас телефон в кармане, и все, что было выключено, а все, что было включено, считайте, что у вас недоступно.

Что вы будете делать, и как долго вы будете восстанавливать всю инфраструктуру, данные и процессы? Ну, на самом деле, по факту, обычно все идет сначала, время уходит на панику. То есть IT-служба пытается менять пароли, что-то пытаться восстанавливать из бэкапов, диски с резервными копиями подключаются в зараженную инфраструктуру, злоумышленники, конечно, это ждут, и эти резервные копии с этих подключенных дисков что? Удаляют. Отлично. И через час, два, три, день, я знаю случаи, на третий день приходит осознание, что мы делаем что-то не так, что мы время, силы и деньги потратили впустую, и нам надо реагировать на инцидент, то есть проводить DFIR, Digital Forensic Incident Response, а не просто пытаться побороть это как IT-сбой.

Ну, обычно это происходит когда? Пятница, праздники, выходные, иногда в четверг последнее время стало происходить. Почему? Потому что шифровальщику или вайперу нужно время, чтобы всю инфраструктуру уничтожить. Это операции записи, они требуют времени, чтобы вы им по возможности не помешали. И здесь очень важно иметь телефоны работников, чтобы их вызвать на работу, отозвать с дачи, с пикника, из отпуска, из командировки. У вас же есть телефоны родственников работников, чтобы до них дозвониться в выходной день, в распечатанном виде на бумаге? И рассчитывать надо на все те наработки, которые в компании сделаны заранее. Потому что только они позволят: а) восстановиться, б) сделать это максимально быстро.

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

Собственно, цель рекомендации – дать понимание, что надо делать, что нужно сделать заранее, чтобы иметь возможность это сделать, и понимание того, что надо действовать, причем быстро. Описываем, как это могло произойти, основные векторы проникновения, чтобы вы могли довести до клиента, до владельца бизнеса, до генерального директора, то, собственно, чем, если не заниматься, то вырастет вероятность этого печального события. Рассматриваем вопрос, платить ли выкуп. Если в двух словах мы помним, что шифровальщик – это программа, если вы будете пытаться выкупить у злоумышленников ключи расшифрования, они, во-первых, могут не сработать, потому что злоумышленникам важно зашифровать вашу инфраструктуру, а расшифровать – это для них вторичная задача, они могли это не протестировать, это во-первых. Во-вторых, вы можете просто не получить в обмен на деньги ключи шифрования, особенно будучи в зоне.ru, российской компанией и так далее.

И надо понимать, что ваш расчетный банк может вам не то что не помочь, а отказаться проводить платеж в адрес злоумышленников по соображениям противодействия отмыванию денег и финансированию терроризма. И самое худшее, если вы все-таки умудритесь этот платеж провести, то он впоследствии может быть признан как раз как финансирование терроризма и со всеми печальными последствиями для всех, кто в этом проведении платежа участвовал. Собственно, основные, тут только верхушка айсберга, экстренные действия. Это проверить операции в ДБО. Ведь, конечно же, у вашего бухгалтера есть распечатка с адресами, номерами телефонов, кому звонить, с какими данными, чтобы сверить платежки, которые были направлены, но, возможно, еще не были исполнены. Может быть, там есть злоумышленные, которые можно еще отменить и деньги вернуть.

Не выключать, не перезагружать технику, чтобы сохранить forensic-данные в памяти. Изолировать ценное, в первую очередь, систему резервных копирований и бэкапы. Снять снапшоты с виртуалок, если это еще возможно, система виртуализации не разрушена. Изучить исходящий трафик, чтобы понять, что вас скачали, украли, сделать предположение об утечке данных. Рассмотреть сетевую изоляцию компании в целом или каких-то сегментов. Позаботиться о режиме работы персонала, поскольку компания теперь переходит в режим работы 24 на 7 и, скорее всего, на несколько дней, а может быть, недель. HR — позаботиться о том, как они будут оплачивать переработки, как они это будут проводить. PR — как они будут взаимодействовать с регулятором, с клиентами и с прессой, желательно имея заранее подготовленные наработки пресс-релизов.

IT — откуда они будут восстанавливаться и кого из подрядчиков будут привлекать в помощь в качестве дополнительных рук системных администраторов и на какое железо или в какое облако они это будут делать, ИБ — какую компанию экспертов по DFIR они будут привлекать, ну и так далее. Собственно, там же расписаны роли. Каждая может из рекомендаций свой кусочек выкражить и сделать подготовительную домашнюю работу заранее. Касательно помощи, да, конечно, мы говорим про компании, которые умеют в DFIR. Там есть рекомендации по выбору компании, выбору режима проведения. Понятно, вы договариваетесь о количестве экспертов, дате время выезда, адрес, контакты, встреча, пропуска, парковка, установочная встреча, планирование. Что мы хотим?

Мы, например, хотим не просто расследовать, но и привлечь к ответственности? Или мы хотим расследовать и по возможности не придать огласки? Привлечь к ответственности, не придать огласки? Сложно сочетаемые между собой истории. Эксперты это вам подсветят. Анализ, собственно, скомпрометированных узлов, выявление всех точек входа, анализ дисков, и так далее, и так далее, и так далее, зачистка, и только потом вы занимаетесь восстановлением. Понятно, что вы заинтересованы восстановить компанию как можно быстрее, мы должны экономить время, надо понимать, сколько экспертов в DFIR будет работать, и важно, чтобы вы могли обеспечить такой же синхронный режим работы ваших экспертов.

Иначе они будут сидеть, ждать, пока вы проснетесь на работу, придете, будут простаивать. Важно ли говорить, что всем субъектам КИИ обязательно в первую очередь нужно обращаться в ГосСОПКА или в аккредитованный центр ГосСОПКА, или в НКЦКИ. Что приготовить к прибытию эксперта? Это и рабочее место, и коммуникации вне пораженной инфраструктуры. Потому что иначе злоумышленники будут читать вашу почту, ваш мессенджер, ваши личные мессенджеры, если вы логинились в них с техникой, которая подключена к вашей инфраструктуре, будут читать и принимать меры, как вам помешать с учетом того, что вы готовитесь сделать. Более того, они скриншоты вашей переписки будут выкладывать в интернет и всячески будут над вами глумиться. Поэтому лучше коммуникации сразу вычислять вне инфраструктуры.

Про синхронный режим мы говорили. Отмена отпусков, командировок, увольнений. То есть все, кто может работать, должны быть поставлены в ружье. Пробежимся теперь по этапам реагирования. Тут на базе методички SANS вариантов много. Но хотелось бы обратить внимание, что первое – подготовка к инциденту. То, что вы как компания, ваши клиенты могут сделать заранее. Логи с операционок, приклада, с СУБД, средств защиты. Они вообще есть? Они достаточной степени детализации? На какой глубине они хранятся и где? Они не будут ли вайпнуты или стерты или зашифрованы вместе с инфрой? Диски. Физически эксперт DFIR может найти вместе с вами, где конкретно находятся эти жесткие диски, в каком сервере.

То есть IP-адрес соотнести с конкретным юнитом стойки. Взять в руки, то есть технически открутить их, что там нет замков. А если вы использовали, например, свои средства защиты типа BitLocker, то и расшифровать. Артефакты. Можете ли вы запустить на каждом узле вашей инфраструктуры нужную программу? У вас есть сетевой доступ? А права доступа, учетная запись, а пароль вы от нее помните? А он точно не записан в файлике на сервере, который будет зашифрован? Такие случаи, к сожалению, неизвестны. Резервы. Есть ли у вас резерв финансов на привлечение подрядчика, вычислительных мощностей, на которые вы будете восстанавливаться, поскольку ваша техника потом может частично подлежать выемке?

Бэкапы и так далее. А зарезервировали ли вы дистрибутивы? А лицензионные ключи к дистрибутивам тоже зарезервировали? Особенно для трофейного программного обеспечения, где вы не сможете их повторно запросить у вендора.

Второй этап – идентификация. Классно, если вы пользуетесь TI-фидами. Вы можете узнать о подготовке атаки на вашу инфраструктуру еще до того, как все случилось. Такой shift-left. Тогда, возможно, и весь респонс у вас сведется к паре-тройке часов, а простой это особо не будет. Compromise assessment будет достаточно. Если нет, хуже. Возможно, ваш SOC прореагирует и скажет, что происходит что-то подозрительное. Если его нет, ну, может быть, у вас хотя бы managed EDR есть, и партнеры скажут, что, ребят, что-то у вас на тех узлах подозрительное. Нет managed, хотя бы, может быть, свой EDR. Ну, хуже, когда просто мы в IT-мониторинге видим, как методично отключаются антивирусы на узлах. Ну, тоже подозрительно, согласитесь, если антивирусы выключаются. А злоумышленники будут отключать средства защиты, они просто мешают работать. Могут помешать, там, шифровальщик запустить, еще что-то. Ну, в худшем варианте, если вы остальным не озаботились, то прочитаете в Telegram-канале из отпуска, что можно обратно из отпуска не возвращаться, некуда.

Изоляция. Это, наверное, последнее, что компания может сделать самостоятельно, без чьей-либо помощи. Изолировать технику, не перезагружать, но отключать от ЛВС. И виртуалки, и физические машины, и другие интерфейсы, и отключать от SAN-сети. Особо хитрые и вредные зловреды, они умеют, например, запускать шифрование, если теряют связанность с своим командным центром. То есть вы инфраструктуру интернета свою отключили, чтобы вам никто не мешал проводить расследование и восстановление. А некоторые шифровальщики с этого момента и запускаются. Ну, соответственно, если у вас зрелая инфраструктура, то у вас данные все на СХД доступны по SAN-сети, по сети данных. Вы эту сеть отключаете, и то, что там в операционной системе крутится, шифровальщик, а ему шифровать нечего. Все на СХД отключенный.

Зачистка. Здесь, конечно, как раз нужны эксперты. Это, собственно, выявление и удаление всех закладок без исключения. Восстановление средств защиты, которые могут быть отключены, испорчены, в них могут быть внесены исключения. И потом смена паролей. Везде. В доменных, в локальных, в никсах, в маках, в винде, в standalone АРМах, в СУБД, в VPN, в прикладе, во внешних личных кабинетах, сертификаты доступа, односторонние, двусторонние, личные кабинеты ФНС и так далее. Крайне важно, чуть позже расскажу почему, нельзя не забыть вообще ничего. И системные учетные записи тоже не забываем.

Ну, восстановление и вынесенные уроки. Тут-то как раз вы восстанавливаете из резервных копий все ваши данные. Причем вы, скорее всего, еще будете сетапить приклад из дистрибутивов, накатывать все патчи, только потом восстанавливать данные с бэкапов. Если они у вас сохранились, конечно. Например, если вы используете схему резервного копирования 3-2-1. Три резервные копии на двух носителях, один из которых вне вашей инфраструктуры. Причем желательно еще с контролем целостности. Восстановились, восстановили данные. Кто не сохранил бэкапы, начинает искать тестовые среды. Слушайте, а мы там, кажется, на тестовой среде когда-то промданные раскатывали для теста. Давайте с них восстановимся.

Плохая идея, конечно, промданные на тесте, но как бы у каждого по-разному. А кто-то говорит, ну что, а теперь мы в три смены будем всем коллективом с бумажной первички данные в базу вводить. Недель две. Такое тоже бывает. Отчет о реагировании. Рекомендация для неповторения плана работы, чтобы это не случилось второй раз. Это все может быть долго. То есть, как я говорил, что если шифровальщик еще не запущен, может, за 2-3 часа управитесь разобраться со всей ситуацией и выгнать злодеев. Но если ваша IT-служба пойдет тут менять массово пароли, то, конечно, злоумышленник такой, о, они пароль меняют. Наверное, они меня заметили.

Ну, запускаем. С Богом. И мы переходим сразу ко второму. Шифрование отработало, и здесь уже это измеряется днями, неделями. Ну и если вы подготовились, то днями, если не подготовились, то неделями. Можно онлайн, можно дистанционно. Особенно актуально для тех, у кого инфраструктура расположена далеко от федеральных центров. То есть экспертам туда просто долго добраться, 3 дня на собаках. Но тут очень важно, что руками на месте будете вы, ваши сотрудники. Если у вас не хватает людей или не хватает компетенции, там все джуны, например, такое бывает, то может получиться только хуже и дольше, чем эксперты к вам приедут.

И это, к сожалению, не все, потом вас ждет много развлечения. То есть вы обращаетесь в правоохранительные органы, с заявительными материалами, с отчетом от DFIR, который подготовили либо сами, либо вместе с экспертами, которых привлекали, регистрация в КУСП, получение номера, потом выемка, возможно, возбуждение уголовного дела, справка о признании компании потерпевшей, для того, чтобы при взаимодействии с другими госорганами, например, если вас пошифровали в конце налогового или отчетного периода, иметь возможность сказать, это мы не скрываем от вас бухгалтерскую отчетность, мы просто не можем ее вовремя предоставить, не казните нас.

Но это тоже не все. У вас могли украсть данные, например, персональные данные. И если вы раньше, например, пошли на выкуп, то тут хорошая тема попросить у вас второй выкуп за удаление этих данных. Но, как правило, их никто не удаляет. Даже если получили выкуп, их все равно потом продают, публикуют. И потом примерно 6 миллиардов человек, плюс-минус взрослого населения нашей планеты, могут с этими данными делать все, что угодно. Что они будут делать? Теперь за персональные данные сразу к вам придет регулятор. Клиенты, очевидно, будут unhappy и обратятся с жалобами. Если там будут данные клиентов вместе с слоями договоров, то ваши конкуренты такие, о, хорошие клиенты, платят исправно, давайте скидочку чуть сделаем и к себе уведем. Интересно?

Ваша интеллектуальная собственность, например, программный код. Класс, удобно. Ключи и пароли. Вот тут как раз та большая проблема, что примерно несколько миллиардов человек могут теперь спокойно отпарсить ваши данные и все, что там найдут, логопассы, попытаться применить в вашем интерфейсе или в интерфейсе ваших контрагентов, клиентов и государственных регуляторов, чтобы зайти от вашего лица что-нибудь нехорошее сделать. Поэтому мы тогда на том этапе все меняли. В случае утечки персданных обращения. И самое веселое. Готовьтесь к тому, что в будущем 100% и неоднократно, может быть, даже каждый день будет появляться в интернете информация, что вас снова якобы взломали и у вас снова украли данные. И будут публиковаться примеры данных, это ваши старые, плюс обогащенные вымышленными, сгенерированными данными или из других утечек. И вы теперь каждый раз будете оправдываться, что вы не верблюд.

Вы будете сверять эти данные, выложенные в интернете, с тем, что у вас сейчас, с тем, что у вас было на момент инцидента, и пытаться понять, это нас снова взломали. Или это злоумышленники просто пытаются выдать компиляцию за новый взлом. То есть мы говорим, что это все ложь, или мы говорим, что надо проводить DFIR заново. И если это все не ложь, то на самом деле в каждом реальном случае вы в 24 часа обязаны уведомить Роскомнадзор, в том числе о фейковой утечке. Все равно вы обязаны в 24 часа уведомить, а в 72 часа направить отчет о результатах внутреннего расследования. А мы с вами говорили, что DFIR будет длиться даже при подготовке несколько дней. Это не разные 72 часа.

Субъекты КИИ уведомить, соответственно, НКЦКИ, поднадзорные ЦБ уведомить, ФинЦЕРТ. Ну, может быть, кто-то еще GDPR соблюдает, не знаю. Поэтому желательно для каждого информированного органа заранее понять, кто будет, на основе какого шаблона, куда подавать отчет, с кем согласовывать, кто эти лица, уполномочены ли они и так далее. А если интерфейс недоступен, по вашей вине, не по вашей вине, как вы это на бумаге повезете и куда, и как будете штампик о получении получать. Ну, соответственно, моя личная рекомендация к подготовке любой отчетности – готовить их полноценными и исчерпывающими, потому что у государственных регуляторов тоже времени не супермного и ввязываться в переписку, наверное, не стоит. Лучше сразу полноценно подробно описать, что случилось, что сделано, что планируем сделать.

Ну, соответственно, если же еще пока не произошло самое печальное, но есть подозрение, что оно может произойти, можно провести compromise assessment. Это некоторый такой light вариант DFIR, когда собираются логи, собирается трафик и делается заключение вероятностное о том, взломана ваша инфраструктура, злоумышленники в ней уже сидят или пока еще не взломана. Почему? Из отчетов крупнейших компаний в сфере кибербезопасности и из отчетов киберкриминалистических лабораторий мы видим, что до запуска шифрования или вайпа в инфраструктуре злоумышленники могут в ней провести до этого 3, 6, а то и 9 месяцев, занимаясь разведкой, скачиванием всего, что можно, поиском бэкапов, чтобы их тоже удалить, зашифровать, чтобы вам было сложнее подняться.

И возможно, что за этот немаленький период, если у вас возникнет подозрение, вы проведете CA и выявите, что да, злоумышленники есть, они готовятся к уничтожению вашей компании и гораздо меньшими силами и средствами дешевле будет им противостоять и их выдворить. Как подготовиться? CISO, CIO, CTO, директора по IT и кибербезопасности могут заранее разработать план реагирования на случай как раз успешной кибератаки с самыми печальными последствиями. И это ни разу не IT-план восстановления, это совершенно другой принцип плана. Создать необходимые резервы на этот случай, включая финансы, технику, программное обеспечение и много чего распечатанной бумаги заранее.

Уделить особое внимание безопасности не только бэкапов данных, но и бэкапам прикладного ПО и лицензионных ключей, защитить саму систему резервного копирования. Потому что вот эта история, когда система резервного копирования, ее сервер находится в плоской сети с узлами, которые он бэкапирует, и рабочее место, с которого администрируется система резервного копирования, тоже в этой плоской сети, да еще и включено в домен. Ну что, думаете, у вас в случае запуска шифровальщика какие-то бэкапы будут? Да нет, конечно. И, собственно, провести учения, пусть даже командно-штабные, по реагированию. Мы пришли в понедельник, у нас ничего не работает, кроме того, что было выключено.

Сколько нам потребуется времени, чтобы восстановить работу полностью или в каком-то необходимом бизнесу объеме? А бизнес окей с этим сроком? Ему нормально? Если не нормально, то нужны инвестиции. Причем есть два вида инвестиций. Инвестиции в снижение вероятности инцидента. Это антивирусы, межсетевые экранирования, SOC, EDR и так далее. А есть инвестиции, сокращение времени простоя и сокращение ущерба, когда инцидент произойдет. Это другие мероприятия. И часть из них, так же как в случае с харденингом, вы можете сделать заранее, спокойно, бесплатно. Не все, но очень многое. В том числе можно заранее выбрать DFIR-партнеров или периодически проводить compromise assessment или что-то еще.

Как может к этому подготовиться генеральный директор? Во-первых, рекомендации довести до своих команд IT и ИБ, проверить, убедиться, что все все могут, все все умеют, никто не стесняется сказать, что он что-то не может или у него чего-то нет. При необходимости дать им нужное. Оценить время простоя в работе компании в случае инцидента с самыми печальными последствиями. И принять вообще, мне нормально это время простоя? Мне эти потери, ущерб репутации, отток клиентов, штрафы, проверки и так далее, они нормальны или нет. При инциденте привлечь все возможные ресурсы, изо всех сил поддерживать, поддерживать команду, поддерживать работников. И главное помнить, что любой работник, который допустил инцидент по своей вине или нет, но демотивированный, не будет заинтересован в его ликвидации. А тот работник, который принял все меры и усилия для того, чтобы компанию восстановить, чтобы ликвидировать последствия для компании, ценнее новых двух.

Рекомендации по ссылкам, они опубликованы вместе с Кибердомом, оформлены, доступны для скачивания. Пожалуйста, используйте их на здоровье ваших компаний, ваших партнеров, ваших клиентов. Спасибо за внимание.

Константин, большое спасибо. Вопросы? Спасибо, очень интересно. Вопрос такой. Какой… поздно пить боржоми, когда уже инцидент совершился? Так вот, из опыта, когда уже шифрование, в том числе бэкапа, уже совершилось и случаев, когда выявили соотношение их только начала, то есть когда только готовится инцидент к совершению и когда он уже совершен, как правило, чего больше-то? Вы понимаете, правильнее этот вопрос было бы задать компаниям, которых вызывают для проведения DFIR. Потому что мы с вами со стороны можем на это смотреть, но есть такой понятие, как ошибка выжившего. Вот многие те, кто не смог восстановиться, они не ходят на эти конференции, не говорят об этом. Ну, потому что это полное уничтожение бизнеса. Ну, понятно, то есть скрывают информацию, но мы-то все видим уже, когда произошло, а вот вообще…

Наша с вами задача подготовиться к тому, чтобы когда или если это произойдет, а) восстановиться, б) сделать это максимально быстро.

— Ну, это понятно. Спасибо. И многое можно сделать заранее, несложно и бесплатно. Начните с того, чтобы распечатать то, что в случае шифрования будет невосстановимо, но будет нужно в первую очередь. Я, в принципе, об этом тоже и говорил в самом начале, так что спасибо.

— Итак, коллеги, еще вопросы?

Константин, рук не вижу, поэтому большое спасибо. Давайте проводим Константина аплодисментами. Так, микрофончик. А мы с вами, коллеги, сейчас уходим на перерыв и снова в зале встречаемся мы в 3.30. Спасибо.

Спасибо отдельному блоку нашей сегодняшней конференции. Поэтому всех очень прошу вернуться в зал. Можно взять с собой все, что вы взяли непосредственно в зоне кейтеринга. И через пару минут буквально мы начнем двигаться дальше. Спасибо.

[музыка]

[музыка]

[музыка]

[В записи вырезан перерыв (по программе 14:55–15:30); от него осталось около полутора минут музыки.]