Не все стандарты одинаково полезны

 

 

Гайко Андрей

заместитель директора Департамента

сертификационного аудита (Digital Security)

 

 

Как соблюдать правила в ущерб безопасности

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

 

 

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


Конечно, если какая-либо мера реализована совсем не корректно, нужно сразу сообщить клиенту об этом для внесения изменений. Но в массе своей вопрос эффективности или, лучше сказать, «полезности» тех мер, которых требует стандарт, уходит на второй план. Хорошо, если разработчики документа позаботились о пользователях, и предлагаемые ими меры понятны и хорошо работают (например, правила, которые касаются паролей).


Но есть такие рекомендации, которые предоставляют «безопасникам» огромное поле для деятельности. Те же требования к реализации оценки рисков, тестам на проникновение, анализу событий, управлению инцидентами... Приведенные в примере процессы являются достаточно сложными в реализации. С завидной регулярностью встречаются клиенты, у которых специалисты по ИБ имеют поверхностные теоретические и практические знания по этим процессам. Поэтому им приходится подходить к ним формально – выполнять только те требования, которые указаны в стандартах.


Такой подход, в частности, особенно опасен в сочетании с пристрастием к «коробочным» SOC. В процессе аудита мы нередко встречаем SIEM с определенным набором правил. «Местный» специалист демонстрирует алерты, сообщения в почте, графики. Формально все совпадает с требованиями стандарта. Однако, если задать дополнительные вопросы, нередко всплывают различные нюансы. И приходит понимание, что ни в одном стандарте нет самого простого и главного требования – специалист должен понимать, что и зачем он делает.


А теперь давайте посмотрим на практике, какие именно опасные нюансы имеются ввиду. Разберем требования к тесту на проникновение в рамках стандарта PCI DSS (см. Требование 11.3) и попробуем ответить на вопрос: как можно использовать требования к тесту на проникновение, чтобы тест был эффективен и дал полезные результаты?


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


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


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


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


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


И вот почему. Результатом пентеста не обязательно должен быть перечень CVE. Взлом может быть выполнен и без эксплуатации уязвимостей в ПО. Например, у нас есть веб-сервер и СУБД с картами. Возможен такой вектор атаки - могут быть подобраны пароли по словарю от каких-либо сервисов, учетных записей пользователей. Далее, можно установить свое приложение на веб-сервер. Если сервер запущен из-под привилегированной учетной записи, то наше приложение тоже будет иметь повышенные права. Это приложение может дать shell. Используя ПО для снятия образа памяти, можно получить пароли пользователей в открытом виде, которые входили на этот сервер (актуально для Windows 2008, для Windows 2012). Одним из пользователей может быть доменный администратор.


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


Непонятно, почему в компаниях тестирование планов реагирования на инциденты и тестирование на проникновение выполняются как последовательные, а не параллельные процессы? И почему в рамках пентеста отдел ИБ не сопротивляется взлому? PCI DSS этого не запрещает. Ведь если компания смогла «отбить» пентест, то с большей вероятностью можно говорить о том, что она будет готова защититься и от реальных атак. Конечно, тут есть «но» – реальная атака может иметь разную продолжительность, а время на проведение теста по проникновение ограничено.


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


Наиболее правильным подходом к использованию теста на проникновение видится его применение в рамках так называемого red team exercise. Достаточно хорошо об этом опыте в своей статье рассказал Кирилл Ермаков, директор по информационной безопасности компании QIWI - http://journal.ib-bank.ru/post/413


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

Источник: BIS-Journal http://www.journal.ib-bank.ru/