День третий. Экватор

Сегодняшний день начался с установки и настройки SecretNet'a. Он используется для контроля доступа к файлам, содержащим ПДн (в т.ч. печати); контроля целостности как файлов, содержащих ПДн, так и операционной системы; контроля устройств.
Контроль доступа осуществляется на основе мандатного или дискреционного механизмов. Дискреционный доступ реализован и в операционной системе (каждому конкретному файлу "назначаются" пользователи, которые могут читать/писать/изменять файл) и не особо интересен. С мандатным интереснее. Во-первых, выделяются категории файлов, например - ПДн, коммерческая тайна и общедоступные данные. Во-вторых, каждому файлу назначается выбранная категория (поддерживается механизм наследования, т.е. можно на папку повешать "гриф" ПДн и все файлы, созданные в ней, или перемещённые туда, будут обладать этим грифом). В-третьих, для каждого пользователя определяется "наиболее серьёзный" гриф, который должен быть ему доступен и имеет ли этот пользователь возможность самостоятельного назначения грифов для файлов. Т.е., если пользователю, например, доступен гриф ПДн, то он сможет видеть все общедоступные файлы и файлы с грифом "ПДн", "коммерческая тайна" будет ему недоступна, а пользователь с правами доступа к коммерческой тайне, будет иметь возможность доступа к данным с любым грифом.
Проблемных мест, к сожалению, хватает. Во-первых, имеется возможность назначения всего трёх видов грифов, один из которых должен быть общедоступным. Это достаточно крупное разделение. Во-вторых, назначение доступных грифов пользователям - оно производится для каждого пользователя, нельзя назначить доступность грифа группе пользователей.
Контроль устройств. С ним всё относительно просто. Выбираются устройства и назначаются разрешения для конкретных пользователей. Удобно тем, что можно каждому пользователю выдать по флэшке и разрешить компьютере втыкать этому пользователю именно эту флэшку, а все остальные накопители запретить. В плане учёта материальных носителей ПДн - очень удобно. Есть возможность назначать права вообще на всё - вплоть до ядер процессора - применимость не совсем понятна, но есть и ладно.
Контроль целостности. К сожалению, сегодня мы с ним разобраться не успели. Смогли выбрать каталог для контроля целостности, создать там пару файлов и задать эталонные значения. Что должно происходить дальше - непонятно - то ли SecretNet должен запретить их изменение, то ли не должен. Ответ получить не смогли. Единственное, что контроль целостности ОС тормозит так сильно, что загрузка ОС вместо привычных 3-4 минут тянулась минут 10. Если на заводе загрузка будет идти столько же - пользователи нас казнят.
Плюс, нам не показывали, но сказали, что есть "центральная административная" консоль, через которую SecretNet можно настраивать в сети удалённо, со своего рабочего места. На курсах в ОмГУ говорили, что при таком варианте все журналы сообщений будут по сети сливаться на центральную машину и генерировать приличный траффик, тут же говорят, что журналы будут храниться локально и их просто можно просматривать с "центральной" машины.

После SecretNet'a некоторое время потратили на модель угроз. Ничего нового не было, всё есть в базовой модели угроз ФСТЭК и их же методических рекомендациях по выявлению актуальных угроз. Единственное, что при определении уровня исходной защищённости ("УИЗ"), можно сыграть на нечёткости формулировок и снизить этот уровень (например под одноточечным доступом в сеть общего пользования можно понимать как отдельный компьютер, "физически подключенный" к интернету, так и шлюз, через который выходит в интернет сотня пользователей).
Кроме того, для составления модели угроз можно воспользоваться программным продуктом WingDoc, он стоит порядка 15 тыр, гуглится легко. Отвечая на вопросы программы, формируется модель угроз и какие-то сопутствующие документы.
До составления модели угроз самостоятельно я не доходил, так что для меня стало открытием, что для актуальных угроз (например, хищение hdd из системного блока без боковой крышки), нужно составлять ещё и список конкретных уязвимостей. Например, для этой угрозы, уязвимости могут быть такими: отсутствие регламента постановки помещения под охрану и, собственно, отсутствие крышки на системном блоке. Каждая из этих уязвимостей должна закрываться отдельно.

Для оценки рисков, вызванных наличием актуальных угроз, можно воспользоваться методикой оценки рисков от Digital Security. Формулы достаточно не сложные, обоснование тоже вроде как присутствует. О других методиках оценки рисков, нам никто не рассказывал.
По сути, подзаконные акты не требуют и не описывают процедуру оценки рисков, но оценив риски, можно закрывать угрозы не в произвольном порядке, а в порядке уменьшения риска, что достаточно логично.

Составив список актуальных угроз, можно провести классификацию ИСПДн по приказу трёх (который до сих пор никто не отменял) и установить уровни защищённости по постановлению 1119. С классификацией по приказу трёх я не хочу даже связываться, для специальных систем она делается на основании "экспертной оценки" (эксперт считает, что исходя из обрабатываемых ПДн и актуальных угроз, субъекту может быть нанесён значительный/незначительный вред и определяет класс ИСПДн), а вот уровень защищённости, по модели угроз, определяется хорошо. Во-первых, определяется тип актуальных угроз:
1-й, если актуальны угрозы НДВ в системном ПО;
2-й, если актуальны угрозы НДВ в прикладном ПО и неактуальны в системном ПО;
3-й, если угрозы НДВ не актуальны.
Во-вторых, определяется какие ПДн и в каком количестве обрабатываются (специальные, биометрические, иные, общедоступные) и на основании этих двух параметров определяется требуемый уровень защищённости.
Проблема здесь может крыться в том, что не все сертификаты ФСТЭК гарантируют отсутствие НДВ в ПО, на это следует обратить внимание.
В принципе, если ОС сертифицирована и угрозы 1-го типа неактуальны, то ИСПДн завода (с учётом того, что мы обрабатываем иные ПДн менее чем 100 000 человек) нужно будет обеспечить уровень защищённости 3, что вполне приемлимо.
Перечень применяемых мер, для обеспечения требуемого уровня защищённости, будет утверждён ФСТЭКом позднее. В декабре выходил проект их приказа, достаточно сильно раскритикованный в сети.

Далее, после определения уровня защищённости, нужно будет составить ТЗ на создание системы защиты ИСПДн. Желательно по ГОСТу 34.602. Вообще же, для оформления документов, желательно пользоваться ГОСТом 6.30. В этом случае, вряд ли у проверяющих будут претензии как минимум к оформлению.

Неопределенность

Второй день занимаюсь на курсах повышения квалификации по защите персональных данных.
Программа курса, как говорят, преподаватели, согласована со ФСТЭКом, однако, по этой программе у меня есть определенные вопросы.
Точнее, не по самой программе, а по тому что нам дают. Всего этот курс читают четверо преподавателей - трое из них часть своего материала уже отчитали, четвертый появится завтра. Что любопытно - у всех троих свой взгляд на этот закон. Один из них говорит, что СТР-К и другие документы, посвященные конфиденциальным данным, может быть удобно использовать при создании документации к ИСПДн (СЗПДн), но обязательный характер эти документы не носят. Такая позиция мне понятна и очень даже нравится - в этом случае мы не обязаны составлять технические паспорта на компьютеры и проводить аттестацию системы.
Другой говорит, что ВСЕ операторы ОБЯЗАНЫ использовать СТР-К и, соответственно, проводить аттестацию системы, составлять технические паспорта и прочее. Но, опять же, он не говорит о том как проводить параллели между классом ИСПДн и классом АС, но признает, что это разные вещи, т.е. остается неопределенность - какие требования СТР-К мы должны выполнять для ИСПД класса К2, например.
Третья точка зрения - ВСЕ документы ВСЕХ регуляторов в части конфиденциальных данных обязательны для применения. Т.е. в первую очередь мы защищаем конфи, а только потом персональные данные.
Вот как, блин, как они все это согласовали со ФСТЭКом? Или ФСТЭК считает, что любой из этих подходов имеет право на жизнь и оператор сам должен выбирать? В таком случае, мне кажется, должна быть оговорка, что оператор волен выбирать любой из понравившихся вариантов.
Впрочем, до конца курсов еще далеко и, возможно, что-то прояснится.
На данный момент, самое главное, что я вынес с курсов (и в чем сходятся все преподаватели) - это то, что для работ по установке, настройке и вводу в эксплуатацию средств защиты информации, организация должна иметь лицензию по ТЗКИ от ФСТЭК. Если такой лицензии нет - мы обязаны приглашать лицензиата (это, кстати, хорошо объясняет почему четверть стоимости по коммерческому предложению одного из лицензиатов - это именно работы по настройке СЗИ). Тут есть один нюанс, все они говорят, что готовится к принятию новый закон о лицензируемых видах деятельности, в результате принятия которого, лицензия на ТЗКИ будет "разбита" на несколько более мелких лицензий, что может облегчить и удешевить для оператора процесс получения такой лицензии.
Еще один важный момент - использование ТОЛЬКО сертифицированных СЗИ. Фактически, слов "сертифицированные СЗИ" в законе и подзаконных актах нет, но пункт 5 положения об обеспечении безопасности персональных данных при их обработке в ИСПДн, говорит о том, что СЗИ, применяемые в ИС, в установленном порядке проходят процедуру оценки соответствия.
Фактически, под процедурой оценки соответствия подразумевается та самая сертификация, и, если у СЗИ, применяемого у нас, нет сертификата, мы можем не заменять его, а договориться с одним из аттестационных центров (список которых есть на сайте ФСТЭК) о проведении процедуры оценки соответствия для этого СЗИ. Что будет стоить, вероятно, бешенных денег, но в итоге у нас будет сертифицированное СЗИ. Ход, по сути, достаточно глупый (на мой взгляд) и дорогостоящий, т.е. лучше сразу проектировать СЗПДн с теми СЗИ, которые уже имеют сертификат соответствия требованиям ФСТЭК.
Плюс, было много ссылок на 149 ФЗ, с которым я, увы, пока не успел познакомиться - возможно, после ознакомления что-то для меня прояснится.