Польза ИT-систем в работе ИБ-аналитика
Это вторая статья из цикла «Взаимодействие ИТ и ИБ». Первую статью можно прочитать здесь.
Зачем ИБ-шникам ИТ-системы?
Нередко при работе с инцидентами аналитику приходится сталкиваться с таким страшным зверем, как обогащение и поиск дополнительной информации. Любые улики, зацепки и мелочи могут помочь как в продвижении расследования, так и в принятии решения касательно действий — выполнять или нет, стоит ли результат риска и так далее.
Часто выходит так, что ИТ и ИБ-подразделения пользуются схожим инструментарием в части ИТ-систем. А иногда и не просто схожим, одинаковым. В результате чего могут возникать непримиримые противоречия и неутихающие споры, нередко заканчивающиеся чем-то вроде холодной войны между департаментами.
Почему нельзя просто взять и поделиться
Был такой случай в работе, когда заказчик пришел с запросом на большую систему мониторинга активов. С представителями ИБ-подразделения очень долго обговаривались все подробности, дашборды и настройки интеграций — когда, как и для кого это дело будет обновляться, в какие процессы встроится и так далее. В конечном итоге была проделана огромная аналитическая работа, удовлетворявшая нашу команду вплоть до одного интересного момента: прямо за стеной ИБ-департамента иронично висела на стене видеопанель с точно такой же системой, почти идентичными ТЗ настройками, только… только принадлежала она ИТ-департаменту, и ходить туда и смотреть было ни в коем случае нельзя.
Разграничение доступа обычно вводится не по прихоти и не от плохого настроения: задачи у подразделений могут быть действительно разными, а камнем преткновения по классике становится консистентность данных — мало ли какой департамент решит поменять модель данных, добавить новые контексты или вовсе избавиться от привычных ИТ полей.
После первого случая следующие уже не удивляли — так, другой заказчик, выбирая все ту же CMDB, заранее предупреждал нас о том, что от ИТ будет идти другой запрос и другая система, т.к. данные в ИТ-департаменте нужны эталонные, без лишних связей и вовлеченности в инциденты, и процесс управления активами не то чтобы слабо связан с процессом управления инцидентами — эти процессы идут параллельно, не пересекаясь в рабочей жизни.
То же самое можно сказать и про мониторинг как самих средств защиты, так и инфраструктуры — нередко это вотчина только ИТ, кроме совсем уж ярких случаев контроля за машинами самой SOC-командой.
Но самая большая часть споров велась и будет вестись в области компетенций и прав по проактивным действиям в ходе реагирования на инциденты. Тут уже привычные нам четыре пути и их сочетания:
— система автоматизации сама управляет СЗИ и рабочими станциями;
— только аналитик и сотрудник ИБ может выполнять действия на конечных устройствах;
— решение о действии принимает аналитик, но выполнением занимается ИТ-отдел через систему заявок;
— аналитик уполномочен лишь создавать заявки, принимает и выполняет действие только ИТ.
Из которых на практике чаще всего встречаются вторые два. Получается, что в целом полномочия разделены таким образом, что иногда кому-то можно что-то подглядеть, и на этом все? Не совсем.
Вопреки противоречиям
На самом деле, в реальной ситуации все не настолько полярно. Когда команды начинают по-настоящему работать друг с другом и думать о том, как процессы улучшить, а не затормозить, могут происходить позитивные метаморфозы.
Начиная от систем виртуализации, защиту которых может обеспечить ИБ в обмен на возможность администрирования этих самых систем с целью получения необходимой статистики и проработки рекомендаций, — к примеру, для веб-сервера компании. И заканчивая отдельными админ-правами, пусть и на чтение, для системы автоматизации или аналитика ИБ в процессе получения слепков хостов, сохранения данных об их состояниях и производительности.
В конце концов, удобные и безопасные хранилища и решения по защите БД не вышло бы реализовать на том же уровне, если бы ИБ-подразделение ничего не знало об инфраструктуре.
И наконец, если что-то касается КИИ — то без совместного использования системы управления активами и общего контекста никак не обойтись.
Обмен информацией о процессах скорее несет пользу, чем вред, и ценность этой помощи куда выше предполагаемых проблем.
