Конвейер кибербезопасности для 200 ИТ-проектов в год
ИТ, ИБ и бизнес обычно разделяют не так много мыслей, но одну мы вспоминаем практически всегда: кибербезопасность должна быть экономически эффективной! И дальше: максимальная эффективность возможна лишь при «встроенной» кибербезопасности, когда риски и контроли кибербезопасности анализируются, адаптируются и реализуются как часть архитектуры еще до перевода разрабатываемых или внедряемых систем в production – до загрузки бизнес-данных и начала предоставления сервисов пользователям системы.
Однако встраивание кибербезопасности в ИТ-проекты потребует выстраивания конвейера контроля и разработки архитектуры безопасности ИТ-проектов, иначе или ИТ-проекты затормозят (в отдельных крупных организациях очередь ИТ-проектов на контроль достигает полугода) и бизнес недополучит прибыль, или безопасность из проектов выбросят, чтобы не мешала трансформировать бизнес.
Несколько лет назад, работая в центре компетенции ИБ нефтегазовой корпорации, я построил конвейер контроля кибербезопасности для ИТ-проектов, и добился приличных даже по сегодняшним меркам результатов: SLA отклика на запрос на проверку – 8 рабочих часов, SLA проверки – 3 дня, SLA отклика на запрос по осмечиванию архитектурного участия – 4 часа и отсутствие претензий по всем проектам с архитектурным участием. При этом на поток в 200 проектов приходилось всего 2 человека на функцию контроля, а функция разработки архитектуры была распределена по проектам и не создавала нагрузки на бюджет блока безопасности компании.
После этого я стал обращать внимание, как строят подобные конвейеры коллеги в других компаниях, информация накапливалась, ко мне стали обращаться за консультациями, и я решил формализовать этот опыт, изложив его в кратком виде.
КОНТЕКСТ
Существенным компонентом успеха любого проекта всегда будет среда, в которой он реализуется. В моем конкретном случае компания была крупная, с развитыми бизнес-процессами, а значит существовал ряд значимых предпосылок:
Мы начали с создания основы – списка требований безопасности к ИТ-проектам. Такой чек-лист стал де-факто стандартом качества операционного контроля, позволил нормировать трудозатраты на контроль и обещать руководителям проектов и бизнес-заказчикам средние сроки рассмотрения документов.
Естественно, мы не ограничились чек-листом. Проверка также включала в себя анализ рисков, который выполнялся тем тщательнее, чем понятнее были драйверы риска кибербезопасности. Например, доступность из сети Интернет и автоматизация критичного процесса (движение углеводородов, «цифровое месторождение», закупки и МТО, финансовые процессы и т.п.).
По итогам проверки архитектурного плана каждый проект получал требования к безопасности и должен был их реализовать. Для критичных систем требования могли включать тест на проникновение либо аудит фрод-рисков. Для решения этих задач привлекалась внешняя экспертная компания, но иногда делали и сами. Для входящих в контур формирования финансовой отчетности т.н. материальных систем к проверке привлекались специалисты Департамента внутреннего контроля – чтобы удостовериться в правильном формировании матрицы доступа, корректной идентификации и управлении риском конфликта полномочий (SoD – Segregation of Duties).
На каждом из последующих этапов реализации проекта производился контроль проектирования и реализации требований, в том числе проверка проведения тестов на проникновение для бизнес-критичных, а также доступных из интернета, веб-приложений.
Возвращаясь к стартовому этапу – после разработки чек-листа и внедрения в технический проект дополнительной контрольной точки был создан специальный почтовый ящик (вида sec-projects@oilcompany.com), проведены обучение сотрудников проектного офиса новому процессу и последующая рассылка необходимых материалов руководителям проектов.
ПЕРВЫЕ РЕЗУЛЬТАТЫ
Руководители проектов приняли перемены благосклонно. Сняв нагрузку по контролю проектов с CISO, мы сразу сократили сроки анализа на порядок (с недель-дней до дней-часов), а также разработали стандарт архитектурного участия кибербезопасности в проектах.
По прошествии месяца руководители проектов стали все чаще обращаться за оценками стоимости архитектурного участия безопасности в проекте, хотя часть неплохо спроектировала и реализовала требования силами подрядчиков или внутренних служб (проекты тиражей).
В случае невозможности реализации был вариант – подписать протокол принятия риска, но желающих подписывать такие протоколы среди бизнес-заказчиков не находилось. За первые полгода был один случай подписания дорожной карты по развитию ИБ одной из корпоративных платформ (СЭД), так как платформа просто не интегрировалась в AD (выступавшей в виде SSO, интеграция с которой была в списке требований безопасности). Такие практики создавали канал для «выпуска пара»: безопасность не становилась тормозом для бизнеса, но проверяла риски надлежащим образом, мол, идентифицированы, учтены и контролируются.
ПОДДЕРЖИВАЮЩИЕ ИНСТРУМЕНТЫ (АРТЕФАКТЫ)
Для облегчения работы и контроля качества для специалистов сервиса контроля, руководителей проектов и проектных групп был создан набор из 7 инструментов (артефактов):
Параллельно с быстрым запуском сервиса контроля (на все про все ушло две недели) был запущен проект по комплексному редизайну сервиса контроля и контрольной функции ИБ в отношении ИТ-проектов в целом. В рамках проекта мы проделали много работы, в том числе:
НЕОЖИДАННЫЕ РЕЗУЛЬТАТЫ
Качество внедрённых процессов и артефактов получило признание обеих ключевых сторон процесса. Во-первых, практически все непосредственные участники получили или повышение (двое стали начальниками подразделений в центральном аппарате, один директором по развитию бизнеса ИТ-компании), или существенный рост заработной платы (экспертный путь развития).
А во-вторых, попавшие под контроль руководители проектов («мыши») не единожды рекомендовали руководителя сервиса контроля («кошку») на работу в другие организации, в том числе и в те, где сами работали.
Вероятно, значительная часть проблем и недопонимания в коммуникациях между ИБ, ИТ и бизнесом в том, что ИТ и бизнес просто не понимают, что для них делает безопасность. Деятельность по кибербезопасности для них непрозрачна и непрогнозируема. Может быть, это главный урок, который я вынес из этого проекта.
Однако встраивание кибербезопасности в ИТ-проекты потребует выстраивания конвейера контроля и разработки архитектуры безопасности ИТ-проектов, иначе или ИТ-проекты затормозят (в отдельных крупных организациях очередь ИТ-проектов на контроль достигает полугода) и бизнес недополучит прибыль, или безопасность из проектов выбросят, чтобы не мешала трансформировать бизнес.
Несколько лет назад, работая в центре компетенции ИБ нефтегазовой корпорации, я построил конвейер контроля кибербезопасности для ИТ-проектов, и добился приличных даже по сегодняшним меркам результатов: SLA отклика на запрос на проверку – 8 рабочих часов, SLA проверки – 3 дня, SLA отклика на запрос по осмечиванию архитектурного участия – 4 часа и отсутствие претензий по всем проектам с архитектурным участием. При этом на поток в 200 проектов приходилось всего 2 человека на функцию контроля, а функция разработки архитектуры была распределена по проектам и не создавала нагрузки на бюджет блока безопасности компании.
После этого я стал обращать внимание, как строят подобные конвейеры коллеги в других компаниях, информация накапливалась, ко мне стали обращаться за консультациями, и я решил формализовать этот опыт, изложив его в кратком виде.
КОНТЕКСТ
Существенным компонентом успеха любого проекта всегда будет среда, в которой он реализуется. В моем конкретном случае компания была крупная, с развитыми бизнес-процессами, а значит существовал ряд значимых предпосылок:
- Контрольные точки. По всему циклу реализации ИТ-проектов уже было 2 контрольные точки – без согласования CISO было невозможно утвердить архитектурный план системы, а также сдать систему в промышленную эксплуатацию. Помогало то, что в моем ведении находился сервис контроля ИТ-изменений, а значит, без согласованной документации не открывались сетевые порты. Обойти контрольные точки кибербезопасности было тяжело – потребовались бы де-факто усилия уровня Исполнительного директора – члена правления (одного из акционеров).
- Владение активами и P&L-ответственность. В компании была внедрена концепция владения ИТ-активами бизнес-подразделениями, и те уже привыкли что именно они отвечают за состояние своих активов, в том числе и за принятие и финансирование решений по обеспечению их кибербезопасности.
- Централизованные интерфейсы в ИТ. Компания реализовывала большую часть проектов централизованно, имела коммуникационные инструменты для донесения позиции кибербезопасности на все уровни проектной деятельности – спонсоры, ИТ-директора бизнес-направлений (Upstream, Downstream, Finance, Services), руководители проектов – все, кто выступал представителем внутренних клиентов и бюджетировал участие безопасности на стадии создания архитектуры.
- Компетентность персонала. Создающая конвейер группа службы кибербезопасности была опытной (8+ лет), она хорошо понимала корпоративные процессы, предметную область ИБ и в частности лучшие практики по созданию масштабируемых процессов ИБ.
Мы начали с создания основы – списка требований безопасности к ИТ-проектам. Такой чек-лист стал де-факто стандартом качества операционного контроля, позволил нормировать трудозатраты на контроль и обещать руководителям проектов и бизнес-заказчикам средние сроки рассмотрения документов.
Естественно, мы не ограничились чек-листом. Проверка также включала в себя анализ рисков, который выполнялся тем тщательнее, чем понятнее были драйверы риска кибербезопасности. Например, доступность из сети Интернет и автоматизация критичного процесса (движение углеводородов, «цифровое месторождение», закупки и МТО, финансовые процессы и т.п.).
По итогам проверки архитектурного плана каждый проект получал требования к безопасности и должен был их реализовать. Для критичных систем требования могли включать тест на проникновение либо аудит фрод-рисков. Для решения этих задач привлекалась внешняя экспертная компания, но иногда делали и сами. Для входящих в контур формирования финансовой отчетности т.н. материальных систем к проверке привлекались специалисты Департамента внутреннего контроля – чтобы удостовериться в правильном формировании матрицы доступа, корректной идентификации и управлении риском конфликта полномочий (SoD – Segregation of Duties).
На каждом из последующих этапов реализации проекта производился контроль проектирования и реализации требований, в том числе проверка проведения тестов на проникновение для бизнес-критичных, а также доступных из интернета, веб-приложений.
Возвращаясь к стартовому этапу – после разработки чек-листа и внедрения в технический проект дополнительной контрольной точки был создан специальный почтовый ящик (вида sec-projects@oilcompany.com), проведены обучение сотрудников проектного офиса новому процессу и последующая рассылка необходимых материалов руководителям проектов.
ПЕРВЫЕ РЕЗУЛЬТАТЫ
Руководители проектов приняли перемены благосклонно. Сняв нагрузку по контролю проектов с CISO, мы сразу сократили сроки анализа на порядок (с недель-дней до дней-часов), а также разработали стандарт архитектурного участия кибербезопасности в проектах.
По прошествии месяца руководители проектов стали все чаще обращаться за оценками стоимости архитектурного участия безопасности в проекте, хотя часть неплохо спроектировала и реализовала требования силами подрядчиков или внутренних служб (проекты тиражей).
В случае невозможности реализации был вариант – подписать протокол принятия риска, но желающих подписывать такие протоколы среди бизнес-заказчиков не находилось. За первые полгода был один случай подписания дорожной карты по развитию ИБ одной из корпоративных платформ (СЭД), так как платформа просто не интегрировалась в AD (выступавшей в виде SSO, интеграция с которой была в списке требований безопасности). Такие практики создавали канал для «выпуска пара»: безопасность не становилась тормозом для бизнеса, но проверяла риски надлежащим образом, мол, идентифицированы, учтены и контролируются.
ПОДДЕРЖИВАЮЩИЕ ИНСТРУМЕНТЫ (АРТЕФАКТЫ)
Для облегчения работы и контроля качества для специалистов сервиса контроля, руководителей проектов и проектных групп был создан набор из 7 инструментов (артефактов):
- Таблица требований безопасности.
- Контрольный лист безопасности проекта (создавался для каждого проекта).
- Опросник для определения критичности системы по параметрам конфиденциальности, целостности и доступности.
- Шаблоны документов – архитектурного плана, технического проекта и заявки на поддержку.
- Контрольные практики в документах – матрица ролей, RPO/RPO, матрица взятия на поддержку компонентов системы и др.
- Концепция контроля – каким видам контроля подвергаются системы в зависимости от интегральной степени их критичности (документарный контроль, дополнительный аудит и т.п.).
- База знаний сервиса контроля (централизованное хранение проверенной и проверяемой проектной документации).
Параллельно с быстрым запуском сервиса контроля (на все про все ушло две недели) был запущен проект по комплексному редизайну сервиса контроля и контрольной функции ИБ в отношении ИТ-проектов в целом. В рамках проекта мы проделали много работы, в том числе:
- Пересмотрели шаблоны документов – архитектурного плана, технического проекта и заявки на обслуживание.
- Разделили проекты на типы (внедрение, тираж и модернизация) и виды (консалтинг, АСУ ТП, бизнес-приложения и инфраструктура).
- Проанализировали лучшие мировые практики (ISO 27k, PCI DSS, PA DSS, NIST 800-53, Australian Information Security Manual, СТО БР ИББС) и практики схожих по масштабу деятельности глобальных нефтегазовых компаний (2 200+ контролей).
- Сформировали матрицу контролей безопасности в зависимости от вида и типа проектов.
- Разработали презентацию для обучения заинтересованных сторон.
НЕОЖИДАННЫЕ РЕЗУЛЬТАТЫ
Качество внедрённых процессов и артефактов получило признание обеих ключевых сторон процесса. Во-первых, практически все непосредственные участники получили или повышение (двое стали начальниками подразделений в центральном аппарате, один директором по развитию бизнеса ИТ-компании), или существенный рост заработной платы (экспертный путь развития).
А во-вторых, попавшие под контроль руководители проектов («мыши») не единожды рекомендовали руководителя сервиса контроля («кошку») на работу в другие организации, в том числе и в те, где сами работали.
Вероятно, значительная часть проблем и недопонимания в коммуникациях между ИБ, ИТ и бизнесом в том, что ИТ и бизнес просто не понимают, что для них делает безопасность. Деятельность по кибербезопасности для них непрозрачна и непрогнозируема. Может быть, это главный урок, который я вынес из этого проекта.