Ценность активов, вероятности угроз и уровни уязвимостей сопоставляются в следующей таблице.
При объединении ценности активов с угрозами и уязвимостями необходимо рассмотреть возможность создания комбинацией угроза/уязвимость проблем для конфиденциальности, целостности и/или доступности этих активов. В зависимости от результатов этих рассмотрений должны быть выбраны подходящие значения ценности активов, т.е. значения, которые выражают последствия нарушения конфиденциальности, или целостности, или доступности.
Использование этого метода может привести к рассмотрению одного, двух или трех рисков для одного актива, в зависимости от конкретной рассматриваемой комбинации «угроза/уязвимость». Если используются дополнительные свойства (такие, например, как аутентичность или неотказуемость), тогда для каждого актива и каждой комбинации «угроза/уязвимость» может вычисляться даже более трех рисков. В этом примере величина рисков определяется по шкале от 0 до 8:
Величина риска в диапазоне от 0 до 2 соответствует относительно низкому уровню риска, который, как правило, может быть принят без дальнейшей обработки.
Величина риска в диапазоне от 3 до 5 соответствует среднему уровню риска, который может требовать определенной обработки.
Величина риска в диапазоне от 6 до 8 соответствует высокому уровню риска, который должен быть обработан в первую очередь.
Для многих организаций такой шкалы вполне достаточно. Однако ничто не мешает эту шкалу расширить, введя дополнительные уровни угроз, уязвимостей или ущерба (ценности актива).
Реестр информационных рисков – основной документ, описывающий текущую ситуацию с рисками в организации. Он формируется путем объединения таблицы ценности активов, таблицы оценки угроз и уязвимостей и таблицы величины рисков.
После идентификации угроз и уязвимостей необходимо оценить вероятность их объединения и возникновения риска. Это включает в себя оценку вероятности реализации угроз, а также того, насколько легко они могут использовать имеющиеся уязвимости.
Оценка вероятности угроздолжна учитывать природу угроз и особенности, присущие различным группам угроз, например:
Преднамеренные угрозы. Вероятность преднамеренных угроз зависит от мотивации, знаний, компетенции и ресурсов, доступных потенциальному злоумышленнику, а также от привлекательности активов для реализации атак.
Случайные угрозы. Вероятность случайных угроз может оцениваться с использованием статистики и опыта. Вероятность таких угроз может зависеть от близости организации к источникам опасности, таким как автомагистрали и железнодорожные пути, а также заводы, имеющие дело с опасными материалами, химическими веществами или бензином. Также географическое положение организации оказывает влияние на возможность возникновения экстремальных погодных условий. Вероятность человеческих ошибок (одна из наиболее распространенных случайных угроз) и поломки оборудования также должны быть оценены.
Прошлые инциденты. Инциденты, происходившие в прошлом, иллюстрирующие проблемы в существующих защитных мерах.
Новые разработки и тенденции. Они включают в себя отчеты, новости и тенденции, полученные из Интернет, групп новостей, от других организаций и консультантов.
Лучше всего получать информацию, используемую для оценки вероятности угрозы и величины уязвимости, от тех, кто непосредственно вовлечен в бизнес-процессы, находящиеся в условиях риска, а также от экспертов по безопасности, имеющих наибольший опыт в обращении с этими угрозами и уязвимостями. Также может быть полезным использование списков угроз и уязвимостей и взаимосвязей между угрозами и механизмами контроля из ISO 27002, приведенных в Приложении № 6.
Для оценкивероятности реализации угрозы может использоваться трехуровневая качественная шкала:
Н– низкая вероятность. Маловероятно, что эта угроза осуществится, не существует инцидентов, статистики, мотивов и т.п., которые указывали бы на то, что это может произойти. Ожидаемая частота реализации угрозы не превышает 1 раза в 5–10 лет.
С– средняя вероятность. Возможно, эта угроза осуществится (в прошлом происходили инциденты), или существует статистика или другая информация, указывающая на то, что такие или подобные угрозы иногда осуществлялись прежде, или существуют признаки того, что у атакующего могут быть определенные причины для реализации таких действий. Ожидаемая частота реализации угрозы – примерно один раз в год.
В– высокая вероятность. Эта угроза, скорее всего, осуществится. Существуют инциденты, статистика или другая информация, указывающая на то, что угроза, скорее всего, осуществится, или могут существовать серьезные причины или мотивы для атакующего, чтобы осуществить такие действия. Ожидаемая частота реализации угрозы – еженедельно или чаще.
Такой трехуровневой шкалы обычно достаточно для первоначальной высокоуровневой оценки угроз. В дальнейшем ее можно расширить, добавив еще пару промежуточных уровней.
Таблица. Оценка вероятности угроз (фрагмент)
№
Группа угроз
Уровень
Примечание
Угрозы утечки конфиденциальной информации
Утечка конфиденциальной информации из сети по каналам связи (email, web, chat/IM и т.п.)Не целевое использование компьютерного оборудования и сети Интернет сотрудниками организации
С
Квалификация сотрудников досточно низкая и большинство каналов перекрыто, что снижает вероятность данной угрозы
Утечка конфиденциальной информации на мобильных устройствах, носителях информации, ноутбуках и т.п.Не целевое использование компьютерного оборудования и сети Интернет сотрудниками организации
С
Угроза достаточно легко осуществима, однако ноутбуки и КПК не используются
Прослушивание внешних каналов связи злоумышленниками
Н
Угроза не соответствует ценности информации
Общая вероятность инцидента также зависит от уязвимостей активов, т.е. насколько легко слабости активов могут быть использованы для успешного осуществления угроз.
Уязвимости, так же как и угрозы, могут быть оценены по трехуровневой качественнойшкале. Значение уровня уязвимости показывает, насколько вероятно успешное осуществление угрозы с использованием данной уязвимости в случае, если эта угроза будет реализовываться. Соответствующие качественные уровни уязвимости могут быть определены, например, следующим образом:
В– вероятно. Уязвимость легко использовать, и существует слабая защита или защита вообще отсутствует. Вероятность успешной реализации угрозы ~ 0.9 – 1.
С– возможно. Уязвимость может быть использована, но существует определенная защита. Вероятность успешной реализации угрозы ~ 0.5.
Н– маловероятно. Уязвимость сложно использовать, и существует хорошая защита. Вероятность успешной реализации угрозы ~ 0 – 0.1.
Так же, как и с угрозами, для первоначальной высокоуровневой оценки уязвимостей вполне должно хватить данной трехуровневой шкалы. В дальнейшем для более детальной оценки, при необходимости, сможем добавить еще пару промежуточных уровней.
Оценка вероятности угроз и величины уязвимостей заносится в таблицу, изображенную на рисунке, и в реестр информационных рисков, минуя промежуточную таблицу.
Таблица. Результаты оценки угроз и уязвимостей (фрагмент)
№
Группы угроз
Уязвимости
Вероятность угроз
Уровень уязвимости
Механизмы контроля
НСД к ресурсам ЛВС компании со стороны внутренних злоумышленниковМаскарад, использование чужих пользовательских идентификаторов, раскрытие паролей и другой аутентификационной информации
Слабые пароли, отсутствие парольной политикиНаличие внутренних уязвимостей, обусловленных несвоевременным обновление ОСМониторинг действий пользователей не производится
С
В
Корректное управление доступомНизкая квалификация пользователей для осуществления НСД
НСД к ресурсам ЛВС компании со стороны внешних злоумышленниковМаскарад, использование чужих пользовательских идентификаторов, раскрытие паролей и другой аутентификационной информации
Отсутствуют последние обновления на корпоративном файрволлеЕдинственный защитный барьерНаличие внутренних уязвимостей, обусловленных несвоевременным обновлением ОСОтсутствие системы обнаружения вторжений (IDS)
В
C
Хорошая защита периметраОтсутствие известных уязвимостей
Следует обратить внимание на то, что в таблице оценки угроз и уязвимостей фигурируют группы угроз и группы уязвимостей, а оценка вероятности является суммарной оценкой вероятностей всех угроз и всех связанных с ними уязвимостей.
При оценке величины группы уязвимостей взвешиваются все найденные слабости защиты, способствующие успешному осуществлению угроз, и все существующие механизмы контроля, затрудняющие осуществление этих угроз. Суммарный уровень группы уязвимостей определяется путем сложения уровней всех идентифицированных уязвимостей и вычитания из них уровней всех идентифицированных механизмов контроля, при это действенность (уровень) механизма контроля определяется по такому же принципу, как и уровень уязвимости:
В– высокий уровень контроля. Маловероятно, что такой механизм контроля удастся обойти. Вероятность обхода (преодоления) механизма контроля ~ 0 – 0.1.
С– средний уровень контроля. Механизм контроля обеспечивает определенную защиту, однако есть возможность его обойти, затратив определенные усилия. Вероятность обхода (преодоления) механизма контроля ~ 0.5.
Н– низкий уровень контроля. Такой механизм контроля незначительным образом уменьшает уязвимости активов, и его довольно просто обойти. Вероятность обхода (преодоления) механизма контроля ~ 0.9 – 1.
Для определения итогового уровня уязвимости, рассматриваемой для конкретной группы угроз, обычно используются экспертные оценки. На правую чашу весов кладутся механизмы контроля, на левую – уязвимости. Если сильно перевешивают уязвимости, тогда итоговый уровень будет высоким. Если существенный перевес на стороне механизмов контроля, которые способны нивелировать все имеющиеся уязвимости, тогда итоговый уровень уязвимости будет низким. Если между механизмами контроля и уязвимостями наблюдается примерный паритет, тогда итоговый уровень уязвимости оценивается как средний.
Конечно, такая оценка навряд ли может считаться объективной, т.к. всецело зависит от мнения того или иного эксперта об уязвимостях и механизмах контроля. К сожалению, ничего более точного мы здесь предложить не можем. Многие умные люди пытались придумать более точные методы анализа угроз и уязвимостей, писали формулы, строили модели, но так ни до чего реально эффективного и не додумались. Любые математические выкладки, сопровождающие точные количественные методы измерений, оставались на бумаге, и если для чего то и годились, то только не для использования в практической работе.
Хорошая новость заключается в том, что для принятия решений по рискам, а больше излагаемая здесь методология ни для чего не нужна, вполне достаточно простого качественного подхода к оценке угроз и уязвимостей. Такой подход демонстрирует свою высокую эффективность и в полной мере соответствует потребностям современных организаций. На практике всего-навсего требуется правильно и своевременно идентифицировать возможные проблемы, расставив должны образом приоритеты по их предупреждению.
Для повышения объективности оценки следует применять подтвердившие свою эффективность методы экспертной оценки, такие как, например, метод Дельфи. Надо устраивать коллективные обсуждения угроз, уязвимостей и механизмов контроля, на которые следует приглашать представителей различных бизнес-подразделений, владельцев активов и бизнес-процессов, экспертов по безопасности и внешних консультантов. Это повышает не только объективность оценок, но и, что не менее важно, осведомленность всех участников таких обсуждений.
Оценки ожидаемой частоты реализации угрозы от уровня к уровню по качественной шкале различаются в разы, поэтому маловероятно, чтобы компетентная экспертная группа так сильно ошибалась в своих оценках.
В Приложениях № 7 и № 8 приведены примеры опросных листов, используемых для оценки угроз и уязвимостей в методе CRAMM.
Идентификация технических уязвимостей(см. рисунок) производится для внешнего и внутреннего периметра корпоративной сети. Внешний периметр – это совокупность всех точек входа в сеть. К внутреннему периметру (внутренней ИТ инфраструктуре) мы относим все хосты и приложения, доступные изнутри.
Традиционно используются два основных метода тестирования:
тестирование по методу «черного ящика»;
тестирование по методу «белого ящика».
Тестирование по методу «черного ящика» предполагает отсутствие у тестирующей стороны каких-либо знаний о конфигурации и внутренней структуре объекта испытаний. При этом против объекта испытаний реализуются все известные типы атак и проверяется устойчивость системы защиты в отношении этих атак. Используемые методы тестирования эмитируют действия потенциальных злоумышленников, пытающихся взломать систему защиты. Основным средством тестирования в данном случае являются сетевые сканеры, располагающие базами данных известных уязвимостей.
Метод «белого ящика» предполагает составление программы тестирования на основании знаний о структуре и конфигурации объекта испытаний. В ходе тестирования проверяется наличие и работоспособность механизмов безопасности, соответствие состава и конфигурации системы защиты требованиям безопасности. Выводы о наличии уязвимостей делаются на основании анализа конфигурации используемых средств защиты и системного ПО, а затем проверяются на практике. Основным инструментом тестирования в данном случае являются средства анализа защищенности системного уровня, хостовые сканеры и списки проверки.
Для интентификации технических уязвимостей проводятся следующие организационно-технические мероприятия по анализу защищенности:
ручные проверки системной конфигурации;
сетевое и хостовое сканирование;
тестовые испытания;
тесты на проникновение;
социальные тесты;
анализ программных кодов.
Современные методы анализа защищенности информационных систем настолько разнообразны, что им можно было бы посвятить отдельную книгу. Далее мы ограничимся кратким рассмотрением лишь некоторых из этих методов.
Ручная проверка системной конфигурации
Ручная проверка системной конфигурации производится с использованием списков проверки, рекомендаций разработчиков и независимых экспертов, политик и технических стандартов, а также собственного опыты проверяющего.
Оформление результатов ручных проверок производится точно так же, как и для организационных уязвимостей.
На следующем рисунке приведен фрагмент отчета с описанием уязвимостей антивирусной системы.
Таблица. Результаты проверки антивирусной подсистемы (фрагмент)
Задачи:
1. Проверка конфигурации антивирусной подсистемы2. Проверка лицензий на антивирусное ПО3. Проверка установки последних обновлений антивирусных БД и ПО4. Проверка настройки параметров карантина
Свидетельства:
1. Все рабочие станции, серверы и почтовая система защищены антивирусным ПО в соответствии с Политикой антивирусной защиты2. Лицензии имеются3. Обновление антивирусных БД устанавливаются каждый час
Уязвимости/недостатки:
1. Не настроены параметры карантина, что приводит к потере подозрительных файлов
Рекомендации:
1. Произвести настройку параметров антивирусного карантина, определив место и время хранения подозрительных файлов
При анализе конфигурации средств защиты внешнего периметра ЛВС и управления межсетевыми взаимодействиями особое внимание обращается на следующие аспекты, определяемые их конфигурацией:
настройку правил разграничения доступа (правил фильтрации сетевых пакетов) на МЭ и маршрутизаторах;
используемые схемы и настройка параметров аутентификации;
настройку параметров системы регистрации событий;
использование механизмов, обеспечивающих скрытие топологии защищаемой сети, включающих в себя трансляцию сетевых адресов (NAT), «маскарадинг» и использование системы split DNS;
настройку механизмов оповещения об атаках и реагирования;
наличие и работоспособность средств контроля целостности;
версии используемого ПО и наличие установленных пакетов программных коррекций.
Сетевое сканирование
Большая часть технических уязвимостей выявляется в автоматическом режиме при помощи сетевых и хостовых сканеров, которые способны одновременно выполнять тысячи проверок сразу на многих хостах. Обычно сканеры создают очень подробные отчеты об уязвимостях, к которым следует относиться весьма критически. Мы называем эти отчеты гипотезами об уязвимостях, требующими дальнейших ручных проверок.
На рисунке представлены результаты сканирования в сканере Nessus.
Принцип работы сканера заключается в моделировании действий злоумышленника, производящего анализ сети при помощи стандартных сетевых утилит, таких как host, showmount, traceout, rusers, finger, ping и т.п. При этом используются известные уязвимости сетевых сервисов, сетевых протоколов и ОС для осуществления удаленных атак на системные ресурсы и осуществляется документирование удачных попыток.
В настоящее время существует большое количество как коммерческих, так и свободно распространяемых сканеров, как универсальных, так и специализированных – предназначенных для выявления определенных классов уязвимостей, ориентированных на определенные программно-аппаратные платформы и приложения. Их можно найти в сети Интернет. Число уязвимостей в базах данных современных сканеров исчисляется тысячами.
Результаты сканирования систем должны быть отсортированы по степени критичности обнаруженных уязвимостей. Описание уязвимости должно включать в себя: ее название или идентификационный номер CVE (Common Vulnerabilities and Exposures – общепризнанный репозиторий уязвимостей), адреса и имена хостов, подверженных данной уязвимости, описание угрозы для конкретной организации, связанной с данной уязвимостью, а также рекомендации по устранению уязвимости либо уменьшению ее влияния на безопасность организации (обычно с ссылкой на соответствующие источники информации и программные коррекции).
Таблица. Результаты сетевого сканирования (фрагмент)
Атакующий может использовать переполнение буфера для выполнения кода с привилегиями сервера ToolTalkRPC, который обычно выполняется от лица суперпользователя.
ddi-tcp-1 (8888/tcp): Возможность подключения к портам, защищенным файерволлом на удаленном хосте с исходящего порта 20.BID: 5279
10.х.х.х
Атакующий может подключиться к сервисам на удаленном хосте, минуя файерволл
Заблокировать на файерволле все пакеты с исходящим портом 20.
Уязвимость сервиса bootparamdRPC, используемого бездисковыми клиентами для получения загрузочной информации.CVE: CVE-1999-0647
10.х.х.х
Атакующий может использовать функцию BOOTPARAMPROC_WHOAMI для получения имени домена NISс сервера, затем используя его для получения доступа к файлу паролей NIS
Настроить фильтрацию входящего трафика для предотвращения доступа к сервисам portmapperи bootparam
Тестовые испытания
Тестовые испытания могут включать в себя любые виды проверок: ручные, автоматические, оценку соответствия и т.п. Кроме этого, они позволяют убедиться в работоспособности механизмов контроля и проверить правильность обработки информации на тестовых данных. Примером могут служить аттестационные испытания объектов информатизации по требованиям безопасности информации, сертификационные испытания средств вычислительной техники (СВТ), а также приемо-сдаточные испытания систем, вводимых в эксплуатацию.
Для проведения тестовых испытаний необходимо определить требования безопасности, предъявляемые к испытываемым системам, разработать программу и методику испытаний в соответствии с этими требованиями, подготовить наборы входных и выходных данных.
Фрагмент программы аттестационных испытаний информационной системы обработки персональны данных (ИСПДн) по требованиям безопасности информации может выглядеть, например, следующим образом:
Наименование и порядок испытаний
Пункт методи
Проверка реализации требований по защите каналов связи, используемых для обмена персональными данными
4.2.1
Проверка реализации требований по физической защите помещений, в которых ведется работа с персональными данными
4.2.2
Проверка реализации требований по защите персональных данных от НСД
4.2.3
Проверка реализации требований по обеспечению доступности и незамедлительного восстановления персональных данных
4.2.4
Проверка реализации требований по контролю уровня защищенности персональных данных
4.2.5
Проверка правильности и полноты реализации организационно-технических мероприятий по обеспечению безопасности персональных данных
4.2.6
Проверка наличия утвержденного списка лиц, допущенных к работе с персональными данными
4.2.7
Проверка реализации требований по регистрации запросов на получение персональных данных
4.2.8
Проверка регламента (процедуры), определяющего порядок предоставления персональных данных и порядок действий в случае обнаружения нарушений порядка предоставления персональных данных
4.2.9
Методика испытаний для каждого пункта Программы определяет проверяемые требования безопасности, способы их реализации в испытываемой системе и методы проверки их реализации.
Фрагмент методики аттестационных испытаний системы Банк-Клиент показан на рисунке.
Другим примером тестовых испытаний может служить тестирование планов обеспечения непрерывности бизнеса, фрагмент программы которого показан на рисунке.
По результатам испытаний оформляются протоколы и заключения, в которых отражаются выявленные недостатки.
Тестовые испытания информационных систем различного назначения позволяют идентифицировать свойственные для этих систем как организационные, так и технические уязвимости.
К организационным уязвимостям относятся любые слабости защиты, не являющиеся слабостями технических или программных средств.
Для идентификации организационных уязвимостей проводится проверка источников этих уязвимостей, к которым относятся:
процессы управления безопасностью;
организационная структура, распределение ролей и ответственности;
документированные процедуры и записи;
квалификация, осведомленность и обученность персонала;
физические меры защиты и физическое окружение;
соответствие требованиям законодательства, нормативной базы, договоров, стандартов и бизнеса.
Организационные уязвимости обычно заключаются в отсутствии или неправильном применении механизмов контроля. Поэтому основным источником идентификации организационных уязвимостей служит международный стандарт ISO 27001, т.к. этот стандарт содержит наиболее полное высокоуровневое описание того, что должно быть сделано для защиты информационных активов. Если чего-то не хватает, то это может рассматриваться в качестве потенциальной уязвимости. Международный стандарт ISO 27002 содержит подробное описание областей и механизмов контроля. Выпускаемые Британским институтом стандартов руководства по аудиту и внедрению СУИБ BIP 0072 и BIP 0073 описывают, каким образом можно оценивать соответствие ISO 27001 и идентифицировать организационные уязвимости.
Еще одним источником идентификации организационных уязвимостей служит анализ законодательной и нормативной базы в области информационной безопасности.
_________________________________________
Источники идентификации потенциальных организационных уязвимостей:
ISO 27001, разделы 4-8, – определяют требования и процессы СУИБ;
ISO 27001, приложение А, – определяет 11 областей и 137 механизмов контроля;
ISO 27002 – подробно описывает 11 областей и 137 механизмов контроля;
BIP 0072 – содержит опросники для проверки соответствия требованиям ISO 27001;
BIP 0073 – предоставляет дополнительное руководство по внедрению и аудиту механизмов контроля;
применимая законодательная и нормативная база.
__________________________________________
Оценка процессов СУИБ на соответствие ISO 27001
Разделы 4–8 международного стандарта ISO 27001 определяют обязательные (читай – наиболее важные с точки зрения передового опыта и здравого смысла) элементы СУИБ, такие как политика безопасности, оценка и обработка рисков, аудиты, анализ со стороны руководства, анализ эффективности, корректирующие и превентивные меры и т.п. Отсутствие этих элементов почти всегда свидетельствует о наличии серьезных уязвимостей.
Для анализа данных организационных уязвимостей составляется таблица соответствия, в которой для каждого требования, содержащегося в стандарте ISO 27001, отмечается текущее состояние с выполнением этого требования, а также дается описание свойственных организации особенностей в интерпретации этого требования и существующих затруднений с его выполнением.
Оценочные мероприятия включают в себя интервьюирование персонала, сбор и анализ свидетельств надлежащего функционирования СУИБ, анализ полноты и правильности реализации механизмов контроля, описанных в стандарте. Результаты анализа заносятся в оценочную таблицу, фрагмент которой показан на рисунке.
Целесообразность использования механизмов контроля, перечисленных в приложении А стандарта ISO 27001 и далее подробно описанных в стандарте ISO 27002, должна определяться по результатам оценки рисков. Однако отсутствие любого из этих механизмов контроля может рассматриваться на данном этапе в качестве потенциальной уязвимости, т.к. это ослабляет защиту активов.
Для анализа этой группы уязвимостей также используется оценочная таблица, фрагмент которой показан на рисунке. Левая часть этой таблицы полностью повторяет структуру Приложения А стандарта ISO 27001, а в правой части отмечается текущий статус реализации соответствующих механизмов контроля, описываются особенности реализации этих механизмов, а также приводится обоснование исключений некоторых механизмов контроля там, где это необходимо.
Как мы увидим далее, именно эта оценочная таблица будет выполнять роль Декларации о применимости механизмов контроля – важнейшего документа СУИБ, вокруг которого в последующем будет строиться обработка рисков и аудиты.
Результатом идентификации организационных уязвимостей является отчет о несоответствиях, в котором для каждой области контроля определяется степень соответствия, перечисляются существующие механизмы безопасности, сильные и слабые стороны, а также даются рекомендации по усилению защиты.
На следующем рисунке приведен фрагмент таблицы с описанием уязвимостей для области контроля «Управление активами».
Таблица. Оценка достижения цели контроля «Управление активами»
Цель контроля:
Обеспечить и поддерживать надлежащий уровень защиты активов организации.Все активы должны быть учтены и иметь назначенного владельца. Также должна быть определена ответственность за сопровождение этих активов и обеспечение их безопасности.
Уровень соответствия:
Низкий (40%)
Свидетельства соответствия:
Политика безопасности организации определяет права доступа к основным категориям информационных и ИТ активов на уровне файловых папок, ИТ сервисов и программных модулей. Права доступа периодически проверяются и пересматриваются.Политика безопасности определяет правила допустимого использования активов, которые внедрены и соблюдаются на практике.Перечень конфиденциальной информации оформлен в виде приложения к Политике безопасности.
Несоответствия:
Отсутствует реестр информационных активов.Владельцы активов не идентифицированы явным образом.Отсутствуют правила маркирования и обращения с конфиденциальными документами, а также схема их классификации.
Рекомендации:
Сформировать и поддерживать в актуальном состоянии реестр активов.Назначить владельцев для каждого активов и определить их ответственность за активы.Определить общую схему классификации информации по критериям конфиденциальности, целостности и доступности.Разработать и внедрить правила маркировки и обращения с конфиденциальными документами.
Уязвимости представляют собой слабости защиты, ассоциированные с активами организации. Эти слабости могут использоваться одной или несколькими угрозами, являющимися причиной нежелательных инцидентов. Уязвимость сама по себе не наносит ущерба, это только условие или набор условий, позволяющих угрозе причинить ущерб активам.
Другими словами, уязвимости – это любые факторы, делающие возможной успешную реализацию угроз. Поэтому для оценки уязвимостей необходимо идентифицировать существующие механизмы безопасности и оценить их эффективность.
Идентификация уязвимостей должна определять связанные с активами слабости в следующих областях:
физическом окружении;
персонале, процедурах управления, администрирования и механизмах контроля;
деловых операциях и предоставлении сервисов;
технических средствах, программном обеспечении, телекоммуникационном оборудовании и поддерживающей инфраструктуре.
Угрозы и уязвимости должны объединиться для того, чтобы стать причиной инцидентов, которые могут причинить ущерб активам. Поэтому необходимо четко определять взаимосвязь между угрозами и уязвимостями.
Мы делим все существующие уязвимости на две большие группы: организационные и технические. Далее мы рассмотрим, каким образом может осуществляться идентификация и анализ этих уязвимостей.
Существуют различные способы классификации угроз безопасности: по объекту воздействия, по источнику угрозы, способам ее осуществления, возможным последствиям и видам ущерба. Одновременно могут использоваться несколько критериев классификации, например, угрозы, классифицированные по объекту воздействия, дополнительно, внутри каждого класса, могут классифицироваться по видам ущерба и источникам угрозы.
По виду активов, на которые они направлены (объектам воздействия), угрозы делятся на:
угрозы, направленные против информационных активов;
угрозы, направленные против программного обеспечения;
угрозы, направленные против технических средств;
угрозы кадровым ресурсам;
угрозы помещениям организации.
В конечном итоге все перечисленные классы угроз, за исключением последнего, могут оказывать прямое влияние на безопасность информационных активов.
По источнику угрозы можно разделить, например, на следующие классы:
угрозы со стороны различных классов внешних нарушителей;
угрозы со стороны различных классов внутренних нарушителей;
природные катаклизмы (землетрясение, наводнение, ураганы и т.п.);
несчастные случаи (пожар, обрушение здания и т.п.).
По типу нарушения угрозы можно разделить на следующие классы:
угрозы нарушения конфиденциальности информации;
угрозы нарушения целостности информации;
угрозы нарушения доступности информации;
угрозы отказа от совершенных действий с информацией (угрозы неотказуемости);
угрозы, связанные с невозможностью установления авторства электронных документов (угрозы аутентичности);
угрозы нарушения требований законодательства.
Далее мы более подробно рассмотрим некоторые основные классы угроз безопасности.
Угрозы, реализуемые при помощи программных средств
Угрозы информационной безопасности, реализуемые с использованием программныхсредств, – наиболее многочисленный класс угроз в отношении конфиденциальности, целостности и доступности информационных активов, связанный с получением внутренними или внешними нарушителями несанкционированного логического доступа к информации, а также блокированием или разрушением этой информации с использованием возможностей, предоставляемых общесистемным и прикладным программным обеспечением.
К этому классу угроз относится, например, следующее:
использование ошибок проектирования, кодирования, либо конфигурации для получения НСД;
использование закладок в ПО, оставленных для отладки, либо умышленно внедренных;
сбои в работе средств защиты информации;
маскарад, перехват паролей или взлом паролей пользователей;
нецелевое использование ПО;
анализ сетевого трафика с целью перехвата информации;
замена, вставка, удаление или изменение данных пользователей в информационном потоке;
ошибки пользователей и технического персонала;
внедрение вредоносного ПО;
утечка конфиденциальной информации по электронным каналам связи (электронная почта, системы мгновенных сообщений и т.п.) либо на внешние устройства и носители информации;
и т.п.
Большинство рассматриваемых в этом классе угроз реализуется путем осуществления локальных или удаленных атак на информационные активы системы внутренними и внешними нарушителями. Результатом успешного осуществления этих угроз становится получение НСД к информации электронного архива, управляющей информации, хранящимся на рабочих местах администраторов, конфигурационной информации активного сетевого оборудования, а также к данным, передаваемым по каналам связи.
Угрозы утечки информации по техническим каналам
Утечка информации по техническим каналам связи – это специфический класс угроз, требующий для своей реализации специальных навыков и оборудования для проведения технической разведки. Такие методы пускаются в ход, когда перехватываемая информации имеет очень большую ценность, что характерно для деятельности разведслужб.
К данному классу угроз относится следующее:
побочные электромагнитные излучения;
наводки сигнала на провода и линии связи, заземления, электропитания;
радиоизлучения, обусловленные воздействием на технические средства высокочастотных сигналов, создаваемых при помощи разведывательной аппаратуры;
аппаратные закладки;
акустическое излучение речевого сигнала;
виброакустические излучения речевого сигнала;
просмотр информации с экранов дисплеев при помощи оптических средств;
телевизионная и фотографическая разведка.
Угрозы в отношении программных средств
Программное обеспечение выступает в трех ипостасях. Во-первых, оно является средством обработки информации, которое может использоваться для нарушения безопасности информационных активов. Во-вторых, исходные тексты и исполняемые файлы программ сами по себе являются информационными активами, подверженными тем же угрозам безопасности, что и любые другие активы. В-третьих, программное обеспечение выступает в качестве объекта интеллектуальной собственности, нуждающегося в юридической защите.
В отношении программных средств могут реализовываться следующие виды угроз:
порча ПО и резервных копий;
внесение несанкционированных изменений в исходные тесты ПО;
использование нелицензионного ПО;
нарушение лицензионных соглашений;
нарушение конфиденциальности программных кодов.
Угрозы техническим средствам
К данному классу относятся угрозы доступности, целостности и, в некоторых случаях, конфиденциальности информации, хранимой, обрабатываемой и передаваемой по каналам связи, связанные с повреждениями и отказами технических средств системы и повреждением линий связи.
В этом классе целесообразно рассмотреть следующие основные виды угроз:
умышленное или неумышленное физическое повреждение технических средств внутренними нарушителями;
физическое повреждение сетевого и каналообразующего оборудования внутренними нарушителями;
физическое повреждение линий связи внешними или внутренними нарушителями;
перебои в системе электропитания;
отказы технических средств;
установка непроверенных технических средств или замена вышедших из строя аппаратных компонентов на неидентичные компоненты;
хищение носителей конфиденциальной информации внутренними нарушителями вследствие отсутствия контроля за их использованием и хранением.
Источниками угроз в отношении технических средств могут служить:
внутренние нарушители, имеющие доступ к системному оборудованию и линиям связи;
внешние нарушители, имеющие доступ к линиям связи;
пожар;
наводнение;
другие стихийные бедствия.
Подробный перечень угроз безопасности, обычно рассматриваемых при оценке информационных рисков, приведен в Приложении № 5.
Опишите профиль и жизненный цикл для одной из следующих угроз:
Заражение компьютерным вирусом
Атака на отказ в обслуживании
Несанкционированный доступ к системе и хищение конфиденциальной информации
Выход из строя файлового сервера
Пожар в офисе
Постарайтесь дать как широкое определение угрозе, включающее в себя большое количество различных сценариев инцидентов, так и более узкое определение, включающее в себя лишь один конкретный сценарий реализации угрозы.
Например, можно описать группу угроз, включающую в себя все виды пожаров, а можно определить более узкую группу инцидентов, связанных с неосторожным использованием нагревательных приборов в офисе.
Формально угрозу можно описать, используя понятия профиля и жизненного циклаугрозы.
Профиль угрозы определяется следующими статичными атрибутами:
Название угрозы (в соответствии с принятой классификацией).
Общее описание угрозы.
Источник угрозы, описываемый моделью нарушителя.
Вид угрозы – указывает на принадлежность к тому или иному известному виду угроз согласно их классификации.
Способ реализации – указывает на принадлежность к тому или иному известному способу реализации данного вида угрозы согласно их классификации.
Объект защиты (виды активов, на которые направлена угроза).
Последствия (результат) осуществления угрозы.
Уязвимости (предпосылки возникновения угрозы, такие как наличие определенных изъянов защиты, нарушения технологического процесса проектирования и разработки ПО и т. п.).
Поскольку реализация любой угрозы представляет собой определенную последовательность действий и/или событий, то при описании угрозы, помимо профиля, описывающего статические характеристики угрозы, для описания ее динамических характеристик используется понятие жизненного цикла угрозы.
Этапы реализации большинства угроз безопасности (жизненный цикл угроз), включают в себя следующие процессы:
зарождение;
развитие;
проникновение в АС;
проникновение в критичную информацию;
инициализация;
результат действия;
регенерация.
В качестве примера рассмотрим профиль угроз безопасности, связанных с получением внутренними злоумышленниками несанкционированного доступа (НСД) к информационным активам организации.
Профиль угрозы:
название угрозы – НСД к информации;
общее описание угрозы – пользователь может получить доступ к ресурсам АС или выполнить операции, на которые ему не было предоставлено соответствующих прав;
источник угрозы – можно выделить следующие категории потенциальных нарушителей:
операторы, обладающие самым низким уровнем возможностей, предоставляемых им штатными средствами АС, – запуск задач (программ) из фиксированного набора, реализующих заранее предусмотренные функции по обработке информации;
прикладные программисты, которым предоставляется возможность создания и запуска собственных программ с новыми функциями по обработке информации;
администраторы АС и системные программисты, которым предоставляется возможность управления функционированием АС, т. е. воздействия на базовое программное обеспечение системы, а также состав и конфигурацию ее оборудования;
разработчики АС и лица, обладающие всем объемом возможностей по проектированию, реализации и ремонту технических средств АС, вплоть до включения в ее состав собственных технических средств по обработке информации;
вид угрозы – использование штатных средств для осуществления НСД к информации АС;
способ реализации – подбор или воровство пароля, использование слабостей защиты;
объект защиты – база данных;
последствия – утечка конфиденциальной информации из базы данных;
уязвимости – ошибка в настройке правил разграничения доступа к базе данных, нарушение сотрудниками правил парольной политики, уязвимости программного обеспечения базы данных или операционной системы.
Жизненный цикл угрозы:
зарождение – возникновение предпосылок для НСД;
развитие – выявление возможностей и способов НСД к информационным ресурсам АС;
проникновение в АС – НСД к ресурсам АС при помощи штатных средств;
проникновение в критичную информацию – путем обхода средств разграничения доступа;
Описанная группа угроз включает в себя множество угроз, предполагающих различные сценарии развития инцидентов, различные виды нарушителей и используемых ими уязвимостей.
Следует ли при разработке модели угроз отдельно описывать подгруппы угроз и отдельные угрозы входящие в группу, зависит от конкретной ситуации с рисками и потребностей организации. Основным критерием здесь служит достаточность информации, предоставляемой по результатам процесса оценки рисков, для принятия руководством организации обоснованных решений по обработке рисков. Например, при рассмотрении чрезвычайных ситуаций, приводящих к потере оборудования и помещений, угрозу пожара не следует объединять в одну группу с угрозами наводнения, землетрясения или урагана, т.к., несмотря на общие последствия этих угроз и их случайный характер, они существенно отличаются по вероятности, используемым уязвимостям и механизмам контроля, необходимым для их уменьшения.
Разработка профилей угроз является полезным упражнением для эксперта по оценке рисков. Эта задача требует определенного навыка. Далее мы рассмотрим различные виды и классификации угроз безопасности более подробно. Однако, прежде чем переходить к следущим разделам, рекомендуем вам самостоятельно выполнить Задание №1.
Активы являются объектом для многих видов угроз. Угроза может стать причиной нежелательного инцидента, в результате которого организации будет причинен ущерб. Этот ущерб может возникнуть в результате атаки на информацию, принадлежащую организации и приводящей к ее несанкционированному раскрытию, модификации, повреждению, уничтожению, недоступности или потери. Угрозы могут исходить от случайных или преднамеренных источников или событий. При реализации угрозы используется одна или более уязвимостей систем, приложений или сервисов. Угрозы могут исходить как изнутри организации, так и извне. Примеры угроз приведены в Приложении № 5.
Угрозы информационной безопасности на редкость разнообразны. Сориентироваться в этом разнообразии помогают перечни угроз, приведенные в приложениях к стандартам BS 7799-3 и ISO 27005. Одно из наиболее детальных описаний тысяч угроз информационной безопасности можно встретить в открытом немецком стандарте BSI IT Baseline Protection Manual (Базовое руководство по защите ИТ).
Для каждого информационного актива или группы активов определяется список угроз в отношении конфиденциальности, целостности и доступности. За основу берется модель угроз, являющаяся частью Концепции обеспечения информационной безопасности организации.
Для каждой идентифицированной угрозы определяется список уязвимостей, благодаря которым становится возможным реализация угрозы. При этом учитываются результаты аудитов безопасности и контроля защищенности информационных систем организации, влияние человеческого фактора, а также факты отсутствия или слабости применяемых механизмов контроля (организационных и технических). Примерный перечень типовых уязвимостей приведен в Приложении № 6.
На некоторой стадии, либо перед началом мероприятий по оценке рисков, либо перед началом идентификации угроз и уязвимостей, должны быть идентифицированы уже реализованные механизмы безопасности. Это необходимо для полной идентификации и реалистичной оценки угроз и уязвимостей, а также важно при рассмотрении вариантов обработки рисков и мероприятий по управлению рисками.
– Внимание, Земля! Говорит станция «Мир»! У нас отказал бортовой компьютер. Что делать? – Станция «Мир»! Станция «Мир»! Это диспетчер! Слышите меня? Играйте пока на резервном! Играйте на резервном!
Анекдот
В этом разделе устанавливается связь оценки рисков нарушения доступности приложений и информационных активов с процессом планирования непрерывности бизнеса.
Одной из основных задач информационной безопасности является обеспечение непрерывности бизнеса в той части, которая касается доступности для бизнеса его информационных активов. Поэтому процессы управления непрерывностью бизнеса и процессы управления информационной безопасностью и информационными рисками тесно взаимосвязаны и частично пересекаются. Вопросы управления инцидентами и рисками информационной безопасности, которые приводят к прерыванию критичных для организации бизнес-процессов, относятся к управлению непрерывностью бизнеса. Этот класс инцидентов обычно называют аварийными ситуациями. Многие подобные ситуации вынуждают организацию переходить на резервные площадки и в резервные центры обработки информации и там восстанавливать свои информационные системы.
Согласно определению британского стандарта BS 25999-1, управление непрерывностью бизнеса (УНБ) – это процесс, связанный с бизнесом и развивающийся в зависимости от него, в ходе которого в соответствии с поставленными целями формируется система, направленная на следующее:
активное совершенствование способности организации к восстановлению при нарушении возможностей достижения ее основных целей;
обеспечение отработанного метода восстановления способности организации производить основные продукты и услуги на заданном уровне в течение согласованного срока после нарушения нормального хода деятельности;
обеспечение управления во время нарушения нормального хода бизнеса и защиты репутации и бренда организации.
УНБ дополняет систему управления рисками, направленную на основные продукты и услуги организации. Нормальный ход производства продуктов и предоставления услуг может быть нарушен в результате самых разнообразных инцидентов, многие из которых сложно предсказать и проанализировать.
Благодаря сосредоточению внимания на последствиях нарушения нормального хода деятельности, УНБ позволяет определить те продукты и услуги, от которых зависит выживание организации, а также предусмотреть меры, необходимые для непрерывного выполнения ее обязательств. В ходе УНБ организация получает представление о том, что нужно сделать до наступления инцидента, чтобы защитить людей, помещения, технологию, информацию, цепочку поставок, заинтересованные стороны и репутацию.
Имея подобное понимание, организация может реалистично оценить ответные меры, которые необходимо принять при нарушении нормального хода деятельности, чтобы справиться с любыми последствиями без недопустимого нарушения сроков производства продуктов или предоставления услуг.
Конкурентным преимуществом организации, принимающей надлежащие меры в области УНБ, является ее способность воспользоваться высокорискованными и одновременно наиболее перспективными и высокодоходными возможностями ведения бизнеса, которые не доступны другим организациям из-за высокого риска.
На этапе планирования УНБ организации следует определить и документально зафиксировать воздействие, которое способно оказать нарушение нормального хода различных видов деятельности, обеспечивающих производство основных продуктов и услуг. Данный процесс часто называют анализом воздействия на бизнес (business impact analysis). Анализ воздействия на бизнес – это процесс анализа функций, выполняемых бизнесом, и воздействия, которое может на них оказать нарушение нормального хода бизнеса.
Для каждого вида деятельности, обеспечивающего производство основных продуктов и услуг, в рамках программы УНБ организация должна:
Оценить во времени воздействие, которое может оказать нарушение нормального хода деятельности.
Установить максимально допустимую продолжительность нарушения нормального хода деятельности для каждого вида деятельности, определив:
максимальный срок с начала нарушения нормального хода деятельности, в течение которого такую деятельность необходимо возобновить;
минимальный уровень, на котором необходимо осуществлять такую деятельность после ее возобновления;
продолжительность срока, в течение которого необходимо возобновить деятельность на нормальном уровне.
При нарушении нормального хода деятельности воздействие, как правило, возрастает со временем и по-разному влияет на различные виды деятельности. Кроме того, воздействие может быть различным в зависимости от дня, месяца или этапа жизненного цикла бизнеса.
Определить любые взаимозависимые виды деятельности, активы, элементы поддерживающей инфраструктуры или ресурсы, которые также необходимо непрерывно поддерживать на определенном уровне или восстановить через какое-то время.
При оценке воздействия организации следует учитывать его составляющие, относящиеся к целям и задачам бизнеса и заинтересованным сторонам. Сюда могут относиться:
воздействие на персонал или общественное благополучие;
последствия причинения ущерба помещениям, технологии или информации либо утраты таковых;
последствия нарушения законодательных или нормативных требований;
ухудшение репутации;
ухудшение финансовой жизнеспособности;
снижение качества продуктов или услуг;
причинение ущерба окружающей среде.
Организации следует документально зафиксировать свой подход к оценке воздействия нарушения нормального хода деятельности, а также результаты своего анализа и выводы.
Приоритеты аварийного восстановления – результат анализа влияния на бизнес чрезвычайных ситуаций, производимого в ходе оценки рисков.
Ущерб, связанный с нарушением доступности активов, зависит от времени их восстановления. Для того чтобы этот ущерб минимизировать, важно правильно спланировать восстановление данных и систем. Такое планирование осуществляется в рамках процесса управления непрерывностью бизнеса. Основой такого планирования является анализ влияния чрезвычайных ситуаций на бизнес, который производится в ходе оценки рисков недоступности активов.
В течение основного периода после аварийного восстановления придется смириться с определенным сокращением работоспособности. Для целей планирования необходимо определить два ключевых положения:
для каких приложений жизненно необходимо функционирование после аварии;
какие из наиболее важных приложений потребуют неотложного внимания сразу после начала действий по ликвидации последствий аварии.
Таблица приоритетов аварийного восстановления обеспечивает связь между процессом оценки рисков информационной безопасности и процессом планирования непрерывности бизнеса. Параметр «Время восстановления» приложения определяется на основе оценки рисков нарушения доступности приложений и связанных с ними информационных активов. Остальные параметры, такие как «Потребность в особых ресурсах» или «Устойчивость к потерям», характеризуют возможности и сложность восстановления конкретного приложения. Приоритет аварийного восстановления определяется в результате комбинирования требований по доступности приложений и возможностей их восстановления.
Для оценки критичности прикладных систем используются семь показателей, позволяющих установить степень уязвимости приложения к падению производительности ИТ инфраструктуры после аварии, а также ограничения, которые могут возникнуть при восстановлении приложения:
Допустимое время, которое может пройти перед тем, как приложение заработает после аварии.
Особые ресурсы, которые необходимы в случае, если приложение будет восстанавливаться.
Способность приложения переносить смену компьютера в процессе восстановления.
Опыт сотрудников в тестировании процесса восстановления.
Предельные значения потерь, на которые можно пойти, если восстановление приложения задерживается или невозможно.
Структурные или функциональные ошибки, которые могут присутствовать в приложении.
Требования к структуре или функционированию.
Все эти факторы вместе определяют относительную важность после аварийного восстановления данного приложения. Оценки отдельных факторов располагаются в следующем порядке:
Время восстановления:
5 – требуется достичь среднего уровня производительности за время от 4 до 6 часов после аварии;
4 – требуется достичь среднего уровня производительности за время от 7 до 12 часов после аварии;
3 – требуется достичь среднего уровня производительности за время от 13 до 24 часов после аварии;
2 – требуется достичь среднего уровня производительности за время от 25 до 48 часов после аварии;
0 – никаких ограничений по времени восстановления.
Потребность в особых ресурсах:
5 – восстановление в достаточном объеме возможно только при восстановлении специальной базы данных и/или программной/аппаратной части заказчика и/или средств связи по некоммутируемым линиям;
4 – возможно функционирование в достаточной мере при использовании связи по коммутируемым линиям, если есть все необходимые ресурсы;
3 – достаточная степень производительности может быть обеспечена при частичном восстановлении ключевых ресурсов (например, при использовании текущей/резервной версии базы данных);
2 – для восстановления не нужно никаких уникальных ресурсов;
0 – может функционировать в течение периода после аварийного восстановления даже при отсутствии отдельных блоков и подсистем.
Переносимость:
5 – приложение не может быть восстановлено нигде, кроме основного рабочего компьютера;
3 – приложение может быть успешно перемещено, но с задержкой, превосходящей фактор времени данного приложения;
0 – при перемещении приложения не предвидится никаких трудностей.
Необходимая квалификация:
5 – сотрудники не смогли успешно протестировать процесс восстановления приложения;
3 – тестирование восстановления приложения было успешным, но достигнуто это было с большой задержкой;
0 – тестирование восстановления прошло успешно. Не было встречено никаких проблем.
Устойчивость к потерям:
5 – задержка с восстановлением, скорее всего, приведет к финансовым потерям, превышающим пределы, установленные руководством;
4 – задержка с восстановлением вызовет проблемы с главными заказчиками/поставщиками, которые превысят эксплуатационные или установленные руководством пределы;
2 – приложение должно быть успешно восстановлено, но проблемы потерь, связанные с неполным или задержанным восстановлением, не выходят за установленные пределы;
0 – при задержанном или неполном восстановлении никаких проблем или потерь не предвидится.
Рабочие неисправности:
5 – успешное восстановление и «нормальная» эксплуатация требуют непосредственного участия основного программиста и оператора;
4 – приложение нуждается документировании;
3 – Приложение имеет значительную чувствительность к изменениям в объемах входных данных, их качеству и/или имеет склонность к отказам;
0 – никаких известных дефектов.
Необходимый уровень защищенности:
5 – приложение содержит важные для компании сведения;
4 – приложение содержит систему управления финансовыми активами;
0 – не нужны никакие дополнительные меры безопасности сверх организации обслуживания на время процесса восстановления.
