Привет, Хабр! Меня зовут Ирина, я аналитик по информационной безопасности в Авито. В этой статье я делюсь опытом и личными впечатлениями о выстраивании процесса оценки и управлении рисками информационной безопасности в Авито.
Речь не о методологии, а о том, как из инициативы мы выстраиваем процесс. Рассказываю, что понадобилось нам для запуска и поддержки процесса оценки рисков, в чем польза оценки рисков для нас, и какие есть методы, чтобы не отставать от трендов.
Спойлер: кейс интересный и в своем роде уникальный, в то же время он в стиле последних тенденций информационной безопасности. Наш опыт будет полезен не только ИБ-аналитикам, риск-менеджерам и менеджерам в безопасности, но и всем тем, кто интересуется темой оценки рисков.
Инициатива становится процессом, когда понятны ценность и результат.
Небольшое отступление по поводу стремительно меняющихся в последние годы трендов ИБ. Мы все уже начитались об уходе от бумажной безопасности к практической. Новый тренд — это переход от практической ИБ к результативной. Первую от второй отличает целеполагание, которое исходит от менеджмента.
Еще один тренд — это уход от сложных рисков к недопустимым событиям. В этой статье речь про недопустимые события в привычном понимании не пойдет, но концепцию недопустимых событий мы частично пересобрали по-своему.
Итак, для себя мы определили ценность в том, чтобы все видели риски overall, тенденцию к их снижению и были готовы коммититься в работу над ними. Коммититься, в первую очередь, должен менеджмент, определяя на основе результатов наших оценок, что для него действительно недопустимо.
Чтобы прийти с этим к менеджменту, у нас должны быть:
большой процент покрытия процессом наших ресурсов;
риски и понимание того, как мы можем их снижать.
и самое главное — объяснить эти вещи понятным менеджменту языком.
Первый виток. Инициатива.
Компании все еще часто начинают заниматься рисками безопасности, если это:
обязательства перед регуляторами (как в банках);
требования стандартов, которым компания соответствует. Оба варианта приводят к очень формальному и отчасти бюрократическому подходу. Если только...
…если только мы не говорим про компанию с определенным уровнем зрелости. Но об этом— далее.
Путь команды ИБ Авито в оценке рисков безопасности своего рода уникален, по крайней мере, на моей практике. Уникальность в том, что оценка рисков как отдельный процесс была собственной инициативой команды продуктовой безопасности.
Представьте, что силами команды ИБ и продуктовых команд уже налажены довольно зрелые процессы в рамках Secure SDLC, есть аудиты, пентесты. Команды продуктовой разработки выполняют упражнения по моделированию угроз, есть довольно осознанное сообщество Security Champions, bug bounty, привлечение к оценке рисков на старте новых проектов/инициатив — и прочее, прочее. Вот и практическая безопасность «по классике»! И ИБ приходит с новой инициативой: дополнительно ко всем существующим активностям решено регулярно оценивать риски.
Профит от инициативы нашли для всех: продуктовые команды могут понять потенциальные проблемы в безопасности overall и прокачать уровень в оценке зрелости TMM (Team Maturity Model, самооценка зрелости команд по разным критериям). Команда безопасности получает прозрачную картину по рискам, имеет возможность обнаруживать и решать системные проблемы.
Чтобы начать, нам понадобилось всего несколько составляющих:
готовность экспертов из ИБ инвестировать свое время и встречаться с командами для совместного брейншторма;
готовность самих команд разработки понять и принять;
простая и интуитивно понятная метода;
любимая рисковиками табличка Excel со списком получающихся рисков.
Провели первые оценки, запланировали задачи и особо ответственные взяли их в работу.
Что же дальше? А дальше надо как-то поддержать жизнеспособность инициативы. И раскатать её на всех, мы ведь хотим получить целостную картину. Для этого надо организовать процесс оценки рисков в постоянно растущей динамичной компании с 300+ команд. А ведь нужно, чтобы картина по рискам не устаревала. То есть результаты оценок нужно время от времени освежать. Ресурсы пока что все те же.
Немного о том, как происходят оценки рисков на этом этапе.
Чтобы найти и впервые оценить риски для команды, эксперт ИБ встречается с кем-то из команды разработки (обычно это тимлид и security champion или просто кто-то из разработчиков с пониманием процессов команды) . В качестве «домашнего задания» команда сама составляет список того, что у них есть, с какими данными это связано. Следующий этап — вопросы о том, что плохого с этой информацией может произойти:
что будет, если данные «утекут», куда не следует?
что будет, если кто-то изменит информацию так, как не было задумано изначально?
что будет, если актив/данные в активе будут удалены или недоступны?
Некоторые команды могут сразу назвать потенциальные «узкие места» в своих процессах, особенно если они уже проводили моделирование угроз.
На встрече с командой эксперт проверяет «домашку» или же делает ее вместе с коллегами. Далее он погружается глубже в возможные сценарии утечек, несанкционированных изменений и доступов, недоступности. Делает он это, исходя из специфики процесса или системы. Задача — определить существенность уже подсвеченных узких мест и найти то, что могло выпасть из поля зрения. Посмотреть на системы и процессы с разных сторон нам также помогает чек-лист с вопросами.
Второй виток. Налаживание процесса.
Надо понимать, что переход от инициативы к внедрению процесса (то есть осознание ценности) невозможен без трёх важных составляющих:
зрелость компании;
зрелость менеджмента;
наличие ресурса.
Любые другие необходимые составляющие на этом этапе — скорее вытекающие из этого списка следствия.
Здесь нам становится очевидно, что поставленные задачи текущими силами и вездесущим Excel не решить.Тогда мы идем дальше: внедряем систему класса SGRC. Выбираем из популярных присутствующих на рынке решений — адаптируем под свой кейс и процесс.
Пройдя огонь, воду и медные трубы, процесс внедрения, мы можем управлять рисками и масштабировать процесс за счет автоматизации.
А именно:
создавать риски и задачи по ним, делиться с продуктовыми командами;
следить за рисками с истекшим сроком давности;
вовремя находить тех, кто еще не проходил оценку;
собирать свежий
урожайитог оценок, демонстрировать его всем стейкхолдерам и подсвечивать боли.
Работа с рисками стала проще, реестр рисков начал стремительно пополняться. На этом этапе мы имеем реестр с сотнями рисков и прозрачность на нижнем уровне (для продуктовых команд).
Теперь новый подход к оценке рисков разблокирован!
Как я писала выше, исходные параметры задачи — необходимость в регулярной оценке рисков в 300+ командах и ограниченное количество ресурсов ИБ.
После прохождения второго этапа становления процесса мы открываем возможность выбирать способ повторной оценки рисков. Первый способ (как мы помним) — это встреча с экспертом и мозговой штурм. Командам доступны все артефакты первых оценок. На основании этого они могут ответить на вопросы, что поменялось с последней оценки и насколько сильно. При незначительных изменениях оценку рисков делаем асинхронно.
Третий виток. Автоматизация.
На третьем этапе мы сфокусированы сразу на нескольких направлениях:
уход в автоматизацию. Собираем без участия людей все ассеты и факторы рисков, которые можно собрать. Факторами могут быть — ПДн, бизнес-критикал процессы, API, которые отдают данные наружу, прочие подобные вещи;
упор на автономность продуктовых команд. В целевой картине они могут самостоятельно следить за рисками и даже их выявлять, будучи погруженными в контекст и понимая свои бизнес-процессы;
метрики и метрики. К примеру, нам важно знать: насколько наши риски актуальны в каждый момент времени, закрываются ли задачи, какое покрытие наших сервисов процессом оценки рисков и так далее.
Процесс есть. Что дальше?
Вишенка на торторте всего процесса оценки рисков — риск-комитеты.
Идея проста — мы несем менеджменту регулярно картину по рискам и задачи по их снижению. Получаем коммитменты или возражения о том, что существование каких-то из рисков допустимо и приемлемо, а иногда и единственно правильно. Появляются приоритетные задачи, инициативы, направления и цели. Вот такое движение в сторону результативного кибербеза.
Мы еще в процессе выстраивания схемы работы, сейчас — третий его этап. Но польза от уже сделанного есть и она ощутима. При этом не исключено, что в дальнейшем мы будем трансформировать сам процесс и методику.
Спасибо вам за время, уделенное статье! В комментариях я с радостью отвечу на вопросы, там же вы можете поделиться историями из личного опыта о построении ИБ-процессов и возникших при этом сложностях.
