Ева Беляева, Security Vision
Ранее мы обсуждали точки соприкосновения ИТ и ИБ в разрезе технических решений, сценарии их использования и обмена опытом.
Осталось подняться на уровень выше и понять, откуда в принципе начинаются все противоречия и проблематика - к процессам.
Общие процессы
Как ИТ, так и ИБ-отделы в компании могут целиком или частично отвечать за внутренние процессы компании. Некоторые из них могут быть специфическими и относиться только к одной из команд, другие же более общие и даже «бизнесовые», там зоны влияния и ответственности серые и размытые.
1. Тестирование
Апробирование любых нововведений, особенно касающихся установки новых решений любых классов, бизнес-истории (проверка надежности и восстановления) - все это проводится и той, и другой командой в разрезе собственной инфраструктуры. Иногда бывают пересечения, когда речь идет, например, о новой платформе виртуализации, новом сервисе - и тогда приходится работать совместно, а не в параллель.
2. Поддержка
Поддержка может быть, как внутренняя пользовательская, так и направленная на все тот же стек решений; но и в том, и в другом случае есть место для ИБ: пресловутый awareness и рекомендации/задачи по харденингу по итогам пентеста и работы с инцидентами.
3. Разработка и SSDLC
О том, какую роль играют безопасники в разработке, мы обсуждали в одной из наших статей ранее.
Но и о том, что разработка и любой git зачастую полагается на поддержку и администрирование от ИТ, забывать нельзя. На стыке это и является, в основном без видимых конфликтов, полноценной работой нескольких команд над одним и тем же процессом.
4. Системный анализ, системный дизайн
Бизнес говорит, как ему требуется. ИБ говорит, как эти требования выполнить с оглядкой на безопасность. И уже ИТ будет отвечать за реализацию в том или ином виде. Мы снова говорим о совместной работе, только здесь есть место для споров и различных зон ответственности - потому как у каждой команды будет свое видение и свои ресурсы для того, чтобы решать задачу.
Честно говоря, рисковики - народ отдельный, со своими правилами. Но в любом случае в каждом процессе есть этот краеугольный камень эффективности против разумности, скорости против установленных правил.
6. Управление уязвимостями
Это процесс, сложность работы с которым обусловлена тем, что за выполнение отвечает ИТ, а ставить такие задачи могут и те, и другие. И если в случае с ИТ зачастую есть какой-то четкий план или ресурсы, на стороне ИБ требования и знания о том, как приоритизировать угрозы, стоящие за уязвимостями; потребность в том, чтобы придерживаться четких сроков, ведь от этого может зависеть безопасность и работа всей компании.
Часто этот процесс ассоциируется только с ИТ, но если мы посмотрим на тот же NIST и его фазы работы с инцидентами, мы увидим, что две первые стадии отвечают за понимание того, чем ты владеешь. И именно знания об инфраструктуре, внутренних взаимосвязях, а также возможность влияния на это требуется ИБ. Это влечет за собой попытки максимально разделить возможности команд - как мы рассказывали ранее, системы управления активами могут быть у каждой команды свои и совсем не пересекаться, хотя процесс по сути общий.
8. Управление инцидентами
Хотя из самого названия следует, что такой процесс относится именно к ИБ, политиками компании очень часто предусматривается выполнение проактивных действий по реагированию только через ИТ-команду. Обусловлено ли это тем, что аналитикам нельзя это доверить, или тем, что решения, через которые такие действия реализуются, находятся в команде ИТ, неважно. Главное, что в этом процессе без совместной работы совершенно не получится сделать ничего толкового.
9. Управление изменениями
Когда речь заходит о пресловутом харденинге и постинцидентных активностях, как будто подразумевается, что ИБ говорит, а ИТ исполняет, хотя это и не всегда так.
Недостаточно сформировать и выдать рекомендации для инфраструктуры, предстоит путь защиты любых нововведений сначала для ИТ, а потом и для бизнеса.
10. Управление конфигурациями
Данный процесс управляется точно так же, как и предыдущий, они идут в связке.
11. Патч-менеджмент
В основном здесь речь может идти об уязвимостях, но иногда это связано и с процессами разработки - найденные в процессе тестирований и проверок кода проблемы в собственном продукте также влекут за собой цепочку согласований и споров - насколько это нужно в конкретный момент, насколько эффективно.
12. Комплаенс
Несмотря на то, что требования комплаенса больше важны бизнесу, работают с ними как раз-таки безопасники, что в рамках awareness, что по части организации процесса. А для того, чтобы этот процесс в принципе мог существовать, он должен опираться на работу ИТ-департамента.
13. BCM (business continuity management), управление процессами
Как это ни удивительно, но даже такие, казалось бы, «чисто бизнесовые» процессы содержат в себе и подпроцессы и управление активами, и работу с безопасностью, так как тестирования проводятся и для ИБ-решений в том числе. От слаженной работы двух команд зависит непрерывность бизнеса в целом.
Общие сложности
1. Коммуникация
Бывает тяжело настроить общение, если департаменты существуют максимально отдельно друг от друга. Если закупки проводятся с каждым по отдельности, требования не согласовываются друг с другом и нет никакой площадки для взаимодействия.
2. Приоритеты
На примере патч-менеджмента и управления уязвимостями видно, что цель ИТ и ИБ иногда заключается в разных вещах, которые могут друг другу противоречить.
3. Ответственность
Наверное, это самое большое, что бросается в глаза. Все эти политики и определения, кто что может и кому что недоступно - первое, что вы услышите, как ответ на вопрос о противоречиях.
4 Экспертиза
Различный уровень экспертизы и компетенций нередко может стать причиной плохой коммуникации. Ведь если две команды говорят на разных языках и у них нет «переводчика», то как они договорятся?
5. Общение с бизнесом
Иногда ИТ ближе к бизнес-проблемам, иногда ИБ, зависит от компании. Тем не менее, практически всегда чьи-то потребности совпадают с основным вектором компании, а кто-то должен дополнительно защищать их.
6. Смена процессов
В принципе, очень сложно взять и начать работать по-другому. Очень сложно перестроиться, особенно там, где процесс уже отлажен и показал свою эффективность.
Пути решения
1. Объединение усилий для общих процессов
Может помочь как набор общей команды, куда войдут участники от разных департаментов, так и внедрение процесса из списка выше, который учитывал бы участие и потребности обоих подразделений. Внутренняя лаборатория доведет до конца такие проекты совместно, объединяя сильные стороны.
2. Единая стратегия от бизнеса
ИТ и ИБ в компании одинаково ценны, и если одну сторону весов непрерывно наполнять, забывая о второй, дисбаланс рано или поздно даст о себе знать. Невозможно получить хороший результат без объединения компетенций и практик с обеих сторон.
3. Обмен опытом и кадрами
Иногда бывает полезно какое-то время поработать в команде людей, чья деятельность тебе не совсем понятна и прозрачна. В некоторых случаях столкновение с теми же сложностями, через которые люди проходят каждый день в своей работе, несколько отрезвляет и позволяет подумать о том, как эти проблемы решать вместо того, чтобы усугублять их.
4. Обмен технологическим стеком
Как мы описывали ранее, есть очень много полезных решений, которые могут повысить эффективность как ИБ, так и ИТ. Обмен этими знаниями, технологиями и экспертизой позволяет в рабочем порядке выйти на новый уровень комфортной и эффективной работы.
В целом, здоровая коммуникация и отсутствие навязанной конкуренции и стереотипов, которые приходят как от бизнеса, так и от простых пользователей, помогают решить большую часть проблем и разногласий.
.jpg)
