Классификация уязвимостей
Уязвимостью (vulnerability) я называю любую характеристику информационной системы, использование которой нарушителем может привести к реализации угрозы. При этом неважно, целенаправленно используется уязвимость или это происходит ненамеренно. В качестве нарушителя может выступать любой субъект корпоративной сети, который попытался осуществить попытку несанкционированного доступа к ресурсам сети по ошибке, незнанию или со злым умыслом.
Проблема уязвимостей и их обнаружения исследуется очень давно, и за время ее существования предпринимались различные попытки классифицировать уязвимости по различным критериям. Например, американские проекты Protection Analysis Project и RISOS, исследования лаборатории COAST или компании Internet Security Systems и т.д. Каждая организация приводила и обосновывала свою классификацию. Однако ни одна классификация не может быть категоричной. Например, уязвимость, использование которой для ОС Unix (например, переполнение буфера демона statd) может иметь самые плачевные последствия (самый высокий приоритет), для ОС Windows NT может быть вообще не применима или иметь очень низкую степень риска. Кроме того, существует неразбериха и в самих названиях атак и уязвимостей. Например, одна и та же атака, может иметь совершенно различные наименования у разных производителей (Таблица 1).
Таблица 1. Различные названия одной и той же уязвимости
CERT | CA-96.06.cgi_example_code |
CyberSafe | Network: HTTP 'phf' Attack |
ISS | http-cgi-phf |
AXENT | phf CGI allows remote command execution |
Bugtraq | PHF Attacks - Fun and games for the whole family |
BindView | #107 - cgi-phf |
Cisco | #3200 - WWW phf attack |
IBM ERS | Vulnerability in NCSA/Apache Example Code |
CERIAS | http_escshellcmd |
L-3 | #180 HTTP Server CGI example code compromises http server |
Для устранения описанной неразберихи с именованием уязвимостей и атак в 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. Категории уязвимостей
Проектирование ИС | Уязвимости проектирования |
Реализация ИС | Уязвимости реализации |
Эксплуатация ИС | Уязвимости конфигурации |
Смысл уязвимостей второй категории (уязвимости реализации) заключается в появлении ошибки на этапе реализации в программном или аппаратном обеспечении корректного с точки зрения безопасности проекта или алгоритма. Яркий пример такой уязвимости - "переполнение буфера" ("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. Возможности по обнаружению и устранению уязвимостей
Уязвимости проектирования | Трудно и долго Трудно и долго (иногда невозможно) |
Уязвимости реализации | Относительно трудно и долго Легко и относительно долго |
Уязвимости конфигурации | Легко и быстро Легко и быстро |