8 августа, 2017, BIS Journal №3(26)/2017

Конвейер кибербезопасности для 200 ИТ-проектов в год


Бодрик Александр

заместитель генерального директора, CISA, ITIL Expert (ANGARA Professional Assistance)

Заметки безопасника

ИТ, ИБ и бизнес обычно разделяют не так много мыслей, но одну мы вспоминаем практически всегда: кибербезопасность должна быть экономически эффективной! И дальше: максимальная эффективность возможна лишь при «встроенной» кибербезопасности, когда риски и контроли кибербезопасности анализируются, адаптируются и реализуются как часть архитектуры еще до перевода разрабатываемых или внедряемых систем в production – до загрузки бизнес-данных и начала предоставления сервисов пользователям системы.

Однако встраивание кибербезопасности в ИТ-проекты потребует выстраивания конвейера контроля и разработки архитектуры безопасности ИТ-проектов, иначе или ИТ-проекты затормозят (в отдельных крупных организациях очередь ИТ-проектов на контроль достигает полугода) и бизнес недополучит прибыль, или безопасность из проектов выбросят, чтобы не мешала трансформировать бизнес.

Несколько лет назад, работая в центре компетенции ИБ нефтегазовой корпорации, я построил конвейер контроля кибербезопасности для ИТ-проектов, и добился приличных даже по сегодняшним меркам результатов: SLA отклика на запрос на проверку – 8 рабочих часов, SLA проверки – 3 дня, SLA отклика на запрос по осмечиванию архитектурного участия – 4 часа и отсутствие претензий по всем проектам с архитектурным участием. При этом на поток в 200 проектов приходилось всего 2 человека на функцию контроля, а функция разработки архитектуры была распределена по проектам и не создавала нагрузки на бюджет блока безопасности компании.

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

КОНТЕКСТ 

Существенным компонентом успеха любого проекта всегда будет среда, в которой он реализуется. В моем конкретном случае компания была крупная, с развитыми бизнес-процессами, а значит существовал ряд значимых предпосылок:
  1. Контрольные точки. По всему циклу реализации ИТ-проектов уже было 2 контрольные точки – без согласования CISO было невозможно утвердить архитектурный план системы, а также сдать систему в промышленную эксплуатацию. Помогало то, что в моем ведении находился сервис контроля ИТ-изменений, а значит, без согласованной документации не открывались сетевые порты. Обойти контрольные точки кибербезопасности было тяжело – потребовались бы де-факто усилия уровня Исполнительного директора – члена правления (одного из акционеров).
  2. Владение активами и P&L-ответственность. В компании была внедрена концепция владения ИТ-активами бизнес-подразделениями, и те уже привыкли что именно они отвечают за состояние своих активов, в том числе и за принятие и финансирование решений по обеспечению их кибербезопасности.
  3. Централизованные интерфейсы в ИТ. Компания реализовывала большую часть проектов централизованно, имела коммуникационные инструменты для донесения позиции кибербезопасности на все уровни проектной деятельности – спонсоры, ИТ-директора бизнес-направлений (Upstream, Downstream, Finance, Services), руководители проектов – все, кто выступал представителем внутренних клиентов и бюджетировал участие безопасности на стадии создания архитектуры.
  4. Компетентность персонала. Создающая конвейер группа службы кибербезопасности была опытной (8+ лет), она хорошо понимала корпоративные процессы, предметную область ИБ и в частности лучшие практики по созданию масштабируемых процессов ИБ.
НАШИ ДЕЙСТВИЯ НА СТАРТОВОМ ЭТАПЕ 

Мы начали с создания основы – списка требований безопасности к ИТ-проектам. Такой чек-лист стал де-факто стандартом качества операционного контроля, позволил нормировать трудозатраты на контроль и обещать руководителям проектов и бизнес-заказчикам средние сроки рассмотрения документов.

Естественно, мы не ограничились чек-листом. Проверка также включала в себя анализ рисков, который выполнялся тем тщательнее, чем понятнее были драйверы риска кибербезопасности. Например, доступность из сети Интернет и автоматизация критичного процесса (движение углеводородов, «цифровое месторождение», закупки и МТО, финансовые процессы и т.п.).

По итогам проверки архитектурного плана каждый проект получал требования к безопасности и должен был их реализовать. Для критичных систем требования могли включать тест на проникновение либо аудит фрод-рисков. Для решения этих задач привлекалась внешняя экспертная компания, но иногда делали и сами. Для входящих в контур формирования финансовой отчетности т.н. материальных систем к проверке привлекались специалисты Департамента внутреннего контроля – чтобы удостовериться в правильном формировании матрицы доступа, корректной идентификации и управлении риском конфликта полномочий (SoD – Segregation of Duties).

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

Возвращаясь к стартовому этапу – после разработки чек-листа и внедрения в технический проект дополнительной контрольной точки был создан специальный почтовый ящик (вида sec-projects@oilcompany.com), проведены обучение сотрудников проектного офиса новому процессу и последующая рассылка необходимых материалов руководителям проектов.

ПЕРВЫЕ РЕЗУЛЬТАТЫ 

Руководители проектов приняли перемены благосклонно. Сняв нагрузку по контролю проектов с CISO, мы сразу сократили сроки анализа на порядок (с недель-дней до дней-часов), а также разработали стандарт архитектурного участия кибербезопасности в проектах.

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

В случае невозможности реализации был вариант – подписать протокол принятия риска, но желающих подписывать такие протоколы среди бизнес-заказчиков не находилось. За первые полгода был один случай подписания дорожной карты по развитию ИБ одной из корпоративных платформ (СЭД), так как платформа просто не интегрировалась в AD (выступавшей в виде SSO, интеграция с которой была в списке требований безопасности). Такие практики создавали канал для «выпуска пара»: безопасность не становилась тормозом для бизнеса, но проверяла риски надлежащим образом, мол, идентифицированы, учтены и контролируются.

ПОДДЕРЖИВАЮЩИЕ ИНСТРУМЕНТЫ (АРТЕФАКТЫ)

Для облегчения работы и контроля качества для специалистов сервиса контроля, руководителей проектов и проектных групп был создан набор из 7 инструментов (артефактов):
  1. Таблица требований безопасности.
  2. Контрольный лист безопасности проекта (создавался для каждого проекта).
  3. Опросник для определения критичности системы по параметрам конфиденциальности, целостности и доступности.
  4. Шаблоны документов – архитектурного плана, технического проекта и заявки на поддержку.
  5. Контрольные практики в документах – матрица ролей, RPO/RPO, матрица взятия на поддержку компонентов системы и др.
  6. Концепция контроля – каким видам контроля подвергаются системы в зависимости от интегральной степени их критичности (документарный контроль, дополнительный аудит и т.п.).
  7. База знаний сервиса контроля (централизованное хранение проверенной и проверяемой проектной документации).
РАЗВИТИЕ МЕТОДОЛОГИИ 

Параллельно с быстрым запуском сервиса контроля (на все про все ушло две недели) был запущен проект по комплексному редизайну сервиса контроля и контрольной функции ИБ в отношении ИТ-проектов в целом. В рамках проекта мы проделали много работы, в том числе:
  1. Пересмотрели шаблоны документов – архитектурного плана, технического проекта и заявки на обслуживание.
  2. Разделили проекты на типы (внедрение, тираж и модернизация) и виды (консалтинг, АСУ ТП, бизнес-приложения и инфраструктура).
  3. Проанализировали лучшие мировые практики (ISO 27k, PCI DSS, PA DSS, NIST 800-53, Australian Information Security Manual, СТО БР ИББС) и практики схожих по масштабу деятельности глобальных нефтегазовых компаний (2 200+ контролей).
  4. Сформировали матрицу контролей безопасности в зависимости от вида и типа проектов.
  5. Разработали презентацию для обучения заинтересованных сторон.
Оглядываясь назад, я понимаю, что 2 200+ контролей могут показаться избыточными (тем более, что добрая половина из них повторяла друг друга), но такова была культура организации. Подход best enough («и так сойдет») не приветствовался, организация ставила себе задачу вырасти в мирового лидера нефтегазового комплекса и применяла самые современные и совершенные практики и системы.

НЕОЖИДАННЫЕ РЕЗУЛЬТАТЫ 

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

А во-вторых, попавшие под контроль руководители проектов («мыши») не единожды рекомендовали руководителя сервиса контроля («кошку») на работу в другие организации, в том числе и в те, где сами работали.

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