2 марта, вторник 14:20
Bankir.Ru

Объявление

Свернуть
Пока нет объявлений.

Подзаконные акты к новой редакции ФЗ-152 "О персональных данных"

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • Подзаконные акты к новой редакции ФЗ-152 "О персональных данных"

    Создание этой темы навеяно постом в блоге Алексея Лукацкого.
    Посыл у Алексея правильный и верный, но блог, как место для изложения идей все же не лучшее место. Лично мне довольно сложно воспринимать развернутые предложения читателей блога из комментариев. Поэтому ниже я постарался изложить наиболее интересные предложения, прежде всего для упорядочивания собственных мыслей.
    Начну собственно с посыла Алексея Лукацкого:
    Сообщение от Алексей Лукацкий Посмотреть сообщение
    Представьте, что вам дана уникальная возможность при действующей редакции ФЗ-152 все-таки поучаствовать в разработке подзаконных актов (не меняя текста ФЗ-152). Т.е. как-то выкрутиться в ворохе "уровней защищенности", "требований по безопасности", "актуальных угроз", "видов деятельности" и других понятий нового старого ФЗ-152. Как бы вы выстроили стратегию и иерархию разработки подзаконных актов?

    Понятно, что начинать надо с базовой модели угроз. C ней более менее все понятно. Чтобы не создавать вторую "базовую" модель от ФСТЭК я бы в новую модель включил бы стандартный минимум - вирусы, НСД, утечки и т.п. А уж расширять ее можно было бы на уровне отраслевых и "союзных" моделей.

    Что дальше? Вид и объем персданных брать из приказа трех или новую градацию использовать? Зачем и почему?

    С видами деятельности основная засада - их слишком много, если ориентироваться на всякие классификаторы ОКВЭД и т.п. Поэтому надо исходить из каких-то других критериев. Каких? Если в расчет брать виды не экономической деятельности оператора, а деятельности, связанной с обработкой ПДн, то по сути у нас их и не так много - Интернет-обработка, трансграничка, мультимедиа, мобильные устройства, облака. Все эти виды обработки/использования/передачи ПДн специфичны с точки зрения способов защиты и можно их описать в подзаконниках.

    Затем я бы против угроз для каждого вида деятельности сделал бы две колонки - организационные и технические меры защиты. При этом зафиксировал бы, что организационным отдается приоритет (за основу взял бы ISO 29100/29101).

    Ну и уже потом покумекал бы над требованиями к оценке соответствия. То, что она нужна в том или ином виде, понятно. Но и гнуть всех под обязательную сертификацию тоже неверно.

    Дополнительно все это стоило бы еще поделить на два направления - для госорганов/муниципалов и коммерческих структур.

    Вот как-то так! Есть иные мысли, предложения, замечания, комментарии?..

    ЗЫ. Флеймить на тему бесполезности этой работы не стоит. Не верите в результат, лучше просто понаблюдайте за дискуссией. Есть конкретика - предлагайте, буду только благодарен. И помните, что под лежачий камень вода не течет ;-)
    Евгений Родыгин:
    Сообщение от Евгений Родыгин
    На мой взгляд самый важный момент - добиться адекватной борьбы с угрозами. Для чего необходимо сформировать подходы по формированию и оценке угроз.
    Затем, нужно проработать два момента:
    1 - пусть разработчик системы применяет что угодно для нейтрализации угроз... но он должен как то убедиться в том, что угрозы нейтрализованы
    2 - разработчик системы должен контролировать процесс выявления угроз и их нейтрализации в процессе эксплуатации

    Вопрос не в том, сертифицированные средства или нет - вопрос - целевая система выполняет функции ?
    Андрей Бурдаев:
    Сообщение от Андрей Бурдаев
    Попробовали по линии ОНФ http://komiexpo.com/news/508/

    Несколько, так скажем, в упрощенном виде
    Sergey.Shustikov:
    Сообщение от Sergey.Shustikov
    Что касается классификации ПДн, считаю, что нужно конкретно, без размытостей, двусмысленностей, общих понятий и прочих "и т. д." для каждого уровня (категории ПДн) создать перечень видов ПДн, относимых к каждой категории. Это нужно, чтобы исправить ситуацию с чрезчур общим определением ПДн и исключить в будущем споры типа: "мы считаем, что это ПДн, потому что (определение ПДн)" - "нет, это не ПДн, потому что (определение ПДн).

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

    Вместо сертификации-аттестации в идеале - тест на проникновение при вводе в эксплуатацию, а также ежегодно и при внесении значительных изменений. Что такое значительное изменение - опять же нужно четко определить. При обнаружении уязвимостей, через которые возможно нарушение кофиденцальности ПДн, следует устранить уязвимости и выполнить повторный тест на проникновение, для подтверждения того, что уязвимости устранены. На мой взгляд, это хорошя норма из PCI DSS, которую можно перенять.
    GORS:
    Сообщение от GORS
    Наиболее системный на сегодня вариант методики всё-таки изложен в 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). А в строках - исходные данные по ИСПДн: одно-много пользовательская, с подключением к СМИО или без, распределенная и т.д. Это надо вместе думать. А главное - весовые коэффициенты, которые вносят эти исходные данные для соответствующего количества субъектов. Итоговый уровень защищенности - сумма коэффициентов по столбцу.
    Алексей:
    Сообщение от Алексей
    А я против выбора СЗИ в зависимости от объёма... как вспомнишь этот бред когда люди тычутся чтобы уменьшить число от 1012 до 997, аж противно становится. По уму - штраф оператора должен увеличиваться пропорционально числу субъектов (это его мотивирует), а законодательством уровень защиты определяется в зависимости от типа ПДн.

    ПДн я бы разделил на (можно из них вывести "уровни защищённости):
    1. "Ликвидные" ПДн - это те, что легко конвертируются в выгоду злоумышленника - копия паспорта, номера кредиток (то, что по уму и должно защищаться в первую очередь) - это обычно материальный ущерб субъекту.
    2. Специальные ПДн - это те, что из закона - подразумевается что их раскрытие наносит моральный ущерб субъекту (определение из закона).
    3. Общая категория - всё, что осталось, и что вообще вряд ли субъектам принесёт заметный ущерб (номер телефона, адрес, образование, опыт работы и проч.)
    4. Обезличенные и общедоступные (отсутствие мер или минимум мер по целостности).

    Соответственно у 1 уровня максимальная защита, у 3 - минимальная, у 4 - по решению оператора.

    Это будет мотивировать оператора обезличивать данные, и разделять сегменты ИС по ущербу субъекту.

    Биометрические ПДн - фигню типа 512 ПП РФ желательно вообще выкинуть, ибо такие ущербные требования к биометрическим носителям только будут заставлять операторов прятать или обходить биометрию, но не защищать. По уму, наверно, биометрические данные надо хранить в неизвлекаемом виде (необратимое шифрование) - но это сулит ещё большие проблемы с ФСБ... Поэтому здесь затрудняюсь.
    al:
    Сообщение от al
    Данная заметка была написана как ответ на сообщение Алексея Лукацкого "Вы готовы изменить если не мир, то хотя бы ФЗ-152?! " от 5 августа 2011 года.

    Все ниженаписанное является исключительно моим ИМХО по данному вопросу, написано несколько сумбурно и не исключаю, что в чем-то может быть противоречиво. В этом тексте пытался изложить примерно то, что сам хотел бы увидеть касательно данного вопроса.
    ==========================================

    Исходные данные, от которых, на мой взгляд, нужно отталкиваться, представляют собой два утверждения:

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

    Отсюда следует вывод:

    Классификация в общем случае не должна зависеть от того, кто именно обрабатывает данные. Она должна зависеть исключительно от состава и, возможно, от количества обрабатываемых данных.

    Если банк зачем-то хочет обрабатывать информацию о венерических болезнях клиента, то утечка от него будет не менее чувствительна, чем утечка от соответствующей клиники. Номер кредитной карты, обрабатываемый в торговой точке, ничем не отличается от того-же номера, обрабатываемого крупным банком, или частной клиникой. Кстати, в PCI DSS, вроде бы, как раз применяется похожий подход к проблеме.
    Такой подход позволяет уйти от малопродуктивной попытки описать все бизнес-процессы, которые существуют в природе (а если завтра появится новый тип бизнеса - новые документы писать?), и сконцентрироваться на исходной задаче - защитить связанные с персональной информацией права субъекта, разумным и достаточным образом.

    При этом нужно учесть момент, озвученный в комментарии Евгения к исходному сообщению, а именно - "косвенные" персональные данные, связанные с самим местом обработки. Сам факт наличия персональных данных в какой-то БД также является персональной информацией.
    Данный вопрос может быть решен путем создания определенных исчерпывающих перечней организаций, с указанием, что вне зависимости от состава обрабатываемых в них персональных данных считается, что базы данных каждой организации из такого пределенного перечня также содержат информацию определенного характера независимо от того, имеется ли она в них в явном виде, или нет. То есть, для классификации и определения мер защиты БД учреждений ГУИН следует считать, что их базы включают в себя информацию о судимости, для диспансеров и частных клиник - соответствующию информацию о здоровье и т.п.

    Для целей классификации, необходимо решить 3 вопроса:

    в1. Определить полный, исчерпывающий перечень сведений, которые являются персональными данными.
    в2. Установить для каждой позиции из данного перечня численным коэффициентом потенциальный ущерб субъекту от нарушения каждой из характеристик безопасности персональных данных отдельно.
    в3. Установить для каждой позиции из данного перечня численным коэффициентом возможную выгоду для злоумышленника (нарушителя безопасности) - также, для каждой характеристики безопасности.

    Исходя из этих данных, можно определить значение риска для субъекта по каждой позиции перечня в1.

    При этом возникает вопрос, связанный с кумулятивным эффектом: многие сведения по отдельности не позволяют надежно идентифицировать субъекта, однако позволяют это сделать, будучи собранными воедино. С другой стороны, для некоторых сведений из этого списка нарушение характеристик безопасности само по себе может не нести ущерба субъекту. Таким образом, перечень в1. следует разбить на 2 части:
    вч1. Комбинации персональных данных, позволяющих идентифицировать субъекта
    вч2. Отдельные сведения, нарушение характеристик безопасности которых можнет нанести ущерб субъекту (в него могут входить не все данные из списка вч1.).

    При этом "группы" вч1. имеет смысл разделить на подкатегории: позволяют достоверно идентифицировать, позволяют идентифицировать с малой степенью достоверности.
    Те данные, которые позволяют идендифицировать субъекта с низкой степенью достоверности, не считать персональными данными. Для тех наборов данных, которые позволяют идентифицировать с малой степенью достоверности, применять поправочный уменьшающий коэффициент при рассчете угрозы субъекту персональных данных.
    При этом считать, что данные из списка вч2. являются персональными только в том случае, если они связаны с набором данных из списка вч1. (т.е. входят в состав данных, включающий в себя подмножество из вч1.).

    Тогда характеристики в2. и в3. (потенциальный ущерб и потенциальная выгода) нужно определить только для данных из списка вч2., при этом рассматривая только случай, когда субъект, к которому относятся эти данные, достоверно установлен, что снимает некоторую часть неопределенности при такой оценке.

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

    Таким образом, у нас появляется весовой коэффициент критичности для "атомарной" записи в БД (возможно, "атомарность" стоит как-то определить отдельно).

    При оценке "количества персональных данных" нужно учитывать только те данные, нарушение характеристик безопасности которых возможно одновременно. Т.е. если реализация какой-то угрозы приводит к потенциальному нарушению безопасности тысячи записей, при общей емкости базы в десять тысяч, то такая угроза очевидно более существенна, чем та, реализация которой приводит к нарушению характеристики всего одной записи, даже если в БД их миллион. Это решает вопрос БД, разделенных на части, с одной стороны снимая необходимость плодить искуственные ИСПДн, а с другой не позволяя искуственным же образом фиктивно занижать угрозу. При этом саму количественную оценку имеет смысл сделать логарифмической, с достаточно большим уровнем дискретности для умножающего коэффициента, чтобы не имело смысла "подгонять" его в пограничных случаях.

    Таким образом, умножая "атомарный вес" одной записи на логарифмический коэффициент, получаем коэффициент критичности для данной части ИСПДн.


    По мерам защиты - возвращаясь к началу, можно также отметить, что способы защиты информации от определенной угрозы для характеристик безопасности данной информации в общем случае не зависят от собственно значения данной информации, а зависят только от (физических) характеристик ее носителя. Информация, размещенная на веб-сервере в DMZ, уязвима одинаково независимо от того, информация ли это о химическом оружии, список банковских счетов или таблица умножения.

    Таким образом, для определения мер защиты необходимо знать 2 характеристики:

    х1. Размещение информации
    х2. Критичность информации.

    При этом х2. - это как раз тот коэффициент критичности ИСПДн, который мы определили выше, а x1. - способы размещения и обработки информации. Для каждого из них теперь можно описать набор комплексов организационно-технических мер, в зависимости от разных значений характеристики критичности информации x2.

    Возможно, при этом целесообразным будет раздельное определение необходимых мер защиты для каждой из характеристик безопасности персональных данных.


    Бонус описанного подхода, на мой взгляд, в том, что он:

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

  • #2
    ZZubra:
    Сообщение от ZZubra
    Сначала мои замечания к моим предложениям: они могут быть не стандартными своим подходом (но не оригинальными). Сразу не отвергайте. Надо помусолить. Отложить. Еще раз посмотреть. Откусить А потом уже выплевывать и морщиться. Можно ругаясь плохими словами. Всем кто найдет в себе силы так проделать - спасибо.

    Теперь предложения.

    Общие предложения 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персданные которые принадлежат человеку потому что он человек/животное) и (персданные отнесенные к специальным категориям, кроме предыдущего)
    Без шифрования: (общедоступные персданные) и (обезличенные данные)

    К структуре добавка: флешки

    Орг меры: двери, замки, камеры, решетки, сигнализация, ...
    Матрица подмен: решетка+дверь+замок=шифрование при хранении (с особыми требованиями конечно), ...

    Уровни защиты: вирус, контроль защищенности, обнаружение атак - одинаковые требования; НСД - набор механизмов как сейчас; МЭ - аналогично.

    Оценка соответствия: на первом этапе - как сейчас аттестация(все равно так и будет), при появлении ПО - его настройка первоначальная лицензиатом и потом периодический контроль.

    - Как бороться с пользователями - по аналогии с программкой "Английский для хулиганов" (вариант)
    - Как бороться с админами: учить их нормально в институтах
    - Как бороться с руководителями: показательными порками
    - Как бороться с производителями - требования регулятор выдвигает, а им деваться некуда + создание конкуренции
    - Как бороться с техподдержкой - рублем. Если заявили, что работает, а оно не работает по инструкции - плати неустойку (например, через рекламации - только не производителю а регулятору)

    Насчет лицензиатов:
    - провести дифференциацию - кто обычные системы, а кто и ПЭМИН и со специальными может работать
    - соответственно разные требования по наличию оборудования, СПО и главное специалистам
    - обязательно экзамены для сотрудников лицензиата (мне давеча один лицензиат ФСБ втирал, что не надо кроме випнета ничего на комп ставить - какая нафиг мол эксплуатационная документация на СКЗИ??? Вы что (он меня спрашивает) на все свои компы с СКЗИ НСД что ли ставите???)
    - единые формы документов (пока в бумаге) и главное список чего должно в итоге быть. И чтоб наизусть знали
    - жесткий контроль и за косяки лишать напропалую (ввести шкалу нарушений)
    - запретить лицензиатам с 10 специалистами за 2 месяца аттестовывать 50 объектов по всей стране (а потом кроме аттестата и акта установки СЗИ неизвестно куда, сделанного местными по присланному шаблону и еще протокола снятия контрольных сумм (без них самих) - ни одного документа нет! Даже дисков установочных на СЗИ не дали...)
    - уже сделать какие-то "Вестники лицензиата" где выход новых документов будет освещаться, кого лицензий лишили и за что
    - организовать обобщение опыта - централизованно.

    Комментарий


    • #3
      t5d:
      Сообщение от t5d
      1) Если действительно есть возможность что-то предложить, то нужно предлагать правдоподобные вещи...
      Метафорично говоря, это же не торги: если нам предложат сумму 500 р., а мы предложим 5 р., то нам ответят не 400 р., а просто не примут наше предложение... Надо предлагать хотя бы 300 р.

      Например, "виды деятельности".
      В законе написано, что органы власти определяют актуальные угрозы для своих отраслей.
      Если определить, что виды деятельности - это "Интернет-обработка, трансграничка, мультимедиа, мобильные устройства, облака", то какие органы власти будут определять угрозы для каждого из них? Минкомсвязь, МИД, Минкомсвязь, Минкомсвязь, Минкомсвязь? Или вместо МИД тоже Минкомсвязь? Какова вероятность того, что это примут к рассмотрению?

      2) Конструктивно.
      В связи с п. 1 хотелось бы добавить один маленький тезис. Мне кажется, что нужно все-таки перечислять виды экономической деятельности так, чтобы можно было привязать их к конкретному органу власти. Поэтому предлагаю исходить из перечня органов власти - их количество весьма обозримо: см. gosuslugi.ru.
      Например, (могу сильно ошибаться, но хочу просто передать идею):
      - Минтруда: трудовые отношения, кадровые агентства, ?
      - Минфин/ЦБРФ: банковские услуги, платежные услуги, страховые услуги, фондовые рынки, ?
      - Минкомсвязь: услуги связи, СМИ, почтовые услуги, ?
      - Минрегион: ЖКХ - УК/ТСЖ/ЖСК, информационно-расчетные центры, ресурсоснабжающие организации
      - МВД: паспортные столы, ...
      - Минздрав: больницы, диспансеры, медицинские НИИ, ?
      - Минобрнауки: образовательные учреждения, библиотеки, детские сады, ?
      - Минспорта: ДЮСШ, ?
      - Минтранс: аэропорты, ?
      - ?: выборы органов власти
      - ?: пенсионные фонды
      - ФСБ: госуслуги, ?
      - ...

      Да, модель угроз на самом деле очень мало зависит от рода деятельности, ведь модель угроз всего лишь классифицирует в принципе возможные угрозы. Возможно, эти "нормативно-правовые акты, в которых определяют угрозы безопасности" будут вообще одинаковые. Но что делать, если так написано в законе, который по условиям не изменяется?
      doom:
      Сообщение от doom
      Мне кажется, это утопия - взяв только ПДн постараться изменить всю систему регулирования ИБ в РФ (а предложения ввести оценку рисков, примерить опыт ISO27001 или PCI DSS это именно предложение переделать регулятора на корню). Что значит принять международный стандарт (тот же ISO27001) - это значит, что параллельно принять еще целый блок стандартов (по сертификации на соответствие ISO27001, по требованиям к аудиторам, по порядку аккредитации и т.п.).
      ФСТЭК/ФСБ не смогут что-то подобное внедрить в своих подразделениях, отвечающих за проверки и формирование требований ни в какие обозримые сроки.

      К тому же, если это еще будет фрагментарно - типа для защиты ПДн международные стандарты, нормальные методики оценки соответствия и т.п., то по КТ, КСИИ и, тем более, гос. тайне - все те же устаревшие уже в момент принятия средства и методы?

      Мне кажется, всю невозможность революционной смены подхода к обеспечению ИБ в разрезе ПДн хорошо продемонстрировал ZZubra (хотя сам он, наверное, рассчитывал на другой результат ). Нельзя сказать, что в представленном им плане мероприятий есть явно лишние места, думаю, поднапрягшись там можно даже добавить. При этом хорошо видно, что если делать так основательно, то уйдут годы, если не десятилетия. Надо менять все и вся.

      Поэтому я бы предлагал рассматривать более мягкие - эволюционные подходы. Чего желают все?

      1. Обоснованности требований (т.е. писать не потому, что так писали последние 20 лет, а писать потому, что есть конкретная цель).
      2. Реализуемости требований (аттестовать нормальную систему по Положению ... практически нереально, кроме того само положение явно требует сертификацию СрЗИ, а не оценку соответствия, что противоречит действующему законодательству).

      Требования обоснованными могут быть только при наличии двусторонней ответственности - это, к сожалению, не реализовать на уровне подзаконных актов, а вот оценку реализуемости можно и нужно проводить. Ведь если была бы официальная оценка, что приведение всех ИСПДн в соответствие требованиям ЗоПДн обойдется в 7% ВВП (причем надо добавить, что не разово - это ж еще потом поддерживать), то может у какого-нибудь ВВП и появился бы вопрос - а что мы с этого получим?

      А пока такая оценка фигурирует просто в записках некоего Алексея Лукацкого - она мало интересна сильным мира сего.
      Ronin:
      Сообщение от Ronin
      В обсуждениях уже высказывались здравые мысли, так что не буду повторять, возможно немного позже удастся сформулировать свои идеи, а пока что:
      1. В ФЗ прописаны весьма конкретные вещи: уровни защищенности (отправные точки для них), актуальные угрозы, способы и меры по их нейтрализации, так что прежде всего от них и стоит отталкиваться, а не городить большую (хоть и красивую) концепцию сверху, пытаясь вписать в неё эти вещи... это может быть и более грамотный подход, но не на таком уровне и не в таких условиях.
      2. коллеги, 2700х - это, конечно, хороший стандарт, как ни крути, но даже там есть такая вещб, как зрелость, так что применять это сплошь и рядом тоже не совсем корректно - не будут те же конторы по 50 человек или в глубинке следовать процесионному подходу как бы мы ни хотели. Можно лишь некоторые общие принципы позаимствовать.
      3. К оценке соответствия многие упоминали пентест. По указанным выше причинам это также не панацея и не всегда возможна, так что можно его для наиболее критичных систем рекомендовать, а в целом было бы более реально применить банальный аудит, причем, можно даже собственными силами с отчетностью в журналах ответственных лиц - проверка настроек СЗИ, проверка учеток и прав доступа и т.д. - это ведь также неотъемлемая часть любимых 2700х и PCI, так что не стоит забывать.
      4. Идея про ограничения для совсем небольших организаций, обрабатывающих ПДн в рамках ТК также хороша, только стоит ограничить область деятельности - для организаций, которые спецкатегории не обрабатывают.
      5. Угрозы. Как ни крутите, но большая часть угроз все равно будет соответствовать текущей типовой модели, так как там основные угрозы и перечислены. Предложенные адаптации по отраслям на мой взгляд и имхо не совсем корректны, так как основные угрозы зависят от процесса обработки и архитектуры ИСПДн (распределенность, подключение к Интернет, возможность использования съемных дисков, использование виртуализации или тонких клиентов...) В практически любой системе нужно рассматривать управление доступом, регистрацию событий, защиту на уровне сети, антивирусные средства, контроль целостности и т.д. Эти вещи настолько базовые, что их сложно в зависимости от деятельности убрать - можно лишь более детализировать для конкретных архитекрур и ИС и понятно, что на уровне подзаконников это сделать невозможно. Как вариант - описать те же самые базовые угрозы и приписать, что в рамках конкретных ИСПДн указанные угрозы могут быть детализированы и адаптированы под конкретную архитектуру, хотя это опять же передача бразд правления Операторам - надо как-то лучше обмозговать.

      6. Идея с указанием организационных и технических мер для угроз хороша - пропадает неясность для Операторов в построении СЗПДн, однако при этом нужно быть осторожным чтоб не загнать Оператора в угол и рассмотреть все варианты - необходимые и достаточные. Опять же, их сложно будет прописать на уровне подзаконников, особенно если учитывать все угрозы (которые могут быть детализированы, как указал выше), да ещё и меры защиты.
      7. Все снова забыли про сертифицированные СЗИ... как понимаю на нормативку, регулирующую порядок прохождения процедуры оценки, повлиять возможности нет. Тогда хотя бы для указанных наименее критичных ИСПДн (кадры, менее 100-500 человек) можно попытаться убрать требования, хотя сомневаюсь, что с текущими нормативными документами это реально. Так что по-хорошему доделать остальные варианты подтверждения соответствия.
      8. Было бы неплохо детализировать остальные варианты защиты каналов связи помимо СКЗИ (оптоволокно и т.д.)
      9. Идея специфицировать "классы ИСПДн" - паспорта, ОМС, ИНН, и т.д, спец категории и отстраненные (где был, что делал, образование и т.д.) хороша, но прописать полные и точные списки будет затруднительно - опять возникнут неучтенные данные и будут новые споры куда отнести... хотя попробовать стоит, но тогда без указания конкретных данных, а ввести какой-то общий критерий отнесения. Примеры были в теме.
      10. Существующий вариант коэффициента защищенности бредовый и от него следует уйти. Как пример - распределенность ИСПДн влияет на актуальность угрозы загрузки со съемных носителей и т.д. Лучше создать конкретные профили ИСПДн (подключение к интернет, возможность использования съемных устройств, отсутствие сегментирвоания ИСПДн внутри ЛВС, различные права доступа к ИСПДн и т.д.) и для них указать различные варианты мер защиты.

      А как основное - надо как-то систематизировать процесс сбора идей и подходов и их обсуждения, а то мы сейчас сделаем шикарную помойку, в которой что-то путное выцепить будет сложно. Может на форуме по темам прям раскидать: уровни защищенности, их составляющие, подход к определению угроз, возможности по спецификации отраслевых моделей, подход к определению мер и средств защиты и т.д.?

      Комментарий


      • #4
        Супер! Спасибо, что свел все тут ;-)

        Комментарий


        • #5
          Uomo,
          Клёво подобрал.
          Кстати, впервые прочитал чёткие и логически правильные мысли:
          Алексей:

          Сообщение от Алексей
          А я против выбора СЗИ в зависимости от объёма... как вспомнишь этот бред когда люди тычутся чтобы уменьшить число от 1012 до 997, аж противно становится. По уму - штраф оператора должен увеличиваться пропорционально числу субъектов (это его мотивирует), а законодательством уровень защиты определяется в зависимости от типа ПДн.

          ПДн я бы разделил на (можно из них вывести "уровни защищённости):
          1. "Ликвидные" ПДн - это те, что легко конвертируются в выгоду злоумышленника - копия паспорта, номера кредиток (то, что по уму и должно защищаться в первую очередь) - это обычно материальный ущерб субъекту.
          2. Специальные ПДн - это те, что из закона - подразумевается что их раскрытие наносит моральный ущерб субъекту (определение из закона).
          3. Общая категория - всё, что осталось, и что вообще вряд ли субъектам принесёт заметный ущерб (номер телефона, адрес, образование, опыт работы и проч.)
          4. Обезличенные и общедоступные (отсутствие мер или минимум мер по целостности).
          Соответственно у 1 уровня максимальная защита, у 3 - минимальная, у 4 - по решению оператора.

          Это будет мотивировать оператора обезличивать данные, и разделять сегменты ИС по ущербу субъекту.

          Биометрические ПДн - фигню типа 512 ПП РФ желательно вообще выкинуть, ибо такие ущербные требования к биометрическим носителям только будут заставлять операторов прятать или обходить биометрию, но не защищать. По уму, наверно, биометрические данные надо хранить в неизвлекаемом виде (необратимое шифрование) - но это сулит ещё большие проблемы с ФСБ... Поэтому здесь затрудняюсь.
          Полностью согласен. Вчера у меня 999 записей - всё ОК, защита ПД работает.
          Сегодня 1001- всё ёк-макарёк, срочно докупать СЗИ!
          Дебилизм.

          Комментарий


          • #6
            Сообщение от surfer Посмотреть сообщение
            Uomo,
            Клёво подобрал.
            Кстати, впервые прочитал чёткие и логически правильные мысли:


            Полностью согласен. Вчера у меня 999 записей - всё ОК, защита ПД работает.
            Сегодня 1001- всё ёк-макарёк, срочно докупать СЗИ!
            Дебилизм.
            А кто мешает сделать как и раньше специальную систему и класс через последствия, а не объем делать согласно приказа трех?

            Комментарий


            • #7
              Сообщение от surfer Посмотреть сообщение
              Вчера у меня 999 записей - всё ОК, защита ПД работает.
              Сегодня 1001- всё ёк-макарёк, срочно докупать СЗИ!
              мне кажется, не стоит воспринимать такие вещи буквально. В районе тысячи - пишем тысячу, в районе 20 тысяч - пишем 20. Кто там считать будет при проверке, речь ведь о порядке идет? или я не прав, считают?

              А если нам укажут вилку, которая входит и в ту и в ту категорию, тоже ведь недовольны будем, непонятно куда относить?

              Комментарий

              Обработка...
              X