Аудит информационной безопасности

1.

Аудит информационной
безопасности

2.

В данной лекции будут рассмотрены
1.Управление безопасностью
2.Администрирование безопасности и защитные меры
3.Организационная модель безопасности
4.Управление информационными рисками
5.Анализ рисков
6.Политики, стандарты, базисы, руководства и процедуры
7.Классификация информации
8.Уровни ответственности
9.Персонал
10.Обучение (тренинги) по вопросам безопасности

3.

Управление безопасностью
Управление безопасностью включает в себя управление рисками, политики
информационной безопасности, процедуры, стандарты, руководства,
базисы, классификацию информации, организацию безопасности и
обучение по вопросам безопасности. Эти ключевые аспекты служат
основой корпоративной программы безопасности. Целью безопасности и
программы безопасности является защита компании и ее активов. Анализ
рисков позволяет идентифицировать эти активы, выявить угрозы,
вызывающие риски для них, оценить возможные потери и потенциальные
убытки, которые компания может понести в случае реализации любой из
этих угроз. Результаты анализа рисков помогают руководству подготовить
бюджет, учитывающий все необходимые затраты для защиты
идентифицированных активов от выявленных угроз, и разрабатывать
применимые на практике политики безопасности, которые направляют
деятельность по обеспечению безопасности. Обучение и повышение
осведомленности по вопросам безопасности позволяет довести
необходимый объем информации до сведения всех и каждого сотрудников
компании, что упрощает их работу и позволяет достичь целей безопасности.

4.

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

5.

Управление безопасностью
Управление
безопасностью
основывается
на
четко
идентифицированных и оцененных активах компании. После
идентификации и оценки активов внедряются политики безопасности,
процедуры, стандарты и руководства по обеспечению целостности,
конфиденциальности и доступности для этих активов. Для
классификации данных, выполнения анализа и оценки рисков
используются различные инструменты. Эти инструменты помогают
выявить уязвимости и показывают уровень их критичности, что
позволяет внедрить эффективные контрмеры для снижения рисков
наиболее оптимальным способом. В обязанности руководства входит
обеспечение защиты ресурсов компании в целом. Этими ресурсами
являются люди, капитал, оборудование и информация. Руководство
должно принимать в этом участие, чтобы убедиться, что программа
безопасности внедрена, угрозы, которые влияют на ресурсы компании,
учтены, а также, чтобы иметь уверенность в том, что необходимые
защитные средства эффективны.

6.

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

7.

Администрирование безопасности и защитные меры
Следующие защитные меры следует использовать для выполнения
указаний руководства по вопросам безопасности:
•Административные меры включают в себя разработку и публикацию
политик, стандартов, процедур и руководств, управление рисками,
подбор персонала, проведение тренингов по вопросам безопасности,
внедрение процедур управления изменениями.
•Технические (логические) меры включают внедрение и поддержку
механизмов управления доступом, управления паролями и ресурсами,
методами
идентификации
и
аутентификации,
устройствами
безопасности, а также настройками инфраструктуры.
•Физические меры включают в себя контроль доступа людей в здание и
различные
помещения,
использование
замков,
удаление
неиспользуемых дисководов и приводов CD-ROM, защиту периметра
здания, выявление вторжений, контроль окружения.

8.

Администрирование безопасности и защитные меры

9.

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

10.

Основные принципы безопасности
Существует несколько маленьких и больших задач
программы безопасности, но 3 основных принципа есть во
всех
программах:
доступность,
целостность
и
конфиденциальность.
Это
называется
AIC-триадой
(Availability, Integrity, Confidentiality). Уровень безопасности,
необходимый для реализации этих принципов, отличается в
различных компаниях, т.к. каждая компания имеет
собственное уникальное сочетание целей бизнеса и
безопасности, а также потребностей. Все защитные меры и
механизмы безопасности внедряются для реализации одного
(или нескольких) из этих принципов, а все риски, угрозы и
уязвимости измеряются по их потенциальной способности
нарушения одного или всех принципов AIC.

11.

Основные принципы безопасности

12.

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

13.

Целостность
Целостность обеспечивает гарантии точности и надежности информации и
предоставляющих ее информационных систем, предотвращает возможность
несанкционированных изменений. Аппаратные средства, программное
обеспечение и коммуникационное оборудование должны работать совместно для
надлежащего хранения и обработки данных, их правильного перемещения до
места назначения в неизменном виде. Системы и сети должны быть защищены от
вмешательства извне.
Атаки на системы или ошибки пользователей не должны влиять на целостность
систем и данных. Если злоумышленник установит вирус, логическую бомбу или
скрытый вход (backdoor), целостность системы будет нарушена. Это может
негативно повлиять на целостность информации, хранящейся в системе, и
привести к мошенничеству, несанкционированным изменениям программного
обеспечения и данных. Для борьбы с этими угрозами необходим строгий
контроль доступа, системы выявления вторжений.
Пользователи, как правило, влияют на целостность систем или данных в
результате ошибок (хотя внутренние пользователи также могут совершать
мошеннические или злоумышленные действия). Например, случайное удаление
конфигурационных файлов, ввод ошибочной суммы операции и т.д.
.

14.

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

15.

Определения безопасности
Уязвимость – это недостаток в программном обеспечении, оборудовании или
процедуре, который может предоставить атакующему возможность доступа к
компьютеру или сети и получения несанкционированного доступа к
информационным ресурсам компании. Уязвимость – это отсутствие или слабость
защитных мер. Уязвимостью может являться служба, запущенная на сервере,
«непропатченное» приложение или операционная система, неограниченный вход
через модемный пул, открытый порт на межсетевом экране, слабая физическая
безопасность, позволяющая любому войти в серверную комнату, отсутствие
управления паролями на серверах и рабочих станциях.
Угроза – это потенциальная опасность для информации или системы. Угрозой
является, если кто-то или что-то выявит наличие определенной уязвимости и
использует ее против компании или человека. Нечто, дающее возможность
использования уязвимости, называется источником угрозы (threat agent).
Источником угрозы может быть хакер, получивший доступ к сети через открытый
на межсетевом экране порт; процесс, осуществляющий доступ к данным
способом, нарушающим политику безопасности; торнадо, разрушившее здание;
сотрудник, совершивший ошибку, которая может привести к утечке
конфиденциальной информации или нарушению целостности файлов.

16.

Определения безопасности
Риск – это вероятность того, что источник угрозы воспользуется
уязвимостью, что приведет к негативному воздействию на бизнес. Если
межсетевой экран имеет несколько открытых портов, существует высокая
вероятность, что злоумышленник воспользуется одним из них для
несанкционированного доступа к сети. Если пользователи не обучены
правильным процессам и процедурам, существует высокая вероятность
совершения ими умышленных и неумышленных ошибок, которые могут
привести к уничтожению данных. Если в сети не внедрена система IDS,
существует высокая вероятность того, что факт проведенной атаки останется
не выявленным, пока уже не будет слишком поздно.
Воздействие (exposure) – это нечто, приводящее к потерям в связи с
действиями источника угрозы. Уязвимости воздействуют на компанию,
приводя к возможности нанесения ей ущерба. Если управление паролями
слабое, а требования к паролям не внедрены, компания подвержена
возможному воздействию в результате компрометации паролей пользователей
и их использования для несанкционированного доступа. Если компания не
следит за своей электропроводкой и не предпринимает шагов для
предотвращения пожара, она подвержена потенциальному воздействию
пожара.

17.

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

18.

Определения безопасности

19.

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

20.

Организационная модель безопасности

21.

Организационная модель безопасности
Модель безопасности имеет различные слои и различные виды
целей, которые должны быть достигнуты за различные промежутки
времени. Цели могут быть ежедневными (операционными),
среднесрочными
(тактическими)
и
долгосрочными
(стратегическими). То же самое происходит и в сфере планирования
безопасности. Ежедневные (операционные) цели связаны с
продуктивностью и выполнением текущих задач, обеспечивающих
функционирование
компании
предсказуемым
образом.
Среднесрочной (тактической) целью является, например,
объединение всех рабочих станций и ресурсов в один домен, чтобы
обеспечить возможность централизованного контроля. Примером
долгосрочных (стратегических) целей может являться перевод всех
филиалов на связь с головным офисом посредством VPNсоединений, объединение всех беспроводных технологий с целью
единого подхода к обеспечению их безопасности.

22.

Организационная модель безопасности
Стратегическое планирование работает с планами, которые находятся на
одном уровне с бизнес-целями и целями ИТ. Цели стратегического
планирования долгосрочны и имеют широкий горизонт. Стратегическое
планирование может включать некоторые из следующих целей:
•Обеспечить правильное понимание и учет рисков
•Обеспечить соответствие требованиям законодательства и регуляторов
•Интегрировать обязанности по безопасности в деятельность компании
•Создать модель зрелости для обеспечения постоянного улучшения
•Использовать безопасность как бизнес-преимущество, чтобы привлечь
больше клиентов
Тактическое планирование относится к деятельности и поддержке,
которые необходимы для достижения широких целей, выдвинутых в
процессе стратегического планирования. В общем случае, тактические
планы имеют более короткие сроки и более узкий горизонт планирования
по сравнению со стратегическими планами.

23.

Организационная модель безопасности
И, наконец, оперативное планирование – это весьма конкретные планы,
сроки и цели. Оперативное планирование предполагает указание
конкретных мероприятий, установление жестких сроков и графиков
выполнения плана. Это конкретные действия, которые нужно предпринять
для достижения целей тактических и стратегических планов. Ниже
приводятся несколько примеров оперативного планирования:
•Выполнения оценки рисков безопасности
•Недопущение негативного влияния изменений в системе безопасности на
продуктивность
•Поддержка и внедрение защитных мер
•Постоянное сканирование уязвимостей и установка программных
обновлений
•Контроль соответствия политикам
Такой подход к планированию называется горизонтом планирования
(planning horizon). Безопасность работает лучше всего, если оперативные,
тактические и стратегические цели компании определены и работают
поддерживая друг друга.

24.

Стандарты в области безопасности
CobiT (Control Objectives for Information and related Technology) – это набор стандартов
и лучших практик, разработанный ISACA (Information Systems Audit and Control
Association) и ITGI (IT Governance Institute). CobiT определяет цели контроля ИТ,
которые следует использовать для надлежащего управления ИТ и обеспечения
соответствия информационных технологий компании потребностям ее бизнеса. CobiT
состоит из четырех доменов: Планирование и Организация, Приобретение и
Внедрение, Эксплуатация и Сопровождение, Мониторинг и Оценка. Каждый домен
делится на подкатегории.
Таким образом, домены CobiT предоставляют компаниям цели и инструкции,
применимые при покупке, установке, тестировании, сертификации и аккредитации
ИТ-продуктов. CobiT очень полезен, т.к. большинство компаний используют
неформальные и непродуманные подходы при закупке ИТ-продуктов и выполнении
процедур. Многие требования, а также аудиты основываются на стандарте CobiT.
Поэтому, если вы хотите сделать своих аудиторов счастливыми, изучайте, используйте
в работе, внедряйте контрольные объекты, которые считаются лучшими практиками.
Людей, которые впервые видят CobiT, он просто ошеломляет, т.к. он имеет очень
большой объем и не поддается полномасштабному внедрению даже за пару лет. По
каждой из категорий CobiT определяет цели и методы контроля, целевые показатели,
факторы успеха, а также модель зрелости. В нем излагается подробный план,
которому можно следовать для выполнения каждой из 34 предусмотренных в нем
целей контроля.

25.

Стандарты в области безопасности

26.

Стандарты в области безопасности
CobiT основан на стандарте COSO, разработанном в 1985 году (разработчик:
Committee of Sponsoring Organizations of the Treadway Commission) для борьбы с
мошеннической финансовой деятельностью и недостоверной отчетностью. Структура
COSO состоит из следующих компонентов:
Управление средой
oФилософия управления и стиль работы
oКультура компании, как отношение к этике и мошенничеству
Оценка риска
oОпределение целей в области рисков
oВозможность управлять внутренними и внешними изменениями
Деятельность по контролю
oПолитики, процедуры и практика, применяемая для снижения риска
Информация и коммуникации
oСтруктура, обеспечивающая что только уполномоченные
достоверную информацию в то время, когда она им необходима
Мониторинг
oВыявление и реакция на недостатки контроля
лица
получают

27.

Стандарты в области безопасности
Разработка и внедрение программы безопасности не так сложны, как кажутся многим
компаниям, однако это новые для них вещи, которые представляются страшными и
запутанными.
Поэтому им следует обратиться к отраслевым стандартам и лучшим практикам,
которые дают конкретные рекомендации по созданию и реализации полноценной
программы безопасности.
Наиболее широко для этих целей используется стандарт ISO 17799, основой которого
является Британский Стандарт BS 7799. Это признанный на международном уровне
стандарт управления информационной безопасностью, который предоставляет
высокоуровневые концептуальные рекомендации по обеспечению безопасности
компании. BS 7799 состоит из двух частей: в первой части описываются цели
управления и ряд средств управления, которые могут быть использованы для
достижения этих целей, а во второй части приводится порядок внедрения и поддержки
программы безопасности. Вторая часть BS 7799 является базисом, на соответствие
которому может быть сертифицирована компания. Сертификация компании может
проводиться, например, с целью повышения доверия к ней со стороны клиентов и
партнеров, а также с целью использования факта сертификации в качестве
инструмента маркетинга. Сертификацию проводит уполномоченная независимая
третья сторона, при этом компания может быть сертифицирована на соответствие
всему ISO 17799 Part II, либо только отдельным его частям.

28.

Стандарты в области безопасности
В настоящее время осуществлен переход от стандарта ISO 17799 к целой группе
стандартов ISO, которые помогут вам понять и структурировать эти лучшие практики.
ISO использует различные номера серий для различных видов стандартов. Например,
серия ISO 9000 содержит ряд стандартов, которые относятся к управлению качеством
для бизнес-процессов. Новая серия ISO/IEC 27000 используется для стандартов
безопасности и гарантий. ISO подкорректировал стандарты 17799 для их соответствия
новому формату нумерации. Ниже представлены стандарты ISO/IEC, которые следует
использовать компаниям при разработке своей программы безопасности:
•ISO/IEC 27001. Основан на стандарте BS7799 Part II, связанном с организацией,
внедрением, контролем и совершенствованием Системы управления информационной
безопасностью.
•ISO/IEC 27002. Свод правил по управлению защитой информации (предыдущее
название – ISO 17799), основан на стандарте BS 7799 Part I.
•ISO/IEC 27004. Стандарт для измерений в области управления информационной
безопасностью.
•ISO/IEC 27005. Предназначен для реализации надлежащей информационной
безопасности на основе ориентированного на риски подхода.
•ISO/IEC 27006. Руководство по процессу сертификации / регистрации.
•ISO/IEC 27799. Руководство по защите персональных данных о здоровье.

29.

Управление безопасностью на стратегическом уровне
Стратегическое управление безопасностью очень похоже по своему характеру на
корпоративное управление и управление ИТ на том же уровне, поскольку существуют
дублирующиеся функции и задачи во всех трех. Все три вида управления работают в
рамках организационной структуры компании, и имеют одни и те же цели –
обеспечение выживания и процветания компании, просто каждый вид управления
фокусируется на своей части. Количество требований, которым должны удовлетворять
компании, постоянно растет. Советы Директоров компаний несут все больше и больше
ответственности за работу бизнеса и эффективность всей компании. В связи с этим,
более важную роль начинает играть стратегическое управление безопасностью и
защитой информации, что обеспечивает использование надлежащих механизмов и
предоставление Совету Директоров (и руководству компании) возможности
эффективного надзора с целью управления рисками, поддержания их на приемлемом
для компании уровне и ограничения потенциального ущерба.
Существует множество различных определений стратегического управления
безопасностью. Вот вариант определения, подготовленного ITGI: "Стратегическое
управление (governance) – это набор обязанностей и функций, выполняющихся
Советом Директоров и высшим руководством, которые задают стратегическое
направление, контролируют достижение целей, надлежащее управление рисками и
ответственное использование ресурсов компании".

30.

Управление безопасностью на стратегическом уровне
Это абсолютно правильное определение, но оно очень высокоуровневое и его трудно
понять. Чтобы упростить понимание, давайте сравним две компании. Компания "А"
внедрила эффективную программу стратегического управления безопасностью, а компания
"Б" нет. Обе компании имеют политику безопасности, процедуры, стандарты, одинаковые
технологии управления безопасностью (межсетевые экраны, системы выявления
вторжений, системы управления идентификацией и т.д.), подразделение безопасности,
которой руководит CISO. Может показаться, что уровень безопасности компаний "А" и "Б"
одинаков... Но это не так.
Большинство компаний на сегодняшний день имеют множество частей программы
безопасности (политики, стандарты, межсетевые экраны, подразделение безопасности,
системы выявления вторжений и т.д.), но руководство в обеспечении безопасности не
участвует, а безопасность не интегрирована в деятельность компании. За обеспечение
безопасности компании отвечает исключительно подразделение безопасности, что
является невозможным практически. Безопасность в таких компаниях является вопросом
техники. Но сегодня в мире информационной безопасности такой подход не работает.
Сегодняшняя безопасность – это намного большее, чем чисто техническое решение.
Специалисты по безопасности должны понимать, что безопасность должна соблюдаться в
рамках всей компании, и крайне важно иметь несколько центров ответственности и
подотчетности. Стратегическое управление безопасностью является целостной системой,
состоящей из различных компонентов (технических средств, персонала, процессов,
политик и т.д.), которые существуют для выживания и процветания компании.

31.

Управление безопасностью на стратегическом уровне
Компания "А"
Компания "Б"
Члены Совета Директоров понимают, что
информационная безопасность имеет
решающее значение для компании, и требуют
ежеквартально предоставлять сведения об
эффективности безопасности и выявленным
недостаткам.
CEO, CFO, CIO и руководители бизнесподразделений участвуют в работе Комитета
по управлению рисками, который собирается
каждый месяц, тема информационной
безопасности всегда является одной из тем
повестки дня.
Члены Правления не понимают, что
информационная безопасность находится в их
сфере ответственности, и сосредотачиваются
исключительно на корпоративном управлении
и прибыли.
CEO, CFO и руководители бизнесподразделений считают, что информационная
безопасность находится в сфере
ответственности CIO, CISO и ИТдепартамента. И поэтому не вмешиваются.
Высшее
руководство
устанавливает CISO использует шаблонные политики
приемлемый уровень риска, что является безопасности, включая в них название
основой для политики безопасности компании компании и подпись CEO.
и всей деятельности в области безопасности.
Высшее руководство делегировало
Вся деятельность, касающаяся безопасности,
руководителям бизнес-подразделений
осуществляется департаментом безопасности.
обязанности по управлению рисками,
Таким образом, безопасность работает в
относящимися непосредственно к их
бункере и не интегрирована в работу
подразделениям.
компании.
Критичные бизнес-процессы
документированы с учетом рисков, которые
им присущи на различных шагах.
Бизнес-процессы не документированы, не
проанализированы на наличие потенциальных
рисков, которые могут повлиять на операции,
производительность и рентабельность.

32.

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

33.

Разработка программы безопасности
Важно понимать, что программа безопасности имеет непрерывный
жизненный цикл, т.к. она должна постоянно оцениваться и
совершенствоваться. Для описания жизненного цикла программы
безопасности, будем использовать следующие шаги:
1. Планирование и Организация
2. Реализация (внедрение)
3. Функционирование и Поддержка
4. Мониторинг и Оценка

34.

Разработка программы безопасности
Однако многие компании не применяют подход жизненного цикла при разработке,
внедрении и поддержании своей программы управления безопасностью. Они не
знают, как это делать, или считают, что это слишком сложно и бесполезно. В
результате это, как правило, приводит к следующим последствиям:
•Написанные политики и процедуры, не отражаются на деятельности по обеспечению
безопасности и не поддерживают ее
•Отсутствует взаимодействие и координация между различными сотрудниками
компании, задействованными в обеспечении защиты ее активов
•Не проводится оценка результатов, отдачи от инвестиций и распределения ресурсов
•Отсутствует понимание недостатков программы безопасности, не применяются
единообразные способы исправления недостатков
•Нет гарантий соответствия требованиям законодательства, регуляторов, требованиям
политик
•Компания полностью полагается на технологии для решения всех вопросов
безопасности
•Отсутствует единый орган принятия решений в компании
•К любым нарушениям применяется подход «пожарной тревоги», а не спокойный
проактивный, детективный подход
•Появляется ложное чувство безопасности

35.

Разработка программы безопасности
Основные элементы каждой фазы жизненного цикла программы
безопасности представлены ниже:
Планирование и Организация
oПолучение одобрения от руководства
oСоздание руководящего комитета по надзору (oversight steering
committee)
oОценка бизнес-драйверов (бизнес-драйверы – это люди,
информация или задачи, которые обеспечивают реализацию бизнесцелей компании)
oСоздание профиля угроз компании
oПроведение оценки рисков
oРазработка архитектуры безопасности на организационном,
прикладном, сетевом и компонентном уровнях
oОпределение решений на каждом уровне архитектуры
oПолучение согласия руководства на дальнейшие действия

36.

Разработка программы безопасности
Реализация (внедрение)
o Распределение ролей и обязанностей
o Разработка и внедрение политик безопасности, процедур, стандартов, базисов и
руководств
o Выявление критичных данных на этапах хранения и передачи
o Реализация следующих проектов:
• Идентификация и управление активами
• Управление рисками
• Управление уязвимостями
• Соответствие требованиям
• Управление идентификацией и доступом
• Управление изменениями
• Жизненный цикл разработки программного обеспечения
• Планирование непрерывности бизнеса
• Обучение и повышение осведомленности
• Физическая безопасность
• Реакция на инциденты
o Внедрение решений (административных, технических, физических) по каждому
проекту
o Разработка решений по аудиту и мониторингу для каждого проекта
o Установка целей, соглашений об уровне обслуживания (SLA) и метрик по каждому
проекту

37.

Разработка программы безопасности
Функционирование и Поддержка
oСоблюдение
установленных
процедур
для
обеспечения
соблюдения базисных уровней в каждом реализованном проекте
oПроведение внутренних и внешних аудитов
oВыполнение задач, намеченных в каждом проекте
oУправление соглашениями об уровне обслуживания по каждому
проекту
Мониторинг и Оценка
oАнализ лог-файлов, результатов аудита, собранных значений
метрик и SLA по каждому проекту
oОценка достижения целей по каждому проекту
oПроведение ежеквартальных встреч с руководящими комитетами
oСовершенствование действий каждого этапа и их интеграция в
фазу Планирования и Организации

38.

Разработка программы безопасности
Модели и структуры весьма полезны, но они находятся на очень высоком уровне. Для
воплощения их в жизнь необходимо разработать соответствующие проекты (blueprint).
Проекты должны соответствовать требованиям безопасности компании, основанным
на обязательствах компании, бизнес-драйверах и внутренних требованиях. Например,
компания "В" имеет политику конфиденциальности, подразделение безопасности
компании разработало стандарты и процедуры, реализующие стратегию обеспечения
конфиденциальности, которым все сотрудники компании должны следовать. Затем
разрабатывается проект, в проектной документации к которому указывается больше
деталей, учитываются процессы и компоненты, к которым относятся требования
политики, стандартов и процедур. В проектной документации должно быть, как
минимум, следующее:
•Схема сети компании
•Места в сети, где находятся критичные данные
•Сегменты сети, через которые проходят критичные данные
•Различные применяемые решения по безопасности (VPN, SSL, PGP), которые
защищают критичные данные
•Подключения третьих сторон, с которыми совместно используются критичные
данные
•Используемые меры безопасности в отношении подключений третьих сторон
•И многое другое ...

39.

Разработка программы безопасности
Проекты должны соответствовать потребностям компании. Если
компания "В" использует систему управления идентификацией (identity
management), у нее должен быть соответствующий проект, проектная
документация к которому содержит описание ролей, управления
регистрацией, источников авторизации, хранения идентификационных
данных, применения решений единого входа (single sign-on) и т.д. Если
компания "В" не использует систему управления идентификацией, то ей
не нужен проект для этой системы. Ряд проектов, которые следует
разработать большинству компаний, приведен ниже:
•Управление безопасностью
•Непрерывность бизнеса
•Журналирование и мониторинг
•Управление идентификацией
•Целостность приложений
•Инфраструктура
•Управление активами
•Физическая безопасность и безопасность окружения
•И многое другое.

40.

Разработка программы безопасности

41.

Управление информационными рисками
Риск (в контексте безопасности) – это вероятность причинения
ущерба и возможные последствия. Управление информационными
рисками (IRM - Information Risk Management) представляет собой
процесс выявления и оценки рисков, снижения их до приемлемого
уровня, а также внедрения адекватных механизмов для
поддержания этого уровня. Стопроцентной защиты не существует.
Каждая система имеет уязвимости и подвержена угрозам.
Необходимо выявлять эти угрозы, оценивать вероятность их
реализации и ущерб, к которому это может привести. Затем нужно
предпринимать правильные шаги для снижения общего уровня
риска всего окружения до уровня, считающегося в компании
приемлемым.

42.

Управление информационными рисками
Риски могут иметь различные формы, не обязательно связанные с компьютерами. С
точки зрения информационной безопасности, существует несколько видов рисков,
которые компания должна понимать и учитывать. Ниже представлен список основных
категорий:
•Физический ущерб. Пожар, затопление, вандализм, отсутствие электроэнергии,
стихийные бедствия.
•Действия человека. Случайные или намеренные действия или бездействие, которые
могут нарушить работу компании.
•Неисправность оборудования. Неработоспособность систем или периферийных
устройств.
•Внутренние и внешние атаки. Хакинг, крекинг и проведение атак.
•Неправильное использование данных. Предоставление совместного доступа к
конфиденциальной информации компании, мошенничество, шпионаж, кражи.
•Утрата данных. Преднамеренное или непреднамеренное уничтожение информации.
•Ошибки приложений. Ошибки в вычислениях, ошибки ввода информации,
переполнения буфера.
Эти угрозы должны быть выявлены, категорированы, и оценены с точки зрения
масштабов потенциальных потерь. Реальные риски очень трудно измерить, однако
расставить приоритеты в списке потенциальных рисков и выбрать те, которыми
следует заняться в первую очередь, вполне достижимо

43.

Управление информационными рисками
Полноценное управление рисками требует полноценной поддержки высшего руководства,
документированного процесса поддержки миссии компании, IRM-политики и IRM-группы.
IRM-политика должна быть частью общей политики управления рисками компании. IRMполитика должна быть отражена и в организационной политике безопасности компании. В IRMполитике должны учитываться следующие аспекты:
•Цели IRM-группы
•Уровень риска, который компания приняла для себя как приемлемый
•Формальные процессы выявления рисков
•Связь между IRM-политикой и процессами стратегического планирования компании
•Обязанности, связанные с IRM, и роли, необходимые для их выполнения
•Связь между рисками и внутренним контролем
•Подходы к изменению поведения сотрудников и распределения ресурсов с учетом анализа
рисков
•Связь между рисками и целевыми показателями и бюджетами
•Ключевые показатели для мониторинга эффективности защитных мер
IRM-политика предоставляет инфраструктуру для процессов и процедур управления рисками
компании. Она должна охватывать все вопросы информационной безопасности, начиная от
подбора персонала и инсайдерских угроз, заканчивая физической безопасностью и
межсетевыми экранами. Она должна предоставлять механизм передачи информации о рисках от
IRM-группы высшему руководству, а также механизм принятия решений о необходимости
снижения рисков высшим руководством.

44.

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

45.

Анализ рисков
Анализ рисков, который на самом деле представляет собой инструмент для управления
рисками, является методом выявления уязвимостей и угроз, оценки возможного воздействия,
что позволяет выбирать адекватные защитные меры именно для тех систем и процессов, в
которых они необходимы. Анализ рисков позволяет сделать безопасность экономически
эффективной, актуальной, своевременной и способной реагировать на угрозы. Он также
помогает компании приоритезировать список рисков, определить и обосновать разумную
стоимость защитных мер.
Анализ рисков имеет четыре основные цели:
•Идентификация активов и их ценности для компании
•Идентификация угроз и уязвимостей
•Количественная оценка вероятности и влияния на бизнес этих потенциальных угроз
•Обеспечение экономического баланса между ущербом от воздействия угроз и стоимостью
контрмер
Анализ рисков позволяет сравнить годовую стоимость защитных мер с потенциальным
ущербом. Годовая стоимость защитных мер не должна превышать потенциальный годовой
ущерб. Также, анализ рисков позволяет связать программу безопасности с целями и
требованиями бизнеса компании, что крайне важно для успеха и в том, и в другом.
Перед началом работы по выявлению и анализу рисков важно понять цель данной работы, ее
объем и ожидаемый результат. Следует учитывать, что попытка проанализировать все риски во
всех областях за один раз может оказаться невыполнимой.

46.

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

47.

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

48.

Ценность информации и активов
Например, стоимость сервера составляет $4,000, но это не является его
ценностью, учитываемой при оценке рисков. Ценность определяется затратами на
его замену или ремонт, потерями из-за снижения производительности, ущербом
от повреждения или утраты хранящихся на нем данных. Именно это будет
определять ущерб для компании в случае повреждения или утраты сервера по той
или иной причине.
Следующие вопросы должны быть учтены при определении ценности активов:
•Затраты на получение или разработку актива
•Затраты на поддержку и защиту актива
•Ценность актива для владельцев и пользователей
•Ценность актива для злоумышленников (конкурентов)
•Ценность интеллектуальной собственности, использованной при разработке
актива
•Цена, которую другие готовы заплатить за актив
•Затраты на замену актива при утрате
•Операционная и производственная деятельность, которая зависит от
доступности актива
•Ответственность в случае компрометации актива
•Польза и роль актива в компании

49.

Ценность информации и активов
Понимание ценности актива является первым шагом к пониманию того,
какие средства и механизмы безопасности должны использоваться для его
защиты. Ценность актива определяет стоимость защитных мер, которые
следует использовать для его защиты.
Определение стоимости активов полезно для компании по целому ряду
причин, включая следующие:
•Для проведения анализа затраты/выгоды (cost/benefit analyse)
•Для выбора конкретных контрмер и защитных средств
•Для определения необходимого уровня страхового покрытия
•Для понимания, чем именно рискует компания
•Для выполнения требований законодательства, регуляторов, соблюдения
должной заботы (due care)
Активы могут быть материальным (компьютеры, оборудование,
материалы) или нематериальные (репутация, данные, интеллектуальная
собственность). Обычно трудно оценить количественно ценность
нематериальных активов (например, репутации), которая может меняться
с течением времени.

50.

Идентификация угроз
Как было сказано ранее, риск – это вероятность того, что источник угрозы
воспользуется уязвимостью, что приведет к негативному воздействию на
бизнес. Существует множество видов источников угрозы, которые могут
использовать разные типы уязвимостей, что может привести к
определенным угрозам.
Источник угрозы
Вирус
Хакер
Пользователи
Пожар
Сотрудник
Подрядчик
Атакующий
Нарушитель
Может использовать эту уязвимость
Отсутствие антивирусного
программного обеспечения
Большое количество служб,
запущенных на сервере
Неверно настроенный параметр
операционной системы
Отсутствие огнетушителей
В результате возникнет угроза
Заражение вирусом
Несанкционированный доступ к
конфиденциальной информации
Неисправность системы
Здание и компьютеры повреждены,
возможны человеческие жертвы
Отсутствие обучения или требований Общий доступ к критичной
Отсутствие контроля
информации Внесение изменений во
вводимую информацию и выводимую
из приложений обработки данных
Слабые механизмы контроля доступа Утечка конфиденциальной
информации
Плохо написанное приложение
Проведение атаки "переполнение
Нестрогие настройки межсетевого
буфера" Проведение DoS-атаки
экрана
Отсутствие охраны
Похищение компьютеров и других

51.

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

52.

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

53.

Анализ сбоев и дефектов
FMEA (Failure Modes and Effect Analysis) – это метод определения функций,
выявления функциональных дефектов, оценки причин дефекта и его последствий
с помощью структурированного процесса. Применение этого процесса в случае
постоянных дефектов позволяет определить место, где ошибка, скорее всего,
произойдет. Это очень помогает выявить уязвимые места, точно определить
границы уязвимостей и последствия их эксплуатации. В свою очередь, это
позволяет не только упростить применение исправлений, устраняющих
уязвимости, но и обеспечить более эффективное использование ресурсов в
рамках этой задачи.
Следуя определенной последовательности шагов, можно достичь наилучших
результатов в анализе дефектов.
1. Начните с блок-схемы системы или контроля (объекта анализа).
2. Рассмотрите, что произойдет, если каждый блок диаграммы даст сбой.
3. Нарисуйте таблицу, и укажите в ней дефекты в паре с их последствиями и
оценкой этих последствий.
4. Корректируйте проект системы и вносите соответствующие изменения в
таблицу до тех пор, пока не станет ясно, что система не подвержена проблемам.
5. Получите несколько инженерных обзоров характера дефектов и анализа
последствий.

54.

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

55.

Анализ сбоев и дефектов
Подготовлено
Согласовано:
Дата:
Версия:
Идентификация
элемента
Контентный
фильтр
прикладного
уровня IPS
Дефект воздействует на...
Функция
Характер сбоя Причина сбоя Последствия Последствия Последствия для Метод выявления
на
более системы
сбоя
высоком
уровне
Защита
Сбои, приводят Перегрузка Единая точка IPS блокирует IPS выходит из Сообщение о
периметра к отключению вследствие отказа; отказ в входящий
строя
текущем состоянии
большого
обслуживании поток
(работоспособности
объема
трафика
), отправляется на
трафика
консоль и по
электронной почте
администратору
безопасности
Центральный
"движок"
обновления
антивирусных
сигнатур
Передает
Сбои не
Отключается Не
Сеть
Центральный Сообщение о
обновления позволяют
центральный обновляются заражается
сервер
может текущем состоянии
сигнатур на обеспечить
сервер
антивирусы вредоносным быть заражен (работоспособности
все серверы адекватную и
на серверах и кодом
и/или заражать ), отправляется на
и
рабочие своевременную
рабочих
другие системы консоль и страницу
станции
защиту от
станциях
сетевого
вредоносного
администратора
кода
Водяные трубы
системы
пожаротушения
Тушение
Неисправности, Вода в трубах Нет
пожара
в приводят к
замерзает
пяти зонах неработоспособздания 1
ности
В здании 1 Трубы системы Датчики системы
тушение
пожаротушения пожаротушения
пожара
не ломаются
напрямую
производится
связываются с
центральной
консолью
пожарной системы

56.

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

57.

Анализ сбоев и дефектов

58.

Анализ сбоев и дефектов
Некоторые из наиболее распространенных программных сбоев, которые
могут быть исследованы с помощью анализа дерева сбоев, приведены ниже:
•Ложные срабатывания (тревоги или защиты)
•Недостаточная обработка ошибок
•Нарушение последовательности или порядка
•Некорректная синхронизация выдачи результатов
•Корректные, но неожиданные результаты
Итак, мы получили надлежащую поддержку руководства в рамках задачи по
анализу рисков, создали группу анализа рисков из сотрудников различных
подразделений компании, определили ценность каждого из активов компании,
определили все возможные угрозы, которые могут повлиять на активы. Мы
также приняли во внимание все возможные варианты отложенного ущерба,
который может выдержать компания в отношении каждого актива и угрозы.
Мы провели анализ сбоев и дефектов (или анализ дерева сбоев) для
понимания причин, лежащих в основе выявленных угроз. Следующим шагом
является расчет актуальных для компании рисков с использованием
качественных и количественных методов.

59.

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

60.

Шаги процесса анализа рисков
Шаг 1: Определить ценность активов. Для каждого актива
необходимо ответить на следующие вопросы для определения его
ценности:
•В чем заключается ценность данного актива для компании?
•Сколько стоит его поддержка?
•Какую прибыль он приносит компании?
•Сколько за него готовы заплатить конкуренты?
•Сколько будет стоить его повторное создание или восстановление?
•Сколько стоило его получить или разработать?
•Какова мера ответственности в случае компрометации данного
актива?

61.

Шаги процесса анализа рисков
Шаг 2: Оценить потенциальные потери от угрозы. Для оценки
потенциальных потерь, необходимо ответить на следующие
вопросы:
•К каким физическим повреждениям может привести угроза и
сколько это будет стоить?
•Какую потерю продуктивности может вызвать угроза и сколько это
будет стоить?
•Какие потери понесет компания в случае разглашения
конфиденциальной информации?
•Какова стоимость восстановления после воздействия угрозы?
•Какова стоимость потерь в случае неисправности критичных
устройств?
•Каков ожидаемый ущерб от единичного инцидента (SLE – Single
Loss Expectancy) для каждого актива и каждой угрозы?

62.

Шаги процесса анализа рисков
Шаг 3: Выполнить анализ угроз. Для анализа угроз нужно выполнить
следующие действия:
•Собрать информацию о вероятности каждой угрозы, опросив
сотрудников каждого подразделения, проанализировав произведенные
ранее записи, а также официальные источники по безопасности, которые
предоставляют такую информацию.
•Рассчитать среднегодовую частоту возникновения инцидентов (ARO –
Annualized Rate of Occurrence), которая показывает сколько инцидентов
может произойти за год.
Шаг 4: Определить общие годовые потери на угрозу. Для этого нужно
выполнить следующее:
•Объединить потенциальные потери и вероятность.
•Рассчитать ожидаемый среднегодовой ущерб (ALE – Annualized Loss
Expectancy) на угрозу, используя информацию, собранную на первых трех
шагах.
•Выбрать контрмеры для противодействия каждой угрозе.
•Выполнить анализ затрат/выгод выбранных контрмер.

63.

Шаги процесса анализа рисков
Шаг 5: Уменьшить, перенести, избежать или принять риск. Для каждого риска
необходимо выбрать меры по его снижению, переносу, либо принять его.
Методы снижения риска:
o Внедрить защитные меры и средства управления;
o Усовершенствовать процедуры;
o Изменить окружение;
o Внедрить методы раннего обнаружения для своевременного выявления
факторов воздействия угрозы и снижения возможных последствий;
o Разработать план действий в непредвиденных ситуациях, позволяющий
продолжить работу в случае воздействия определенных угроз и снизить
последствия от угрозы;
o Создать препятствия для реализации угрозы;
o Провести тренинг по вопросам безопасности.
Перенос риска – например, застраховать некоторые риски.
Избежание риска – прекратить деятельность, вызывающую риск.
Принятие риска – смириться с риском и не тратить деньги на защиту от него (это
целесообразно, если стоимость защитных мер превышает величину возможного
ущерба). Однако при этом нужно учитывать, что реализация риска может вести к
дополнительным последствиям (например, потере репутации).

64.

Шаги процесса анализа рисков
При проведении количественного анализа рисков необходимы, реальные цифры и
расчеты. Ранее уже были упомянуты показатели SLE (ущерб от единичного
инцидента) и ALE (ожидаемый среднегодовой ущерб). SLE – это потенциальная сумма
(в деньгах) ущерба для компании в результате единичного факта реализации
соответствующей угрозы:
Ценность актива х Фактор воздействия (EF - Exposure Factor) = SLE
EF (фактор воздействия) – это процент ущерба для актива от реализовавшейся угрозы,
т.е. часть значения (ценности), которую актив потеряет в результате инцидента.
Например, ценность актива "хранилище данных" составляет $150,000. В случае
пожара может быть повреждено 25% хранилища (но не более, т.к. установлена
система пожаротушения, поблизости находится пожарная часть и т.д.). В этом случае
SLE будет составлять $37,500. Значение SLE используется при расчете ALE:
SLE х Среднегодовая частота возникновения инцидентов (ARO - Annualized Rate of
Occurrence) = ALE
ARO (среднегодовая частота возникновения инцидентов) – это величина,
представляющая собой ожидаемую частоту реализации соответствующей угрозы в
год. Значение ARO может быть от 0,0 (никогда) до 1,0 (по крайней мере, раз в год) и
выше (несколько раз в год). Например, наводнения в той местности, в которой
расположено здание компании, происходят в среднем раз в 1000 лет. Значит величина
ARO составляет 0,001. репутации).

65.

Шаги процесса анализа рисков
Таким образом, если SLE для хранилища данных компании при
пожаре равно $37,500, а пожары в аналогичных условия случаются
примерно раз в 10 лет (ARO равно 0,1), величина ALE будет равна
$3,750 ($37,500 х 0,1 = $3,750).
Значение ALE используется при оценке целесообразности
внедрения тех или иных мер защиты соответствующего актива от
соответствующей угрозы – годовая стоимость защитных мер,
обеспечивающих необходимый уровень безопасности актива, не
должна превышать значение ALE. Применение более дорогих
защитных мер не будет эффективным и целесообразным.
Рассмотрим пример результатов анализа рисков. Используя
полученные данные компания может принять обоснованное
решение о том, какие угрозы необходимо рассматривать в первую
очередь, основываясь на их последствиях и вероятности
реализации. Также компания может оценить целесообразный
уровень затрат на защиту от каждой угрозы.

66.

Шаги процесса анализа рисков
Актив
Угроза
SLE
ARO
ALE
Здание
Пожар
$230,000
0,1
$23,000
Коммерческая тайна
Хищение
$40,000
0,01
$400
Файловый сервер
Неисправность $11,500
0,1
$1,150
Данные
Вирус
$6,500
1,0
$6,500
Информация о
кредитной карте
клиента
Хищение
$300,000
3,0
$900,000

67.

Результаты анализа рисков
Группа анализа рисков должна иметь четко определенные цели.
Следующий список показывает что в основном можно ожидать от
результатов анализа рисков
•Ценность активов в денежном выражении;
•Полный список всех возможных и существенных угроз;
•Вероятная частота возникновения каждой угрозы;
•Потенциальные потери компании от угроз, которые она может
понести в 12-ти месячный срок;
•Рекомендуемые меры безопасности, контрмеры и действия.
Хотя данный список следует по возможности детализировать,
следует сделать краткое резюме для руководства, на основании
которого можно быстро сделать выводы о результатах анализа.

68.

Качественный анализ рисков
Другим методом анализа рисков является качественный метод,
который не присваивает количественные или денежные значения
компонентам и потерям, вместо этого он использует различные
сценарии вероятности риска, уровней серьезности угроз и
обоснованности различных возможных контрмер. Для качественного
анализа рисков применяются суждения, лучшие практики, интуиция и
опыт. Примерами техник сбора данных для качественного анализа
рисков являются: метод Delphi, мозговой штурм, работа с архивными
документами, опросы целевых групп, анкетирование, чек-листы,
личные встречи, интервью. Группа анализа рисков должна выбрать
лучшую технику в зависимости от видов оцениваемых угроз, культуры
компании, людей, вовлеченных в процесс анализа.
В группу анализа рисков должны быть включены сотрудники, которые
имеют опыт и образование в той области, в которой они будут
оценивать угрозы. В процессе оценки угрозы и ущерба каждый член
группы высказывает свою оценку, основываясь на своем предчувствии
и опыте.

69.

Качественный анализ рисков

70.

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

71.

Качественный анализ рисков
Рассмотрим простой пример качественного анализа рисков. Группа
анализа рисков написала одностраничный сценарий, описывающий
угрозу получения хакером доступа к конфиденциальной
информации, хранящейся на файловых серверах компании. Группа
распространяет этот сценарий между пятью сотрудниками (ИТдиректор, администратор базы данных, программист, системный
инженер и руководители подразделения технической поддержки),
которые заполняют лист оценки, ранжируя (от 1 до 5) серьезность
угрозы, уровень потенциального ущерба, эффективность каждой
защитной меры. Затем на основе этих результатов один из членов
группы готовит отчет для руководства, в котором указывает, что из
проанализированных трех вариантов защиты (межсетевой экран,
система IDS и honeypot), наиболее эффективной является защита с
помощью межсетевого экрана.

72.

Техника Delphi
Техника Delphi – это метод группового принятия решений,
обеспечивающий получение от каждого члена его истинного
мнения, не подверженного влиянию мнения других. Каждый член
группы указывает свое мнение на листке бумаги, после чего все
члены группы показывают свои листки для выполнения
окончательного
анализа.
Результаты
объединяются
и
распространяются между членами группы, которые пишут свои
комментарии и возвращают их. Комментарии объединяются и снова
распространяются до тех пор, пока не будет достигнут консенсус.
Этот метод позволяет получить согласованное общее мнение по
стоимости, уровню потерь, вероятности события без устного
обсуждения. С использованием данной техники возможно
проведение анонимных опросов.

73.

Количественный или качественный
Каждый метод имеет свои преимущества и недостатки. Критерием выбора могут быть
особенности группы анализа рисков, мнение руководства, имеющиеся инструменты
анализа рисков, культура компании. Целью обоих методов является оценка реальных
рисков компании, их классификация по уровню серьезности угроз, что позволит
выбрать правильные контрмеры в рамках имеющегося бюджета.
Недостатки качественного анализа:
Оценка и результаты в основном субъективны;
Обычно исключает возможность оценки затрат/выгод;
Сложно сопоставить цели управления рисками с субъективными оценками;
Нет стандартов. Каждый специалист имеет свою интерпретацию процесса и
результатов.
Недостатки количественного анализа:
Расчеты более сложны. Сложно объяснить руководству как эти значения были
получены;
Процесс очень трудоемок без применения средств автоматизации;
Больше предварительной работы, связанной с получением детальной информации об
окружении;
Нет стандартов. Каждый специалист имеет свою интерпретацию процесса и
результатов.

74.

Выбор защитных мер
Преимущества внедряемых защитных механизмов должны
превышать затраты на них, только в этом случае они будут
эффективными. Для проведения такой оценки используется анализ
затрат/выгод. Обычно это считают следующим образом:
(ALE до ввода защитных мер) – (ALE после ввода защитных мер) –
(годовая стоимость защитных мер) = ценность защитных мер
Например, ALE угрозы выведения веб-сервера из строя хакерами
составляет $12,000 до внедрения соответствующих защитных мер, а
после их внедрения ALE снижается до $3,000. При этом годовая
стоимость функционирования и поддержки этих защитных мер $650. В этом случае ценность защитных мер составляет $8,350 в
год.

75.

Выбор защитных мер
Стоимость контрмер – это не просто цена их покупки. Нужно
учитывать следующие элементы при расчете полной стоимости
контрмер:
•Стоимость продукта
•Стоимость проектирования / планирования
•Стоимость внедрения
•Необходимость внесения изменений в окружение
•Совместимость с другими контрмерами
•Эксплуатационные требования
•Тестирование
•Стоимость восстановления, замены и обновления
•Стоимость эксплуатации и поддержки
•Влияние на производительность
•Стоимость подписки
•Работа сотрудников в нерабочее время и по выходным дням для
мониторинга и реакции на сообщения об инцидентах

76.

Выбор защитных мер
Например, компания А решает защитить ряд своих ресурсов с помощью IDS, стоимостью
$5,500. Эта IDS должна быть протестирована в отдельном тестовом сегменте сети, чтобы
ИТ-службы убедились в безопасности ее ввода в промышленную эксплуатацию. После
этого ИТ-службы должны установить и настроить сенсоры и программное обеспечение
для мониторинга. Затем ИТ-службы должны перенастроить коммуникационное
оборудование, направив все потоки трафика через IDS, а также ограничить доступ к
консоли IDS, настроить базу данных сигнатур атак. Только после этого IDS можно
включить в работу.
При этом нужно учесть вероятное снижение производительности сети, возможные
неудобства для пользователей, проявление "тонкостей", о которых "забыл" заранее
сообщить поставщик, а также затраты времени и денег на обучение персонала, а затем
затраты на реагирование на реальные и ложные срабатывания IDS. Кроме того, может
возникнуть необходимость закупки средств оповещения администратора безопасности об
инцидентах, выявленных IDS, от которых будет зависеть время реакции на инциденты.
Таким образом изначальная цена увеличивается: $5,500 стоит сама система IDS, $2,500
стоит обучение персонала, $3,400 стоит тестирование системы, $2,600 – потери
производительности пользователей, вызванные внедрением этой системы и еще $4,000
стоит перенастройка коммуникационного оборудования, установка IDS, выявление
ошибок, установка патчей. Реальная стоимость этой защитной меры составит $18,000.
Если при этом рассчитанная величина вероятного ущерба составляет только $9,000,
применение этой IDS неэффективно и приведет к перерасходу адекватного бюджета на
100%.

77.

Выбор защитных мер
Характеристика
Модульная
архитектура
Описание
Система может быть установлена или удалена из
окружения без неблагоприятного воздействия на
другие механизмы
Обеспечивает
Стандартный уровень безопасности обеспечивается
стандартную защиту стандартными настройками всех механизмов
Предоставляет
Администратор может отменить ограничения при
возможность отмены необходимости
функциональности
Минимальные
После установки должны применяться настройки по
привилегии по
умолчанию, не предусматривающие какие- либо
умолчанию
разрешения и права, кроме заданных явно
Независимость
Средства защиты могут быть использованы для
средств защиты и
защиты различных активов, а различные активы, в
защищаемых активов свою очередь, могут быть защищены различными
средствами
Гибкость и
Должно быть предоставлено как можно больше
безопасность
функций безопасности, однако настройки при этом
должны быть гибкими и позволять выбрать нужный
набор функций (а не «все», либо «ничего»)
Явное разделение
Пользователь должен иметь минимум разрешений
«пользователя» и
на изменение настроек или отключение механизмов
«администратора»
защиты

78.

Выбор защитных мер
Характеристика
Минимальное
вмешательство
человека
Описание
Средства защиты должны предусматривать
минимальное вмешательство человека, т.к. любые
производимые вручную настройки и изменения с
высокой степенью вероятности приводят к ошибкам.
Простота обновления Программное обеспечение продолжает развиваться,
поэтому важно, чтобы обновления устанавливались
безболезненно
Средства аудита
Должен существовать механизм, являющийся
неотъемлемой частью средства защиты,
предоставляющий минимальный и/или подробный
аудит событий
Минимальная
Средства защиты должны быть гибкими и не
зависимость от других предъявлять жестких требований к окружению, в
компонентов
которое они устанавливаются
Простота
использования,
незаметность для
персонала
Средства защиты не должны снижать
производительность работы, добавлять
дополнительные шаги к простым задачам;
пользователи не должны испытывать дискомфорт изза их применения
Исходящая
Важная информация должна быть представлена в
информация (отчеты) простой для человека форме, понятной и
должна
применимой для анализа изменений и тенденций
предоставляться в
простом и понятном

79.

Выбор защитных мер
Характеристика
Описание
Должна существовать Средства защиты должны позволять сбросить
возможность сброса настройки и вернуться к оригинальной конфигурации
настроек средства
и настройкам, что не должно оказывать влияние на
защиты
защищаемые системы и активы
Возможность
тестирования
Отсутствие
компромиссов
Должна существовать возможность протестировать
работу средств защиты в различном окружении и в
различных ситуациях
Средства защиты не должны содержать скрытых
каналов и потайных входов (backdoors)
Производительность
систем и
пользователей
Применение средств защиты не должно оказывать
существенного влияния на производительность
систем и пользователей
Качественная система Порог срабатывания системы оповещения персонала
оповещений
об инцидентах безопасности должен быть
настраиваемым, типы оповещений должны быть
приемлемыми
Не должно
Средства защиты не должны оказывать
оказываться влияние неблагоприятного воздействия на активы
на активы

80.

Общий риск и остаточный риск
Общий риск (total risk) – это риск, перед лицом которого стоит
компания, не внедрившая никаких защитных мер. Если его уровень
не приемлем для компании (вероятный ущерб от реализации риска
превышает стоимость защитных мер), она внедряет защитные меры
чтобы снизить общий риск до приемлемого уровня. Однако систем
или сред, защищенных на 100%, не существует – всегда есть
некоторый остаточный риск (residual risk). Необходимо обеспечить,
чтобы уровень остаточного риска был приемлем для компании.
Общий риск = угроза х уязвимость х ценность актива
Остаточный риск = (угроза х уязвимость х ценность актива) х
недостаток контроля

81.

Обработка риска
Когда компания рассчитала величину общего и остаточного риска, она должна
принять решение о дальнейших действиях. Существует 4 варианта действий,
которые можно предпринять в отношении риска: перенести, избежать, уменьшить
или принять риск.
Если общий или остаточный риск слишком высок для компании, она может
купить страховку, чтобы перенести риск на страховую компанию.
Если компания решает прекратить деятельность, которая вызывает риск, это
называется избеганием риска. Например, компания может запретить
использование сотрудниками программ передачи мгновенных сообщений (IM –
Instant Messenger), вместо того, чтобы бороться с множеством рисков, связанных с
этой технологией.
Другим подходом является снижение риска до уровня, считающегося
приемлемым для компании. Примером может быть внедрение межсетевого
экрана, проведение обучения сотрудников и т.д.
И последний подход заключается в осознанном принятии риска компанией,
которая осознает его уровень, размеры потенциального ущерба, и, тем не менее,
решает жить с этим риском и не внедрять контрмеры. Для компании
целесообразно принять риск, когда анализ затрат / выгоды показывает, что
расходы на контрмеры превышают размеры потенциальных потерь.

82.

Обработка риска
Ключевым вопросом при принятии риска является понимание того,
почему это является наилучшим выходом из конкретной ситуации.
К сожалению, в наше время многие ответственные лица в
компаниях принимают риски, не понимая в полной мере, что они
принимают. Обычно это связано с относительной новизной
процессов управления рисками в области безопасности,
недостаточным уровнем образования и опытом работы этих людей.
Когда руководителям бизнес-подразделений вменяются обязанности
по борьбе с рисками в их подразделениях, чаще всего они
принимают любые риски, т.к. их реальные цели связаны с
производством компанией готовой продукции и выводом ее на
рынок, а вовсе не с рисками. Они не хотят увязать в этой глупой,
непонятной и раздражающей безопасности.

83.

Обработка риска
Принятие риска должно быть основано на нескольких факторах. В
частности, нужно ответить на следующие вопросы:
• Потенциальные потери меньше стоимости контрмер?
•Сможет ли компания жить с той "болью", которую причинит ей
принятие этого риска?
Второй вопрос имеет отношения в том числе и к бесплатным
решениям. Например, если компания примет этот риск, она должна
будет добавить еще три шага в свой производственный процесс:
•Имеет ли это смысл для нее?
В другом случае, принятие риска может привести к возрастанию
количества инцидентов безопасности:
•Готова ли компания справиться с этим?

84.

Обработка риска