Курс закончен, сертификат получен. Попытаюсь разобраться, что этот курс мне дал.
Собственно, не так уж много. Первое - я потыкался с SecretNet'ом. Второе, узнал немного о проведении проверок и получил вполне очевидные рекомендации. Третье - узнал о WingDoc. Если мы будем защищаться целиком своими силами - он может быть полезен. Четвёртое - немного узнал о Microsoft NAP. Вот его мы, возможно, когда-нибудь используем. Пятое - методика расчёта риска от Digital Security, с ней нужно разбираться, но первое впечатление таково, что это может быть полезным при работе. Ну и последнее - некоторое представление об ITIL и PMBok, хотя, про них нужно почитать самостоятельно, чтобы понять будет ли мне это полезно хоть когда-нибудь (словам лектора верить очень сложно, после того как он расшифровал ITSM как IT Security Management и два часа рассказывало том, что этот раздел посвящён исключительно ИБ).
В общем, после курсов у меня появилась "пища для размышлений", но шесть дней на это всё - это перебор. Курс можно было бы упихнуть в пару дней, либо в пяток вебинаров - было бы дешевле и без такого значительного отрыва от производства.
воскресенье, 17 февраля 2013 г.
Обучение в Softline. Итоги.
пятница, 15 февраля 2013 г.
День пятый. Ватный.
Учитывая, что вчера мы закончили практически всё, сегодняшний день был чрезвычайно ватным. Единственное более-менее интересное, что было сегодня - это ссылка на http://csrc.nist.gov - кучу американскх рекомендаций по ИБ, первые из которых относятся аж к 1995-му году, а последние к декабрю 2012-го.
В конце дня потыкались в WingDoc, о котором уже было упоминание несколько дней назад. Запросили демо-версию и обнаружили, что эта демка умеет делать только акты классификации ИСПДн, т.е. на модель угроз посмотреть не получилось. Плюс, выяснилось, что даже акт классификации она нам не сформирует, поскольку на машине не установлен Word, без которого документы не формируются.
В общем, в очередной раз я убедился в том, что русские поделки для ЗИ, с сертификатами ФСТЭК, создаются не для улучшения защиты, а исключительно для выкачивания денег.
четверг, 14 февраля 2013 г.
Четвёртый день
Поигрались ещё немного с SecretNet, с контролем целостности. Сегодня всё получилось нормально. Выбрали файлы для отслеживания и действие при нарушении целостности. Действия зависят от того как именно эта целостность контроллируется - либо с помощью хэш-функции, либо с помощью сравнения содержимого (т.е. SecretNet может в качестве эталона запомнить всё содержимое нужного файла). Если используется хэш-функция - SecretNet может либо проигнорировать это нарушение, либо заблокировать компьютер, либо заменить эталонное значение на изменённое. Т.е. при первом варианте, в журнале SecretNet'a появится запись о нарушении целостности, во втором тоже самое плюс заблокируется компьютер, в третьем - запись в журнале и замена эталонного значения. При этом, вернуться к эталону будет невозможно! Т.е. мы узнаем, что файл отличается от эталона, но что там был за эталон мы никогда не узнаем. Если же мы, например, будем проверять целостность операционной системы и вирус изменит содержимое какого-то файла, то, при неправильной настройке, "испорченный" файл может стать эталонным...
Для того, чтобы появилась возможность "вернуться" SecretNet в качестве эталона может использовать всё содержимое исходного файла. В этом случае, можно просто заменить контролируемый изменённый файл из сохранённого значения. То же самое произойдёт при удалении файла.
Спросил про то как правильно организовать "поздравлялку" с днями рождения. У нас используется программа birthday - она выводит "сегодняшних" и "завтрашних" юбиляров. Вопрос - какое основание использовать при сборе этих данных?
Предлагается два варианта - первый, в трудовой договор вписывать пункт о поздравлениях. В этом случае не нужно будет брать согласие, а в качестве основания обработки в перечне ПДн можно указать: "исполнение трудового договора". Хотя, конечно, вариант сомнительный.
Другой вариант - в какой-нибудь "кодекс корпоративной этики" добавить "поздравлялочный" пункт, а в согласии и перечне ссылаться на этот кодекс. Тут есть одно большое НО - когда я составлял перечень ПДн на заводе, находил информацию о том, что в качестве основания нельзя использовать локальные акты - только законы и НПА, либо Устав. Само-собой, в Устав никто ничего подобного вписывать не будет, поэтому, насколько законным будет вариант с локальным актом непонятно.
Видимо, будем искать третий вариант.
Немного узнал про Microsoft NAP. Должно быть удобная штука для тех организаций, в которые могут подключаться, например, домашние ноутбуки. Принцип примерно такой - в сети хранятся "эталонные" настройки - антивирусная программа, минимальный набор установленных обновлений, ОС, сетевые настройки и, при включении домашнего ноутбука в сеть, настройки ноута сверяются с эталонными. При совпадении ноутбук попадает в сеть, при несовпадении, настройки ноутбука "догоняются" до минимально необходимых и проверка повторяется.
Тоже стоит подумать о применимости. Может быть, если мы-таки доживём до подключения к сети из дома, эта штука и пригодится.
Ну и напоследок, нам дали рекомендации по тому как себя вести в случае проверки:
1. Сразу же после получения программы проверки - собрать всю документацию и, при возможности, дописать недостающее.
2. Оповестить всех сотрудников о предстоящей проверке. Заставить всех "освежить память", чтобы они помнили на основании каких инструкций они получают доступ к ПДн.
3. Документы должны содержать актуальную информацию на дату проверки.
4. Уделить особое внимание:
1) организации пропускного режима;
2) отделу кадров;
3) бухгалтерии;
4) содержимому сайта - тому что общедоступно, возможно, туда могли попасть ПДн не являющиеся общедоступными.
5. Оперативно реагировать на замечания проверяющих. Если исправлять небольшие недочёты по ходу првоерки, возможно, это устроит проверяющих и никаких предписаний выписано не будет.
среда, 13 февраля 2013 г.
День третий. Экватор
Контроль доступа осуществляется на основе мандатного или дискреционного механизмов. Дискреционный доступ реализован и в операционной системе (каждому конкретному файлу "назначаются" пользователи, которые могут читать/писать/изменять файл) и не особо интересен. С мандатным интереснее. Во-первых, выделяются категории файлов, например - ПДн, коммерческая тайна и общедоступные данные. Во-вторых, каждому файлу назначается выбранная категория (поддерживается механизм наследования, т.е. можно на папку повешать "гриф" ПДн и все файлы, созданные в ней, или перемещённые туда, будут обладать этим грифом). В-третьих, для каждого пользователя определяется "наиболее серьёзный" гриф, который должен быть ему доступен и имеет ли этот пользователь возможность самостоятельного назначения грифов для файлов. Т.е., если пользователю, например, доступен гриф ПДн, то он сможет видеть все общедоступные файлы и файлы с грифом "ПДн", "коммерческая тайна" будет ему недоступна, а пользователь с правами доступа к коммерческой тайне, будет иметь возможность доступа к данным с любым грифом.
Проблемных мест, к сожалению, хватает. Во-первых, имеется возможность назначения всего трёх видов грифов, один из которых должен быть общедоступным. Это достаточно крупное разделение. Во-вторых, назначение доступных грифов пользователям - оно производится для каждого пользователя, нельзя назначить доступность грифа группе пользователей.
Контроль устройств. С ним всё относительно просто. Выбираются устройства и назначаются разрешения для конкретных пользователей. Удобно тем, что можно каждому пользователю выдать по флэшке и разрешить компьютере втыкать этому пользователю именно эту флэшку, а все остальные накопители запретить. В плане учёта материальных носителей ПДн - очень удобно. Есть возможность назначать права вообще на всё - вплоть до ядер процессора - применимость не совсем понятна, но есть и ладно.
Контроль целостности. К сожалению, сегодня мы с ним разобраться не успели. Смогли выбрать каталог для контроля целостности, создать там пару файлов и задать эталонные значения. Что должно происходить дальше - непонятно - то ли SecretNet должен запретить их изменение, то ли не должен. Ответ получить не смогли. Единственное, что контроль целостности ОС тормозит так сильно, что загрузка ОС вместо привычных 3-4 минут тянулась минут 10. Если на заводе загрузка будет идти столько же - пользователи нас казнят.
Плюс, нам не показывали, но сказали, что есть "центральная административная" консоль, через которую SecretNet можно настраивать в сети удалённо, со своего рабочего места. На курсах в ОмГУ говорили, что при таком варианте все журналы сообщений будут по сети сливаться на центральную машину и генерировать приличный траффик, тут же говорят, что журналы будут храниться локально и их просто можно просматривать с "центральной" машины.
После SecretNet'a некоторое время потратили на модель угроз. Ничего нового не было, всё есть в базовой модели угроз ФСТЭК и их же методических рекомендациях по выявлению актуальных угроз. Единственное, что при определении уровня исходной защищённости ("УИЗ"), можно сыграть на нечёткости формулировок и снизить этот уровень (например под одноточечным доступом в сеть общего пользования можно понимать как отдельный компьютер, "физически подключенный" к интернету, так и шлюз, через который выходит в интернет сотня пользователей).
Кроме того, для составления модели угроз можно воспользоваться программным продуктом WingDoc, он стоит порядка 15 тыр, гуглится легко. Отвечая на вопросы программы, формируется модель угроз и какие-то сопутствующие документы.
До составления модели угроз самостоятельно я не доходил, так что для меня стало открытием, что для актуальных угроз (например, хищение hdd из системного блока без боковой крышки), нужно составлять ещё и список конкретных уязвимостей. Например, для этой угрозы, уязвимости могут быть такими: отсутствие регламента постановки помещения под охрану и, собственно, отсутствие крышки на системном блоке. Каждая из этих уязвимостей должна закрываться отдельно.
Для оценки рисков, вызванных наличием актуальных угроз, можно воспользоваться методикой оценки рисков от Digital Security. Формулы достаточно не сложные, обоснование тоже вроде как присутствует. О других методиках оценки рисков, нам никто не рассказывал.
По сути, подзаконные акты не требуют и не описывают процедуру оценки рисков, но оценив риски, можно закрывать угрозы не в произвольном порядке, а в порядке уменьшения риска, что достаточно логично.
Составив список актуальных угроз, можно провести классификацию ИСПДн по приказу трёх (который до сих пор никто не отменял) и установить уровни защищённости по постановлению 1119. С классификацией по приказу трёх я не хочу даже связываться, для специальных систем она делается на основании "экспертной оценки" (эксперт считает, что исходя из обрабатываемых ПДн и актуальных угроз, субъекту может быть нанесён значительный/незначительный вред и определяет класс ИСПДн), а вот уровень защищённости, по модели угроз, определяется хорошо. Во-первых, определяется тип актуальных угроз:
1-й, если актуальны угрозы НДВ в системном ПО;
2-й, если актуальны угрозы НДВ в прикладном ПО и неактуальны в системном ПО;
3-й, если угрозы НДВ не актуальны.
Во-вторых, определяется какие ПДн и в каком количестве обрабатываются (специальные, биометрические, иные, общедоступные) и на основании этих двух параметров определяется требуемый уровень защищённости.
Проблема здесь может крыться в том, что не все сертификаты ФСТЭК гарантируют отсутствие НДВ в ПО, на это следует обратить внимание.
В принципе, если ОС сертифицирована и угрозы 1-го типа неактуальны, то ИСПДн завода (с учётом того, что мы обрабатываем иные ПДн менее чем 100 000 человек) нужно будет обеспечить уровень защищённости 3, что вполне приемлимо.
Перечень применяемых мер, для обеспечения требуемого уровня защищённости, будет утверждён ФСТЭКом позднее. В декабре выходил проект их приказа, достаточно сильно раскритикованный в сети.
Далее, после определения уровня защищённости, нужно будет составить ТЗ на создание системы защиты ИСПДн. Желательно по ГОСТу 34.602. Вообще же, для оформления документов, желательно пользоваться ГОСТом 6.30. В этом случае, вряд ли у проверяющих будут претензии как минимум к оформлению.
вторник, 12 февраля 2013 г.
День второй
Сначала мы быстро посмотрели на возможности Microsoft NAP, о котором я ранее даже не слышал. Правда не совсем понятна область применения. Возможно, при рассмотрении модели угроз, ясность появится.
Максим (наш лектор) рассказывал о технических каналах утечки. Рассказал и забавную историю о том, что при поиске "закладок" ("жучков"), при обнаружении такой закладки, прежде чем сообщать об этом заказчику, нужно направить запрос в ФСБ - узнать не они ли её установили.
Большую часть дня мы потратили на рассмотрение ОРД. Он обратил внимание на то, что когда приходит проверка, проверяющие могут не требовать какие-то конкретные документы для предоставления, а просить информацию в виде: "А каким образом вы закрываете требование 152 ФЗ, ст.19, п2., пп. 8 (например)". Как-то раньше о таком подходе я не задумывался, в основном искал именно список документов, которые требуют проверяющие. Надо будет взять 152 ФЗ, все подзаконные акты и пройтись по ним, составить свой список и сравнить с тем, который он нам дал.
Всего в списке Максима 31 документ, каждый мы быстро рассмотрели, хотя там всё понятно и из названия (типа "Политика безопасности", "Список лиц, допущенных к обработке ПДн" и т.д.).
Кроме того, он даёт такой список работ (в общем виде):
1. Выделение процессов обработки ПДн.
2. Выделение ИСПДн в различные подсистемы.
3. Классификация ИСПДн.
4. ТЗ на СЗПДн.
В принципе, примерно такой же план, давали и в ОмГУ. Первый пункт, этого плана, в свою очередь, делится на следующие шаги:
1. Назначение ответственного и комиссии.
2. Изучение внутренней и внешней ОРД - т.е. всех документов циркулирующих на предприятии.
3. Интервьюирование должностных лиц - определяем кто и что конкретно делает, выделяем цели обработки ПДн.
4. Идентификация точек входа и выхода информации, пути её перемещения на предприятии.
5. Изучение содержимого входящих и исходящих потоков информации - на этом этапе можно попытаться найти лишнюю информацию.
6. Выявление информации обрабатывающейся без использования средств автоматизации и с их использованием.
7. Анализ и уточнение оснований обработки, установка условий начала и прекращения обработки ПДн, определение категорий, обрабатываемых ПДн.
8. Определение структурных подразделений и должностных лиц, использующих ПДн в своей работе.
9. Составление и утверждение перечня ПДн, с учётом целей, оснований и сроков обработки.
В итоге, на выходе будет: перечень ПДн; список лиц, допущенных к обработке ПДн; описание процессов обработки ПДн.
Для описания самих процессов, по словам Максима, удобно использовать нотацию IDEF0, а для описания логики IDEF3. Честно говоря, с трудом представляю себе размер такой схемы для нашего предприятия, но, возможно, для небольших предприятий такой подход подойдёт.
Что будет дальше - будем посмотреть.
понедельник, 11 февраля 2013 г.
День первый
Итак, завершился первый день курсов по обеспечению безопасности персональных данных от софтлайна.
Понравилось, что в отличии от курсов в ОмГУ, на которых я был в 2011-м году, всё происходит намного быстрее и весь курс, в целом, имеет более практическую направленость. Сегодня, за 5 часов, мы бегло прошлись по самому 152 ФЗ и новому постановлению правительства 1119 от 01.11.2012. И это ещё одно отличие от ОмГУ - там мы в декабре 2011-го изучали "старую" версию 152 ФЗ, без "свежих" на тот момент поправок от 25.07.2011. Так же, мы бегло рассмотрели возможности SecretNet и VipNet. В принципе, об использовании SecretNet'а можно было бы подумать, если бы все файлы на шарах были рассортированы по категориям.
Особенно же интересны сегодня были два момента. Первый - это является ли фотогрфия в пропуске биометрическими ПДн или нет. В интернете единого мнения нет. Одни говорят, что по ГОСТу к биометрии можно отнести только один тип фотографий - те, которые используются в загранпаспорте и им подобные - т.е., хранящих, помимо изображения, ещё кучу дополнительных данны (набор контрольных точек, пол и т.д.). Другие говорят, что если эта фотография используется для "установления личности субъекта персональных данных", то она, согласно 152ФЗ (и ПП 1119) является биометрией (ст. 5 ПП 1119). Наш лектор сторонник первой точки зрения. Он говорит, что вообще определение "установление личности" можно найти только в уголовном кодексе и оно возможно только по "настоящей" биометрической фотографии, при наличии специального оборудования. То же, чем занимается охранник на КПП - это "удостоверение тождественности
личности гражданина с лицом,
изображенным на фотографии", что отличается от "установления личности" как идентификация от аутентификации. Т.е. он признаёт, что человек на фото совпадает с человеком, предъявляющим пропуск, но не гарантирует, что в пропуске всё верно (т.е. он не знает, правильно ли там указана фамилия, например). В общем, об этом стоит подумать.
Второй момент - это озвученная лектором позиция ФСТЭК о выходе новых подзаконных актов. "Считайте все выходящие нормативные документы дополнением к уже вышедшим ранее, если явно не указанно обратное". Т.е., в ПП 1119 явно указано, что ПП 781 утратило силу, соответственно, само ПП 781 принимать во внимание не требуется, а вот, например, приказ 58 (дочерний от ПП 781) остаётся действительным до тех пор, пока его явно не опишут как "утративший силу". Позиция неприятная для меня, как представителя оператора, но хотя бы понятная. В принципе, пока в плане проверок нас нет, будем продолжать ждать выхода новых документов.
Ну и ещё один забавный момент. Лектор при мне позвонил какому-то знакомому, работающему у Челябинского лицензиата по ТЗКИ, и спросил сколько будет стоить разработать комплект документации по 152 ФЗ для предприятя, предположительно К2-К3 и получил ответ: "20-25 тыр". Нам же, местные, предлагают разработать комплект документов за 500 тыр (цифра из реального коммерческого предложения). Вот такие дела. Будем ждать следующего дня.