Пример самооценки для госоргана (в продолжение вчерашней заметки)

Стратегия
Вчера, после заметки про вариант использования ГОСТ Р ИСО/МЭК 15504 для оценки соответствия требованиям 17-го приказа, в ФБ и в блоге возникла небольшая дискуссия, которая заключалась в том, что либо 15504 не применим к 17-му приказу, так как он не описывает процессов, либо применим, но я слишком упростил его для восприятия 🙂 Придется пояснить что же я имел ввиду.

Но прежде отвечу на общее замечание, что все, что я предложил, госорганам не нужно и инициатива вообще наказуема. Это так. Поэтому в самом начале я и написал, что это имеет смысл только там, где госорган занимается ИБ не для галочки и не для 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-продукты — реализуют одну и ту же защитную меры, но совершенно по-разному.
И так, по каждой из защитных мер, для которых надо разработать свою градацию перехода от уровня к уровню, взяв описанный выше подход. Идеально, конечно, если это сделать сам регулятор, предложив единую систему самооценки, но пока ему не до этого.
Оцените статью
Бизнес без опасности
Есть что добавить? Добавьте!

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

  1. Andrey Prozorov

    С примером уже лучше! Спасибо!
    Ну, раз уж тебе эта тема запала в душу, то можешь ещё и вот эту мою разработку посмотреть — http://80na20.blogspot.ru/2015/06/dlp-dlp-maturity-model.html
    Это я в своё время сделал Модель зрелости для DLP… Там чуть больше объяснения теории и более детализированный пример.

    Ответить
  2. Gmshik

    Дождался всех трёх публикаций.
    Почему не оказалось ссылок на СТО БР ИББС? То же самое. Методология расписана. Групповые показатели в зависимости от целей самооценки (не галочки и compliance) скорректировать ни кто не мешает — хоть по 17 приказу, хоть по 21, хоть по 378, да хоть актуальные угрозы так представлять и оценивать, упростить тоже есть где. Круговая диаграмма тоже есть (на вкус и цвет кому как — но визуализация дело очень полезное).

    Соглашусь — такие самооценки совсем не для регулятора).
    Почти все больные вопросы такими самооценками увидеть можно и результаты красиво показать, да что там — и на бюджет красиво попросить)

    А дальше решение по автоматизации … базы мер/требований/процессов по ИБ … и организациям остаётся только используемые меры и средства знать и понимать для чего, как и где у них находятся … и в проведении аудита и сбора сведений интеграторами смысла станет меньше … а тут и посчитать в кризис можно, что дешевле)

    Ответить
  3. Сергей Городилов

    Для начала хорошо. Вот эти все идеи — то, над чем интересно даже поработать 🙂 Включая методическую часть, точки зрения на процессы и меры.

    Ответить
  4. Алексей Лукацкий

    Gmshik: я передумал, будет пять публикаций

    Ответить
  5. IT Support In LA

    Этот комментарий был удален администратором блога.

    Ответить