SIZTKS_Lectures.org

Системная интеграция ЗТКС

Контрольный перечень действий по обработке некатегорированных инцидентов

Анализ инцидентов ИБ

1. Приоритетная обработка инцидентов с точки зрения воздействия на бизнес.
2. Сообщение об инциденте причастному персоналу или внешним организациям.

Сдерживание, устранение инцидента, восстановление после инцидента

1. Получение, сохранение, документирование — доказательство инцидента.
2. Сдерживание инцидента.
3. Устранение инцидента.
4. Восстановление после инцидента:
   • восстановление всех систем;
   • проверка функционирования затронутых систем.

Деятельность после инцидента

1. Подготовка отчёта по обработке инцидента.
2. Обсуждение полученных уроков.
3. Корректировка защитных мер, процедур обработки инцидентов.

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

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

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

Эти два фактора определяют влияние инцидента на деятельность (бизнес-процесс) организации.

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

В организации должно быть руководство по обработке инцидентов.

Матрица приоритетности инцидентов:

Критичность

Сущ. или пот. воздействие	Выс.	Ср.	Низ.
Доступ на системном уровне	15 мин.	30 мин.	1 час
Неавт. модификация данных	15 мин.	30 мин.	2 часа
Неавт. доступ на уровне пользователя	30 мин.	2 часа	4 часа
Недоступность услуг	30 мин.	2 часа	4 часа
Раздражение, приставание	30 мин.	1 час	2 часа

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

Процесс реализации и эксплуатации процедуры обработки инцидентов ИБ

1. Входные данные: признаки инцидента (предвестники, указатели).
2. Требования по управлению: стратегии и процедуры сдерживания инцидента.
3. Ресурсы и роли: материальные, финансовые ресурсы; сотрудники.
4. Выходные данные: отчёт о произошедших инцидентах.

Выходные данные получаются в результате выполнения следующих мероприятий:

1. Обнаружение и оповещение об инцидентах ИБ.
2. Анализ инцидентов ИБ.
3. Сдерживание инцидентов ИБ.
4. Устранение инцидентов, восстановление после инцидентов.
5. Сбор и обработка данных (доказательств) об инцидентах, подготовка отчётов.

Обнаружение и оповещение об инцидентах ИБ

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

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

Признаки инцидентов ИБ делятся на 2 категории:

1. Предвестники. Является признаком того, что инцидент ИБ может произойти в будущем. Пример:
   • активность сканирования портов, узлов ЗТКС;
   • угроза от группы хакеров, заявляющих, что они будут атаковать систему.
2. Указатели. Является признаком того, что инцидент ИБ возможно произошёл, или может произойти сейчас. Пример:
   • СОВ предупреждает о попытке переполнения буфера на сервере FTP;
   • антивирусное ПО предупреждает, что возможно появился вирус в компьютере или системе;
   • пользователи указывают на затруднённый доступ к узлам интернета;
   • системный администратор обнаруживает файл с подозрительными характеристиками;
   • приложение регистрирует многочисленные неудачные попытки доступа из какой-то удалённой системы.

Предвестники и указатели могут быть обнаружены сотрудниками организации.

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

Анализ инцидентов

<2011-04-06 Ср.>

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

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

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

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

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

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

1. Останов системы.
2. Отключение системы от внешних сетей.
3. Отключение модемов.

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

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

Для идентификации атакующего выполняются действия:

1. Определение IP-адреса атакующего. Задача заключается в том, чтобы определить реальность такого адреса (с помощью тестирования, трассировок подозрительного узла).
2. Сканирование системы атакующего.
3. Мониторинг возможных каналов связи атакующего.

Устранение инцидента и восстановление после инцидента

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

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

Сбор и обработка данных, подготовка отчётов

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

По инциденту необходимо собирать данные:

1. Число обработанных инцидентов. Обработка большего числа инцидентов — это не обязательно лучше (могут быть лучше защитные меры).
2. Время, затраченное на инцидент:
   • общее время, затраченное на обработку инцидента;
   • время от начала инцидента до окончания его обработки;
   • время каждого этапа обработки инцидента.

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

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

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

Анализ и оценка уязвимостей ИБ

Примеры уязвимостей

1. Среда и инфраструктура.
   • Отсутствие физической защиты здания, дверей и окон. Может быть использована угрозой кражи;
   • неадекватное или небрежное управление физическим доступом в здание, помещение, на территорию. Может быть использована угрозой кражи, преднамеренного повреждения;
   • нестабильная сеть электропитания. Может быть использована угрозой колебания мощности;
   • размещение в зоне, чувствительной к наводнению;
2. Аппаратные средства.
   • Отсутствие порядка периодической замены. Может быть использована угрозой износа активов;
   • восприимчивость к изменениям напряжения. Может быть использована угрозой колебания мощности;
   • восприимчивость к температурным изменениям;
   • восприимчивость к электромагнитному излучению. Может быть использована угрозой э/м излучения;
   • недостаточное техническое обслуживание. Может быть использовано угрозой выхода из строя, отказа аппаратного средства.
3. Программное обеспечение.
   • Отсутствие или неэффективное тестирование ПО. Может быть использована угрозой отказа;
   • сложный интерфейс пользователя. Может быть использована угрозой ошибки пользователя;
   • отсутствие механизмов аутентификации пользователя. Угроза подделки учетной записи;
   • незащищенные списки паролей. Угроза подделки идентификатора пользователя, подделки учетной записи;
   • плохое управление паролями. Угроза подделки идентификатора пользователя, подделки учетной записи;
   • отсутствие записей мониторинга. Угроза НСД.
4. Неправильное распределение прав доступа.
   • неконтролируемая загрузка и использование ПО. Может быть использовано угрозой внедрения вредоносного ПО;
   • отсутствие резервных копий ПО. Может использована угрозой пожара, вредоносного ПО, выход из строя носителей.
5. Телекоммуникации.
   • незащищенные линии связи. Может быть использована угрозой перехвата;
   • отсутствие аутентификации передатчика и приёмника. Может быть использована угрозой подделки учетной записи, аутентификатора пользователя;
   • неадекватное управление сетью. Может быть использована угрозой перегрузки трафика.
6. Документы.
   • отсутствие внимания при распоряжении активами. Может использована угрозой кражи;
   • неконтролируемое копирование. Может быть использована угрозой кражи.
7. Сотрудники.
   • Отсутствие или недостаток персонала. Может быть использована угрозой дефицита персонала (некачественное выполнение функций).
   • недостаточное обучение ИБ. Может быть использована угрозой операционной ошибки персонала.
   • отсутствие или недостаток осведомленности о мерах ИБ. Может быть использована угрозой ошибок сотрудников.
   • отсутствие политик и нормативных документов правильного использования среды передачи и обмена сообщениями. Может быть использована угрозой использования информационной среды неавторизованным образом.

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

Уязвимости могут быть оценены качественно:

1. Низкий уровень.
2. Средний уровень.
3. Высокий уровень.

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

Анализ и оценка существующих защитныx мер

Оценивание риска

Комбинированная оценка риска

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

• базовый или
• детальный.

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

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

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

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

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

Выбор защитных мер

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

Чтобы сделать правильный выбор должны быть:

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

Для определения способов выбора защитных мер:

1. Предотвращение, избежание рисков.
2. Перенос рисков.
3. Снижение рисков:
   • уменьшение угроз;
   • уменьшение уязвимостей.

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

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

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

Необходимо оценить приобретённые и перенесённые риски.

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

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

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

1. Простота применения защитной меры.
2. Прозрачность для пользователя.
3. Относительная стойкость защитных мер.
4. Типы выполняемых функций защитных мер.
   • предотвращение;
   • сдерживание;
   • обнаружение;
   • сигнализация;
   • восстановление;
   • мониторинг.

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

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

Как правило, область ИБ соответствует области деятельности организации. Области ИБ различаются:

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

Ограничения таковы:

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

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