Кто одолеет проект: сказ о трех богатырях на новый лад
Всем привет! Меня зовут Андрей Скрипкин. Еще когда был студентом, понял, что хочу заниматься информационной безопасностью — увлек брат. Уже прошло больше 15 лет, а интерес к профессии только растет. И даже когда казалось, что, работая в различных интеграторах по информационной безопасности и попробовав себя в роли инженера, проектировщика, архитектора, руководителя групп инженеров и проектировщиков, видел уже все, мир информационной безопасности подкидывает что-то новое и дает возможность учиться дальше и узнавать что-то новое. Сейчас уже два года работаю в Positive Technologies в департаменте инжиниринга: реализую проекты на базе продуктов PT. И это, с одной стороны, похоже на мой предыдущий опыт работы в интеграторах, а с другой — это новый опыт, новые подходы к ведению проектов и новый уровень экспертизы.
Пожалуй, главное, что я понял о проектах за время работы: самое важное — это люди. Люди, которые реализуют проект. И от того, как эти люди буду взаимодействовать друг с другом, зависит успех всего проекта. Хороший инженер всегда «приручит» любую технику и победит любые проблемы с программным обеспечением —, а хороший менеджер всегда найдет компромисс в спорных ситуациях.
В этой статья я хочу поделиться своим опытом: рассказать, как продуктивно реализовывать проекты и выстраивать отношения между участниками проекта — заказчиком, интегратором и вендором.
Участники проекта
Ключевую роль в любом проекте всегда играет заказчик. И самое важное для самого заказчика — чтобы ему был нужен этот проект, чтобы люди, ответственные за проект, понимали, зачем они это делают и какие задачи проект должен решить. Цель проекта — не «сделать для галочки», а получить реальную пользу от результата.
Я очень часто сталкивался с ситуациями, когда после завершения пусконаладочных работ и проведения приемо-сдаточных испытаний система либо вообще выключалась, либо не эксплуатировалась. А потом все удивлялись:, а почему же произошел инцидент, и главное — что теперь делать? Сталкивался и с ситуациями, когда программное обеспечение было куплено, а внедрение выполнено не было. А потом происходил инцидент, и приходилось отключать всю ИТ-инфраструктуру от интернета и срочно искать, кто может внедрить систему за один день. Как исполнителю, мне всегда грустно, когда такое происходит.
Но в большинстве проектов я видел, как горят глаза у руководителя, который сам решил поработать с DLP-системой, как зауважала SIEM-систему служба ИТ, которая нашла майнер в сети с его помощью. Видел радость специалистов по ИБ, которые смогли предотвратить инцидент.
Используйте системы защиты. Не кладите их на полку.
А еще в реализации проекта со стороны заказчика всегда участвует команда, состоящая из разных людей, из разных подразделений. Это и руководители, и специалисты по ИТ, и отдел ИБ. И успех будет тогда, когда каждый из них поймет, зачем нужен проект и какова его роль в нем. Часто бывает так, что службы ИТ и ИБ не ладят между собой — здесь важно искать компромисс и общую выгоду от проекта, чтобы каждый участник был заинтересован в его реализации.
Интегратор — это сформированная экспертная команда. В нее должны входить руководитель проекта, консультанты по информационной безопасности, архитекторы, проектировщики и инженеры.
От руководителя проекта зависит вся организационная часть: план, графики, соблюдение сроков, решение административных вопросов. Руководитель проекта должен быть менеджером по задачам инженеров и проектировщиков, иначе работа будет растягиваться и выполняться не очень качественно.
Остальные задачи распределяются следующим образом:
Консультанты по информационной безопасности анализируют процессы в организации заказчика, моделируют угрозы безопасности информации, разрабатывают организационные меры защиты (политики, регламенты, стандарты, положения по информационной безопасности).
Архитекторы или проектировщики разрабатывают проектную документацию и определяют технические меры защиты.
Инженеры проводят пусконаладочные работы.
Такое разделение ролей, по моему опыту, наиболее сбалансированно (при этом нужно учесть, что проектировщики и инженеры должны иметь опыт работы с продуктами, на базе которых строится система защиты).
Руководители проекта со стороны интегратора и заказчика должны согласовать все организационные вопросы на старте проекта: разработать план-график и ресурсный план, чтобы определить, какой объем работ реализует интегратор, какой — заказчик. Когда есть план-график, проект становится структурированным и управляемым. Кроме того, на старте проекта должны быть определены способы взаимодействия (через ВКС или с выездами на площадку) между исполнителями со стороны интегратора и исполнителями со стороны заказчика. Все это помогает заранее спланировать ресурсы и время реализации проекта.
Вендор — участник проекта, который в первую очередь поставляет программное или программно-аппаратное решение, на базе которого будет строиться будущая система при реализации проекта. Также у вендора всегда есть техническая поддержка, и ей нужно пользоваться. Если у интегратора или заказчика на каком-то из этапов реализации проекта или в процессе эксплуатации возникает проблема, он может обратиться к вендору и попросить помощи.
В отдельных случаях вендор может быть исполнителем или соисполнителем проекта — и выделять своих архитекторов, проектировщиков и инженеров. В Positive Technologies для таких задач есть департамент инжиниринга, где работают архитекторы, проектировщики и инженеры. Услуги при этом оказываются в рамках различных моделей взаимодействия: это и консалтинг, и работа по договору, и профессиональные сервисы (по сертификату).
Определиться с участниками проекта обычно несложно. Что касается самого процесса реализации проекта, то я сторонник декомпозиции: проект разбивается на этапы, этапы — на подэтапы, подэтапы — на задачи. Так становится понятно, за что браться и в какой последовательности: мамонта едят по частям.
Этапы
Этап 0. Пилотирование
Я указал этот этап под номером 0, поскольку это не полноценный этап проекта, это скорее пресейл. И на мой взгляд — не самый эффективный. Со мной многие не согласятся, и, когда я выступал с докладом на Positive Hack Days Fest, на эту тему было больше всего вопросов. Когда я работал в интеграторе, у меня практически не было пилотов — интегратору это невыгодно. Работая в Positive Technologies, я поучаствовал в большом количестве пилотов и часто сталкивался с ситуацией, когда пилот проводится «для галочки» —, но не ради продажи. При этом бывают и проекты, где от пилота не уйти: его реализация может быть прописана во внутренних нормативных актах заказчика.
При проведении пилота должны быть четко определены его цели и задачи: только так можно понять, а нужен ли он вообще. Кроме того, нужно понимать, что пилот — это временные (а значит, и денежные) затраты не только для интегратора и вендора, но и для заказчика. И, возможно, эффективнее будет провести демонстрацию (в том числе на стенде), предложить обучение или организовать «референсный» визит в компанию, где уже используется продукт.
Этап 1. Разработка технического задания
Данный этап выполняет в первую очередь заказчик, формулируя запрос и определяя, что он хочет. Это один из самых важных этапов: помимо того, что по составленному документу будет проводиться закупочная процедура и впоследствии приемка системы в эксплуатацию, правильно поставленная задача и четко сформированные требования — это половина успеха любого проекта.
Ну и желательно, чтобы требования были реализуемы. Поэтому перед стартом проекта важно изучить возможности продуктов и понять, какой из них вам больше подходит и какие требования указывать. Но если очень нужна какая-то функциональность, не реализованная в продукте, можно попробовать запросить и ее: на моей практике были случаи, когда либо вендор дорабатывал продукт, либо интегратор придумывал work around («костыли»), чтобы реализовать конкретную потребность.
Вообще, команды, которые реализуют проекты, обычно очень изобретательны и делают порой гениальные вещи. Как правило, это скрипты, нестандартные интеграции различных продуктов, доработка кода (если продукт с открытым исходным кодом). Но после проведения испытаний оказывается, что сопровождать такие «костыли» некому и никто не готов взять их на поддержку. Гениальное решение умирает, в лучшем случае попадает в бэклог разработки вендора с перспективой когда-нибудь появиться в продукте.
Когда техническое задание подготовлено, проводится конкурсная процедура, определяется победитель — интегратор. Интегратор приступает к работе и начинает с обследования.
Этап 2. Обследование
В этапе участвует заказчик и исполнитель (может быть как интегратор, так и вендор, если внедрение производится командой вендора). Здесь важно, чтобы исполнитель максимально полно обозначил информацию, которая понадобится в рамках проекта, а заказчик — максимально полно и честно ее предоставил.
Чтобы сэкономить время всех участников, я всегда стараюсь большую часть вопросов задать в опросных листах. Сначала составляется общий опросный лист, чтобы получить общее представление об инфраструктуре ИТ и ИБ в организации заказчика, затем на основе полученной информации готовятся уточняющие опросные листы по каждому из направлений. И если какую-то информацию не удалось добыть с помощью опросников, нужно переходить к интервьюированию. Такая схема ни разу не давала сбоя, но она может занимать разное время — в зависимости от готовности заказчика к вопросам.
Для меня всегда самое главное в обследовании — получить от заказчика схему сети. Когда у тебя есть перед глазами картинка, зачастую и вопросы остаются только уточняющие. Но я нередко сталкивался с тем, что у заказчика готовой схемы не оказывалось или ее детализация была недостаточной. В этом случае самое эффективное — это сесть со специалистом по ИТ или ИБ рядом и вместе на бумажке нарисовать схему, а затем перевести ее в цифровой формат и согласовать с заказчиком.
Остановлюсь на еще одном важном моменте. Часто бывает, что исполнитель берет стандартный опросный лист и отправляет его заказчику — без анализа его запроса и без персонализации. А потом удивляется, что заказчик не понимает, зачем у него спрашивают модели маршрутизаторов, если производится внедрение антивируса. Все опросники должны быть адаптированы под конкретный проект и под конкретного заказчика. Нужно уважать время заказчика, тогда и заказчик будет предоставлять более точную и полную информацию.
После обследования всегда появляются новые вводные, которые кардинально влияют на реализацию проекта. И после обследования, как правило, необходимо составить еще одно техническое задание, которое конкретизирует требования, указанные заказчиком в техническом задании на этапе 1.
Этап 3. Адаптация технического задания
Этот этап — в первую очередь работа интегратора. На основании проведенного обследования интегратор классифицирует информационные системы заказчика, определяет актуальные угрозы безопасности информации и конкретизирует требования, указанные в исходном техническом задании.
У меня не было ни одного проекта, где этот этап был бы не нужен. Обследование и моделирование угроз всегда вносят корректировки в проект.
Этап 4. Проектирование и разработка организационно-распорядительной документации
Когда все требования определены и зафиксированы, необходимо подготовить всю документальную обвязку проекта. От того, насколько хорошо написана документация по проекту, зависит то, насколько быстро и качественно будет проведено внедрение.
В обсуждении документации хотелось бы еще раз вернуться к этапу разработки технического задания (этапу 1). Не надо вписывать в ТЗ весь комплект документов в соответствии с ГОСТ по разработке автоматизированных систем или по разработке автоматизированных систем в защищенном исполнении. При составлении ТЗ важно понять, какие документы действительно нужны и будут приносить пользу. Очень странно иногда видеть в ТЗ по системе защиты документ «Перечень входных и выходных сигналов», который вообще никак не применим к создаваемой системе.
Самые важные документы, на мой взгляд, — это различные схемы, отражающие технические меры защиты: спецификация (или ведомость покупных изделий), пояснительная записка, программа и методика испытаний, а также рабочая документация, отражающая параметры и размещение создаваемой системы.
Очень важно иметь комплект проектной документации и поддерживать его в актуальном состоянии, чтобы при смене специалистов или команды по ИБ не получилось так, что никто не знает, что внедрено, зачем и как оно работает.
Ну и никогда не нужно забывать, что безопасность — это совокупность технических и организационных мер защиты. Организационно-распорядительную документацию нужно разрабатывать не только, когда этого требует какой-то конкретный ФЗ или приказ ФСТЭК, но в любых других случаях. Регламенты, приказы — это все действенные инструменты специалиста по информационной безопасности.
Этап 5. Поставка программных и технических средств
На этом этапе исполнитель поставляет программные и технические средства, разработанные вендором, а заказчик ставит их на баланс.
Я выделил поставку в отдельный этап, потому что ее всегда нужно учитывать при планировании работ. В отдельных случаях поставка может растянуться на полгода, и состав поставляемых средств нужно определять как можно раньше, но не в ущерб качеству проекта. Как правило, закупочную спецификацию можно подготовить на ранних этапах проектирования (этап 4).
Как только поставка программных и технических средств будет завершена, можно приступать к внедрению.
Этап 6. Внедрение
Когда я только начинал работать проектировщиком, мой начальник (в отделе проектирования) на какой-то общей встрече департамента ИБ сказал, что инженеры внедрения — это самые важные люди на проекте. В обследовании бывают ошибки, в проектировании бывают, а во внедрении ошибок быть не может. Инженеры всегда на передовой.
У меня не было ни одного проекта, в который не приходилось бы вносить изменения по результатам внедрения. И это на самом деле нормальная история, потому что на этапе внедрения всегда обнаруживаются подводные камни: все инфраструктуры разные и всего учесть невозможно.
Инженеров надо ценить, беречь и уважать — как со стороны заказчика, так и со стороны исполнителя. От их слаженной работы в первую очередь зависит успех проекта.
Завершением любого внедрения являются:
Предварительные испытания — проверка системы на корректность функционирования в инфраструктуре заказчика.
Опытная эксплуатация — проверка работы системы перед ее приемкой в постоянную эксплуатацию.
Приемочные испытания — проверка на соответствие требованиям ТЗ либо требованиям методики испытаний (чек-листа, где указывается «прошел» или «не прошел проверку»); также могут проводиться в формате киберучений (приходит команда красных хакеров и пытается вас ломать, это довольно эффективный метод проверки).
Аттестационные испытания — проверка системы на соответствие требованиям нормативных документов, в случае если это предусмотрено в ТЗ.
Этап 7. Эксплуатация
Заказчик никогда не остается один на один с продуктом: у него всегда есть техническая поддержка вендора. Поэтому, хотя эксплуатация уже и не является частью проекта, я выделил ее как отдельный этап существования системы.
Система — это живой организм, поэтому ее нужно эксплуатировать, постоянно модернизировать, а также своевременно закупать оборудование и обновлять программное обеспечение.
И небольшое резюме
Для меня самое важное в любом проекте — это люди, которые принимают в нем участие, а также их умение понимать друг друга, дополнять друг друга, умение работать в команде. Часто бывает так, что после большого проекта люди, которые до этого друг друга не знали, становятся хорошими друзьями и продолжают общаться вне проекта. В любом проекте встречаются технические, организационные, политические сложности, но умение договариваться решает любые из этих проблем.
Таким образом, основные этапы проекта:
Часто пилот — это лишнее.
Требования к системе должны быть выполнимы.
После обследования требования должны быть адаптированы под систему заказчика.
Документация по системе должна поддерживаться в актуальном состоянии.
Учитывайте сроки поставки на этапе планирования.
Не кладите систему на полку, используйте ее.
Система должна быть живой и постоянно улучшаться.
Андрей СкрипкинГлавный архитектор комплексных проектов, Positive Technologies
