Это интересно

  • ОКД
  • ЗКС
  • ИПО
  • КНПВ
  • Мондиоринг
  • Большой ринг
  • Французский ринг
  • Аджилити
  • Фризби

Опрос

Какой уровень дрессировки необходим Вашей собаке?
 

Полезные ссылки

РКФ

 

Все о дрессировке собак


Стрижка собак в Коломне

Поиск по сайту

Главная » Журнал » Журнал инцидентов информационной безопасности

Обработка инцидентов информационной безопасности (Часть 3). Журнал инцидентов информационной безопасности


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

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

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

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

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

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

habrahabr.ru

Обработка инцидентов информационной безопасности (Часть 3) — ISO27000.ru

Сергей Романовский, [email protected]

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

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

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

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

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

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

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

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

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

Идентификация нарушителя

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

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

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

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

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

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

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

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

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

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

  • возможные разбирательства в суде
  • время хранения свидетельств
  • стоимость хранения (стоимость эксплуатации носителей и систем)

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

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

Литература

  2. BS 25999-1:2006 Управление непрерывностью бизнеса – Часть1: Практические правила

  3. .BS ISO/IEC 27001:2005 Информационные технологии. Методы обеспечения безопасности. Системы управления информационной безопасностью. Требования

  4. ISO13335-1:2004 Информационные технологии. Руководство по управлению ИТ безопасностью. Концепции и модели для управления безопасностью информационных и телекоммуникационных технологии)

www.iso27000.ru

Обработка инцидентов информационной безопасности (Часть 2) — ISO27000.ru

Сергей Романовский, [email protected]

Превентивные мероприятия

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Документирование событий инцидента информационной безопасности необходимо для сбора и последующей консолидации свидетельств расследования. Документированию подлежат все факты и доказательства злонамеренного воздействия. Различают технологические свидетельства и операционные свидетельства воздействия. К технологическим свидетельствам относят информацию, полученную от технических средств сбора и анализа данных (сниферы, IDS), к операционным – данные или улики, собранные в процессе опроса персонала, свидетельства обращений на service desk, звонки в call center.

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

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

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

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

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

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

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

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

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

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

Литература

  2. BS 25999-1:2006 Управление непрерывностью бизнеса – Часть1: Практические правила

  3. BS ISO/IEC 27001:2005 Информационные технологии. Методы обеспечения безопасности. Системы управления информационной безопасностью. Требования

  4. ISO13335-1:2004 Информационные технологии. Руководство по управлению ИТ безопасностью. Концепции и модели для управления безопасностью информационных и телекоммуникационных технологии)

www.iso27000.ru

Обработка инцидентов информационной безопасности (Часть 1) — ISO27000.ru

Сергей Романовский, [email protected]

Принципы реализации

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

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

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

  • созданию формализованной политики реагирования на инциденты

  • разработке процедур обработки инцидентов

  • урегулированию юридических аспектов обращения информации в процессе расследования

  • утверждению структуры команды реагирования на инциденты

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

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

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

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

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

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

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

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

  • урегулированию проблемы несоразмерного разглашения служит создание, так называемых, контактных позиций (POC - point of contact), структура и правомочность которых оговаривается на этапе формирования политики расследования инцидентов и представляет собой юридически закреплённую доверительную среду участников информационного обмена

Информирование о результатах расследования инцидента своих сотрудников и партнёров.

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

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

Формализация принципов приоритезации событий информационной безопасности.

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

  • действия команды по расследованию инцидентов должны быть формализованы и представлены в виде Соглашения об уровне обслуживания (SLA - Service Level Agreement), где подробно определяются действия каждого сотрудника и время реакции на определённые события

Анализ инцидентов и обработка результатов с целью получения практического опыта:

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

  • понимание причинно-следственных связей в процессе расследования сложных инцидентов

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

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

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

  • понимание руководством организации необходимости реагирования на инциденты информационной безопасности
  • управление процедурой расследования инцидентов информационной безопасности
  • определение целей и места политики расследования инцидентов в общей структуре процессов управления безопасностью и организацией в целом (политика расследования инцидентов является частью процесса обеспечения непрерывности функционирования организации)
  • определение понятий “инцидент информационной безопасности” и “последствия инцидента информационной безопасности” в контексте сферы деятельности организации
  • описание состава, структуры, функциональных обязанностей, зон ответственности, ролей, правил внутриорганизационного взаимодействия, порядка внешних сношений команды по расследованию инцидентов информационной безопасности
  • порядок установления приоритетов инцидентов и оценки серьёзности последствий инцидентов информационной безопасности
  • оценка критериев качества работы команды по расследованию инцидентов
  • разработка форм отчётности и регламента оповещений об инциденте
  • разработка набора процедур, описывающих действие сотрудников организации в случае инцидента информационной безопасности (выделенный телефон, адрес электронной почты)
  • разработка стандартных операционных процедур (SOPs – Standard Operating Procedures), подробно описывающих действия сотрудников команды реагирования в процессе обработки инцидента информационной безопасности
  • порядок пересмотра, тестирования и актуализации стандартных операционных процедур

Структура команды по расследованию инцидентов информационной безопасности

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

Существуют три основных типа моделей структуры команды реагирования:

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

Существуют три основные модели комплектации структуры команды реагирования персоналом:

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

Факторы, влияющие на выбор модели:

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

Факторы, влияющие на выбор модели в случае привлечения стороннего обслуживания:

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

Взаимодействие со структурой организации

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

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

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

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

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

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

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

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

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

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

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

В состав инструментария должны входить, также, средства программного обеспечения и аппаратные средства сбора данных:

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

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

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

Команда реагирования на инциденты должна иметь универсальный мобильный инструментарий для возможности реагирования на инцидент (jump kit). Организация должна обеспечить финансовую основу для совершенствования и поддержания в актуальном состоянии инструментария команды реагирования.

Литература

  2. BS 25999-1:2006 Управление непрерывностью бизнеса – Часть1: Практические правила

  3. BS ISO/IEC 27001:2005 Информационные технологии. Методы обеспечения безопасности. Системы управления информационной безопасностью. Требования

  4. ISO13335-1:2004 Информационные технологии. Руководство по управлению ИТ безопасностью. Концепции и модели для управления безопасностью информационных и телекоммуникационных технологии)

www.iso27000.ru

выявление инцидентов информационной безопасности / Блог компании Pentestit / Хабрахабр

image  «Корпоративные лаборатории» — программа профессиональной подготовки в области информационной безопасности, состоящая из теоретической (курсы-вебинары) и практической подготовки (работа в пентест-лабораториях). В данной статье будет рассмотрено содержание именно практической базы, составляющей порядка 80% от общей программы обучения.

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

Процесс обучения

Процесс обучения построен по принципу: 20% теоретической части и 80% практики для закрепления материала. Теоретические части даются порционно, после чего обучающиеся получают доступ к практическим лабораториям.

Одной из отличительных особенностей «Корпоративных лабораторий» является актуальность материала. Отсутствие длительного процесса согласования программы обучения с различными инстанциями позволяет нам с каждым набором (раз в 2 месяца) производить актуализацию курса.

Теория

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

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

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

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

Практика

Закрепление знаний, полученных на уникальных курсах этичного хакинга и тестирования на проникновение от Pentestit, производится путем выполнения практических заданий.

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

Примеры практических заданий:

  • Определить, какой из уволенных сотрудников ответственен за утечку данных.
  • Определить, какой из пользователей пытался получить права пользователя root.
  • Определить, какой из пользователей удалил файл.
  • Определить, кто последний получал доступ к файлу перед его удалением (исключая удалившего файл пользователя).
На одной из машин в сети было обнаружено аномальное поведение. Удалось оперативно снять дамп памяти и сетевого трафика. Необходимо исследовать полученные дампы и выявить:
  • способ компрометации машины;
  • с какого IP-адреса она была атакована;
  • выявить действия злоумышленника на атакованной машине.
Также есть задания, связанные с направлением мобильной форензики приложений iOS и Android — необходимо провести анализ приложений в рамках практической работы.

В новой программе курса Red Team будет уделено большее внимание к расследованию инцидентов и выстраиванию цепочки доказательной базы:

  • реагирование и расследование инцидентов;
  • анализ вредоносной активности;
  • выявление и нейтрализация угроз;
  • выявление задействованных в инциденте систем.
Специалисты, проходящие курс, получат практические навыки работы с утилитами apktools, binutils, Volatility Framewrok, журналами операционных системы и т.д.

Эти навыки позволят оперативно реагировать на инциденты безопасности, выявлять его масштабы, затронутые системы и последствия, а также объективно применять защитные меры и средства.

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

Узнать подробности и записаться на ближайшие курсы можно по ссылке.

habrahabr.ru

Управление инцидентами информационной безопасности | Журнал "Системы управления бизнес-процессами"

Мелькин П.В. выпускник группы MBA CSO-05Школа IT-менеджментаРАНХиГС при Президенте РФ

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

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

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

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

Актуальность темы дипломной работы определяется:

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

В первом разделе рассмотрены основные стандарты и практики управления инцидентами ИБ: Международный и национальный стандарты ISO/TEC 27001:2013 и ГОСТ Р ИСО/МЭК 27001:2006, ГОСТ Р ИСО/МЭК 18044:2007, Рекомендации в области стандартизации Банка России. РС БР ИББС 2.5 2014, ISO/IEС 27035:2011,  NIST SP 80061 и другие.

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

Во втором разделе  рассмотрены понятия событие ИБ и инцидент ИБ, подробно рассмотрен процесс управления инцидентами информационной безопасности, определены цели и задачи. Этапы процесса управления инцидентами ИБ:

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

Рассматривается применение цикла Деминга  и основанная на нем модель непрерывного улучшения процессов PDCA.

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

Ключевые задачами управления инцидентами:

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

Разработка и реализация процесса управления инцидентами ИБ в соответствии с лучшими практиками обеспечивает следующее:

  • четкое определение ролей и ответственности всех специалистов за качественное и своевременное реагирование на инциденты ИБ;
  • предоставление оперативной информации для мониторинга эффективности принимаемых защитных мер;
  • предоставление необходимой информации для корректного проведения анализа рисков ИБ;

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

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

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

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

Особое внимание уделено проведению расследований и сохранению доказательств инцидента ИБ.

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

Ежедневно средства защиты могут регистрировать множество событий ИБ, имеющих разные происхождение и последствия. Анализировать данный поток  выявлять и обрабатывать события для получения информации об инцидентах ИБ, может оказаться затруднительным. Для решения задачи управления потоком событий ИБ, получаемых от средств защиты, и для автоматизации ряда процессов управления инцидентами ИБ используются автоматизированные средства управления событиями ИБ системы класса SIEM (Security Information and Event Management). Эти системы позволяют достичь следующих целей при управлении ИБ:

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

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

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

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

Рубрика: 

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

journal.itmane.ru

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

Особенности управления событиями безопасности

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

Управление инцидентами информационной безопасности основано на следующих действиях:

  • определение. В организации отсутствует методика выявления и классификации инцидентов, описание их основных параметров, поэтому сотрудники встают перед необходимостью или самостоятельно определять критерии события, или игнорировать его. Вход в сеть под аккаунтом другого сотрудника, согласно стандартам, является инцидентом информационной безопасности, но он не будет зафиксирован в журнале, так как сотрудники считают такое поведение стандартным и дозволенным, особенно в условиях дефицита кадровых ресурсов;
  • оповещение о возникновении. Даже если какое-либо событие может быть определено согласно принятым в организации методикам или личному мнению сотрудника как инцидент, чаще всего в организации не разработаны стандарты и маршруты оповещения о таких событиях. Даже если кем-то будет выявлен факт копирования документов, относящихся к коммерческой тайне, сотрудник встанет в тупик перед вопросом, кто именно и в какой форме должен быть оповещен об этом инциденте: его руководитель, служба безопасности или иное лицо;
  • регистрация. Эта часть стандартов является наиболее невыполнимой для российских компаний, инциденты не идентифицируются, соответственно, не фиксируются. Отсутствует практика заведения регистров учета, в которых бы фиксировались значимые события, что впоследствии давало бы материал для их анализа и прогноза возможных атак;
  • устранение причин и последствий. Любой инцидент вызывает определенные следы и последствия, которые, с одной стороны, могут мешать деятельности компании, с другой – служат материалом для проведения расследования причин его возникновения. Отсутствие регламентов устранения последствий может привести как к накоплению ошибок, так и к полному уничтожению доказательственной базы, позволяющей выявить виновника произошедшей ситуации. Любые срочные меры, предпринимаемые для восстановления стабильности, могут случайно или намеренно уничтожить следы проникновения в базу данных;
  • меры реагирования на инциденты. В ряде случаев возникновение инцидента может потребовать срочных мер реагирования, например, отключения компьютера от сети, приостановки передачи информации, установки контакта с провайдером. Должны быть определены органы и должностные лица, ответственные за разработку механизма реагирования и его оперативную реализацию;
  • расследование. Полномочия по расследованию должны быть переданы из ведения IT-службы в компетенцию служб безопасности. В рамках расследования должны быть изучены журналы учета, проанализированы действия всех пользователей и администраторов, которые имели доступ к системам в период возникновения чрезвычайной ситуации. Расследование должно стать одним из основных элементов управления инцидентами. На практике в российских компаниях от реализации этого этапа отказываются, ограничиваясь устранениями последствий произошедшего события. При необходимости расследование должно производиться с привлечением оперативно-следственных органов;
  • реализация превентивных мер. В большинстве случаев инциденты не являются единичными, их возникновение свидетельствует о том, что в системе ИБ возникла брешь и аналогичные случаи будут повторяться. Во избежание этих рисков необходимо по результатам расследования подготовить протокол или акт комиссии, в котором определить, какие именно меры должны быть применены для предотвращения аналогичных ситуаций. Кроме того, применяются определенные меры дисциплинарной ответственности, предусмотренные Трудовым кодексом и внутренними регламентами;
  • аналитика. Все события, нарушающие регламентированные процессы и могущие быть квалифицированы в качестве инцидентов информационной безопасности, должны стать основой для анализа, который поможет определить их характер, проявить системность и выработать рекомендации для совершенствования системы ИБ, действующей в компании.
Основные проблемы, связанные с нарушением процедур, обусловлены неготовностью персонала в полной мере воспринимать, адаптировать и выполнять рекомендации. Касательно инцидентов информационной безопасности, сложности в восприятии и реакции вызывают моменты, связанные с совершением действий, которые прямо не регламентированы инструкциями или стандартами или вызывают ощущение излишних или избыточных.

Процедура управления

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

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

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

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

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

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

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

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

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

Превентивные меры, изменения стандартов и ликвидация последствий

Непосредственно после выявления инцидента предпринимаются оперативные меры по устранению его последствий. На следующем этапе необходим анализ причин его возникновения и совершение комплекса действий, направленных на предотвращение возможного повторения аналогичного события. Сегодня основным регламентирующим документом, предлагающим стандарты реакции на инциденты, стал ISO/IEC 27000:2016, это последняя версия совместной разработки ISO и Энергетической комиссии.

В России на основе более ранних версий ISO/IEC разработаны ГОСТы. В рамках ISO/IEC 27000:2016 предлагается создать специальную службу поддержки, Service Desk, на которую должны быть возложены функции управления инцидентами.

it-club.info

Смотрите также

KDC-Toru | Все права защищены © 2018 | Карта сайта