А. В. Лукацкий
Научно-инженерное предприятие "Информзащита"
Год 1996, 4 июня, вторник, космодром во Французской Гвиане. 9 часов 33 минуты 59 секунд. Первый запуск ракеты-носителя Ariane 5. Ракета взмывает в небо и через 40 секунд после старта взрывается на 50-метровой высоте. Ущерб составил по различным данным от пятисот миллионов до шести миллиардов долларов. Через полтора месяца, 19 июля, был опубликован исчерпывающий доклад комиссии по расследованию, в результате которого выяснилось, что взрыв произошел из-за ошибки переполнения одной из переменных в программном обеспечении бортового компьютера ракеты. Небольшая, на первый взгляд, уязвимость в программном обеспечении привела к столь значительному ущербу. Это типичный, но далеко не единственный случай, который демонстрирует опасность, возникающую в результате появлении в корпоративной сети различных уязвимостей.
Уязвимостью (vulnerability) я называю любую характеристику информационной системы, использование которой нарушителем может привести к реализации угрозы. При этом неважно, целенаправленно используется уязвимость или это происходит ненамеренно. В качестве нарушителя может выступать любой субъект корпоративной сети, который попытался осуществить попытку несанкционированного доступа к ресурсам сети по ошибке, незнанию или со злым умыслом.
Проблема уязвимостей и их обнаружения исследуется очень давно, и за время ее существования предпринимались различные попытки классифицировать уязвимости по различным критериям. Например, американские проекты Protection Analysis Project и RISOS, исследования лаборатории COAST или компании Internet Security Systems и т.д. Каждая организация приводила и обосновывала свою классификацию. Однако ни одна классификация не может быть категоричной. Например, уязвимость, использование которой для ОС Unix (например, переполнение буфера демона statd) может иметь самые плачевные последствия (самый высокий приоритет), для ОС Windows NT может быть вообще не применима или иметь очень низкую степень риска. Кроме того, существует неразбериха и в самих названиях атак и уязвимостей. Например, одна и та же атака, может иметь совершенно различные наименования у разных производителей (Таблица 1).
Таблица 1. Различные названия одной и той же уязвимости
| Организация \ Компания | Наименование атаки |
|---|---|
Для устранения описанной неразберихи с именованием уязвимостей и атак в 1999 году компания MITRE Corporation (http://www.mitre.org) предложила решение, независимое от различных производителя средств поиска уязвимостей. Это решение было реализовано в виде базы данных CVE (Common Vulnerability Enumeration), которая затем была переименована в Common Vulnerabilities and Exposures. Это позволило всем специалистам и производителям разговаривать на одном языке. Так, например, описанные в таблице 1 различные названия одной и той же уязвимости получили единый код CVE-1999-0067.
В разработке базы данных CVE помимо экспертов MITRE принимали участие специалисты многих известных компаний и организаций. Например, ISS, Cisco, BindView, Axent, NFR, L-3, CyberSafe, CERT, Carnegie Mellon University, институт SANS, UC Davis Computer Security Lab, CERIAS и т.д. О своей поддержке базы CVE заявили компании Internet Security Systems, Cisco, Axent, BindView, IBM и другие. Однако, несмотря на столь привлекательную инициативу, база данных CVE пока не получила широкого распространения среди производителей коммерческих продуктов.
В процессе практической деятельности я разработал свою классификацию, отражающую этапы жизненного цикла любой информационной системы (Таблица 2).
Таблица 2. Категории уязвимостей
| Этапы жизненного цикла ИС | Категории уязвимостей ИС |
|---|---|
Наиболее опасны уязвимости проектирования, которые обнаруживаются и устраняются с большим трудом. В этом случае, уязвимость свойственна проекту или алгоритму и, следовательно, даже совершенная его реализация (что в принципе невозможно) не избавит от заложенной в нем уязвимости. Например, уязвимость стека протоколов TCP/IP. Недооценка требований по безопасности при создании этого стека протоколов привела к тому, что не проходит месяца, чтобы не было объявлено о новой уязвимости в протоколах стека TCP/IP. Например, 7 и 8 февраля 2000 года было зафиксировано нарушение функционирования таких популярных и ведущих Internet-серверов, как Yahoo (http://www.yahoo.com), eBay (http://www.ebay.com), Amazon (http://www.amazon.com), Buy (http://www.buy.com) и CNN (http://www.cnn.com). 9 февраля аналогичная участь постигла и сервера ZDNet (http://www.zdnet.com), Datek (http://www.datek.com) и E*Trade (http://www.etrade.com). Проведенное ФБР расследование показало, что указанные сервера вышли из строя из-за огромного числа направленных им запросов, что и привело к тому, что эти сервера не могли обработать трафик такого объема и вышли из строя. Например, организованный на сервер Buy трафик превысил средние показатели в 24 раза, и в 8 раз превысил максимально допустимую нагрузку на сервера, поддерживающие работоспособность Buy. Раз и навсегда устранить эти недостатки уже невозможно - существуют только временные или неполные меры. Однако бывают и исключения. Например, внесение в проект корпоративной сети множества модемов, облегчающих работу персонала, но существенно усложняющих работу службы безопасности. Это приводит к появлению потенциальных путей обхода межсетевого экрана, обеспечивающего защиту внутренних ресурсов от несанкционированного использования. И обнаружить, и устранить эту уязвимость достаточно легко.
Смысл уязвимостей второй категории (уязвимости реализации) заключается в появлении ошибки на этапе реализации в программном или аппаратном обеспечении корректного с точки зрения безопасности проекта или алгоритма. Яркий пример такой уязвимости - "переполнение буфера" ("buffer overflow") во многих реализациях программ, например, sendmail или Internet Explorer. Кстати, приведенный выше пример с ракетой Ariane 5 относится именно к этой категории уязвимостей. Обнаруживаются и устраняются такого рода уязвимости относительно легко - путем обновления исполняемого кода или изменения исходного текста уязвимого ПО. Еще одним примером уязвимостей реализации является случай с компьютерами Tandem, произошедший 1 ноября 1992 г. и 7 января 1993 г. В 3 часа ночи функционирование большинства компьютеров Tandem во всем мире было нарушено по причине сбоя в подсистеме BASE23 Nucleus, приводящего к переполнению переменной микрокода таймера при определении времени. Из-за этой ошибки значения системных часов было сброшено на декабрь 1983 г., что иногда приводило к неправильной интерпретации данных в различных финансовых приложениях.
Последняя причина возникновения уязвимостей - ошибки конфигурации программного или аппаратного обеспечения. Наряду с уязвимостями реализации они являются самой распространенной категорией уязвимостей. Существует множество примеров таких уязвимостей. К их числу можно отнести, например, доступный, но не используемый на узле сервис Telnet, использование "слабых" паролей или паролей менее 6 символов, учетные записи (accounts) и пароли, остановленные по умолчанию (например, SYSADM или DBSNMP в СУБД Oracle), и т.д. Обнаружить и исправить такие уязвимости проще всего (Таблица 3).
Таблица 3. Возможности по обнаружению и устранению уязвимостей
| Категория уязвимости | Обнаружение Устранение |
|---|---|
Реальным примером использования такой уязвимости явился взлом базы данных компании Western Union, специализирующейся на денежных переводах, которая 8 сентября 2000 г. объявила о том, что из-за "человеческой ошибки" неизвестному злоумышленнику удалось скопировать информацию о кредитных карточках около 15,7 тысяч клиентов ее Web-сайта. Представитель Western Union сообщил, что взлом произошел, когда во время проведения регламентных работ были открыты системные файлы, доступ к которым во время штатной работы сайта имеют только администраторы. Western Union настаивала, что это не проблема архитектуры системы защиты, это была ошибка персонала.
Разумеется, уязвимости необходимо обнаруживать, чем и занимаются системы анализа защищенности (security assessment systems), также известные как сканеры безопасности (security scanners) или системы поиска уязвимостей. Они проводят всесторонние исследования заданных систем с целью обнаружения уязвимостей, которые могут привести к нарушениям политики безопасности. Результаты, полученные от средств анализа защищенности, представляют "мгновенный снимок" состояния защиты системы в данный момент времени. Несмотря на то, что эти системы не могут обнаруживать атаку в процессе ее развития, они могут определить потенциальную возможность реализации атак.
Эти системы могут быть классифицированы по типам обнаруживаемых ими уязвимостей (Рис.1), описанных выше.
Системы поиска уязвимостей проектирования не получили широкого распространения в российских компаниях. Связано это, на мой взгляд, с высокой стоимостью таких решений и недопониманием их значимости. Единственный класс организаций, где эти системы нашли свое применение, - это лаборатории, осуществляющие сертификацию программно-аппаратного обеспечения и аттестацию информационных систем по требованиям безопасности. Такие лаборатории существуют в рамках всех пяти российских систем сертификации по требованиям защиты информации, принадлежащих ГТК, ФАПСИ, МО РФ, ФСБ и СВР. Примерами таких зарубежных систем можно назвать CRAMM, RANK-IT, @RISK, ALRAM, ARES, LAVA и т.д. Из российских разработок известны ZOND, SEZAM и результаты работ 4 ЦНИИ Министерства Обороны РФ.
Системы анализа защищенности второго и третьего классов получили наибольшее распространение среди конечных пользователей. Существует несколько дополнительных классификаций этих систем. Например, системы анализа исходного текста и исполняемого кода тестируемого программно-аппаратного обеспечения и т.д. Первые также применяются обычно при сертификации программного обеспечения по требованиям безопасности. Такие систему существуют у зарубежных (например, SLINT) и российских (например, АИСТ, АСТМА и СОТМА) производителей.
В большинстве случаев программное обеспечение поставляется в организации без исходных текстов. Кроме того, анализ исходных текстов требует высокой квалификации от обслуживающего их персонала. Да и отсутствие эффективных систем анализа исходных текстов не позволяет проводить такой анализ на качественном уровне. По словам сотрудника одной из отечественных сертификационных лабораторий, "выполнение указанных работ проводится путем ручного анализа исходных текстов программ". Именно поэтому большой интерес вызывают системы поиска уязвимостей в исполняемом коде, самым распространенным подклассом которых являются системы имитации атак, которые моделируют различных несанкционированных воздействий на компоненты информационной системы. Именно эти системы получили широкую известность во всем мире ввиду своей относительной простоты и дешевизны. Посредством таких имитаторов обнаруживаются уязвимости еще до того, как они будут использованы нарушителями для реализации атак. К числу систем данного класса можно отнести SATAN, Internet Scanner, Cisco Secure Scanner и т.д. Из российских систем можно назвать систему с многозначительным названием НКВД, разработанную в Центре безопасности информации.
Системы имитации атак с одинаковым успехом обнаруживают не только уязвимости реализации, но и уязвимости эксплуатации. Именно эти системы, наряду с системами поиска уязвимостей эксплуатации, получили наибольшее распространение среди пользователей.
Как показано на рисунке 2 функционировать системы анализа защищенности, в частности системы поиска уязвимостей реализации и эксплуатации, могут на всех уровнях информационной инфраструктуры любой компании, то есть на уровне сети, операционной системы, СУБД и прикладного программного обеспечения. Наибольшее распространение получили средства анализа защищенности сетевых сервисов и протоколов. Связано это, в первую очередь, с универсальностью используемых протоколов. Изученность и повсеместное использование таких стеков протоколов, как TCP/IP, SMB/NetBIOS и т.п. позволяют с высокой степенью эффективности проверять защищенность корпоративной сети, работающей в данном сетевом окружении, независимо от того, какое программное обеспечение функционирует на более высоких уровнях. Примером такой системы является Internet Scanner компании ISS. Вторыми по распространенности являются средства анализа защищенности операционных систем. Связано это также с универсальностью и распространенностью некоторых операционных систем (например, UNIX и Windows NT). Однако, из-за того, что каждый производитель вносит в операционную систему свои изменения (ярким примером является множество разновидностей ОС UNIX), средства анализа защищенности ОС анализируют в первую очередь параметры, характерные для всего семейства одной ОС. И лишь для некоторых систем анализируются специфичные для нее параметры. Примером такой системы является System Scanner компании ISS. Средств анализа защищенности СУБД и приложений на сегодняшний день не так много, как этого хотелось бы. Такие средства пока существуют только для широко распространенных прикладных систем, типа Web-броузеры (Netscape Communicator, MS Internet Explorer), СУБД (MS SQL Server, Oracle) и т.п. Примером такой системы является Online Scanner и Database Scanner также компании ISS.
При проведении анализа защищенности эти системы реализуют две стратегии. Первая - пассивная, - реализуемая на уровне операционной системы, СУБД и приложений, при которой осуществляется анализ конфигурационных файлов и системного реестра на наличие неправильных параметров; файлов паролей на наличие легко угадываемых паролей, а также других системных объектов на нарушения политики безопасности. Вторая стратегия, - активная, - осуществляемая в большинстве случаев на сетевом уровне, позволяющая воспроизводить наиболее распространенные сценарии атак, и анализировать реакции системы на эти сценарии.
Однако не стоит думать, что при помощи средств анализа защищенности можно тестировать только возможность несанкционированного доступа в корпоративную сеть из сетей открытого доступа (например, Internet). Эти средства с не меньшим успехом могут быть использованы для анализа некоторых сегментов или узлов внутренней сети организации. Системы анализа защищенности могут быть использованы как отделами защиты информации (для оценки уровня безопасности организации), так и управлениями информатизации (для контроля эффективности настройки сетевого, системного и прикладного программно-аппаратного обеспечения). Эта два наиболее распространенных варианта применения систем анализа защищенности. Однако есть и другие варианты. Например, внешними аудиторскими и консалтинговыми компаниями, осуществляющими информационные обследования сетей своих заказчиков. Есть и более интересные варианты - например, для тестирования и сертификации того или иного программно-аппаратного обеспечения. Этот вариант очень популярен на Западе при оценке сетевого оборудования, межсетевых экранов и т.п. различными тестовыми лабораториями. В России такая практика пока не получила широкого распространения. Однако и у нас зафиксированы факты применения средств анализа защищенности. Гостехкомиссия России использует системы Internet Scanner и Nessus в процессе сертификации межсетевых экранов на соответствие требованиям руководящих документов.
В настоящий момент существует более сотни различных средств, автоматизирующих поиск уязвимостей на уровне сети, ОС, СУБД и прикладного ПО. Одни средства ориентированы на обнаружение целого спектра различных уязвимостей, другие - только на определенную их категорию. Например, система Internet Scanner является одним из самых известных средств поиска "дыр" и обнаруживает более 900 различных уязвимостей, принадлежащих различным категориям: Denial of Service, Brute Force, FTP, LDAP, SNMP, RPC, NIS, NFS, DNS и т.д. А система Whisker была создана специально для сканирования Web-серверов и позволяет выявлять уязвимые CGI-скрипты.
Я не ставил перед собой цели сравнивать предлагаемые в России решения. Поскольку сравнивать различные средства - задача неблагодарная; особенно в России. Ведь между конечным пользователем и производителем всегда встает третье звено (или несколько) - поставщик, который может свести "на нет" все достоинства предлагаемого решения за счет низкого качества послепродажной и гарантийной поддержки. Вторая причина отказа от сравнения в том, что данные решения - это далеко не все, что должно сравниваться. Для каждого продукта должна существовать своя инфраструктура (которая также должна приниматься во внимание при выборе), включающая в себя качество документации (в том числе и на русском языке) и технической поддержки, наличие авторизованного обучения и квалифицированных консультаций, выезды специалистов организации к заказчику и т.д. Ну и наконец, сравнить и выбрать продукты может только конечный пользователь и только в своей собственной сети, чтобы проверить поведение и удобство использования того или иного решения именно в той технологии обработки информации, которая принята в организации.
В таблице 4 приведен список средств анализа защищенности, наиболее часто используемых в России.
Таблица 4. Средства анализа защищенности, используемые в России
| Название | Производитель | Категория | Примечание |
|---|---|---|---|
В России стоимость является, пожалуй, одним из основных критериев выбора системы обнаружения атак. Зачастую такой выбор делается не в пользу более эффективного, а в пользу более дешевого решения. Можно спорить, что такая практика порочна, но она существует и с ней надо считаться. Понимая это, многие производители помимо цены, указанной в прайс-листе, предлагают специальные программы удержания потенциального покупателя. Именно поэтому в вышеприведенной таблице нет колонки "Цена". Можно привести некоторые примеры без указания названий фирм, использующих такие методы:
В среднем стоимость анализа одного узла может меняться в диапазоне от 100 до 3 долларов США, в зависимости от числа сканируемых устройств.
И хотя в одной статье трудно описать критерии выбора различных средств анализа защищенности, я бы хотел дать некоторые основные советы, которым надо следовать при приобретении таких систем. Замечу, что подробное описание критериев оценки таких систем будет приведено в книге "Обнаружение атак", которая выйдет летом 2001 года в издательстве BHV-СПб (http://www.bhv.ru).
Я категорически не рекомендую использовать в качестве основного параметра выбора системы анализа защищенности число обнаруживаемых ею уязвимостей. Ведь это очень субъективный параметр. В качестве примера можно привести следующий случай. Зачем в сети, в которой используется только платформа Windows система, обнаруживающая еще и Unix'овые уязвимости. Эти возможности являются лишними и возможно никогда не будут использованы. Поэтому подходить к выбору системы анализа защищенности надо очень осторожно и не стоит полагаться только на число обнаруживаемых уязвимостей.
Поскольку постоянно появляются новые уязвимости, то для их эффективного обнаружения необходимо постоянно обновлять базу данных системы анализа защищенности. Ведь не вызывает сомнений необходимость обновления антивирусной системы или установка патчей и Service Pack'ов для операционных систем. Также и с системой поиска уязвимостей. Только в случае периодического и своевременного обновления эта система сможет поддерживать защищенность сети на должном уровне. В идеале разрыв между появлением информации об уязвимости в различных "хакерских" источниках и появлением сигнатуры в базе данных системы обнаружения должен отсутствовать. Еще лучше, когда производитель системы обнаружения уязвимостей идет на шаг впереди злоумышленников и обновляет свою систему еще до того, как информация о новых "дырах" разойдется по всему миру. Однако на практике это далеко не так. И задача и производителя (или поставщика) системы анализа защищенности и персонала, использующего эту систему, снизить этот интервал до минимума. Но как бы часто не обновлялась база данных уязвимостей, существует временной промежуток между сообщением о новой уязвимости и появлением проверки для нее. Уменьшение этого интервала - одна из главных задач, стоящих перед эксплуатирующим систему анализа защищенности подразделением. Один из путей ее решения - создание своих собственных проверок. Решаться это может путем использованием языка описания уязвимостей. Такая возможность существует в системах Internet Scanner, CyberCop Scanner, Nessus, WebTrends Security Analyzer и ряде других.
Механизм описания своих проверок, уязвимостей, атак и иных контролируемых событий является очень полезной возможностью для администраторов, отслеживающих уязвимости, описанные в Bugtraq и иных списках рассылки. Эта возможность позволяет быстро записать новое правило и использовать его в своей сети. Однако необходимо заметить, что хотя данная возможность и является полезной, ее необходимость достаточно эфемерна. В своей практической деятельности мне не приходилось встречаться с организациями, которые могли бы себе позволить содержать целый штат или одного сотрудника, занимающихся исследованиями в области новых проверок и уязвимостей (я не беру в расчет силовые ведомства и иные организации, работающие в области защиты информации). Как правило, человек, отвечающий за обеспечение безопасности в российских организациях, не обладает глубокими познаниями в программировании. Кроме того, помимо написания новых правил на нем "висит" еще много других задач (контроль деятельности пользователей, установка прав доступа, противодействие ПЭМИН и т.д.), и он просто не имеет времени для такой творческой работы, как создание новых проверок.
Несмотря на то, что система анализа защищенности является средством обеспечения информационной безопасности, она сама должна быть защищена от посягательств со стороны злоумышленников, так как выведение ее из строя существенно снизить защищенность всей сети. Для этого в этой системе должны быть предусмотрены механизмы контроля своей целостности, ограничения круга лиц к собранным данным и разграничения прав на запуск проверок.
Далеко не всегда система анализа защищенности является основным средством защиты в сети. Мало того, даже самая "главная" система защиты может быть второстепенной системой в общей телекоммуникационной инфраструктуре. Очень часто приходится встречаться с организациями, в которых отделы защиты информации находятся в подчиненном положении по отношению к отделам информатизации. В таких организациях в качестве корпоративного стандарта принята какая-либо система сетевого управления (например, HP OpenView), с которой и пытаются интегрировать все остальные системы (в том числе и средства защиты). Поэтому при выборе системы поиска уязвимостей необходимо делать выбор в пользу той, которая имеет возможность интеграции с системами управления и другими средствами, используемыми в вашей организации.
Подсистема генерации отчетов - немаловажный элемент системы анализа защищенности. Без нее трудно составить мнение о том, каков уровень защищенности сегментов корпоративной сети. На основе созданных этой системой отчетов администратор безопасности строит всю свою дальнейшую деятельность - изменяет политику безопасности, устраняет обнаруженные уязвимости, реконфигурирует средства защиты, готовит отчеты руководству и т.д. При этом хорошая подсистема генерации отчетов должна обладать следующими свойствами:
Алексей Викторович Лукацкий, заместитель технического директора Научно-инженерного предприятия "Информзащита" (Москва), сертифицированный инструктор по безопасности компании Internet Security Systems, сертифицированный инженер по безопасности компании Check Point Technologies. Связаться с ним можно по тел. (095) 289-8998 или e-mail: luka@infosec.ru.
17 апреля 2001 г.
[an error occurred while processing this directive]