Сколько нужно VM-щиков, чтобы поменять лампочку? Андрей Прозоров спрашивает про ИБ-шников, но я за них за всех не скажу, поэтому давайте сфокусируемся на решении задачи именно с точки зрения Управления Уязвимостями.

Для начала нужно понять, а какую задачу мы решаем. Нас волнует именно эта конкретная лампочка в этом конкретном месте или проблема шире: лампочки перегорают, их вовремя не заменяют, это создает угрозы, которые требуется минимизировать. Если первое, то достаточно одного письма в АХО (Административно-хозяйственный отдел) от сотрудника, которого бесит перегоревшая лампочка, этим сотрудником может быть VM-щик. Возможно потребуется ещё одно письмо через пару дней для эскалации. Если второе, то нужно строить нормальный процесс, вернее даже несколько связанных процессов:

1. Инвентаризация и аудит состояния (в первую очередь светимости). Мы вообще понимаем сколько у нас лампочек в организации, где они расположены, какого они типа, какой у них ресурс, какой регламент по их замене? Если нет, то это нужно собирать и поддерживать в актуальном состоянии (проверять, что в данных нет аномалий). В качестве исходных данных можно взять планы помещений, информацию по закупкам и остаткам на складе. Аудит может представлять собой периодический поэтажный обход, а возможно есть и более продвинутые способы мониторинга. Возможно в компании используются smart-лампочки, к которым можно относиться как к части IT-инфраструктуры? А возможно перегоревшие лампочки можно детектировать через анализ изображения с камер? Вариантов может быть много, нужно обсуждать с IT и АХО. VM-щик здесь должен быть заинтересован в первую очередь в том, чтобы процессом были покрыты все лампочки во всех помещениях (и во всех филиалах).

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

3.* Приоиритизация и применение компенсирующих мер. По мне если лампочка перегорела - она должна быть оперативно заменена. Но есть разные взгляды на этот вопрос. Например, лампочки могут перегорать слишком быстро и их будут не успевать менять. Как по мне, то это вопрос к инфраструктуре и архитектуре, почему нам так сложно лампочки заменять? Нормально ли это вообще? Но есть мнение, что нужно наоборот смириться с обстоятельствами и заменять лампочки только там где это ДЕЙСТВИТЕЛЬНО НУЖНО. Там, где люди уже ноги ломали, нужно менять в первую очередь, а там где просто мигать начала или из трех одна пока светит, менять во вторую очередь или вообще не менять. В принципе это также можно учитывать в заведении тасков. VM-щик здесь должен принимать во внимание кучу факторов о локациях и лампочках, чтобы ставить в приоритет к исполнению именно то, что требуется в первую очередь. Но как по мне, лучше этой ерундой не заниматься вовсе, если есть такая возможность.

Можно ли покрыть эти процессы одним человеком? Можно, но он будет постоянно переключать контекст, будет малоэффективно. Лучше чтобы это были разные люди, которые бы специализировались и целиком отвечали за свою часть работы. Т.е. от 2-3 человек, затем увеличивать при необходимости. 🙂