Неудача?

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

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

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

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

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

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

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

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

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


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

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

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

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

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


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

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

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

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

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


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

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

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

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

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

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


Заключение

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


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

#softs #privacy #culture #AI

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

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

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

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

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

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

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


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

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

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

#privacy #edu

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

В игре от 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
⬇️

⬆️начало в предыдущем посте

В общем
Не мешайте субъектов риска в один котёл.

🥘 Ваших ЛПР будут интересовать только последствия для вашей компании и для них самих. Всем остальным можно посочувствовать, но не более того – если это не приносит выгоду компании или не уменьшает ее убытки.
Соответственно, в вашем реестре рисков должны быть только риски, где субъект - ваша компания.

🥘 Реакции других лиц, которые будут влиять на вас при реализации риска, возникнут не со 100% вероятностью. И последствия этих реакций (вторичный риск) тоже для вас наступят не всегда. То есть шанс наступления вторичного риска - доля от шанса наступления основного события.

#risks

Сюжет болливудского кино, не иначе.

CISO индийской страховой продал доступ к базе данных 31 миллиона индийцев китайскому хакеру

@

В какой-то момент доступ хакера блокируется, хакер возмущается

@

CISO отвечает, что нужно больше денег, потому что руководство компании требует свою долю

@

Хакер требует вернуть деньги, ему, видимо, отказывают

@

Хакер выкладывает данные в открытый доступ



Новость отсюда, оригинальный пост в Х.

Две рисковых культуры

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

1️⃣ Принятие риска как главный способ обработки рисков в компании

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


2️⃣ "Закрытие риска" как единственное, что с рисками можно сделать

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

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


⏯️ Как исправить ситуацию?

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

Но есть несколько направлений, куда можно двигаться:

⚛️ Обучить защитников основам риск-менеджмента
Здесь главное не попасть на простые и быстрые методики оценки рисков. Суть не в том, чтобы понять, как оценивать риски, а в том, чтобы понять, зачем нужно управлять рисками, какова цель. Цель, как я уже говорила - повысить информированность, обоснованность управленческих решений.

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

⚛️ Поговорить с топ-менеджментом о том, какие задачи перед компанией стоят в целом, и какие главные проблемы у бизнеса. Возможно, вопросы безопасности действительно меньшее из зол, что может произойти. В таком случае от защитников может ожидаться только поддержание базовой гигиены, и это нормально.

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

⚛️ Определить зоны ответственности, отталкиваясь от возможностей и влияния. Ответственность должна быть на том, кто выделяет ресурсы. Если он хочет передать часть ответственности, он должен передать и часть возможностей по распределению ресурсов.

⚛️ Выступать
Занимать эфир на собраниях компании, проводить встречи и вебинары для отдельных подразделений, публиковаться на внешних ресурсах от имени компании. Рекламировать свою деятельность, показывая её важность и результативность для бизнеса.