Главная страница
Форум
Промиздат
Опережения рынка
Архитектура отрасли
Формирование
Тенденции
Промстроительство
Нефть и песок
О стали
Компрессор - подбор и ошибки
Из истории стандартизации резьб
Соперник ксерокса - гектограф
Новые технологии производства стали
Экспорт проволоки из России
Прогрессивная технологическая оснастка
Цитадель сварки с полувековой историей
Упрочнение пружин
Способы обогрева
Назначение, структура, характеристики анализаторов
Промышленные пылесосы
Штампованные гайки из пружинной стали
Консервация САУ
Стандарты и качество
Технология производства
Водород
Выбор материала для крепежных деталей
Токарный резец в миниатюре
Производство проволоки
Адгезия резины к металлокорду
Электролитическое фосфатирование проволоки
Восстановление корпусных деталей двигателей
Новая бескислотная технология производства проката
Синие кристаллы
Автоклав
Нормирование шумов связи
Газосварочный аппарат для тугоплавких припоев
|
Главная страница / Архитектура отрасли Практические аспекты проведения аудита информационной безопасности Прежде всего посмотрим, на какие этапы сегодня разбивается проведение аудита ИБ, в частности на примере методики проведения аудита NSA Infosec (методика АНБ США). На первом этапе необходимо провести оценку системы управления информационной безопасностью, на втором – технологический аудит защищенности. Третий этап – анализ информационных рисков . В общем виде в данной схеме нет ничего нового, и большинство специалистов с ней согласно. Проблемы для заказчика начинаются в деталях – что именно и как будет сделано в процессе выполнения работ по этой схеме, особенно на этапах технологического аудита и анализа рисков. Возникает вопрос – почему? Дело в том, что в само понятие «аудит» вкладывается оценка на соответствие какому-либо четкому критерию (или стандарту). На первом этапе для оценки системы управления ИБ в качестве такого критерия широко используется хорошо проработанный стандарт ISO 27001/ISO 17799. Основные проблемы возникают на втором этапе аудита – при проведении технологической оценки защищенности. Это обусловлено отсутствием четкого критерия, по которому на технологическом уровне можно понять, защищена система или нет; есть в ней уязвимости, позволяющие осуществить проникновение в нее или нет. Соответственно, не сформирован перечень проверок, которые должен выполнить аудитор. Да, собственно говоря, ни четкого критерия, ни и единого перечня проверок быть не может. Максимум, что должно быть, – это общая методика проведения таких проверок. Теперь поговорим о методах выполнения аудита на этом этапе. В России подавляющее большинство интеграторов при проведении внутреннего аудита (внутри периметра корпоративной сети) ограничиваются сканированием уязвимостей и анализом настроек ОС и оборудования с точки зрения ИБ. Соответственно, выполняя данные проверки, мы теоретически сможем ответить на вопрос, какие уязвимости существуют в ИС без проверки возможности их реализации на практике. Теоретически – потому что далеко не все из того, что мы найдем, действуя таким образом, можно реализовать на практике. Сканирование и анализ настроек дают только первоначальную оценку о наличии уязвимостей и возможных способах проникновения. Для ответа на главные вопросы технологического аудита – можно ли реализовать на практике обнаруженные уязвимости; как будет действовать взломщик, находясь внутри информационной системы компании, куда он реально сможет проникнуть, – данных пока недостаточно. Одна из наиболее важных задач второго этапа – имитировать действия потенциального нарушителя, максимально реализовав обнаруженные на стадии сканирования возможные уязвимости, тем самым на 100% подтвердив их наличие и продемонстрировав на практике реальный уровень защищенности ИС. Кроме того, только выполнение подобного «внутреннего» теста на проникновение (стадия реализации уязвимостей) позволяет обнаружить и реализовать сложные комплексные стратегии нападения (стадия распространения), которые используют хакеры. Поясним это на следующем примере (см. рисунок). Предположим, стадия первоначального сканирования показала наличие потенциальных проблем на серверах 2, 5 и 8. Стадия анализа настроек выявила проблемы с защищенностью на сервере 15, рабочих станциях 110 и 250 и маршрутизаторе 5. Главная страница / Архитектура отрасли |