Ключ к сердцу "безопасника"

Информационная безопасность(далее ИБ) начинается с чтения законодательства и заканчивается выбором сетевого кабеля, не являюсь экспертом ни в одной из этих областей, но могу сказать о том, что зачастую соприкосновения data people и ИБ довольно болезненная тема. 

Во-первых,главный принцип безопасности “используйте необходимый минимум в работе ”,а ключевая задача DWH наоборот “сохранить все, что только можно сохранить”(и использовать потом). Т.е. data people изначально находятся  на радаре. 

Во-вторых, вопреки бесконечным тренингам по кибербезопасности не всем очевидна именно их роль и зона ответственности. Например, менеджерами data продуктов чаще всего становится люди из аналитики, разработки, бизнеса и фокус на безопасность(если это жестко не контролируется) наводится уже после появления определенных проблем. 

 

Поговорим о том, как data people могут занять проактивную позицию и наиболее эффективно наладить взаимодействие. 

 

Публикация будет состоять из 3х блоков: 

1. Источники формирования требований ИБ и почему иногда они могут быть избыточными? 
2. Разбор популярных вопросов ИБ, к тем у кого есть доступ к данным
3. Как найти ключ к сердцу безопасника?(кратко)

Источники формирования требований ИБ и почему иногда они могут быть избыточными? 

В основе любого консенсуса, лежит желание понять позицию оппонента, поэтому предлагаю начать с источников требований.  При поиске разъяснений мне понравилась классификация предложенная dama book, так как она отражает не только ограничивающие, но и “разрешающие” потребности. Итак, 4 блока: 

1. Нормативно правовое регулирование (например, формы строгость по срокам предоставления определенных данных)
2. Законные интересы бизнеса (например, kpi руководства или патентную документацию)
3. Интересы сторон ( например, в россии это несколько федеральных законов в том числе:  N 152-ФЗ О персональных данных , 323-ФЗ (ред. от 26.03.2022) "Об основах охраны здоровья граждан в Российской Федерации")
4. Необходимые потребности бизнеса в доступе к данным

Изучив картинку, становится понятным, что гипотеза, что ИБ просто придумывают правила - не верна, а задача формирование политики ИБ не тривиальна. 

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

 

Приведу пример зафиксированных в законодательстве требований. В законе о защите персональных данных  N 152-ФЗ  в статье 5. "Принципы обработки персональных данных" можно найти такие строки: 

 

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

При определенной интерпретации и излишней тревожности и безграничной власти сотрудников ИБ, прочитав N 152-ФЗ,  можно в целом поставить крест на аналитике использующей в своей основе персональные данные, которые все еще являются бизнес ключами и той самой изюминкой любого dwh. Конечно, в действительно, не все так страшно, потому что, например, за недавний масштабный грубый слив данных Яндекс еды наказание составило всего  60000 тыс рублей.

 

Откуда берётся избыточность в требованиях?

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

 

Суть этой части статьи в том, что нужно проникнутся к “безопасникам” глубоким уважением.

 

Разбор популярных вопросов ИБ, к тем у кого есть доступ к данным

 

Что за данные лежат на этой флешке(условно, в пересылаемом письме) и зачем вы выносите эти данные за пределы компании?  

 

Ответ - не нужно ничего выносить, если вы предварительно не согласовали это действие с руководством с определенной целью. Это действительно, полностью ваша ответственность. 

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

 

Если вам очень очень нужно - задумайтесь над процессом обезличивания.  Однажды в пятницу около 8 вечера,  разговаривая с малознакомым дядей на три должности выше меня из отдела с очень безопасным названием я усвоила для себя классный урок - нормально выносить и  те данные, в которых по самому датаесту, если вдруг его зальют в сеть невозможно определить : “какой организации принадлежат данные и о ком они?”. Такое вот простое правило, для которого даже не требуется читать таблицу с категориями информации. Посмотрите отстраненно и задайте этот вопрос. 

 

Т.е, как минимум уберите идентификаторы(всегда для локальных задач можно заменить на промежуточные sequence) и не забудьте поменять название самого файла, особенно если изначально оно было “зарплаты руководства”.

 

Зачем вы используете персональные идентификаторы и/или другую чувствительную информацию? (вообще и/или при разработке дата-продукта)

 

Начать стоит с того, что минимизировать объем таких данных. 

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

 

Для тех данных, что останутся: 

• Нарисуйте модель данных это позволит намного проще и объяснить, и самим понять почему вам критичны именно эти атрибуты.
• В некоторых БД есть большие преимущества по базовым возможностям разграничения прав доступа, стоит изучить этот вопрос отдельно. Где-то можно создать view, и навязать на них умные ролевые модели,  а где то в движок БД вшита даже построковая фильтрация результата - используйте это по максимуму, просто пряча чувствительные данные на нижние уровни. Ну а если у вас hadoop.. то подходите к вопросу более творчески;) Например, если у вас есть информация о заболеваниях клиента, детальная с диагнозом - это критично, вы можете вынести в доступную “для широкого круга пользователей” некий недискредитирующий флаг “требует особого отношения”, а в скрытой таблице витрины оставить мед тайну. 
• Проверьте в документации/и/или политиках/законодательстве сами, что данные могут использовать для тех целей, для которых вы хотите - это например, должно быть в политике конфиденциальности или договорах с клиентом. Подготовьте почву для общения, но не торопитесь выкладывать ее пока не спросят.
• Привлеките бизнес заказчиков, которые объяснят экономический эффект от использования данных, а иногда может и будут готовы взять на себя некоторые риски. 
• Опасный совет, но считаю его правильным. Зафиксируйте договоренности с бизнес владельцем данных, тем самым продемонстрировав сотрудникам ИБ свою этичность (по хорошему они должны согласовывать распространение производных данных, но это уже data governance).Под бизнес владельцем я понимаю, того кто формирует ценность данных на входе в ваш продукт(например, собирает и создает клиентскую базу),также он часто является ключевым потерпевшим в случае утечки информации. 

Откуда на этой среде данные?

 

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

 

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

 

Пожалуй, остальные вопросы, которые приходят в голову уже лежат в плоскости проектирования архитектуры решения или относятся к data opsу.

Например, у кого будет пароль на обновление и изменение кода? Какие методы шифрования данных применяются? как устроена аутентификация?каким образом организована доставка кода на промышленную среду?есть ли бэкапирование, куда делают бэкап? как организован доступ к данным? каким образом устроено логирование пользователей? 

Кроме этого требования периодически меняются, и естественно лучше стараться решать вопросы “малой кровью” и просто обыграть ту архитектуру, что есть. 

У нас был такой случай, когда представителю ИБ категорически не нравился приемник наших данных с формулировкой как раз про отсутствие логирования, но каким то сказочным путем его удовлетворило как sas клиент логирует  пользовательские обращения к готовому дата продукту.(т е нас спас не наш, а конечный пользователь). 

 

Как найти ключ к сердцу безопасника в вашем случае?

1. Понимайте, когда за вами придут(шутка). Осознайте какие принимаемые именно вами или вашей командой решения влияют на ИБ. Обращайте на это внимание в работе. 
2. Общайтесь с ИБ на этапе проектирования решения. Совет не нов, ибо в waterfall все так и делали. В общем, на этапе проектирования или создания первых прототипов, найдите конкретного специалиста ИБ, у которого потребуется получать согласование,  обсудите ожидания и подводные камни. Даже если вы придете к каким то непреодолимым сложностям, то не придется начинать сначала, да и просто человеческие отношения уже будут налажены. Если у вас в организации есть официальный процесс - отлично, если нет - создайте его на своем уровне. 
3. Делайте описания доступными, с картинками. Всегда помните - ИБ проще запретить, особенно запретить, то что непонятно. Поэтому в ваших интересах максимально просто и с правильным фокусом подготовить материалы. Далеко не каждый ( в силу скиллов, свободного времени, личных причин) сотрудник ИБ готов выполнять роль не только полицейского, но и конструктора/инженера/проектировщика безопасного решения.
4. Медитируйте. Безопасность выполняет свою работу. Это то что как мантру про себя повторяла на сложных многочасовых встречах. Так и задумано, они проверяют, как охранники на концерте. Помните, возможно именно они помогут найти вам сумочку, если вас ограбят. Будьте доброжелательны и спокойны, но и конструктивно не давайте себя в обиду. 

 

успехов нам всем, друзья, в это непростое время, когда под угрозой не только информационная безопасность,  ILOVEDATA