Следуя правильной причинно-следственной логике , прежде чем выбирать инструмент решения, следует понять задачу. Очевидно, сканер уязвимостей нужен для поиска уязвимостей, чтобы их потом латать и так, постепенно, улучшать свои ИТ-системы в предположении, что минимизация уязвимостей == повышение безопасности, наверно, это так и есть.
Ранее, мы разбирались с уязвимостями (кому лень читать, можно послушать ), в совокупности с предположением, что в компании не разрабатывается ПО, с необходимостью сканера не все понятно.
Вообще, аудит мне подтверждает две вещи: что я делаю правильные вещи, и что я делаю эти вещи правильно. Второе - это аудит соответствия. Первое - пентест, этакая Зарница , в идеале, может, даже и без оповещения, что мы в состоянии игры. Как я не раз отмечал , в большом интерпрайзе управляемость - один из важнейших моментов, а следовательно, обычно, есть централизованные системы управления элементами ИТ-комплекса, типа SCCM , выполняющих любые виды инвентаризации. Чем вам такая инвентаризация не аудит соответствия? Сейчас уже у любого производителя есть руководство по безопасной настройке, так называемые hardening-гайды, - аудит соответствия такому гайду легко автоматизировать, да и многие производители имеют автоматизированные инструменты , которые проверят соответствие (некоторые потом даже предложат и исправить) - совсем нетрудно дергать такие проверялки при инвентаризации. В общем, очевидно, уязвимости конфигурации средствами инвентаризации легко закрываются.
Но закрываются и ошибки разработчиков, поскольку уязвимости коммерческого ПО решаются для интерпрайза единственным образом - установкой патчей. Если я имею дело с 0-day, то такие риски компенсируются другими "эшелонами" моей безопасности: сегментацией, "навесными" средствами с разными модными технологиями, типа "virtual patch", контролем доступа, постоянным мониторингом и пр. К тому же, если производитель нормальный (я рекомендую, и от души желаю, работать только с нормальными производителями), скорее всего он выпустит какие-нибудь рекомендации, что нам всем делать, пока он не выпустил патч. Производитель, в софте которого вы нашли уязвимость, а затем безрезультатно закидываете его enhancements request-ами с требованиями исправить проблему, - не достоин называться "нормальным" , поэтому неразумно держать сканер исключительно для таких случаев.
Перейдем к пентестам. Здесь мы пытаемся удостоверитья, что мы делаем правильные вещи. Безусловно, здесь уже нужна автоматизация... Но, в случае уязвимости конфигурации - эксплуатация тривиальна, как правило, можно и не пробовать, а в случае уязвимости ПО - вопрос эксплуатируемости, обычно, исследован вендором , и этому исследованию можно и нужно верить, а проверять экплуатируемость сканером - ну разве что только из спортивного интереса - насколько хорошо производитель сканера реализовал эксплоит. Более того, исследовать вопрос насколько правильные вещи я делаю, мне едва ли нужно часто. А раз так, то, наврено, эффективнее нанять профессиональную команду, где натренированные практики будут использовать десятки инструментов, чем я-любитель буду в автоматизированном режиме использовать один, имеющейся у меня сканер.
Любопытно, что даже если я разрабатываю ПО, мне тоже едва ли подходит off-the-shelf сканер, - значительно эффективнее будет работать моя продуктовая безопасность, которая знает мои продукты лучше производителя сканера и имеет специализованные инструменты, адаптированные под мою продукцию, понимает, что дейстительно критично и поэтому может правильно расставлять приоритеты.
Подводя итог всему написанному, хочется все-таки понять, когда же мне нужен сканер:
1. Я не знаю свою инфраструктуру. Отсканировал - получил какое-то представление.
2. У меня нет систем управления ИТ-инфраструктурой, поэтому я это компенсирую сканером, реализовав следующий процесс управления ИТ-инфраструктурой: отсканировал --> нашел узявимости --> устранил --> отсканировал --> ...
2,5. У меня плохие отношения с ИТ, поэтому я не могу использовать их системы управления ИТ-инфраструкурой и должен обязательно иметь свою штуку.
3. У меня стандартные системы, чтобы в сканере под них были сигнарутыпрофили.
4. Я не хочу разбираться с безопасной настройкой каждой из используемых у меня систем, мне удобнее иметь комбайн, который все мои ошибки конфигурации (в целом, отсутствующий патч тоже можно считать уязвимостью конфигурации) найдет мне в виде уязвимостей.
5. Меня вынудил комплайнс, требующий от меня наличия сканера, или инструмента управления уязвимостями, или еще чего подобного.
6. У меня есть желание поразвлечься - посмотреть эксплуатируемость стандартных уязвимостей (== доступных в сигнатурахпроверках сканера)
7. Я хочудолжен кому-то что-то продемонстрировать или доказать, сделать вау-эффект, или эффективность моей работы характеризуется количетсвом найденных уязвимостей.
8. Сканер - это мой инструмент situational awareness (что-то около п.1) - фундаментальное требование для эффективной работы SOC .
Ранее, мы разбирались с уязвимостями (кому лень читать, можно послушать ), в совокупности с предположением, что в компании не разрабатывается ПО, с необходимостью сканера не все понятно.
Вообще, аудит мне подтверждает две вещи: что я делаю правильные вещи, и что я делаю эти вещи правильно. Второе - это аудит соответствия. Первое - пентест, этакая Зарница , в идеале, может, даже и без оповещения, что мы в состоянии игры. Как я не раз отмечал , в большом интерпрайзе управляемость - один из важнейших моментов, а следовательно, обычно, есть централизованные системы управления элементами ИТ-комплекса, типа SCCM , выполняющих любые виды инвентаризации. Чем вам такая инвентаризация не аудит соответствия? Сейчас уже у любого производителя есть руководство по безопасной настройке, так называемые hardening-гайды, - аудит соответствия такому гайду легко автоматизировать, да и многие производители имеют автоматизированные инструменты , которые проверят соответствие (некоторые потом даже предложат и исправить) - совсем нетрудно дергать такие проверялки при инвентаризации. В общем, очевидно, уязвимости конфигурации средствами инвентаризации легко закрываются.
Но закрываются и ошибки разработчиков, поскольку уязвимости коммерческого ПО решаются для интерпрайза единственным образом - установкой патчей. Если я имею дело с 0-day, то такие риски компенсируются другими "эшелонами" моей безопасности: сегментацией, "навесными" средствами с разными модными технологиями, типа "virtual patch", контролем доступа, постоянным мониторингом и пр. К тому же, если производитель нормальный (я рекомендую, и от души желаю, работать только с нормальными производителями), скорее всего он выпустит какие-нибудь рекомендации, что нам всем делать, пока он не выпустил патч. Производитель, в софте которого вы нашли уязвимость, а затем безрезультатно закидываете его enhancements request-ами с требованиями исправить проблему, - не достоин называться "нормальным" , поэтому неразумно держать сканер исключительно для таких случаев.
Перейдем к пентестам. Здесь мы пытаемся удостоверитья, что мы делаем правильные вещи. Безусловно, здесь уже нужна автоматизация... Но, в случае уязвимости конфигурации - эксплуатация тривиальна, как правило, можно и не пробовать, а в случае уязвимости ПО - вопрос эксплуатируемости, обычно, исследован вендором , и этому исследованию можно и нужно верить, а проверять экплуатируемость сканером - ну разве что только из спортивного интереса - насколько хорошо производитель сканера реализовал эксплоит. Более того, исследовать вопрос насколько правильные вещи я делаю, мне едва ли нужно часто. А раз так, то, наврено, эффективнее нанять профессиональную команду, где натренированные практики будут использовать десятки инструментов, чем я-любитель буду в автоматизированном режиме использовать один, имеющейся у меня сканер.
Любопытно, что даже если я разрабатываю ПО, мне тоже едва ли подходит off-the-shelf сканер, - значительно эффективнее будет работать моя продуктовая безопасность, которая знает мои продукты лучше производителя сканера и имеет специализованные инструменты, адаптированные под мою продукцию, понимает, что дейстительно критично и поэтому может правильно расставлять приоритеты.
Подводя итог всему написанному, хочется все-таки понять, когда же мне нужен сканер:
1. Я не знаю свою инфраструктуру. Отсканировал - получил какое-то представление.
2. У меня нет систем управления ИТ-инфраструктурой, поэтому я это компенсирую сканером, реализовав следующий процесс управления ИТ-инфраструктурой: отсканировал --> нашел узявимости --> устранил --> отсканировал --> ...
2,5. У меня плохие отношения с ИТ, поэтому я не могу использовать их системы управления ИТ-инфраструкурой и должен обязательно иметь свою штуку.
3. У меня стандартные системы, чтобы в сканере под них были сигнарутыпрофили.
4. Я не хочу разбираться с безопасной настройкой каждой из используемых у меня систем, мне удобнее иметь комбайн, который все мои ошибки конфигурации (в целом, отсутствующий патч тоже можно считать уязвимостью конфигурации) найдет мне в виде уязвимостей.
5. Меня вынудил комплайнс, требующий от меня наличия сканера, или инструмента управления уязвимостями, или еще чего подобного.
6. У меня есть желание поразвлечься - посмотреть эксплуатируемость стандартных уязвимостей (== доступных в сигнатурахпроверках сканера)
7. Я хочудолжен кому-то что-то продемонстрировать или доказать, сделать вау-эффект, или эффективность моей работы характеризуется количетсвом найденных уязвимостей.
8. Сканер - это мой инструмент situational awareness (что-то около п.1) - фундаментальное требование для эффективной работы SOC .
