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 не несет ответственности за точность, полноту и достоверность опубликованных данных. Вся информация предоставлена «как есть» и может не соответствовать официальной позиции компании.
310K
долларов
до 18 лет
Антипов жжет
Ребёнок как убыточный
актив. Считаем честно.
Почему рожают меньше те, кто умеет считать на десять лет вперёд.

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

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

FREE
100%
Кибербезопасность · Обучение
УЧИСЬ!
ИЛИ
ВЗЛОМАЮТ
Лучшие ИБ-мероприятия
и вебинары — в одном месте
ПОДПИШИСЬ
T.ME/SECWEBINARS