Министерство по развитию информационных технологий и коммуникаций республики узбекистан “каршинский филиал ташкентского университета информационных технологий имени

Анализ инцидентов информационной безопасности
Инцидент не является очевидным свершившимся фактом, напротив, злоумышленники стараются сделать всё чтобы не оставить в системе следов своей деятельности. Признаки инцидента содержит незначительное изменение в файле конфигурации сервера или, на первый взгляд, стандартная жалоба пользователя электронной почты. Принятие решения о наступлении события инцидента во многом зависит от компетентности экспертов команды реагирования. Необходимо отличать случайную ошибку оператора от злонамеренного целенаправленного воздействия на информационную систему. Факт отработки “в холостую” инцидента информационной безопасности также является инцидентом информационной безопасности, поскольку отвлекает экспертов команды реагирования от насущных проблем. Руководство организации должно обратить внимание на данное обстоятельство и предоставить экспертам команды реагирования известную свободу действий.
Составление диагностических матриц служит для визуализации результатов анализа событий, происходящих в информационной системе. Матрица формируется из строк потенциальных признаков инцидента и столбцов – типов инцидентов. В пересечении даётся оценка событию по шкале приоритетов “высокий”, “средний”, ”низкий”. Диагностическая матрица призвана документировать ход логических заключений экспертов в процессе принятия решения и, наряду с другими документами, служит свидетельством расследования инцидента.
Документирование инцидента информационной безопасности
Документирование событий инцидента информационной безопасности необходимо для сбора и последующей консолидации свидетельств расследования. Документированию подлежат все факты и доказательства злонамеренного воздействия. Различают технологические свидетельства и операционные свидетельства воздействия. К технологическим свидетельствам относят информацию, полученную от технических средств сбора и анализа данных (сниферы, IDS), к операционным – данные или улики, собранные в процессе опроса персонала, свидетельства обращений на service desk, звонки в call center.
Типичной практикой является ведение журнала расследования инцидента, который не имеет стандартной формы и разрабатывается командой реагирования. Ключевыми позициями подобных журналов могут служить:

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

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

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

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