Старые требования на новый лад

Давно известно, что ожидание определенного события порой имеет более сильный эффект, чем само событие. Эффект от ожидания усиливается многократно, если важных событий несколько, а те, от кого зависит их наступление, создают и постоянно поддерживают напряженный «информационный фон», однако события не торопят.

Операторы персональных данных (ПДн) уже более полутора лет живут в таких условиях с момента вступления в силу новой редакции 152-ФЗ. Тема персональных данных регулярно выплывает на ТВ, в интернет-СМИ и блогах. Государственные регуляторы (Роскомнадзор, ФСТЭК и ФСБ) периодически «скармливают» общественности новые проекты своего нормотворчества. Масла в огонь подливают высказывания представителей Совета Федерации и Государственной Думы о том, что эти законодательные органы «вот-вот» займутся очередными «правками» и без того многострадального 152-го ФЗ.

Но жизнь не стоит на месте, и ПДн нужно защищать даже в условиях отсутствия полного набора подзаконных актов. Автору регулярно приходят письма от читателей, практически с одними и теми же вопросами: как выполнить требования того, чего пока нет, исходя из того, что уже есть или еще осталось?

Уведомить нельзя не уведомить

Театр, как известно, начинается с вешалки, а оператор ПДн — с «уведомления о намерении осуществлять обработку»: именно так записано в ст. 22 152-ФЗ. Согласно статистике число операторов, подпадающих под ч. 2 ст. 22, не так велико, и потому уполномоченный орган (Роскомнадзор) рассылает суровые, получившие в народе название «письма счастья» о непредоставлении операторами сведений, предусмотренных ч. 3 ст. 22 ст. 152-ФЗ.

Многие операторы, получив такое письмо, не понимают, о чем идет речь — ведь они уже подавали уведомление. Дело в том, что форма уведомления в новой редакции 152-ФЗ претерпела изменения: теперь необходимо указывать описание мер, предусмотренных ст. 18.1 и 19 152-ФЗ, сведения о лицах, ответственных за организацию обработки ПДн, о трансграничной передаче ПДн и об обеспечении безопасности ПДн в соответствии с требованиями к защите, установленными Правительством РФ.

Согласно ст. 25 недостающую в ранее поданном уведомлении информацию нужно было предоставить в Роскомнадзор до 01.01.2013 года, и с этим не было бы проблем, если бы не «требования, установленные Правительством РФ». С 27 ноября 2007 года эти требования успешно устанавливало постановление Правительства № 781 но, как известно, «новая» редакция 152-ФЗ привнесла иные подходы к обеспечению безопасности ПДн, во многом несовместимые с ПП-781. Постановление Правительства за номером 1119, устанавливающее требования, соответствующие «новому» законодательству и отменяющие «старое» ПП-781, вышло только 01.11.2012 года, а нормативные документы, раскрывающие состав и содержание этих требований, до сих пор в разработке. Получается своего рода парадокс: закон обязывает подать уведомление, но что в нем писать — пока не установлено.

Есть и второй парадокс. Дело в том, что форма подачи уведомлений, установленная Приказом Роскомнадзора № 706 от 19.08.2011 г., по-прежнему оперирует «старыми» понятиями вроде «класса информационной системы», хотя приказ № 55/86/20 от 13.02.2008, утверждавший порядок проведения классификации, равно как и приказ ФСТЭК РФ № 58, утверждавший «Положение о методах и способах...» защиты ПДн, отменены вместе с ПП-781. Не верите? Посмотрите текст самих приказов: первый разработан «в соответствии с пунктом 6», второй — «в соответствии с пунктом 3» ПП-781.

Тем не менее до 1 ноября 2012 года и «классификация», и «приказ № 58» формально действовали, операторы продолжали по ним «жить», а регуляторы не гнушались проверять выполнение указанных в них требований. Именно поэтому некоторые юристы полагают, что тем, у кого информационная система была построена в соответствии со старой нормативной базой, ничего менять не придется: закон, по их мнению, обратной силы не имеет. К такому же мнению, видимо, склоняется и Роскомнадзор, оставивший возможность указания (или не указания) классов в уведомлении.

Как следует поступить оператору, получившему «письмо счастья»? Операторам, ранее не предоставлявшим уведомление, придется составить новый документ (это можно сделать на сайте Роскомнадзора http://www.pd.rsoc.ru/operators-registry/notification/form/), содержащий все необходимые сведения. Операторам, уже предоставившим уведомление, оформлять новое не нужно: необходимо составить «информационное письмо о внесении изменений в уведомление», указав дату его первой подачи и регистрационный номер оператора (можно найти на сайте Роскомнадзора http://www.rsoc.ru/personal-data/register/). В этом письме необходимо указать только сведения, установленные пунктами 5, 7.1, 10 и 11 ч. 3 ст. 22 152-ФЗ.

При заполнении «проблемного» пункта 11, описывающего «требования, установленные Правительством», оператору предоставляются на выбор два варианта: либо указать класс ИСПДн и перечислить требования, реализованные в соответствие со «старой» нормативной базой (только для ИСПДн, введенных в эксплуатацию до 01.11.12), либо перечислить то, что указано в п.п. А-В п. 13 постановления Правительства № 1119. Оператор в любом случае обязан выполнять требования, установленные для минимального (4) уровня защищенности, и, поскольку Роскомнадзор проверяет соответствие сведений, указанных в уведомлении, тому, что реально сделано, никакого нарушения не будет — то, что оператор делает «сверх» заявленного идет ему «в плюс». «Автор, как же так? — спросите вы. — А как быть с остальными уровнями защищенности?» Об этом мы поговорим чуть позже, а сейчас...

Полная автоматизация

Читатели, возможно, помнят, сколько копий было поломано во времена «старого» Закона вокруг «автоматизированной» (регулируемой ПП-781) и «неавтоматизированной» (регулируемой постановлением Правительства № 687 от 15.09.2008 г.) обработки ПДн. Отнесение определенных процессов, использующих средства вычислительной техники, к «неавтоматизированной» обработке позволяло «изворотливому» оператору сэкономить уйму денег на создание системы защиты и обойтись только организационными, не отягощающими бюджет, мерами.

Об этом прекрасно знали регуляторы и, видимо, для исключения «двойных толкований», добились внесения в ч. 3 новой редакции 152-ФЗ определения автоматизированной обработки: теперь таковой считается «обработка с использованием средств вычислительной техники». Но стало ли от этого легче, и если да — то кому?

Согласно п. 1 ПП-687, фактически единственного оставшегося в «добром здравии» документа «старой формации», обработка ПДн, содержащихся в информационной системе персональных данных либо извлеченных из такой системы, считается осуществленной без использования средств автоматизации (неавтоматизированной), если такие действия с персональными данными, как использование, уточнение, распространение, уничтожение ПДн в отношении каждого из субъектов ПДн, осуществляются при непосредственном участии человека.

Определение ИСПДн дается в той же ст. 3 152-ФЗ: это совокупность содержащихся в базах данных ПДн и обеспечивающих их обработку информационных технологий и технических средств. Само определение является сокращенным вариантом того, что было приведено в п. 1 ПП-781, с небольшим исключением: в «новой» редакции Закона была «отрезана» фраза «позволяющих осуществлять обработку таких ПДн с использованием средств автоматизации». ПП-1119 обилием слов тоже не отличается: как следует из п. 1, он «устанавливает требования к защите ПДн при их обработке в ИСПДн». И все — ни слова об «автоматизации» или «автоматизированной обработке»!

Учитывая размытость определения «базы данных», приведенного в ч. 2 ст. 1260 Гражданского Кодекса РФ, под него, разве что, не подпадает компьютер, используемый в качестве печатной машинки, без функций поиска. Получается, что «фокус» с неавтоматизированной обработкой у «хитрых» операторов больше «не пройдет»: для ПДн, обрабатываемых в ИСПДн, будьте добры выполнить требования ПП-1119, для ПДн, извлеченных из этой ИСПДн, — требования ПП-687, для биометрических ПДн — требования постановления Правительства № 512 (п. 3 ч. 3, ч. 10 152-ФЗ), а если вы государственный или муниципальный орган — еще и требования постановления Правительства № 211 от 21.03.2012 года (ч. 3 ст. 18.1 152-ФЗ). Такая вот, понимаете, конструкция.

Концепция моделирования

Как уже говорилось выше, пункт 6 канувшего в Лету ПП-781 предписывал проводить классификацию ИСПДн. В зависимости от объема обрабатываемых ПДн и угроз безопасности жизненно важным интересам личности, общества и государства, все ИСПДн делились на два вида: типовые (с классами с 1 по 4) и специальные. Тем, кто хоть раз проводил классификацию, должно быть хорошо известно, что ни о каких «угрозах безопасности интересам личности» в нормативной документации для этого процесса речи не велось. «Типовые» информационные системы классифицировались на основании «исходных данных», по сути, отражавших технические характеристики ИСПДн. Классификация «специальных» ИСПДн воспринималась многими как «шаманство»: разработка «модели угроз» по методикам ФСТЭК позволяла понижать класс специальной ИСПДн относительно типовой, рассчитанной по аналогичным параметрам, и корифеи моделирования многократно проворачивали этот трюк.

Вопросы «угроз безопасности жизненно важных интересов» в «методике определения актуальных угроз безопасности ПДн при их обработке в ИСПДн», разработанной ФСТЭК в 2008 году, также не рассматривались. Угрозы были чисто техническими, а их актуальность определялась двумя показателями: опасностью и возможностью возникновения. Последний показатель зависел от технических характеристик, определявших так называемый «уровень исходной защищенности» ИСПДн. С выходом ПП-1119 и отменой ПП-781, «методические рекомендации» ФСТЭК по той же причине, что и приказ № 58, утратили свою актуальность (см. введение к документу), чего нельзя сказать о моделировании угроз в целом.

Что несет в себе новая концепция моделирования? Во-первых, новое определение «актуальной угрозы»: фактически это старая «угроза безопасности» из методических рекомендаций ФСТЭК (перетекшая в ч. 11 ст. 19 152-ФЗ), создающая «актуальную» опасность вместо обычной. Во-вторых, новый метод использования ранее известного понятия «уровень защищенности» (УЗ) вместо «класса ИСПДн». Теперь «УЗ» — это не «исходный», а «требуемый» — тот, который оператор должен обеспечить путем реализации соответствующих мер (та же ч. 11 ст. 19 152-ФЗ).

Есть и сходство: уровней защищенности, как и классов, по-прежнему четыре и определяются они по параметрам, частично схожим с параметрами для классификации типовых ИСПДн. Основная «новелла» заключается в параметре «тип актуальной угрозы», который необходимо определить путем «шаманского» (видимо, без этого моделирование угроз невозможно в принципе) соотнесения двух величин.

Первая величина — оценка возможного вреда, проведенная в соответствии с п. 5 ч. 1 ст. 18.1 152-ФЗ и с нормативными правовыми актами, принятыми во исполнение ч. 5 ст. 19 152-ФЗ. При анализе первой ссылки становится понятно, что речь идет о вреде, который может быть причинен субъектам ПДн в случае нарушения оператором 152-ФЗ. Кроме того, оператор должен сопоставить оцененный им вред и принимаемые меры для выполнения обязанностей, предусмотренных законодательством. Закон не говорит, для чего именно это нужно, но вывод очевиден: чтобы принять решение об экономической целесообразности различных защитных мер и выбрать наиболее адекватные по соотношению стоимость/эффективность, для чего нужно всего лишь разработать модель угроз!

Однако анализ ч. 5 и 6 ст. 19 152-ФЗ «сбивает» эйфорию: во-первых, в Законе в явном виде сказано только об актуальных угрозах, определяемых федеральными органами исполнительной власти, органами государственной власти субъектов Российской Федерации, Банком России, органами государственных внебюджетных фондов и иными государственными органами в пределах своих полномочий. Исходя из контекста ч. 5 и 6 ст. 19 получается, что актуальные угрозы из ч. 5 являются «основными», в ч. 6 ассоциации, союзы и иные объединения операторов определяют угрозы «дополнительные», и ровным счетом ничего не сказано о том, должен ли сам оператор что-то моделировать. Возникает очередной парадокс: требования к определению актуальных угроз есть, но методика их определения, равно как и перечни актуальных угроз, установленные ч. 5 и 6 ст. 19 152-ФЗ, отсутствуют!

Как быть оператору? Эксперты склоняются к следующему мнению (и регуляторы неявно, но поддерживают): если законодатель в явном виде не запрещает оператору определять актуальные угрозы, значит, ничто не мешает ему сделать это самостоятельно путем традиционного «моделирования», тем более в отсутствие нормативных актов, указанных в предыдущем абзаце. И все бы ничего, если бы не самая главная «новелла» — вторая величина параметра «тип актуальной угрозы» под названием «угрозы, связанные с наличием недокументированных (недекларированных) возможностей в системном (прикладном) программном обеспечении, используемом в информационной системе», сокращенно НДВ.

Декларированные невозможности

Принято считать, что официальная история отечественного термина НДВ начинается в 90-х годах прошлого века — с момента выхода руководящего документа (РД) ФСТЭК РФ с длинным названием «Защита от несанкционированного доступа к информации. Часть 1. Программное обеспечение средств защиты информации. Классификация по уровню контроля отсутствия НДВ». Именно там приведено наиболее часто употребляемое определение НДВ, позднее «перетекшее» в ГОСТ Р 51275-2006 «Защита информации. Объект информатизации. Факторы, воздействующие на информацию. Общие положения». Согласно РД под НДВ следует понимать «функциональные возможности ПО, не описанные или не соответствующие описанным в документации, при использовании которых возможно нарушение конфиденциальности, доступности или целостности обрабатываемой информации».

Некоторые эксперты склонны полагать, что понятия «НДВ» и «уязвимости ПО» тождественны, однако это не совсем так: наличие НДВ может являться причиной появления уязвимости, создающей связанную с НДВ угрозу. Следует помнить также, что прикладное и системное ПО не работает само по себе — оно является частью ИС, и потому наличие НДВ создает предпосылки к появлению «слабостей» (ГОСТ Р ИСО 7498-2-1999) или «брешей» (ГОСТ Р 50922-2006) как новых «свойств» ИС. Таким образом, не каждое НДВ может создать угрозу уязвимости ИС и не каждая уязвимость ИС является следствием НДВ в ПО.

Профессионалы в области разработки ПО все как один твердят: полностью избавиться от НДВ в ПО невозможно. Ни один из методов, включая «безопасное» проектирование, контроль исходного кода и среды функционирования не дает 100%-ной гарантии их отсутствия. Помимо этого, среди всего многообразия НДВ нужно выделить только те, что создают «связанные угрозы» для конкретной среды эксплуатации, а значит, задача серьезно усложняется. Для «близкого к идеальному» результату, помимо «общего» контроля отсутствия НДВ, необходимо еще проводить контроль «частный», применительно к каждой ИС — а это, по понятным причинам, не в состоянии сделать ни один оператор ПДн.

Если оператор достоверно не знает о наличии НДВ в системном и прикладном ПО, а разработчики не дают 100%-ной гарантии их отсутствия, значит, все ИСПДн попадают в 1-й уровень защищенности? Вовсе нет. Прежде всего, следует помнить, что бороться нужно не с наличием НДВ, а с угрозами, связанными с их наличием, понижая вероятность их реализации до приемлемого уровня. Угроза реализуется через уязвимости ИС, следовательно, комплексное обеспечение безопасности ИСПДн в общем и наличие процесса управления уязвимости в частности (включая управление жизненным циклом ПО, patch management, pentesting и т. д.) способно комплексно снизить вероятность реализации угроз ИС, в том числе создаваемых НДВ.

Кроме того, в соответствии с п.п. «Г» п. 13 ПП-1119 одной из мер, предлагаемых оператору для снижения вероятности актуальных угроз, в том числе связанных с НДВ, является «использование средств защиты информации, прошедших процедуру оценки соответствия требованиям законодательства РФ в области обеспечения безопасности информации». Речь идет, прежде всего, о сертификации СЗИ но, исходя из формулировки указанного пункта, оператор самостоятельно принимает решение о необходимости использования им сертифицированных средств защиты информации.

Возвращаясь к предыдущей главе, стоит отметить один важный момент: для выбора нужного типа в соответствии с ПП-1119, оператор должен обосновать актуальность угроз, связанных с наличием НДВ, путем разработки модели угроз. Для этого, профессионалы «моделирования» рекомендуют оператору экспертным путем определить три параметра: ценность информации для потенциального злоумышленника (производная от возможного вреда субъекту), квалификацию злоумышленника и его технические возможности, и соотнести их с полнотой и качеством организационных и технических мероприятий, предпринимаемых для борьбы с уязвимостями.

И вот здесь возникает последний на сегодня «шаманский» парадокс. Предположим, некий бессовестный оператор обрабатывает сведения о состоянии здоровья 100000 граждан РФ, смело пользуется нелицензионным ПО с «кряками», ни о какой антивирусной защите не идет и речи, а база данных размещена на публичном компьютере в интернет-кафе. Конечно же, такой случай подпадает под УЗ-2 или даже УЗ-1, со всеми вытекающими последствиями. Но вдруг оператору скромно намекнули на то, что он не прав, тот образумился, перешел на лицензионное ПО от официального поставщика, приобрел комплексное решение для защиты рабочих станций, настроил пароли, «прибрал» базу данных — словом, сделал все то, что нужно для УЗ-3. Затем оператор разрабатывает модель угроз, в которой показывает, что принятых мер достаточно для признания угроз, связанных с наличием НДВ, неактуальными, и спокойно «живет» себе на 3 уровне защищенности, вместо...

Вместо злоключения

Хоть и не без иронии, автор статьи со сдержанным оптимизмом отмечает определенные улучшения в сфере защиты набивших оскомину персональных данных. Увеличивая штрафы за несоблюдение законодательства, правительство и некоторые регуляторы идут по пути пусть и не явной, но либерализации требований для негосударственного сектора и наведения порядка в «своей епархии». Проект постановления Правительства РФ «Об утверждении Положения о государственном контроле и надзоре за соответствием обработки ПДн требованиям 152-ФЗ», четко определяющий границы области контроля Роскомнадзора в этой сфере — хороший тому пример. Сюда же следует отнести и проекты документов от ФСТЭК, устанавливающие «требования к защите информации в государственных информационных системах» и «состав и содержание организационных и технических мер по обеспечению безопасности ПДн», а также привлечение экспертного сообщества для их разработки.

К огромному сожалению, автор ровным счетом ничего не может сказать о третьем регуляторе — ФСБ, просто потому, что нормотворческая деятельность этой службы никогда не отличалась открытостью. Остается только надеяться, что регулятор учтет общий «тренд» при разработке своей части нормативной базы, но, как говорится, поживем — увидим, тем более что ждать, судя по всему, осталось не так уж долго.