На тему аудита информационной безопасности на сегодняшний день написано огромное количество публикаций. Однако до сих пор эта тема интересна и вызывает вопросы как у заказчиков, так и, как это ни парадоксально, у поставщиков данных услуг. К сожалению, как показывает наша практика, до сих в нашей стране низкий уровень знания западных стандартов, и как следствие до сих пор можно встретить, как аудитом информационной безопасности называют обычное сканирование уязвимостей. На самом деле, сегодня в области стандартизации подходов к информационной безопасности все обстоит довольно неплохо – надо лишь внимательно изучить существующие подходы и стандарты и воплощать их на практике. Казалось бы, что проще. И действительно, в случае ISO 27001/ISO 17799 так и случилось, и существует вполне однозначный механизм аудита на соответствие требованиям данного стандарта и практика его внедрения. Почему же с аудитом безопасности ситуация обстоит иначе?

Прежде всего, посмотрим на то, на какие этапы сегодня разбивается проведение аудита ИБ, в частности, на примере методики проведения аудита NSA Infosec (методика АНБ США). На первом этапе необходимо провести оценку системы управления информационной безопасностью. На втором этапе – технологический аудит защищенности. Третий этап – анализ информационных рисков (В данной статье мы сосредоточимся на технологическом аудите и не будем рассматривать этап анализа информационных рисков, который требует написания отдельной статьи). В общем виде в этой схеме нет ничего нового, и большинство специалистов с ней согласно. Проблемы для заказчика начинаются в деталях – что именно и как будет сделано в процессе выполнения работ по этой схеме, особенно на этапах технологического аудита и анализа рисков. Возникает вопрос почему? Все достаточно просто. Дело в том, что в само понятие «аудита» вкладывается оценка на соответствие какому-либо четкому критерию (или стандарту). Что касается первого этапа, то для оценки системы управления ИБ в качестве такого критерия все используют хорошо проработанный стандарт ISO 27001/ISO 17799 и, несмотря на сложность и недостаток практических методик проверки глубины выполнения его требований, на практике с той или иной степенью успеха проводят аудит на соответствие требованиям стандарта. Все-таки, когда речь идет об организации системы управления ИБ, все более однозначно, несмотря на необходимость глубокого понимания сущности системы управления и возникающих при ее внедрении практических сложностей.

Основные же проблемы возникают как раз на втором этапе аудита – при проведении технологической оценки защищенности. Почему? Ответ очевиден – нет четкого критерия, по которому на технологическом уровне можно понять защищена ли система или нет; существуют ли в ней уязвимости, позволяющие осуществить проникновение в нее или нет. Соответственно, нет четкого перечня проверок, которые должен выполнить аудитор. И что важно – такого критерия и единого перечня проверок никогда и не будет.

Максимум что должно быть – это общая методика проведения таких проверок.

Теперь поговорим о практических методах проведения аудита на этом этапе. В России подавляющее большинство интеграторов при проведении внутреннего аудита (внутри периметра корпоративной сети) ограничиваются сканированием уязвимостей и анализом настроек ОС и оборудования с точки зрения ИБ. Соответственно, выполняя данные проверки, мы теоретически сможем ответить на вопрос, какие уязвимости существуют в ИС без проверки возможности их реализации на практике. Почему теоретически – потому что далеко не все из того, что мы найдем, действуя таким образом, можно реализовать на практике. Сканирование и анализ настроек дает только первоначальную оценку о возможном наличии уязвимостей и возможных способах проникновения. Совершенно очевидно, что данных проверок не достаточно, так как мы пока не ответили на основной вопрос, на который должен ответить этап технологического аудита. А можно ли реализовать на практике обнаруженные уязвимости? А как будет действовать реальный взломщик, находясь внутри информационной системы компании, куда он реально сможет проникнуть? На самом деле, именно на этот вопрос необходимо найти ответ на данном этапе, одна из важнейших задач которого - имитировать действия потенциального нарушителя, максимально реализовав обнаруженные на стадии сканирования возможные уязвимости, тем самым 100% подтвердив их наличие и продемонстрировав на практике реальный уровень защищенности ИС. Кроме того, только выполнение подобного «внутреннего» теста на проникновение (стадия реализации уязвимостей) позволяет обнаружить и реализовать сложные комплексные стратегии нападения (стадия распространения), которые всегда реализуются на практике хакерами.

Поясним это на следующем примере. Предположим, стадия первоначального сканирования показала наличие потенциальных проблем на серверах 2, 5 и 8. Стадия анализа настроек выявила проблемы с защищенностью на сервере 15, рабочих станциях 110 и 250 и маршрутизаторе 5.

На стадии реализации обнаруженных уязвимостей выяснилось, что по ряду причин реализовать уязвимости на сервере 5 и 8 оказалось невозможно. Реализовав уязвимость на сервере 2, затем удалось проникнуть на серверы 3, 6 и 20. Далее, действуя по этой ветке, был проведен анализ того, что можно сделать, находясь на данных трех серверах (это азы работы злоумышленников, попав на объект, посмотреть как можно с него распространиться далее по системе). В итоге, используя данные с сервера 6, удалось проникнуть на серверы 11, 12 и 13. Затем через сервер 12 было осуществлено успешное проникновение на сервер 35, который оказался контроллером домена и из-за особенностей настройки которого тем самым было осуществлено успешное проникновение на все серверы, входящие в домен. Через маршуртизатор 5 удалось проникнуть на маршуртизаторы 3, 2, и 1. Из рабочих станций реально оказалась уязвима станция 250, через которую удалось организовать проникновение на станции 10, 11 и 12 и сервер 16. Пример можно продолжать и далее, по любым другим веткам, в том числе и через рабочие станции. Важно отметить, в соответствии с нашей практикой очень часто даже одна рабочая станция может стать причиной компрометации всей системы.

Итак, давайте теперь вернемся к началу примера и сравним результаты действий в первом и втором случаях. Напомним, что в первом случае мы ограничились стадиями сканирования уязвимостей и анализом настроек, а во втором – добавили стадии реализации уязвимостей и стадии распространения по системе. В первом случае картина следующая: уязвимы серверы 2, 5, 8, 15; рабочие станции 110 и 250 и маршрутизатор 5. А реальная картина защищенности показана во втором примере, когда аудитор действует по правильной методике: уязвимы серверы 2, 3, 6, 20, 11, 12, 13, 16, 35 (через который уязвимы все серверы, входящие в домен); рабочие станции 10, 11, 12 и 250; маршрутизаторы 1, 2, 3 и 5.

Сравнение впечатляет? А это объективная реальность, которую и должен показать этап технологического аудита! Именно поэтому все международные стандарты рекомендуют проводить так называемый активный аудит (в терминологии NSA Infosec тесты на проникновение по «красной группе»). В случае активного аудита внутренней сети применяется модель нарушителя, согласно которой аудиторам выдаются следующие минимальные привилегии: физический доступ внутрь охраняемого периметра и возможность подключения к КИС Компании на физическом уровне. Логическими правами доступа к информационным ресурсам КИС на этой стадии аудитор не обладает.

В этом случае совершенно ясно, за что клиент платит деньги и почему он должен приглашать внешнего консультанта, а не ограничиться самостоятельным сканированием своих ресурсов. Также не вызывает вопросов актуальность подобного шага. Конечно, если нет желания уподобиться страусу, засунув голову в песок, и жить в полной уверенности в собственной «защищенности».

Однако парадокс в том, что сегодня в России (в отличие от Запада) за редким исключением никто не проводит аудит по этим методикам. Почему? Ответ на поверхности – во-первых, заказчики не знают плюсов данной методики и не требуют ее выполнения от исполнителей. Во-вторых, исполнители с одной стороны просто не могут реализовать эту методику, так как ее реализация требует наличия в штате консультантов, обладающих глубокими навыками в области проведения тестов на проникновение. Круг замкнулся.

Однако не все так плохо и выход из замкнутого круга совсем не за горами. Сегодня на рынке ИБ у ряда заказчиков существует понимание необходимости использования и в аудите безопасности лучших западных практик. Просто пока этап аудита будет восприниматься как ненужная помеха перед интеграцией - все будет по-прежнему. Но как только внешний аудит в соответствии со стандартами по управлению ИБ (в частности, ISO 27001 или стандарт ЦБ РФ СТО БР ИББС-1.0-2006) станет одной из частей жизненного цикла системы управления безопасностью, перейдя опять же в полном соответствии с международными стандартами на регулярную основу – ситуация в этой области в РФ в корне изменится. Тем более, в 2007 году большинство международных стандартов в области информационной безопасности, наконец, получат статус российских ГОСТов.

Илья Медведовский, к.т.н.
Директор Digital Security
"Connect! Мир связи" №10/2006

обсудить  |  все отзывы (0)
Выберите оценку 10 (изумительно) 9 (отлично) 8 (хорошо) 7 (неплохо) 6 (средненько) 5 (сойдет) 4 (так себе) 3 (слабо) 2 (плохо) 1 (отвратительно) Вернуться в раздел Перейти к рейтингу Перейти к обсуждению Вернуться к статье	[34389; 7; 4.85]