Примеры событий информационной безопасности

Примеры событий информационной безопасности

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

Классификация

Инциденты информационной безопасности (ИБ) представлены десятками событий, объединенных в классификацию и делящихся по нескольким признакам:

  • По уровню тяжести для профессиональной деятельности компании.
  • По вероятному возникновению рецидива – повторное «заражение».
  • По типам угроз.
  • По нарушенным свойствам ИБ.
  • По преднамеренности возникновения.
  • По уровню информационной инфраструктуры.
  • По сложности выявления.
  • По сложности устранения и т.д.

Примеры

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

  • Отказ в обслуживании. Большая категория, включающая события, которые приводят системы, сети или серверы к неспособности функционировать с прежними показателями и параметрами. Чаще всего проявляются, если пользователи в процессе авторизации получают отказ доступа. В данной группе инцидентов информационной безопасности (ИБ) выделяют несколько типов, создаваемых компьютерными и иными ресурсами: истощение и полное уничтожение ресурсов. Наиболее распространенные примеры: единовременный запуск сразу нескольких сеансов в рамках одной системы, передача данных в запрещенном формате в попытках вызвать различные нарушения или свести на «нет» их нормальную работу и т.д.
  • Сбор информации. Предусматриваются действия, связанные с установлением возможных, наиболее явных целей атаки и получением сведений о соответствующих сервисах. Инциденты в этой категории предполагают выполнение разведывательных мероприятий, чтобы выявить: наличие цели и ее потенциальные уязвимости. Распространенные примеры атак с использованием технических устройств – сброс записей DNS, отправление сообщений-тестов по «левым» координатам для поиска функционирующей системы, исследование объекта для идентификации, анализ открытых поротов на протокол передачи файлов и т.д.
  • Несанкционированный доступ. Это остальные инциденты, которые не подходят под параметры вышеперечисленных категорий. Сюда входят несанкционированные попытки получения доступа к системе или ее неправильное использование. Типичные примеры – извлечение внутренних файлов с паролями, атаки переполнения буфера с целью получения привилегированного доступа к сети, использование уязвимостей протокола для перехвата важной информации, разрушение устройств физической защиты с последующим завладением данных и т.д.

Видов и примеров самых разных инцидентов информационной безопасности (ИБ) гораздо больше. Важно вовремя отреагировать и принять меры.

Реагирование на инцидент

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

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

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

Доброго дня, уважаемый хабрахабр!

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

Читайте также:  Шкаф для роутера в квартире
Информирование об инцидентах

Перво наперво необходимо получить информацию об инциденте. Этот момент необходимо продумать ещё на этапе формирования политики безопасности и создания презентаций по ликбезу в ИБ для сотрудников.
Основные источники информации:

1. Helpdesk.
Как правило (и это хорошая традиция) о любых неполадках, неисправностях или сбоях в работе оборудования звонят или пишут в хелпдеск вашей IT-службы. Поэтому необходимо заранее «встроиться» в бизнес-процесс хелпдеска и указать те виды инцидентов, с которыми заявку будут переводить в отдел информационной безопасности.

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

3. Инциденты, обнаруженные сотрудниками ИБ.
Тут всё просто, и никаких телодвижений для организации такого канала приёма не требуется.

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

Категорирование инцидента

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

1. Разглашение конфиденциальной или внутренней информации, либо угроза такого разглашения.
Для этого необходимо иметь, как минимум, актуальный перечень конфиденциальной информации, рабочую систему грифования электронных и бумажных носителей. Хороший пример — шаблоны документов, практически на все случаи жизни, находящиеся на внутреннем портале организации или во внутренней файлопомойке, по умолчанию имеют проставленный гриф «Только для внутреннего использования».
Немного уточню про угрозу разглашения, в предыдущем посте я описывал ситуацию, когда документ с грифом «Только для внутреннего использования» был вывешен в общем холле, смежным с другой организацией. Возможно, самого разглашения и не было (вывешено было после окончания рабочего дня, да и замечено было очень быстро), но факт угрозы разглашения — на лицо!

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

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

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

5. Компрометация учетных записей.
Этот пункт перекликается с 3. Фактически инцидент переходит из 3 в 5 категорию, если в ходе расследования инцидента выясняется, что пользователь в этот момент физически и фактически не мог использовать свои учётные данные.

Классификация инцидента

С этим пунктом в работе с инцидентами можно поступить 2-мя путями: простым и сложным.
Простой путь: взять соглашение об уровне сервиса вашей IT-службы и подогнать под свои нужды.
Сложный путь: на основе анализа рисков выделить группы инцидентов и/или активов, в отношении которых решение или устранение причин инцидента должны быть незамедлительными.
Простой путь неплохо работает в небольших организациях, где не так уж и много закрытой информации и нет огромного количества сотрудников. Но стоит понимать, что IT-служба исходит в SLA из своих собственных рисков и статистики инцидентов. Вполне возможно, что зажевавший бумагу принтер на столе генерального директора будет иметь очень высокий приоритет, в том случае, как для вас важнее будет компрометация пароля администратора корпоративной БД.

Сбор свидетельств инцидента

Есть особенная прикладная наука — форензика, которая занимается вопросам криминалистики в области компьютерных преступлений. И есть замечательная книга Федотова Н.Н. «Форензика — компьютерная криминалистика». Я не буду сейчас расписывать детально аспекты форензики, просто выделю 2 основных момента в сохранении и предоставлении свидетельств, которых необходимо придерживаться.

Читайте также:  Программа контроля состояния компьютера

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

После устранения инцидента

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

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

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

Несколько советов

1. Ведите журнал регистрации инцидентов, где записывайте время обнаружения, данные сотрудника, обнаружившего инцидент, категорию инцидента, затронутые активы, планируемое и фактическое время решения инцидента, а так же работы, проведенные для устранения инцидента и его последствий.
2. Записывайте свои действия. Это необходимо в первую очередь для себя, для оптимизации процесса решения инцидента.
3. Оповестите сотрудников о наличие инцидента, что бы во-первых они не мешали вам в расследовании, во-вторых исключили пользование затронутыми активами на время расследования.

В отчёте мы собрали сводную статистику по зафиксированным в I квартале 2017 года нашим корпоративным Центром мониторинга событиям и инцидентам информационной безопасности.

Поскольку у нас есть достаточно большой набор данных:

  • 12 000 узлов на мониторинге;
  • 137 873 416 событий информационной безопасности;
  • 98 подтверждённых инцидентов;

то статистика будет применима для любой средней и крупной организации.

Данные в отчёте — это то, что видим мы, и вы можете «прикинуть» картину на свою систему обеспечения безопасности информации.

Центр мониторинга (ЦМ) компании «Перспективный мониторинг» — это сервис, который обрабатывает поступающие от подключённых систем события информационной безопасности, определяет, является ли инцидентом последовательность событий или нет, и помогает сотрудникам подключённой на мониторинг организации реагировать на инциденты.

Работает это примерно так:

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

За этот год поменялись правила выявления и учёта событий (некоторые события «склеиваются» в одно) и количество узлов на мониторинге, поэтому напрямую сравнивать количество событий и инцидентов сейчас и год назад будет не совсем правильно. Тем не менее, вся статистика за предыдущие периоды доступна в предыдущих отчётах (pdf с нашего сайта).

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

В рамках данного отчёта:

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

Источниками событий выступают сетевые и хостовые IDS, сетевые устройства, сканеры защищённости, антивирусные решения и honeypot’ы.

Для внутренней обработки мы классифицируем инциденты в зависимости от затронутых ресурсов.

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

Аналитик Центра мониторинга произвольно определяет степень критичности, если считает, что инцидент может привести к серьёзным негативным последствиям.

Результаты мониторинга

В период с 1 января по 31 марта 2017 года сотрудники Центра мониторинга контролировали информационные системы нескольких организаций с общим числом подключённых узлов около 12 000 (рабочие места, веб, почта, файловые хранилища, VPN и т.д.).

Читайте также:  Как очистить историю чата в стиме

За три месяца сенсоры зафиксировали и проанализировали 137 873 416 событий информационной безопасности и выявили 98 инцидентов.

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

На рисунке выше показано, как изменялось соотношение типов событий ИБ. Чтобы оценить размер поступающих данных, стоит упомянуть, что «Сканирование» в I квартале 2017 года — это 30% и
41 646 524 зафиксированных события; а «Подбор паролей» — 15% и почти 21 млн. событий.

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

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

«Атака или эксплуатация» — события, свидетельствующие о попытках удалённого исполнения кода или эксплуатации уязвимостей на контролируемых ресурсах.

«Сканирование» — события, свидетельствующие об исследовании сети перед попыткой атаки.

«Подбор паролей» — события, свидетельствующие о попытках получения доступа к контролируемым ресурсам путём подбора аутентификационных данных.

«Трояны и вирусы» — события, свидетельствующие о факте заражения контролируемых ресурсов вирусами или активности вредоносного ПО.

«DDoS» — события, свидетельствующие о попытках осуществления распределённых атак на отказ в обслуживании.

«Другое» — события которые по своей сути не могут быть отнесены к одному из вышеперечисленных классов.

Среди выявленных 98 инцидентов:

Класс инцидента Высокая критичность Средняя критичность Низкая критичность Всего инцидентов Доля инцидентов
Вредоносное ПО 16 20 15 51 52%
Атака 9 5 1 15 16%
Подбор паролей 11 3 14 14%
Нарушение политики ИБ 2 4 3 9 9%
Эксплуатация уязвимостей 3 3 6 6%
DDoS 3 3 3%
Всего: 98 100,0%

Доля инцидентов, %
Класс инцидента IIкв. 2016 IIIкв. 2016 IVкв. 2016 Iкв. 2017
Вредоносное ПО 43,5 42,8 51 52
DDoS 8,7 14,3 1,9 3
Нарушение политики ИБ 30,4 14,3 13,2 9
Подбор паролей 17,4 23,8 13,2 14
Атака 11,3 16
Эксплуатация уязвимостей 4,8 9,4 6

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

Одно интересное наблюдение. Сотрудники часто используют корпоративные ресурсы в своих личных целях: от распечатки доклада ребёнку в школу до доступа в личный интернет-банк. Сейчас же мы столкнулись с тем, что сотрудники майнят bitcoin и ethereum на вычислительных ресурсах организации. Такие инциденты попали в «Нарушение политики».

За предыдущий IV квартал 2016 года Центр мониторинга зафиксировал 21 788 201 событие ИБ и 53 инцидента.

Распределение инцидентов ИБ относительно дней недели в I квартале 2017 года:

Распределение инцидентов ИБ за I квартал 2017 года:

Если внимательно посмотреть на два графика выше, то видно, что «пятничный» пик инцидентов приходится на конкретный день — 17 февраля. В этот день в наш Центр мониторинга стали поступать и обрабатываться события от сети довольно крупной организации, соответственно сразу же стала видна и была зафиксирована в статистике вредоносная активность, уже присутствовавшая в этой сети. Постепенно по мере реагирования на эти инциденты количество новых зафиксированных инцидентов снижалось.

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

ТОП источников

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

На графике отражено расположение первой сотни IP-адресов по количеству зарегистрированных событий. Большинство таких адресов расположено в России, США и Германии, хотя, конечно, нельзя утверждать, что атакующие были именно из этих стран.

Есть одна интересная особенность. Во II и III кварталах 2016 года среди лидеров по количеству IP-адресов, с которых осуществлялись атаки, был Китай. В IV квартале 2016 года и в I квартале 2017 года ситуация очень сильно изменилась — мы не зафиксировали вредоносной активности оттуда. Предполагаем, что злоумышленники перешли на российские прокси.

ТОП подверженных инцидентам сегментов

Ситуация по целям атак изменилась непринципиально: наибольшую активность злоумышленники проявляли в отношении пользовательских рабочих мест. На этот сегмент приходится больше половины всех инцидентов.

Ссылка на основную публикацию
Adblock detector