Что такое компьютерный инцидент

Инциденты информационной безопасности – выявление и расследование

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

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

Есть несколько основных рисков внутри корпораций и фирм:

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

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

Аномалии, с которыми сталкиваются предприятия можно классифицировать по следующим признакам:

Существует категорирование инцидентов, позволяющее прописать их в политике безопасности и предотвращать их уже по первым признакам:

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

2. Угроза или разглашение конфиденциальной информации. Для этого нужно получить доступ к актуальному списку конфиденциальных данных.

3. Превышение полномочий определенными лицами. Речь идет о несанкционированном доступе работников к определенным ресурсам или офисным помещениям.

Что делать при обнаружении инцидента?

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

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

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

Реагирование на утечку данных

При обнаружении нарушений в сети организации рекомендован следующий алгоритм действий со стороны службы информационной безопасности:

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

2. Координация работы по прекращению влияния информационных атак, проведение которых спровоцировало появление инцидента.

3. Анализ всего сетевого трафика.

4. Локализация события.

5. Сбор важных данных для установления причин происшествия.

6. Составление перечня мер, направленных на ликвидацию последствий инцидента, который нанес урон.

7. Устранение последствий.

8. Контроль устранения последствий.

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

Выявление причин инцидента безопасности

Анализ ситуации позволяет оценить риски и возможные последствия инцидента.

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

По факту расследования составляют перечень мер, направленных на профилактику аналогичных кибератак. Дополнительно составляется список действий моментального реагирования в случае, если имело место проникновение вредоносного ПО в систему. Нужно провести обучение персонала фирмы для повышения киберграмотности.

Решения для информационной безопасности организации

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

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

Источник

Работа с инцидентами информационной безопасности

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

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

Информирование об инцидентах

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

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. Оповестите сотрудников о наличие инцидента, что бы во-первых они не мешали вам в расследовании, во-вторых исключили пользование затронутыми активами на время расследования.

Источник

Как происходит обмен информацией об инцидентах и уязвимостях в системе ГосСОПКА

В системе ГосСОПКА скапливается огромное количество данных о произошедших в стране киберинцидентах. Эта информация способна стать для каждого безопасника полезнейшим инструментом, который поможет оперативно обнаружить злоумышленника внутри организации. Однако не все знают, как формируется эта база данных, в каком виде информация передаётся в НКЦКИ и как рассылается субъектам КИИ.

Введение

С самого появления системы ГосСОПКА многие субъекты критической информационной инфраструктуры воспринимали обязанность передавать сообщения о киберинцидентах как нечто навязанное регулятором. Даже сегодня, несмотря на всеобщее порицание «бумажной безопасности» и декларирование ориентации на реальную киберзащиту, большинство организаций в основном интересует вопрос формального выполнения требований, чтобы избежать штрафов или внезапных проверок.

К сентябрю 2019 года все субъекты КИИ уже должны были провести категорирование своих объектов, а к сентябрю 2020-го — выстроить систему защиты информации значимых объектов КИИ в соответствии с требованиями ФСТЭК России и подключиться к ГосСОПКА. Однако эта работа до сих пор не завершена, и многие организации только сейчас начинают задумываться об исполнении указанных выше требований.

Проблема в том, что, в представлении многих владельцев КИИ, если не передавать требуемые данные в ГосСОПКА, то за ними непременно приедет «чёрный воронок», а если передавать, то приедет ещё быстрее, причём с проверкой и вопросами: «Почему это вы так плохо информацию защищаете?». К тому же в Госдуме сейчас обсуждаются поправки в КоАП, которые вводят штраф до 500 тыс. рублей за отсутствие сообщений об инциденте в ГосСОПКА.

На самом деле НКЦКИ — это не карательный орган и не «телефон доверия» для жертв киберпреступников. ГосСОПКА — это огромное «озеро данных» (Data Lake), где скапливается информация о произошедших в стране инцидентах. Система даёт участникам информационного обмена необходимые сведения для защиты от компьютерных атак, направляя сообщения об уязвимостях в ПО и бюллетени по безопасности со сводкой актуальных угроз.

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

Какие данные о субъекте КИИ получает НКЦКИ

Когда центр ГосСОПКА (корпоративный или аутсорсинговый) принимает в свою зону ответственности информационные ресурсы, он передаёт в НКЦКИ следующие данные:

Эта информация помогает НКЦКИ актуализировать и персонализировать для потребителей передаваемые бюллетени по безопасности, чтобы, например, в организацию, где все процессы построены на Windows-стеке, не приходила сводка уязвимостей по Astra Linux.

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

В каком виде данные передаются в ГосСОПКА

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

Эти полученные от участников ГосСОПКА карточки становятся основным источником для формирования бюллетеней по безопасности, которые рассылает НКЦКИ для предотвращения подобных инцидентов в схожих инфраструктурах других компаний.

Что происходит внутри НКЦКИ

Сбор данных и формирование IOC и бюллетеней по ИБ выглядят следующим образом (рис. 1).

Рисунок 1. Сбор данных внутри ТИ НКЦКИ

Примечание: КИ — компьютерный инцидент, УБИ — угроза безопасности информации, СИБ — события по информационной безопасности

Все данные об инцидентах от субъектов КИИ (через ГосСОПКА и другие каналы связи, например электронную почту) поступают во внутреннюю IRP-систему НКЦКИ, где под каждое сообщение заводится карточка. Для каждой из карточек прописывается свой регламент (playbook), назначается ответственный, происходят обогащение полученных данных и выдача рекомендаций по реагированию.

Источники атаки проверяются по внутренним репутационным базам НКЦКИ, а при выявлении угрозообразующих факторов для других субъектов ГосСОПКА, которые являются КИИ, этим субъектам отправляются уведомления о признаке компьютерного инцидента.

Кроме обеспечения информационного взаимодействия и координации участников ГосСОПКА НКЦКИ помогает в выявлении инцидентов путём анализа пользовательского DNS-трафика, а также анализирует подозрительные (потенциально вредоносные) почтовые сообщения или файлы.

Как SOC обрабатывает бюллетени по ИБ

Для подключения к инфраструктуре НКЦКИ субъект КИИ может использовать собственную сеть (ПАК ViPNet, «Континент», «С-Терра Шлюз») или воспользоваться услугами центра мониторинга (центр ГосСОПКА), заключившего соглашение с НКЦКИ.

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

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

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

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

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

Выводы

Особое внимание в системе отведено центрам ГосСОПКА, к которым предъявляются отдельные требования со стороны регулятора. В их зоне ответственности сконцентрировано множество информационных ресурсов критической инфраструктуры страны, а значит, от них требуется оперативно и качественно реагировать на возникающие угрозы. Для этого в центрах ГосСОПКА должно слаженно работать множество разнопрофильных специалистов (по мониторингу, по ликвидации последствий киберинцидента, а также пентестеры, технические эксперты, аналитики-архитекторы и т. д.). Подробнее о том, какой может быть оптимальная команда центра ГосСОПКА, можно прочитать здесь.

Субъектам КИИ, которые подключаются к ГосСОПКА через сервис-провайдера, не нужно решать сложный кадровый вопрос, но в то же время им необходимо тщательно подойти к выбору стороннего SOC. В частности, для реального соответствия званию центра ГосСОПКА центр мониторинга должен решать задачи не только анализа рисков, но и киберразведки (Threat Intelligence). Именно TI позволяет выделить наиболее актуальные для определённой организации угрозы и внести превентивные изменения в инфраструктуру (выделить новый сегмент сети, повысить частоту обновления антивирусных баз или степень значимости части хостов). Безусловно, «правильный» SOC должен обладать множеством других характеристик, но об этом мы тоже уже писали ранее.

Источник

Статьи по теме: «Информационная безопасность»

Состав технических параметров компьютерного инцидента, указываемых при представлении информации в ГосСОПКА, и форматы представления информации о компьютерных инцидентах

Форматы представления информации о компьютерных инцидентах (компьютерных атаках, уязвимостях) в государственную систему обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Российской Федерации (далее – ГосСОПКА) в формате JSON доступны по ссылке:

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

Дополнительно, субъекты КИИ и другие владельцы российских информационных ресурсов имеют право уведомлять НКЦКИ о компьютерных атаках, зафиксированных на принадлежащих им объектах КИИ или других системах, а также уязвимостях в них. В целях унификации сведений, передаваемых в ходе информационного взаимодействия между НКЦКИ и субъектом КИИ, НКЦКИ и владельцами российских информационных ресурсов, НКЦКИ и иностранными (международными) организациями, выделяются следующие базовые категории и типы событий, по которым инициируется такое информационное взаимодействие (таблица 1).

Таблица 1 – Базовые категории и типы событий, по которым инициируется информационное взаимодействие.

Указанные категории и типы событий могут быть направлены в/от НКЦКИ в форме следующих уведомлений:

Таблица 2 – «Уведомление о компьютерном инциденте» (направляется субъектом ГосСОПКА в адрес НКЦКИ) и «Уведомление о признаке компьютерного инцидента» (направляется дежурной службой НКЦКИ в адрес субъекта ГосСОПКА).

Таблица 3 – «Уведомление о компьютерной атаке» (направляется субъектом ГосСОПКА в адрес НКЦКИ).

Таблица 4 – «Уведомление об уязвимости» (направляется субъектом ГосСОПКА в адрес НКЦКИ) и «Уведомление о признаке уязвимости» (направляется дежурной службой НКЦКИ в адрес субъекта ГосСОПКА).

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

С такими иностранными (международными) организациями субъекты КИИ должны взаимодействовать через НКЦКИ, за исключением случаев, когда прямой обмен между субъектом КИИ и такой организацией предусмотрен международным договором Российской Федерации.

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

В случаях, когда субъекту КИИ требуется через НКЦКИ отправить «Обращение в иностранную (международную) организацию», необходимо оформлять такое обращение с учетом формализованных НКЦКИ категорий и типов компьютерных инцидентов, а также указывая максимально полный состав технических сведений.

Таким образом, субъект КИИ должен определиться с характером уведомления (инцидент, атака, уязвимость) в иностранную (международную) организацию, предоставить имеющиеся в его распоряжении технические сведения и дополнительно указать:

НКЦКИ со своей стороны будет в установленные приказом сроки рассматривать такие обращения и предоставлять субъекту КИИ информацию следующего характера:

Источник