На прошлой неделе ФСТЭК выпустила документ, о котором давно было известно (тут опубликовано информационное сообщение по данному проекту). Это проект методического документа "Меры защиты информации в государственных информационных системах", который содержит состав, содержание, правила выбора и реализации организационных и технических мер защиты информации, принимаемых в государственных информационных системах в соответствии с Требованиями о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах, утвержденными приказом ФСТЭК России от 11 февраля 2013 г. No 17. Иными словами, 17-й приказ говорит "ЧТО делать", а предлагаемый проект "КАК делать". Этот же документ может быть использован и операторами персональных данных (по их желанию).
Пока сложно детально оценить документ - все-таки 165 страниц подробных объяснений. Но первые впечатления у меня сложились. Документ напоминает NIST SP 800-53 по своей идеологии. Есть базовые меры, есть меры, их усиливающие в зависимости от ряда параметров. Вот как выглядит пример блока в проекте документа ФСТЭК:
А вот как в SP800-53:
Это означает, что существует возможность адекватного выбора защитных мер, которой так не хватало раньше в документах ФСТЭК (и до сих пор не хватает в документах 8-го Центра). Правда, есть и один нюанс, на который обращали внимание критики 21-го и 17-го приказов - их сложность. В рассматриваемом проекте документа ФСТЭК эта сложность возрастает - сложно ожидать от обычного муниципального учреждения или госоргана, что они прочтут все 160 страниц текста, осознают их и смогут реализовать на практике. Но тут вынужден отметить, что решить эту задачу иначе на данном этапе сложно.
Безусловно, можно пойти по пути австралийцев или SANS и выпустить свои Топ35 или Топ20 защитных мер, которые закроют свыше 80-85% всех проблем с ИБ. Но с этими Топами есть свои особенности. Чтобы сваять такой Топ, нужно начинать именно с обширных документов, аналогичных NIST SP800, СТО БР ИББС или 17/21-го приказов ФСТЭК. Потом несколько лет следить и контролировать их внедрение. Потом оценить то, что получилось. Потом выбрать самое важное и сформировать Топ защитных мер, которые нейтрализуют основные угрозы. Возможно ФСТЭК придет и к этому, но не сейчас.
Сейчас у нас есть неплохой проект, с которым нам жить долгие годы (пока на жизненный цикл нормативного документа в 2 года, как у PCI DSS, мы еще не перешли). И его содержание может стать основой и для других документов ФСТЭК, которые будут появляться из под "ее пера". Не исключаю, что и документы по информационной безопасности КВО будут строиться по той же концепции. Поэтому сейчас есть возможность внести в ФСТЭК свои обоснованные предложения и замечания. Их ждут до конца декабря (адрес указан в информационном сообщении). Учитывая опыт разработки и 17-го, и 21-го приказов (а также ряда других документов), могу заметить, что ФСТЭК прислушивается ко многим здравым идеям и не выбрасывает их, не читая или признавая сразу нецелесообразными, как 8-й Центр. Так что сейчас действительно есть шанс сделать этот документ еще лучше. Не упускайте его.
Пока сложно детально оценить документ - все-таки 165 страниц подробных объяснений. Но первые впечатления у меня сложились. Документ напоминает NIST SP 800-53 по своей идеологии. Есть базовые меры, есть меры, их усиливающие в зависимости от ряда параметров. Вот как выглядит пример блока в проекте документа ФСТЭК:
А вот как в SP800-53:
Это означает, что существует возможность адекватного выбора защитных мер, которой так не хватало раньше в документах ФСТЭК (и до сих пор не хватает в документах 8-го Центра). Правда, есть и один нюанс, на который обращали внимание критики 21-го и 17-го приказов - их сложность. В рассматриваемом проекте документа ФСТЭК эта сложность возрастает - сложно ожидать от обычного муниципального учреждения или госоргана, что они прочтут все 160 страниц текста, осознают их и смогут реализовать на практике. Но тут вынужден отметить, что решить эту задачу иначе на данном этапе сложно.
Безусловно, можно пойти по пути австралийцев или SANS и выпустить свои Топ35 или Топ20 защитных мер, которые закроют свыше 80-85% всех проблем с ИБ. Но с этими Топами есть свои особенности. Чтобы сваять такой Топ, нужно начинать именно с обширных документов, аналогичных NIST SP800, СТО БР ИББС или 17/21-го приказов ФСТЭК. Потом несколько лет следить и контролировать их внедрение. Потом оценить то, что получилось. Потом выбрать самое важное и сформировать Топ защитных мер, которые нейтрализуют основные угрозы. Возможно ФСТЭК придет и к этому, но не сейчас.
Сейчас у нас есть неплохой проект, с которым нам жить долгие годы (пока на жизненный цикл нормативного документа в 2 года, как у PCI DSS, мы еще не перешли). И его содержание может стать основой и для других документов ФСТЭК, которые будут появляться из под "ее пера". Не исключаю, что и документы по информационной безопасности КВО будут строиться по той же концепции. Поэтому сейчас есть возможность внести в ФСТЭК свои обоснованные предложения и замечания. Их ждут до конца декабря (адрес указан в информационном сообщении). Учитывая опыт разработки и 17-го, и 21-го приказов (а также ряда других документов), могу заметить, что ФСТЭК прислушивается ко многим здравым идеям и не выбрасывает их, не читая или признавая сразу нецелесообразными, как 8-й Центр. Так что сейчас действительно есть шанс сделать этот документ еще лучше. Не упускайте его.
6 коммент.:
Опять ты с NIST 800-53 сравниваешь, зря.
Я вот даже еще раз его перечитал http://80na20.blogspot.ru/2013/12/vs-nist-800-53.html
Я тебе развернуто отвечу
Друзья, хотелось бы от вас увидеть посты про то, как реализовывать те или иные меры. Я вот до сих пор ума не приложу как можно УПД.1 реализовать для сервиса(сайта) в ЦОДе Хостера, при условии, что пользователи представлены полями в БД на этой же виртуалке. O_o
Не можете реализовать - не реализовывайте. Приказ ФСТЭК вам позволяет либо исключить меру, если таковы особенности ИСПДн и технологии обработки, либо заменить ее мерой компенсирующей
"Не можете реализовать - не реализовывайте." Совершенно верно подмечено. Данный приказ оставляет на откуп оператору ПДн меры защиты.
Алексей, где же этот долгожданный развернутый ответ про NIST 800-53?
Отправить комментарий