В области компьютерной безопасности и информационных технологий , управление инцидентами компьютерной безопасности включает в себя мониторинг и обнаружение событий безопасности на компьютерной или компьютерную сеть , а также выполнение соответствующих ответов на эти события. Управление инцидентами компьютерной безопасности - это специализированная форма управления инцидентами , основной целью которой является разработка хорошо понятного и предсказуемого ответа на разрушительные события и компьютерные вторжения. [1]
Управление инцидентами требует процесса и группы реагирования, которая следит за этим процессом. Это определение управления инцидентами компьютерной безопасности соответствует стандартам и определениям, описанным в Национальной системе управления инцидентами (NIMS). Координатор инцидента управляет ответ на инцидент аварийной безопасности. В случае стихийного бедствия или другого события, требующего реагирования со стороны аварийных служб, координатор инцидента будет действовать в качестве связующего звена с менеджером аварийных служб. [2]
Обзор
Управление инцидентами компьютерной безопасности - это административная функция управления и защиты компьютерных активов, сетей и информационных систем. Эти системы продолжают становиться все более важными для личного и экономического благополучия нашего общества. Организации (группы государственного и частного секторов, ассоциации и предприятия) должны понимать свою ответственность перед общественным благом и благосостоянием своих членов и заинтересованных сторон. Эта ответственность распространяется на наличие программы управления, «что делать, если что-то пойдет не так». Управление инцидентами - это программа, которая определяет и реализует процесс, который организация может принять для продвижения собственного благосостояния и безопасности общества.
Компоненты инцидента
События
Событие - это наблюдаемое изменение нормального поведения системы, среды, процесса, рабочего процесса или человека (компонентов). Есть три основных типа событий:
- Нормальный - нормальное событие не влияет на критические компоненты и не требует управления изменениями до реализации решения. Обычные события не требуют участия старшего персонала или уведомления руководства о событии.
- Эскалация - событие с эскалацией влияет на критически важные производственные системы или требует выполнения решения, которое должно следовать за процессом управления изменениями. События с эскалацией требуют участия старшего персонала и уведомления заинтересованных сторон о событии.
- Чрезвычайная ситуация - чрезвычайная ситуация - это событие, которое может
- влияют на здоровье или безопасность людей
- нарушать первичный контроль критических систем
- существенно влиять на производительность компонентов или из-за воздействия на системы компонентов предотвращать действия, которые защищают или могут повлиять на здоровье или безопасность людей
- считаться чрезвычайной ситуацией в соответствии с политикой или заявлением доступного координатора инцидента
Персонал компьютерной безопасности и информационных технологий должен обрабатывать чрезвычайные ситуации в соответствии с четко определенным планом реагирования на инциденты компьютерной безопасности.
Инцидент
Инцидент - это событие, причиной которого является человек. Это различие особенно важно, когда событие является результатом злонамеренного намерения причинить вред. Важное примечание: все инциденты - это события, но многие события не являются инцидентами. Сбой системы или приложения из-за возраста или дефекта может быть аварийным событием, но случайный дефект или сбой не является инцидентом.
Группа реагирования на инциденты
Координатор инцидентов безопасности управляет процессом реагирования и отвечает за сборку команды. Координатор обеспечит включение в команду всех лиц, необходимых для надлежащей оценки инцидента и принятия решений относительно правильного курса действий. Группа по инцидентам регулярно встречается для проверки отчетов о состоянии и принятия конкретных мер. Команда должна использовать заранее выделенное физическое и виртуальное место для встреч. [3]
Расследование инцидента
Следствие стремится установить обстоятельства происшествия. Каждый инцидент требует расследования. Однако ресурсы для расследования, такие как инструменты судебной экспертизы, грязные сети, карантинные сети и консультации с правоохранительными органами, могут быть полезны для эффективного и быстрого разрешения чрезвычайного происшествия.
Процесс
Первоначальный процесс управления инцидентами
- Сотрудник, поставщик, клиент, партнер, устройство или датчик сообщает о событии в службу поддержки .
- Перед созданием заявки служба поддержки может отфильтровать событие как ложное срабатывание. В противном случае система службы поддержки создает заявку, которая фиксирует событие, источник события, исходную серьезность события и приоритет события.
- Билетная система создает уникальный идентификатор для мероприятия. ИТ-персонал должен использовать билет для перехвата электронной почты, обмена мгновенными сообщениями и другого неформального общения.
- Последующие действия, такие как контроль изменений, отчеты об управлении инцидентами и отчеты о соответствии, должны ссылаться на номер заявки.
- В случаях, когда информация о событии представляет собой «Ограниченный доступ», билет должен ссылаться на соответствующие документы в защищенной системе управления документами.
- Реагент первого уровня собирает дополнительные данные о событиях и выполняет предварительный анализ. Во многих организациях объем мероприятий значителен по отношению к персоналу. В результате может применяться автоматизация, обычно в форме инструмента SOAR (управление безопасностью, автоматизация и реагирование) [4], интегрированного с интеллектуальным API. Инструмент SOAR автоматизирует расследование с помощью рабочей книги автоматизации рабочего процесса. [4] API киберразведки позволяет программе автоматизировать исследование, связанное с заявкой (поиск потенциальных фишинговых URL-адресов, подозрительного хэша и т. Д.). Служба экстренного реагирования определяет критичность события. На этом уровне это обычное событие или событие эскалации.
- Обычные события не влияют на критически важные производственные системы и не требуют контроля изменений до реализации решения.
- События, которые влияют на критически важные производственные системы или требуют контроля изменений, должны быть увеличены.
- Руководство организации может запросить немедленную эскалацию без проверки на первом уровне - 2-й уровень создаст заявку.
- Событие готово к разрешению. Ресурс вводит разрешение и категорию проблемы в заявку и отправляет заявку на закрытие.
- Владелец заявки (сотрудник, продавец, клиент или партнер) получает решение. Они определяют, что проблема решена к их удовлетворению, или переоформляют заявку.
- Отчет об эскалации обновляется, чтобы показать это событие, и заявке назначается ресурс второго уровня для расследования и реагирования на событие.
- Ресурс второго уровня выполняет дополнительный анализ и повторно оценивает критичность заявки. При необходимости ресурс второго уровня отвечает за реализацию контроля изменений и уведомление ИТ-менеджмента о событии.
- Аварийного реагирования:
- События могут следовать по цепочке эскалации до тех пор, пока не будет определена необходимость экстренного реагирования.
- Руководство организации верхнего уровня может определить необходимость экстренного реагирования и напрямую инициировать этот процесс.
Деталь аварийного реагирования
- Экстренное реагирование инициируется эскалацией события безопасности или прямым заявлением ИТ-директора или другого исполнительного персонала организации. ИТ-директор может назначить координатора инцидента, но по умолчанию координатор будет самым старшим сотрудником службы безопасности, доступным на момент инцидента.
- Координатор инцидентов собирает группу реагирования на инциденты. Команда встречается с использованием заранее определенного конференц-зала. Один из (ИТ-директор, CSO или ИТ-директор) должен присутствовать на каждом собрании группы по инцидентам.
- Протоколы собрания фиксируют статус, действия и решения инцидента. Координатор инцидента сообщает о стоимости, подверженности и продолжающемся коммерческом риске инцидента. Группа реагирования на инциденты определяет следующий план действий.
- Блокировка и ремонт - выполните действия, необходимые для предотвращения дальнейшего ущерба организации, отремонтируйте затронутые системы и внесите изменения для предотвращения повторного возникновения.
- Ложно-положительный результат - группа по инцидентам определяет, что эта проблема не требует экстренного реагирования. Команда представляет письменный отчет высшему руководству, и проблема рассматривается как обычный инцидент или закрывается.
- Мониторинг и захват - проведите тщательное расследование с постоянным мониторингом для обнаружения и поимки преступника. Этот процесс должен включать уведомление следующего старшего и профессионального персонала:
- Генеральный директор и финансовый директор
- Корпоративный поверенный и связи с общественностью
- Просмотрите и проанализируйте данные журнала, чтобы определить характер и масштаб инцидента. Этот шаг должен включать использование вирусов, шпионского ПО, руткитов и других средств обнаружения для определения необходимого смягчения и исправления.
- Восстановите системы, устраните вектор (ы) атак и уменьшите уязвимости, которые можно использовать.
- Отчет о проведении испытаний документов валидации процесса ремонта.
- Системы тестирования для обеспечения соответствия политике и снижения рисков.
- Выполните дополнительный ремонт, чтобы устранить все текущие уязвимости.
- Расследуйте инцидент, чтобы определить источник нападения и поймать преступника. Это потребует использования инструментов судебной экспертизы, анализа журналов, чистой лаборатории и грязной лабораторной среды и возможного взаимодействия с правоохранительными органами или другими сторонними организациями.
- «Отчет о состоянии расследования» as фиксирует всю текущую информацию об инциденте. Группа реагирования на инциденты использует эту информацию для определения дальнейших действий. (См. Ссылки 2 и 3)
Определения
- Служба быстрого реагирования / Обзор первого уровня
- Первым прибывшим на место происшествия или получившим уведомление о событии, организациям следует провести обучение лиц, оказывающих первую помощь, распознавать и надлежащим образом реагировать на чрезвычайные обстоятельства.
- Билет службы поддержки (контроль)
- электронный документ, занесенный в базу данных и систему отслеживания / разрешения проблем
- Владелец билета
- лицо, сообщающее о событии, основной владелец активов, связанных с событием, или владелец общего права или юрисдикции.
- Отчет об эскалации (контроль)
- В документации First Responder по эскалации заявки ответчик записывает эту информацию в заявку или журнал WIKI для события. Билет ссылается на журнал WIKI для события.
- Второй ярус
- Старшие технические ресурсы, назначенные для разрешения проблемы с эскалацией.
- Координатор инцидентов
- лицо, назначенное высшим руководством организации для формирования группы реагирования на инциденты, управления и документирования реакции на инцидент.
- Отчет о состоянии расследования (контроль)
- документирования текущих результатов расследования, координатор может задокументировать этот материал в заявке, WIKI или инженерном журнале.
- Протокол собрания (контрольный)
- документация собрания группы по инцидентам, протоколы документируют участников, текущий характер инцидента и рекомендуемые действия. Координатор может задокументировать этот материал в билете, WIKI или инженерном журнале.
- Блокировка управления изменениями
- процесс, заказанный как разрешение инцидента. Этот процесс следует тем же требованиям авторизации и реагирования, что и управление аварийными изменениями.
- Отчет об испытаниях (контроль)
- в этом отчете подтверждается, что ИТ-специалисты выполнили все необходимые и доступные ремонты систем перед их возвратом в эксплуатацию.
- Военная комната
- безопасная среда для просмотра конфиденциальных материалов и расследования инцидентов, связанных с безопасностью.
- Отчет перед высшим руководством (контроль)
- координатор инцидента отвечает за подготовку старшего отчета об управлении. Координатор может задокументировать этот материал в билете, WIKI или инженерном журнале.
Действия по реагированию на инциденты
- Обнаружение - инцидент может быть обнаружен датчиком, сетевым аналитиком или пользователем, сообщающим о чем-то необычном на своем ПК.
- Сдерживание - в случае вредоносного сетевого трафика или компьютерного вируса диспетчер реагирования на инциденты должен остановить трафик, отключив компьютер от сети.
- Очистить - запустить сканирование на вирусы, чтобы удалить вирус, или очистить компьютер и заново создать образ машины.
- Обратный инжиниринг - используйте инструменты компьютерной криминалистики , чтобы понять, почему вообще возник вредоносный трафик. После того, как происшествие будет полностью осознано, составьте план по снижению вашего будущего риска.
Смотрите также
Рекомендации
- ^ «ISO 17799 | ISO / IEC 17799: 2005 (E)» . Информационные технологии - Методы безопасности - Свод правил управления информационной безопасностью . Бюро авторских прав ISO. 2005-06-15. С. 90–94.
- ^ «НИМС - Система управления инцидентами» . Национальная система управления инцидентами . Департамент внутренней безопасности. 2004-03-01. Архивировано из оригинала на 2007-03-18 . Проверено 8 апреля 2007 .
- ^ «Создание группы реагирования на инциденты компьютерной безопасности» (PDF) . Группа реагирования на компьютерные чрезвычайные ситуации . US-CERT. 2003-04-01 . Проверено 8 апреля 2007 .
- ^ а б «Что такое SOAR (управление безопасностью, автоматизация и реагирование)?» . SearchSecurity . 2019-12-06 . Проверено 6 декабря 2019 .
дальнейшее чтение
- Справочник для групп реагирования на инциденты компьютерной безопасности (CSIRT) http://www.sei.cmu.edu/library/abstracts/reports/03hb002.cfm