Выявление инцидентов и реагирование на них - Форум по вопросам информационной безопасности

В 17-м и 21-м приказах.
Есть такой раздел, как
XIV. Выявление инцидентов и реагирование на них (ИНЦ)
1. Определение лиц, ответственных за выявление инцидентов и реагирование на них
2. Обнаружение, идентификация и регистрация инцидентов
3. Своевременное информирование лиц, ответственных за выявление инцидентов и реагирование на них, о возникновении инцидентов в информационной системе пользователями и администраторами
4. Анализ инцидентов, в том числе определение источников и причин возникновения инцидентов, а также оценка их последствий
5. Принятие мер по устранению последствий инцидентов
6. Планирование и принятие мер по предотвращению повторного возникновения инцидентов

Пункты 1, 4, 5, 6.
На мой взгляд, - это чисто организационные.

Пункты 2,3 - у меня вызывают некоторые вопросы:
Если это все реализуется технически, то чем это отличается от РСБ?
Или все таки это тоже организационные моменты?

Спасибо!

Объясню логику вопроса:

В Техзадании делаю описание технических мер и организационных - в разных подразделах.

Т.е. беру эти два приказа и смотрю меры согласно класса и делю: тут нужно установить так, настроить так
А тут нужно регламентировать то и это.

Приветствую!
1. В 17 приказе ИНЦ группы в виде пункта перечня нет. Есть требования (аналогичные ИНЦ из 21), предъявляемые к аттестованной системе.
2. Пожалуй, все ИНЦ - организационные мероприятия, нежели сугубо технические. И касаются больше работы персонала, чем системы.
3. "События безопасности" - это подкласс "инцидентов", относящийся к функционированию самой технической системы защиты.
4. Зачем в ТЗ вообще все это прописывать в столь явном виде? В техническом проекте - да (указать, как и что из требований НМД реализовано созданной системой защиты), но в ТЗ-то зачем?

oko
Спасибо!

На самом деле я не прописываю конкретные конфиги.
Я в ТЗ прописываю требования, но только не просто копирую тот же 17 и 21, а выбираю, что конкретно нужно и сначала требования к чисто техническим моментам, а потом к орг мерам.

Я несколько о другом. Зачем в ТЗ вообще требования конкретизировать? Если я правильно понял, то ТЗ разрабатывается для создания системы защиты и/или аттестации ИС по требованиям безопасности информации?
Тогда, если для ИС "Частная модель угроз и нарушителей..." отсутствует - достаточно фразы "реализация требований ФСТЭК России по такому-то классу защищенности ГИС или такому-то уровню защищенности ИСПДн". Если Модель в наличии - то + дополнительная реализация организационно-технических мероприятий, нейтрализующих нижеследующие каналы утечки / угрозы безопасности / уязвимости системы.

Не совсем корректно выразился. Конечно, в случае отсутствия Модели следует указать также обязательность ее разработки с возможностью в дальнейшем доработки системы защиты с целью ликвидации угроз, признанных в Модели актуальными, но не включенным в типовой перечень требований ФСТЭК, предъявляемых к системе данного класса (уровня) защищенности.
Правда, на такие вещи редко кто пойдет. Обычно вначале обследование + разработка Модели. А потом уже расписание всех требований (как по Приказам ФСТЭК, так и по выводам Модели).

ГОСТ 34.602-89
требует описания по множеству разделов.

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

oko вы породили у меня сомнения. Зачем? У меня и так голова болит. ))))

Не парьтесь :)
Если уже начали - продолжайте как идет. Просто опять-таки в ТЗ редко указывается полная конкретика (она и не нужна, если имеются ранее разработанные документы для явного описания каждого направления работ). ТЗ - это указание на то, ЧТО нужно сделать с краткой спецификацией КАК нужно делать в случае нетиповой системы. А дальше все в зависимости от конечной задачи, сформулированной в ТЗ. Проще говоря, после краткого описания задачи, условий и описания ИС, прикрепляются ссылки на имеющиеся документы по Обследованию ИС (если задача в моделировании угроз и т.д.), по Моделированию угроз и нарушителей (если задача в последующем проектировании системы защиты), по Тех.Проектированию системы защиты (если задача в интеграции/пусконаладке), по всему предыдущему + эксплуатационной и распорядительной документации (если задача в аттестации).