Продолжаем рассматривать недавние изменения в приказ ФСТЭК России №17. В этот раз – анализ уязвимостей ГИС.
Теперь анализ уязвимостей ГИС требуется проводить на 3 из 6 этапах жизненного цикла системы защиты ГИС: формирования требований, внедрения и аттестации.
1. На этапе анализа угроз безопасности информации ГИС, необходимо провести анализ возможных уязвимостей ИС, используя при этом БДУ ФСТЭК России, а также иные источники данных об уязвимостях в качестве исходных данных. В модель угроз нужно включить описание возможных уязвимостей ИС.
Основное отличие от других этапов кроется в слове “возможных”. Не фактических, а именно возможных. А при наличие хорошей фантазии, у нас будет возможно всё. На сколько я понимаю, тут нужна некая классификация всех возможных уязвимостей и исключение неподходящих типов уязвимостей по определенным причинам (отсутствие объекта воздействия, определенные структурные характеристики, неиспользуемые ИТ).
Проблема в том, что в БДУ ФСТЭК в разделе Уязвимости отсутствует подобная классификация уязвимостей. Кроме того, разделе Уязвимости приведены только фактические уязвимости ПО. А как же уязвимости ГИС в целом? Недостатки орг. мер?
На самом деле, перечень таких возможных уязвимостей скрывается в неструктурированном виде в тексте угроз БДУ ФСТЭК: “Данная угроза обусловлена уязвимостями некоторых системных (материнских) плат – наличием механизмов аппаратного сброса паролей, установленных в BIOS/UEFI” или “Данная угроза обусловлена слабостями механизмов фильтрации сетевого трафика и антивирусного контроля на уровне организации”.
2. На этапе внедрения системы защиты информации требуется провести уже фактический анализ уязвимостей.
“При анализе уязвимостей информационной системы проверяется отсутствие известных уязвимостей средств защиты информации, технических средств и программного обеспечения, в том числе с учетом информации, имеющейся у разработчиков и полученной из других общедоступных источников, правильность установки и настройки средств защиты информации, технических средств и программного обеспечения, а также корректность работы средств защиты информации при их взаимодействии с техническими средствами и программным обеспечением.
По результатам анализа уязвимостей должно быть подтверждено , что в информационной системе отсутствуют уязвимости, содержащиеся в банке данных угроз безопасности информации ФСТЭК России, а также в иных источниках, или их использование (эксплуатация) нарушителем невозможно.”
Но хорошо, что уязвимости имеют такие поля как Производитель, Наименование ПО, Версия ПО. Составив заранее полный перечень ПО, можно сделать выборку нужных уязвимостей. Но что делать с результатами? Например, для Windows 8.1 – 247 уязвимостей в БДУ. Далее нужно в каждой пройти по ссылке на внешние источники и проверить что там предлагалось для устранения уязвимостей, проверить наличие установленных обновлений для данных уязвимостей.
Вручную - сложно. Хотелось бы, чтобы сканнеры уязвимостей могли работать с БДУ и делать всё за нас. Давайте посмотрим…
RedCheck от Алтекс-Софт: “RedCheck производит поиск уязвимостей по нашей базе ovaldb которая синхронизируется с БД угроз безопасности информации ФСТЭК России! Список уязвимостей Вы можете посмотреть на сайте базы данных https ://ovaldb .altx -soft .ru /Definitions .aspx ?refsource =FSTEC .”
Вроде ок. Жаль только последняя уязвимость по ссылке – от 2016 г. А в БДУ уже куча за 2017 г.
Ревизор Сети 3.0 от ЦБИ: “Ревизор Сети изначально осуществляет поиск включенных в БДУ ФСТЭК России (http://bdu.fstec.ru) уязвимостей, содержащихся в операционных системах Windows и функционирующих в них приложениях и средствах защиты информации, в том числе российской разработки. Помимо поиска уязвимостей из базы данных уязвимостей ФСТЭК России Сетевой сканер «Ревизор Сети» версии 3.0 осуществляет поиск уязвимостей, содержащихся в таких источниках, как cve.mitre.org, ovaldb.altx-soft.ru, microsoft.com и других источниках. ”
XSpider от Positive Technologies “Обязательно такая возможность будет. В июне в рамках пересертификации XSpider будет передана в испытательную лабораторию ФСТЭК сборка уже с таким функционалом ”.
Сканер-ВС от Эшелон “Сканер-ВС поддерживает поиск уязвимостей по БДУ ФСТЭК России”. Правда опыт показал, что текущая, сертифицированная версия – не поддерживает.
Итого, в перспективе возможно за нас всё будут делать сканеры, но в данный момент готового отчета, подтверждающего отсутствие уязвимостей из БДУ ФСТЭК я не обнаружил. Да и с актуальностью баз вопросы – надо будет внимательно проверять результаты и возможно последние уязвимости просматривать вручную.
Кроме того, не забываем, что в анализ уязвимостей входит ещё анализ настройки СЗИ, ПО и ТС и анализ корректности работы СЗИ.
3. На этапе аттестации требуется провести следующие испытания “анализ уязвимостей информационной системы, в том числе вызванных неправильной настройкой (конфигурированием) программного обеспечения и средств защиты информации” при этом в качестве исходных данных используются “результаты анализа уязвимостей информационной системы” . Это как вообще?
Просто повторяем то что делали на этапе внедрения? С учетом последних требований к разделению аттестаторов и внедренцев, видимо тут расчет на выборочный независимый дублирующий анализ.
Киверина Н.Ш.
Кандидат технических наук, Евразийский национальный университет имени Л.Н.Гумилева
АНАЛИЗ УЯЗВИМОСТИ ИНФОРМАЦИОННОЙ СИСТЕМЫ
Аннотация
В статье описывается метод анализа уязвимостей любой информационной системы. Также представлены по категориям угрозы безопасности. С помощью данной методики составляется документ, содержащий описание информационной системы, ее компонент, всех потенциальных для системы угроз и мер, необходимых для их устранения.
Ключевые слова: угрозы безопасности, информационные системы, анализ.
Kiverina N.SH.
Candidate of Technical Sciences, Eurasian National University of L.N.Gumilev
ANALYSIS OF THE VULNERABILITY OF AN INFORMATION SYSTEM
Abstract
Describes a method of analysis of any information system vulnerabilities. Also represented are a security threat. Using this technique, a document containing a description of the information system, its components, all potential for threats and actions needed to address them.
Keywords: security threats, information systems, analysis.
Обеспечение защищенности информационной системы является одним из важнейших этапов ее разработки и поддержки. Очевидно, что информационная система, отданная в производство без каких-либо средств защиты от угроз, не несет никакой практической и материальной ценности. Например, система совершения и обработки торговых сделок, реализованная без использования алгоритмов шифрования, не может гарантировать целостность обрабатываемых данных. Естественно, такая система не должна и не будет использоваться в реальных торговых операциях. При проектировании любой новой информационной системы, а также при использовании уже реализованной системы стоит проблема гарантии ее защищенности от компрометации. Гарантия нужна не только для конечного пользователя, но и, например, для лица, выделяющего средства на разработку информационной системы. Анализ защищенности разрабатываемой системы рекомендуется проводить с помощью моделирования потенциальных угроз. В последнее время новые уязвимости появляются каждый день, поэтому важно уметь классифицировать угрозы и оценивать их по степени риска. Информационная безопасность определяется всеми аспектами, связанными с достижением и поддержанием конфиденциальности, целостности, доступности, неотказуемости, подотчетности, аутентичности и достоверности информации или средств ее обработки. Защита информации должна носить комплексный характер, однако, необходимо учитывать возможность возникновения угроз, специфичных для данной информационной системы. На этапе проектирования системы защиты информации важно не упустить существенных деталей и, в то же время, не переоценить некоторые из них. Необходимо знать о характере возможных опасностей, классифицировать угрозы и проводить меры по их устранению. Основной принцип обеспечения безопасности информационной системы лежит в анализе потенциальных угроз, проведении мер по их устранению и последующем анализе состояния безопасности системы. Моделирование угроз позволяет структурировать процесс обеспечения безопасности информационной системы и обозначить угрозы, которые способны нанести наибольший ущерб и которые необходимо устранить в первую очередь. Нельзя обеспечить безопасность информационной системы без должного понимания специфики и происхождения угроз. Обычно, уязвимости устраняются по мере их обнаружения, часто случайным образом. Используя этот подход, невозможно ответить на вопрос: «Достаточно ли безопасна информационная система?». Моделирование угроз не является единовременным процессом. Это итеративный подход, который начинается с ранних стадий разработки системы и продолжается на протяжении всего ее жизненного цикла. Необходимость итеративного подхода обусловлена двумя причинами. Во-первых, физически невозможно обнаружить и зафиксировать все потенциальные для системы угрозы за один раз. Во-вторых, разрабатываемое приложение (информационная система) непременно адаптируется под постоянно изменяющиеся пользовательские и функциональные требования. Поэтому моделирование угроз необходимо повторять на протяжении всего развития информационной системы. Специалисты по безопасности компании Microsoft предложили процесс моделирования угроз, состоящий из шести этапов : 1. Определение защищаемых ресурсов. 2. Обзор архитектуры. 3. Декомпозиция системы. 4. Определение угроз. 5. Документация угроз. 6. Приоритезация угроз. На первом этапе определяются все ресурсы, которые необходимо защищать. Это могут быть конфиденциальные данные, базы данных, веб-страницы и т.д. Далее проводится документация функций информационной системы, ее архитектуры, физической конфигурации и технологий, использованных для ее реализации. Возможен поиск уязвимостей в дизайне информационной системы. Определение используемых в реализации технологий поможет не упустить специфичных для них уязвимостей и в дальнейшем сконцентрироваться на их устранении. На этапе декомпозиции система разбивается на компоненты для создания профиля безопасности (который описывает реализацию аутентификации, авторизации, криптографии и других аспектов безопасности в системе). Проверяются основные вопросы безопасности, выделяются границы доверия, потоки данных и их входные точки. Система анализируется на исполнение следующих свойств: проверка пользовательских данных, аутентификация и авторизация, криптографическая защита передачи данных, управление исключениями, аудит и др. Профиль безопасности описывает реализацию аутентификации, авторизации, криптографии и других аспектов безопасности в системе. Далее определяются потенциальные угрозы для всех компонент системы. Компания Microsoft предлагает методику STRIDE для определения и категоризации угроз . Моделирование при помощи STRIDE поможет обеспечить исполнение в информационной системе всех свойств безопасности. STRIDE – аббревиатура от: Spoofing Identity (подмена личности). Tampering with Data (изменение данных). Repudiation (отказ от совершенной операции). Information Disclosure (разглашение сведений). Denial of Service (отказ в обслуживании). Elevation of Privilege (повышение прав доступа).
По этой методике определяются угрозы для каждого компонента информационной системы в зависимости от категории угрозы. Угрозы типа «Подмена личности» актуальны для систем, в которых реализуются разные уровни доступа пользователей. Пользователь не должен иметь возможность притвориться другим пользователем или прочитать атрибуты другого пользователя. Угрозы типа «Изменение данных» реализуют возможность пользователя повлиять на логику работы системы через доступные интерфейсы. Система должна тщательно проверять все исходящие от пользователя данные в процессе их использования и вплоть до момента их сохранения в системе. При недостаточном аудите транзакций в системе угрозы типа «Отказ от совершенной операции» реализуют возможность пользователя отказаться от выполненных им каких-либо действий в системе, что может повлиять на достоверность циркулирующей по системе информации. Например, пользователь может заявить «Я не перечислял денежные средства на этот счет». При недостаточном аудите операций невозможно проверить данное заявление. Угрозы типа «Разглашение сведений» реализуют возможность публикации конфиденциальных данных в системе. Возможно, в системе обнаружится утечка информации. Дизайнеры системы также должны учитывать тот факт, что на нее будут проводиться атаки типа DoS (отказ в обслуживании). Необходимо убедиться, что ресурсоемкие процессы будут недоступны неавторизованным пользователям. Такими процессами могут являться: чтение больших файлов, сложные вычисления, исполнение длинных запросов к базе данных и т.д. Если в системе различаются пользовательские и административные роли, то необходимо убедиться в невозможности повышения прав доступа. Все действия в системе должны проверяться по матрице доступа. На следующем этапе моделирования все определенные угрозы необходимо зафиксировать в представленном далее виде:
На последнем этапе процесса расставляются приоритеты по устранению угроз в зависимости от их риска. Это позволит заняться в первую очередь угрозами, которые могут нанести системе наибольший ущерб. Экономически невыгодно устранять абсолютно все определенные угрозы, поэтому возможно опустить угрозы, вероятность реализации которых стремится к нулю и ущерб от которых минимален. В итоге, для разработчиков информационной системы представляется документ, позволяющий им сформировать отчетливое понимание о потенциальных угрозах и рисках.
Литература
References
Анализ защищенности - это процесс проверки инфраструктуры организации на наличие возможных уязвимостей сетевого периметра, виртуальной инфраструктуры, вызванных в том числе ошибками конфигурации, а также программного обеспечения и исходного кода приложений. Другими словами, при анализе защищенности проверяется безопасность различных информационных систем, как внутренних, так и внешних.
Анализ защищенности проводится с целью определения незакрытых уязвимостей в инфраструктуре и поиска слабых мест, которые могут быть использованы злоумышленниками для получения доступа во внутреннюю сеть организации из интернета. Одной из причин такой проверки могут служить требования регуляторов (например, ФСТЭК России) по проведению анализа защищенности государственных информационных систем и систем персональных данных. Такой анализ должен быть проведен на момент формирования требований к защищенности инфраструктуры и выполняться периодически уже после проведения мероприятий по защите и использования сертифицированных средств защиты.
Для анализа защищенности чаще всего используются сканеры защищенности, а также проводятся тесты на проникновение с привлечением сторонних специалистов.
Результатом работы сканеров защищенности являются подробные отчеты с описаниями найденных уязвимостей и возможных путей их устранения, что позволяет повысить уровень защищенности инфраструктуры организации. В то же время использование сканера защищенности предоставляет следующие преимущества:
При этом при проверке сканеры защищенности способны выявлять уязвимости следующих объектов:
Сканеры защищенности могут работать в двух режимах:
Режим статического сканирования. Позволяет проводить пассивный анализ инфраструктуры. В данном случае проверка на наличие уязвимостей происходит по косвенным признакам - проверяются заголовки портов, обнаруженные на сетевых устройствах, после чего сравниваются с базой данных уязвимостей. В случае совпадения сканер защищенности сигнализирует о найденной уязвимости.
Режим динамического сканирования. Позволяет проводить активный анализ инфраструктуры. При таком режиме работы сканер уязвимостей действует как злоумышленник и имитирует атаки, проверяя реакцию системы. Исходя из возможностей этого режима, он является более медленным, однако считается более точным при выявлении уязвимостей.
Принцип работы сканеров уязвимостей заключается в последовательном прохождении следующих шагов:
1. Сбор данных об инфраструктуре.
2. Поиск потенциальных уязвимостей методом сканирования.
3. Подтверждение найденных уязвимостей динамическими методами.
4. Создание отчетов на основе результатов анализа.
5. Автоматические исправление найденных уязвимостей (при наличии данной функциональности у выбранного сканера защищенности).
IDENTIFICATION OF INFORMATION SYSTEMS VULNERABILITIES
Sergei Konovalenko
postgraduate of Krasnodar higher military school,
Russia, Krasnodar
Igor Korolev
doctor of Engineering, Professor, Professor of the department of protected information technologies, Krasnodar higher military school,
Russia, Krasnodar
АННОТАЦИЯ
Проведена оценка существующих средств анализа защищенности информационных систем, на основе которой построены модели выявления, идентификации и оценки образов уязвимостей информационных систем. Определены основные характеристики (элементы), присущие образам существующих уязвимостей информационных систем.
ABSTRACT
An assessment of existing tools for analyzing information systems security was performed. On the basis of the achieved results the models of detection, identification and evaluation of information systems vulnerabilities images were built. The main characteristics (elements) inherent to the images of the existing information systems vulnerabilities were defined.
Ключевые слова: выявление; информационная система; идентификация; оценка; описание образа; уязвимость.
Keywords: detection; information system; identification; evaluation; description of the image; vulnerability.
Любой информационной системе (далее по тексту – ИС) присущи определенные уязвимости, перечень которых является достаточно объемным и постоянно подлежит обновлению (расширению). Уязвимости ИС обусловлены недостатками (ошибками), возникающими в процессе «жизненного цикла» этой системы. В этом виду, возможность реализации угроз безопасности ИС напрямую зависит от действий злоумышленника по обнаружению и использованию присущих ей уязвимостей. С другой стороны, процесс выявления уязвимостей ИС, проводимый специалистом, является основополагающим в противодействии злоумышленнику на ранних стадиях реализации атак.
Целью данной статьи является построение обобщенных моделей выявления, идентификации и оценки образов уязвимостей ИС, а также определение характеристик (элементов), присущих образам существующих уязвимостей, что позволит специалисту более качественно систематизировать свою работу в области обеспечения безопасности контролируемой ИС.
Согласно ГОСТ Р 56545-2015, «уязвимость» – это недостаток (слабость) программного (программно-технического) средства или ИС в целом, который (которая) может быть использована для реализации угроз безопасности информации . «Информационная система» – это совокупность содержащейся в базах данных (далее по тексту – БД) информации и обеспечивающих ее обработку информационных технологий и технических средств .
Любую уязвимость ИС можно представить в виде образа, который включает в себя набор определенных характеристик (элементов, описывающих данную уязвимость), формируемых по определенным правилам.
Описание уязвимости ИС – это информация о выявленной (обнаруженной) уязвимости . Правила описания уязвимости ИС – это совокупность положений, регламентирующих структуру и содержание описания уязвимости .
Согласно образы уязвимостей подразделяются на образы известных уязвимостей, образы уязвимостей нулевого дня и образы впервые выявленных уязвимостей. Известная уязвимость – это уязвимость, опубликованная в общедоступных источниках с описанием соответствующих мер защиты информации, исправлений недостатков и соответствующих обновлений . Уязвимость нулевого дня – это уязвимость, которая становится известной до момента выпуска разработчиком компонента ИС соответствующих мер защиты информации, исправлений недостатков или соответствующих обновлений . Впервые выявленная уязвимость – это уязвимость, неопубликованная в общедоступных источниках .
Каждому типу образов уязвимостей ИС присущи как общие, так и специфические характеристики (элементы), которые можно свести в таблицу. Пример таблицы представлен ниже.
Таблица 1.
Элементы различных типов образов уязвимостей ИС
|
Характеристики образа уязвимости |
Элемент, присущий образу известной уязвимости |
Элемент, присущий образу уязвимости нулевого дня |
Элемент, присущий образу впервые выявленной уязвимости |
|
|
Место обнаружения (выявления) уязвимости в ИС. |
||||
|
Способ обнаружения (выявления) уязвимости. |
||||
|
Наименование уязвимости. |
||||
Прежде чем перейти к моделям выявления, идентификации и оценки образов уязвимостей, необходимо пояснить, что ИС состоит из уровней :
Каждому из уровней ИС соотносят различные типы (классы) уязвимостей. Для выявления уязвимостей необходимо разрабатывать модели выявления, идентификации и оценки уязвимости.
Основными источниками возникновения уязвимостей ИС являются :
Для выявления, идентификации и оценки уязвимостей ИС, а также формирования отчетов и устранения (нейтрализации) уязвимостей, используются средства анализа защищенности сети (далее по тексту – САЗ) (сканеры безопасности (далее по тексту – СБ)), которые можно разделить на два типа :
Актуальность применения САЗ (СБ) обусловлена тем, что специалист способен заблаговременно определить достаточно большой перечень типов (классов) уязвимостей, присущих контролируемой ИС, и предпринять необходимые меры (в отдельных случаях, попытаться предпринять) по их устранению или исключению (минимизации) возможности использования обнаруженных уязвимостей злоумышленником.
Для систематизации работы специалиста в области обеспечения безопасности, контролируемой ИС и на основе проведенного анализа строится обобщенная модель выявления образов уязвимостей ИС (рисунок 1).
Рисунок 1. Обобщенная модель выявления образов уязвимостей ИС
Процесс выявления уязвимостей ИС строится посредствам выполнения пассивных проверок (сканирование – scan) и активных проверок (зондирование – probe) наличия уязвимостей контролируемой ИС.
В процессе сканирования САЗ, отправляя соответствующие запросы в адрес контролируемой ИС (на порты контролируемого хоста), анализирует обратно возвращаемые баннеры (заголовки пакетов данных) и делает соответствующие выводы о типе ИС и наличии потенциальных (возможных) ее уязвимостей. Результат сканирования не всегда на сто процентов говорит о наличии возможных (типовых) уязвимостей ИС, так как текстовое содержание баннера могло быть специально модифицировано, либо известные уязвимости, присущие данной ИС, были устранены специалистом в процессе ее реализации (использования). Еще одним способом выполнения сканирующих действий являются активные зондирующие проверки, которые предоставляют возможность проанализировать возвращаемый цифровой слепок (fingerprint) фрагмента ПО контролируемой ИС (т. е. выполнить процесс сравнения полученного результата с цифровым слепком известной уязвимости данного типа ИС). Данный способ обеспечивает более надежную и точную процедуру выявления возможных (типовых) уязвимостей контролируемой ИС.
В процессе зондирования САЗ имитирует выполнение атаки на контролируемую ИС, используя образ возможной (типовой) уязвимости, полученной при сканировании. Результат процесса зондирования является самой точной и надежной информацией о наличии уязвимостей контролируемой ИС. Данный способ применяется не всегда, так как существует вероятность нарушения работоспособности (вывода из строя) контролируемой ИС. Решение на применение вышеуказанного способа принимает администратор сети в случаях не эффективного выполнения или необходимости подтверждения результатов сканирования и активных зондирующих проверок.
Результаты сканирования и зондирования поступают в БД уязвимостей, в которой хранятся образы уязвимостей контролируемой ИС. На основании процедуры сравнения образа обнаруженной уязвимости с образами уязвимостей контролируемой ИС САЗ формирует отчет об отсутствии или наличии совпадений в образах уязвимостей (обнаружение уязвимостей), который сохраняется в БД уязвимостей.
Детализирует обобщенную модель выявления образов уязвимостей обобщенная модель идентификации и оценки образов уязвимостей ИС (рисунок 2).
Рисунок 2. Обобщенная модель идентификации и оценки образов уязвимостей ИС
Процесс идентификации образа обнаруженной уязвимости ИС, который имеет специфические характеристики (элементы), осуществляется посредствам процедуры его сравнения с образами известных уязвимостей и уязвимостей нулевого дня, хранящихся в БД уязвимостей. Формализованное описание известных уязвимостей и уязвимостей нулевого дня оформляется в виде паспортов, которые содержат информацию о специфических характеристиках (элементах) конкретной уязвимости. Для точной идентификации образа обнаруженной уязвимости он должен содержать информацию о наименовании и версии ПО ИС, в которой обнаружена уязвимость, о идентификаторе, наименовании и классе обнаруженной уязвимости. На основании вышеуказанной информации САЗ соотносит образ обнаруженной уязвимости к одному из типов образов уязвимостей. Для качественного проведения оценки идентифицированный образ уязвимости, в свою очередь, должен содержать информацию об идентификаторе и типе недостатка ИС, при котором обнаружена уязвимость, о месте обнаружения уязвимости в ИС, о способе выявления уязвимости. Процесс оценки образа уязвимости оканчивается выработкой рекомендаций по устранению уязвимости или по исключению возможности ее использования. В случаях, если был обнаружен образ впервые выявленной уязвимости, то САЗ помещает информацию о нем в БД уязвимостей с формированием нового паспорта уязвимости нулевого дня. При выпуске разработчиком ИС мер защиты информации, необходимых обновлений и при исправлении недостатков, уязвимость нулевого дня переходит в статус известной уязвимости.
Поводя итоги данной статьи, отмечаем, что специалист по обеспечению безопасности ИС обязан постоянно проводить работу по выявления уязвимостей в системе, четко представлять и понимать процессы, протекающие в САЗ, следить за обновлением (расширением) БД уязвимостей, своевременно устранять недостатки в системе, устанавливать соответствующие меры защиты и обновления на контролируемую ИС.
Список литературы:
Инструментальные средства анализа уязвимостей (известные также как оценка уязвимостей ) тестируют сеть или хост для определения наличия уязвимостей для известных атак. Анализ уязвимостей предоставляет дополнительную информацию для систем обнаружения проникновения. Используемыми источниками информации являются атрибуты состояния системы и выходные данные осуществленных атак. Источники информации являются частью механизма оценки. Интервал времени анализа либо является фиксированным, либо определяется параметром в пакетном режиме, типом анализа является определение злоупотреблений . Это означает, что системы оценки уязвимостей являются пакетным режимом детекторов злоупотреблений, которые оперируют с информацией о состоянии системы, и результатом становятся специальные тестовые подпрограммы.
Анализ уязвимостей - очень сильная технология управления безопасностью, но эта технология является лишь дополнением к использованию IDS , а отнюдь не ее заменой. Если организация полагается исключительно на инструментальные средства анализа уязвимостей для слежения за системой, осведомленный атакующий может просмотреть систему анализа уязвимостей , заметить, когда выполняется анализ, и осуществить атаку во время интервала между этими проверками.
Тем не менее системы анализа уязвимостей могут создавать "моментальный снимок" состояния безопасности системы в конкретное время. Более того, так как они являются исключительно тестовыми системами поиска уязвимостей для большого числа известных атак, системы анализа уязвимостей могут позволять менеджеру безопасности контролировать ошибки человека или выполнять аудит системы для анализа согласованности с конкретной политикой безопасности системы.
Разница между системами анализа уязвимостей и системами обнаружения проникновения
Системы анализа уязвимостей аналогичны системам обнаружения проникновений, так как и те и другие следят за конкретными симптомами проникновения и другими нарушениями политики безопасности. Однако системы анализа уязвимостей рассматривают статический взгляд на такие симптомы, в то время как обнаружение проникновений исследует их динамически. Здесь такая же разница, как между кадром фотоснимка и прокручиванием видео.
Общий процесс оценки уязвимостей состоит в следующем:
Коммерческие системы оценки уязвимостей часто оптимизируют данный процесс тем, что выполняют параллельно несколько инструментальных средств оценки.
Существует два основных способа классификации систем анализа уязвимостей : первый – по расположению, из которого информация об оценке получена, и второй – по информации, которой располагает инструментальное средство анализа уязвимостей . При использовании первой схемы классификации для оценки уязвимостей системы классифицируются либо как network-based , либо как host-based . При использовании второй схемы системы классифицируются как credentialed или non-credentialed . Эти термины указывают, делался ли анализ с креденциалами или без креденциалов (таких, как IDs и пароли или другая идентификационная и аутентификационная информация, с помощью которой предоставляется доступ к внутренним системам). Мы будем использовать первую схему классификации для описания различных подходов к анализу уязвимостей.
Системы host-based анализа уязвимостей определяют уязвимость, анализируя доступный источник системных данных, такой как содержимое файлов, параметры конфигурации и другая информация о статусе. Данная информация обычно доступна с использованием стандартных системных запросов и проверки системных атрибутов. Так как информация получена в предположении, что анализатор уязвимости имеет доступ к хосту, данный тип инструментальных средств анализа также иногда называется credential-based оценка уязвимости. Такая оценка определяется как пассивная.
Наилучшего результата достигают host-based оценки уязвимостей , которые имеют возможность выполнять привилегированные атаки. Это такие атаки, которые могут получить привилегии superuser или root на UNIX-системе или доступ administrator на Windows-системе.
Системы network-based анализа уязвимостей получили распространение в последние несколько лет. Данные системы требуют установления удаленного соединения с целевой системой. Они могут реально проводить атаки на систему, понимать и записывать ответы на эти атаки или прощупывать различные цели для поиска слабых мест, которые следуют из их ответов. Такое проведение атак или прощупывание может происходить независимо от того, есть ли разрешение на доступ к целевой системе; следовательно, это можно считать non-credential анализом. Более того, так как network-based анализ уязвимостей выглядит как реальная атака или сканирование целевой системы, он также иногда обозначается как активный анализ.
Инструментальные средства network-based анализа уязвимостей иногда определяются как инструментальные средства обнаружения проникновения. Хотя, как уже обсуждалось ранее, это корректно в соответствии с некоторыми определениями обнаружения проникновения, все же программный продукт анализа уязвимостей не является законченным решением обнаружения проникновения для большинства окружений.
Существуют два метода, используемые при network-based оценки уязвимостей :
Преимущества систем анализа уязвимостей :
Недостатки и проблемы систем анализа уязвимостей :
Проверки целостности файлов являются другим классом инструментальных средств безопасности, которые дополняют IDS . Эти инструментальные средства используют дайджест сообщений или другие криптографические контрольные суммы для критичных файлов и объектов, сравнивая их с хранимыми значениями и оповещая о любых различиях или изменениях.
Использование криптографических контрольных сумм важно, так как атакующие часто изменяют системные файлы по трем причинам. Во-первых, изменение системных файлов могут быть целью атаки (например, размещение Троянских программ), во-вторых, атакующие могут пытаться оставить лазейку (back door) в систему, через которую они смогут снова войти в систему позднее, и, наконец, они пытаются скрыть свои следы, чтобы собственники системы не смогли обнаружить атаку.
Хотя проверка целостности файлов часто используется для определения, были ли изменены системные или выполняемые файлы, такая проверка может также помочь определить, применялись ли модификации для исправления ошибок к программам конкретных производителей или системным файлам. Это также является очень ценным при судебных разбирательствах, так как позволяет быстро и надежно диагностировать следы атаки. Она дает возможность менеджерам оптимизировать восстановление сервиса после произошедшего инцидента.
Свободно распространяемый продукт Tripwire (www.tripwiresecurity.com), возможно, является лучшим примером инструментального средства проверки целостности файлов.
