- Оценка уязвимости систем;
- Оценка систем на соответствие стандартам безопасности;
- Традиционное тестирование на проникновение в систему;
- Исследование приложений.
Прежде чем переходить к описанию конкретных видов мероприятий по оценке защищённости систем, расскажем о том, чем уязвимости отличаются от эксплойтов.
Уязвимость можно определить как дефект информационной системы, воспользовавшись которым можно нарушить её конфиденциальность, целостность или доступность. Существуют различные виды уязвимостей, с которыми можно столкнуться. Вот некоторые из них:
11.2.2. Оценка систем на соответствие стандартам безопасности
Следующий по сложности вид исследований - это оценка систем на соответствие стандартам безопасности. Подобные испытания систем распространены сильнее всего, так как они основаны на проверке требований, предписываемых государственными и индустриальными стандартами, распространяющимися на организации.Существует множество специализированных стандартов безопасности, однако, чаще всего встречается Payment Card Industry Data Security Standard (PCI DSS). Этот стандарт разработан компаниями, выпускающими платёжные карты. Ему должны соответствовать организации, обрабатывающие карточные платежи. Если говорить о других распространённых стандартах, можно отметить такие, как Defense Information Systems Agency Security Technical Implementation Guides (DISA STIG), Federal Risk and Authorization Management Program (FedRAMP), Federal Information Security Management Act (FISMA), и другие.
Корпоративный клиент может заказать подобное исследование или обратиться за результатами ранее проведённого исследования по разным причинам. В частности, инициатива может исходить от самого клиента, либо он может быть вынужден проводить обязательную проверку. В любом случае, такие исследования называют «оценкой систем на соответствие стандартам безопасности», или «исследованиями на соответствие стандартам безопасности», или «проверками на соответствие стандартам безопасности».
Оценка системы на соответствие стандартам обычно начинается с анализа уязвимостей. В случае с процедурой проведения аудита на соответствие стандарту PCI, оценка уязвимостей, если она проведена соответствующим образом, может удовлетворить нескольким основным требованиям стандарта. Среди них - требование 2: «Не использовать пароли и другие системные параметры, заданные производителем по умолчанию». Анализ системы на соответствие этому требованию можно провести с помощью инструментов из категории меню Password Attack (Взлом паролей). Далее, это требование 11: «Регулярно выполнять тестирование систем и процессов обеспечения безопасности». Соответствующую проверку можно провести с помощью инструментов из категории Database Assessment (Исследование баз данных). Некоторые требования нельзя проверить с помощью обычных инструментов сканирования на уязвимости. Среди них - требование 9: «Ограничить физический доступ к данным держателей карт», и 12: « Разработать и поддерживать политику информационной безопасности для всего персонала организации». Для проверки таких требований нужны дополнительные усилия.
На первый взгляд может показаться не вполне понятным, как использовать Kali Linux для выполнения некоторых проверок. Однако, Kali отлично подходит для решения подобных задач, причём, не только из-за богатого набора стандартных инструментов, но и потому, что она основана на Debian, что открывает возможность установки множества дополнительных приложений. Искать программы, реализующие необходимый функционал, можно в менеджере пакетов, используя ключевые слова, взятые из используемого стандарта информационной безопасности. Подобный поиск, почти наверняка, завершится выдачей нескольких заслуживающих внимания результатов. В настоящее время многие организации используют Kali Linux как платформу именно для оценки систем на соответствие стандартам безопасности.
11.2.3. Традиционное тестирование на проникновение в систему
В последнее время стало сложно подобрать подходящее определение для «традиционного теста на проникновение». Дело в том, что подобные тесты используются в различных сферах деятельности, как результат, все описывают их по-своему. Путаницы добавляет и то, что «тестированием на проникновение» всё чаще стали называть описанную выше оценку систем на соответствие стандартам безопасности, или даже обычную оценку уязвимостей. В подобных случаях исследование не выходит за рамки неких минимальных требований.В этом разделе мы не будем касаться споров об особенностях различных видов испытаний систем. Здесь мы расскажем об исследованиях, которые не ограничены некими «минимальными требованиями». Это - исследования, которые задуманы так, чтобы после их проведения можно было бы по-настоящему улучшить общую безопасность организации.
В противоположность видам исследований, которые мы обсудили ранее, традиционные тесты на проникновение не часто начинаются с определения области исследования. Вместо этого для них устанавливают определённые цели. Например: «смоделировать последствия компрометации внутреннего пользователя», или: «выяснить, что случилось бы, если бы организация попала под целенаправленную атаку, выполняемую внешним злоумышленником». Ключевой отличительной чертой подобных исследований является то, что в ходе их выполнения не только находят и оценивают уязвимости, но ещё и используют найденные проблемы для раскрытия наихудших вариантов развития событий.
В ходе тестирования на проникновение не полагаются исключительно на инструменты сканирования систем на уязвимости. Работа продолжается путём исследования находок, путём использования эксплойтов или испытаний для исключения ложноположительных результатов, делается всё возможное для того, чтобы обнаружить скрытые уязвимости, или то, что мы называем ложноотрицательными результатами.
Подобное исследование часто включает в себя эксплуатацию обнаруженных уязвимостей, оценку уровня доступа, который предоставляют эксплойты, и использование этого повышенного уровня доступа как отправной точки для дополнительных атак на целевую систему.
Здесь требуется критический анализ целевого окружения, ручной поиск уязвимостей, креативность, способность к нестандартному мышлению. Всё это - подходы к обнаружению дополнительных уязвимостей, которые требуют других инструментов, способных найти уязвимости там, где заканчиваются возможности самых мощных автоматических сканеров. Нередко, после завершения этого шага, весь процесс начинают снова и снова для того, чтобы обеспечить полное и качественное выполнение работы.
Несмотря на сложность и многоплановость традиционного тестирования на проникновение, ход такого исследования можно упорядочить, разбив на несколько шагов. Стоит отметить, что Kali упрощает подбор ПО для каждого из таких шагов. Итак, вот пошаговый план тестирования на проникновение с комментариями об используемых инструментах:
- Сбор информации. На данной фазе усилия пентестера направлены на то, чтобы узнать как можно больше о целевом окружении. Обычно эта деятельность неинвазивна и выглядит как обычная активность пользователей. Эти действия составляют основу для остальных этапов исследования и таким образом они должны привести к сбору как можно более полных данных о системе. Раздел Information Gathering (Сбор информации) меню Applications (Приложения) Kali Linux содержит в себе десятки инструментов, направленных на то, чтобы раскрыть как можно больше информации об исследуемой системе.
- Обнаружение уязвимостей. Этот шаг часто называют «активным сбором информации». Специалист, пытаясь идентифицировать потенциальные уязвимости в целевом окружении, ещё не атакует систему, но уже ведёт себя не так, как обычный пользователь. Именно здесь часто имеет место вышеописанное сканирование систем на уязвимости. На данном шаге исследования будут полезны программы из разделов Vulnerability Analysis (Анализ уязвимостей), Web Application Analysis (Анализ веб-приложений), Database Assessment (Исследование баз данных), и Reverse Engineering (Реверс-инжиниринг).
- Эксплуатация уязвимостей. Имея список обнаруженных потенциальных уязвимостей, на данном шаге исследования специалист пытается воспользоваться ими для того, чтобы найти точку опоры в целевой среде. В этом деле полезны инструменты, которые можно найти в категориях Web Application Analysis (Анализ веб-приложений), Database Assessment (Исследование баз данных), Password Attacks (Взлом паролей), и Exploitation Tools (Средства эксплуатации уязвимостей).
- Проникновение в системы и незаметное извлечение данных. После того, как исследователю удалось закрепиться в системе, нужно двигаться дальше. Как правило, на данном этапе ищут способ повышения привилегий до уровня, соответствующего тому, который необходим для достижения целевых систем, ранее недоступных, и скрытного извлечения их них секретной информации. На этом шаге можно обратиться к таким разделам меню приложений, как Password Attacks (Взлом паролей), Exploitation Tools (Средства эксплуатации уязвимостей), Sniffing & Spoofing (Сниффинг и спуфинг), и Post Exploitation (Действия после эксплуатации уязвимости).
- Подготовка отчётов. После завершения активной фазы исследования, нужно задокументировать произведённые действия и подготовить отчёт. Обычно этот шаг не отличается такой же технической сложностью, как предыдущие. Однако, благодаря качественным отчётам клиент может получить полную отдачу от проделанной работы, поэтому не стоит недооценивать важность этого этапа исследования. Соответствующие инструменты можно найти в разделе Reporting Tools (Средства подготовки отчётов) меню Applications (Приложения).
Среди часто встречающихся дополнительных настроек Kali Linux можно отметить следующие:
- Предустановка лицензированных коммерческих пакетов. Например, имеется пакет, вроде платного сканера уязвимостей, который планируется использовать в ходе многих сеансов тестирования на проникновение. Для того, чтобы избежать необходимости устанавливать этот пакет на каждой развернутой копии Kali, можно интегрировать его в систему. Как результат, этот пакет окажется установленным при каждом развёртывании Kali.
- Предварительно настроенная виртуальная частная сеть с обратным соединением. Это очень удобная функция для устройств, которые преднамеренно оставляют подключёнными внутри исследуемой сети. Такие устройства позволяют проводить «удалённые внутренние» исследования. Устройство с функцией обратного соединения подключается к компьютеру пентестера, создавая туннель, который можно использовать для подключения к внутренним системам. Дистрибутив Kali Linux ISO of Doom - это пример как раз такой специальной настройки системы.
- Предустановленные инструменты и программы собственной разработки. Многие организации имеют наборы инструментов собственной разработки, необходимые в ходе сеансов тестирования на проникновение, поэтому их предварительная установка при формировании специального образа системы позволяет экономить время.
- Предварительная настройка конфигурации ОС, в том числе - настройка отображение имён хостов на IP-адреса, обоев рабочего стола, настройки прокси-серверов, и так далее. Многие пользователи Kali предпочитают особые настройки системы. Если вы собираетесь регулярно переустанавливать систему, сохранение подобных настроек может иметь смысл.
11.2.4. Исследование приложений
Большинство мероприятий по оценке защищённости систем отличаются достаточно большими масштабами. Особенностью же исследований приложений является тот факт, что изучению подвергается конкретная программа. Подобные исследования становятся всё более распространёнными из-за сложности жизненно важных приложений, используемых компаниями. Многие из таких приложений созданы собственными силами этих компаний. Если нужно, исследование приложений может сопутствовать другим видам исследований. Среди видов приложений, которые могут быть исследованы на предмет безопасности, можно отметить следующие:- Веб-приложения. Эти приложения часто являются целями злоумышленников, так как они, обычно обладая значительной поверхностью атаки, доступны из интернета. Стандартные тесты нередко позволяют обнаружить базовые проблемы веб-приложений. Однако, более детальное исследование, хотя и может занимать немало времени, позволяет найти скрытые дефекты приложений. Для проведения подобных испытаний можно воспользоваться метапакетом kali-linux-web , который содержит множество полезных инструментов.
- Настольные приложения, распространяемые в виде исполняемых файлов. Серверные приложения - это не единственная цель злоумышленников. Настольные приложения также подвержены атакам. В прошедшие годы многие настольные программы, такие, как средства для чтения PDF-файлов, или видео-приложения, использующие интернет-ресурсы, подвергались множествам атак, что привело к их совершенствованию. Однако, всё ещё существует множество настольных приложений, в которых, при правильном подходе, можно найти массу уязвимостей.
- Мобильные приложения. С ростом популярности мобильных устройств, мобильные приложения становятся постоянными предметами исследований безопасности. Эти приложения очень быстро развиваются и меняются, поэтому в данной сфере методология исследований пока не достигла достаточной зрелости, что ведёт к регулярному, практически еженедельному, появлению новых методик. Инструменты, относящиеся к изучению мобильных приложений, можно найти в разделе меню приложений Kali Linux Reverse Engineering (Реверс-инжиниринг).
Существуют и более сложные сценарии исследования приложений. Такие исследования могут быть выполнены в интерактивном режиме. При их проведении используют модели чёрного и белого ящиков.
- Исследование методом чёрного ящика. Инструмент (или исследователь) взаимодействует с приложением, не обладая специальными знаниями о нём, или особым доступом к нему, превышающим возможности обычного пользователя. Например, в случае с веб-приложением, исследователь может иметь только доступ к функциям и возможностям, открытым пользователю, который не авторизован в системе. Любая используемая учётная запись будет такой же, которую обычный пользователь может зарегистрировать самостоятельно. Это не даст атакующему возможности анализировать функционал, который доступен только привилегированным пользователям, учётные записи которых необходимо создавать администратору.
- Исследование методом белого ящика. Инструмент (или исследователь) часто имеет полный доступ к исходному коду приложения, административный доступ к платформе, на которой оно выполняется, и так далее. Это гарантирует выполнение полного и тщательного анализа всех возможностей приложения, независимо от того, где именно находится изучаемая функциональность. Минус такого исследования заключается в том, что оно не является имитацией реальных действий злоумышленника.
В других случаях может быть применён гибридный подход, когда исследователь не обладает полным доступом к исходному коду приложения для платформы, на которой оно выполняется, но выданная ему учётная запись подготовлена администратором и даёт доступ к как можно большим возможностям приложения.
Kali - это идеальная платформа для всех подходов к исследованию приложений. После установки стандартного дистрибутива здесь можно найти множество сканеров, рассчитанных на конкретные приложения. Тут есть и инструменты для более продвинутых исследований. Среди них - редакторы исходного кода и скриптовые окружения. В деле исследования приложений вам могут оказаться полезными материалы из разделов Добавить метки
Продолжаем рассматривать недавние изменения в приказ ФСТЭК России №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. На этапе аттестации требуется провести следующие испытания “анализ уязвимостей информационной системы, в том числе вызванных неправильной настройкой (конфигурированием) программного обеспечения и средств защиты информации” при этом в качестве исходных данных используются “результаты анализа уязвимостей информационной системы” . Это как вообще?
Просто повторяем то что делали на этапе внедрения? С учетом последних требований к разделению аттестаторов и внедренцев, видимо тут расчет на выборочный независимый дублирующий анализ.
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. Обобщенная модель идентификации и оценки образов уязвимостей ИС
Процесс идентификации образа обнаруженной уязвимости ИС, который имеет специфические характеристики (элементы), осуществляется посредствам процедуры его сравнения с образами известных уязвимостей и уязвимостей нулевого дня, хранящихся в БД уязвимостей. Формализованное описание известных уязвимостей и уязвимостей нулевого дня оформляется в виде паспортов, которые содержат информацию о специфических характеристиках (элементах) конкретной уязвимости. Для точной идентификации образа обнаруженной уязвимости он должен содержать информацию о наименовании и версии ПО ИС, в которой обнаружена уязвимость, о идентификаторе, наименовании и классе обнаруженной уязвимости. На основании вышеуказанной информации САЗ соотносит образ обнаруженной уязвимости к одному из типов образов уязвимостей. Для качественного проведения оценки идентифицированный образ уязвимости, в свою очередь, должен содержать информацию об идентификаторе и типе недостатка ИС, при котором обнаружена уязвимость, о месте обнаружения уязвимости в ИС, о способе выявления уязвимости. Процесс оценки образа уязвимости оканчивается выработкой рекомендаций по устранению уязвимости или по исключению возможности ее использования. В случаях, если был обнаружен образ впервые выявленной уязвимости, то САЗ помещает информацию о нем в БД уязвимостей с формированием нового паспорта уязвимости нулевого дня. При выпуске разработчиком ИС мер защиты информации, необходимых обновлений и при исправлении недостатков, уязвимость нулевого дня переходит в статус известной уязвимости.
Поводя итоги данной статьи, отмечаем, что специалист по обеспечению безопасности ИС обязан постоянно проводить работу по выявления уязвимостей в системе, четко представлять и понимать процессы, протекающие в САЗ, следить за обновлением (расширением) БД уязвимостей, своевременно устранять недостатки в системе, устанавливать соответствующие меры защиты и обновления на контролируемую ИС.
Список литературы:
- Астахов А.С. Анализ защищенности корпоративных автоматизированных сетей // Информационный бюллетень Jet Info. – 2002. – № 7 (110). / – [Электронный ресурс]. – Режим доступа: URL: http://www.jetinfo.ru
- Горбатов В.С., Мещеряков А.А. Сравнительный анализ средств контроля защищенности вычислительной сети // Безопасность информационных технологий. – 2013. – № 1. / – [Электронный ресурс]. – Режим доступа: URL: http://www.bit.mephi.ru
- ГОСТ Р 56545-2015 «Защита информации. Уязвимости информационных систем. Правила описания уязвимостей». – М.: Стандартинформ, 2015.
- ГОСТ Р 56546-2015 «Защита информации. Уязвимости информационных систем. Классификация уязвимостей информационных систем». – М.: Стандартинформ, 2015.
- Лукацкий А.В. Как работает сканер безопасности? / – [Электронный ресурс]. – Режим доступа: http://www.citforum.ru/security/internet/scaner.shtml (Дата обращения: 14.09.2016).
- Лукацкий А.В. Обнаружение атак. – СПб. : Издательство «БВХ», 2001. – 624 с.
- Руководство пользователя программного комплекса «Средство анализа защищенности «Сканер-ВС». НПЭШ.00606-01. ЗАО «НПО «Эшелон», 2011.
- Сканер безопасности XSPider. Руководство администратора / – [Электронный ресурс]. – Режим доступа: http://www.ptsecurity.ru (Дата обращения: 15.09.2016).
- Сканер безопасности MaxPatrol. Система контроля защищенности / – [Электронный ресурс]. – Режим доступа: http://www.ptsecurity.ru (Дата обращения: 16.09.2016).
- Стивен Норткат, Джуди Новак. Обнаружение нарушений безопасности в сетях. 3-е изд.: Пер. с англ. – М.: Издательский дом «Вильямс», 2003. – С. 265–280.
Инструментальные средства анализа уязвимостей (известные также как оценка уязвимостей ) тестируют сеть или хост для определения наличия уязвимостей для известных атак. Анализ уязвимостей предоставляет дополнительную информацию для систем обнаружения проникновения. Используемыми источниками информации являются атрибуты состояния системы и выходные данные осуществленных атак. Источники информации являются частью механизма оценки. Интервал времени анализа либо является фиксированным, либо определяется параметром в пакетном режиме, типом анализа является определение злоупотреблений . Это означает, что системы оценки уязвимостей являются пакетным режимом детекторов злоупотреблений, которые оперируют с информацией о состоянии системы, и результатом становятся специальные тестовые подпрограммы.
Анализ уязвимостей - очень сильная технология управления безопасностью, но эта технология является лишь дополнением к использованию IDS , а отнюдь не ее заменой. Если организация полагается исключительно на инструментальные средства анализа уязвимостей для слежения за системой, осведомленный атакующий может просмотреть систему анализа уязвимостей , заметить, когда выполняется анализ, и осуществить атаку во время интервала между этими проверками.
Тем не менее системы анализа уязвимостей могут создавать "моментальный снимок" состояния безопасности системы в конкретное время. Более того, так как они являются исключительно тестовыми системами поиска уязвимостей для большого числа известных атак, системы анализа уязвимостей могут позволять менеджеру безопасности контролировать ошибки человека или выполнять аудит системы для анализа согласованности с конкретной политикой безопасности системы.
Разница между системами анализа уязвимостей и системами обнаружения проникновения
Системы анализа уязвимостей аналогичны системам обнаружения проникновений, так как и те и другие следят за конкретными симптомами проникновения и другими нарушениями политики безопасности. Однако системы анализа уязвимостей рассматривают статический взгляд на такие симптомы, в то время как обнаружение проникновений исследует их динамически. Здесь такая же разница, как между кадром фотоснимка и прокручиванием видео.
Процесс анализа уязвимостей
Общий процесс оценки уязвимостей состоит в следующем:
- определить множество атрибутов системы, которые будут рассматриваться в качестве шаблона;
- сохранить значения данного шаблона в безопасном репозитории данных. Данное множество может быть вручную определено как образец "идеальной конфигурации" или моментальный снимок состояния системы, созданный ранее;
- периодически определять текущие значения атрибутов и сравнивать их с шаблоном;
- определить различия между шаблоном и текущими значениями и создать отчет.
Коммерческие системы оценки уязвимостей часто оптимизируют данный процесс тем, что выполняют параллельно несколько инструментальных средств оценки.
Классификация инструментальных средств анализа уязвимостей
Существует два основных способа классификации систем анализа уязвимостей : первый – по расположению, из которого информация об оценке получена, и второй – по информации, которой располагает инструментальное средство анализа уязвимостей . При использовании первой схемы классификации для оценки уязвимостей системы классифицируются либо как network-based , либо как host-based . При использовании второй схемы системы классифицируются как credentialed или non-credentialed . Эти термины указывают, делался ли анализ с креденциалами или без креденциалов (таких, как IDs и пароли или другая идентификационная и аутентификационная информация, с помощью которой предоставляется доступ к внутренним системам). Мы будем использовать первую схему классификации для описания различных подходов к анализу уязвимостей.
Host-Based анализ уязвимостей
Системы host-based анализа уязвимостей определяют уязвимость, анализируя доступный источник системных данных, такой как содержимое файлов, параметры конфигурации и другая информация о статусе. Данная информация обычно доступна с использованием стандартных системных запросов и проверки системных атрибутов. Так как информация получена в предположении, что анализатор уязвимости имеет доступ к хосту, данный тип инструментальных средств анализа также иногда называется credential-based оценка уязвимости. Такая оценка определяется как пассивная.
Наилучшего результата достигают host-based оценки уязвимостей , которые имеют возможность выполнять привилегированные атаки. Это такие атаки, которые могут получить привилегии superuser или root на UNIX-системе или доступ administrator на Windows-системе.
Network-Based анализ уязвимостей
Системы network-based анализа уязвимостей получили распространение в последние несколько лет. Данные системы требуют установления удаленного соединения с целевой системой. Они могут реально проводить атаки на систему, понимать и записывать ответы на эти атаки или прощупывать различные цели для поиска слабых мест, которые следуют из их ответов. Такое проведение атак или прощупывание может происходить независимо от того, есть ли разрешение на доступ к целевой системе; следовательно, это можно считать non-credential анализом. Более того, так как network-based анализ уязвимостей выглядит как реальная атака или сканирование целевой системы, он также иногда обозначается как активный анализ.
Инструментальные средства network-based анализа уязвимостей иногда определяются как инструментальные средства обнаружения проникновения. Хотя, как уже обсуждалось ранее, это корректно в соответствии с некоторыми определениями обнаружения проникновения, все же программный продукт анализа уязвимостей не является законченным решением обнаружения проникновения для большинства окружений.
Существуют два метода, используемые при network-based оценки уязвимостей :
- Тестирование exploit’ов . В этом случае система пытается осуществить реальную атаку. После этого возвращается флаг статуса, указывающий, была ли атака успешной.
- Анализ создаваемых объектов . В данном случае система реально не использует уязвимости, а анализирует определенные созданные объекты, которые могут приводить к успешным атакам. Примеры подобных технологий анализа включают проверку номеров версий, указываемых системой в ответ на запрос, анализ открытых портов, проверку согласованности протоколов с помощью простых запросов статуса или другой аналогичной информации.
Преимущества и недостатки систем анализа уязвимостей
Преимущества систем анализа уязвимостей :
- Анализ уязвимостей имеет важное значение как часть системы мониторинга безопасности, позволяя определять проблемы в системе, которые не может определить IDS .
- Системы анализа уязвимостей имеют возможность выполнять относящееся к безопасности тестирование, которое может использоваться для документирования состояния безопасности систем в момент начала функционирования программы безопасности или для переустановки базовых функций безопасности всякий раз, когда происходили существенные изменения.
- Когда системы анализа уязвимостей используются регулярно, они могут надежно обнаруживать изменения в состоянии безопасности системы, оповещая администраторов безопасности о проблемах, которые требуют решения.
- Системы анализа уязвимостей предлагают способ комплексной проверки любых изменений, сделанных в системе, гарантируя, что уменьшение одного множества проблем безопасности не создаст другого множества проблем.
Недостатки и проблемы систем анализа уязвимостей :
- Host-based анализаторы уязвимостей сильно привязаны к конкретным ОС и приложениям; следовательно, они часто являются более дорогими с точки зрения развертывания, сопровождения и управления.
- Network-based анализаторы уязвимостей являются платформо-независимыми, но они менее точные и создают больше ложных тревог.
- Некоторые network-based проверки, особенно касающиеся DoS-атак, могут разрушить систему, которую они тестируют.
- При выполнении оценки уязвимостей
в сетях, в которых работают системы обнаружения проникновений, IDS
могут блокировать проведение последующих оценок. Хуже того, регулярные анализа уязвимостей
выполняют мониторинг и анализ состояния системы с интервалами; следовательно, они являются аналогами камер, которые делают фотоснимки. Системы анализа уязвимостей
могут определить, существует ли проблема в конкретный момент времени, и далее предоставить этот результат для дальнейшего исследования и обработки. IDS
могут, с другой стороны, сказать очень точно, существуют ли проблемы в течение интервала времени, и далее сообщить об условиях, которые необходимы для решения проблемы, а также об угрозах, возникающих в связи с данной проблемой.
Проверка целостности файлов
Проверки целостности файлов являются другим классом инструментальных средств безопасности, которые дополняют IDS . Эти инструментальные средства используют дайджест сообщений или другие криптографические контрольные суммы для критичных файлов и объектов, сравнивая их с хранимыми значениями и оповещая о любых различиях или изменениях.
Использование криптографических контрольных сумм важно, так как атакующие часто изменяют системные файлы по трем причинам. Во-первых, изменение системных файлов могут быть целью атаки (например, размещение Троянских программ), во-вторых, атакующие могут пытаться оставить лазейку (back door) в систему, через которую они смогут снова войти в систему позднее, и, наконец, они пытаются скрыть свои следы, чтобы собственники системы не смогли обнаружить атаку.
Хотя проверка целостности файлов часто используется для определения, были ли изменены системные или выполняемые файлы, такая проверка может также помочь определить, применялись ли модификации для исправления ошибок к программам конкретных производителей или системным файлам. Это также является очень ценным при судебных разбирательствах, так как позволяет быстро и надежно диагностировать следы атаки. Она дает возможность менеджерам оптимизировать восстановление сервиса после произошедшего инцидента.
Свободно распространяемый продукт Tripwire (www.tripwiresecurity.com), возможно, является лучшим примером инструментального средства проверки целостности файлов.
Общие понятия и терминология
В общем случае под риском понимают возможность наступления некоторого неблагоприятного события, влекущего за собой различного рода потери. Поскольку информация перестала быть просто необходимым для производства вспомогательным ресурсом или побочным проявлением всякого рода деятельности, а приобрела ощутимый стоимостной вес, который четко определяется реальной прибылью, получаемой при ее использовании, или размерами ущерба, с разной степенью вероятности наносимого владельцу информации в случае ее искажения или утраты, проблема обеспечения информационной безопасности приобрела в настоящее время исключительное значение.
Введем ряд понятий, используемых в сфере информационной безопасности и защиты информации, а также в современных методиках управления рисками И Б.
В соответствии с ГОСТ ИСО/МЭК Р 27002-2005 «Информационные технологии. Свод правил по управлению защитой информации» защита информации (information security) - это сохранение конфиденциальности, целостности и доступности информации; кроме того, также могут быть включены другие свойства, такие как аутентичность, подотчетность, неотрекаемость и надежность.
Важным этапом в сфере обеспечения информационной безопасности является процесс управления рисками И Б. Процесс управления рисками представляет собой скоординированные действия по управлению и контролю организации в отношении риска. Управление рисками включает в себя оценку риска, обработку риска, принятие риска и сообщение о риске.
Цель процесса оценивания рисков состоит в определении характеристик рисков по отношению к информационной системе и ее ресурсам (активам). На основе полученных данных могут быть выбраны необходимые средства защиты. При оценивании рисков учитываются многие факторы: ценность ресурсов, оценки значимости угроз, уязвимостей, эффективность существующих и планируемых средств защиты и многое другое.
Угроза (Threat) - совокупность условий и факторов, которые могут стать причиной нарушения целостности, доступности, конфиденциальности информации.
Уязвимость (Vulnerability) - слабость в системе защиты, которая делает возможным реализацию угрозы.
Анализ рисков (Risk Analysis) - процесс определения угроз, уязвимостей, возможного ущерба, а также контрмер.
Базовый уровень безопасности (Baseline Security) - обязательный минимальный уровень защищенности для информационных систем. В ряде стран существуют критерии для определения этого уровня. В качестве примера приведем критерии Великобритании - ССТА Baseline Security Survey, определяющие минимальные требования в области И Б для государственных учреждений этой страны. В Германии эти критерии изложены в стандарте BSI. Существуют критерии ряда организаций - NASA, Х/Ореп, ISACA и др. В нашей стране это может быть класс защищенности в соответствии с требованиями ФСТЭК России, профиль защиты, разработанный в соответствии со стандартом ISO-15408, или какой-либо другой набор требований. Тогда критерий достижения базового уровня безопасности - это выполнение заданного набора требований.
Базовый (Baseline) анализ рисков - анализ рисков, проводимый в соответствии с требованиями базового уровня защищенности. Прикладные методы анализа рисков, ориентированные на данный уровень, обычно не рассматривают ценность ресурсов и не оценивают эффективность контрмер. Методы данного класса применяются в случаях, когда к информационной системе не предъявляются повышенные требования в области И Б.
Полный (Full) анализ рисков - анализ рисков для информационных систем, предъявляющих повышенные требования в области И Б; включает в себя определение ценности информационных ресурсов, оценку угроз и уязвимостей, выбор адекватных контрмер, оценку их эффективности.
Риск информационной безопасности (Information Security Risk) - возможность того, что данная угроза сможет воспользоваться уязвимостью актива или группы активов и тем самым нанесет ущерб организации (см. ГОСТ Р ИСО/МЭК 27005-2010. «Информационная технология. Методы и средства обеспечения безопасности. Менеджмент риска информационной безопасности»).
Количественная оценка риска (Risk Estimation) - процесс присвоения значений вероятности и последствий риска (см. ГОСТ Р ИСО/МЭК 27005-2010. «Информационная технология. Методы и средства обеспечения безопасности. Менеджмент риска информационной безопасности»).
Управление рисками (Risk Management) - процесс определения контрмер в соответствии с оценкой рисков.
Система управления ИБ (Information Security Management System) - комплекс мер, направленных на обеспечение режима И Б на всех стадиях жизненного цикла информационной системы (ИС).
Ресурсы (активы ) - объекты, имеющие ценность для организации и оказывающие влияние на непрерывность осуществления деятельности. Все ресурсы должны быть идентифицированы и учтены, также должны быть определены владельцы ресурсов.
В BS ISO/IEC 17799-2005 «Информационные технологии. Методы обеспечения безопасности. Практические правила управления информационной безопасностью» выделяются следующие типы ресурсов (рис. 3.1):
- информация : базы данных и файлы данных, договоры и соглашения, системная документация, руководства пользователей, планы обеспечения непрерывности бизнеса, процедуры восстановления, журналы аудита и архивная информация;
- программные ресурсы, прикладное программное обеспечение, системное программное обеспечение, средства разработки и утилиты;
И иформа цион мыс
Программные
физические ресурсы: компьютерное оборудование, коммуникационное оборудование, переносные носители и другое оборудование;
Нематериальные
Сервисные
- сервисы : вычислительные и телекоммуникационные сервисы, основные коммунальные услуги, например отопление, освещение, электроэнергия и кондиционирование;
- люди , а также их квалификации, навыки и опыт;
- нематериальные ресурсы, такие как репутация и
имидж организации. Рис. 3.1. Типы ресурсов
На рис. 3.2 представлен процесс менеджмента риска информационной безопасности (ГОСТ Р ИСО/МЭК 27005-2010).
Менеджмент риска И Б должен быть непрерывным процессом. В рамках данного процесса следует устанавливать контекст, оценивать и обрабатывать риски, используя для реализации рекомендации и решения плана обработки рисков. До принятия решения о том, что и когда должно быть сделано для снижения риска до приемлемого уровня, в рамках менеджмента риска анализируется, что может произойти и какими могут быть возможные последствия.
Вторая точка принятия решения о риске. Результат обработки риска удовлетворительный?
Принятие риска
Рис. 3.2. Процесс менеджмента риска информационной безопасности
(ГОСТ Р ИСО/МЭК 27005-2010)
Менеджмент риска И Б должен способствовать:
- идентификации рисков;
- оценке рисков, исходя из последствий их реализации для бизне са и вероятности их возникновения;
- осознанию и информированию о вероятности и последствиях рисков;
- установлению приоритетов в рамках обработки рисков;
- установлению приоритетов мероприятий по снижению имеющих место рисков;
- привлечению причастных сторон к принятию решений о менеджменте риска и поддержанию их информированности о состоянии менеджмента риска;
- эффективности проводимого мониторинга обработки рисков;
- проведению регулярного мониторинга и пересмотра процесса менеджмента риска;
- сбору информации для совершенствования менеджмента риска;
- подготовке менеджеров и персонала по вопросам рисков и необходимых действий, предпринимаемых для их уменьшения.
Процесс менеджмента риска И Б может быть применен ко всей организации, к любой отдельной части организации (например, подразделению, филиалу, службе), к любой информационной системе, к имеющимся, планируемым или специфическим аспектам управления (например, к планированию непрерывности бизнеса) 1 .
