OVAL® или «миф об идеальном сканере»

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

    Спасибо за внимание.
    • +20
    • 6.9k
    • 5
    Positive Technologies
    229.91
    Company
    Share post

    Comments 5

      +3
      К любому сканеру нужны мозги. А у нас привыкли на мозгах экономить, а всякие сканеры закупать. И вот приходит такой, с позволения сказать, офицер безопасности и говорит: у тебя тут сканер обнаружил, я тебе отчет прислал. Открываю — там уязвимость ПХП на внутреннем сайте, причем такая, которую можно юзать только в полнолуние при наличии 100% экспы и 100% везения. Я в репы — нету патча, я на сайт ПХП там типа: мы знаем, но не критично, потом, может быть, устраним. А сканер (не буду называть какой, но одной известной антивирусной фирмы) выдает как критическую. Я к офицеру:
      -Батюшка, помилуй, во-первых уязвимость закрыть нечем, во-вторых сайт-то внутренний, в эту сетку работники только доступ имеют. Некому эту уязвимость эксплуатировать.
      -Ничего не знаю, — отвечает, — мне программу прислали сверху, сказали бдить и критических уязвимостей не допускать! И нигде не написано, что для внутреннего сайта какие-то другие требования чем к машине Васи Пупкина или внешнего сервера. У тебя N дней для устранения.
      И все. Делай что хочешь.
      Так, что сканер — это хорошо, но в руках таких вот «безопасников» — это, увы, зло…
        0
        Абсолютно согласен, что мало иметь сканер.
        Конечный пользователь должен быть достаточно компетентен для принятия самостоятельных решений.
          0
          Нормальная ситуация. Человек действует по инструкции. Мозги мозгами, но в суде мозги к делу не пришьешь. Все вариации, возможности и жизненные ситуации одной инструкцией не описать. И суду вообще дела нет, что кто-то к кому-то в положение вошел.
          Бороться можно теми же средствами — писать бумаги и разводить бюрократию.

          Не повезло с организацией, это не значит что безопасник без мозгов. Это значит что ему дешевле для себя копать от забора и до обеда, чем бодаться с системой и искать правду, которой нет.

          С другой стороны, с чего вы решили, что обладаете достаточной компетенцией, чтобы ставить проверяющему диагнозы и решать опасна дырка или нет. Вы же по факту не обладаете всей информацией, которой обладает проверяющий? Так что зло не зло, а делать придется что говорят.
            +1
            > С другой стороны, с чего вы решили, что обладаете достаточной компетенцией.

            Потому, что я инженер с высшим образованием и 10-тилетним ИТ стажем. А он — бывший военный. И все его познания в ИТ сводятся к установить антивирус да в экселе и ворде работать.

            >Бороться можно теми же средствами — писать бумаги и разводить бюрократию.

            «Хороший совет». Это, может, и Ваш путь, но не мой. Поэтому в Г и живем, что

            >ему дешевле для себя копать от забора и до обеда

            Далее.

            >Вы же по факту не обладаете всей информацией, которой обладает проверяющий?

            Как раз я и обладаю, потому, как сервера — моя специализация, я не его. Его специализация «копать от забора и до обеда». Поэтому, повторюсь, так и живем: настраивают специалисты, а контролируют — те, кто в этом почти не разбирается, зато у него инструкция и «военный» склад ума.

            >Так что зло не зло, а делать придется что говорят.

            Интересно, как? Написать свой патч? Выключить сервер?

            >Это значит что ему дешевле для себя копать
            А, если, предположим, знает, что это невыполнимо в данный момент? Тогда, это, по крайней мере, некрасиво с его стороны: я руки умыл, а ты, как хочешь, так и выкручивайся. Завтра, в аналогичной ситуации я с ним поступлю также. Может, для кого-то такое положение вещей и нормально, но не для меняю.

            Поэтому и свалил от туда.
          0
          До тех пор, пока безопасники не смогут сформулировать конструктивное определение безопасности (а не отрицающее перечисление «не должно быть» или неконструктивный квантор «не должно быть никаких»), до этого момента говорить про абсолютные метрики смысла нет. Всё это ИМХОизм и потрясание экспертным заключением, невоспроизводимым и непроверяемым.

          Only users with full accounts can post comments. Log in, please.