OVAL® или «миф об идеальном сканере»
Приветствую, коллеги. Вопрос автоматических сканеров безопасности стоит весьма остро на "корпоративном" рынке услуг. Конечно, кому же хочется проверять тысячи хостов вручную ? Поскольку спрос рождает предложение, вы можете найти их на любой вкус, цвет и бюджет. Они призваны решать одни и те же цели: комплайнс-менеджмент. Тем самым сэкономить корпорации огромное количество денег при массовой стандартизации 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 на каждом этапе сканирования не принесет вреда вендорам. Но сделает "прозрачным" результаты сканирования и позволит напрямую сравнить продукты информационной безопасности. Тем самым мы добьемся поставленной задачи: сделать безопасность "измеримой". Спасибо за внимание.