Существуют некоторые общие принципы борьбы с уязвимостями, которые можно использовать для управления мышлением и принятием решений в области безопасности.
Во-первых, всегда важно понимать, что мы защищаем, поскольку это влияет на действия, которые нам необходимо предпринять. Например, если наш артефакт — веб-сервер, то нам необходимо защитить его от недоверенных пользователей. Если наш артефакт — криптографическое программное обеспечение, то нам, очевидно, необходимо защитить его даже от пользователей, имеющих физический доступ к системе. В каждом случае мы четко различаем, каковы границы риска и на чем нужно сосредоточиться.
Во-вторых, конфигурация является частью базы кода. Если злоумышленник имеет доступ к вашей конфигурации, это, по сути, то же самое, как если бы злоумышленник имел доступ к вашей базе кода.
Учитывая цунами уязвимых систем, вызванное недавней уязвимостью Log4j 2.x (Log4Shell), мы, как организация, занимающаяся безопасностью, возможно, будем более внимательно искать другие потенциальные уязвимости. Однако, возможно, нам также следует воспользоваться этой возможностью, чтобы сделать паузу и подумать, прежде чем спешить судить о каждой потенциальной проблеме безопасности, которую мы обнаруживаем в нашем коде. Более хладнокровные люди могут также предположить, что не все, что вызывает проблемы с безопасностью, обязательно классифицируется как одинаковое.
В качестве примера мы можем посмотреть на недавнее распределение CVE-2021-4104 по сравнению с Log4j 1.x через эту призму. Для использования этого требуется прямой доступ к файлу конфигурации для управления настройками. Похожая тема сейчас возникает вокруг проекта Logback, а также примеров из сообщества Node.
Давайте проясним: выявление потенциальных уязвимостей по-прежнему является хорошей вещью. Но в разгар паники в СМИ также уместно изучить наше собственное критическое мышление и восстановить основу сообщества, на которую нам следует обращать внимание. Создание еще одного цунами потенциальных уязвимостей может принести больше вреда, чем пользы, еще больше перегрузив и без того перегруженные команды по безопасности и подорвав текущие усилия отрасли по защите программного обеспечения с открытым исходным кодом.
Критическое мышление о CVE
Обсуждение, указанное в теме выше, поднимает несколько очень интересных вопросов.
Например, если для использования уязвимости требуется привилегированный доступ к файлам внутри системы, действительно ли это уязвимость? Практически любое современное программное обеспечение можно настроить на разрешение небезопасных операций. Аналогичным образом, вполне возможно, что sshd настроен на разрешение входа в систему с пустым паролем. Должны ли мы считать это новой уязвимостью в sshd?
Одним из механизмов, который использует наша команда безопасности, является идея рассмотрения ожидаемого и неожиданного поведения. Если часть программного обеспечения можно настроить для удаленного выполнения кода и эта функциональность хорошо документирована, является ли это действием, создающим уязвимость, которую можно использовать? Это можно считать ожидаемым поведением, а не уязвимостью безопасности само по себе.
Должны ли мы разрабатывать программное обеспечение без небезопасных настраиваемых шаблонов? Это можно рассматривать как похвальную цель, но она несколько противоречит тому, как мы разрабатывали программное обеспечение с открытым исходным кодом на протяжении последних 30 или более лет. Типичная цель разработки программного обеспечения с открытым исходным кодом — достичь высочайшего уровня настраиваемости, позволяющей реализовать все варианты использования. В последние годы разумные настройки безопасности по умолчанию стали второстепенной целью, но принцип всегда заключался в том, чтобы предоставить пользователям возможность настраивать программное обеспечение так, как они считают нужным, безопасным или небезопасным.
В настоящее время мы также живем в мире, где CVE легко создать как частным лицам, так и компаниям, и они ценны из-за своей надежности и возможности кэширования. Эта уникальная комбинация может привести к проблематичным заданиям. С другой стороны, возможность беспрепятственно сообщать о потенциальных проблемах безопасности может быть только положительным моментом, поэтому мы сталкиваемся с чем-то вроде парадокса.
Как отрасль, мы становимся все лучше и лучше в выявлении уязвимостей, создавая при этом гораздо больше программного обеспечения, поэтому легко увидеть потенциал перегрузки.
Правильное выявление уязвимостей в программном обеспечении, их оценка и принятие мер по их устранению — это очень ресурсоемкий и в основном ручной процесс, особенно в сложных случаях. Хотя методы машинного обучения становятся все более полезными, а искусственный интеллект может оказаться более ценным, во многих случаях (по иронии судьбы) компьютеры не так уж полезны для диагностики.
Взгляд в будущее
Изложенные здесь пункты обсуждения не предназначены для изменения какой-либо конкретной CVE, а скорее для того, чтобы начать разговор о будущем оценки уязвимостей и о том, что мы считаем небезопасным сейчас и в будущем. Создание надежного и общего программного обеспечения с открытым исходным кодом, подходящего для распространенных случаев использования, неизбежно приводит к настраиваемым режимам, обеспечивающим большую или меньшую безопасность. Если мы хотим продолжать это делать, пользователь также должен понимать подводные камни использования. Возможно, ответом является лучшая документация и обучение, а также сортировка потенциальных уязвимостей в обычных случаях использования.
Ссылка: https://snyk.io/blog/when-is-a-cve-not-a-cve/
Оригинал статьи, автор: CNCSO, при перепечатке указать источник: https://cncso.com/ru/security-of-context.html
