
Они все такие разные, но все же у них есть одна общая черта: полнейшая анархия и разброд в формате отчетов, результатов инвентаризации и контента для обновления. Как каждая группа программистов придумала, так и было сделано. Такая ситуация привод к тому, что сравнить сканеры безопасности становится чрезвычайно трудоемко. А разговора о том, что бы использовать накопившиеся за время использования продукта «А» данные при переходе на продукт «Б» не может быть и речи. Как же: куда не сунься, везде «коммерческая тайна» да «интеллектуальная собственность». Решение, уважаемый мой читатель, очевидно: стандартизация входных и выходных форматов на всех этапах деятельности сканера. Именно это и описано в стандарте 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 на каждом этапе сканирования не принесет вреда вендорам. Но сделает «прозрачным» результаты сканирования и позволит напрямую сравнить продукты информационной безопасности. Тем самым мы добьемся поставленной задачи: сделать безопасность «измеримой».
Автор: Кирилл Ермаков, эксперт исследовательского центра Positive Research
Комментариев нет:
Отправка комментария