Анализ «громких» инцидентов в сфере информационной безопасности в 2019 году

Содержание

EDR

Постепенно ряд производителей включает решения данного класса в состав уже существующих агентов – антивирусной защиты, систем защиты от утечек данных и т.д. Но оно несёт принципиально другой функционал – это дополнительная телеметрия (Detection в Endpoint Detection and Response) и возможности по реагированию (Response).

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

Реагирование средствами EDR делает процесс локальным и увеличивает его стабильность.

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

Результат использования EDR – расширенная телеметрия и локальное автоматизированное реагирование.

Что и как мы считаем

  • Событие ИБ — идентифицированное появление определённого состояния системы, сервиса или сети, указывающего на возможное нарушение политики ИБ или отказ защитных мер, или возникновение неизвестной ранее ситуации, которая может иметь отношение к безопасности.
  • Инцидент ИБ — появление одного или нескольких нежелательных или неожиданных событий ИБ, с которыми связана значительная вероятность компрометации бизнес-операций и создания угрозы ИБ.
Высокая критичность Инциденты, связанные с ключевыми ресурсами серверного сегмента или с критичными ресурсами пользовательского сегмента (ресурсы, обрабатывающие критичную с точки зрения бизнеса, финансов или законодательства информацию).
Средняя критичность Инциденты, связанные с некритичными ресурсами серверного сегмента.
Низкая критичность Инциденты, связанные с некритичными ресурсами пользовательского сегмента (рядовой пользователь).

Защита данных

DAP – Database audit and protection

Системы данного класса обеспечивают безопасность систем управления реляционными базами данных (СУБД). DAP – это развитие базовых возможностей мониторинга инструментов database activity monitoring (DAM), но при этом они имеют такие дополнительные функции, как:

  • обнаружение и классификация данных;
  • управление угрозами и уязвимостями;
  • анализ на уровне приложений;
  • предотвращение вторжений;
  • блокировка активности;
  • анализ управления идентификацией и доступом.

DLP – Data Leak Prevention или Data Loss Prevention

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

DCAP – Data-Centric Audit and Protection

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

CASB – Cloud Access Security Broker

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

SDS – Software-Defined Storage

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

4. Группы обеспечения непрерывности и восстановления деятельности

Название группы Состав группы Функции группы
Группа обеспечения непрерывности Пользователи, руководители структурных подразделений, работники департамента информационных технологий и департамента экономической безопасности Реализация комплекса защитных мер обеспечения непрерывности деятельности и контроль их исполнения, тестирование Плана, его пересмотр и обновление, обучение и повышение осведомленности работников организации
Группа первоначального реагирования Пользователи, руководители структурных подразделений, начальник управления анализа и контроля рисков, начальник отдела ИБ и ЗИ ДЭБ Выявление, локализация, классификация инцидента ИБ, определение степени ущерба и перечня восстановительных процедур
Группа восстановления Представитель ДИТ, начальник отдела ИБ и ЗИ ДЭБ, руководители структурных подразделений, пользователи Восстановление информационной и сетевой инфраструктуры, восстановление утраченной информации, проведение исправительных (корректирующих) операций
Группа кадров Представитель отдела кадров Решение вопросов, связанных с командировками и переездами
Группа административной    поддержки Представители руководства организации, руководители структурных подразделений Обеспечение работы группы восстановления, координация восстановления работы всех структурных подразделений, участвующих в деятельности организации

Эти новые решения класса _подставить_нужное_ — только очередная трата денег

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

Дальше уже не важно, как вы будете её реализовывать. Чью экспертизу задействовать – положитесь на защиту от вредоносов с помощью антивирусов, будете пытаться блокировать их на подлёте, внедрив решение типа IPS, или выберете гибридный вариант? Будут ваши затраты входить в CAPEX из-за внедрения средства защиты в инфраструктуре предприятия или весь ЦОД, вместе с системами обеспечения безопасности, поедет в облако, попадая в OPEX? Доверитесь встроенным решениям от облачного провайдера, или, уйдя в облака, предпочтёте наложенные средства? Технические средства служат автоматизации или привносят экспертизу, подсвечивая расхождения текущего состояния с лучшими практиками? Всё это будет не интересно руководству, которое спросит только, удалось ли минимизировать риски и сколько это стоит

Хотя важен не подход, а результат, лучший вариант – соблюдение баланса между трудозатратами сотрудников и использованием систем защиты. Можно пытаться обходиться без технических решений. Но если компания развивается и растёт, то растут и риски, как качественно, так и количественно. А вслед за ними – желание этими рисками управлять. В том числе, за счёт улучшения качества мониторинга – увеличения его «площади» (сегментов сети, тактик, техник) и «глубины» (не очевидное использование тех же техник, уменьшение порогов срабатывания). Чем больше угроз вы мониторите, тем больше аналитиков вам потребуется. Специалисты в дефиците, а растить их приходится годами.

Автоматизировать те, и только те процессы, которые достигли зрелости – хорошая идея. Да, на начальном этапе это трудозатраты и дополнительные требования к персоналу. Но после выполнения проекта подход приносит плоды в части операционных затрат. Другой ответ на вопрос «зачем» – не устраивает время реакции на инцидент. Если десять аналитиков примутся за одну задачу, результат не будет получен в десять раз быстрее. Но если доверить что-то автоматике, это достижимо.

Важно отличать полезное, новое техническое средство от ребрендинга чего-то старого. А систему, которая принесёт вам пользу уже сейчас, от той, которая будет мигать огоньками в стойке

А когда понадобится – устареет.

Перейдем к техническим средствам системы мониторинга.

Почему Solar JSOC

1

Опыт крупнейшего коммерческого SOC в России в противодействии киберугрозам любого уровня сложности

2

Собственная лаборатория Solar JSOC CERT и ежедневно обновляемая база знаний о новых атаках

3

Сильная команда форензеров: разбор 200+ кибератак в 2020 году, из которых 30+ были профессиональными APT

4

Отработанные процессы выявления и реагирования на кибератаки в 140+ компаниях из разных отраслей

5

Все необходимые лицензии и сертификаты (ФСТЭК России, PCI DSS, ФСБ России)

Аналитика

Эксперты Solar JSOC регулярно публикуютаналитические отчеты и исследованияв области информационной безопасности

Web

Предпринимателей в России активно атаковали банковские трояны Buhtrap и RTM. По данным «Лаборатории Касперского», распространение этих троянов значительно выросло с третьего квартала 2018 года и продолжило рост в 2019 году. Buhtrap и RTM предоставляют своим операторам полный контроль над зараженной системой, а их главным предназначением является кража средств. Buhtrap распространяется с помощью внедренного в новостные ресурсы эксплойта для известной уязвимости 2018-го года, но только если жертва пользуется браузером Internet Explorer (браузер). Таким образом, основным действенным способом защиты является своевременное обновления ПО Internet Explorer и ОС Windows. Распространяются трояны через фишинговые письма близкого к бухгалтерской тематике содержания: «отчет за период» и т.д.

Еще один инцидент связан с компрометацией пакистанского правительственного сайта кейлоггером и JS-фреймворком Scanbox (широко распространенный в 2014-2015 годах) для сбора данных пользователей сайта и отправки их злоумышленникам. Администрация сайта не сразу отреагировала на сообщение исследователей о заражении, сайт долго оставался скомпрометированным. В данном случае риск можно было бы легко устранить периодическим сканированием кода или применением WAF-решения. Обнаружить заражение исследователям удалось по подозрительным данным телеметрии. Выявление аномалий в трафике и других параметрах активности ресурса является одним из наиболее действенных способов обнаружения угроз, так же с этой целью может быть применен целый ряд методов и решений – дополнительные консультации можно получить у экспертов группы компаний Angara.

Летом было обнаружено крупное внедрение группировкой Magecart скиммингового JS-кода для кражи платежных данных в более чем 17 тысячах легитимных сайтах. Тема JS-снифферов, по данным Group-IB, активно эксплуатировалась в 2019 году. Утечки с их использованием происходили у British Airways, Ticketmaster, FILA UK и массы других онлайн магазинов. JS-сниффер, обнаруженный Group-IB в результате расследования утечки в British Airways, выполняет внедрение в код веб-сайта через уязвимость или другим способом, вплоть до брутфорса административных привилегий, и пересылает интересующие злоумышленника данные на внешний ресурс. В качестве мер защиты эксперты группы компаний Angara рекомендуют своевременно обновлять и патчить web-ресурсы, периодически использовать сканеры исходного кода и тестирование на внешнее проникновение. WAF-решения, в определенной мере, также защищают от данной атаки.

Осенью произошел взлом сайта Banks’ Integrated Reporting Dictionary (BIRD) Европейского центрального банка. Сайт был скомпрометирован и заражен вредоносным ПО, но, благодаря сегментации и физической границе между сайтом и внутренними системами банка, никакие другие данные и системы не пострадали.

Защита приложений

AST – Application Security Testing

Инструменты анализа и тестирования приложений, которые позволяют не упустить из виду уязвимости, действующие на уровне ПО. Gartner выделяет четыре основных вида AST:

  • Static AST (SAST) – тестирование методом белого ящика. Позволяет находить уязвимости исходного кода на ранних этапах разработки.
  • Dynamic AST (DAST) – тестирование методом черного ящика. Помогает находить уязвимости и слабости безопасности в работающем приложении. Подобные инструменты моделируют заранее известный список внешних атак на приложение.
  • Interactive AST (IAST) – сочетает в себе некоторые из элементов двух предыдущих подходов. Тестирование происходит в режиме реального времени, пока приложение работает в среде контроля качества или тестовой среде. Проверяется в том числе и сам код, но уже после сборки.
  • Mobile AST – выявляет и анализирует уязвимости мобильных приложений во время разработки и после нее.

SCA – Software Composition Analysis

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

WAF – Web Application Firewall

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

RASP – Runtime Application Self-Protection

Эта технология безопасности встроена или связана с приложением или средой выполнения приложения и способна контролировать его выполнение, а также обнаруживать и предотвращать атаки в реальном времени. RASP может анализировать поведение приложения и контекст, в котором оно происходит, в отличие от защиты на основе периметра. Есть два режима работы:

  • диагностика (только оповещение об угрозах);
  • самозащита (запрет подозрительных инструкций).

Положения ЦБ РФ №№ 683, 684, 607

Положение № 683-Пинформационным письмом

  • использование электронной подписи сообщений;
  • регламентация, реализация и контроль процедур:
    • идентификации, аутентификации и авторизации клиентов;
    • формирования, передачи и приема электронных сообщений;
    • удостоверения права клиентов распоряжаться д/с (в этом случае дополнительно обеспечивается использование электронных подписей и получение подтверждения от клиента о совершенной операции);
    • осуществления банковских операций, учет результатов их осуществления (в этом случае дополнительно обеспечиваются проверка соответствия выходных сообщений входным, проверка соответствия результатов банковской операции данным из электронного сообщения и направление уведомлений клиентам о проведенных операциях);
    • хранения электронных сообщений и информации об осуществленных банковских операциях;
  • обеспечение целостности и достоверности защищаемой информации, включая проверку корректности формирования и заполнения электронного сообщения, контроль дублирования и структурный контроль электронного сообщения, а также непосредственно защиту информации при передаче;
  • регистрация действий работников и клиентов, включая данные о дате и времени совершения операции, уникальный идентификатор субъекта, код технологического участка, результат выполнения операции, сетевой идентификатор использовавшегося устройства.

Положение № 684-Псообщение о переносе сроков

6. Условия активизации Плана

            Введение в действие Плана восстановления деятельности осуществляется при получении оповещения об инциденте ИБ от пользователей или системы управления информационной инфраструктурой.

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

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

К внутренним инцидентам ИБ относятся:

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

К внешним инцидентам ИБ относятся:

  • незаконный мониторинг системы;
  • вредоносные программы;
  • хищение носителей информации;
  • попытки проникновения в систему и т.д.

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

Понятие инцидента

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

Среди основных типов событий присутствуют:

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

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

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

Устранение причин и последствий события, его расследование

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

На этапе расследования от должностных лиц организации требуется:

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

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

Как расследовать утечки информации с помощью DLP-системы? Читать. 

Аномальное поведение пользователей

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

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

Еще одним признаком потенциальной компрометации учетных данных является работа сотрудника в ночное время.

Рисунок 10. Пример инцидента «Работа в ночное время»

Что нам стоит SOC построить

Чем выше бюджет проекта, чем больше проект политизирован, тем сложнее изменить его вводные. Но для решения вопросов безопасности тоже действует принцип Парето.  Добивать самые трудоёмкие 1-5-10% договора, которые не будут заметны в общем результате, не выгодно ни одной из его сторон. Проект лучше разбивать на этапы, а не гнаться за постройкой условного SOC с нуля. Это позволит учесть опыт предыдущих стадий и минимизировать риски по реализации нереализуемого, а часто и не нужного.

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

Декомпозицию на этапы можно производить вплоть до подключения «вот этих 5 видов источников» или создания «вот этих 10 сценариев и ранбуков к ним». Главное – это не полнота внедрения, а полнота использования того, что внедрено. Обосновать модернизацию эффективного решения проще, чем того, которое всплывает два раза в год в негативном контексте и стоит в десять раз дороже.

Если не знаете, что точно хотите и можете получить от автоматизации – просите пилотный проект. Но если не понимаете, что вам надо «без автоматизации» – от кого будете защищаться, куда и как ему было бы интересно проникнуть, что вам с этим делать – преимуществ от пилота будет мало. В технической части вы, вероятно, совершите скачок. Но подходит ли вам конкретный продукт – сказать будет сложно. Тут нужен консалтинг, а не внедрение технических решений. Пока вы не определитесь, что хотите автоматизировать, выбор конкретной системы не будет обоснованным. То, что показалось достаточным в ходе сегодняшнего пилота, завтра придётся подпирать костылями.

Пилот должен проводиться в рамках разумного. Я знаю организацию, которая столкнулась с невозможностью масштабирования после закупки. Не первый раз просят пилот, в котором у SIEM 30 графических панелей, 40 видов источников, 50 правил корреляции и 60 отчётов. Сделайте, а мы подумаем, покупать или обойдёмся. Интересы сторон должны сходиться. В той же части масштабирования можно согласовать решение с производителем и, например, заручиться от него гарантийным письмом.

2. Комплекс мер по защите

В целях обеспечения защиты ИВС организации следует руководствоваться перечисленными ниже правилами.

2.1 Любое неблагоприятное событие в области информационной безопасности может вызвать нарушение конфиденциальности, доступности или целостности информации (например, неавторизованный доступ к информации, потеря функциональности информационной системы, подмена информации и т.п.). При каждом инциденте необходимо предпринимать меры: информировать ответственных лиц; устранять возможные негативные последствия, предотвращать возникновение таких событий в будущем.

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

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

2.4 Отчет должен быть оформлен АИБ в течение 5 рабочих дней с момента получения информации об инциденте.

2.5 В форме отчета должно быть указано, от кого и каким образом была получена информация об инциденте, суть инцидента (кратко), состав рабочей группы, действия рабочей группы, вывод.

2.6 Отчет должен быть размещен в папке «Отчеты по инцидентам» на файл сервере организации, а также предоставлен для ознакомления начальникам УА, СБ.

2.7 Об инциденте информационной безопасности должны быть проинформированы лица, перечень которых определяет АИБ, исходя из специфики и масштаба инцидента.

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

2.9 В течение пяти рабочих дней с момента разрешения инцидента должен быть составлен финальный отчет о предпринятых действиях и принятых мерах, направленных на предотвращение возможности повторения инцидента в будущем.

Какой должна быть информация об инциденте

Чёткое указание на сотрудника, отвечающего за технические меры реагирования

Какие тут есть «подводные камни»: чтобы правильно определить такого ответственного, надо точно идентифицировать место возникновения инцидента — конкретное отделение, значимость хоста, его бизнес-принадлежность, тип происшествия

Это требует очень глубокого погружения в инфраструктуру заказчика на этапе инвентаризации (и, что очень важно, постоянной актуализации этих данных)

Эта же информация нужна для определения степени опасности инцидента. Например, на вирусное заражение машины в филиале в Магадане банк готов реагировать существенно медленнее и силами местного специалиста по информационной безопасности. Если же речь идёт о местном АРМ КБР (автоматизированное рабочее место клиента Банка России. — Прим. ред.), инцидент требует немедленного реагирования и вовлечения в том числе CISO заказчика для координации риска, а также специалистов узла связи на площадке для немедленной изоляции хоста.

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

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

Адаптированная для специалистов с бэкграундом в ИТ и без знаний в ИБ карточка инцидента

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

Базы данных и плохо защищенные ресурсы

У компании Voice Integrate Nordic AB, шведского оператора связи, произошла утечка записей звонков пользователей в медицинскую консультативную службу. Записи хранились незашифрованными в открытом доступе на незащищенном сервере. Случай продемонстрировал опасность потери конфиденциальных медицинских данных в случае халатного отношения к информационной безопасности и полного отсутствия средств защиты информации.

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

Слабая криптография послужила причиной утечки в CaféPress не только учетных данных, но и почти 50 000 паролей, которые хранились зашифрованными с помощью base64 SHA1.

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

Незащищенная база киберзлоумышленников послужила способом раскрытия крупной мошеннической сети по перепродаже недействительных билетов сайтов Ticketmaster, Groupon и др.

Заключение

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

Выводы

Только регулярные усилия позволяют добиться стабильных и высоких результатов. Этот тезис применим ко многим сторонам жизни, и в том числе — к обеспечению информационной безопасности компании.

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

Выводы

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

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

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