Pages - Menu

Страницы

28.1.20

7 уроков из сотен расследованных инцидентов

Наткнулся я тут на презентацию службы реагирования на инциденты Cisco, которая по результатам более 100 проведенных расследований у наших заказчиков, сформулировала 7 ключевых наблюдений/уроков, которые мне показались достаточно интересными, чтобы про них написать. Ну а учитывая, что они не касаются продуктов, то это не стоит рассматривать как product placement.

Helpdesk всегда знает, где закопано тело

В ряде сценариев для киберучений, история начинается со звонков в службу поддержки. Дальше инцидент развивается очень активно и на каждом из шагов я задаю участникам одни и те же вопросы:


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

Следите за изменениями

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

Хакеры знают сеть лучше админов

В большинстве инцидентов выяснялся любопытный факт - хакеры знали свою жертву лучше, чем она сама. Нередко от специалистов по ИТ или ИБ звучала фраза "А что, так можно было?", когда им рассказывали про то, как происходило проникновение, что стало точкой входа и почему инцидент так долго не был обнаружен. Чтобы безопасникам знать свою сеть если не лучше хакеров, то хотя бы на том же уровне, им стоит активнее привлекать Red Team в своей деятельности. И не забывать, что фокусироваться надо не только на расследовании инцидентов, но и на понимании мотивов злоумышленников и того, зачем им вас атаковать.

Сегментация и доступ

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

Хакеры редко используют 0Day

Использование 0Day - это достаточно большие инвестиции для хакеров и их применение часто неоправданно. Когда злоумышленники попали внутрь вашей сети, им не нужны никакие 0Day, - отсутствие сегментации, редко сменяемые пароли, наличие хорошо известных и неустраненных уязвимостей... все это делает многие проникновения успешными. А если уж говорить о технологической состовляющей, то гораздо важнее внедрить решения класса EDR, чем искать серебрянную пулю, которая останавливает 0Day.


Редактирование выбора пользователей 

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


Будьте бдительны при закрытии инцидента

Нередко ошибки допускаются при закрытии инцидента. Опытные злоумышленники по нашему опыту используют мероприятия, выявляющие меры расследования и препятствующие им. Они меняют инструментарий и тактику, могут на время "затихнуть". Даже если вы выявили их и считаете, что выкинули из своей сети, они могут вернуться, если считают вашу сеть лакомым куском для себя. Необходимо тщательно следить за компьютерами конечных пользователей, особенно теми, которые были задействованы в инциденте, который вы закрыли.

В качестве финального аккорда отмечу еще несколько сделанных наблюдений:

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

4 комментария:

  1. Хорошие рекомендации.
    Я бы еще порекомендовал переработать под себя ГОСТ по менеджменту инцидентов ИБ. В принципе там достаточно хорошо описано взаимодействие админов ИС и админов ИБ, а также процесс выявления инцидентов и реагирования

    ОтветитьУдалить
  2. Ну этот ГОСТ все-таки достаточно высокоуровневый

    ОтветитьУдалить
  3. Этот комментарий был удален администратором блога.

    ОтветитьУдалить
  4. Этот комментарий был удален администратором блога.

    ОтветитьУдалить

Примечание. Отправлять комментарии могут только участники этого блога.