Вчера, после заметки про вариант использования ГОСТ Р ИСО/МЭК 15504 для оценки соответствия требованиям 17-го приказа, в ФБ и в блоге возникла небольшая дискуссия, которая заключалась в том, что либо 15504 не применим к 17-му приказу, так как он не описывает процессов, либо применим, но я слишком упростил его для восприятия :-) Придется пояснить что же я имел ввиду.
Но прежде отвечу на общее замечание, что все, что я предложил, госорганам не нужно и инициатива вообще наказуема. Это так. Поэтому в самом начале я и написал, что это имеет смысл только там, где госорган занимается ИБ не для галочки и не для compliance, а для реальной безопасности. И потом... никто же не требует показывать данные результаты самооценки при проверках регулятора - достаточно их иметь для собственного понимания текущего состояния и того, куда можно и нужно развиваться.
Что касается второго замечания о том, что для госоргана не может быть разных уровней соответствия и он обязан выполнить все и сразу, опять же повторю то, что уже написал. Госорган может реализовывать не только базовый уровень с усилением, но и адаптированный, то есть расширенный уровень защищенности своих информационных систем. И госпредприятие как раз может двигаться от базового уровня до адаптированного. Не стоит рассматривать базовый уровень как максимальный, пятый. И это если не рассматривать вариант с возможность исключать защитные меры из базового уровня, о чем я уже писал ранее и повторяться не буду.
Но вернемся к конкретному примеру. Итак, как я и написал, ГОСТ 15504 можно использовать двояко. Я вчера написал "можно взять эту модель без изменения (если рассматривать каждый из блоков защитных мер как процесс), а можно попробовать и упростить (правда, в ущерб качеству)". Первый вариант простой и сложный одновременно. Простой потому что не надо выдумывать свои атрибуты для оценки процессов и условия переходов между ними. Сложность заключается в том, что даже сама ФСТЭК не рассматривает явно защитные меры как процесс ИБ. Например, защитная мера, описанная в УПД.12 "Поддержка и сохранение атрибутов безопасности (меток безопасности), связанных с информацией в процессе ее хранения и обработки". В методичке по мерам защиты в ГИС эта мера описана более подробно, но в обоих случаях совершенно непонятно, речь идет о технологии (например, мандатное разграничение доступа), механизме (например, Oracle Label Security ), законченном продукте защиты (например, Cisco Identity Service Engine ) или целом процессе по управлению метками безопасности. Трактовать текущие формулировки можно по-разному, но чаще всего как процесс защитные меры из 17-го приказа все-таки не воспринимают.
Но и запрета на такую трактовку нет. Просто сами регуляторы, особенно на местах, не готовы к такой трактовке. Ведь это потребует от них пересмотра вообще всей идеологии, к которой они привыкли в ФСТЭК. Не смотря на инициацию перевода и гармонизации ISO 2700x в виде соответствующего ГОСТ, а также отсыл к нему в том же 17-м приказе, к процессному, то есть непрерывному обеспечению ИБ у нас еще в госорганах не привыкли и все по-прежнему живут от аттестации до аттестации.
Если все же рассмотреть УПД.12 как процесс, то как у нас будут выглядеть 6 уровней оценки, которые найдут свое отражение в радарной диаграмме:
Но прежде отвечу на общее замечание, что все, что я предложил, госорганам не нужно и инициатива вообще наказуема. Это так. Поэтому в самом начале я и написал, что это имеет смысл только там, где госорган занимается ИБ не для галочки и не для compliance, а для реальной безопасности. И потом... никто же не требует показывать данные результаты самооценки при проверках регулятора - достаточно их иметь для собственного понимания текущего состояния и того, куда можно и нужно развиваться.
Что касается второго замечания о том, что для госоргана не может быть разных уровней соответствия и он обязан выполнить все и сразу, опять же повторю то, что уже написал. Госорган может реализовывать не только базовый уровень с усилением, но и адаптированный, то есть расширенный уровень защищенности своих информационных систем. И госпредприятие как раз может двигаться от базового уровня до адаптированного. Не стоит рассматривать базовый уровень как максимальный, пятый. И это если не рассматривать вариант с возможность исключать защитные меры из базового уровня, о чем я уже писал ранее и повторяться не буду.
Но вернемся к конкретному примеру. Итак, как я и написал, ГОСТ 15504 можно использовать двояко. Я вчера написал "можно взять эту модель без изменения (если рассматривать каждый из блоков защитных мер как процесс), а можно попробовать и упростить (правда, в ущерб качеству)". Первый вариант простой и сложный одновременно. Простой потому что не надо выдумывать свои атрибуты для оценки процессов и условия переходов между ними. Сложность заключается в том, что даже сама ФСТЭК не рассматривает явно защитные меры как процесс ИБ. Например, защитная мера, описанная в УПД.12 "Поддержка и сохранение атрибутов безопасности (меток безопасности), связанных с информацией в процессе ее хранения и обработки". В методичке по мерам защиты в ГИС эта мера описана более подробно, но в обоих случаях совершенно непонятно, речь идет о технологии (например, мандатное разграничение доступа), механизме (например, Oracle Label Security ), законченном продукте защиты (например, Cisco Identity Service Engine ) или целом процессе по управлению метками безопасности. Трактовать текущие формулировки можно по-разному, но чаще всего как процесс защитные меры из 17-го приказа все-таки не воспринимают.
Но и запрета на такую трактовку нет. Просто сами регуляторы, особенно на местах, не готовы к такой трактовке. Ведь это потребует от них пересмотра вообще всей идеологии, к которой они привыкли в ФСТЭК. Не смотря на инициацию перевода и гармонизации ISO 2700x в виде соответствующего ГОСТ, а также отсыл к нему в том же 17-м приказе, к процессному, то есть непрерывному обеспечению ИБ у нас еще в госорганах не привыкли и все по-прежнему живут от аттестации до аттестации.
Если все же рассмотреть УПД.12 как процесс, то как у нас будут выглядеть 6 уровней оценки, которые найдут свое отражение в радарной диаграмме:
- Уровень 0. Управление метками не реализовано вовсе.
- Уровень 1. Управление метками реализовано в том или иной виде - для файлов, для сетевого трафика, для записей СУБД или еще для какого-либо объекта защиты. Тут важен сам факт реализации, а не то, как это сделано и каких практических результатов мы достигли. По сути у нас никак не прогнозируется достижение поставленных целей и какими усилиями эти цели могут быть достигнуты.
- Уровень 2. Мы не только реализовали простановку меток на защищаемую информацию, но и регулярно отслеживаем его состояние - соответствие целям (мы вообще понимаем, зачем нам метки?); мониторинг процесса (а у нас метки сохраняются на протяжении всего процесса обработки или хранения информации?); определены ответственные за данный процесс и разграничена ответственность между ними; ответственные понимают свои полномочия в рамках простановки меток безопасности; понятно, от чего зависит та или иная метка; процесс документирован и т.п.
- Уровень 3. Процесс выполняется по всей организации (а не только в рамках какого-либо подразделения, сегмента или ИТ-решения), в соответствии с общими правилами "для всех" и мы получаем ожидаемые результаты, которые на предыдущих этапах могли наступить или не наступить. При этом персонал, обеспечивающий управление метками безопасности квалифицирован, что подтверждается соответствующим образованием, навыками и опытом.
- Уровень 4. Процесс управления метками становится предказуемым, то есть измеримым и контролируемым, что и является ключевым отличием от предыдущего этапа. Метрики у данного процесса могут быть разными, например, время простановки и время проверки метки безопасности. Можно вообще выйти за рамки классических меток на файлы или иные порции информации и рассмотреть нечто схожее с Xerox Printed Memory , то есть "физическую" метку, которую можно измерять по числу меток выпущенных и внедренных за единицу времени.
- Уровень 5. Процесс постоянно совершенствуется исходя из изменяющихся целей предприятия.
Но понятно, что такой подход достаточно сложен в реализации. Поэтому я предложил в предыдущей заметке второй вариант, когда мы берем саму идею ГОСТ 15504 и упрощаем ее для нашей конкретной задачи. Мы можем это сделать, так как это не требование регулятора, показывать ему оценку мы не обязаны, и поэтому настраиваем ее сугубо для своих нужд. Если нас такая модификация устраивает, то почему бы и нет?
Итак, для каждой защитной меры можно взять следующие 6 градаций, которые применительно к той же защитной мере УПД.12 могут выглядеть следующим образом:
- Уровень 0. Управление метками безопасности не реализовано вовсе. Можно сколь угодно говорить о том, что госорган обязан реализовывать то, что написано в 17-м приказе, но практика говорит о другом. Нет денег - нет защиты. К тому же, не забываем, что я могу предложенную модель использовать для оценки текущего уровня защищенности и выработки пути движения к базовому уровню по 17-му приказу. В этом случае нулевой уровень имеет право на существование.
- Уровень 1. Управление метками, как защитная мера, есть (и может быть даже как-то задокументирована), но централизованного управления нет. Например, я могу вручную проставлять метки для каждого файла в операционной системе. Например, файл с 17-м приказом ФСТЭК у мена на лэптопе у меня имеет разные метки и я могу добавлять туда и свои собственные метки.
- Уровень 2. Появляется централизованное управление с помощью специализированных решений, например, какое либо решение класса IRM или DLP. Тот же упомянутый выше Cisco ISE - это пример именно централизованной системы управления метками безопасности (Security Group Tag, SGT) для сетевого трафика, который в противном случае можно "метить" с помощью тегов VLAN.
- Уровень 3. Мы не просто централизованно управляем системой управления метками безопасности, но и обеспечиваем непрерывный мониторинг защитной меры - наличие меток на объектах или у субъектов защиты, обработка меток инфраструктурой и т.п. В случае появления каких-то сбоев мы оперативно реагируем на них, но без соблюдения четкого SLA.
- Уровень 4. На этом уровне мы определяем метрики измерение эффективности защитной меры, например, время присвоения метки объекту/субъекту защиты, время реагирования в случае сбоя, время простановки меток, число меток определенного типа/уровня конфиденциальности и т.п.
- Уровень 5. Наконец, на высшем уровне мы оптимизируем данную защитную меру, превращая ее в управляемый, контролируемый, прогнозируемый процесс.
Второй вариант гораздо проще реализовать и он укладывается в действующую модель трактовки 17-го приказа как обычного набора защитных мер, которые могут отличаться уровнем и качеством реализации. Это как отечественные криптошлюзы и зарубежные VPN-продукты - реализуют одну и ту же защитную меры, но совершенно по-разному.
И так, по каждой из защитных мер, для которых надо разработать свою градацию перехода от уровня к уровню, взяв описанный выше подход. Идеально, конечно, если это сделать сам регулятор, предложив единую систему самооценки, но пока ему не до этого.
