Управление информационной безопасностью. Стандарты СУИБ (СИ)

– новых или изменившихся данных об угрозе и уязвимости, которая вносит изменения в существующие результаты оценки и управления рисками ИБ;
– изменений в схеме управления инцидентами ИБ и ее процессах, процедурах, формах учета и/или организационной структуре и базе данных события / инцидента / уязвимости ИБ.
Организация должна рассматривать полученный опыт не только в рамках отдельного инцидента / уязвимости ИБ, но и проводить проверку наличия тенденций / шаблонов появления предпосылок к инцидентам ИБ, которые могут быть использованы в интересах определения потребности в защитных мерах или изменениях подходов к устранению инцидента ИБ. Целесообразно также проведение тестирование ИБ, в особенности оценки уязвимостей, после повлиявшего на ИТ инцидента ИБ.
Поэтому необходимо регулярно анализировать базы данных события / инцидента / уязвимости ИБ для осуществления:
– идентификации тенденций / шаблонов:
– идентификации проблемных областей;
– анализа сфер применения превентивных мер для снижения вероятности появления инцидентов.
Существенная информации, получаемая в процессе обработки инцидента ИБ, должна направляться для анализа тенденций / шаблонов (обработки уязвимости ИБ). Это может в значительной мере способствовать ранней идентификации инцидентов ИБ и обеспечивать предупреждение о том, какие следующие инциденты ИБ могут возникнуть на основе предшествующего опыта и документов.
Необходимо также использовать информацию об инцидентах ИБ и соответствующих им уязвимостях, полученную от государственных и коммерческих ГРИИБ и поставщиков.
Тестирование ИБ и оценка уязвимостей системы, сервиса и/или сети, следующие за инцидентом ИБ, не должны ограничиваться только системой, сервисом и/или сетью, пораженных этим инцидентом ИБ, а должны распространить на любые связанные с ними системы, сервисы и/или сети.
Детальная оценка уязвимостей проводится для того, чтобы выявить их существование в других системах, сервисах и/или сетях, и исключить вероятность появления новых уязвимостей. Она должна проводиться регулярно, поэтому проводимая после инцидента повторная оценка уязвимостей должна быть частью, а не заменой непрерывного процесса оценки.
Необходимо опубликовывать итоговый анализ инцидентов и уязвимостей ИБ для обсуждения его на каждом совещании руководства организации по вопросам обеспечения ИБ и/или на других совещаниях, касающихся общей политики безопасности.
5.2. Идентификация улучшений мер защиты и их внедрение
В процессе анализа, проведенного после решения инцидента ИБ, может быть определена необходимость новых или измененных мер защиты. Однако может случиться так, что их немедленное внедрение будет невозможно по финансовым или эксплуатационным причинам; в этом случае они должны быть предусмотрены в долгосрочных планах организации.
Периодически организация должна осуществлять обновление и/или внедрение новых мер защиты. Это могут быть технические (включая физические) средства, которые потребуют обновления учебного материала для инструктажа персонала и пересмотра директив по ИБ. Системы / сервисы / сети организации должны также периодически подвергаться оценке уязвимостей с целью непрерывного повышения их надежности.
Анализ связанных с ИБ процедур и документации может проводиться сразу после инцидента (выявления уязвимости) или позже. После инцидента (выявления уязвимости) ИБ необходимо обновить политики и процедуры обеспечения ИБ с учетом собранной информации и проблем, возникших в процессе управления инцидентами ИБ. Постоянной задачей ГРИИБ и руководителя ИБ организации является распространение в организации обновленных вариантов политики и процедур обеспечения ИБ и доведение их до персонала ИБ.
5.3. Идентификация улучшений пересмотра результатов оценки и управления рисками и их внедрение
В зависимости от серьезности и степени влияния инцидента (потенциального влияния выявленной уязвимости) ИБ может появиться необходимость пересмотра результатов оценки и управления рисками ИБ с учетом новых угроз и уязвимостей. По результатам обновления результатов оценки и управления рисками ИБ может возникнуть необходимость обновления и/или внедрения новых мер защиты.
 
5.4. Идентификация улучшений схемы управления инцидентами и их внедрение
После разрешения инцидента руководитель ГРИИБ должен проанализировать все произошедшее, чтобы количественно оценить эффективность всех реагирований на инцидент ИБ. Подобный анализ предназначен для идентификации успешно задействованных элементов схемы управления инцидентами ИБ и определения потребности в любых улучшениях.
Важным аспектом анализа, проводимого после реагирования на инцидент, является применение полученной информации в схеме управления инцидентами ИБ. Если инцидент ИБ является серьезным, то после его решения необходимо провести совещание всех заинтересованных сторон, владеющих информацией о нем.
На этом совещании должны рассматриваться следующие вопросы:
– работали ли должным образом процедуры, принятые в схеме управления инцидентами;
– существуют ли процедуры или методы, которые способствовали бы обнаружению инцидентов;
– были ли определены процедуры или средства, которые использовались бы в процессе реагирования;
– применялись ли процедуры, помогающие восстановлению систем после идентификации инцидента;
– была ли передача информации об инциденте всем задействованным сторонам эффективной в процессе обнаружения, оповещения и реагирования.
Все предложения по улучшению схемы управления инцидентами ИБ, полученные в результате совещания, должны быть задокументированы. Области схемы, предназначенные для улучшений, должны быть проанализированы и принято решение о варианте их реализации. Изменения в процессах, процедурах и формах учета должны быть тщательно проверены и протестированы перед применением на практике. После реализации улучшений в документацию схемы должны быть внесены изменения, а обновленный вариант документации – доведен до персонала ИБ.
5.5. Другие улучшения
В течение фазы извлечения уроков могут быть идентифицированы и другие улучшения, например, изменения в политике ИБ, стандартах, процедурах и конфигурациях аппаратного и программного обеспечения.