Управление инцидентами компьютерной безопасности - Computer security incident management

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

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

Обзор

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

Компоненты инцидента

События

Событие - это наблюдаемое изменение нормального поведения системы, среды, процесса, рабочего процесса или человека (компонентов). Есть три основных типа событий:

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

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

Инцидент

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

Группа реагирования на инциденты

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

Расследование инцидента

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

Процесс

Первоначальный процесс управления инцидентами

Автор: Майкл Берман (tanjstaffl)
  1. Сотрудник, поставщик, клиент, партнер, устройство или датчик сообщает о событии Служба поддержки.
  2. Перед созданием заявки служба поддержки может отфильтровать событие как ложное срабатывание. В противном случае система службы поддержки создает заявку, которая фиксирует событие, источник события, исходную серьезность события и приоритет события.
    1. Билетная система создает уникальный идентификатор для мероприятия. ИТ-персонал должен использовать билет для перехвата электронной почты, мгновенных сообщений и других неформальных сообщений.
    2. Последующие действия, такие как контроль изменений, отчеты об управлении инцидентами и отчеты о соответствии, должны ссылаться на номер заявки.
    3. В случаях, когда информация о событии представляет собой «Ограниченный доступ», билет должен ссылаться на соответствующие документы в защищенной системе управления документами.
  3. В Ответчик первого уровня собирает дополнительные данные о событиях и выполняет предварительный анализ. Во многих организациях объем мероприятий значителен по отношению к персоналу. В результате может применяться автоматизация, обычно в форме инструмента SOAR (оркестровка безопасности, автоматизация и реагирование),[4] интегрирован с интеллектуальным API. Инструмент SOAR автоматизирует расследование с помощью рабочей книги автоматизации рабочего процесса.[4] API киберразведки позволяет программе автоматизировать исследования, связанные с билетом (поиск потенциальных фишинговых URL-адресов, подозрительного хэша и т. Д.). Служба экстренного реагирования определяет критичность события. На этом уровне это обычное событие или событие эскалации.
    1. Нормальные события не влияют на критически важные производственные системы и не требуют контроля изменений до реализации решения.
    2. События, которые влияют на критические производственные системы или требуют контроля изменений, должны быть увеличены.
    3. Руководство организации может запросить немедленную эскалацию без проверки на первом уровне - 2-й уровень создаст заявку.
  4. Событие готово к разрешению. Ресурс вводит разрешение и категорию проблемы в заявку и отправляет заявку на закрытие.
  5. Владелец заявки (сотрудник, продавец, клиент или партнер) получает разрешение. Они определяют, что проблема решена к их удовлетворению, или переоформляют заявку.
  6. Отчет об эскалации обновляется, чтобы показать это событие, и заявке назначается ресурс второго уровня для расследования и ответа на событие.
  7. Ресурс второго уровня выполняет дополнительный анализ и повторно оценивает критичность заявки. При необходимости ресурс второго уровня отвечает за реализацию контроля изменений и уведомление ИТ-менеджмента о событии.
  8. Реагирования на чрезвычайные ситуации:
    1. События могут следовать по цепочке эскалации до тех пор, пока не будет определена необходимость экстренного реагирования.
    2. Руководство организации верхнего уровня может определить необходимость экстренного реагирования и напрямую запустить этот процесс.

Деталь аварийного реагирования

Автор: Майкл Берман (tanjstaffl)
  1. Экстренное реагирование инициируется эскалацией события безопасности или прямым заявлением ИТ-директора или другого исполнительного персонала организации. ИТ-директор может назначить координатора инцидента, но по умолчанию координатор будет самым старшим сотрудником службы безопасности, доступным на момент инцидента.
  2. Координатор инцидентов собирает группу реагирования на инциденты. Команда встречается с использованием заранее определенного конференц-зала. Один из (CIO, CSO или ИТ-директор) должен присутствовать на каждом собрании группы по инцидентам.
  3. Протокол собрания фиксирует статус, действия и решения инцидента. Координатор инцидента сообщает о стоимости инцидента, подверженности и продолжающемся коммерческом риске. Группа реагирования на инциденты определяет следующий план действий.
  4. Блокировка и ремонт - выполните действия, необходимые для предотвращения дальнейшего ущерба организации, отремонтируйте затронутые системы и внесите изменения для предотвращения повторного возникновения.
  5. Ложно-положительный результат - группа по инцидентам определяет, что эта проблема не требует экстренного реагирования. Команда предоставляет письменный отчет высшему руководству, и проблема рассматривается как обычный инцидент или закрывается.
  6. Мониторинг и захват - проведите тщательное расследование с постоянным мониторингом для обнаружения и поимки преступника. Этот процесс должен включать уведомление следующего старшего и профессионального персонала:
    1. Генеральный директор и финансовый директор
    2. Корпоративный поверенный и связи с общественностью
  7. Просмотрите и проанализируйте данные журнала, чтобы определить характер и масштаб инцидента. Этот шаг должен включать использование вирусов, шпионского ПО, руткитов и других средств обнаружения для определения необходимого смягчения и восстановления.
  8. Восстановите системы, устраните вектор (ы) атак и уменьшите уязвимости, которые можно использовать.
  9. В Отчет об испытаниях документирует подтверждение процесса ремонта.
    1. Системы тестирования для обеспечения соответствия политике и снижения рисков.
    2. Выполните дополнительный ремонт, чтобы устранить все текущие уязвимости.
  10. Расследуйте инцидент, чтобы определить источник нападения и поймать преступника. Это потребует использования инструментов судебной экспертизы, анализа журналов, чистой лаборатории и грязной лабораторной среды и возможного взаимодействия с правоохранительными органами или другими сторонними организациями.
  11. «Отчет о состоянии расследования» as фиксирует всю текущую информацию об инциденте. Группа реагирования на инциденты использует эту информацию для определения дальнейших действий. (См. Ссылки 2 и 3)

Определения

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

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

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

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

Рекомендации

  1. ^ «ISO 17799 | ISO / IEC 17799: 2005 (E)». Информационные технологии. Методы безопасности. Свод правил управления информационной безопасностью.. Бюро авторских прав ISO. 2005-06-15. С. 90–94.
  2. ^ «НИМС - Система управления инцидентами». Национальная система управления инцидентами. Департамент внутренней безопасности. 2004-03-01. Архивировано из оригинал на 2007-03-18. Получено 2007-04-08.
  3. ^ «Создание группы реагирования на инциденты компьютерной безопасности» (PDF). Группа реагирования на компьютерные чрезвычайные ситуации. US-CERT. 2003-04-01. Получено 2007-04-08.
  4. ^ а б «Что такое SOAR (управление безопасностью, автоматизация и реагирование)?». ПоискБезопасность. 2019-12-06. Получено 2019-12-06.

дальнейшее чтение