Готовы ли российские компании реагировать эти атаки? Недавние инциденты, когда в результате прямых хакерских атак банки теряли суммы, выражающиеся девятизначными числами, показывают, что скорее нет, чем да. В нашей практике девять из десяти тестов на проникновение заканчиваются достижением атакующими своих целей без какой-либо организованной реакции со стороны защищающихся. Поэтому честнее сказать: совсем нет. И это несмотря на наличие широкого ассортимента средств защиты, включая IDS/IPS, SIEM, средств выявления уязвимостей и т. п. Проблема в том, что одних только технических средств (какими бы «интеллектуальными» они ни были) для противодействия атакам недостаточно. Нужна еще и практика их использования. А с ней все обстоит не столь радужно не только в России, но и во всем мире. Поэтому при рассмотрении проблемы реагирования на хакерские атаки со стороны нападающего можно дать несколько рекомендаций по организации работы центров реагирования на инциденты (SOC), основанных прежде всего на здравом смысле. В понятие «инцидент» каждая компания, в зависимости от сферы своей деятельности, вкладывает что-то свое. Мы предлагаем ограничиться событиями, cвязанными с кибератаками на информационные системы.
Нельзя объять необъятное
Представим, что перед нами стоит задача создать корпоративный SOC в компании с высокими рисками кибератак и кибермошенничества. Первое, что в этом случае обычно делают, – пытаются разработать всеобъемлющую модель нарушителя, в которую включают всех, кто потенциально может угрожать компании (от молодых хакеров до иностранных технических разведок и злоумышленников из числа разработчиков ПО). Но давайте будем честны: мы правда верим в то, что в обозримом будущем сможем бороться со спецслужбами, гипотетически умеющими вскрывать сертифицированные криптографические алгоритмы, и с закладками, которые гипотетически может сделать разработчик операционной системы? Если нет, тогда к чему такой максимализм?
Для начала ограничимся теми, кто нам наиболее понятен, – нарушителями из числа пользователей наших внешних информационных систем, использующих известные уязвимости, техники их эксплуатации и инструментальные средства проведения атак. И только научившись справляться с известными угрозами, мы сможем перейти к борьбе с принципиально новыми атаками: программными закладками, ранее неизвестными образцами вирусов, собственными администраторами, наконец. Это длительный эволюционный процесс: от принятия решения о создании SOC до момента, когда он начнет осмысленно и уверенно реагировать на большинство реальных атак, может пройти больше десяти лет, но это единственно возможный путь. Однако, следуя по этому пути, не стоит сбрасывать со счетов и привлечение внешних экспертов: внутренние специалисты останутся как квалифицированная первая линия, оперативно и профессионально отрабатывающая понятные уязвимости, а случаи более изощренных атак, требующие детального и глубокого расследования, могут передаваться внешнему партнеру.
Вторая ошибка, которую делают компании, создавая SOC, – пытаются вменить ему в обязанность защиту всех своих информационных систем. Ничего хорошего из этого не выйдет. Необходимо оценить все ресурсы с точки зрения их критичности, в том числе с учетом действий, которые могут быть предприняты злоумышленниками в ходе атаки. Например, если пока нет возможности блокировать целенаправленные атаки или рассылки вредоносов в файлах электронной почты, в том числе с использованием уязвимостей нулевого дня, это не означает, что можно ничего не делать. Стоит сфокусироваться, скажем, на блокировке загрузок с веб-серверов в Интернете дополнительных модулей, использующихся для реализации атаки, и способов выхода из инфраструктуры даже в случае успешного взлома. Но надо понимать, что даже при такой расстановке приоритетов нельзя просто взять одну, две, три наиболее важные информационные системы и начать деятельность только с них, оставив остальные за бортом. Правильнее проранжировать периодичность мониторинга каждого из активов в зависимости от степени его критичности. Причем наименее критичные на начальных этапах могут контролироваться реже и даже без подключения к SOC, зона охвата которого будет наращиваться поэтапно. Так постепенно сформируется оптимально работающая система.
Но вот мы столкнулись с первым инцидентом. Что делать? Поздравляю! В тот момент, когда нам пришлось задать себе этот вопрос, мы успешно провалили задачу реагирования на инцидент.
Информационная безопасность во многом похожа на медицину: принимая пациента, врач не изобретает лечение на месте. Напротив, еще до того, как его допустили к самостоятельной практике, в него десяток лет вдалбливали стандарты медицинской помощи для различных классов заболеваний, протоколы диагностики и лечения различных болезней, встречающихся в этой местности. В результате врач знает, как проявляется болезнь на каждой ее стадии, как ее на этих стадиях диагностировать и лечить, какие могут быть осложнения и что с ними делать. Только благодаря этому пневмония и грипп, от которых сто лет назад умирали миллионы, перестали быть чересчур опасными.
Каждый успешный взлом информационной системы – это последовательность элементарных действий нарушителя. Например, просканировать внешние IP-адреса, найти на веб-сайте уязвимость скрытой загрузки файлов (RFI), с ее помощью загрузить на веб-сервер веб-шелл, загрузить на веб-сервер сканер уязвимостей, просканировать доступные веб-серверу внутренние узлы сети и т. д. Каждая такая атака выполняется конкретным, хорошо известным способом, нарушитель использует уязвимости определенного типа и оставляет вполне специфические следы. Это значит, что задолго до того, как нарушитель начнет действовать, можно воспользоваться целым арсеналом средств противодействия: найти и устранить нужную нарушителю уязвимость RFI или защитить уязвимый веб-сервер экраном уровня приложений (WAF’ом), загрузить на сенсоры системы обнаружения вторжений сигнатуры, реагирующие на эксплуатацию RFI или на нетипичную загрузку файлов на веб-сервер. А на случай, если хакер найдет обходной путь, − подстраховаться и загрузить на внутренние сенсоры системы обнаружения вторжений сигнатуры, реагирующие на сканирование внутренних узлов сети. Мы также можем определить, какие записи в каких журналах аудита могут свидетельствовать о том, что проводится такая атака. Наконец, у нас есть возможность расписать, кто, что и в какой последовательности должен делать, если на подобную атаку отреагируют сенсоры системы обнаружения вторжений или если постфактум мы обнаружим следы атаки в журналах аудита. Только тогда можно говорить, что мы готовы адекватно реагировать на подобный инцидент. И такая подготовка нужна для каждого потенциально возможного инцидента.
Таким образом, для того чтобы осмысленно реагировать на действия хакеров, нужно самим отчасти стать хакерами. Основа реагирования на такие атаки – большая, заблаговременно проведенная подготовительная работа. Именно потому и рекомендуется начинать деятельность SOC с небольшой области и поначалу ориентироваться на самые простые и понятные типы атак. И лишь с накоплением опыта и знаний сферу действия SOC можно расширять.
Используйте «помощь зала»
Если для реагирования на хакерские атаки нужна настолько детальная проработка, возникает закономерный вопрос: где взять такое количество подготовленных специалистов? И если их нет, можно ли переложить эту задачу на чужие плечи? Существует несколько путей решения этой проблемы.
Первый путь – наработка практики тестирования на проникновение. Для каждого типового компонента информационной системы (веб-сервера, СУБД, АРМ пользователей и т. д.) характерны определенные «детские болезни» – типовые уязвимости программного кода, повторяющиеся раз за разом ошибки в настройках, архитектуре и т. п. Проводя тест на проникновение, исследователь не знает, есть ли такие уязвимости в конкретной информационной системе и отрабатывает все варианты потенциально возможных атак. И если уязвимости, которые он обнаруживает, могут быть уникальны для каждой информационной системы, то инструментальные средства и приемы их применения, которые он использует в ходе работы, достаточно универсальны и применимы к большинству информационных систем. Поэтому результаты качественного теста на проникновение и в еще большей степени наблюдение за его проведением дают богатый материал для разработки планов реагирования на атаки. Многие крупные российские компании, в которых функционируют развитые корпоративные SOC, начинали с того, что учились реагировать на определенные типы атак в ходе подобных тестов.
Второй путь – использование набирающей популярность услуги анализа вредоносной активности (Threat Intelligence), которую предлагает ряд специализированных компаний. Их отчеты и источники данных предоставляют подробную информацию о наиболее распространенных уязвимостях, о типовых атаках, условиях и последствиях их проведения, о характерных свидетельствах их проведения. Как и результаты тестирования на проникновение, эти материалы позволяют определять, какие именно типы атак могут быть применимы к различным компонентам информационных систем, и готовиться к ним.
Третий путь – бескорыстная помощь экспертного сообщества. Практически каждая разновидность компьютерных атак имеет своих энтузиастов-исследователей, а в некоторых случаях представляет интерес для крупных некоммерческих исследовательских проектов. Так, проект OWASP предоставляет исчерпывающую информацию о возможных уязвимостях веб-приложений, способах их поиска и устранения, последствиях их эксплуатации. Изучение таких источников требует весомых трудозатрат, но и пользы от их изучения гораздо больше. В последнее время приобретает популярность и бескорыстное распространение экспертных знаний: столкнувшись с новой для себя атакой, исследователь публикует подробный разбор техники нападения, отмечая особенности проведения атаки, следы, по которым ее можно определить, рекомендации по ее предотвращению и реагированию на нее. Анализ таких материалов – одно из наиболее важных направлений деятельности любого SOC.
Наконец, еще один путь – аутсорсинг экспертизы. Разновидностей кибератак очень много, и они могут быть весьма специфичны, тонко заточены под особенности тех или иных систем (SCADA, телекоммуникационные системы, финансовые и пр.). При этом происходить они могут весьма эпизодически, а для их расследования необходимы узкопрофильные эксперты. Держать в штате на постоянной основе специалистов по всем возможным направлениям чаще всего нецелесообразно. И проблема не только в излишних расходах – сами эксперты могут терять квалификацию без достаточной практики. Поэтому к реагированию на инциденты, связанные с редко встречающимся, узкоспециализированным программным обеспечением и оборудованием, оправданно привлекать специалистов экспертных организаций в рамках отдельных исследовательских проектов или на условиях аутсорсинга. Рынок таких услуг в России еще только зарождается, и пока основные их потребители – операторы связи и промышленные компании.
Учитесь на ошибках
Один из наиболее очевидных показателей эффективности деятельности SOC – количественная доля инцидентов, в которых, благодаря реакции SOC, нарушитель не смог добиться успеха. Использование такого показателя не очень удачная идея. Скажем, мы заблокировали 49 атак: как оценить это количество? 49 из 1000? Или из 50? Первый и второй случаи, как вы понимаете, «две большие разницы». Оптимальный подход − вводить статистические показатели. Пример из сферы целенаправленных атак: здесь можно оперировать статистикой времени присутствия злоумышленника в инфраструктуре организации. Среднемировой показатель – немногим менее полугода. И в этом случае выявление подобной атаки даже в течение месяца говорит о том, что ИБ-команда работает эффективнее большинства своих коллег по отрасли.
Даже самый тщательный анализ не позволит подготовиться к всем возможным типам атак, и наш SOC всегда будет сталкиваться с инцидентами, для которых нет готового протокола реагирования. Это значит, что даже неудачные, неадекватные действия персонала при реагировании на инцидент – еще не повод для карательных мер. Поэтому второе важное направление деятельности SOC – разбор таких инцидентов, анализ действий нарушителя и противодействовавшего ему персонала, поиск причин неудачного реагирования, которых может быть несколько:
- не выполнялись действия, предусмотренные протоколом реагирования на инциденты такого типа;
- не хватило квалификации персонала;
- отсутствовали необходимые технические средства;
- принятию мер помешали несогласованность действий различных подразделений, противоречия между ними и т. п.;
- протокол реагирования оказался неприменим в силу особенностей проведения атаки;
- инцидент стал результатом принципиально новой атаки, и персоналу пришлось действовать по наитию.
И только в первом случае может идти речь о недостатках в работе SOC, требующих выявления и наказания виновных. Во всех других ситуациях неудачное реагирование на инцидент – источник информации, необходимой для развития SOC, его адаптации к изменяющейся обстановке. Поэтому каждый инцидент должен заканчиваться разбором и оценкой действий персонала.
Анализируйте сырые данные
Предположим, мы столкнулись с инцидентом, на который не смогли адекватно отреагировать. Как провести расследование и как собрать необходимые для него свидетельства? Как и в случае предотвращения атак, если нам пришлось задать себе такой вопрос, значит, расследование мы уже практически провалили.
Тот арсенал средств, которые, как правило, использует SOC (системы обнаружения вторжений IDS, экраны уровня приложений WAF, антивирусы, системы обработки событий безопасности SIEM и т. п.), ориентирован на определенный, фиксированный набор атак, для которых в этих средствах есть подходящие сигнатуры, правила разбора данных аудита, корреляции. Если мы столкнулись с принципиально новой атакой, эти средства, скорее всего, не дадут нам полезной для анализа информации. Это значит, что наряду с генерируемыми ими данными необходимо постоянно собирать и в течение некоторого времени хранить первичные сырые данные, которые могут пригодиться в расследовании.
В отличие от разработки протоколов реагирования, в подобном случае у нас нет точного знания о том, что именно потребуется при расследовании инцидента, и подход к планированию должен быть несколько иным. Каждая информационная система – это определенный набор устройств, взаимодействующих между собой операционных систем и прикладных программ. Для каждого из этих компонентов мы можем определить, какие интерфейсы взаимодействия он предлагает своему окружению и какими из них может попытаться воспользоваться злоумышленник (сетевые протоколы, интерфейсы подключения устройств, программные интерфейсы и т. п.). Кроме того, многие из них имеют средства диагностики и аудита, генерирующие в ходе работы этого компонента полезные для расследования сведения.
Таким образом, мы определяем возможные источники сырых данных, а для них самих – средства сбора этих данных. Такими средствами могут быть системы централизованного сбора данных аудита, снифферы сетевых протоколов, средства диагностики и т. п. То, какие именно данные и с какой степенью детализации собирать, в течение какого срока их хранить, придется определять на месте, исходя из технических возможностей SOC. Или, наоборот, нормативно определить требования к составу и срокам хранения сырых данных и на основании этого периодически модернизировать технические ресурсы SOC. Еще один нюанс: в определенный момент приходит понимание, что по метаданным, хранящимся в системах защиты (межсетевых экранах Firewall, SIEM, антивирусах и др.), оценить ситуацию сложно. Например, антивирус удалил в папке Windows файл с вердиктом Heur.Trojan.Generic, который потребовался для понимания ситуации в какой-то момент. Поэтому на определенном уровне зрелости становится понятно, что необходимо хранить сырые данные (вплоть до полного дампа трафика за несколько недель). Как говорится, если что-то пропустили, то лучше узнать об этом позже, чем никогда.
Уставы написаны кровью тех, кто их не соблюдал
Задумавшись над тем, как много нужно знать о защищаемой информационной системе, для того чтобы уметь реагировать на возможные действия атакующего, начинаешь совсем по-другому смотреть на стандарты разработки и документирования информационных систем. Оказывается, их писали не самые глупые люди. Для анализа возможностей атакующего нужно хорошо представлять архитектуру информационной системы, состав ее программных средств, их композицию. Чтобы обеспечить сбор сырых данных для расследований, необходимо досконально знать интерфейсы компонентов информационных систем, их журналы аудита и многое другое. Для получения нужной информации порой приходится потратить несколько месяцев на вдумчивый анализ и тестирование системы.
Но позвольте, еще советские ГОСТы 19-й и 34-й серий и современный ISO 15408 в один голос утверждают, что эта информация должна быть непременной частью проектной документации информационной системы. В реальности на большинство существующих информационных систем документация отсутствует, а когда она есть, то в лучшем случае описывает лишь функциональные возможности системы, а в худшем − обильно цитирует рекламные материалы разработчиков ПО. В итоге после сдачи системы в эксплуатацию приходится тратить дополнительное время и трудовые ресурсы, чтобы понять, как же она устроена.
Необходимость тщательно изучать защищаемые информационные системы, смотреть на них с позиции атакующего и находить недостатки защиты превращает корпоративный SOC в значимого участника жизненного цикла информационных систем.
Во-первых, задача противодействия атакам требует реализации в информационных системах определенных механизмов безопасности, и SOC является наиболее компетентным источником требований к ним. Во-вторых, не секрет, что для современных программных продуктов (особенно для индивидуальных заказных разработок) характерно крайне низкое качество программного кода, в том числе наличие большого количества уязвимостей. Очевидно, что выявлять их разумнее всего на стадии приемки информационной системы, и SOC, который в силу специфики своей деятельности должен обладать и компетенцией, и инструментальными средствами их поиска, должен стать участником приемки системы. На ранних стадиях развития, когда SOC ориентирован на противодействие типовым атакам, его роль может сводиться к поиску известных уязвимостей программного кода и типовых уязвимостей веб-интерфейсов, но с ростом компетенции подразделения в объем проверок, проводимых при приемке, можно включить и оценку качества исходного кода заказных разработок, и поиск возможных программных закладок в них. Наконец, одним из серьезных источников уязвимостей являются настройки программных и аппаратных компонентов. И здесь SOC в силу своей компетенции может выступать и источником требований по безопасной настройке компонентов информационных систем, и контролером, требующим выполнения этих требований.
Заключение
Однако для достижения столь амбициозных целей при создании собственного SOC недостаточно внедрения современных решений. И даже дополнение технологической платформы высококлассными экспертами (собственными или по аутсорсинговой модели) не гарантирует, что вся конструкция «взлетит» и заработает так, как ожидается. На самом деле необходим весьма специфический микроменеджмент, который позволит реализовывать более широкие возможности SOC, нежели классические задачи мониторинга и управления.
