И в принципе сказка-то почти реальна. Машинное обучение, интеграция с облаком, постоянное пополнение сигнатур случившимися инцидентами – все это хорошо помогает в разработке средств защиты. Но, отдавая за это огромные деньги, компании забывают, что такие решения нужно настраивать под конкретную информационную систему, что дефолтные настройки не спасут во время атаки, что информационная система функционирует не в вакууме.
Другие компании выбирают более бюджетные варианты средств защиты — раз в жизни закажут услугу по анализу защищенности и считают, что теперь-то у них точно все в порядке. И очень негодуют, когда что-то случается! Ведь действительно — все было сделано, чтобы обезопасить компанию. Что же пошло не так?
Цель данной статьи – порассуждать на тему безопасности компании, а также разобраться, нужны ли вообще такие услуги, как тестирование на проникновение, и почему ИБ – это дорого.
Немного жизненных ситуаций
Итак, начнем. Ситуация вполне обычная и знакомая многим. Запуганный русскими хакерами (и хакерами других национальностей) директор компании решает выложить круглую сумму и внедрить в информационную систему anti-apt решение. Идея, заслуживающая уважения. Деньги уплачены, решение внедрено, приставлены «мальчики» для реагирования на инциденты. Как утверждает вендор, все настроено так, что будет работать, как говорится, «из коробки». Все идеально. Директор компании почти в нирване, но тут случается страшное. Закупленное решение начинает постоянно сообщать об атаках. Постоянно. Почти 24/7. «Мальчики», которые должны реагировать на все призывы и волнения anti-apt решения, говорят, что ничего критичного не происходит, однако спам уведомлениями об атаках продолжается. Пользователи не могут нормально работать и засыпают техподдержку жалобами. Директор не может зайти на нужные ему сайты, скачать интересный фильм, его любимый компьютерный вирус бьется в предсмертных конвульсиях. Никто не понимает, что происходит, но все знают, кто (точнее, что) виновато. И принимается волевое решение – новую штуку отключить, убрать в шкафчик до лучших времен. Мир снова расцветает красками, спокойствие и размеренный ритм возвращаются в компанию. Директор выдыхает…
Ситуация вторая, тоже тривиальная. Средства защиты закуплены, даже вроде работают более-менее стабильно, не вызывая негатива. И тут начинают приходить уведомления об инцидентах. «Мальчики», которые ведут наблюдение за сигналами SOS, пытаются реагировать, но у них либо получается не оперативно, либо совсем не получается. Защита оказывается бесполезной, как никуда не подключенная пожарная сигнализация.
Ситуация третья, еще более узнаваемая. Директор решает, что компания может обойтись скромными средствами защиты, «без изысков», а чтобы проверить, все ли работает, следует провести тестирование на проникновение. По его мнению, пентест проводится один раз и гарантирует защиту компании от взлома «на всю оставшуюся жизнь». Тестирование на проникновение проведено, отчет написан, дифирамбы средствам защиты спеты, а компанию взламывают. Директор седеет…
Правда, знакомые ситуации? Давайте разбираться, почему так получается.
Почему же так получается
Любое anti-apt решение, SIEM, более-менее интеллектуальное средство защиты требуют специальной настройки под конкретную информационную систему. Под каждую. Нет чудо-средства защиты, нет «большой кнопки», которую нажал — и все сразу работает, без каких-либо дополнительных действий.
Все знают о том, что в любой системе есть ложноположительные и ложноотрицательные срабатывания. В данном случае, соответственно, ложноположительные – это когда за инцидент принимаются какие-либо легитимные действия в системе, ложноотрицательные – когда инцидент принимают за легитимные действия.
Как же настроить средства защиты компании, чтобы уменьшить число ложных срабатываний?
Оптимальное решение – проведение полноценного тестирования на проникновение методом «черного ящика». В идеале, конечно, Red Team. Совсем идеально: сначала пентест для настройки, потом Red Team — для проверки, еще более чувствительной настройки и обучения команды Blue Team оперативно реагировать на сигналы от средств защиты. Таким образом мы сможем решить проблему с недостаточно быстрой реакцией сотрудников. Правда, такая последовательность выливается в круглую сумму, иногда неподъемную для компании.
Тестирование на проникновение? Серьезно? Эти отчетики из сканеров могут нам помочь?
Основная проблема, связанная с тестированием на проникновение, – для крупных компаний это стало мейнстримом. Заказывать пентест и получать отчет о найденном просто потому, что это «стильно, модно, молодежно», – бесполезно. Но если тестирование на проникновение делается качественно и из него извлекаются уроки, это очень полезная штука.
Урок 1. Слаженность работы команды реагирования на инциденты и делегирование полномочий.
В случае возникновения инцидента огромную роль играет быстрота реагирования. Поэтому команда Blue Team должна быть слаженной — понимать зоны ответственности и оперативно обмениваться информацией. Конечно, такой высокий уровень взаимодействия труднодостижим, но грамотно проведенное тестирование на проникновение — искусственное создание инцидентов, провоцирующее реакцию средств защиты, — помогает команде понять последовательность действий и специфику реагирования в подобных ситуациях. Это не значит, что команда просто учится по определенному шаблону (по конкретным инцидентам) и у нее наступает ступор, если происходит атака другого типа. В данном случае важно понять сам принцип взаимодействия, определить зоны ответственности (не в теории, а «в реале») и прочувствовать все вживую.
Урок 2.Расстановка приоритетов на активы компании.
Понятно, что существует информация разной степени критичности, и необходимо расставлять приоритеты на активы. Для отвлечения внимания злоумышленники часто проводят одновременные атаки на разные ресурсы компании. Создается большое количество инцидентов, и команда Blue Team должна грамотно реагировать — понимая, какие атаки представляют опасность для критически важной информации, а какие являются «белым шумом». В случае, если изначальные приоритеты не расставлены или расставлены неправильно, компания рискует среагировать не на те инциденты.
Урок 3.Проверка реагирования средств защиты и их грамотная настройка.
Проведение тестирования на проникновение помогает Blue Team понять, как реагируют средства защиты на конкретные действия злоумышленника. Например, если происходит перебор пользовательского пароля и он периодически блокируется, важно не просто заблокировать на какое-то время учетную запись, но и уведомить об этом команду реагирования на инциденты. Если на действия пентестеров ваши средства защиты не реагируют, значит их нужно корректно настроить. Но увлекаться не стоит, иначе пользователи просто не смогут нормально работать.
Вот, наверное, три основных урока, которые помогает усвоить проведение тестирования на проникновение. Основной момент заключается в том, что пентест должен выполняться не «для бумажки», а серьезно и ответственно. Идеальное решение – Red Team (полная эмуляция действий apt группировки). Это действительно долго, честно, с максимально возможным обходом средств защиты. Как всегда – за качество надо платить, поэтому такого рода услуга стоит очень дорого.
Вместо заключения
А суть сей басни такова: используйте свои ресурсы грамотно. Даже самое дорогое средство защиты не сможет обеспечить безопасность вашей компании, если не будет слаженной команды реагирования на инциденты. Вам нужна реальная безопасность, а не бумажная, поэтому стоит вкладывать средства в «честную» проверку безопасности.
Комментарии (3)
Zwerg
27.09.2018 21:32+1У автора в статье три разных понятия названы одним словом — «тестирование на проникновение».
1. Есть vulnerability assessment — «оценка уязвимостей»: грубо говоря прогнал автоматический сканер типа нессуса/кволиса/макспатрола или еще какого-нибудь (есть специализированные сканеры под веб, под БД и тп), получил отчет и доволен — есть список проблем, можно идти и фиксить.
2. Есть «Penetration Test» — оно же «тестирование на проникновение». Нанимаем пентестеров, обозначаем границы обследования и вперед. Задача у пентеста — проверить адекватность конфигурации и настроек безопасности серверов и приложений. В идеале пентесты проводятся с отключенными средствами защиты, чтобы это не WAF атаки отбивал, а веб-приложение было не уязвимо. Команда защиты заранее предупреждается о пентесте, и не должна реагировать на события от пентестера.
3. «Red Team Exercise» — тут задача как раз проверить процессы и методы реагирования синей команды. О Read Team Exercise никто не предупреждает защитников. Члены красной команды должны моделировать действия хакера в разных сценариях (например популярен сценарий «assumed breach» — т.е. мы заранее помогаем красной команде попасть внутрь периметра, и смотрим как быстро синяя команда обнаружит вторжение).karelovao Автор
28.09.2018 08:19Совершенно верно вы описали все 3 понятия.
И очень часто возникает ситуация, когда при проведении тестирования на проникновение, предупрежденная команда защиты начинает «вредительствовать» (блокировать IP-адреса пентестеров, срочно менять конфигурации и т.д.), чтобы не получить нагоняй от начальства.
Также большинство заказчиков не понимает, чего они хотят. Знают модное слово «пентест» и хотят отчет. Или вообще не понимают зачем им подобного рода проверки безопасности, если у них стоят дорогущие средства защиты.
Можно, конечно, всем сказать — берите RedTeam как услугу и все. Но не все на это готовы морально и финансово. Поэтому цель статьи — показать, что даже при выборе тестирования на проникновение, заказчик может получить значительно больше плюсов, чем просто отчет об уязвимостях и недостатках информационной системы. Можно сидеть и не мешать, пока работают пентестеры, а можно не мешать, но делать выводы и таким образом учить команду BlueTeam. К сожалению, большинство просто ждет отчета, чтобы «потом, когда-нибудь, все устранить» и в плане поставить галочку, что тестирование на проникновение проведено.
saipr
Эти пускай думают, если есть лишние деньги — пусть покупают, нанимают, ну а менеджерам по продажам сам бог велел впаривать.
А истина здесь: