Об анализе информационных рисков и управлении ими написано немало. Однако опыт изучения корпоративных документов показывает, что эти рассуждения носят скорее теоретический, а не практический характер.

Анализ рисков — работа весьма затратная, и российские предприятия лишь недавно подошли к тому уровню зрелости в области ИТ и информационной безопасности, когда они готовы нести эти расходы. Но нередко, потратив немалые средства, предприятие получает под видом анализа рисков нечто бесполезное и неприменимое на практике.

Анализ информационных рисков служит основой для построения системы управления информационной безопасностью — об этом достаточно написано в текущих отраслевых стандартах ISO 17799, 27001, стандарте Банка России СТО БР ИББС-1.0-2006 и др. В статье будем придерживаться такого определения: «Риск информационной безопасности — это вероятность того, что в результате реализации угрозы будет нанесен тот или иной уровень ущерба». Формально риск — это функция от двух параметров: размера ущерба и вероятности его нанесения. Низкое качество работ по анализу рисков обусловлено вторым параметром, связанным с угрозами.

Уязвимости и угрозы подробно описаны в литературе, они регулярно фиксируются в базах данных, доступных в сети, указываются в рассылках производителей программных и аппаратных продуктов. На портале www.cert.оrg за 2006 год описано более трехсот уязвимостей.

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

Живучесть такого подхода обусловлена тем, что трудно найти предприятие с уникальным типом угроз. Большинство организаций использует одни и те же операционные системы и системные механизмы, а бизнес-приложения построены на схожих принципах. Следовательно, и угрозы для них будут весьма похожи.

Для тех, кто еще не пробовал

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

Вот какие требования предъявляются к специалисту, который производит оценку рисков, например, в стандарте BS 7799:3 (Руководство по управлению рисками информационной безопасности):

  • понимание бизнеса и риск-аппетита (готовности принять данный уровень риска в процессе получения прибыли);
  • понимание концепции риска;
  • понимание угроз и уязвимостей;
  • понимание типов контрольных механизмов (контролей) информационной безопасности;
  • навыки использования методик оценки рисков;
  • аналитические способности;
  • способность определять необходимые контактные лица;
  • коммуникабельность.

Как видно из этого списка, умение оперировать угрозами и уязвимостями не занимает первое место и не является единственным навыком.

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

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

Попытка с первого раза произвести количественный анализ рисков будет, скорее всего, неудачной. Конечно, очень заманчиво получить сразу конкретные формулировки типа «вероятность нанесения ущерба в 2 540 237 рублей при реализации данной угрозы составляет 43%». Однако для анализа рисков с такой точностью необходим высокий уровень культуры управления рисками, в особенности среди бизнес-пользователей и владельцев информационных активов, который требует предварительной работы. Он соответствует достаточно высокому уровню зрелости предприятия в вопросах информационной безопасности. Попытки перескочить сразу на высокий уровень по одному из параметров (в данном случае — анализу рисков) могут привести к тому, что работы либо затянутся, либо не будут доведены до конца, либо результат получится некорректным.

Таким образом, наши рекомендации для первого раза — качественная оценка в анализе рисков. То есть оперирование не числовыми параметрами, а понятиями «высокий», «средний», «низкий».

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

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

Невозможно успешно оценить важность для предприятия информационного ресурса и размера потенциального ущерба без привлечения тех, кто понимает суть использования данного ресурса в бизнесе предприятия. В процессе анализа необходим сбор информации в подразделениях организации.

Таким образом, этот этап работы сводится к идентификации информационного ресурса, определению владельца ресурса, оценке стоимости ресурса и оценке потенциального ущерба ресурсу.

Что же надо защищать?

Идентификация информационных ресурсов, особенно наборов данных, которые порой имеют ключевое значение для бизнеса, может быть затруднена. Если подобные работы на предприятии не проводились, мы рекомендуем использовать в качестве источников информации организационную структуру самого предприятия и данные стандарта NIST SP 800-60, том II.

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

Если же информационный ресурс распределен между несколькими подразделениями, целесообразно выделить одно из них, которое несет ответственность за функционирование данного ресурса и, таким образом, идентифицировать владельца ресурса именно в этом подразделении.

Стандарт NIST SP 800-60 (том II) описывает классификацию типов данных для федеральных учреждений США. Понятно, что однозначно применять подобную классификацию для коммерческих учреждений России нельзя. Однако структура классификации, используемая в стандарте, полезна для выявления типов данных практически любого предприятия. В нем описано около 60 типов данных и проведена их оценка по категориям безопасности. Этот стандарт пригодится и на более позднем этапе анализа.

Определив ключевые фигуры подразделения (руководителя и/или наиболее авторитетных уполномоченных сотрудников), в ходе бесед с ними необходимо выяснить, с какими данными приходится работать подразделению. При этом можно использовать одну из двух моделей работы с данными:

— модель жизненного цикла (выяснить, какие данные в подразделении создаются, хранятся, обрабатываются, пересылаются или уничтожаются),

— модель бизнес-процесса (выяснить какая информация поступает на вход бизнес-процесса подразделения, что происходит с информацией в ходе процесса, какая информация является результатом бизнес-процесса).

Как задавать вопросы?

Проводя интервью по идентификации информационного ресурса и его владельца, целесообразно сразу же производить необходимые оценки. За моделью оценки данных обратимся к стандарту FIPS PUB 199 «Стандарт для категорирования федеральной информации и информационных систем с точки зрения безопасности». Суть его сводится к построению оценки по трем категориям безопасности: конфиденциальности, целостности и доступности.

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

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

  • «Что будет, если конкурент сможет ознакомиться с этими данными?»;
  • «Что будет, если злоумышленник сможет изменить эти данные в свою пользу?»;
  • «Что будет, если эти данные будут недоступны в течение определенного времени? Какова допустимая продолжительность этого периода? »

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

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

Завершая оценку

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

Формируя финальную оценку в классификаторе, следует использовать следующие источники:

  • Оценку самого владельца ресурса. Полученная правильным способом, она наиболее достоверна.
  • Собственный экспертный опыт. Если накопленный опыт показывает, что в ходе данного анализа оценка существенно отличается от тех, которые были получены в аналогичных ситуациях, целесообразно ее уточнить.
  • Упомянутый стандарт NIST SP 800-60. Сравнивая полученную оценку с теми, что указаны для похожих типов данных в этом стандарте, следует отметить случаи существенного расхождения. Весьма полезно ознакомиться с тем описанием, которое указано в стандарте, возможно, оно повлияет на изменение оценки, полученной в ходе нашего анализа.

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

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

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

Для управления рисками, то есть применения снижающих риск мероприятий, следует помнить еще о двух понятиях:

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

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

В качестве дополнительных источников рекомендуем обратиться к следующим документам:

  • Стандарт NIST SP 800-30, «Руководство по управлению рисками для ИТ систем»
  • Документ Microsoft Solutions for Security «Руководство по управлению рисками безопасности»

Искандер Конеев — менеджер, CISSP, «Делойт и Туш», ikoneev@deloitte.ru

Три подводных камня

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