Переделали всё, не разломав ничего, или Проект по информационной безопасности (взглядом PM)
Стук в дверь…
Тихо скрипнула задвижка, дверь открылась, и вот они — специалисты информационной безопасности со своими задачами. Куда бежать? Кого спасать? Где лазейки? А поздно! Мы уже всё увидели, услышали и готовы действовать. Новость или само появление отдела информационной безопасности (или Cyber Security-направления) в большой, узнаваемой на рынке компании с хорошей репутацией, часто встречается сотрудниками компании очень неоднозначно.
С одной стороны:
вводятся дополнительные ресурсы и экспертиза для улучшения бизнес-процессов;
увеличивается выявление критичных аспектов текущего и будущего функционала;
появляются доработки, которые повысят уровень непрерывности бизнеса;
повышается востребованность продуктов компании среди потребителей, которым важна сохранность их данных;
улучшается осведомлённость и экспертиза в нормативных требованиях к сохранности данных;
и многое другое.
Но многие обратят внимания на новые барьеры:
дополнительные требования к коду, которые усложнят или замедлят разработку;
исправление старых работающих процессов под нововведённые требования ИБ (зачем трогать то, что и так хорошо работает?);
выявление рисков и уязвимостей с запросом на исправление;
и прочее.
В данной статье поделюсь своими «заметочками» и полученным опытом в изменении уже функционирующих процессов разработки в компании. Процессов, которыми пользуются абсолютно все в компании.
Важно! «Все персонажи и события вымышлены, любые совпадения случайны…». А у меня «Все персонажи — это потрясные высокоуровневые специалисты, участвующие в проекте, а любые изменения происходили под нашим чётким наблюдением и по согласованному мной плану».
Эта статья написана проджект-менеджером (Project manager/PM — такова моя должность в Ozon), который реализует проекты по Информационной безопасности.
Начнём-с…
Большие объемы поставки кода в крупных ИТ-компаниях делают почти невозможным путь реализации процесса, когда:
сотрудники ИБ,
аудиторы,
уполномоченные по проверкам на соответствие нормативным требованиям,
или просто выделенные специалисты
смогут своевременно проверять каждый код для релиза, а именно:
проверять его на выполнение всех требований безопасности;
предоставлять рекомендации;
принимать решение на его внедрение или нет;
И вот для решения данной проблемы сотрудники ИБ стараются выстроить процесс безопасного подхода к разработке (в данном случае поговорим о ней, не трогая направления инцидентов, рисков, аварнеса и т.д.).
А что делать, если процесс уже давно существует, несколько тысяч сотрудников с ним работают ежеминутно, даже ежесекундно и параллельно, а внедрять изменения «больно», страшно и рискованно для работоспособности бизнеса (а это, позвольте, деньги — одно из того, ради чего компания существует, растёт, платит сотрудникам)?
Ответ прост: менять мир к лучшему! Это сложно, да, согласна, но утверждаю, что это возможно. Даже можно сделать так, чтоб разработчики остались в хороших взаимоотношениях с ИБ, а компания продолжала безостановочно работать.
И как это можно сделать, допустим, в рамках какого-то проекта, где мы хотим достичь определённой цели.
Важно! Проектом мы достигаем не общей безопасности компании (псс! ведь это уже стратегия ИБ), а конкретно поставленной цели в рамках стратегии.
Предлагаю рассмотреть шаги такого возможного проекта у вас (ps. так или иначе, все проекты по структуре похожи, поэтому буду писать заметочки из своего проекта);
Все начинается с простого: выявление несоблюдения требований безопасности в выполняемых процессах — наличие риска или рисков, которые компания не имеет возможности принять в текущем состоянии.
Некоторые могут сказать: «когда процесс выстраивался, то не было таких требований» или «мы пользуемся, и все выглядит безопасно», «а что сейчас изменилось? зачем менять? работали так и дальше сможем».
Только мы живём в то время, когда в мире идёт непрерывная разработка чего-то нового, ценного и желанного, что захочется спрятать (конфиденциальность), ограничить (доступность) и оберегать (целостность) только для «своих». И если мы хотим обладать этой ценностью, надо научиться её защищать и проапгрейдить наш сейф до самого защищённого объекта;
Второй шаг: несоблюдение требований безопасности из Шага 1 инициируем в проект, который берёт в работу проджект-менеджер информационной безопасности (далее ПМ ИБ), это больше административный шаг, фиксация необходимости согласовать выделение ресурсов для реализации проекта;
Третий: ПМ ИБ фиксирует границы проекта, а точнее, «расползавшийся» риск безопасности из Шага 1, который требует компенсирующих мер. И ему на помощь выступает технический специалист/архитектор ИБ (далее техлид ИБ). Выделенный специалист на весь проект, который обладает требуемыми знаниями и навыками по устранению риска, заложенного в основе проекта.
Четвёртый шаг: создание roadmap по проекту и к нему же — матрицы коммуникаций (ручками ПМ ИБ). Ведь нам уже известна проблема, известна её зона распространения, осталось найти решение и способ его реализации.
ps. личная заметочка № 4.1
Этот пункт важен тем, что проблема не просто спускается на потребителя и ИБ ждёт его решения, а ИБ совместно (!) со всеми стейкхолдерами и вовлечёнными исполнителями ведёт поиск лучшего решения, а также способов его реализации и старается достигнуть компромисса по минимизации риска и поддержания текущих процессов стейкхолдеров. ПМ ИБ организует все эти встречи/грумминги, фасилитирует их и даёт ход задачам.ps. личная заметочка № 4.2При отсутствии явно зафиксированных границ работ, а также ответственных за деятельность на каком-нибудь этапе проекта может случиться, что на одну задачу назначено 2–3–4 исполнителя, а на другую — ни единого. ПМ важно быть внимательным, любознательным и чуть проактивным (в рамках адекватного);
Если члены команды ИБ не ищут возможные варианты решения выявленной/новоопубликованной/труднореализуемой проблемы безопасности, для которой ещё нет точного ответа на просторах интернета/опыта, тот момент, когда «проблема есть, а вот решения для данного формата — нет (ну нет такой статьи на хабре, что ж тут поделать?)», то точно ли это заинтересованные в результате специалисты, которые способствуют росту компании? Ведь именно такой подход к проблеме укрепляет непонимание и разрушает доверие между командами разработки и ИБ, когда одни хотят быстрее релизнуться и получить результаты от опережения конкурентов на рынке с новым функционалом, а ИБ на постоянной основе блочат релизы с информацией о наличии риска или его возможности. Может, именно поэтому так важно иметь ПМ ИБ?
Фух… благо в Ozon не такие безопасники, наши специалисты вовлечены в процессы смежных подразделений и выделяют время для экспертизы и поиска решений;
Пятый шаг: проверяем, что заложили в roadmap проекта — действия не только по соблюдению требований ИБ — того, что уже было разработано и введено в эксплуатацию, а также по корректировке текущих процессов и внедрению в них изменений для повышения безопасности в рамках зафиксированного риска из Шага 1.
Это позволит новым разработкам/процессам сразу включать в себя необходимые требования безопасности, а не повторять проект через какое-то время снова.
Предлагаю… хммм… разделить Шаг 6 на два стрима:№1 внедрение изменений для улучшения того, что УЖЕ есть;
№2 внедрение предварительных проверок для того, что только БУДЕТ.
ps. личная заметочка
«Безопасность и удобное использование её требований в процессах» звучит почти нереалистично, но к этому можно максимально приблизиться, когда точно знаешь, что нужно команде, разрабатывающей продукт, какой их (скажем так), что действительно нужно заказчику от данной разработки и какие требования безопасности к этому применимы. Требования, которые не перекроют всю разработку своей «неудобностью» или «невозможностью», а сделают продукт более качественным. Поэтому ПМ просто необходимо воспринимать систему во всей своей целостности и делать всё возможное, чтобы потребители получили желанный и безопасный результат в итоге.
Шестой шаг: есть проблема, есть решение, есть исполнители и сроки.
Power ON! Настало время ПМ драйвить проект до достижения результатов.
Мои заметочки на основе предыдущих пунктов и самого процесса ведения проекта. Берите, что хотите:
Наличие специалиста ИБ/техлида ИБ/архитектора ИБ. Профильный специалист информационной безопасности с момента активных шагов в проекте выступает больше наблюдателем и контроллером исполнения требований, а также участвует в поиске решений проблем, которые возникают во время проекта, как неучтённые или новопоявившиеся аспекты;
Наличие технических лидов вовлечённых систем. В связи с тем, что проект инициирован со стороны ИБ, ПМ от ИБ, очень выручает наличие техлидов от смежных направлений: специалистов систем/процессов, которые участвуют в проекте (рекомендуется не больше 6 человек). Они имеют более углублённую экспертизу в текущих процессах, которые запланировано сделать эффективнее.
Принятие масштабных решений. Важно вовлекать всех выделенных техлидов на протяжении всего проекта, они обладают необходимой экспертизой.
Это позволит:на этапах планирования проекта учесть больше вариаций развития, а также отбросить нежизнеспособные;
в процессе проекта качественнее реагировать на неучтённые области и решать выявленные проблемы;
и в конце — все техлиды получат дополнительный опыт в направлении информационной безопасности и понимание о важности привлечения специалистов ИБ на ранних этапах процессов.
Достижение компромисса. ПМ имеет информацию о картине целиком, видит, к какому результату стремятся команды разработки, знает о требованиях безопасности и понимает, какую бизнес-ценность ожидает pаказчик (у нас CISO и СТО). Его задача — не выбрать одну из сторон и действовать только в идеологических целях данной стороны, а найти компромисс между всеми вовлечёнными лицами.
Седьмой шаг: в процессе выполнения проекта могут появляться «подводные камни», обнаружение которых потребует корректировки roadmap проекта.
Заметочки для рефлексирования:
Если у проекта есть повторяющиеся действия или похожие по выполнению (массовое изменение config«ов, миграция клиентов, аудит доступов с последующим отрывом ролей и т.д.), полезно использовать заметки с предыдущего подхода к выполнению задачи перед «вторым заходом». Проверьте выполненные в прошлый раз шаги, возможно, какие-то из них нужно повторить или адаптировать под новые вводные и повторить с изменением, какие-то не потребуются вовсе. Может казаться, что вы все помните, но лучше убедиться в этом. Сделайте чек-лист, инструкцию или план по пунктам. У вас есть бесценный опыт, полученный на прошлых этапах, используйте его;
Заметка, вытекающая из первой. Фиксируйте результаты по каждому этапу и отписывайте статус по задаче. Статус по завершению задачи — это must have, но также информационно для остальных потребителей узнавать промежуточные статусы по задачам, особенно, если они выполняются на протяжении долгого времени. Да и вам будет это полезно, будет видно, простаивает задача или нет, а если да, то искать причины. Можно отписываться по микроизменениям, можно выбрать временной диапазон и отписываться по нему и т.д. Feel free;
Это нормально, что во время реализации проекта какие-то задачи будут терять свою актуальность, это могут быть те, которые запланировали в начале проекта, а к середине необходимость их исполнения исчезла. Не бойтесь их исключить, это оптимизация рабочего процесса по проекту, не надо их выполнять, просто потомууууу… что когда-то это был возможный вариант развития события;
Информирование и обратная связь. Вы меняете давно устоявшиеся процессы, которыми многие уже пользуются не первый год, а с инструкциями или регламентами ознакомились только вначале и забыли , поэтому запланируйте на постоянной основе информирование всех потребителей о тех или иных изменениях, создайте «голубиную почту» для получения обратной связи. Это поможет выявлять отклонения во время раскатки, а также обеспечит быстрое реагирование, если что-то пошло не так;
Проверки. Проверяйте исполнение задач, они должны отвечать тому dod, который им был зафиксирован перед реализацией.
Бонус. «Подводные камни» — это любые факторы, которые не были заложены в проект по причине своего низкого процента реализации или просто «забыли/не знали» и влияют на сроки, результат, качество.
Примеры:
— ветрянка у всего отдела, и у них больничный на несколько недель;
— всемирная пандемия;
— запланированная интеграция с продуктом, который решили в моменте вывести из эксплуатации;
— и прочее.
Восьмой: готово! Вы справились! Вы молодцы!
Проект принят и утверждён, выполнен в срок и даже чуть лучше ожидания Заказчика (я уверена, что именно так вы и сделаете), и все мы немного приблизились к безопасности.Важно! Я очень хочу подсветить, что безопасность НЕ абсолютна, она не статична и это недостижимое состояние. Безопасность — это компромисс, но мы в состоянии поддерживать её на высоком уровне.
Поэтому проектов будет уххх как много ещё, не унывайте по завершению :)
Девятый, последний шаг: задокументируем все выполненные шаги, а также результаты, ошибки, решённые проблемы и что можно было сделать лучше.
И поделимся опытом со своими коллегами:
если проект был инновационным в вашей команде — проведите ретро и обсудите результаты с командой;
если проект был инновационным во всей компании — сделайте финальный анонс с последней актуальной информацией для всех потребителей и уточните, куда обращаться с вопросами.
Заключительная часть, или Тикет со статусом «Закрыт»
Безопасность имеет первостепенное значение на этапе проектирования и выбора архитектуры. Специалисты, отвечающие за информационную безопасность, должны содействовать исполнению требований безопасности, а не заниматься ей самостоятельно, а также не препятствовать развитию бизнеса.
По опыту более компетентных специалистов и на основе проф. литературы можно прийти к заключению, что изменения, внесённые в продукт/процесс на финальных этапах разработки или в уже функционирующей системе, принимаются командами без распростёртых объятий, и они сложнее для реализации, чем внесённые на ранних стадиях.
И все же, если на этапе уже полного функционирования процесса надо внести изменения, связанные с повышением уровня безопасности, то это актуально отдать на реализацию проджект-менеджеру Информационной безопасности.
В его обязанности входят: навыки управления процессами, организация работ различных исполнителей/команд, контроль исполнения сроков, согласование и многое другое, и один из важных аспектов — то, что он имеет знания в области информационной безопасности. ПМ ИБ организовывает работу «разношерстных» команд, является для них связующим звеном, а также единым окном для Бизнеса. В то время как технические специалисты продолжают работать над своими задачами, лишь изредка привлекаясь к участию в процедурах проекта, затронувших их зону ответственности, и не принимают участие в менеджерской деятельности.
Создание среды, в которой безопасный способ работы является и самым простым, — великая цель, к которой стремится ИБ. Давайте строить безопасные, востребованные и способные к развитию процессы вместе, управленец проектами всегда поможет.
