ISACA: Vulnerability Management

ISACA: Vulnerability Management
19 октября на базе площадки Московского Политеха прошло очередное мероприятие, организованное ISACA Moscow Chapter, на тему «Vulnerability Management».
Я решил поделиться своим впечатлением, некоторыми материалами данного мероприятия (не нарушая авторских прав), а также прокомментировать их в части, касающейся.

Самое приятное, что в мероприятии было 2 теоретических методологических доклада и 2 практических.

1-ый доклад был связан с COBIT 5.
Здесь отмечу только то, что если взять «COBIT for Information Security», то «Vulnerability Management» встроен в процесс «Manage Configuration», а его выход идет в «Manage Problems».
b38d9b86542458ca779533f04e47aab9.png
На своей практике данную схему реализации я не проверял, поэтому комментировать ее не готов.
 
2-ой доклад был в разрезе ITIL.
Автором было выделено 5 этапов в процессе «Vulnerability Management»:
- подготовка к сканированию;
- сканирование уязвимостей;
- определение способов устранения;
- устранение уязвимостей;
- проверка исправлений.


Что меня насторожило в обоих докладах, это сужение Vulnerability Management только до техники. Связана это настороженность с тем, что, на мой взгляд, уязвимость – это более широкое понятие.
967bdc6ba3ce8cfacbff0dda0b9d4b3e.png
Если взглянуть на определения, то коллеги акцентировали свое внимание на уязвимостях систем, оставив «за скобками» уязвимости (слабости / недостатки) в процессах и людях.
Например, в процессе управления доступом заявку на предоставление прав реализует и контролирует один и то же человек, это уязвимость процесса.
Или, например, в службе информационной безопасности работает специалист, который регулярно «выпадает на больничный» в самый ответственный момент, это уязвимость в людях.
На мой взгляд, в рамках методологии нужно расширять scope of process в данные области то же.


В практической части я бы выделил следующие моменты:
- даже если у вас есть лучший сканер безопасности – это не значит, что процессе «Vulnerability Management» готов;
7baac904052786a870888cb1918d06cc.png

- нужно быть готовым к далеко неполной и разной зоне покрытия разными сканерами безопасности;
6f8a4117e7b4155d58f3a0f2ee7f1c96.jpg

- нужно быть готовым вести еженедельную борьбу с false positive (были озвучены цифры, что они могут достигать 30%).

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

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

Успехов в реализации вашего Vulnerability Management!
Alt text
Обращаем внимание, что все материалы в этом блоге представляют личное мнение их авторов. Редакция SecurityLab.ru не несет ответственности за точность, полноту и достоверность опубликованных данных. Вся информация предоставлена «как есть» и может не соответствовать официальной позиции компании.

Alert! Зафиксирована утечка экспертных знаний!

Собираем и анализируем опыт профессионалов ИБ

Подключитесь к потоку конфиденциальной информации!

Александр Кузнецов

Заметки про управление в области информационной безопасности и не только