Не за горами принятие промежуточной версии 17-го приказа, за которой воспоследует и уже полноценный вариант новых требований для госорганов, а также иных организаций, обрабатывающих информацию, владельцем которой являются госорганы. Учитывая, что прошлая версия 17-го приказа вышла аж 4 года назад (хотя у ФСТЭК и было желание выйти на двухлетний цикл обновления своих НПА), стоит поразмышлять, чего не хватает текущей редакции и что могло бы появиться в новом варианте.
Сейчас документ исходит из предпосылки (неявной), что в государственной информационной системе все узлы одинаковы и это персональные компьютеры или сервера, за которыми работают или могут работать пользователи, которые в свою очередь могут пройти процесс аутентификации. Иными словами, речь идет только об офисных ИС. Однако уже сейчас даже в офисных системах есть устройства, за которыми пользователи не работают, но устройства обрабатывают информацию ограниченного доступа. Это могут быть принтеры, сканеры, системы видеонаблюдения, видеоконференцсвязь, IP-телефония и т.п.
Во-вторых, сейчас активно, внедряется Интернет вещей, который подразумевает обмен информацией между устройствами, преимущественно консьюмерскими, – интеллектуальные часы, очки, кофеварки и т.п. Они и к офисной беспроводной сети могут подключаться, включаясь тем самым в контролируемую зону. Запретить это сложно, значит нужно контролировать и регламентировать. И если в традиционных ГИС таких устройств может быть и немного, учитывая неразвитость Wi-Fi в ГИС, то в коммерческих структурах, которые после принятия поправок в ФЗ-149 могут попасть под действие 17-го приказа, таких устройств немало и их число будет расти.
В-третьих, в сети могут быть и мобильные устройства, к которым, по крайней мере на текущем этапе, необходимо применять немного отличные требования по защите. Например, многие мобильные устройства подразумевает всего лишь 4-хзначный PIN-код, а не 6-ти-8мисимвольный пароль.
Идем дальше. Сейчас документ статичен – он прописывает набор защитных мер, которые государственное или муниципальное учреждение обязано применить при построении системы защиты. Однако такая статичность в современном динамичном окружении уже не позволяет решать многие задачи ИБ. Например, возьмем пользователя Иванова, который получает доступ к защищаемым ресурсам с ноутбука. Казалось бы сценарий один… но нет, сценариев такого доступа может быть очень много:
Ввиду активного перехода на облачные среды и аутсорсинг по тексту лучше заменить упоминаемого «оператора» на «оператора и уполномоченное лицо, которое может обеспечивать защиту ИС». Также как и лучше заменить заменить по тексту упоминаемого «пользователя» на «субъекта доступа», т.к. контролировать надо в современных информационных системах не только пользователя, но и приложения, процессы, узлы, компоненты ИС, т.е. всех субъектов доступа.
Еще в новый 17-й приказ я бы добавил ряд защитных мер из проекта новой версии NIST Cyber Security Framework v1.1, которая как раз сейчас рассматривается в NIST. 17-й приказ и с первой версией не целиком коррелировался, а уж с новой тем более. Например, в условиях постоянных новостей о закладках со стороны китайских производителей и роста рисков вмешательства в оборудование в процессе его доставки потребителю, в CSF v1.1 был добавлен большой раздел по управлению ИБ в рамках управления цепочками поставок - требования к взаимоотношению с вендорамами, требования к процессу закупки ПО и железа и т.п. В условиях импортозапрещения в России эта тема даже гораздо более важная, чем в других странах мира. Ее стоило бы очертить хотя бы крупными мазками в новой версии 17-го приказа.
В новую версию CSF добавили абсолютно новый раздел по измерению ИБ, демонстрирующий важность ИБ для руководство организации, а также текущий уровень ИБ и его динамику. Я уже писал (а также тут, тут и тут) в прошлом году про то, как можно было бы улучшить 17-й приказ в этой части - повторять не имеет смысла. Если с точки зрения использования этого подхода самим регулятором или органом по аттестации может быть говорить еще и рано, то дать такой инструмент потребителю для самооценки было бы полезно. Когда-то же надо внедрять мысль о том, что измерять уровень своей защищенности можно и нужно (и это не так уж и сложно). Если уж ФСТЭК постепенно переходит на концепцию непрерывного мониторинга защищенности, то почему бы не пойти в сторону измерения этой защищенности?..
Про визуализацию я уже писал на днях, но вновь повторюсь - использование блок-схем, иллюстраций и иных способов выделения контента сильно помогает восприятию документов. Хотя я прекрасно понимаю, что Минюст может такие "квадраты Малевича" и не пропустить. Но почему бы не вынести инфографику на уровень методичек, которые не требуют согласования с Минюстом?
Вот такие предложения вкратце. Надеюсь, что ФСТЭК проект новой редакции 17-го приказа также выложит для общественного обсуждения и многие специалисты смогут высказать свои замечания и сделать предложения регулятору.
Сейчас документ исходит из предпосылки (неявной), что в государственной информационной системе все узлы одинаковы и это персональные компьютеры или сервера, за которыми работают или могут работать пользователи, которые в свою очередь могут пройти процесс аутентификации. Иными словами, речь идет только об офисных ИС. Однако уже сейчас даже в офисных системах есть устройства, за которыми пользователи не работают, но устройства обрабатывают информацию ограниченного доступа. Это могут быть принтеры, сканеры, системы видеонаблюдения, видеоконференцсвязь, IP-телефония и т.п.
В-третьих, в сети могут быть и мобильные устройства, к которым, по крайней мере на текущем этапе, необходимо применять немного отличные требования по защите. Например, многие мобильные устройства подразумевает всего лишь 4-хзначный PIN-код, а не 6-ти-8мисимвольный пароль.
Идем дальше. Сейчас документ статичен – он прописывает набор защитных мер, которые государственное или муниципальное учреждение обязано применить при построении системы защиты. Однако такая статичность в современном динамичном окружении уже не позволяет решать многие задачи ИБ. Например, возьмем пользователя Иванова, который получает доступ к защищаемым ресурсам с ноутбука. Казалось бы сценарий один… но нет, сценариев такого доступа может быть очень много:
- Пользователь Иванов подключился к защищаемым ресурсам с личного ноутбука
- Пользователь Иванов подключился к защищаемым ресурсам со служебного ноутбука
- Пользователь Иванов подключился к защищаемым ресурсам изнутри ведомства
- Пользователь Иванов подключился к защищаемым ресурсам удаленно, через Интернет
- Пользователь Иванов подключился к защищаемым ресурсам по Wi-Fi
- Пользователь Иванов подключился к защищаемым ресурсам по проводному соединению
- Пользователь Иванов подключился к защищаемым ресурсам в рабочее время
- Пользователь Иванов подключился к защищаемым ресурсам в нерабочее время.
Ввиду активного перехода на облачные среды и аутсорсинг по тексту лучше заменить упоминаемого «оператора» на «оператора и уполномоченное лицо, которое может обеспечивать защиту ИС». Также как и лучше заменить заменить по тексту упоминаемого «пользователя» на «субъекта доступа», т.к. контролировать надо в современных информационных системах не только пользователя, но и приложения, процессы, узлы, компоненты ИС, т.е. всех субъектов доступа.
Еще в новый 17-й приказ я бы добавил ряд защитных мер из проекта новой версии NIST Cyber Security Framework v1.1, которая как раз сейчас рассматривается в NIST. 17-й приказ и с первой версией не целиком коррелировался, а уж с новой тем более. Например, в условиях постоянных новостей о закладках со стороны китайских производителей и роста рисков вмешательства в оборудование в процессе его доставки потребителю, в CSF v1.1 был добавлен большой раздел по управлению ИБ в рамках управления цепочками поставок - требования к взаимоотношению с вендорамами, требования к процессу закупки ПО и железа и т.п. В условиях импортозапрещения в России эта тема даже гораздо более важная, чем в других странах мира. Ее стоило бы очертить хотя бы крупными мазками в новой версии 17-го приказа.
 |
| Перечень блоков защитных мер по CSF v.1.1 (красным показаны обновления в v1.1) |
Про визуализацию я уже писал на днях, но вновь повторюсь - использование блок-схем, иллюстраций и иных способов выделения контента сильно помогает восприятию документов. Хотя я прекрасно понимаю, что Минюст может такие "квадраты Малевича" и не пропустить. Но почему бы не вынести инфографику на уровень методичек, которые не требуют согласования с Минюстом?
Вот такие предложения вкратце. Надеюсь, что ФСТЭК проект новой редакции 17-го приказа также выложит для общественного обсуждения и многие специалисты смогут высказать свои замечания и сделать предложения регулятору.
4 коммент.:
Алексей, мне кажется, что Приказ 17 претерпел не такие уж большие изменения, чтобы подвергаться такой критике, тем более, что критика не всегда верная. Так:
1. Ты упоминаешь: "...документ исходит из предпосылки, что в ГИС все узлы одинаковы ... за которыми работают или могут работать пользователи, которые могут пройти процесс аутентификации. Однако уже сейчас есть устройства, за которыми пользователи не работают, но устройства обрабатывают информацию...". Позволю обратить твое внимание на п. 15.1 Приказа, где дано определение "субъекта доступа" - пользователи, процессы, иные субъекты доступа, которые в соответствии с п. 20 должны пройти аутентификацию и идентификацию. То есть в приказе как раз и заложена возможность учета не только принтеров, но и самих процессов (например, обращений прикладного ПО). То есть твой наезд на то, что приказ это не учитывает - ошибочно.
2. По поводу интернета вещей. Тема, в принципе, горячая но вряд ли актуальная для ГИС. Твое замечание о том, что "кофеварки ...могут подключаться к офисной беспроводной сети, включаясь тем самым в контролируемую зону..." весьма громкое, но... пустое. На сколько я могу представлять, для подключения к офисной Wi-Fi (а это, как правило, закрытые сети, хотя бы с точки зрения невозможности подключения "чужака", чтобы не тратить трафик)надо по крайней мере ввести пароль сети. Не думаю, что кофеварка самостоятельно это сможет сделать. Да и вообще, проблема Интернета вещей для ГИС - надуманна. Поэтому она и не нашла отражение в Приказе. Хотя… можно вспомнить п. 20.3 Приказа. «Меры по ограничению программной среды должны обеспечивать установку и запуск только разрешенного ПО и запрещать установку и использование запрещенного ПО.
3. По поводу 4-х значного PIN-кода мобильных устройств. Действительно это так, но только это PIN для входа в устройство, но не в ГИС. Для входа в ГИС все равно потребуется набирать более сложный пароль. Аналогично тому, что войти в гаджет по HIN-коду еще не означает, что ты, например, получишь доступ к своему аккаунту в "облаке". Все равно ты введешь свой пароль доступа к аккаунту, который, по всей вероятности отличается от PINа.
Продолжение следует…
Продолжение...
4. По поводу пользователя Иванова и разных сценариев. Я не вижу описанной тобою «статичности» Приказа. Иванов, как пользователь с ноутбуком вовне ГИС и внутри ГИС – суть два разных пользователя с разными правами. По крайней мере это так воспринимается сейчас. И в чем проблема применения разных сценариев в этом случае? Не будем так же забывать, что приказ нельзя рассматривать в отрыве от методических рекомендаций ( см. п. 21), а там уж точно можно выбрать меры под нужный сценарий. И по времени доступа и по месту доступа и прчая. Просто надо к работе подходить творчески, а не догматично.
5. Управление цепочками поставок. Классная идея! Только вот, в условиях жесткого регламентирования процедур закупок для госучреждений и организаций, на мой взгляд, мало реализуемая. Да, эту процедуру все клянут, да, она не всегда позволяет сделать правильный выбор поставщика. Но, к великому сожалению, это не вопрос ФСТЭК и уж точно не вопрос Требований, изложенных в приказе. Систему закупок надо менять, а уж потом управлять цепочками поставок.
Ну и на последок, мое мнение, подчеркиваю, мое личное мнение, по поводу 2-4 летнего цикла жизни требований. Как известно, жизненный цикл любой ИС это 7-10 лет. И если за это время требования к этой ИС меняются 5 раз, я бы не хотел быть начальником такого объекта… Не должны требования часто меняться, иначе это не требования, а черт знает что. Смена требований должна быть гармонизирована с жизненным циклом ИС, а сами требования должны учитывать перспективу развития ИТ-технологий. Не всегда это возможно? Технологии развиваются быстрее? Значит за период жизни требований должны быть предусмотрены ДОПОЛНЕНИЯ, учитывающие возможные изменения технологий, но они должны применяться только при модернизации системы или внедрении именно этих новых технологий. И еще, не надо путать требования к защите с возможным появлением новых уязвимостей. Создаваемая система обеспечения безопасности информации сама должна уметь (и иметь!) адаптироваться и устранять выявленные уязвимости, но это, еще раз подчеркну, не имеет никакого отношения к изменению требований, это УЖЕ должно быть в ней заложено.
2. Просто в ГИС IoT может и неактуален, но в случае принятия поправок в ФЗ-149, требования 17-го приказа начнут распространяться и на коммерческие организации, в которых IoT применяется очень активно. И это я не упоминаю про активное внедрение IoT в Правительстве Москвы.
3. Мобильное устройство является частью ГИС. И, кроме того, нередки ситуации, когда аутентификация на устройстве означает аутентификацию и в самой сети (по сертификату ли или еще как-то, неважно). Но первична аутентификация по PIN-коду.
4. Иванов - он один. У него одна учетная запись в системе. Только вот его окружение постоянно меняется.
5. Управление цепочками поставок с точки зрения ИБ - это тема именно ФСТЭК. Требования к процессу закупки, к поставляемому решению, к поставщику, к его квалификации...
17 приказ статичен за счет того, что основывается на 34 ГОСТе 89 года. Дополнен он не менее статической процедурой аттестационных испытаний. Эти вещи настолько громоздки и долгосрочны, что в значительной степени мешают бесшовно перейти от проектирования системы к её эксплуатации в условиях изменчивости ИТ. 17-й приказ ранее уже включал малюсенное дополнение о том, что аттестовывать можно не всё, а часть сегментов, реализующих полный цикл, а далее распространять аттестат. Но эта часть настолько неразвита, что применять её сложно. Уходить от понятия "сегмент" сложно, когда вопросы не в сегментах, когда куча систем раздается куче разных пользователей в гибом режиме. И Алексей прав насчет расширения области действия приказа на устройства. Что делать с МФУ, не имеющими сертифицированные средства защиты на 99,9% рынка? Любое проектирование ИБ тут сводится к словоблудию и теоретизации, автономизации устройств, и опять же к статичности процессов. Ну уж не говорю, что хоть на каком бы уровне была поставлена задача обеспечивать интероперабельность средств защиты. У редкого вендора имеется совместимость даже внутри своих линеек. Что ни проект, так не интеграция, а развод СЗИ. Где стандартизация?
Отправить комментарий