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

Пассивная разведка заключается в получении информации без непосредственного воздействия на атакуемую ИС (например, просмотр DNS и Whois информации, связанной с ИС организации).

Активная разведка включает в себя взаимодействие с атакуемой ИС: сканирование портов, поиск уязвимостей ИС и другие действия.

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

2

Подготовка (выбор способа атаки)

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

Злоумышленник внедряет ПО, которое будет использоваться при атаке, в файлы MS Office (.docx, .xlsx), PDF-документы, электронные письма или на съёмные носители. На этом же этапе происходит выбор способа доставки созданного вредоносного ПО в атакуемую организацию: с помощью заражения публичного ресурса компании, через одного из сотрудников или через компрометацию компаний-субподрядчиков, работающих с атакуемой организацией.

3

Доставка

Атакующий должен обеспечить попадание разработанного на прошлом шаге вредоносного ПО в ИС атакуемой организации. Обычно для этого используются вложения электронной почты, вредоносные и фишинговые ссылки, watering hole-атаки (заражения сайтов, которые посещают сотрудники атакуемой организации) или зараженные USB-устройства.

4

Эксплуатация

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

Команды от злоумышленника могут поступать как через интернет, так и с помощью доставки другого вредоносного ПО (например, если на машине отсутствует прямое подключение к интернету).

5

Закрепление

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

6

Управление

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

7

Действие

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

Основные этапы процесса реагирования на инциденты ИБ

Организация процесса реагирования на инцидент преследует следующие цели:

- предупредить нескоординированные действия и в кратчайшие сроки восстановить работоспособность компании при возникновении инцидента;

- представить детализированный отчет о произошедшем инциденте и полезные рекомендации;

- создать условия для накопления и хранения точной информации о компьютерных инцидентах;

- обеспечить быстрое обнаружение и/или предупреждение подобных инцидентов в будущем (путем анализа случившихся в прошлом инцидентов, изменения политики ИБ, модернизации системы ИБ);

- обеспечить сохранность и целостность доказательств произошедшего инцидента;

- создать условия для возбуждения гражданского или уголовного дела против злоумышленника;

- минимизировать нарушение порядка работы и повреждения данных информационных систем, оборудования;

- минимизировать последствия нарушения конфиденциальности, целостности и доступности системы;

- провести обучение сотрудников реагированию на инцидент. [9]

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



Рис. 2.4 Алгоритм выявления и реагирования на инциденты ИБ

Попробуем кратко рассмотреть основные составляющие процесса ликвидации инцидента (рис. 2.6).

Рис. 2.6 Процесс реагирования на инциденты ИБ

Подготовка.

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

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

Обнаружение.

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

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

Сбор индикаторов компрометации является итерационным процессом (рис. 2.6).

Рис. 2.6 Сбор индикаторов компрометации

Дальнейшие шаги предпринимаются, только если событие решено считать инцидентом ИБ.[8]

Для обнаружения уязвимостей в ИС проводится процедура аудита информационной безопасности, которая состоит из двух этапов - анализа текущего уровня защищённости ИС и разработки предложений по устранению выявленных уязвимостей. Аудит состоит из комплекса проверок, часть из которых направлена на обнаружение и устранение уязвимостей. Выявление уязвимостей используется для анализа защищённости ПО, которое уже установлено и функционирует в ИС. Метод предполагает использование специализированных программных средств - так называемых сканеров безопасности или систем анализа защищённости. Эти средства позволяют обнаруживать уязвимости на основе активного и пассивного методов. При помощи пассивного метода осуществляется сбор информации о настройках ПО, присутствующего в ИС и на основе этих данных делается вывод о наличии или отсутствии в системе уязвимостей. Активные методы анализа защищённости приложений имитируют информационные атаки и затем на основе анализа результатов делается вывод о наличии уязвимостей в системе. Использование пассивных и активных методов анализа защищённости приложений ИС позволяет выявить эксплуатационные уязвимости конфигурации ПО.[6]

Сдерживание

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

Удаление.

Цель этого этапа - привести скомпрометированную ИС в состояние, в котором она была до вторжения. Сотрудники, ответственные за ИБ, удаляют вредоносное ПО, а также все артефакты, которые оно могло оставить на зараженных компьютерах в ИС.

Восстановление.

Ранее скомпрометированные компьютеры вводятся обратно в сеть. При этом сотрудники, ответственные за ИБ, некоторое время продолжают наблюдать за состоянием этих машин и ИС в целом, чтобы убедиться в полном устранении угрозы. Устранение уязвимостей в этом случае возможно путём установки соответствующих модулей обновления (service packs, hotfixes, patches и др.) или изменения настроек используемого ПО.

Выводы

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

При невозможности полного предотвращения будущей атаки составленные рекомендации позволят ускорить реагирование на подобные инциденты.[8]

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

Планирование и подготовка

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

В соответствии с ГОСТ Р ИСО/МЭК ТО 18044-2007 для обеспечения эффективности реакции на инциденты ИБ необходимо:

- разработать и документировать политики менеджмента инцидентов ИБ, а также получить очевидную поддержку этой политики заинтересованными сторонами и, в особенности, высшего руководства;

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

- обновить политики менеджмента ИБ и рисков на всех уровнях, то есть на корпоративном и для каждой системы, сервиса и сети отдельно с учетом системы менеджмента инцидентов ИБ;

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

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

- тщательно тестировать систему менеджмента инцидентов ИБ.

Обнаружение и анализ инцидентов информационной безопасности

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

Основные источники информации:

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

- сообщения непосредственно от пользователей;

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

- журналы и оповещения систем, средств антивирусной защиты.

Необходимо настроить оповещения в консоли антивируса и других систем безопасности. Особое внимание уделяется точкам соприкосновения с внешней сетью и местам хранения чувствительной информации. [11]

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

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

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

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

- текущий статус расследования;

- описание инцидента;

- действия, производимые командой реагирования в процессе обработки инцидента;

- список факторов расследования с описанием их функций и процентом занятости в процедуре расследования;

- перечень свидетельств (с обязательным указанием источников), собранных в ходе обработки инцидента;

- комментарии участников расследования инцидента;

- описание последующих действий и состояние процесса;

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

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

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

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

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

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

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

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

6. Физическое уничтожение носителей информации. Здесь необходимо определить было физическое уничтожение преднамеренным или неумышленным.

При сборе свидетельств инцидента необходимо выделить 2 основных момента в сохранении и предоставлении свидетельств, которых необходимо придерживаться:

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

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

Стратегия противодействия распространению последствий инцидента

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

- потенциальное возможное повреждение или кража данных;

- потребность в сохранности свидетельств инцидента;

- доступность данных;

- количество времени и необходимые ресурсы для реализации противодействия;

- эффективность стратегии противодействия (частичное или полное решение проблемы);

- срок действия стратегии (неделя, месяц, квартал и т.д.).

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

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

Сбор свидетельств инцидента и их обработка, идентификация нарушителя

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

- идентификация источника (местоположение, ID, имя хоста, MAC- адрес, IP-адрес, и т.п.);

- данные сотрудников, обращавшихся за помощью;

- дата и время каждого свидетельства;

- местоположение ресурса хранения свидетельства;

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

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

ликвидации последствий инцидента ИБ

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

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

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

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

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

- переоценка рисков, повлекших возникновение инцидента;

- подготовка перечня защитных мер для минимизации выявленных рисков, в случае повторения инцидента;

- актуализация необходимых политик, регламентов, правил ИБ;

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

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

Хранение материалов расследования инцидентов ИБ

Типичными метриками для хранения данных инцидента являются:

- количество обработанных инцидентов информационной безопасности;

- среднее время, затрачиваемое на обработку одного инцидента;

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

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

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

- возможные разбирательства в суде;

- время хранения свидетельств;

- стоимость хранения (стоимость эксплуатации носителей и систем).

ЗАКЛЮЧЕНИЕ

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

- обеспечение совершенствования Системы обеспечения безопасности информации в рамках управления информационной безопасностью;

- минимизация (предотвращение) негативных последствий возникновения инцидентов информационной безопасности;

- недопущение (снижение угрозы) возникновения инцидентов;

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

- обеспечение своевременного выполнения процедур управления инцидентами информационной безопасности;

- обеспечение осведомлённости пользователей о необходимости реагирования на инциденты;

- создание, развитие и поддержание функционирования системы управления инцидентами;

- обеспечение функционирования группы реагирования на инциденты информационной безопасности.

Список литературы

информационная безопасность аудит

1. ISO/IEC 27001\ГОСТ Р ИСО/МЭК 27001.

2. ISO/IEC TR 18044:2004\ ГОСТ Р ИСО/МЭК ТО 18044-2007.

3. NIST SP 800-61 «Computer security incident handling guide».

4. CMU/SEI-2004-TR-015 «Defining incident management processes for CSIRT».

5. https://rtmtech.ru - официальный сайт компании «RTM Group»

6. https://www.intuit.ru/ - официальный сайт национального открытого университета «Интуит».

7. https://xakep.ru - Официальный сайт журнала «Хакер».

8. Kaspersky Lab, «Руководство по реагированию на инциденты информационной безопасности» электронный документ версия 1.0

9. http://www.topsbi.ru - официальный сайт компании «TopS Business Integrator» (TopS BI)

10. Реагирование на инциденты информационной безопасности: цели и алгоритм. Международный научный журнал «Инновационная наука» (№9/2016 issn 2410-6070), статья.

11. https://habr.com/ru - «Работа с инцидентами информационной безопасности», статья.

12. http://www.iso27000.ru - (ЗАЩИТА-ИНФОРМАЦИИ.SU) - авторитетный информационно-аналитический портал сообщества менеджеров и экспертов в области информационной безопасности.

13. https://fstec.ru/ - официальный сайт Федеральной службы по техническому и экспортному контролю.

14. Федеральный закон от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации».

15. Приказ ФСТЭК № 17 (ред. от 28.05.2019) "Об утверждении Требований о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах".

ПРИЛОЖЕНИЕ

РЕГЛАМЕНТ

обнаружения, реагирования и расследования инцидентов информационной безопасности в Межрайонной ИФНС России

I. Общие положения и основные понятия

1.1. Настоящий Регламент обнаружения, реагирования и расследования инцидентов информационной безопасности (далее - Регламент) в Межрайонной ИФНС России (далее - Инспекция) устанавливает порядок обнаружения, регистрации, реагирования и устранения последствий инцидентов информационной безопасности (далее - ИБ) в целях быстрого устранения последствий произошедшего инцидента, минимизации потерь и недопущения повторения подобных инцидентов в будущем.

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

Регламент разработан в соответствии с «Политикой управления инцидентами информационной безопасности ФНС России», утвержденной Приказом ФНС России № СД-7-24/167@ от 26.02.2021.

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

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

1.3. Настоящий регламент при необходимости должен пересматриваться (актуализироваться) после каждого инцидента ИБ.

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

II. Основные задачи регламентирования и цели расследования инцидентов ИБ

2.1. Основные задачи регламентирования расследования инцидентов ИБ:

- координация реагирования на инцидент;

- подтверждение / опровержение факта возникновения инцидента ИБ;

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

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

- минимизация последствий нарушения конфиденциальности, целостности и доступности информации информационных систем;

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

- защита репутации налоговых органов и его информационных ресурсов;

- быстрое обнаружение и/или предупреждение подобных инцидентов в будущем;

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

2.2. Цели расследования инцидентов ИБ:

- локализация и ликвидация последствий инцидентов ИБ;

- установление виновных лиц и их мотивации, обеспечение возможности привлечения их к ответственности;

- анализ инцидентов и принятие мер по предотвращению подобных в будущем.

III. Признаки инцидента ИБ

3.1. Основные признаки инцидента ИБ:

- нарушение требований руководящих документов по информационной безопасности;

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

- уведомление антивирусной программы;

- обнаружение посторонних установленных программ, программ явно деструктивного действия или программ-взломщиков (программы-сканеры);

- выявление несанкционированного изменения (удаления) записей в базах данных);

- резкое снижение скорости работы с сетевыми информационными ресурсами;

- появление файлов с нечитабельными названиями;

- самопроизвольное исчезновение или перемещение файлов;

- появление в почтовых ящиках множества повторяющихся сообщений или спама;

- фиксация в системных журналах множественных неудачных попыток авторизации;

- фиксация резкого увеличения сетевого трафика и т.д.

IV. Действия при обнаружении инцидента ИБ

4.1. Действия пользователей локально-вычислительной сети Инспекции при обнаружении инцидента ИБ:

- о фактах или подозрениях, о возникновении какого-либо инцидента ИБ незамедлительно оповестить администратора ИБ и отдел информатизации Инспекции;

- прекратить работу на АРМ, на котором произошел (происходит) инцидент ИБ, до получения разрешения от администратора ИБ Инспекции;

- возобновить работу на АРМ только после выяснения причин инцидента ИБ и получения разрешения от администратора ИБ Инспекции;

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

4.2. Действия администратора ИБ Инспекции и отдела информатизации Инспекции при обнаружении инцидента ИБ:

- все полученные сообщения об инциденте ИБ, а также информацию об инцидентах ИБ, выявленные работниками отдела информатизации, в том числе полученные с использованием программных средств, внести в журнал регистрации инцидентов ИБ (приложение 1 к Регламенту);

- по факту обнаружения провести анализ информации об инциденте, полученной от первоисточников: сообщения сотрудников Инспекции, сообщения администраторов информационной системы, системные журналы (в т.ч. журналы систем обнаружения вторжений и т.д.);

- по результатам анализа принять решение о подтверждении или опровержении возникновения инцидента ИБ;

- в случае подтверждения инцидента ИБ выяснить его серьезность и масштабы распространения;

- купировать вторжение и предотвратить дальнейшее повреждения компонентов информационной системы и/или кражу данных, изолировав поражённую систему или ПК путём разрыва сетевого соединения;

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

- оценив последствия, отключить или заблокировать сервисы, используемые злоумышленниками или вредоносным ПО;

- удалить вредоносное ПО из системы;

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

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

V. Расследование инцидента ИБ

5.1. Расследование Инцидента ИБ, состоит из следующих этапов:

подтверждение/опровержение факта возникновения Инцидента ИБ;

классификация инцидента ИБ;

подтверждение/корректировка уровня значимости Инцидента ИБ;

уточнение дополнительных обстоятельств (деталей) Инцидента ИБ;

получение (сбор) доказательств возникновения Инцидента ИБ, обеспечение их сохранности и целостности;

минимизация последствий Инцидента ИБ;

информирование и консультирование персонала Управления по действиям обнаружения, устранения последствий и предотвращения инцидентов ИБ;

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

5.2.В процессе проведения разбирательства Инцидента ИБ обязательными для установления являются:

дата и время совершения Инцидента ИБ;

ФИО, должность и подразделение Нарушителя ИБ;

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

уровень критичности Инцидента ИБ;

обстоятельства и мотивы совершения Инцидента ИБ;

информационные ресурсы, затронутые Инцидентом ИБ;

характер и размер реального и потенциального ущерба;

обстоятельства, способствовавшие совершению Инцидента ИБ.

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

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

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

5.5. В течение 3 (трех) рабочих дней с момента выявления инцидента ИБ администратор ИБ запрашивает у начальника структурного подразделения объяснительную записку Нарушителя ИБ. Объяснительная записка должна быть составлена, подписана Нарушителем ИБ и представлена его непосредственным руководителем администратору ИБ в течение 3 (трех) рабочих дней с момента поступления запроса.

5.6. Администратор ИБ проводит оценку негативных последствий от реализации Инцидента ИБ. В ходе данной оценки учитываются;

прямой финансовый ущерб;

репутационный ущерб;

потенциальный ущерб;

косвенные потери, связанные с недоступностью сервисов, потерей информации;

другие виды ущерба или аспекты негативных последствий для Инспекции или субъектов персональных данных.

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

VI. Устранение последствий инцидента ИБ

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

Деятельность по восстановлению после инцидента ИБ должна быть согласована с отделами, участвующими в инциденте и может быть делегирована для выполнения соответствующим администраторам ИБ, ответственным за функционирование информационной системы, либо сотрудникам ФКУ «Налог-Сервис».

6.2. После устранения последствий воздействия злоумышленников или вредоносного ПО необходимо:

а) восстановить данные и функциональность поражённых систем;

б) при необходимости, установить временные меры, принятые при реагировании на угрозу:

- провести разработанные мероприятия, направленные на предупреждение подобных инцидентов в будущем;

- в случае необходимости произвести дополнительный инструктаж пользователей и/или администраторов поражённой системы;

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

- при необходимости внести изменения в структуру информационной системы (изменения сетевых взаимодействий, реконфигурация ПО и т.д.).

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

- переоценка рисков, повлекших возникновение инцидента;

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

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

VII. Оформление результатов проведенного расследования

7.1. Собранная в процессе расследования Инцидента ИБ информация фиксируется администратором ИБ в карточке данных «Инциденты ИБ» (приложение 2 к Регламенту) и учитывается при подготовке итогового заключения по Инциденту ИБ.

7.2.Администратор ИБ формирует, согласовывает со всеми участниками разбирательства и подписывает итоговое заключение по расследованию Инцидента ИБ.

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

7.4.Администратор ИБ фиксирует завершение расследование в карточке «Инциденты ИБ» и присваивает инциденту статус «Расследование завершено».

7.5. Администратор ИБ, при необходимости определения правовой оценки Инцидента ИБ, может обратиться за консультациями в правовой отдел.

7.6. В случае выявления в Инциденте ИБ признаков административного правонарушения или уголовного преступления, относящихся к сфере информационных технологий, администратор ИБ передает все материалы по Инциденту ИБ руководству Инспекции для принятия решения о подаче заявления в правоохранительные органы Российской Федерации.

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

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

- время хранения устанавливается - не менее 5 лет.

к Регламенту обнаружения, реагирования и расследования инцидентов информационной безопасности в Межрайонной ИФНС России

Журнал регистрации инцидентов информационной безопасности в Межрайонной ИФНС России

№ п/п	Описание выявленного инцидента	Дата и время выявления инцидента	Кем выявлен инцидент	Способ выявления инцидента	Дата и время регистрации инцидента	Результат проверки инцидента (нарушения)	Область распространения (АРМ, ЛВС, ИС)	Сотрудник, ответственный за устранение инцидента	Подпись сотрудника группы реагирования

к Регламенту обнаружения, реагирования и расследования инцидентов информационной безопасности в Межрайонной ИФНС России

Карточка данных инцидента ИБ № _____ от «___» __________20___ г. № и дата из Журнала регистрации инцидентов ИБ

Информация о сообщающем лице

Ф.И.О.
Код ИФНС		Отдел
Телефон		e-mail

Описание события ИБ

Что произошло
Как произошло
Почему произошло
Пораженные компоненты
Негативное воздействие
Любые идентифицированные уязвимости на АРМ на данный момент

Детали события/инцидента ИБ

Дата и время возникновения события	Дата и время обнаружения события	Дата и время сообщения о события

Краткая классификация события

Закончилось ли событие?		Да		Нет
Если «Да» то уточнить, как долго длилось событие (дни/часы/минуты)

Тип инцидента ИБ (Описание инцидента информационной безопасности)

№ п/п	Описание (Приложение №1, иное)	Текущий	Значимый	Имеющий признаки преступления

Нарушение целостности активов (оборудования, информации, программного обеспечения и т.п.)

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

Негативное воздействие / влияние инцидента

	V	Описание
Нарушение конфиденциальности
Нарушение целостности
Нарушение доступности
Нарушение неотказуемости
Уничтожение

Разрешение инцидента

Дата начала расследования инцидента
Дата окончания расследования инцидента
Дата окончания инцидента
Дата окончания воздействия
Ссылка и место хранения электронных материалов отчета о расследовании
Список лиц, проводившие расследование инцидента

Причастные лица

Физическое лицо
Учреждение (организация)
Организованная группа
Случайность
Нет виновного (природные факторы, отказ оборудования и т.п.)

Описание нарушителя

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

Мотивация

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

Действия, предпринятые для разрешения инцидента

«Никаких действий», «решен подручными средствами», «внутреннее расследование», «внешнее расследование с привлечением…», ссылка на программные средства, материалы, использованные для разрешения инцидента

Действия, запланированные для разрешения инцидента

«Никаких действий», «решен подручными средствами», «внутреннее расследование», «внешнее расследование с привлечением…», ссылка на программные средства, материалы, использованные для разрешения инцидента

Прочие действия

Дополнительные мероприятия, необходимые для завершения инцидента, завершения расследования и т.п.

Заключение

		Краткое объяснение
Значимость инцидента	- значительный - незначительный - другие заключения

Ознакомленные лица

Структурное подразделение, должность
		подпись		(Ф.И.О.)		дата

Привлеченные лица

Организация, должность
		подпись		(Ф.И.О.)		дата

Размещено на Allbest.ru

...