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

В игре от 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️⃣ "Закрытие риска" как единственное, что с рисками можно сделать

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

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


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

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

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

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

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

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

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

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

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

Самое главное в проектировании процессов

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

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

📐 Нет ли другого варианта продолжить деятельность?
Например, пролезть в дырку в заборе вместо КПП.

📐 Они заинтересованы в прохождении процесса?
Например, он снимает с них ответственность за что-то.

📐 Есть ли возможность подделать параметры, по которым процесс запускается?
Например, сказать, что ребенку еще нет семи лет, и за него не надо платить в транспорте.

📐 Есть ли наказание за обход процесса? Достаточно ли оно чувствительно для этих людей?
Увольнение, лишение премии? Или просто письмо руководителю, который так же не заинтересован следовать процессу?

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

Не пишите бумажки, пишите работающие документы.

Кто такой методолог ИБ?

О методологах ИБ не часто говорят в перечнях специализаций в ИБ. Вакансий методолога ИБ не так много, как технических специалистов. Но с каждым годом их становится всё больше.
Я сама работаю методологом ИБ – уже во второй компании.

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

Чем занимается методолог?

Если коротко, то методолог занимается организацией процессов ИБ. По сути методолог занимается тем, что могло бы ожидаться от CISO в части управления ИБ, но CISO в компании один, а задач у него столько, что нормированный рабочий день ему (ей) только снится. В зарубежных вакансиях такой специалист называется GRC – Governance, Risk and Compliance.
Если вам интересна методология ИБ, я рекомендую почитать учебник по подготовке к ISACA CISM.

Подробный перечень зон ответственности методолога зависит от компании, её размера, особенностей управления, и в него может входить:
🍪 составление организационных ЛНА по ИБ: политика ИБ, положение о конфиденциальности, перечень конфиденциальной информации, положение о коммерческой тайне, документация СУИБ, положение о подразделении ИБ, должностные инструкции сотрудников ИБ
🍪 оформление и поддержание базы знаний ИБ: наведение порядка в хаосе, формирование структуры базы знаний, правил её ведения, редактирование страниц и разделов так, чтобы они были понятны тем, кто их будет читать, включая нетехнических специалистов
🍪 помощь в написании (а часто написание за них) документов техническим специалистам по ИБ, у которых чаще всего требования лежат в голове, а перенести на бумагу очень тяжело
🍪 решение юридических вопросов ИБ (хорошо, если вместе с юристами): как не нарушить закон, обеспечивая ИБ, как кого-то правильно уволить за нарушение ИБ, лицензирование деятельности по ИБ, взаимодействие с регуляторами по ИБ
🍪 соответствие внешним требованиям и стандартам в области ИБ (и смежных вроде непрерывности, требований к хранению данных и т.п.): законодательства, регуляторов, вышестоящих организаций, контрагентов, добровольная сертификация
🍪 аналитика: оценка состояния ИБ по внешнему или внутреннему фреймворку, BIA, внутренние аудиты
🍪 управление рисками ИБ, непрерывности: организация, формирование методик и процессов, интеграция в процессы компании, проведение анализа и оценки, формирование планов обработки рисков, организация обработки рисков, внедрение и поддержание GRC-системы
🍪 соответствие требованиям законодательства о персональных данных: выполнение функций DPO
🍪 сопровождение внешних аудитов: аудиты регуляторов, головной компании, аудиты не по теме ИБ (например, финансовые аудиты, в которых есть вопросы ИБ), сбор и организация хранения артефактов для аудиторов и результатов аудитов, организация работ по исправлению найденных несоответствий
🍪 анализ и улучшение процессов ИБ: поиск пробелов и несвязностей в процессах, изменение и контроль процессов
🍪 организация комплексного подхода к ИБ, где решаются не точечные проблемы, а повышается зрелость по домену ИБ целиком

Кто может работать методологом по ИБ?

Проще всего работать методологом бывшему консультанту по ИБ с широким профилем (например, как я 😊). Это точно не работа, которой можно заниматься сразу после выхода из вуза: нужен широкий кругозор в ИБ, гибкость, умение находить компромиссы, делать MVP. Нужно уметь смотреть на ИБ сверху вниз, с позиции менеджмента и общей картинки, а не конкретных контролей. И нужна большая насмотренность, чтобы понимать, что будет работать в долгосрочной перспективе, а что – мертворожденное и быстро отвалится.

Нужен ли вашей компании методолог?

Всё зависит от факторов:
- количество и сложность внешних требований
- желание компании вырасти из штанов стартапа и жить по процессам
- наличие ФОТ на еще одного ИБшника)

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

Онлайн-конференция “CyberGirls: как построить карьеру в ИБ”

В прошлом году я была ментором в менторской программе Women in Tech Russia. Мои менти хотели перейти в сферу ИБ как из ИТ, так и из далекой от ИТ сферы. Сфера ИБ сейчас востребована, но тяжело понять, чем же занимается ИБ-шник, и какие скиллы для этого нужны. Многие гайды по специализациям в ИБ довольно узконаправленные и часто не затрагивают все возможные специализации, либо завышают требования к специалистам. И, например, юристы могут увидеть, что для того, чтобы перейти в ИБ, им нужно знать несколько языков программирования, и подумать, что это не для них, так и не узнав, насколько в ИБ не хватает толковых специалистов по работе с документацией.

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

Зачем, а главное нафига

Люди не любят не понимать, зачем им что-то делать.

🛠 Если специалисты не понимают, зачем они работают свою работу, они выгорают

🔒 Если ИБ не понимает, чего от них ожидает бизнес, они занимаются самодурством и безопасностью ради безопасности

⚖️ Если попросить юриста провести анализ, он просто ответит "так нельзя", не объясняя свою позицию и не предлагая альтернатив, если не понимает, зачем этот анализ.

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

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

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

Иногда может помочь даже фейковое объяснение – это показали эксперименты Эллен Лангер, в ходе которых люди охотнее выполняли просьбы, если в них были слова "потому что", даже если за ними следовало что-то несущественное.

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


Кто такие бизнес-партнеры по ИБ?

Бизнес-партнер по ИБ (ИБ БП) - по сути "маленький CISO" бизнес-направления, и одновременно первая линия для оценки со стороны ИБ изменений в бизнес-процессах и ИТ-инфраструктуре направления.

ИБ БП появляются в компаниях, где внимания центральной службы ИБ не хватает для того, чтобы глубоко погружаться в проекты бизнеса.
В таких случаях у СИБ есть три пути, как справиться с нагрузкой:
1. наращивать количество персонала СИБ,
2. создавать подчиненные СИБ в направлениях бизнеса,
3. создать роль бизнес-партнеров, что будет промежуточным вариантом между 1 и 2.


В каких компаниях есть ИБ БП?

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

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


Как организована работа бизнес-партнеров по ИБ?

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

Подчиненность бизнес-партнеров может быть разная в зависимости от компании. Функциональная подчиненность всегда остается СИБ, организационная подчиненность может быть и руководителю бизнес-направления. Также и финансирование позиции, KPI могут быть в бизнес-подразделении, а не в ИБ.


Какие скиллы нужны бизнес-партнеру по ИБ?

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

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

Что не так с секьюрити чемпионами?

Security Champion - это сотрудник бизнес-направления, заинтересованный в ИБ и продвигающий идеи ИБ в бизнес-направлении. У этого сотрудника помимо задач ИБ также есть бизнес-роль и бизнес-задачи.

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

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

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

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