Видимо, я неоднозначно выразился. Я в первом предложении описал вариант решения для опроса, во вотором — решение общей проблемы. Насколько мне известно, скриншоты не являются фактами подтверждения за исключением тех случает, когда их делали сами аудиторы либо они были нотариально заверенные. Аудитор должен придерживаться принципа «никому не доверять».
Почему бы аудитору не пойти по другому пути? По окончанию опроса работника аудитором озвучивается, что будет записано в протокол, чтобы работник понимал, всю ответственность. Если компанией за установленный срок не были предоставлены свидетельства, подтверждающие выполнение пункта аудита, значит пункт не выполняется.
Подскажите, какой вы использовали инструмент для рекурсивного брутфорса поддоменов. Он автоматических набрутил поддомен пятого уровня или вы его перенастраивали при нахождении очередного поддомена?
Я создал таблицу-матрицу, где наглядно видно, какое ПО и ОС на каких системах тестируется, чтобы ничего не пропустить. docs.google.com/spreadsheets/d/16iREU_vCVSClTzkLPjmb_rFmY9iztH6IMtrtetTIXSU/edit?usp=sharing
Как правило, тестирование длится до 2-х недель (фиксируются заявки от пользователей + ручное тестирование), а затем раскатывается на оставшиеся хосты и сервера
Индекс влияния — это количество затронутых уязвимым пакетом серверов, умноженное на CVSS-балл уязвимости. Зачастую бывает что уязвимость с не самым выскоким балом имеет гораздо большее распространение в инфраструктуре, и поэтому потенциально более опасна
Смею не согласиться. Допустим, у меня имеется 50 серверов с низким уровнем уязвимости и 1 сервер с критической уязвимостью. Из-за такого расчета индекса влияния на верхней позиции окажется строчка с 50 серверами, и, пока я буду устранять уязвимости на этих серверах (а ведь таких серверов/ПК может быть и гораздо больше), может произойти компрометация сервера через критическую уязвимость. Исходя из собственного опыта, в первую очередь я бы начал устранять критические уязвимости и уязвимости с высоким уровнем опасности, т.к. это занимает меньше времени и эффективнее снижает риски ИБ.
— Какими инструментами пользуетесь и почему выбрали именно их.
— Пошаговые инструкции по реагированию на различные инциденты.
— С какими проблемами сталкиваетесь при расследовании инцидентов и сборе логов, как их решаете.
— Статью раздела «SOC для среднего уровня» :)
Всегда интересно читать про внутреннюю кухню ИБ-компаний. К сожалению, большинство не желают делиться подобными сведениями. За это вам отдельная благодарность!
Когда говорят о безопасной разработке программного обеспечения обычно ссылаются на аббревиатуру «SDL» от Microsoft, https://www.microsoft.com/en-us/sdl/
Как правило, тестирование длится до 2-х недель (фиксируются заявки от пользователей + ручное тестирование), а затем раскатывается на оставшиеся хосты и сервера
Смею не согласиться. Допустим, у меня имеется 50 серверов с низким уровнем уязвимости и 1 сервер с критической уязвимостью. Из-за такого расчета индекса влияния на верхней позиции окажется строчка с 50 серверами, и, пока я буду устранять уязвимости на этих серверах (а ведь таких серверов/ПК может быть и гораздо больше), может произойти компрометация сервера через критическую уязвимость. Исходя из собственного опыта, в первую очередь я бы начал устранять критические уязвимости и уязвимости с высоким уровнем опасности, т.к. это занимает меньше времени и эффективнее снижает риски ИБ.
— Пошаговые инструкции по реагированию на различные инциденты.
— С какими проблемами сталкиваетесь при расследовании инцидентов и сборе логов, как их решаете.
— Статью раздела «SOC для среднего уровня» :)