Привет, Хабр! Меня зовут Ирина, я аналитик по информационной безопасности в Авито. В этой статье я делюсь опытом и личными впечатлениями о выстраивании процесса оценки и управлении рисками информационной безопасности в Авито.

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

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

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

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

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

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

Чтобы прийти с этим к менеджменту, у нас должны быть: 

• большой процент покрытия процессом наших ресурсов;

• риски и понимание того, как мы можем их снижать. 

• и самое главное — объяснить эти вещи понятным менеджменту языком.

Первый виток. Инициатива.

Компании все еще часто начинают заниматься рисками безопасности, если это:

• обязательства перед регуляторами (как в банках); 

• требования стандартов, которым компания соответствует. Оба варианта приводят к очень формальному и отчасти бюрократическому подходу. Если только...

…если только мы не говорим про компанию с определенным уровнем зрелости. Но об этом— далее.

Путь команды ИБ Авито в оценке рисков безопасности своего рода уникален, по крайней мере, на моей практике. Уникальность в том, что оценка рисков как отдельный процесс была собственной инициативой команды продуктовой безопасности. 

Представьте, что силами команды ИБ и продуктовых команд уже налажены довольно зрелые процессы в рамках Secure SDLC, есть аудиты, пентесты. Команды продуктовой разработки выполняют упражнения по моделированию угроз, есть довольно осознанное сообщество Security Champions, bug bounty, привлечение к оценке рисков на старте новых проектов/инициатив — и прочее, прочее. Вот и практическая безопасность «по классике»! И ИБ приходит с новой инициативой: дополнительно ко всем существующим активностям решено регулярно оценивать риски.

Профит от инициативы нашли для всех: продуктовые команды могут понять потенциальные проблемы в безопасности overall и прокачать уровень в оценке зрелости TMM (Team Maturity Model, самооценка зрелости команд по разным критериям). Команда безопасности получает прозрачную картину по рискам, имеет возможность обнаруживать и решать системные проблемы.

Чтобы начать, нам понадобилось всего несколько составляющих:

• готовность экспертов из ИБ инвестировать свое время и встречаться с командами для совместного брейншторма;

• готовность самих команд разработки понять и принять; 

• простая и интуитивно понятная метода;

• любимая рисковиками табличка Excel со списком получающихся рисков.

Провели первые оценки, запланировали задачи и особо ответственные взяли их в работу.

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

Немного о том, как происходят оценки рисков на этом этапе.

Чтобы найти и впервые оценить риски для команды, эксперт ИБ встречается с кем-то из команды разработки (обычно это тимлид и security champion или просто кто-то из разработчиков с пониманием процессов команды) . В качестве «домашнего задания» команда сама составляет список того, что у них есть, с какими данными это связано. Следующий этап — вопросы о том, что плохого с этой информацией может произойти:

• что будет, если данные «утекут», куда не следует?

• что будет, если кто-то изменит информацию так, как не было задумано изначально?

• что будет, если актив/данные в активе будут удалены или недоступны?

Некоторые команды могут сразу назвать потенциальные «узкие места» в своих процессах, особенно если они уже проводили моделирование угроз.

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

Второй виток. Налаживание процесса.

Надо понимать, что переход от инициативы к внедрению процесса (то есть осознание ценности) невозможен без трёх важных составляющих:

• зрелость компании;

• зрелость менеджмента;

• наличие ресурса.

Любые другие необходимые составляющие на этом этапе — скорее вытекающие из этого списка следствия. 

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

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

А именно:

• создавать риски и задачи по ним, делиться с продуктовыми командами;

• следить за рисками с истекшим сроком давности;

• вовремя находить тех, кто еще не проходил оценку;

• собирать свежий урожай  итог оценок, демонстрировать его всем стейкхолдерам и подсвечивать боли.

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

Теперь новый подход к оценке рисков разблокирован!

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

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

Третий виток. Автоматизация.

На третьем этапе мы сфокусированы сразу на нескольких направлениях:

• уход в автоматизацию. Собираем без участия людей все ассеты и факторы рисков, которые можно собрать. Факторами могут быть — ПДн, бизнес-критикал процессы, API, которые отдают данные наружу, прочие подобные вещи;

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

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

Процесс есть. Что дальше?

Вишенка на торторте всего процесса оценки рисков — риск-комитеты.

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

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

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