Сертификация средств защиты и персональные данные

Сертификация средств защиты информации вызывала, вызывает и будет вызывать огромное количество вопросов у IT-люда. И к сожалению не только у него: сами «законотворцы» и «методикоделы» не всегда толком могут ответить на вопрос о сертификации. Тут можно выделить пожалуй два подвопроса:
1. Что «хотят» контролирующие органы (ФСТЭК, ФСБ, Роскомнадзор) — далее «КО»;
2. А что «хочет» закон и методики.
Частично написано в ответ на , где, считаю, не совсем корректно представлено текущее положение дел… хотя взгляд на него излагаю из личного опыта общения с КО, сертифицирующими органами, клиентами и опытом внедрения систем защиты.

Не стоит воспринимать эту статью как научный труд о законодательстве в области защиты перс. данных. Скорее как краткое эссе на указанную тему.

Что «хочет» закон и методики

До выхода Постановления Правительства РФ от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных» ситуация была примерно следующая:
Сертификация являлась единственной реально выполнимой формой оценки соответствия средств защиты информации.
Были другие методы, но с ними было всё веселее: отсутствовали технические регламенты по оценке соответствия для конкретных типов средств защиты. Требования были, а руководств по оценке не было. А для государства всё просто: нет процедуры проверки (то есть не описано, какие конкретно процессы являются проверочными для выполнения требования), значит, не существует проверки.
Возможно, можно было бы самостоятельно написать «Программу и методику оценки соответствия», согласовать ее с ФСТЭК или сертифицирующим органом (что очень вряд ли) и написать «Протокол…». Но данный вопрос не исследовал, потому что в большинстве случаев это было слишком трудоемко и не окупалось. Легче было купить сертифицированный продукт или уйти от угрозы в «Модели угроз…».
Это выглядело бы довольно просто с технической точки зрения, если бы требовалось обеспечить СЗИ 5 класс защищенности СВТ, что в большинстве случаев было достаточно (что при беглом взгляде является тестированием функций авторизации продукта как blackbox-системы), но, например, если продукт был в системе класса К1, то еще требовалось обеспечить контроль НДВ (отсутствие недекларированных возможностей). А контроль НДВ 4 уровня по сути представляет из себя отсутствие избыточности кода, которое надо подтвердить опять же сертифицированными средствами навроде АК-ВС или Аист, которые стоят в несколько сотен тысяч рублей.
Да, можно было бы сделать это вручную, но когда у вас имеется продукт с закрытым кодом? Или продукт настолько сложен, что вручную эта работа займет огромное количество времени? И опять же вопрос согласования " Программы и методики…".
И открою маленький секрет: в настоящее время и для сертификационных лабораторий не существует методик и регламентов по оценке, и многие лаборатории создают их по мере опыта. И опыт больше сводится к тому, утвердят ли методику в органе по сертификации, а не к качеству оценки защитных функций.
С выходом же Постановления № 1119 ситуация немного изменилась.
В пункте 12 указано:

Для обеспечения… уровня защищенности персональных данных при их обработке в информационных системах необходимо выполнение следующих требований:…
г) использование средств защиты информации, прошедших процедуру оценки соответствия требованиям законодательства Российской Федерации в области обеспечения безопасности информации, в случае, когда применение таких средств необходимо для нейтрализации актуальных угроз.

Озвучу своё виденье: теперь сертифицированные СЗИ требуются для закрытия актуальных угроз, соответственно, в ваших руках грамотно составить «Модель угроз…», сведя к минимуму использование данных СЗИ. Остались меры, указанные в Приложении к Положению. Но нет указания ни в постановлении, ни в других нормативных документах на использование СЗИ для реализации требуемых мер.
Также, теперь скромно указано «оценка соответствия», а не «сертификация». Но этот момент я рассмотрел выше: да, это не обязательно сертификация «де-юре», но сертификация «де-факто». И почему это так и нужно воспринимать, ниже.

Что «хотят» контролирующие органы

Думаю, тут стоит отметить два момента:
1. В первую очередь стоит отметить, что КО зачастую имеют свой замысловатый взгляд на то, что написано в законе. При этом комментировать свой подход они не сильно собираются. Достаточно вспомнить «обсуждение» Постановления 1119, к которому КО всех пригласили, но никого не послушали и никому ничего не прокомментировали. Тут два предположения: либо они просто не поняли, что им сказали, либо «обсуждение» затевалось для галочки. Мое мнение: всего по чуть-чуть.
Наша организация тоже несколько раз пыталась получить комментарии по некоторым пунктам, которые мы, как интеграторы, должны выполнять, но в ответ лишь было: «А не наше это дело — комментировать, что мы придумали» (как в шутке — «сама придумала, сама обиделась»).
Показательным было уведомление на официальном сайте ФСТЭК (полный текст здесь):

Одновременно сообщаем, что ФСТЭК России не наделена полномочиями по разъяснению Требований к защите персональных данных при их обработке в информационных системах персональных данных, утвержденных постановлением Правительства Российской Федерации от 1 ноября 2012 г. N 1119, в том числе в части определения типов угроз персональных данных и порядка определения уровней защищенности персональных данных.

2. В связи с пунктом 1 при проверке все карты будут на руках у ФСТЭК (при проверке ФСТЭК). Усугубляется всё еще тем, что в каждом федеральном округе свои ФСТЭК, Роскомнадзор, ФСБ и почему-то точки зрения в связи с этим у них свои и могут кардинально отличаться от соседнего ФО.

Так что же делать

1. Попытайтесь минимизировать перечень актуальных угроз, тут благо вас никто особо не ограничивает. Приведите разумные аргументы, пропишите их в «Модели угроз…». Но наглеть тоже не стоит.
2. Исходя из Модели определитесь с перечнем СЗИ.
Нужно учитывать, что для закрытия угрозы, не обязательно требуется сертифицировать всё ПО, необходимо сертифицировать механизм защиты: если у вас реализован вход в ПО обработки с использованием NTLM-аутентификации (Kerberos) и всё разграничение прав идет на уровне домена, сертифицируйте механизмы домена, а не само ПО (если не требуется НДВ), каким-нибудь Secret Net, Dallas Lock, пакетом сертификации Windows.
В связи с этим решать читателю: «встать в позу» или с минимумом рисков и затрат достичь цели.
К счастью, стоит отметить, что большинство самых используемых продуктов прошли сертификацию и не весь рынок представляет из себя студенческие российские поделки. Если будет интерес, то могу написать небольшой обзор средств защиты для минимального ущерба работоспособности.