Сразу оговорюсь: я не безопасник. В ИБ я разбираюсь ровно настолько, насколько должен разбираться любой взрослый человек не называть три цифры с оборота карты, не хранить пароли в файле "пароли.txt", немного понимаю про доступы и разграничение прав. ИБ это не моя специализация, и я не претендую на экспертную оценку конкретных практик.
Но у меня как у человека, который много лет занимается внедрениями ITSM/ITAM и постоянно взаимодействует со службами безопасности заказчиков, накопилось наблюдение, которым хочется поделиться и услышать мнение тех, кто в теме глубже.
Наблюдение
Возьмем типовую ситуацию. Есть сервис-деск. Он хочет постучаться во внешнюю систему которая живет в руже интернета, чтобы, например, автоматически забирать оттуда критичные уязвимости ПО и заводить по ним заявки. Задача понятная, полезная, снижает ручной труд и человеческий фактор.
Приходит ИБ и говорит НЕТ. Защищенный контур, никаких внешних обращений, точка.
И вот тут у меня как у стороннего наблюдателя возникает вопрос, а разве задача ИБ это запретить инициативу? Или все-таки оценить риск и предложить, как его закрыть?
То есть в идеальном мире ответ звучал бы не НЕТ, а что-то вроде: "окей, делаем, но трафик шифруем так-то, доступ даём только сервисному аккаунту с такими-то правами, логируем каждое обращение, ставим WAF/прокси на периметре, ревью раз в квартал". Риск не в том, что система смотрит наружу риск в том, как она это делает. И управлять этим КАК это и есть, как мне кажется, содержание работы ИБ, а не сам факт запрета любых инициатив.
Почему тогда так происходит?
У меня есть несколько версий, и я не уверен, какая ближе к истине возможно, все сразу, в разных пропорциях.
Версия про бюджет и ресурсы. Сказать НЕТ это бесплатно. Спроектировать безопасную схему интеграции, согласовать ее, потом сопровождать это время, компетенции и деньги. Если в ИБ два человека на весь холдинг, у них физически нет ресурса разбираться с каждым "а давайте достучимся туда-то" проще закрыть тему одним словом НЕТ.
Версия про ответственность. Запрет не создает для безопасника личного риска. Разрешение создает. Если что-то случится после ДА, спросят с того, кто разрешил.
Версия про традицию. ИБ во многих компаниях исторически выросла из "режимного отдела" оттуда, где по умолчанию всё закрыто, а открывается только по специальному разрешению сверху. Культура за 20-30 лет не поменялась, хотя ландшафт угроз и кардинально другой.
Версия про КИИ и регуляторику. Отдельная история объекты критической информационной инфраструктуры, там свои требования, свои категории значимости, и там запрет часто действительно обоснован нормативкой, а не ленью или отсутствием бюджета. Но проблема в том, что логика "раз где-то есть жесткие требования давайте применим их ко всему" переносится и на банальный сервис-деск, которому нужно всего лишь синхронизировать справочник уязвимостей.
Мне интересно, насколько мое наблюдение справедливо, или я просто вижу нерепрезентативную выборку компании, где ИБ действительно недоинвестировано и работает по остаточному принципу.
Если вы работаете в ИБ или тесно с взаимодействуете с ними правда ли, что зрелая практика по умолчанию ищет способ разрешить с компенсирующими мерами, а не запретить? Или запрет по умолчанию это и есть правильный подход при текущем уровне угроз, а мое "а давайте разрешим, но защитим" звучит инфантильно?
Буду рад комментариям, особенно от тех, кто может аргументированно высказать свое мнение.
