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

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

Общие процессы

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

1. Тестирование

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

2. Поддержка

Поддержка может быть как внутренняя пользовательская, так и направленная на все тот же стек решений; но и в том, и в другом случае есть место для ИБ: пресловутый awareness и рекомендации/задачи по харденингу по итогам пентеста и работы с инцидентами.

3. Разработка и SSDLC

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

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

4. Системный анализ, системный дизайн

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

5. Управление рисками

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

6. Управление уязвимостями

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

7. Управление активами

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

8. Управление инцидентами

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

9. Управление изменениями

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

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

10. Управление конфигурациями

Данный процесс управляется точно так же, как и предыдущий, они идут в связке.

11. Патч-менеджмент

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

12. Комплаенс

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

13. BCM (business continuity management), управление процессами

Как это ни удивительно, но даже такие, казалось бы, «чисто бизнесовые» процессы содержат в себе и подпроцессы и управление активами, и работу с безопасностью, так как тестирования проводятся и для ИБ-решений в том числе. От слаженной работы двух команд зависит непрерывность бизнеса в целом.

Общие сложности

1. Коммуникация

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

2. Приоритеты

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

3. Ответственность

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

4 Экспертиза

Различный уровень экспертизы и компетенций нередко может стать причиной плохой коммуникации. Ведь если две команды говорят на разных языках и у них нет «переводчика», то как они договорятся?

5. Общение с бизнесом

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

6. Смена процессов

В принципе, очень сложно взять и начать работать по-другому. Очень сложно перестроиться, особенно там, где процесс уже отлажен и показал свою эффективность.

Пути решения

1. Объединение усилий для общих процессов

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

2. Единая стратегия от бизнеса

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

3. Обмен опытом и кадрами

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

4. Обмен технологическим стеком

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

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