Управление зоопарком безопасности

Алексей Лукацкий, менеджер по развитию бизнеса компании Cisco Systems, завел блог на Computerra.ru. В первой записи он рассказывает, как в компаниях уживаются разношерстные средства защиты.

Практически любой крупный город (и не только) имеет зоопарк, в котором собраны различные представители фауны, встретить которых в природе в одном месте практически невозможно. Искусство владельцев зоопарка состоит в грамотном размещении вольеров с животными так, чтобы их "постояльцы" не слишком нервничали от соседства между собой, а посетителям зоопарка было удобно ходить по территории.

Под стать зоопарку ситуация и в области информационной безопасности современных компаний. Как бы ни хотели производители средств защиты быть монополистами в области поставки своих решений заказчикам, но реальная ситуация немного иная. В каждой компании существует большой набор различных оборонительных средств, выпущенных под разными торговыми марками. Это происходит по различным причинам. Во-первых, каждый новый руководитель приводит с собой своих поставщиков. Во-вторых, поэтапное и эволюционное развитие корпоративной сети требует новых подходов и решений и, зачастую, новых производителей. И наконец, нельзя сбрасывать со счетов требования российского законодательства, которое в неявной форме делит некоторые категории средств защиты на российские и зарубежные, закрывая последним дорогу на отечественный рынок (речь идет в первую очередь о средствах шифрования). А раз так, то возникает задача единого управления этими разнородными средствами.

Решить эту задачу непросто. Ведь у каждого вендора свое мнение по поводу того, как надо реализовывать средства информационной безопасности. Даже наличие стандартов не всегда помогает – всегда находятся какие-то недомолвки или спорные места, которые трактуются по-своему. Нередки также ситуации, когда компания-производитель, не довольствуясь существующей версией стандарта, начинает расширять его. В этой ситуации пользователь конкретной системы, конечно, выигрывает, но вот интегрировать такие "расширенные" продукты становится очень трудно. Но несмотря на все препятствия, решить описываемую задачу все-таки можно.

Вариантов, собственно, два – изначально разрабатывать систему управления, поддерживающую наиболее распространенные средства защиты, или использовать единые стандарты управления ими. Первый путь – менее затратный и гораздо быстрее приводит нас к цели. С другой стороны, он имеет одно серьезное ограничение – он позволяет управлять только теми средствами защиты, для которых разрабатывалась система – подключение любого нового защитного решения обречено на провал. Но несмотря на это, пока основное внимание производителей сосредоточено на управлении самыми известными средствами безопасности. И их тоже можно понять – поддержка оборудования только трех ведущих игроков рынка сетевой безопасности (Cisco, Check Point, Juniper) позволяет закрыть потребности свыше 80% всех пользователей по всему миру.

Второй путь самый правильный, но и самый трудный. Необходимо признать, что таких стандартов пока нет, хотя речь об их создании идет давно. К сожалению, появляющиеся стандарты "имени конкретных производителей", не получают распространения. Отчасти потому, что стандарт, разработанный конкретной компанией, мало кто поддерживает из конкурентов (даже если стандарт хорош). Например, когда-то компанией Cisco был разработан стандарт RDEP. Потом RDEP был поддержан компаниями NFR, ISS, Sourcefire, занимающимися обнаружением вторжений, и на его основе родился протокол SDEE. Но и его постигла судьба RDEP – кроме Cisco его никто почти не использовал. Аналогичная судьба и у протоколов спецификации OPSEC компании Check Point. Кроме ее партнеров, желающих "сесть на хвост" известному производителю, этот стандарт никто больше не поддерживает.

Сейчас ситуация стала постепенно меняться, и в отрасли появляются стандарты, позволяющие унифицировать взаимодействие разнородных средств защиты. Первой ласточкой стал CVE – CommonVulnerabilities and Exposures – стандарт, определяющий единое именование уязвимостей. Его поддерживают практически все производители сканеров безопасности, включая и отечественную компанию Positive Technologies, разработчик сканера MaxPatrol. Потом появился OVAL – OpenVulnerability and Assessment Language – стандартизованный язык описания уязвимостей в сканерах и системах анализа защищенности (пока его используют немногие). Оба эти стандарта были разработаны под эгидой MITRE.

С тех пор число стандартов, над которыми MITRE взяла шефство, только возросло. Среди них:

• CCE – CommonConfiguration Enumeration – стандарт описания конфигураций, которые затем могут проверяться в сканерах и системах анализа защищенности;
• CEE – Common Event Expression – стандарт описания, хранения и обмена сигналами тревоги между разнородными средствами защиты;
• CME – Common Malware Enumeration – стандарт, похожий на CVE, но ориентированный на вредоносное ПО;
• CWE – Common Weakness Enumeration – стандартизованный набор слабых мест в ПО. Этот стандарт не зацикливается только на уязвимостях как CVE и является более высокоуровневым, описывая типы проблем, а не их конкретные имена и проявления;
• CPE – Common Platform Enumeration – стандарт описания и именования элементов ИТ-инфраструктуры;
• CAPEC – Common Attack Pattern Enumeration and Classification – создание публичного каталога и схемы классификации шаблонов атак
• CRF – Common Result Format – стандартизация описания результатов тестирования или оценки защищенности.

Еще три стандарта появились не в MITRE, но тоже в Америке и тоже в известной своей деятельностью в области ИБ организации – Национальном институте стандартов США (NIST):

• SCAP – SecurityContent Automation Protocol – это даже не стандарт, а метод, использующий различные стандарты для автоматизации процесса управления уязвимостями;
• CVSS – Common Vulnerability Scoring System – стандарт рейтингования уязвимостей;
• XCCDF – eXtensible Configuration Checklist Description Format – стандартизованный язык описания чеклистов, тестирований и т.п.

Не все стандарты еще получили широкое распространение, не все вышли из разряда "беты"... Но и этого уже немало. Мы в начале большого пути, и главное - чтобы эти стандарты не постигла судьба SDEE. Правда, надо заметить, что в России эти стандарты, как и многие другие, практически не используются разработчиками, занимающимися изобретением велосипеда. Возможно, со временем ситуация изменится…