Представьте, что вам дана уникальная возможность при действующей редакции ФЗ-152 все-таки поучаствовать в разработке подзаконных актов (не меняя текста ФЗ-152). Т.е. как-то выкрутиться в ворохе "уровней защищенности", "требований по безопасности", "актуальных угроз", "видов деятельности" и других понятий нового старого ФЗ-152. Как бы вы выстроили стратегию и иерархию разработки подзаконных актов?
Понятно, что начинать надо с базовой модели угроз. C ней более менее все понятно. Чтобы не создавать вторую "базовую" модель от ФСТЭК я бы в новую модель включил бы стандартный минимум - вирусы, НСД, утечки и т.п. А уж расширять ее можно было бы на уровне отраслевых и "союзных" моделей.
Что дальше? Вид и объем персданных брать из приказа трех или новую градацию использовать? Зачем и почему?
С видами деятельности основная засада - их слишком много, если ориентироваться на всякие классификаторы ОКВЭД и т.п. Поэтому надо исходить из каких-то других критериев. Каких? Если в расчет брать виды не экономической деятельности оператора, а деятельности, связанной с обработкой ПДн, то по сути у нас их и не так много - Интернет-обработка, трансграничка, мультимедиа, мобильные устройства, облака. Все эти виды обработки/использования/передачи ПДн специфичны с точки зрения способов защиты и можно их описать в подзаконниках.
Затем я бы против угроз для каждого вида деятельности сделал бы две колонки - организационные и технические меры защиты. При этом зафиксировал бы, что организационным отдается приоритет (за основу взял бы ISO 29100/29101).
Ну и уже потом покумекал бы над требованиями к оценке соответствия. То, что она нужна в том или ином виде, понятно. Но и гнуть всех под обязательную сертификацию тоже неверно.
Дополнительно все это стоило бы еще поделить на два направления - для госорганов/муниципалов и коммерческих структур.
Вот как-то так! Есть иные мысли, предложения, замечания, комментарии?..
ЗЫ. Флеймить на тему бесполезности этой работы не стоит. Не верите в результат, лучше просто понаблюдайте за дискуссией. Есть конкретика - предлагайте, буду только благодарен. И помните, что под лежачий камень вода не течет ;-)
Понятно, что начинать надо с базовой модели угроз. C ней более менее все понятно. Чтобы не создавать вторую "базовую" модель от ФСТЭК я бы в новую модель включил бы стандартный минимум - вирусы, НСД, утечки и т.п. А уж расширять ее можно было бы на уровне отраслевых и "союзных" моделей.
Что дальше? Вид и объем персданных брать из приказа трех или новую градацию использовать? Зачем и почему?
С видами деятельности основная засада - их слишком много, если ориентироваться на всякие классификаторы ОКВЭД и т.п. Поэтому надо исходить из каких-то других критериев. Каких? Если в расчет брать виды не экономической деятельности оператора, а деятельности, связанной с обработкой ПДн, то по сути у нас их и не так много - Интернет-обработка, трансграничка, мультимедиа, мобильные устройства, облака. Все эти виды обработки/использования/передачи ПДн специфичны с точки зрения способов защиты и можно их описать в подзаконниках.
Затем я бы против угроз для каждого вида деятельности сделал бы две колонки - организационные и технические меры защиты. При этом зафиксировал бы, что организационным отдается приоритет (за основу взял бы ISO 29100/29101).
Ну и уже потом покумекал бы над требованиями к оценке соответствия. То, что она нужна в том или ином виде, понятно. Но и гнуть всех под обязательную сертификацию тоже неверно.
Дополнительно все это стоило бы еще поделить на два направления - для госорганов/муниципалов и коммерческих структур.
Вот как-то так! Есть иные мысли, предложения, замечания, комментарии?..
ЗЫ. Флеймить на тему бесполезности этой работы не стоит. Не верите в результат, лучше просто понаблюдайте за дискуссией. Есть конкретика - предлагайте, буду только благодарен. И помните, что под лежачий камень вода не течет ;-)
105 коммент.:
Все более-менее, мне лично непонятно это:
> Дополнительно все это стоило бы еще поделить на два направления - для госорганов/муниципалов и коммерческих структур.
Непонятно основание, если муниципал с точки зрения обработки ПДн занимается тем же, что и коммерс - в этом нет никакого смысла, требования одни для всех.
Разве что методы их выполнения в плане "сертификации и аттестации" - то, наверное, да.
На мой взгляд самый важный момент - добиться адекватной борьбы с угрозами. Для чего необходимо сформировать подходы по формированию и оценке угроз.
Затем, нужно проработать два момента:
1 - пусть разработчик системы применяет что угодно для нейтрализации угроз... но он должен как то убедиться в том, что угрозы нейтрализованы
2 - разработчик системы должен контролировать процесс выявления угроз и их нейтрализации в процессе эксплуатации
Вопрос не в том, сертифицированные средства или нет - вопрос - целевая система выполняет функции ?
На счет видов деятельности, Алексей, я с вами не согласен.
Модели угроз и перечни требований должны учитывать отраслевую специфику.
Поэтому для начала правительство РФ должно разработать модель и требования для ограниченного перечня видов деятельности, связанных с обработкой ПДн. Например для госсуслуг.
Для остальных видов деятельности Правительство должно организовать технические комитеты или поручить какой-то организации организовать технический комитет, на котором будут разработаны отраслевые модели угроз и перечни контрмер.
Попробовали по линии ОНФ http://komiexpo.com/news/508/
Несколько, так скажем, в упрощенном виде :)
А отраслевые комитеты - хорошо!
Алексею Волкову: Деление именно по причине аттестации и т.д.
Сергею Борисову: Правительство ДОЛЖНО... Если ждать, что оно что-то родит, мы получим новое четверокнижие. Я ведь написал, что есть возможность вмешаться хотя бы в подготовку подзаконных актов. Отраслевые модели угроз Правительство писать не будет ;-(
Евгению и Андрею: Супер. Спасибо за идею.
Есть ИСПДн общие для ВСЕХ операторов: Зарплата/Кадры. Вот для нее и пусть установят МУ, уровни и требования. Остальное - я за отраслевые комитеты.
Оценка соответствия - тест на проникновение при вводе (изменении) и ежегодно. Дешево и сердито + актуализация по новые угрозы.
Алексею Лукацкому:
"3. Правительство Российской Федерации с учетом возможного вреда субъекту персональных данных, объема и содержания обрабатываемых персональных данных, вида деятельности, при осуществлении которого обрабатываются персональные данные, актуальности угроз безопасности персональных данных устанавливает"
Нигде не указаны сроки выполнения данного мероприятия.
Я не вижу противоречий если сегодня Правительство РФ выпустит документ "Уровни защищенности и требования к защите при обработке ПДн сотрудников"
Завтра по результатам работы отраслевого комитета выпустит "уровни защищенности и требования к защите при обработке ПДн при оказании платежных услуг"
Послезавтра по результатам работы отраслевого комитета выпустит "уровни защищенности и требования к защите при обработке ПДн при оказании услуг связи"
Через неделю по результатам работы отраслевого комитета выпустит "уровни защищенности и требования к защите при обработке ПДн при оказании государственных услуг"
Сергей пишет...
>Есть ИСПДн общие для ВСЕХ операторов: Зарплата/Кадры.
Здесь все гораздо проще ;-)
Тут не требования Правительства нужны, а правильно составленные поручения операторов (которые в подавляющем большинстве гос-ы или завязанные на них структуры)
2toparenko
Поручения - это аутсорс. Большинство делают сами.
Сергею Борисову: Это вы не видите противоречий. А Правительство в 3-хмесячный срок хочет подготовить ВСЕ документы. И ему все равно, что думают про это операторы и субъекты.
Как правильно - не будет. Просто есть возможность попытаться внести коррективы в то, что готовится сейчас.
"Что дальше? Вид и объем персданных брать из приказа трех или новую градацию использовать? Зачем и почему?"
Градацию использовать с учетом возможного вреда субъекту персональных данных, объема и содержания.
А вообще что не бери всё равно глупость получается. Если отраслевое то это очень огромое и неопределенное понятие получается, если по степени ущерба то опять же кто и как будет его оценивать и применять базовые принципы. Деятельность связанная с обработкой ПДн опять же понятие расплывчатое и неопределенное. Хотел было предложить по аналогии с документами имеющими гриф "Для служебного пользования, секретно, совершенно секретно, но опять глупость получается...
Делить на гос/не гос органы смысла нет, выше уже сказали что закон должен быть один для всех
Коллеги, я все-таки просил не флеймить, а предлагать что-то конкретное.
Что касается классификации ПДн, считаю, что нужно конкретно, без размытостей, двусмысленностей, общих понятий и прочих "и т. д." для каждого уровня (категории ПДн) создать перечень видов ПДн, относимых к каждой категории. Это нужно, чтобы исправить ситуацию с чрезчур общим определением ПДн и исключить в будущем споры типа: "мы считаем, что это ПДн, потому что (определение ПДн)" - "нет, это не ПДн, потому что (определение ПДн).
Также нужно сохранить зависимость жесткости требований от количества обрабатываемых ПДн. Возможно, до какого-то уровня (скажем, до пятисот записей), следует исключить из области действия требований по ИБ, либо отдать эту ситуацию на регулирование соглашениями между субъектами ПДн и операторами. Тем самым можно спасти малый бизнес, у которого из ПДн только трудовые книжки и отчетность в фонды по сотрудникам. Для них достаточно в трудовом договоре описать ответственность работодателя за утечку.
Вместо сертификации-аттестации в идеале - тест на проникновение при вводе в эксплуатацию, а также ежегодно и при внесении значительных изменений. Что такое значительное изменение - опять же нужно четко определить. При обнаружении уязвимостей, через которые возможно нарушение кофиденцальности ПДн, следует устранить уязвимости и выполнить повторный тест на проникновение, для подтверждения того, что уязвимости устранены. На мой взгляд, это хорошя норма из PCI DSS, которую можно перенять.
для начала классифицировать ПДн, затем сделать не две, а три колонки: классификация ПДн | организационные | технические меры защиты
Обоснование: защищать необходимо сами ПДн, и уровень защиты должен быть адекватным классификации ПДн, при таком подходе не имеет значение гос или коммерческий орган и соответственно отраслевая принадлежность тоже опускается.
Пример: для работы только с ФИО можно ограничится антивирусным ПОЛ или орг.мерами, при обработке паспортных данных, ИНН должен быть иной уровень защиты, на порядок выше.
да, как указал Sergey.Shustikov необходимо учитывать еще и объем, тогда табличная часть будет выглядеть примерно так:
классификация ПДн | объём | организационные | технические меры защиты
Базовый | до 300 чел | заявление о разрешении обработки ПДн, Положение о защите ПДН, Заявление на обработку ПДн | на усмотрение руководства
Наиболее системный на сегодня вариант методики всё-таки изложен в ISO 27001. Он включает важнейшие этапы менеджмента ИБ:
1. Инвентаризация активов.
2. Классификация активов.
4. Исследование и оценка рисков.
5. Планирование мероприятий.
6. Обеспечение мероприятий.
7. Измерение эффективности мероприятий.
8. Улучшение системы ИБ.
У американцы есть еще один этап "Минимизация", но при грамотном подходе это включено и имеется ввиду в 1,2,3 и тд.
Что касается рисков - модели угроз, которая и завязывается на отрасли. в ISO 27005 подход такой: всё должно исходить из результатов инвентаризации и классификации. При этом ДВА важнейших актива по стандарту, которые нужно инвентаризировать:
1. Информация.
2. Процессы.
ISO вообще с 2000 года проповедует процессный подход в ISO 9001, 14001, 18001, 27001 и т.д.,
Так вот ПРОЦЕСС, имея четкие границы в виде входа и выхода, а также норм и исполнителей, обосновывает и цели обработки и вид информации, которая этому процессу нужна.
Отраслевые же специфики управления рисками вытекают из того набора процессов, которые там есть.
А в общем методика может оказаться универсальной для ВСЕХ и её даже придумывать не надо.
Да, еще. Цель управления рисками (модели угроз) состоит в установлении _осознанной_ и _понятной_ взаимосвязи между активами (их ценностью) и мерами защиты. Этот момент нужно не упустить, а то в варианте приказа Трех этого тоже не было и не понятно было зачем нужна модель угроз.
1. При определении уровней защищенности исходить из того, что требуется обеспечить 3 характеристики:КЦД.
2. В идеале уровень защищенности формируется на основании матрицы (таблицы), в которой количество столбцов = градации по чилу субъектов (1-300, 301-1000, 1001-100000, более 100000). А в строках - исходные данные по ИСПДн: одно-много пользовательская, с подключением к СМИО или без, распределенная и т.д. Это надо вместе думать. А главное - весовые коэффициенты, которые вносят эти исходные данные для соответствующего количества субъектов. Итоговый уровень защищенности - сумма коэффициентов по столбцу.
Безусловно, в идеале хотелось бы такой же подход, как в ISO 27001, но предполагаю, что в нашем случае это не получится во-первых по уже существующим нормам 152-ФЗ, не предполагающим гибкости, а во -вторых по политическим причинам.
Очень хотелось бы видеть модель угроз не предопределенной, а определяемой на основе анализа рисков для каждого конкретного предприятия.
А я против выбора СЗИ в зависимости от объёма... как вспомнишь этот бред когда люди тычутся чтобы уменьшить число от 1012 до 997, аж противно становится. По уму - штраф оператора должен увеличиваться пропорционально числу субъектов (это его мотивирует), а законодательством уровень защиты определяется в зависимости от типа ПДн.
ПДн я бы разделил на (можно из них вывести "уровни защищённости):
1. "Ликвидные" ПДн - это те, что легко конвертируются в выгоду злоумышленника - копия паспорта, номера кредиток (то, что по уму и должно защищаться в первую очередь) - это обычно материальный ущерб субъекту.
2. Специальные ПДн - это те, что из закона - подразумевается что их раскрытие наносит моральный ущерб субъекту (определение из закона).
3. Общая категория - всё, что осталось, и что вообще вряд ли субъектам принесёт заметный ущерб (номер телефона, адрес, образование, опыт работы и проч.)
4. Обезличенные и общедоступные (отсутствие мер или минимум мер по целостности).
Соответственно у 1 уровня максимальная защита, у 3 - минимальная, у 4 - по решению оператора.
Это будет мотивировать оператора обезличивать данные, и разделять сегменты ИС по ущербу субъекту.
Биометрические ПДн - фигню типа 512 ПП РФ желательно вообще выкинуть, ибо такие ущербные требования к биометрическим носителям только будут заставлять операторов прятать или обходить биометрию, но не защищать. По уму, наверно, биометрические данные надо хранить в неизвлекаемом виде (необратимое шифрование) - но это сулит ещё большие проблемы с ФСБ... Поэтому здесь затрудняюсь.
Может быть не стоит загромождать предметную область ФЗ-152 целостностью и доступностью? Закон изначально по духу направлен на защиту конфиденциальности.
Риски по Ц и Д - это риски оператора, а не субъекта.
Алексей, зависимость от объема - это не бред, а реальный способ спасти малый бизнес, основная деятельнось которого никак с обработкой ПДн не связана. ПДн у них только в кадровом делопроизводстве по 1 - 300 сотрудникам.
Зачем хлебопекарню, где работают 5 человек нагибать на СЗИ?
Зачин хороший, хотя конечно вероятность успешного внедрения мала. Тем не менее, хочу заметить, что формат комментариев к блогу не совсем удачен.
По теме. Коллеги, один из важнейших этапов - классификация ПДн - в его существующей реализации не учитывает, на мой взгляд, важнейшей характеристики при установлении уровня защищенности, а именно - цель обработки.
Примеры.
1. В организации обрабатывается ПДн сотрудников - ФИО, профессия, стаж, медицинские ограничения по допуску к работам (например дальтоники не могут быть водителями). В количестве 1500 шт.
2. В кожно-венерологическом диспансере (психиатрической лечебнице, наркологической клинике, клуб бывших алкоголиков) в одной из систем обрабатывается следующий состав ПДн клиентов: ФИО, адрес, количество обращений. Без диагноза!
Скажите, какой класс будет у этих систем и насколько он будет соотноситься с возможным ущербом в случае разглашения этих сведений?
Да, в клинике клиентов было не более 50. Это по поводу количества и малого бизнеса...
Сергею Шустикову: как раз на ISO 27001 всё хорошо накладывается и на практике, т.к. подход универсален и исповедует здравый смысл, не зависимы от изменчивости норм. Все имеющиеся сегодня методики ПДн тоже находят своё место в перечисленных этапах. Весь вопрос в правильной трансляции и обосновании терминологии.
Сергею Шустикову: О целостности и доступности. Если вчитаться в цель закона, то она состоит в ЗАЩИТЕ ПРАВ СУБЪЕКТОВ ПДн. Мы не ПДн защищаем, а права субъектов ПДн, даже в статье 19! Поэтому и целостность, и доступность.
Сергей пишет...
>Поручения - это аутсорс. >Большинство делают сами.
См. мой комент от 2 августа 2011 г. 17:32 в соседней ветке http://lukatsky.blogspot.com/2011/08/152.html
Сергею Городилову:
Я согласен, что цель - это защита прав субъектов ПДн. Однако, как и какие права субъекта ПДн может нарушить нанесение ущерба доступности и целостности ПДн в информационных системах оператора?
Большинство аппелирует к международным стандартам. Это правильно. Нужно для начала определиться с методами, зафиксировать основные риски и угрозы в базовой модели угроз. Но нельзя фиксировать все. Величину риска оператор должен определять сам, но по строго заданной методике. Это вообще нельзя делать в формате модели угроз. В идеале это должна быть методика оценки рисков, в которой основные риски зафиксированы на уровне Правительства или регуляторов, дополнительные (отраслевые) риски на уровне отрасли, частные риски на уровне оператора. При этом зафиксированы - это не значит оценены.
Вообще мы с коллегами тоже обсуждали проблему разработки отраслевых моделей угроз и ситуацию с новым ФЗ-152. В письменном виде мысли зафиксировались в паре постов.
Чем черт не шутит, попробую тоже поучаствовать. Попытался сформулировать, что бы хотел видеть в целом, получилось длинновато и немного сумбурно:
http://alt777.blogspot.com/2011/08/152.html
Алексей Лукацкий - вот это подход профессионала! Мега респект за пост. Вопрос: у Вас реально есть возможность предложить свой вариант?
Сначала мои замечания к моим предложениям: они могут быть не стандартными своим подходом (но не оригинальными). Сразу не отвергайте. Надо помусолить. Отложить. Еще раз посмотреть. Откусить :) А потом уже выплевывать и морщиться. Можно ругаясь плохими словами. Всем кто найдет в себе силы так проделать - спасибо.
Теперь предложения.
Общие предложения 1. Структура работы.
1. Определить проблему (составить дерево целей и задач)
2. Определить целевую аудиторию
3. Описать целевую аудиторию (и проверять последующие решения на соответствие ее возможностям)
4. Определить взаимосвязи с иными областями
5. Определить условия использования документов (описание среды их использования)
6. Определить список ограничений (проверять на соответствие ему каждый следующий этап)
7. Определить имеющиеся ресурсы (любого типа)
8. Определить перечень альтернативных моделей решения
9. Выбрать модель на основании максимально соответствия пп. 3, 4, 6, 7 (или 2 крайних и одну серединную)
10. Определить перечень документов, общее назначение
11. Определить систему документов, их взаимосвязь
12. Определить целевого пользователя каждого документа
13. Определить содержание документов
14. Определить требования к текстам подзаконных актов (ПЗА) (как писать - я например за каноническую форму текста, кому-то нравиться ссылочная или забубенная какая-нибудь - чтоб никто не понял ничего)
15. Определить тезаурус для документов
16. Разработка текста каждого документа с проверкой соответствия пп. 3-7 и 11-15 (каждое несоответствие должно однозначно отвергаться)
Общие предложения 2. Описание работы.
Конструктивное предложение: давайте займемся пока этапами 1-8. По команде Лукацкого проведем закончим описание этих этапов и перейдем к оформлению каждого. Это будет обоснование. Перечень экспертов с их заслугами можно привести в конце этого документа :) По следующей команде Лукацкого проведем экспертную оценку моделей и определимся с одной или несколькими (не более трех). Для каждой из выбранных моделей их приверженцы и примкнувшие к ним попробуют выполнить пункты с 10 по 16.
Можно для каждого этапа создать по теме, куда все все по этому этапу скидывают. (Ну и наглый я. Пришел в чужой огород и там раскомандовался. Простите!!! Ну не ко мне же всех звать :) А к Вам куча народу ходит. Даже Емельянников(!) заглядывает ;) ) Обсуждение можно было бы и раскидать по блогам, но сомневаюсь, что потом удастся собрать. Или кто еще площадку предложит (только не вики - не подходит она для такого режима, сложна по сравнению с блогом)). Еще момент. Всем надо только предлагать - эдакий мозговой штурм. А когда в единый документ сведутся все предложения, тогда и пообсуждать можно. У лукацкого должно с лихвой хватить авторитета отмодерировать нерадивых )))) При работе по плану необходимо учесть: этапы с 1 по 8 слабо связаны между собой; этапы с 10 по 16 жестко связаны.
Специальные предложения. Вариант 1 (от ZZubra). Первая иттерация.
Этап 1. Определить проблему (составить дерево целей и задач)
1. Разработать документы для реализации статьи 19 152-ФЗ
1.1 Обеспечить соответствие существующей нормативной базе
1.2 Обеспечить простоту применения конечным пользователем
1.3 Обеспечить тиражируемость решений
1.4 Обеспечить гибкость и относительную независимость от применяемых технологий
1.5 Обеспечит плавность перехода с существующих требований
1.6 Обеспечить простоту доработки
1.7 Обеспечить минимизацию затрат (в рамках требований) конечным пользователем
1.8 Обеспечить простоту понимания и исполнения конечным пользователем
1.9 Разрешить возможность применения дополнительных к обязательным мер и средств, не отвечающих установленным требованиям
1.10 Обеспечить многоуровневость требований и критерии достаточности уровней
1.11 Обеспечить альтернативность мер и средств, в том числе принцип замены/замещения мер (типа для автономной можно ограничиться журналом вскрытия помещения, железной дверью с печатью и замком и решеткой на окнах - не ставить ЗСИ от НСД)
1.12 Обеспечить системность в ликвидации основных каналов утечки информации
1.13 Обеспечить адекватность предъявляемых требований к условиям решаемых задач
1.14 Обеспечит научность работ, системность их выполнения
1.15 Обеспечить принцип эволюции требований
1.16 Обеспечить единство теории и практики
1.17 Обеспечить соответствие новым технологиям и угрозам
1.18 Обеспечить диференциацию требований для различных организаций по определенным критериям с выдвижением минимального набора требований к каждому классу
1.19 Обепсечить модульность системы документов/требований
1.20 Обеспечить простоту контроля за состоянием всех апектов влияющих на систему защиты
1.21 Обеспечить относительную непрерывность выполнения требований
Можно ввести другой уровень для объединения подпунктов, по какому-то признаку. Может несколько в один по-включать.
Этап 2. Определить целевую аудиторию
Целевой аудиторией являются:
- контролирующие органы и в них проверяющие
- производители СЗИ/СКЗИ и в них все кто задействован в разработке
- организации-лицензиаты (для простоты - сюда же всех интеграторов) и в них все кто (зарабатывает деньги) проектирует и создает системы защиты ПДн
- организации, которым надо защищать ПДн и в них руководители, администраторы (где есть) и конечные пользователи
- производители прикладного ПО (в том числе и с применением СУБД)и в них все кто задействован в разработке
- организации-внедренцы прикладного ПО и те кто внедряет и подправляет напильником под конкретные системы
- органы исполнительной власти, создающие системы межведовственного взаимодействия
Этап 3. Описать целевую аудиторию (и проверять последующие решения на соответствие ее возможностям)
1. Контролирующие органы и в них проверяющие
???
2. Производители СЗИ/СКЗИ и в них все кто задействован в разработке
???
3. Организации-лицензиаты (для простоты - сюда же всех интеграторов) и в них все кто проектирует и создает системы защиты ПДн
3.1 Технические аспекты: СЗИ не отвечают применяемым технологиям, программному обеспечению, а ведь на них заказчик уже потратил немеряно бабла. Фактическое отсутствие технической поддержки от производителей СЗИ (типа читай мануал - так там у Вас нет - у меня такой же мануал как у тебя [копирайт Инфотекс год назад], напишите нам о Вашей проблеме [копирайт Информзащита], перезванивает через неделю - а вы решили проблему - да- расскажите как [копирайт Информзащита], а как настроить Ваше СЗИ, ну хоть примерчик один - нет ответа второй год [копирайт Газинформсервис] и так по всем, простите, кого не написал) При этом и в техподдержке есть Человеки!
3.2 Документарные аспекты: сложность добывания нормативных документов, отсутствие менеджмента качества, отсутствие стандартов исполнения документов (в том числе содержания), надо все в бумаге - а это не актуально и ОЧЕНЬ много.
3.3 Социальные аспекты
3.3.1. Руководители - срубить бабла одномоментно
3.3.2. Исполнители - не читаются нормативные документы, теряются в трактовках, не считают обязательным исполнение нормативных требований (часто из-за незнания)
4. Организации, которым надо защищать ПДн и в них руководители, администраторы (где есть) и конечные пользователи
4.1. Технические аспекты:
применяются разнородные и однородные структуры построения систем; с возможностью разделения систем на подсистемы и без такой возможности; от одиночной автономной ПЭВМ до сложных территориально распределенных систем с сотнями ПЭВМ и иного оборудования; с описанием или без описания структур и выполняемого функционала, применяемых технологий и программного обеспечения; решения в системах применяется как без участия человека, так и с его участием; с постоянно изменяющейся структурой и неизменяемые в течении значительного промежутка времени; большое количество разнообразных информационных технологий, применяемых в системах. Нет нормальных средств ведения документации. Даже вручную - фиг с ним с автоматическим сбором списка ПО с компов - дайте СУБД для ведения списка компов и по, матриц доступа и т.д. - если будет автоматизация - это только плюс.
4.2. Документарные аспекты:
Отстутсвие или необоснованная закрытость документов, определяющих функциональные задачи обработки ПДн, несоответсвие имеющихся документов реальному состоянию дел, несоответствие требованиям законодательства (общего и специального), отсутствие нормативных документов по вопросам основной деятельности, отсутствие списков сотрудников и их неактуальность, постоянное изменение структуры организации, наименования должностей, исполняемых сотрудниками должностных обязанностей, в общем бардак. Закрепить в бумажках - фиг получится.
4.3. Социальные аспекты:
4.3.0 Высокая текучка кадров.
4.3.1 Руководители - неприятие нового вообще, неприятие новых требований, нежелание изыскания средств, непонимание цели работ, подверженность влиянию конечных пользователей (особенно главбуха). Неприятие вообще законодательства. Небудут ничего делать пока непосредственный руководитель не напишет.
4.3.2 Администраторы - завышенное самомнение, отсутствие желания изучения документов, сильная загруженность, ориентация только на технические аспекты, отсутствие желания применять новые средства, в том числе из-за отвратительной технической поддержки отечественных производителей. Короткий срок работы на одном месте. Боязнь руководителя. Многое на "авось".
4.3.3 Конечные пользователи - незнание своих должностных обязанностей, слабое владение компьютерной техникой, отсутствие желания изучать новое, сильная подверженность влияния СМИ (сюда же слухи), сильное психологическое давление на руководителей и администраторов. Непонимание ответственности за свои действия.
5. Производители прикладного ПО (в том числе и с применением СУБД)и в них все кто задействован в разработке
6. Организации-внедренцы прикладного ПО и те кто внедряет и подправляет напильником под конкретные системы.
7. Органы исполнительной власти, создающие системы ммежведовственного взаимодействия
Этап 4. Определить взаимосвязи с иными областями
Связи с:
1. правилами и принятыми решениями по обработке ПДн
2. карающими нормативными документами
3. нормативными документами по проверкам
4. наличием финансирования статей (в коммерческих - еще хуже, чем в госах. Типа надо для закупки 2 карандашей в Москву заявку писать)
5. новыми информационными технологиями
6. функциональными требованиями предъявляемыми технологическими процессами
7. уровнем подготовки всех людей, кто задействован
Этап 5. Определить условия использования документов (описание среды их использования)
забыл, что хотел в этом пункте писать :(
Этап 6. Определить список ограничений (проверять на соответствие ему каждый следующий этап)
все плохо :)
Генерирую иерархический список из предыдущих этапов. При этом обобщаю многое.
Этап 7. Определить имеющиеся ресурсы (любого типа)
- деньги
- образование
- нормативные документы (список)
- время
Этап 8. Определить перечень альтернативных моделей решения
- Регулятор - создает общие требования по классам и специальные требования для отдельных инфоормационных технологий (отдельными документами, например для виртуалок, облаков, терминалов и т.д.). И в тех и в тех уже содержаться перечни угроз. Для специальных систем - по запросам производителей СЗИ и лицензиатов.
- Производитель СЗИ - создают СЗИ по перечням угроз, разрабатывают типовые инструкции настройки под конкретные типовые задачи и нормальные руководства админам и пользователям для сложных систем
- Лицензиат - обучает, проектирует, ставит, настраивает, проверяет соответствие требованиям (боюсь заикнуться, что проверять должен из другого города - утопия). Проверяет соответствие по запросу (ведь в электронной БД сразу видно, что изменилось). Как вариант сертифицируется СУБД ведения документации, которая автоматом проверяет соответствие новых правил (фантастика, однако можно). Типа как сертифицировались билинговые системы у связистов.
- Администратор - собирает информацию в БД (как буд-тонаконец то создан такой продукт) или в бумагу по конечному списку и по формам, классифицирует систему, определяет список общих и спецциальных требований. Эксплуатирует систему и поддерживает документацию в актуальном состоянии.
Классификация по сути персданных:
- персданные которые выдало государство или комерсант - условно персональные (условно переменные)(паспортные, ИНН, СНИЛС, банковский счет, номер в базе, где работает, номера рабочих телефонов, должность и т.д.)
- персданные которые принадлежат человеку потому что он человек/животное (где был, здоровье, вера, мысли, биометрия и т.п.)
- персданные отнесенные к специальным категориям, кроме предыдущего (судимость, и т.д.)
- втоичные персданные (собственно что купил, что в собственности, факт нахождения в БД и т.д.)
- общедоступные персданные
- обезличенные данные (лучше бы их небыло)
Определение процентных соотношений для организаций, которым надо защищать ПДн по критериям:
1. Количество работников
1.1 количество БД с ПДн
1.3 назначение БД с ПДн
1.4 количество ПЭВМ у которых доступ к БД с ПДн
1.4.1 Распределенность
1.5 Применяемые информационные технологии
1.6 Применяемое ПО для обработки ПДн
1.7 Образование/уровень подготовки админа
1.8 уровень подготовки пользователя
1.9 Основной профиль организации
1.10 Географическое расположение
И всякие выводы. Это надо для определения Общих требований к защите - для большинства и самых нужных для самых используемых особых информационных технологий - специальных требований. Можно выборку по методу Монте-Карло (не помню как пишется) сделать из ЕГРЮЛ по городам, а для банков и операторов связи - все просто - их не много, лицензирующие органы могут запросить информацию.
Общие меры:
- многоуровневость: физический доступ, организационные мероприятия, технические средства.
- альтернативность мер и средств, в том числе принцип замены/замещения мер (типа для автономной можно ограничиться журналом вскрытия помещения, железной дверью с печатью и замком и решеткой на окнах - не ставить ЗСИ от НСД)
Требования к документам:
просто, ясно, лаконично, нетрактуемо. В общем класический канонический текст (если надо напишу требования к такому тексту)
Перевод организационно-распорядительной и оценочной документации в электронный вид. Разработка автоматических ситем управления документами и контроля/оценки вносимых изменений (американцы же сделали такие и используют).
Как говорила одна старая лошадь: "Все что шмагла". :)
Да. Забыл. На вполне резонный вопрос: "А если регулятор, несмотря на свои внутренние возможности, не сможет квалифицированно создать модель угроз для какой-то супер новой технологии, то что делать?" Отвечу: НИР, которую, например, выигрывают Микрософт и Циско. А по результатм уже регулятор обобщает результаты и выдвигает модель. Как-то так.
Для общих мер:
- структура: автономка, одноранговая сеть, домен, интернет, связь с не защищаемыми ПЭВМ
- основные каналы утечки: НСД, вирус, межсетевой экран, шифрование, контроль защищенности, обнаружение атак
- по шифрованию - выбор из КС1-КС3:
КС1:(персданные которые выдало государство или коммерсант)
КС2:(втоичные персданные)
КС3:(персданные которые принадлежат человеку потому что он человек/животное) и (персданные отнесенные к специальным категориям, кроме предыдущего)
Без шифрования: (общедоступные персданные) и (обезличенные данные)
К структуре добавка: флешки
Орг меры: двери, замки, камеры, решетки, сигнализация, ...
Матрица подмен: решетка+дверь+замок=шифрование при хранении (с особыми требованиями конечно), ...
Уровни защиты: вирус, контроль защищенности, обнаружение атак - одинаковые требования; НСД - набор механизмов как сейчас; МЭ - аналогично.
Оценка соответствия: на первом этапе - как сейчас аттестация(все равно так и будет), при появлении ПО - его настройка первоначальная лицензиатом и потом периодический контроль.
- Как бороться с пользователями :) - по аналогии с программкой "Английский для хулиганов" (вариант)
- Как бороться с админами: учить их нормально в институтах
- Как бороться с руководителями: показательными порками
- Как бороться с производителями - требования регулятор выдвигает, а им деваться некуда + создание конкуренции
- Как бороться с техподдержкой - рублем. Если заявили, что работает, а оно не работает по инструкции - плати неустойку (например, через рекламации - только не производителю а регулятору)
Интересные мысли. Но, имхо, несколько технические.
Все-таки предлагаю несколько упростить задачу:
1. Сузить круг "подозреваемых": утвердить максимально "разжеванный" Порядок для операторов, не переходящих рубеж Зарплата/Кадры.
2. Определить направления "главного удара", основные источники утечки ПДн:
- регистрационные центры (любого профиля),
- расчетные центры (любого профиля),
- клиентские (в т.ч. дисконтные) ИСПДн.
И загнать их в трехмерную матрицу категорий и уровней угроз.
Не технические, а научные!
Насчет лицензиатов:
- провести дифференциацию - кто обычные системы, а кто и ПЭМИН и со специальными может работать
- соответственно разные требования по наличию оборудования, СПО и главное специалистам
- обязательно экзамены для сотрудников лицензиата (мне давеча один лицензиат ФСБ втирал, что не надо кроме випнета ничего на комп ставить - какая нафиг мол эксплуатационная документация на СКЗИ??? Вы что (он меня спрашивает) на все свои компы с СКЗИ НСД что ли ставите???)
- единые формы документов (пока в бумаге) и главное список чего должно в итоге быть. И чтоб наизусть знали
- жесткий контроль и за косяки лишать напропалую (ввести шкалу нарушений)
- запретить лицензиатам с 10 специалистами за 2 месяца аттестовывать 50 объектов по всей стране (а потом кроме аттестата и акта установки СЗИ неизвестно куда, сделанного местными по присланному шаблону и еще протокола снятия контрольных сумм (без них самих) - ни одного документа нет! Даже дисков установочных на СЗИ не дали...)
- уже сделать какие-то "Вестники лицензиата" где выход новых документов будет освещаться, кого лицензий лишили и за что
- организовать обобщение опыта - централизованно.
Здравствуйте.
1) Если действительно есть возможность что-то предложить, то нужно предлагать правдоподобные вещи...
Метафорично говоря, это же не торги: если нам предложат сумму 500 р., а мы предложим 5 р., то нам ответят не 400 р., а просто не примут наше предложение... Надо предлагать хотя бы 300 р. ;)
Например, "виды деятельности".
В законе написано, что органы власти определяют актуальные угрозы для своих отраслей.
Если определить, что виды деятельности - это "Интернет-обработка, трансграничка, мультимедиа, мобильные устройства, облака", то какие органы власти будут определять угрозы для каждого из них? Минкомсвязь, МИД, Минкомсвязь, Минкомсвязь, Минкомсвязь? Или вместо МИД тоже Минкомсвязь? Какова вероятность того, что это примут к рассмотрению?
2) Конструктивно.
В связи с п. 1 хотелось бы добавить один маленький тезис. Мне кажется, что нужно все-таки перечислять виды экономической деятельности так, чтобы можно было привязать их к конкретному органу власти. Поэтому предлагаю исходить из перечня органов власти - их количество весьма обозримо: см. gosuslugi.ru.
Например, (могу сильно ошибаться, но хочу просто передать идею):
- Минтруда: трудовые отношения, кадровые агентства, ?
- Минфин/ЦБРФ: банковские услуги, платежные услуги, страховые услуги, фондовые рынки, ?
- Минкомсвязь: услуги связи, СМИ, почтовые услуги, ?
- Минрегион: ЖКХ - УК/ТСЖ/ЖСК, информационно-расчетные центры, ресурсоснабжающие организации
- МВД: паспортные столы, ...
- Минздрав: больницы, диспансеры, медицинские НИИ, ?
- Минобрнауки: образовательные учреждения, библиотеки, детские сады, ?
- Минспорта: ДЮСШ, ?
- Минтранс: аэропорты, ?
- ?: выборы органов власти
- ?: пенсионные фонды
- ФСБ: госуслуги, ?
- ...
Да, модель угроз на самом деле очень мало зависит от рода деятельности, ведь модель угроз всего лишь классифицирует в принципе возможные угрозы. Возможно, эти "нормативно-правовые акты, в которых определяют угрозы безопасности" будут вообще одинаковые. Но что делать, если так написано в законе, который по условиям не изменяется?
Для ZZubra:
Предложения во многом здравые, но...
С учетом того, насколько "активно" у нас все меняется, Ваше предложение в целом (части во многом здравые, но в целом...) походит на план пятилетки.
Мне кажется, что нужно выделить задачу, которая может быть реально решена сообществом специалистов по защите информации.
Все более чем реально. Понимая общую структуру можно сейчас создать то, что очень надо, а остальное по-потихонечку подтянуть.
ZZubra: неплохо, даже очень. Вот только времени и сил на это все совсем не хватит. А если такой перечень работ выкатить заказчику, то будем посланы однозначно...
Евгению Родыгину:
1 - пусть разработчик системы применяет что угодно для нейтрализации угроз... но он должен как то убедиться в том, что угрозы нейтрализованы
Угрозы невозможно нейтрализовать в принципе. Можно снизить риск их возникновения или ущерб от реализации.
Вообще, я уже говорил, что нужно сделать: нужно взять брошюру PIA и оценить степень воздействия целей, объемов данных и технологий обработки на субъекта. Это и будут угрозы: чем больше объем, чем круче технологии - тем серьезней угроза (выше риск). Вот в этом направлении и надо идти, в том числе и по видам деятельности.
Мне кажется, это утопия - взяв только ПДн постараться изменить всю систему регулирования ИБ в РФ (а предложения ввести оценку рисков, примерить опыт ISO27001 или PCI DSS это именно предложение переделать регулятора на корню). Что значит принять международный стандарт (тот же ISO27001) - это значит, что параллельно принять еще целый блок стандартов (по сертификации на соответствие ISO27001, по требованиям к аудиторам, по порядку аккредитации и т.п.).
ФСТЭК/ФСБ не смогут что-то подобное внедрить в своих подразделениях, отвечающих за проверки и формирование требований ни в какие обозримые сроки.
К тому же, если это еще будет фрагментарно - типа для защиты ПДн международные стандарты, нормальные методики оценки соответствия и т.п., то по КТ, КСИИ и, тем более, гос. тайне - все те же устаревшие уже в момент принятия средства и методы?
Мне кажется, всю невозможность революционной смены подхода к обеспечению ИБ в разрезе ПДн хорошо продемонстрировал ZZubra (хотя сам он, наверное, рассчитывал на другой результат :) ). Нельзя сказать, что в представленном им плане мероприятий есть явно лишние места, думаю, поднапрягшись там можно даже добавить. При этом хорошо видно, что если делать так основательно, то уйдут годы, если не десятилетия. Надо менять все и вся.
Поэтому я бы предлагал рассматривать более мягкие - эволюционные подходы. Чего желают все?
1. Обоснованности требований (т.е. писать не потому, что так писали последние 20 лет, а писать потому, что есть конкретная цель).
2. Реализуемости требований (аттестовать нормальную систему по Положению ... практически нереально, кроме того само положение явно требует сертификацию СрЗИ, а не оценку соответствия, что противоречит действующему законодательству).
Требования обоснованными могут быть только при наличии двусторонней ответственности - это, к сожалению, не реализовать на уровне подзаконных актов, а вот оценку реализуемости можно и нужно проводить. Ведь если была бы официальная оценка, что приведение всех ИСПДн в соответствие требованиям ЗоПДн обойдется в 7% ВВП (причем надо добавить, что не разово - это ж еще потом поддерживать), то может у какого-нибудь ВВП и появился бы вопрос - а что мы с этого получим?
А пока такая оценка фигурирует просто в записках некоего Алексея Лукацкого - она мало интересна сильным мира сего.
> А пока такая оценка фигурирует просто в записках некоего Алексея Лукацкого - она мало интересна сильным мира сего.
Вообще-то эта оценка взята из материалов парламентских слушаний http://www.aksakov.ru/media/File/filelist/st08.doc, но от этого никому не легче.
А это уже к вопросу о том, готов ли кто-то слушать хоть какие-то рекомендации со стороны...
В обсуждениях уже высказывались здравые мысли, так что не буду повторять, возможно немного позже удастся сформулировать свои идеи, а пока что:
1. В ФЗ прописаны весьма конкретные вещи: уровни защищенности (отправные точки для них), актуальные угрозы, способы и меры по их нейтрализации, так что прежде всего от них и стоит отталкиваться, а не городить большую (хоть и красивую) концепцию сверху, пытаясь вписать в неё эти вещи... это может быть и более грамотный подход, но не на таком уровне и не в таких условиях.
2. коллеги, 2700х - это, конечно, хороший стандарт, как ни крути, но даже там есть такая вещб, как зрелость, так что применять это сплошь и рядом тоже не совсем корректно - не будут те же конторы по 50 человек или в глубинке следовать процесионному подходу как бы мы ни хотели. Можно лишь некоторые общие принципы позаимствовать.
3. К оценке соответствия многие упоминали пентест. По указанным выше причинам это также не панацея и не всегда возможна, так что можно его для наиболее критичных систем рекомендовать, а в целом было бы более реально применить банальный аудит, причем, можно даже собственными силами с отчетностью в журналах ответственных лиц - проверка настроек СЗИ, проверка учеток и прав доступа и т.д. - это ведь также неотъемлемая часть любимых 2700х и PCI, так что не стоит забывать.
4. Идея про ограничения для совсем небольших организаций, обрабатывающих ПДн в рамках ТК также хороша, только стоит ограничить область деятельности - для организаций, которые спецкатегории не обрабатывают.
5. Угрозы. Как ни крутите, но большая часть угроз все равно будет соответствовать текущей типовой модели, так как там основные угрозы и перечислены. Предложенные адаптации по отраслям на мой взгляд и имхо не совсем корректны, так как основные угрозы зависят от процесса обработки и архитектуры ИСПДн (распределенность, подключение к Интернет, возможность использования съемных дисков, использование виртуализации или тонких клиентов...) В практически любой системе нужно рассматривать управление доступом, регистрацию событий, защиту на уровне сети, антивирусные средства, контроль целостности и т.д. Эти вещи настолько базовые, что их сложно в зависимости от деятельности убрать - можно лишь более детализировать для конкретных архитекрур и ИС и понятно, что на уровне подзаконников это сделать невозможно. Как вариант - описать те же самые базовые угрозы и приписать, что в рамках конкретных ИСПДн указанные угрозы могут быть детализированы и адаптированы под конкретную архитектуру, хотя это опять же передача бразд правления Операторам - надо как-то лучше обмозговать.
6. Идея с указанием организационных и технических мер для угроз хороша - пропадает неясность для Операторов в построении СЗПДн, однако при этом нужно быть осторожным чтоб не загнать Оператора в угол и рассмотреть все варианты - необходимые и достаточные. Опять же, их сложно будет прописать на уровне подзаконников, особенно если учитывать все угрозы (которые могут быть детализированы, как указал выше), да ещё и меры защиты.
7. Все снова забыли про сертифицированные СЗИ... как понимаю на нормативку, регулирующую порядок прохождения процедуры оценки, повлиять возможности нет. Тогда хотя бы для указанных наименее критичных ИСПДн (кадры, менее 100-500 человек) можно попытаться убрать требования, хотя сомневаюсь, что с текущими нормативными документами это реально. Так что по-хорошему доделать остальные варианты подтверждения соответствия.
8. Было бы неплохо детализировать остальные варианты защиты каналов связи помимо СКЗИ (оптоволокно и т.д.)
9. Идея специфицировать "классы ИСПДн" - паспорта, ОМС, ИНН, и т.д, спец категории и отстраненные (где был, что делал, образование и т.д.) хороша, но прописать полные и точные списки будет затруднительно - опять возникнут неучтенные данные и будут новые споры куда отнести... хотя попробовать стоит, но тогда без указания конкретных данных, а ввести какой-то общий критерий отнесения. Примеры были в теме.
10. Существующий вариант коэффициента защищенности бредовый и от него следует уйти. Как пример - распределенность ИСПДн влияет на актуальность угрозы загрузки со съемных носителей и т.д. Лучше создать конкретные профили ИСПДн (подключение к интернет, возможность использования съемных устройств, отсутствие сегментирвоания ИСПДн внутри ЛВС, различные права доступа к ИСПДн и т.д.) и для них указать различные варианты мер защиты.
А как основное - надо как-то систематизировать процесс сбора идей и подходов и их обсуждения, а то мы сейчас сделаем шикарную помойку, в которой что-то путное выцепить будет сложно. Может на форуме по темам прям раскидать: уровни защищенности, их составляющие, подход к определению угроз, возможности по спецификации отраслевых моделей, подход к определению мер и средств защиты и т.д.?
В предлагаемую модель отлично вписываются уже имеющиеся документы. Достаточно будет написать доктрину и план, а общие требования сказать, что делаются по имеющимся документам (тот же 58), оценка соответствия - пока по Положению по аттестации, лицензирование по имеющемуся постановлению, сертификация остается - проверяется как производитель реализовал защиту от модели угроз. Кроме того, на первое время можно вообще оставить сертификацию как есть - по готовым моделям - РД Гостехкомиссии (тем более на них и сертифицируют до сих пор).
Самое главное все будут знать куда все движется.
Плюс к тому же учитывайте, что ПДн все же даже не конфиденциалка. Все можно сделать с нуля в плане концепции. Обкатать процесс введения изменений. А потом, при необходимости, растиражировать модель на иные тайны (если надо).
Насчет угроз по видам деятельности.
Два варианта: (1) по видам деятельности и (2) по информационным технологиям.
Если бы можно было "настраивать" ФЗ152 под вид деятельности - тогда да, а иначе будет волна возмущения: и там и там паспорт, но этим можно не защищать, а этим надо по полной.
По инфотехнологиям: именно в них камень преткновения. Все спрашивают как защищать "мой Ubuntu?" или другую технологию. Почитайте форумы. Если бы все делалось по предложенному плану - это стало бы очевидным.
Поэтому не должно быть дифференциации по видам деятельности. В конце концов мы обсуждаем организационно-ТЕХНИЧЕСКУЮ статью 19. А то Вы так запретите использовать что-то допустим у туроператоров :)
2 Ronin
+100 хотелось бы подумать над оценкой сделанной уже СЗИ! Можно набрать отличных средств но не настроить их и целевая система не защищена. Что будет результатом - как оценить защищенность? Акт комиссии внутренней проверки защищенности + с привлечением 3 стороны или аттестация для особоважных систем ? Цель всего балагана как закрепить ?
2 А.Волков - ткнул меня носом в Нейтрализацию ?! (сие есть 1) ослабление, уничтожение силы, влияния.. бла бла... но можно и полное устранение угрозы)
2 Zzubra
Вы демонстрируете системный подход... что вызывает уважение, но на практике дай бог все специалисты смогут впитать, но на местах...
Пожалуй мы не сможем сформировать алгоритм для оператора, а если сможем то ляжет пылиться ибо не сможем "продать"...
На мой взгляд нужно акцентироваться на 3х задачах:
1 - установление угроз
2 - оценка защищенности после создания СЗИ
3 - организационные и технические итерации при изменении угроз
Угрозы - как фундаментальный подход (по видимому появится модель, которая будет развиваться)
В части нейтрализации угроз - набор рекомендаций и лучших практик(так же развивающийся документ)
Оценка защищенности - самый тяжелый вопрос... ибо операторы пусть проявляют творчество по используемым средствам но как оценить результат ?
Угрозы по видам деятельности - на каждый вид будем выдвигать требования по средствам и методам обработки данных?
Надо упрощать процедуры на местах. Если не могут по форме составить техпаспорт, настроить СЗИ, то когда заставляют создавать модель угроз результат будет только хуже.
2 Евгений Родыгин
Ну построим мы СЗИ и даже оценим. А дальше? Если нет процесса, то все это разболтается и расшатается. В этом отношении подход того же 27001 просто замечательный - они никакой уровень защищенности не замеряют. Они смотрят на постановку процесса - пусть даже плохой процесс защиты, но хороший процесс управления - потому что хороший процесс управления даже плохой процесс защиты потихоньку приведет к нужному уровню, но не наоборот.
Опять же непонятно почему всем так охота формулировать конкретные требования. Да если посмотреть американские FIPS'ы - то там совсем немного конкретики. Есть, правда, у DoD'а очень даже конкретные STIG'и - но они по очень узким областям, почти по каждому продукту более-менее распространенному на рынке - вряд ли у нас кто-то готов разрабатывать документы такого уровня.
А оценка системы... Как говорят про 9001 - задача не убедиться, что ваша система позволяет обойти все грабли - задача убедиться, что система позволит наступить на каждые грабли только один раз. Вот и надо оценивать функционирование системы защиты - как система реагирует на внешние раздражители (инциденты, изменения в ИТ и не ИТ инфраструктуре и т.п.) и есть ли какая-то положительная тенценция или наоборот.
Sergey.Shustikov
"Алексей, зависимость от объема - это не бред, а реальный способ спасти малый бизнес, основная деятельнось которого никак с обработкой ПДн не связана. ПДн у них только в кадровом делопроизводстве по 1 - 300 сотрудникам.
Зачем хлебопекарню, где работают 5 человек нагибать на СЗИ?"
А защищать права субъектов нужно только если их собралось больше 300 человек?
Я предлагаю вариант как рациональнее, а вы - как с помощью "костылей" обойти требования закона.
В вашей "хлебопекарне" 5 человек, а в других двух - 299 и 301 - почему они должны защищаться по-разному? а если первая на летний период дополнительно двух работников возьмёт? Защиту перестраивать?
Е.Родыгину: экий ты обидчивый. Не ткнул, а поправил.
ZZubra: идти надо от технологий. Вообще, в приказе трех был неплохой задел, вот только критериев маловато, для типовых они не использовались (там только объем), а для специальных экспертным методом получался сферический конь в вакууме.
То, что для разных видов обработки одни и те же данные будут подлежать разной степени защиты - это совершенно нормально. По закону оператор обязан соблюдать конфиденциальность всех ПДн. А вот насколько критичными эти данные будут являются в конкретном случае - тут уже зависеть только от крутизны ИС и целей ее существования (банк или копировальный аппарат).
Вот, вот, я уже писал выше, что уровни защиты _должны_ учитывать цели обработки.
Вот если бы сообщество хотя бы начало выработку критериев оценки возможного ущерба, и это было учтено в классификации, это была бы польза.
Просто для примера (к уже указанным выше).
Организация ведет базу "черного списка" сотрудников, которые провинились, по мнению организации, в том или ином виде - воровство, злостное нарушение трудовой дисциплины и т.п.
Она не хочет больше их нанимать, и вообщем-то имеет право в соответствии с новыми положениями ФЗ. В базе ФИО, паспортные данные.
Состав данных минимален, количество тоже вряди превысит 10 тыс., а вот ущерб субъектам от публикации этой базы например на job.ru будет.
Как выделить такие случаи?
Все таки акцентирую внимание на следующей фразе - "которые провинились, по мнению организации".
Не по суду, а просто по мнению некоего руководителя этой организации.
2 Евгений
Ну дак нельзя объять необъятное.
Нельзя прописать все, что можно в руководящих документах - надо дать людям возможность самим взвесить свои риски.
Пусть организация сама предполагает сколько им придется выплатить субъекту в случае утечки и решает, а стоит ли заморачиваться с защитой (может им правда проще выплатить по миллиону каждому пострадавшему, если что-то произойдет, чем выстраивать полноценную СЗПДн - это же тоже способ, в конце-концов).
Тогда ваш случай будет вполне понятным - руководство будет осознавать, что утечка черного списка им вылетит в копеечку и сами предпримут наиболее адекватные меры.
2 doom
в 3 посте указывал про процесс на эксплуатации. Можно прописать обязаловку по выполнению норм сотни ISO - но реально кто их будет выполнять? Только тот, кто и так хочет выполнять... если исходить из того, что оператор не будет делать ничего, кроме того что ему вменяют...
Процесс управления внедрять - насколько это реально и не превратится ли он в формальность...
по сути им нужно создать СЗИ, проверить что она защищает и периодически контролировать работу с учетом выявления угроз...
2 А.Волков
Конечно, ибо нейтрализация - вполне себе подходящий термин
Зачем тому же ФСТЭКу или ФСБ влезать в цели? Есть какой-то ресурс на ПЭВМ. Его надо защитить. С точки зрения защиты информации важно "что" защищать, а не "зачем тут это обрабатывают". Это "зачем" пусть Роскмнадзор проверяет. В рамках ФЗ все "зачем" уже жестко прописаны.
2 Евгений Родыгин
Но ведь согласитесь, что даже правильно настроенные СЗИ ничего не гарантируют. Вот есть у вас антивирус - хорошо настроен, но вирусы все равно будут проникать, если не анализировать, как они обошли вашу защиту и что надо подкрутить (возможно вообще организационно).
Здесь самый показательный вариант - регистрация и учет. Толку, что все регистрируется и учитывается, если потом не прописано, что с этими данными делать (и нет способа убедить, что что-то действительно делается).
Поэтому во всем мире регулятор рекомендует как правильно поставить процесс, а спрашивает не за несоответствие, а за реальный причиненный ущерб - это какую-то хоть мотивацию у бизнеса создает.
А от конкретных функциональных требований по защите тех или иных систем весь западный мир ушел уже очень давно. Вспомните, сначала была Оранжевая книга, которая считала, что все системы можно разделить на 5 классов, потом европейцы создали свой аналог, где ввели уже 2 метрики - классы с точки зрения защищенности и функционала, а потом все равно поняли, что профанация, что систем разных слишком много и появились Общие Критерии - нам бы где-то на этом уровне подхватывать, не повторять ошибок, которые все поняли уже 20-30 лет назад...
2 doom
"Поэтому во всем мире регулятор рекомендует как правильно поставить процесс, а спрашивает не за несоответствие, а за реальный причиненный ущерб - это какую-то хоть мотивацию у бизнеса создает."
Вот реальный ущерб - это у нас и не работает и продавить не получится...
Можно рекомендовать процесс и его контролировать.
Но стоит кому то заявить, что кто то будет контролировать Бизнес и их процесс (аттестация, проверки защищенности, оценка актуальности установленных угроз, эффективность орг и тех мер, подготовку персонала, реакцию на инциденты) - того тут же в ту же секунду подымут на штыках !!!
Можно продумать алгоритмы, и карать за утечки. Но так как кара за утечки смехотворна - остается контроль выполнения - тут же см. штыки...
Если же карать достойно - оператор сам рассмотрит риски и сделает как нужно...
Посему мы находимся в патовой ситуации - собралась группа экспертов в области ИБ и предложила серьезные подходы - но они эти подходы нужны не на этапе задачи, а на этапе реализации цели... Цель для оператора - выполнение обязаловки на данный момент...
После инцидента с выплатой штрафа или приостановкой деятельности - цель сформируется - и оператор возьмет в руки НМД и рекомендации...
P.S> кстати наверное нужно вспомнить про следующий принцип - оператор начинает обработку ПДн только после ввода в эксплуатацию СЗИ.
кстати наверное нужно вспомнить про следующий принцип - оператор начинает обработку ПДн только после ввода в эксплуатацию СЗИ.
нужно ли оповещать оператору регулятора о начале обработки с указанием что СЗИ создана и введена в эксплуатацию - и в какой форме и какие характеристики СЗИ указывать ?
может быть такое уведомление и будет играть роль декларации ;)
> систематизировать процесс сбора идей и подходов и их обсуждения
Мы ведь сейчас придумываем содержание подзаконников, а оно описано в законе.
Попробовал составить из положений закона небольшую схемку того, что требуется разработать в рамках нашего обсуждения.
Кругами показаны вещи, которые не определены:
- уровень защищенности;
- виды деятельности.
Предлагаю пользоваться этой схемой для оценки того, насколько адекватно то или иное конкретное предложение действующему закону.
Предлагаю следующее адекватное, на мой взгляд, предложение.
1) Уровень защищенности - это сущность, аналогичная классам СЗИ.
По некоторым угрозам уровни уже определены:
- угрозы НСД: 6, 5, 4, ...
- угрозы МЭ: 5, 4, 3, ...
- угрозы НДВ: 4, 3, ...
- угрозы крипто: КС1, КС2, КС3, ...
По другим группам угроз уровни предстоит определить:
- вирусы: ???
- утечки: ???
- угрозы при Интернет-обработке: ???
- угрозы при трансграничной передаче: ???
- угрозы облачных сервисов: ???
- ...
Можно выбрать любое другое разбиение угроз по группам, вышеприведенное - только для примера.
Правительство устанавливает эти уровни и определяет требования по защите (которые фактически сводятся к перечислению угроз, которые нужно нейтрализовать).
ФСБ/ФСТЭК определяют меры по защите, которые нейтрализуют угрозы соответствующих уровней защиты (которые фактически являются руководящими документами - РД СВТ, РД МЭ, ...)
2) Виды деятельности - это, как я предлагал выше, обобщенные виды экономической деятельности.
Отраслевые госорганы должны определить актуальные угрозы. Так как уровни защищенности - это фактически группы угроз, то органам удобно сделать это, определив актуальные уровни защищенности. Например:
- угрозы, актуальные для банка: угрозы НСД уровня 5, угрозы МЭ уровня 4, ...
- угрозы, актуальные для ломбарда: угрозы НСД уровня 6, угрозы МЭ уровня 5, ...
- ...
Отраслевые госорганы могут использовать для классификации своих предприятий какие-либо метрики "содержания персональных данных, характера и способов их обработки".
В результате НПА госорганов будут достаточно короткими и не будут дублировать друг друга.
Обращаю внимание, что в этом моем предложении нет ничего про оценку соответствия, другими словами МЭ 4 класса и МЭ, сертифицированный на соответствие 4 классу - это разные вещи.
Странно, не опубликовался последний пост... Дублирую:
> систематизировать процесс сбора идей и подходов и их обсуждения
Мы ведь сейчас придумываем содержание подзаконников, а оно описано в законе.
Попробовал составить из положений закона небольшую схемку того, что требуется разработать в рамках нашего обсуждения.
Кругами показаны вещи, которые не определены:
- уровень защищенности;
- виды деятельности.
Предлагаю пользоваться этой схемой для оценки того, насколько адекватно то или иное конкретное предложение действующему закону.
Предлагаю следующее адекватное, на мой взгляд, предложение.
1) Уровень защищенности - это сущность, аналогичная классам СЗИ.
По некоторым угрозам уровни уже определены:
- угрозы НСД: 6, 5, 4, ...
- угрозы МЭ: 5, 4, 3, ...
- угрозы НДВ: 4, 3, ...
- угрозы крипто: КС1, КС2, КС3, ...
По другим группам угроз уровни предстоит определить:
- вирусы: ???
- утечки: ???
- угрозы при Интернет-обработке: ???
- угрозы при трансграничной передаче: ???
- угрозы облачных сервисов: ???
- ...
Можно выбрать любое другое разбиение угроз по группам, вышеприведенное - только для примера.
Правительство устанавливает эти уровни и определяет требования по защите (которые фактически сводятся к перечислению угроз, которые нужно нейтрализовать).
ФСБ/ФСТЭК определяют меры по защите, которые нейтрализуют угрозы соответствующих уровней защиты (которые фактически являются руководящими документами - РД СВТ, РД МЭ, ...)
2) Виды деятельности - это, как я предлагал выше, обобщенные виды экономической деятельности.
Отраслевые госорганы должны определить актуальные угрозы. Так как уровни защищенности - это фактически группы угроз, то органам удобно сделать это, определив актуальные уровни защищенности. Например:
- угрозы, актуальные для банка: угрозы НСД уровня 5, угрозы МЭ уровня 4, ...
- угрозы, актуальные для ломбарда: угрозы НСД уровня 6, угрозы МЭ уровня 5, ...
- ...
Отраслевые госорганы могут использовать для классификации своих предприятий критерии "содержания персональных данных, характера и способов их обработки".
В результате НПА госорганов будут достаточно короткими и не будут дублировать друг друга.
Обращаю внимание, что в этом моем предложении нет ничего про оценку соответствия, другими словами МЭ 4 класса и МЭ, сертифицированный на соответствие 4 классу - это разные вещи.
Странно, но блог съедает некоторые комментарии :(
или лимит на комментарии, или глюк с их исчезновением. попробую еще раз:
2 doom, ZZubra:
информация о целях обработки ПДн в базе ничем не отличается от того, как если бы эта информация была прописана в каждой записи о субъекте в БД отдельно.
2 Евгений: имхо, решается по варианту, который предложил чуть выше (ссылкой на блог для экономии места), в чуть измененном виде - путем определения, что если данные "цель обработки ПДн" попаают в перечень данных, относящихся к ПДн, то необходимо считать, что эти данные определены для любого субъекта, включенного в базу, независимо от того, прописано ли это для него в самой базе явно или нет. Но для этого нужно провести рабоу по правильному и корректному составлению перечня данных, являющихся ПДн.
2 doom:
Вы забываете исходные условия задачи, заданные Алексеем - не трогаем ФЗ, предлагаем подзаконные акты - и хотите добавить в КоАП, УК положения о штрафах, которые не пройдут (иначе бы Роскомнадзор уже давно реализовал свою задумку об увеличении штрафов).
Первейшие же подзаконные акты не ФСТЭК'овские и ФСБ'шные, а Постановления Правительства и потом приказ тройки об уровнях (классах) защищенности.
Всем здравствовать.
Р1
Идея градации требований по виду деятельности – лихая, но дохлая: ни формула, ни мегаклассификатор невозможны.
Реально только штучное поименование нескольких деятельностей, являющихся исключением из правила в ту и другую сторону («обработка ПДн субъектов при оказании им медицинских услуг - плюс один уровень от расчетного», «обработка ПДн субъектов при оказании им услуг связи - минус один уровень от расчетного» и т.п.).
Поэтому предлагаю даже и времени не терять – сами этот наносписок счастливчиков напишут и никого кроме лоббистов не спросят.
Сюда же попадут и некоторые госы с муниципалами, кто бы сомневался.
Р2
Названия уровней должны быть такими, чтобы обычному индивиду вплоть до субъекта было понятно расположение в иерархии.
Типа «А/Б/В/Г», «очень плохой/плохой/так себе/хороший/очень хороший», «высокий/средний/низкий», «красный/оранжевый/желтый/…/фиолетовый в крапинку».
Р3
С градацией по ущербам ситуация забавная: для этого нужно менять объект, на котором оцениваются угрозы - перейти от угроз для КДЦ ПДн к угрозам для жизни, здоровья, собственности, репутации субъекта (т.е. опять-таки от ЗИ к ИБ).
Я, честно говоря, не верю, что нашим регуляторам это можно как-то просунуть – не та публика, зря силы потратим.
Какой можно придумать обходной маневр (оценка рисков, не основанная на оценке рисков?), пока что-то не соображу.
Р4
Сложность реализации должна возрастать вместе с уровнями.
Нижний («базовый») уровень магазин дамской бижутерии должен строить сам по бумажке, в которой все расписано. Следующий уровень - приходящий безопасник, следующий – штатный, верхний – специализированная фирма.
Надеюсь продолжить.
Ригелю: ты забыл что сначала нужно оценить угрозы, а только потом - уровни, и уж затем - требования. Так вот угрозы эти должны быть не в отношении данных (КЦД) а в отношении субъекта, включая оценку вреда ему в случае их реализации. Если этого сделано не будет - мы вернемся к четверокнижию и все, что ты написал, можно не делать в принципе.
"Так вот угрозы эти должны быть не в отношении данных (КЦД) а в отношении субъекта, включая оценку вреда ему в случае их реализации. Если этого сделано не будет"
- это сделано не будет! Оценка вреда субъекту проблема субъекта, оценка ущерба оператору - незначительная ;)
Е.Р.: именно поэтому, как я и говорил в отношении 152-ФЗ, так могу сказать и в отношении подзаконников: знаю, что не будет, но верю, что будет.
Алексею Лукацкому: ИМХО посыл неверен: 152-ФЗ нам уже не изменить, а вот подзаконники... Впрочем, см. выше :(
Опять мой коммент пропал :-(
Не уж то предложений больше ни у кого нет? Или все в отпусках?
Нужна более другая площадка для публикации и фиксации предложений, с возможностью комментариев к каждому из них, и человек, который будет их структурировать, обобщать и в итоге представлять.
Без этого тут просто разминка для ума "если бы у рыбы были крылья...."
Мне нравится идея, что при классификации системы необходимо в перечень ПДн добавлять цель обработки. Тогда примеры с наркоманами, алкоголиками, венерологами ) и т.п. попадают в медицинскую характеристику.
Кроме того, в качестве одного из критериев оценки ущерба (угроз) субъекту можно рассмотреть возможное ограничение субъекта в правах без решения суда в результате утечки/публикации ПДн(пример со списком уволенных сотрудников, обнародование которого приводит к ограничениям человека в праве на трудоустройство).
Тогда у меня есть "новость": госконтракт http://zakupki.gov.ru/pgz/public/action/orders/info/order_lot_list_info/show?notificationId=1237032
Лоты 4 и 10.
По 4 лоту: надо сделать документы по документам ФСБ и ФСТЭК, которых еще нет.
По 10 лоту: надо сделать документы по ПЕРВОЙ редакции ЗАКОНОПРОЕКТА Резника!!!! (вот это они тормозят)
Трудоемкость по 4 лоту 50 человеко/месяцев. Время на всю работу 30 дней.
Трудоемкость по 10 лоту 56 человеко/месяцев. Время на всю работу 50 дней.
И кто-то хочет сказать, что это честный конкурс?
Собственно и названия:
4: Разработка типовых требований по обеспечению информационной безопасности персональных данных при их обработке в информационных системах электронного правительства
10:Исследование проблем гармонизации нормативной правовой базы Российской Федерации в сфере персональных данных в связи с принятием Государственной Думой в первом чтении проекта федерального закона № 282499-5 «О внесении изменений в Федеральный закон «О персональных данных» и подготовка необходимых изменений в законодательные акты Российской Федерации
Алексею Волкову:
> ты забыл что сначала нужно оценить
> угрозы, а только потом - уровни, и
> уж затем - требования
А фигули на рогуле! Часть 3 статьи 19 тут нужно читать, а в ней последовательность такая: вред --> объем --> содержание --> деятельность --> угрозы ПДн --> уровни. Затем действительно требования.
А сосулю нехохули ;-) Почему из перечисления через запятую ты сделал вывод, что одно должно вытекать из другого?..
Отечественная бумажная культура за очередностью перечисления обычно подразумевает очередность выполнения, так в традиции.
Вы оба правы, рАвно как и я, ибо все написанное, включая угрозы, должно исходить из вреда субъекту, так как это первоочередное, и я об этом всегда говорю, в т.ч. и в комментируемом комментарии, где слова вырезаны из контекста.
Сейчас пришла в голову мысль:
можно не описывать варианты защиты вообще, а вместо этого описать варианты атак, которые должна выдерживать система. То есть: остается классификация системы персданных по критерию имеющихся данных и их количества (хорошо бы на основе среднеожидаемого ущерба для субъекта), описываются возможные технические средства, на которых содержатся или которыми обрабатываются эти данные в системе, но для каждого из уровней описываются не варианты защит этих объектов, а варианты атак, которые они должны выдерживать.
Варианты защиты при этом тоже нужны, но уже только в качестве "шпаргалки", примеров - как это реализовать, если не хватает своих знаний.
Правда, не очень верю, что такого рода документ имеет шанс появиться в нашей реальности, но вдруг.
"описываются возможные технические средства"
- этого конечно делать нельзя...
Еще один путь: обязать всех построить защиту какого-то определенного уровня, а остальное решает организация. При этом, требования по классам для НСД, антивируса, МЭ, и т.д. - одинаковые (какие-то минимально необходимые).
А вообще через персональные данные можно сейчас решить вопросы "перехода" на электронные услуги. Все равно требования пересекаются: описание и перечни услуг (аналог юридического паспорта), описание автоматизированной системы (аналог техпаспорта), описание порядка обработки/предоставления услуги (регламент/описание технологического процесса обработки), перечни допущенных к обработке информации (аналог матриц доступа), ну и так далее - все это сделать обязательным при обработке ПДн/проверке регуляторов.
При этом получаем перечень конкретных действий и документов в организации (его уменьшение) и упрощение процедур организации защиты информации.
"описываются возможные технические средства"
- этого конечно делать нельзя...
- имел в виду, обобщенно. Требования для МЭ, для веб-сервера, для сервера БД, для рабочей станции, для канала связи.. в зависимости от критичности данных на выбраном ресурсе - варианты нарушителя и доступные ему виды атак, которые ресурс должен выдерживать не хуже, чем с определенной вероятностью и определенными последствиями.
Бонус подхода - возможность большей объективности проверки, если проверяющий смог реализовать атаку - то проверка не пройдена, не смог - пройдена, минимум субъективизма и одовременно простор для творчества. Скажем, утверждает регулятор, что сертифицированные решения лучше - в добрый путь, описывает соответствующую атаку и демонстрирует, наглядно и доступно просрамляя вражеские СЗИ ;) .
Но боюсь, что корректно описать такой подход формальным образом будет непросто.
Ну вот пример РД СВТ - прописано что объектом доступа могут быть информационные объекты и появляются проблемы сертификации систем управления - где объектами доступа являются функции и разграничение доступа осуществляется именно к функциям.
Опасно упоминать конкретные технологии и названия - при их разборе можно упереться в терминологию руководящих документов, которая потянет за собой избыточность реализации или требований по отношению к конкретной системе.
Отправить комментарий