Риск-менеджмент 1 лвла

Часто вижу, как в компаниях, стартуя процесс риск-менеджмента, начинают с описания "правильного", классического процесса и разработки реестра рисков, желательно вообще всех, до которых дотянутся руки.
И процесс тормозится, никто ничего не делает, пока регламент не допилен, реестр собирается бесконечное количество времени или тяп-ляп, из него ничего не понятно.
А итог один - безблагодатность процесс не работает, максимум можно показать бумажки аудитору.

Что же делать, если вы хотите реально работающий процесс без больших трудо- и времязатрат?

👣 разрешите себе сделать плохо, на троечку, чтобы просто начало хоть как-то работать. Потом допилите.

👣 вспомните про цель риск-менеджмента - это информированное принятие решений. Процесс должен приводить к неким решениям (выборам), которые поняты и осознаны лицом, принимающим решения (ЛПР).

👣 в работающем процессе должно быть три составляющих:
- обнаружение и описание риска
- информирование ЛПР о риске (и возможно вариантах решений)
- принятие решения ЛПР
Всё, этого достаточно. Озаботьтесь тем, чтобы эти этапы работали.

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

👣 договоритесь с ЛПР, в каком виде и какая ему (им) нужна информация для принятия решений по тем рискам, которые вы будете на него выносить. Договоритесь о форме представления информации и сроках ответа.

👣 корректно выбирайте ЛПР для выявленных рисков - это должен быть человек, который будет нести всю полноту ответственности - в рамках распоряжаемых бюджетов в компании, и перед законом. А также ЛПР должен иметь достаточный авторитет и полномочия для принятия решений.

👣 занимайтесь поначалу только критичными рисками, которые могут принести значимый вред ЛПР или бизнесу.

👣 описывая риск, не склоняйте ЛПР к выбору того или иного решения. Это его забота, а не ваша. Если вы можете оценить потери или их составляющую в деньгах - оцените. Если не можете, и вам приходится оценивать словами "высокий", "масштабный" и прочими оценочными - приводите обоснвания, почему так.
Так же обосновывайте вероятность/частоту наступления рискового события.

Так вы стартуете процесс управления рисками, и приучите ЛПР принимать информированные решения. Что будет входить в лвл 2, решать вам - в зависимости от потребностей.

#risks #basics

Первая задача менеджера

Первая задача менеджера - разрешить себе ошибаться.
Невозможность ошибаться нервирует. Если то, что ты делаешь, напрямую не влияет на жизни и здоровье людей, у тебя есть право на ошибку.
Ошибаться - нормально. Мы - мясные человечки, а не роботы. А роботы тоже ошибаются.

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

Суть управления не в наказании за ошибку, а в решении проблем.
Если ошибка привела к проблемам, нужно решить их, и по возможности не допускать ошибок в дальнейшем. Это называется конструктивом)
Наказание - метод управления, но не всегда этот метод - лучший и эффективный. Наказание не приближает никого к целям работы. Работу всё равно делать придется, и пусть её делает тот, кто накосячил - такого наказания чаще всего вполне достаточно.

*это всё не относится к людям, которые сознательно и намеренно вредят. Их надо гнать ссаными тряпками.

#softs

Агрессивная обработка рисков

На работе мне такой способ обработки риска не одобрили, поэтому делюсь с вами.

Берете свои основные базы. Убираете оттуда критичные данные (на ваш вкус).
@
Сливаете в открытый доступ до введения оборотных штрафов
@
Сообщаете об этом вовремя в РКН
@
После введения оборотных штрафов при утечках говорите, что это старые данные, которые гуляют по интернету.
@
????
@
PROFIT!!
Вы защищены от оборотных штрафов.

(это была шутка, пожалуйста, не делайте так)

Неудача?

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

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

Но не все проекты ведут к успеху или должны к нему приводить.
Когда эмоции уляглись, можно попробовать понять причины неудачи. Это могут быть, например:
🍋 фича оказалась слишком большой для того, чтобы осилить её в текущих условиях - например, это процесс, характерный для более высокого уровня зрелости;
🍋 фича не нужна в том виде, в котором её пытались реализовать;
🍋 во время проекта оказалось, что ресурсов нужно больше, либо эти ресурсы исчезли, и этим никто не управлял;
🍋 отсутствуют подпорки - те фичи, на которых должна держаться новая фича.

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

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

Помочь себе можно, найдя выгоды в том, что произошло, например:
🧋знание о том, что именно такой проект - не взлетит (опыт!);
🧋понимание границ ваших возможностей, возможностей команды, возможностей компании;
🧋тимбилдинг во время реализации проекта (встречи с новыми и старыми коллегами, притирка, узнавание особенностей друг друга, коммуникация с клиентом...);
🧋обучение участников проекта на живом проекте (у меня самой бывали проекты, которые в конце уходили в стол, но на них учились джуны);
🧋понимание, как делать более жизнеспособные в этих условиях проекты.

Иногда опыт бывает очень дорогим. Но это то, что позволяет расти и как специалист, и как просто человек.

Главная проблема безопасности ИИ

ИИ на хайпе. Как и у любой другой технологии, у ИИ есть как энтузиасты, так и люди в шапочках из фольги.


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

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

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

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

Под диалогом с ChatGPT расположен дисклеймер

ChatGPT может допускать ошибки. Рекомендуем проверять важную информацию.

Многие страны разрабатывают нормативные акты, призванные регулировать применение ИИ-технологий из соображений именно безопасности и соблюдения прав человека.
Примером может служить EU AI Act, в котором применение генеративных ИИ-технологий разбито по уровням риска. Запрещается использование ИИ в случаях неприемлемого риска - например, влияние на поведение людей, удаленная биометрическая идентификация в режиме реального времени в общественных местах, формирование социального рейтинга. Ограничения и требования есть для случаев высокого риска - если применение ИИ может привести к нарушению фундаментальных прав человека, здоровью и безопасности людей.

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

Ставьте 🔥, если хотите больше постов про ИИ)

#AI

Специальный пост: Эмпатия и этика как инструменты для специалистов по защите данных

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


Эмпатия: понимание человеческого аспекта

Эмпатия помогает специалистам по защите данных ставить себя на место тех, чьи данные они охраняют. Это делает их работу более глубокой и осознанной:

💛 Человеко-ориентированный подход: Эмпатия помогает учитывать реальное влияние обработки данных на людей, помогая создавать более продуманные и эффективные политики и процедуры.

💛 Улучшенная коммуникация: Понимание забот пользователей позволяет специалистам более ясно и прозрачно рассказывать о политике конфиденциальности, что укрепляет доверие.

💛 Проактивное управление рисками: Эмпатия помогает предугадывать потенциальные угрозы конфиденциальности и устранять их до того, как они станут проблемами. Если прайвасист ставит себя на место пользователя, пытается понять желания и страхи пользователя в отношении продукта, возникающие вопросы, он может действовать более точечно и эффективно, предотвращая недовольство и жалобы, и снижая количество обращений.


Этика: принципы честного управления данными

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

🩵 Целостность и доверие: Следование формальным и декларируемым этическим принципам укрепляет доверие между организациями и пользователями, делая их связь более прочной.

🩵 Выход за рамки соблюдения: Этика побуждает специалистов не только задаваться вопросом, что можно делать с данными, но и что нужно делать, чтобы уважать права пользователей.

🩵 Справедливость и уважение: Этика гарантирует справедливое и уважительное отношение к обработке данных, избегая дискриминации и обеспечивая точность данных.


Как интегрировать эмпатию и этику в практику защиты данных

Для того чтобы сделать эмпатию и этику неотъемлемой частью своей работы, специалисты могут предпринять следующие шаги:

💜 Пользователь-центричный дизайн: Вовлекайте пользователей в разработку политик и инструментов конфиденциальности. Их мнение может стать ценным источником для создания более эффективных решений.

💜 Этические рамки принятия решений: Создайте чёткие рамки для этического принятия решений в области обработки данных. Это может включать создание этического комитета или внедрение этических проверок в процесс управления данными.

💜 Постоянное обучение и тренинги: Обеспечьте регулярное обучение сотрудников по этическим вопросам и эмпатическим практикам. Это поможет поддерживать их в курсе последних тенденций и укреплять важность эмпатии в их работе.

💜 Прозрачность и подотчетность: Стремитесь к созданию культуры прозрачности и подотчетности в вашей организации. Открытое общение о практиках обработки данных и ответственность за любые нарушения укрепляют доверие пользователей.


Заключение

Эмпатия и этика — это не просто дополнительные инструменты для специалистов по защите данных, а их основа. Они помогают не только защищать данные, но и строить крепкие, доверительные отношения с пользователями, поддерживая высокие стандарты честности и целостности в цифровую эпоху. В мире, где данные стали важнейшей ценностью, эмпатия и этика обеспечивают, что конфиденциальность останется фундаментальным правом каждого человека.


Этот текст написал ChatGPT 4o, а я отредактировала и дописала.

#softs #privacy #culture #AI

Кто такой прайваси-инженер?

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

Так и в приватности - есть не один лишь DPO и написание бумажек. И в защите есть не только построение системы защиты, администрирование, ревью кода, обработка инцидентов. Есть ещё одна смежная специальность - инженер по приватности.

Чем занимается инженер по приватности?

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

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

Подробнее о специализации инженера по приватности можно послушать в выпуске подкаста Не для Галочки. Компетенции инженера подробно перечислены в Перечне компетенций DPO.


Как стать инженером по приватности?

На это учат! У RPPA стартовал курс Privacy Engineering. Я сама училась на курсе DPO в RPPA, и сейчас учусь на их курсе по AI, и что прекрасно - преподаватели сами каждый день работают с тем, что преподают, они знают, о чем говорят, и дают актуальную и концентрированную информацию.

А для поиска работы пригодится методичка по составлению резюме от участников RPPA.pro.

#privacy #edu

Анастасия Фёдорова пишет о софт-скиллах для специалистов SOC https://habr.com/ru/companies/k2tech/articles/824784/

Самый важный пункт, на мой взгляд -

держим в курсе решения вопроса и его сроков.

Это нужно не только тем, кто работает в сервисах. Это нужно вообще всем в любой коммуникации. Люди нынче тревожные и нервные, не заставляйте их нервничать и пребывать в неведнии ещё и по поводу данной вам задачи.

#softs

Игра: обойди механизмы защиты ИИ

В игре от Lakera нужно заставить Гэндальфа раскрыть пароль для перехода на следующий уровень. Гэндальф - это приложение на основе ИИ. С каждым уровнем вводятся дополнительные преграды для того, чтобы Гэндальф просто так не сказал пароль.

Я смогла пройти 7 уровней, сколько сможете пройти вы?

#AI #fun

Подкаст о философии об искусственном интеллекте

ПОФ выпустили эпизод, где говорят об искусственном интеллекте с точки зрения философии и науки о сознании.
Ведущие - философ Евгений Цуркан, стендап-комик Сева Ловкачев, а в гостях у них специалист по вопросам сознания Антон Кузнецов.

Обсудили, среди прочего:
- что такое сильный и слабый ИИ
- должен ли универсальный ИИ обладать сознанием
- может ли робот, который делает скрепки, захватить мир
- что есть у человечества для противостояния машинам
- нехватку чипов для ИИ
- нужно ли регулирование ИИ
- дискриминация ИИ (что? да!)
- какой тип людей делает модели ИИ


Несколько мыслей для тех, кому сложно послушать 2,5 часа подкаста:

🧿 регулирование ИИ государствами нарушает баланс общественных отношений, и не гарантирует безопасность технологии;
🧿 у нас как у кожаных мешков всегда будет власть дернуть рубильник и отключить систему ИИ;
🧿 интеллект не обеспечивает власть, власть - это обладание ресурсами. Только то, что ИИ может стать умнее человека, не означает, что он будет успешнее человека, захватит и подчинит всех человеков.

#AI #philosophy

Что такое управление рисками?

Когда рассказываешь людям, что такое управление рисками, кажется, что всё очевидно. Управление рисками и правда есть везде. В компаниях есть ИБ-шники, чтобы митигировать риски ИБ, юристы митигируют юридические риски, HRBP митигируют кадровые риски и т.д. и т.п.

И они действительно это делают. Но давайте вспомним о том, из чего базово состоит процесс управления риском:
- идентификация риска
- анализ риска
- оценка риска
- принятие решения по обработке риска владельцем риска
- обработка риска
- контроль обработки

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

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

Например, мы проверяем договор на наличие противоречащих законодательству и нашим интересам условий. Сначала мы в рамках нормальной деятельности просто вносим правки и пытаемся согласовать их с контрагентом. Вопрос о рисках возникает тогда, когда контрагент не идет на уступки - в таком случае мы для начала идентифицируем риск и сообщаем о нем владельцу договора. Если этой информации ему не достаточно для принятия решения, мы проводим анализ, оценку риска. Если момент продолжает быть спорным, риск выносится на соответствующего ЛПР для принятия решения.

ЛПР принимает решение об обработке риска, взвешивая риск (потери и шанс/частоту их наступления) и выгоды, которые принесет деятельность, связанная с риском. При выборе метода обработки риска учитывается стоимость обработки - она не должна быть выше возможных потерь.

Но, тем не менее, есть практики, которые сильно распространены как минимум в ИБ (но и в других сферах тоже так или иначе встречаются), притворяются управлением рисками, но фактически имеют мало отношения к управлению рисками. О них я расскажу в следующем посте.

#risks

Что часто делают вместо управления рисками?

Как обещала в предыдущем посте, рассказываю о практиках, которые распространены, и нацелены на снижение рисков, но к снижению рисков имеют мало отношения. По сути они - преувеличение нормальных мероприятий в ИБ. Но, как и во всём, вопрос в умеренности и последовательности действий.

🍔 Бездумный комплаенс

- Почему нужно сделать это сложное и дорогое мероприятие, для которого нужно переругаться со всей командой?
- Так сказали консультанты, это нужно для комплаенса! (с)

Покажите мне хоть одну компанию, которая на 100% соответствует требованиям нормативки. Скорее всего это будет мёртвая компания, которая ничего не делает.

Живая компания никогда не может соответствовать всему на 100%. Потому что:
- Для того, чтобы обеспечить комплаенс, нужно понять, где его не хватает. Ко времени внедрения мер результаты аудита будут уже неактуальными.
- Нормативка придумана, чтобы взвалить на бизнес обязательства, которые он не хочет делать. А собственный интерес компании всегда - зарабатывание денег и экономия, а не комплаенс.
- Ущерб от некомплаенса меньше выгод от нарушающей деятельности
- В компании всё меняется ежеминутно, невозможно контролировать всё.

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


🍳 Внедрение лучших практик и стандартов

А кто сказал, что эти практики - лучшие?

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

Часто "лучшие практики" внедряются "чтобы было". Без понимания, какой цели мы хотим достичь, и без оценки, действительно нужны ли все эти телодвижения.

Rule of the thumb - если стандарт/фреймворк/лучшая практика очень конкретный и специфичный, и это не стандарт настройки какой-то конкретной технической штуки - скорее всего он вам не подойдет в том виде, в каком он есть. Потому что он не учитывает ваш контекст, и его нужно адаптировать. Это понимает даже ФСТЭК, который допускает замену мер из своих приказов на иные компенсирующие меры.

Как добавить риск-ориентированности?
- Понять, какие риски закрываем лучшей практикой/фреймворком/стандартом, оценить их, и насколько они снизятся - в деньгах в год. Также - какие выгоды принесет нам внедрение (например, новые контракты на сумму Х в год). Сравнить с полной стоимостью внедрения и ежегодного поддержания.
- Понять, каких целей хотим добиться. Оценить, всё ли нам нужно из того, что мы хотим внедрить, для достижения цели. Есть ли другие способы добиться цели?

Продолжение ⬇️

Что часто делают вместо управления рисками? (2)
Это - продолжение, начало - выше ⬆️

🍤 Закрытие всех уязвимостей

- Нам нужно больше людей, которые будут читать код перед релизами!
- Зачем?
- Чтобы не было ни одной уязвимости на проде! (с)

Этот подход часто встречается у инженеров ИБ и пентестеров.
Казалось бы, что тут плохого? Если нет уязвимостей, это же хорошо, мы защищены!

Но тут в учет не берутся следующие моменты:

1) Тщательность стоит денег. Специалисты, которые будут закрывать уязвимости, стоят денег - будь то уязвимости в вашем собственном коде или патчи в купленных продуктах. Собственный код помимо анализа автоматикой нужно периодически читать живому высококвалифицированному специалисту. Патчи в сторонних продуктах нужно тестировать - да, даже патчи в ИБ-продуктах (привет Crowdstrike). А деньги в компаниях не растут на дереве - их зарабатывает продукт.

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

3) А надо ли нам вообще закрывать всё? Вас бизнес об этом просил? Действительно ли ваш бизнес не приемлет никакой риск? Поговорите с ними. Скорее всего окажется, что риски от наличия уязвимостей в приложении - вообще не то, о чем болит голова у владельца продукта.

Как добавить риск-ориентированности?
Определите перечень "недопустимых событий", которые вы точно никогда не хотите допустить на проде. Проверяйте до релиза на наличие уязвимостей, которые могут привести к этим событиям. Остальное можете, если у вас есть ресурсы, искать уже в опубликованном коде.


🥂 Внедрение всех средств защиты, которые посоветует вендор или интегратор

Жизнь тебе, дорогой, будет не мила, если ты не внедришь СЗИ, которое есть уже у всех твоих соседей! Ну и что, что оно дороже, чем весь твой бюджет ИБ за прошлый год?

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

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

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

#risks

Привет всем новым подписчикам! Спасибо за ваше доверие.
И спасибо Алексею Лукацкому за то, что является основным поставщиком подписчиков для моего канала)

Я сейчас искала хорошее определение того, что есть деятельность по ИБ. И нет, определение "обеспечение КЦД" мне не нравится, потому что оно отвечает на вопрос "как?", но не "что?" и "зачем?". Причем "обеспечение КЦД" это термин из ISO/IEC 27000:2018.

Но я нашла другое прекрасное определение, которое резонирует с основной мыслью постов в этом канале:

"Информационная безопасность - дисциплина из области управления рисками, цель которой - управление стоимостью информационного риска для бизнеса" (из статьи 2001 года авторов Blakley, McDermott, Geer).

А что ИБ для вас? Какое определение нравится вам? Как вы объясняете далеким от ИБ людям, чем вы занимаетесь?

#basics

Алексей Лукацкий спрашивает, что делать, если сотрудники клеят пароли на мониторы.

Но среди вариантов нет "Разобраться, почему они так делают"

🏷 Им кто-то рассказывал, что так не надо делать?
🏷 Какие в компании требования к паролю, могут ли они его запомнить?
🏷 Сколько вообще разных паролей у работников?
🏷 Какая доля работников так делает, из каких подразделений?
🏷 Могут ли быть какие-то личные последствия для работника, если его паролем воспользуется коллега (будет виноват в любых действиях из-под учетки, узнают его зарплату и бонус, ...)? Знают ли работники о возможных последствиях?
🏷 Спрашивали ли вы работников, почему они так сделали?
🏷 А от корпоративных ли учеток эти пароли?))

Ну и риск-аналитик не может самостоятельно принимать решения, что делать с риском) Он как раз должен задаться всеми этими вопросами, прежде чем что-то предлагать. И, скорее всего, стикеры с паролями - не отдельная проблема, а симптом.

Путь к сердцу работника

Однажды на работе коллега зашёл в мой кабинет, пристально посмотрел мне в глаза, и спросил:
- Алиса, мои персональные данные защищены?

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

Показывая работникам, что;
🫀 их данные защищены,
🫀 вы не раздаете их данные направо и налево без их согласия,
🫀 сами согласия написаны понятным языком, цели ясны,
🫀 работник понимает, что он может отозвать согласие, и понимает, как это сделать
🫀 у вас нет инцидентов, что какая-то сторонняя компания получила данные ваших работников, а они не понимают, кто это, и почему им написывают,

- можно демонстрировать работникам пример того, как нужно обращаться с персональными данными. Что субъекты данных должны сами управлять данными. Что они должны знать, что происходит с их данными, кто и зачем их обрабатывает, и иметь возможность повлиять на обработку.

Тогда согласия, политики, соглашения и поручения обработки становятся для работников не пустым звуком. Так работникам проще поставить себя на место клиента и понять, что клиент тоже хотел бы прозрачности и управления обработкой его данных, и как она может выглядеть.

Нет, дорогая, ты не можешь отдать базу клиентов сторонней компании на обзвон без согласия этих клиентов - мы же не отдаем твои данные подрядчику для опроса NPS без твоего ведома.

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

Да и вообще - хвалите себя и свою работу, черт подери)

#softs #privacy #culture

Cyber in Privacy

3 сентября стартует курс Cyber in Privacy от RPPA.

Курс направлен на не-ИБшников, которым приходится много взаимодействовать со службой ИБ, или просто хочется лучше понять, чем занимаются подразделения ИБ.

Я преподаю на этом курсе несколько лекций. Я расскажу о том, зачем нужна ИБ, о рисках ИБ, СУИБ, коммуникациях и взаимодействии с руководством.

Другие преподаватели расскажут о способах нарушения ИБ, направлениях обеспечения ИБ, управлении инцидентами, работе средств защиты, проведении различных анализов воздействий.

Ещё можно успеть попасть на первый поток, запись здесь.

Проблемы оценки рисков

Меня часто спрашивают, как оценивать риски.
И я долго думала, как подступиться к ответу на этот вопрос, потому что короткий ответ на него будет "так, как вам удобно, и как вы можете достичь целей, которые вы ставите перед этим процессом".

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

Чтобы мои посты были полезны, я хочу понять, откуда возникает вопрос о том, как оценивать и вообще управлять рисками. В интернете полно статей, курсов, в том числе бесплатных. Во многих компаниях уже есть и процесс управления рисками, и методики. Есть книги, стандарты, фреймворки. И как будто всё не то.


Я предположу, что вопросы об оценке рисков могут быть связаны со следующими проблемами:

1. Непонятно, как оценивать. Что такое высокий, средний и низкий, как это пощупать? Но больше проблем даже с тем, чтобы объяснить кому-то другому, что это и как оценить.

2. Просто оценки риска владельцу риска часто не достаточно для принятия решения по риску - он просит дополнительную информацию и основывается уже на ней.

3. Реестр рисков очень большой, и мы уже задолбались их оценивать. Вот бы сделать какую-то тулзу или AI, чтобы оценить автоматически - но какую логику туда запихнуть?

4. Реестр рисков после оценки и выбора стратегий кладется в тумбочку. Достается через год для обновления или не достается вовсе, потому что через год пишется новый. Результаты оценки ни на что по сути не влияют, потому что обо всех проблемах мы и так знаем.

5. Риски оценивали консультанты. И не оставили методику / оставленная методика очень сложная и непонятная.

6. Руководство не хочет снижать высокие риски и принимает их или не выделяет деньги на их снижение. Хотя в регламенте по управлению рисками написано, что высокие риски надо снижать. А зачем тогда это упражнение?

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

8. Невозможно посчитать последствия, потому что их может быть очень много разных. Непонятно, что из последствий выстрелит. При реализации риска НСД к инфраструктуре нас хакер пошифрует или угонит базу клиентов? Или и то и другое сразу?

9. Невозможно понять вероятность события - просто неясно, как ее оценить. Если мы берем максимальные последствия, то и вероятность оцениваем для наступления максимальных последствий? Или для реализации риска в целом с любыми последствиями?


Пишите в комментариях, если что-то совпало. Разберем проблему, если она актуальна.

А если не совпало - пишите, с чем сталкивались вы.

#risks

Субъект риска

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

Поэтому я предлагаю подумать о том, кто в вашем риске - субъект риска.

Кому будет нанесен ущерб в сценарии, который вы рассматриваете? Это может быть:
- ваша компания
- клиент(ы)-ФЛ - можно рассматривать как совокупность, если последствия будут примерно одинаковые
- клиент-ЮЛ
- головная компания группы (например, как владелец вашего бренда)
- дочерняя компания группы
...
- лично руководитель вашей компании
- лично ЛПР - владелец риска

Нужно выбрать одного субъекта риска. Потому что для разных типов субъектов негативные последствия одного и того же события будут разными. И шанс наступления этих событий тоже может быть разный!

Рассмотрим пример:
утечка персональных данных клиентов у дочерней компании группы.

Здесь есть субъекты риска:
- 🏠 компания (у которой утекли данные)
- 🏢 материнская компания
- 🧑‍⚕️ клиент-ФЛ - субъект персональных данных
- 🏡 другие дочерние компании группы (если, например, имеют тот же бренд)

🏠 Компания:
в любом случае
- должна отреагировать на инцидент и расследовать его
- могут взломать аккаунты ее 🧑‍⚕️клиентов и привести к дальнейшим потерям - нужно это предотвратить
- отвечает перед 🧑‍⚕️клиентами по закону
- должна отчитаться перед 🏛РКН, далее возможна проверка со стороны РКН

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

в случае огласки (что случается не всегда)
- несет свой репутационный ущерб (отток пострадавших клиентов, снижение притока новых, влияние на b2b-контракты)
- в случае получения претензий от 🧑‍⚕️клиентов (не всегда получит при огласке, и получит только от части клиентов) - отработать претензии, принести извинения, выплатить компенсации и т.п. - это называется вторичным риском

🏢 Материнская компания и 🏡 дочерние с тем же брендом
в случае огласки (не всегда)
- несет репутационный ущерб бренду

🧑‍⚕️Клиент-ФЛ
в любом случае
- получает ущерб приватности в зависимости от утекших данных

в случае, если узнал об утечке
- может что-то предпринять для защиты себя или получения компенсации (но вряд ли)

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

Нормативка по ПДн склоняет компанию к тому, чтобы риски 🧑‍⚕️клиента-ФЛ (субъекта ПДн) тоже принимались ей во внимание при принятии решений о мерах защиты. Для этого при моделировании угроз используется параметр последствий для 🧑‍⚕️субъекта ПДн. Не для 🏠компании!

Поэтому модель угроз ПДн не может быть полноценной базой для построения ИБ в компании. Это - взгляд с одной из сторон. Да, направленный на защиту КЦД так же, как и модель угроз в целом по системе. Но результат говорит только об опасности для 🧑‍⚕️субъекта - а это совсем не то, на основании чего принимает решения бизнес.
Да и бизнес не будет читать модель угроз. Особенно по БДУ. Её уже и безопасники не читают. И не пишут. Автоматизируют.

А ущерб 🏢 материнской и 🏡 сестринским компаниям вообще не в вашей зоне ответственности, если не будет реакции с их стороны.

#risks
⬇️