Кто одолеет проект: сказ о трех богатырях на новый лад

Всем привет! Меня зовут Андрей Скрипкин. Еще когда был студентом, понял, что хочу заниматься информационной безопасностью — увлек брат. Уже прошло больше 15 лет, а интерес к профессии только растет. И даже когда казалось, что, работая в различных интеграторах по информационной безопасности и попробовав себя в роли инженера, проектировщика, архитектора, руководителя групп инженеров и проектировщиков, видел уже все, мир информационной безопасности подкидывает что-то новое и дает возможность учиться дальше и узнавать что-то новое. Сейчас уже два года работаю в Positive Technologies в департаменте инжиниринга: реализую проекты на базе продуктов PT. И это, с одной стороны, похоже на мой предыдущий опыт работы в интеграторах, а с другой — это новый опыт, новые подходы к ведению проектов и новый уровень экспертизы.

Пожалуй, главное, что я понял о проектах за время работы: самое важное — это люди. Люди, которые реализуют проект. И от того, как эти люди буду взаимодействовать друг с другом, зависит успех всего проекта. Хороший инженер всегда «приручит» любую технику и победит любые проблемы с программным обеспечением —, а хороший менеджер всегда найдет компромисс в спорных ситуациях.

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

Участники проекта

4f92059841714a4c3e2b4003ff99d5ad.png

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

Я очень часто сталкивался с ситуациями, когда после завершения пусконаладочных работ и проведения приемо-сдаточных испытаний система либо вообще выключалась, либо не эксплуатировалась. А потом все удивлялись:, а почему же произошел инцидент, и главное — что теперь делать? Сталкивался и с ситуациями, когда программное обеспечение было куплено, а внедрение выполнено не было. А потом происходил инцидент, и приходилось отключать всю ИТ-инфраструктуру от интернета и срочно искать, кто может внедрить систему за один день. Как исполнителю, мне всегда грустно, когда такое происходит.

Но в большинстве проектов я видел, как горят глаза у руководителя, который сам решил поработать с DLP-системой, как зауважала SIEM-систему служба ИТ, которая нашла майнер в сети с его помощью. Видел радость специалистов по ИБ, которые смогли предотвратить инцидент.

Используйте системы защиты. Не кладите их на полку.

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

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

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

Остальные задачи распределяются следующим образом:

  • Консультанты по информационной безопасности анализируют процессы в организации заказчика, моделируют угрозы безопасности информации, разрабатывают организационные меры защиты (политики, регламенты, стандарты, положения по информационной безопасности).

  • Архитекторы или проектировщики разрабатывают проектную документацию и определяют технические меры защиты.

  • Инженеры проводят пусконаладочные работы.

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

Руководители проекта со стороны интегратора и заказчика должны согласовать все организационные вопросы на старте проекта: разработать план-график и ресурсный план, чтобы определить, какой объем работ реализует интегратор, какой — заказчик. Когда есть план-график, проект становится структурированным и управляемым. Кроме того, на старте проекта должны быть определены способы взаимодействия (через ВКС или с выездами на площадку) между исполнителями со стороны интегратора и исполнителями со стороны заказчика. Все это помогает заранее спланировать ресурсы и время реализации проекта.

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

В отдельных случаях вендор может быть исполнителем или соисполнителем проекта — и выделять своих архитекторов, проектировщиков и инженеров. В Positive Technologies для таких задач есть департамент инжиниринга, где работают архитекторы, проектировщики и инженеры. Услуги при этом оказываются в рамках различных моделей взаимодействия: это и консалтинг, и работа по договору, и профессиональные сервисы (по сертификату).

Определиться с участниками проекта обычно несложно. Что касается самого процесса реализации проекта, то я сторонник декомпозиции: проект разбивается на этапы, этапы — на подэтапы, подэтапы — на задачи. Так становится понятно, за что браться и в какой последовательности: мамонта едят по частям.

Этапы

76a604c65f416ece665c8f800bb83b2c.png

Этап 0. Пилотирование

Я указал этот этап под номером 0, поскольку это не полноценный этап проекта, это скорее пресейл. И на мой взгляд — не самый эффективный. Со мной многие не согласятся, и, когда я выступал с докладом на Positive Hack Days Fest, на эту тему было больше всего вопросов. Когда я работал в интеграторе, у меня практически не было пилотов — интегратору это невыгодно. Работая в Positive Technologies, я поучаствовал в большом количестве пилотов и часто сталкивался с ситуацией, когда пилот проводится «для галочки»  —, но не ради продажи. При этом бывают и проекты, где от пилота не уйти: его реализация может быть прописана во внутренних нормативных актах заказчика.

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

Этап 1. Разработка технического задания

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

Ну и желательно, чтобы требования были реализуемы. Поэтому перед стартом проекта важно изучить возможности продуктов и понять, какой из них вам больше подходит и какие требования указывать. Но если очень нужна какая-то функциональность, не реализованная в продукте, можно попробовать запросить и ее: на моей практике были случаи, когда либо вендор дорабатывал продукт, либо интегратор придумывал work around («костыли»), чтобы реализовать конкретную потребность.

Вообще, команды, которые реализуют проекты, обычно очень изобретательны и делают порой гениальные вещи. Как правило, это скрипты, нестандартные интеграции различных продуктов, доработка кода (если продукт с открытым исходным кодом). Но после проведения испытаний оказывается, что сопровождать такие «костыли» некому и никто не готов взять их на поддержку. Гениальное решение умирает, в лучшем случае попадает в бэклог разработки вендора с перспективой когда-нибудь появиться в продукте.

Когда техническое задание подготовлено, проводится конкурсная процедура, определяется победитель — интегратор. Интегратор приступает к работе и начинает с обследования.

Этап 2. Обследование

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

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

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

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

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

Этап 3. Адаптация технического задания

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

У меня не было ни одного проекта, где этот этап был бы не нужен. Обследование и моделирование угроз всегда вносят корректировки в проект.

Этап 4. Проектирование и разработка организационно-распорядительной документации

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

В обсуждении документации хотелось бы еще раз вернуться к этапу разработки технического задания (этапу 1). Не надо вписывать в ТЗ весь комплект документов в соответствии с ГОСТ по разработке автоматизированных систем или по разработке автоматизированных систем в защищенном исполнении. При составлении ТЗ важно понять, какие документы действительно нужны и будут приносить пользу. Очень странно иногда видеть в ТЗ по системе защиты документ «Перечень входных и выходных сигналов», который вообще никак не применим к создаваемой системе.

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

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

Ну и никогда не нужно забывать, что безопасность — это совокупность технических и организационных мер защиты. Организационно-распорядительную документацию нужно разрабатывать не только, когда этого требует какой-то конкретный ФЗ или приказ ФСТЭК, но в любых других случаях. Регламенты, приказы — это все действенные инструменты специалиста по информационной безопасности.

Этап 5. Поставка программных и технических средств

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

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

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

Этап 6. Внедрение

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

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

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

Завершением любого внедрения являются:

  1. Предварительные испытания — проверка системы на корректность функционирования в инфраструктуре заказчика.

  2. Опытная эксплуатация — проверка работы системы перед ее приемкой в постоянную эксплуатацию.

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

  4. Аттестационные испытания — проверка системы на соответствие требованиям нормативных документов, в случае если это предусмотрено в ТЗ.

Этап 7. Эксплуатация

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

Система — это живой организм, поэтому ее нужно эксплуатировать, постоянно модернизировать, а также своевременно закупать оборудование и обновлять программное обеспечение.

И небольшое резюме

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

Таким образом, основные этапы проекта:

  1. Часто пилот — это лишнее.

  2. Требования к системе должны быть выполнимы.

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

  4. Документация по системе должна поддерживаться в актуальном состоянии.

  5. Учитывайте сроки поставки на этапе планирования.

  6. Не кладите систему на полку, используйте ее.

  7. Система должна быть живой и постоянно улучшаться.

9020e40a950999974cc99e3a036f7783.jpgАндрей Скрипкин

Главный архитектор комплексных проектов, Positive Technologies

© Habrahabr.ru