Приветствую, коллеги.
Вопрос автоматических сканеров безопасности стоит весьма остро на «корпоративном» рынке услуг.
Конечно, кому же хочется проверять тысячи хостов вручную?
Поскольку спрос рождает предложение, вы можете найти их на любой вкус, цвет и бюджет.
Они призваны решать одни и те же цели: комплайнс-менеджмент.
Тем самым сэкономить корпорации огромное количество денег при массовой стандартизации PCI DSS и подобным стандартам.
Они все такие разные, но все же у них есть одна общая черта: полнейшая анархия и разброд в формате отчетов, результатов инвентаризации и контента для обновления. Как каждая группа программистов придумала, так и было сделано. Такая ситуация привод к тому, что сравнить сканеры безопасности становится чрезвычайно трудоемко. А разговора о том, что бы использовать накопившиеся за время использования продукта «А» данные при переходе на продукт «Б» не может быть и речи. Как же: куда не сунься, везде «коммерческая тайна» да «интеллектуальная собственность». Решение, уважаемый мой читатель, очевидно: стандартизация входных и выходных форматов на всех этапах деятельности сканера. Именно это и описано в стандарте Open Vulnerability and Assessment Language (OVAL®)
Что бы не погружаться заново в основы и базовые термины, хотелось бы отметить что про OVAL я рассказывал в своей прошлой статье. Поэтому стоит ее глянуть, что бы не путаться в терминологии.
Собственно, обобщая высказанные тезисы, можно понять следующее: стремление сделать информационную безопасность «измеримой» возможно только при полной стандартизации информации на всех этапах прохождения ее через сканер. Почему это до сих пор не сделали ? Ответ столь прост, насколько он может быть в рамках «мыльного пузыря» информационной безопасности: это не выгодно создателям секьюрити-продуктов. Пока процесс инвентаризации, нахождения уязвимостей и принятия решений об их наличии остается «черной магией» каждой конкретной компании их продукты будут прочно удерживать «рынок», не боясь критики и вторжения конкуренции.
В прочем, не будем столь категоричны. Процесс формализации знаний в информационной безопасности для каждой компании потребует столь больших ресурсов, что это вполне их оправдывает. Ведь перевести 100500 скриптов в «definition», «object», «test» и «state» это большая работа, требующая много «человеко-месяцев».
Так что же такое, этот "идеальный сканер"? Который удовлетворит всем требованиям регуляторов и сможет наконец таки сделать безопасность «измеримой». Ответ лежит на глубине метра от поверхности, и описан в документации к языку OVAL. Ключ к победе, это использование формализованных конструкций на всех этапах сканирования. И это не моя фантазия, а вполне работоспособная схема, предложенная MITRE:
Таким образом, мы получим «шаблонные» конструкции на каждом этапе. Какие от этого плюсы ? Все же очевидно: мы делаем сканирование системы сканером «А», потом сканером «Б» и видим, что разрекламированный зарубежный продукт не нашел половины установленных программ. А его конкурент вообще перепутал Windows и Unix.
Прозрачность результата и сравнимость отчетов — вот главные преимущества такой схемы.
Вынужденные описывать всю последовательность сканирования в виде OVAL-definition авторы смогут показать, почему принято то или иное решение. Не «Алярма! у вас уязвимость CVE-2034-100500!» а раскрытое дерево принятия решения: «У вас уязвимость CVE-2034-100500 потому, что у вас Solaris 15, установлен пакет Firefox 22 версии 1.1.23 и не установлены секьюрити патчи 13455-10». Согласитесь, с точки зрения пользователя такой расклад куда более «вкусный». В качестве бонуса мы получаем полную совместимость как информации по обновления для аудитных проверок, так и результатов инвентаризации хостов.
«А где же „гешефт“ секьюрити-девелопера?» спросите Вы. А он остался на своем месте: в скриптах, реализующих выполнение тех или иных тестов. Будучи расширяемым языком, OVAL позволяется задавать собственные абстрактные типы требуя в качестве обязательного условия лишь их формальное описание. Поэтому «низы» остаются надежно скрыты. Отчуждаемым является тест «проверить в файле /var/log/messages наличие footprint бэкдора LinBackDoor» а не скрипт, его реализующий.
Подводя итог: реализация стандартов языка OVAL на каждом этапе сканирования не принесет вреда вендорам. Но сделает «прозрачным результат» и позволит напрямую сравнить продукты информационной безопасности. Тем самым мы добьемся поставленной задачи: сделать безопасность «измеримой».
Спасибо за внимание.
Автор: isox
