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

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

Кто что делает

Для начала давайте попробуем определиться с тем, что же должен делать руководитель проекта. Понимаю, что вопрос несколько холиварный:) Мне приходилось видеть разное распределение ролей между РП и другими участниками команды. Классический подход предполагает, что проектный менеджер отвечает за сроки, а за техническую часть работ (составление спецификации, качество работ, вопросы инженеров и т. д.) отвечает архитектор проекта или тимлид технической команды. Но это в теории, а на практике мне приходилось видеть разное. Например, типичная история, когда роли РП и архитектора совмещают в одном человеке в целях экономии. Казалось бы, чем плохо, один человек следит за сроками, отмечает вехи в Project, и следит за качеством выполняемых работ. На практике такой подход будет работать только на небольших проектах (пилотах, пресейлах), когда объем работ не столь велик и один человек вполне может справиться со всеми задачами. Хотя, специфика инфобеза и здесь может накладывать свои ограничения. Так, к примеру, в случае если проект связан с персональными данными или КИИ, необходимо хорошо разбираться в соответствующих нормативных актах, причем не только на уровне соответствующих ФЗ № 152 и № 187, но и на уровне приказов ФСТЭК, правил категорирования и т. д.

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

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

ИБ как довесок

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

Здесь руководитель проекта может быть не сильно знаком со спецификой инфобеза (он привык руководить большими проектами, где много разных систем) в результате работы по ИБ планируются по остаточному принципу (ну что там, какой‑то антивирус поставить), хотя по факту система ИБ тоже может содержать в себе множество довольно сложных подсистем (FW, IDS, SIEM, EDR и т. д.). При этом, данные подсистемы тесно интегрируются и с сетевым и серверным оборудованием и тем более с софтом (одно только подключение нестандартных источников к SIEM может занять немало времени). Конечно здесь архитектор должен донести до РП важность‑сложность работ по интеграции компонентов ИБ с другими системами, но и проектный менеджер должен с пониманием отнестись к доводам архитектора и не оставлять на работы по интеграции последнюю неделю перед приемкой.

Таким образом, не воспринимаем инфобез как некий довесок, которой можно внедрять по остаточному принципу.

О стратегии

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

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

При этом у нас нет ни нормального разграничения прав доступа к корпоративным ресурсам, ни аудита доступа, ни анализа защищенности, ни средств мониторинга и реагирования… По сути мы просто кое‑как закрыли одну щель в стене, оставив все остальные.

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

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

Согласование с заказчиком — это весело

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

А дальше начинается веселье. Совершенно необязательно, что наше внедряемое оборудование будет размещаться в ЦОД. Более того, решения по ИБ заказчик вряд ли будет размещать во внешнем ЦОДе, вместо этого он скорее всего будет использовать какое‑то серверное помещение на территории предприятия.

Далее, стойке с нашим оборудованием системы ИБ требуется место в серверной, подвод электропитания как минимум по первой категории, отвод тепловыделения. Банально, наша стойка с оборудованием можно быть довольно тяжелой.

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

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

Заключение

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

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

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

Соблюдение всех этих рекомендаций позволит РП эффективно управлять проектами по информационной безопасности.

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

• 9 июня, 20:00
  Как системному аналитику не допустить Spaghetti Code и других проблем в архитектуре

• 16 июня, 20:00
  Анализ требований и их влияние на архитектуру

• 19 июня, 20:00
  Grafana — продвинутое использование

Полный список открытых уроков по управлению, разработке и ИБ смотрите в календаре.