Что относится к факторам риска информационных технологий в компании

#Информационная безопасность

Риски ИБ

Риск информационной безопасности — это вероятность возникновения негативного события, которое нанесет ущерб организации или физическому лицу. Применительно к сфере информационной безопасности (ИБ) выделяют следующие последствия:

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

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

Человеческий фактор включает в себя не только ошибки сотрудников, но и умышленные действия, которые приводят к распространению конфиденциальной информации.

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

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

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

Аудит подразумевает анализ текущей ситуации в компании и выявление уязвимостей в ИТ-инфраструктуре. Разрабатывается концепция информационной безопасности объекта. Она включает в себя нормативные документы, политику информационной безопасности, а также приоритезацию рисков. Для повышения уровня ИБ применяют организационные и технические средства.

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

Такие факторы принято называть рискообразующими.

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

Чаще всего при анализе факторов выделяются те из них, которые воздействуют на «конкретный вид риска» (в литературе они получили название нейтивных (от английского native — присущий) рискообразующих факторов. В то же время существует ряд рискообразующих факторов, одновременно воздействующих на риски нескольких видов, или так называемые интегральные факторы риска.

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

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

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

Проекты в области информационных технологий (IT) обладают специфическими характеристиками, в силу которых эффективное управление рисками становится жизненно важным для их успеха. Рыночная конкуренция, эволюция технических стандартов, равно как и другие факторы, могут заставить работающую над проектом группу модифицировать принятые планы и решения в середине проекта. Изменяющиеся требования пользователей, новый инструментарий и новые технологии, растущие угрозы для информационной безопасности, текучесть кадров – все это дополнительные факторы, способные повлечь за собой изменения в IT-проекте и заставить проектную группу принимать решения в условиях неопределенности (риска). Jim McCarthy писал: «Практически на каждой стадии даже самых успешных проектов по разработке программного обеспечения существует большое количество важнейших вещей, о которых ничего не известно” (изкниги “Динамика разработки программного обеспечения», 1995, стр. 99)

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

Заместитель генерального директора, директор департамента информационных технологий компании «Аэрофлот — российские авиалинии» Сергей Кирюшин подчеркивает важность рисков, возникающих в работе с IT-системами: «… последствия могут оказать крайне негативное влияние на бизнес…Кроме того, существует риск неуспешного внедрения новой информационной системы, что может привести к потере денег, времени, конкурентных преимуществ на рынке». Причем это справедливо как для компании-заказчика, так и для компании-поставщика IT-продуктов, поскольку ей самой приходится работать с IT-системами (среда разработки, базы-данных и т.д.).

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

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

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

Кроме того, IT-компании часто оказывают консультационные услуги своим заказчикам. Директор по маркетингу Enterprise One (группа компаний Verysell) Ирина Ярославцева подчеркивает, что для компании-консультанта в первую очередь существует риск незапланированного роста объема проекта в ходе его реализации и, как следствие, снижения рентабельности.

Не следует забывать и о такой угрозе, как потеря репутации.

Для сотрудника же главное состоит в том, чтобы прикладные программы работали без перебоев, а что для этого нужно — серверы, операционные системы, телекоммуникации и т.д.

Однако, по мнению многих специалистов в области IT и IT-рисков в частности, что подтверждается и международными исследованиями, на первом месте сейчас стоит человеческий фактор, то есть внутренние проблемы. «Это касается как злонамеренной деятельности, так и просто неумелых действий сотрудников. Техническая составляющая рисков сейчас минимальна» — считает Валентин Крохин, директор по маркетингу Leta IT-company. Такого же мнения придерживается и руководитель отдела внедрения Microsoft CRM компании Softline Solutions Александр Окороков, причем человеческий фактор, по его мнению, представлен не только злым умыслом, но и природной человеческой беспечностью.

В общем виде можно выделить следующие группы факторов риска, присущих компании в сфере IT:

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

Тем не менее, разработаны различные методики, ориентированные на различные предметные области управления рисками в IT.

Например, имеющая большую практику применения — управление рисками Microsoft Solutions Framework.

Управление рисками в рамках Microsoft Solutions Framework (MSF, методология разработки программного обеспечения от Microsoft) существует раздел управления рисками (risk management). Хотя в основном сама MSF и ее управление рисками родилось в процессе разработки программного обеспечения, принципы, заложенные в управление рисками MSF, имеют более широкое применение среди многочисленных партнеров Microsoft при внедрении IT-проектов. Методология управления рисками MSF обеспечивает учет всех элементов проектов: люди, бизнес-процессы, технологии, обеспечивает систематический, непрерывный на протяжении всего жизненного цикла проекта, воспроизводимый процесс управления рисками, обеспечивает обратную связь — непрерывное извлечение уроков из полученного опыта.

Риски — это неизбежная реальность любого бизнеса. Избежать их полностью практически никогда невозможно. Управление рисками строится на том, чтобы минимизировать вероятный ущерб и повысить эффективность деятельности компании. Алексей Александров, генеральный директор компании SEBEKON, рассказал «Бизнесологу», как управлять рисками в IT-проектах.

Алексей Александров, генеральный директор компании SEBEKON, эксперт в области разработки сложных web-проектов.

---

Знакомо? Все эти фразы — это иллюстрации рисков, которые возникают в любом it-проекте.

За всеми it-рисками, на наш взгляд, почти всегда стоят люди: 

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

Если не классифицировать и не оценить риски на подготовительном этапе, то у заказчиков есть большая вероятность либо сильно затянуть сроки внедрения, либо вовсе не получить проект, а у подрядчиков — нарушить сроки или вовсе провалить проект и чувствительно ударить по репутации.

У опытных web-разработчиков есть уже перечень рисков, которые можно предотвратить на старте проекта. Причем для каждого нового проекта этот реестр будет индивидуален.

Как мы управляем ИТ-рисками

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

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

ИТ-риски и их классификация

1. По источнику риски бывают внутренние, т.е. происходящие внутри команды разработчиков, и внешние, зависящие от компании-заказчика.
2. По степени влияния риски делятся на высокие, средние и низкие.

Рамки статьи не позволяют детально рассмотреть все существующие риски, поэтому мы выбрали из своей практики пример проекта по разработке CRM-системы.

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

1. Недостаточная поддержка проекта со стороны заказчика

Степень риска: низкая.

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

Чтобы уменьшить риск, необходимо:

2. Недостаточная поддержка со стороны пользователей ИТ-системы

Степень риска: средняя.

Чтобы уменьшить риск, необходимо:

• дать четкие указания, касающиеся поддержки проекта, подготовить и провести собрание, подготовить приказ или иной документ, в котором будут зафиксированы эти указания;
• контролировать участие сотрудников компании-заказчика в проекте;
• провести обучение сотрудников компании-заказчика;
• передать промежуточную версию системы сотрудникам для тестирования.

В среднем в проекте бывает 5-6 итераций. Если пренебречь последним пунктом, то подрядчик может допустить ошибки, которые фатальным образом скажутся на функционировании всей системы.

3. Несоответствие реализации бизнес-процессов в системе ожиданиям заказчика

Степень риска: низкая. 

Недопонимание бизнес-процессов заказчика подрядчиком может привести к несоответствию реализованной системы ожиданиям заказчика.

Для преодоления данного риска необходимо:

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

4. Расширение функциональных требований в процессе реализации проекта

Степень риска: средняя.

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

Чтобы уменьшить риск, необходимо:

• ответственно относиться к выработке требований к системе на подготовительных этапах и согласованию итоговых документов;

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

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

Для преодоления риска следует обсудить расширения и после этого принять одно из решений:

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

5. Недоступность членов рабочей группы

Степень риска: низкая.

Чтобы уменьшить риск или полностью его преодолеть, необходимо заранее планировать встречи с учётом отпусков и командировок, а также назначить заместителей.

6. Изменение состава рабочей группы

Степень риска: средняя.

Смена участников РГ в ходе проекта может привести к нарушению сроков и низкому качеству работ.

Чтобы уменьшить риск, необходимо:

• заранее планировать встречи с учетом отпусков и командировок;
• мотивировать участников проекта сохранять состав РГ в неизменном виде.

Для преодоления риска необходимо:

• привлечь дополнительных сотрудников из компании при изменении состава РГ для помощи в работе новому участнику;
• скорректировать состав работ, выходных результатов или рамок текущего этапа, если невозможно быстро решить вопросы замены участника РГ;
• скорректировать сроки выполнения работ, если невозможно изменить рамки проекта.

7. Изменение бюджета и сроков проекта

Степень риска: низкая.

Чтобы уменьшить риск, необходимо:

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

Для преодоления риска необходимо своевременно провести встречи со всеми сторонами и выработать согласованный план действий:

• сдвиг плана проекта;
• уменьшение объема работ;
• перенос работ на другой этап и т.д.

8. Несвоевременное предоставление необходимых документов со стороны заказчика

Степень риска: низкая.

В случае несвоевременного предоставления заказчиком документов, необходимых для реализации проекта, возможен сдвиг сроков реализации этапа ТЗ и проекта в целом.

Чтобы уменьшить риск, необходимо:

• заранее сформировать запрос на предоставление документов в начале разработки ТЗ;
• составить график предоставления документов;
• включить данные по статусу получения документов в отчет по проекту.

9. Несвоевременное заключение договоров заказчиком со сторонними сервисами, получение тестовых и боевых доступов для интеграции

Степень риска: средняя.

В случае несвоевременного предоставления заказчиком тестовых / боевых доступов к сторонним сервисам, необходимым для реализации проекта, возможен сдвиг сроков запуска.

Чтобы уменьшить риск, необходимо:

• сформировать запрос на предоставление доступов в процессе разработки ТЗ;
• составить график предоставления доступов;
• включить данные по статусу предоставления доступов в отчет по проекту.

Для преодоления риска необходимо скорректировать план проекта, перенести работы на более позднее время.

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

10. Неполнота отражения ожидаемых  результатов проекта

Степень риска: средняя.

Решения,  проговоренные устно на рабочих встречах, могут быть не зафиксированы документально.

Чтобы уменьшить риск необходимо:

• документировать все существенные результаты встреч и совещаний в протоколах или иных документах;
• согласовывать в письменной форме протоколы встреч со всеми участниками.

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

Список рисков можно продолжать бесконечно. И все они, как правило, взаимосвязаны друг с другом. Для наглядности мы собрали в схему описанные выше риски и стрелками показали их зависимости друг от друга. Помните, что даже риск, оставленный без внимания, тянет за собой как минимум еще один.

Новости

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

Система управления рисками

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

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

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

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

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

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

На этом уровне принимаются концепция (или политика) и план управления рисками.

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

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

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

План управления рисками — краткое схематичное описание деятельности и мероприятий в области управления рисками, определение основных отвественных и ресурсов, применяемых для управления рисками.

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

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

Cогласно стандарту FERMA 2002 система управления рисками строится несколько проще (рис. 3). В ней стратегический (выработка принципов управления рисками) и тактический (работа с системой управления рисками) уровни вынесены за рамки, но присутствуют все основные элементы процесса управления рисками.

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

Рис. 2. Схема управления рисками согласно стандарту ГОСТ Р ИСО 31000:2010 «Менеджмент риска. Принципы и руководство» 1.

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

Рис. 3. Система управления рисками по стандарту FERMA 2002.

Ограничения управления рисками

Управление рисками возможно отнюдь не в любой ситуации. Исходя из определения риска, управлять им можно только в том случае, если в компании существует:

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

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

Система управления ИТ-рисками

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

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

Для постановки системы управления ИТ-рисками целесообразно воспользоваться стандартом COBIT: инструкциями COBIT по аудиту ИТ-процесса «Оценка рисков», рекомендациями Risk Analysis Framework (COBIT) 3. Для оценки ИТ-рисков, разработки мер реагирования на риски, расчёта приемлемого остаточного риска полезно опираться на подходящую методику управления ИТ-рисками. Существует несколько методологий управления ИТ-рисками, из которых следует упомянуть OCTAVE и CRAMM.

1. Методология OCTAVE (Operationally Critical Threat, Asset and Vulnerability Evaluation) разработана в Институте программной инженерии при Университете Карнеги — Меллона. Её особенность — активное вовлечение владельцев информации в процесс определения критичных информационных активов и ассоциированных с ними рисков. Методология OCTAVE гибкая, её можно адаптировать под потребности конкретного предприятия.
2. Методология CRAMM (CCTA Risk Analysis and Management Method) разработана Central Computer and Telecommunications Agency (Великобритания). Её сильная сторона — идентификация элементов ИТ-риска: материальных и нематериальных активов, их ценности, угроз, мер безопасности, величины потенциального ущерба и вероятности реализации рискового события.

К сожалению, вопрос выбора методологии управления ИТ-рисками в каждом конкретном случае — дело сложное, его нельзя свести к кратким советам.

Ожидаемые результаты деятельности по управлению ИТ-рисками как составной части комплексной системы управления ИТ:

• снижение числа инцидентов, связанных с ИТ;
• рост доли ИТ-услуг, предоставляемых в соотвествии с чётко утверждёнными SLA;
• повышение уровня непрерывности деятельности организации;
• повышение удовлетворённости бизнеса работой ИТ-департамента.

* * *

В следующей части статьи мы перейдём к описанию опыта управления рисками в ходе ИТ-проекта внедрения комплексной системы управления.

Время на прочтение
31 мин

Количество просмотров 30K

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

Кроме этого, выстроенный процесс управления рисками ИБ позволит разработать и в случае необходимости применить чёткие планы обеспечения непрерывности деятельности и восстановления работоспособности (Business Continuity & Disaster Recovery): глубокая проработка различных рисков поможет заранее учесть, например, внезапно возникшую потребность в удаленном доступе для большого количества сотрудников, как это может произойти в случае эпидемий или коллапса транспортной системы. Итак, в этой публикации — анализ международных документов по управлению рисками информационной безопасности. Приятного чтения!

Общая концепция управления рисками ИБ

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

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

Цели анализа рисков ИБ таковы:

1. Идентифицировать активы и оценить их ценность.
2. Идентифицировать угрозы активам и уязвимости в системе защиты.
3. Просчитать вероятность реализации угроз и их влияние на бизнес (англ. business impact).
4. Соблюсти баланс между стоимостью возможных негативных последствий и стоимостью мер защиты, дать рекомендации руководству компании по обработке выявленных рисков.

Этапы с 1-го по 3-й являются оценкой риска (англ. risk assessment) и представляют собой сбор имеющейся информации. Этап 4 представляет из себя уже непосредственно анализ рисков (англ. risk analysis), т.е. изучение собранных данных и выдачу результатов/указаний для дальнейших действий. При этом важно понимать собственный уровень уверенности в корректности проведенной оценки. На этапе 4 также предлагаются методы обработки для каждого из актуальных рисков: передача (например, путем страхования), избегание (например, отказ от внедрения той или иной технологии или сервиса), принятие (сознательная готовность понести ущерб в случае реализации риска), минимизация (применение мер для снижения вероятности негативного события, приводящего к реализации риска). После завершения всех этапов анализа рисков следует выбрать приемлемый для компании уровень рисков (англ. acceptable risk level), установить минимально возможный уровень безопасности (англ. baselines of performance), затем внедрить контрмеры и в дальнейшем оценивать их с точки зрения достижимости установленного минимально возможного уровня безопасности.

Ущерб от реализации атаки может быть прямым или непрямым.

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

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

Анализ рисков может быть как количественным, так и качественным.

Рассмотрим один из способов количественного анализа рисков. Основными показателями будем считать следующие величины:

ALE — annual loss expectancy, ожидаемые годовые потери, т.е. «стоимость» всех инцидентов за год.
SLE — single loss expectancy, ожидаемые разовые потери, т.е. «стоимость» одного инцидента.
EF — exposure factor, фактор открытости перед угрозой, т.е. какой процент актива разрушит угроза при её успешной реализации.
ARO — annualized rate of occurrence, среднее количество инцидентов в год в соответствии со статистическими данными.

Значение SLE вычисляется как произведение расчётной стоимости актива и значения EF, т.е. SLE=AssetValue*EF. При этом в стоимость актива следует включать и штрафные санкции за его недостаточную защиту.

Значение ALE вычисляется как произведение SLE и ARO, т.е. ALE=SLE*ARO. Значение ALE поможет проранжировать риски — риск с высоким ALE будет самым критичным. Далее рассчитанное значение ALE можно будет использовать для определения максимальной стоимости реализуемых мер защиты, поскольку, согласно общепринятому подходу, стоимость защитных мер не должна превышать стоимость актива или величину прогнозируемого ущерба, а расчетные целесообразные затраты на атаку для злоумышленника должны быть меньше, чем ожидаемая им прибыль от реализации этой атаки. Ценность мер защиты также можно определить, вычтя из расчётного значения ALE до внедрения мер защиты значение расчётного значения ALE после внедрения мер защиты, а также вычтя ежегодные затраты на реализацию этих мер. Условно записать это выражение можно следующим образом:

(Ценность мер защиты для компании) = (ALE до внедрения мер защиты) — (ALE после внедрения мер защиты) — (Ежегодные затраты на реализацию мер защиты)

Примерами качественного анализа рисков могут быть, например, метод Дельфи, в котором проводится анонимный опрос экспертов в несколько итераций до достижения консенсуса, а также мозговой штурм и прочие примеры оценки т.н. «экспертным методом».

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

1. Фреймворк «NIST Risk Management Framework» на базе американских правительственных документов NIST (National Institute of Standards and Technology, Национального института стандартов и технологий США) включает в себя набор взаимосвязанных т.н. «специальных публикаций» (англ. Special Publication (SP), будем для простоты восприятия называть их стандартами):

1.1. Стандарт NIST SP 800-39 «Managing Information Security Risk» ( «Управление рисками информационной безопасности») предлагает трехуровневый подход к управлению рисками: организация, бизнес-процессы, информационные системы. Данный стандарт описывает методологию процесса управления рисками: определение, оценка, реагирование и мониторинг рисков.
1.2. Стандарт NIST SP 800-37 «Risk Management Framework for Information Systems and Organizations» ( «Фреймворк управления рисками для информационных систем и организаций») предлагает для обеспечения безопасности и конфиденциальности использовать подход управления жизненным циклом систем.
1.3. Стандарт NIST SP 800-30 «Guide for Conducting Risk Assessments» ( «Руководство по проведению оценки рисков») сфокусирован на ИТ, ИБ и операционных рисках. Он описывает подход к процессам подготовки и проведения оценки рисков, коммуницирования результатов оценки, а также дальнейшей поддержки процесса оценки.
1.4. Стандарт NIST SP 800-137 «Information Security Continuous Monitoring» ( «Непрерывный мониторинг информационной безопасности») описывает подход к процессу мониторинга информационных систем и ИТ-сред в целях контроля примененных мер обработки рисков ИБ и необходимости их пересмотра.

2. Стандарты Международной организации по стандартизации ISO (International Organization for Standardization):

2.1. Стандарт ISO/IEC 27005:2018 «Information technology — Security techniques — Information security risk management» («Информационная технология. Методы и средства обеспечения безопасности. Менеджмент риска информационной безопасности») входит в серию стандартов ISO 27000 и является логически взаимосвязанным с другими стандартами по ИБ из этой серии. Данный стандарт отличается фокусом на ИБ при рассмотрении процессов управления рисками.
2.2. Стандарт ISO/IEC 27102:2019 «Information security management — Guidelines for cyber-insurance» («Управление информационной безопасностью. Руководство по киберстрахованию») предлагает подходы к оценке необходимости приобретения киберстраховки как меры обработки рисков, а также к оценке и взаимодействию со страховщиком.
2.3. Серия стандартов ISO/IEC 31000:2018 описывает подход к риск-менеджменту без привязки к ИТ/ИБ. В этой серии стоит отметить стандарт ISO/IEC 31010:2019 «Risk management — Risk assessment techniques» — на данный стандарт в его отечественном варианте ГОСТ Р ИСО/МЭК 31010-2011 «Менеджмент риска. Методы оценки риска» ссылается 607-П ЦБ РФ «О требованиях к порядку обеспечения бесперебойности функционирования платежной системы, показателям бесперебойности функционирования платежной системы и методикам анализа рисков в платежной системе, включая профили рисков».

3. Методология FRAP (Facilitated Risk Analysis Process) является относительно упрощенным способом оценки рисков, с фокусом только на самых критичных активах. Качественный анализ проводится с помощью экспертной оценки.

4. Методология OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) сфокусирована на самостоятельной работе членов бизнес-подразделений. Она используется для масштабной оценки всех информационных систем и бизнес-процессов компании.

5. Стандарт AS/NZS 4360 является австралийским и новозеландским стандартом с фокусом не только на ИТ-системах, но и на бизнес-здоровье компании, т.е. предлагает более глобальный подход к управлению рисками. Отметим, что данный стандарт в настоящий момент заменен на стандарт AS/NZS ISO 31000-2009.

6. Методология FMEA (Failure Modes and Effect Analysis) предлагает проведение оценки системы с точки зрения её слабых мест для поиска ненадежных элементов.

7. Методология CRAMM (Central Computing and Telecommunications Agency Risk Analysis and Management Method) предлагает использование автоматизированных средств для управления рисками.

8. Методология FAIR (Factor Analysis of Information Risk) — проприетарный фреймворк для проведения количественного анализа рисков, предлагающий модель построения системы управления рисками на основе экономически эффективного подхода, принятия информированных решений, сравнения мер управления рисками, финансовых показателей и точных риск-моделей.

9. Концепция COSO ERM (Enterprise Risk Management) описывает пути интеграции риск-менеджмента со стратегией и финансовой эффективностью деятельности компании и акцентирует внимание на важность их взаимосвязи. В документе описаны такие компоненты управления рисками, как стратегия и постановка целей, экономическая эффективность деятельности компании, анализ и пересмотр рисков, корпоративное управление и культура, а также информация, коммуникация и отчетность.

NIST Risk Management Framework

Первым набором документов будет фреймворк управления рисками (Risk Management Framework) американского национального института стандартов и технологий (NIST). Данный институт выпускает документы по ИБ в рамках серии стандартов FIPS (Federal Information Processing Standards, Федеральные стандарты обработки информации) и рекомендаций SP (Special Publications, Специальные публикации) 800 Series. Данная серия публикаций отличается логической взаимосвязанностью, детальностью, единой терминологической базой. Среди документов, касающихся управления рисками ИБ, следует отметить публикации NIST SP 800-39, 800-37, 800-30, 800-137 и 800-53/53a.

Создание данного набора документов было следствием принятия Федерального закона США об управлении информационной безопасностью (FISMA, Federal Information Security Management Act, 2002 г.) и Федерального закона США о модернизации информационной безопасности (FISMA, Federal Information Security Modernization Act, 2014 г.). Несмотря на декларируемую «привязку» стандартов и публикаций NIST к законодательству США и обязательность их исполнения для американских государственных органов, эти документы вполне можно рассматривать и как подходящие для любой компании, стремящейся улучшить управление ИБ, вне зависимости от юрисдикции и формы собственности.

NIST SP 800-39

Итак, документ NIST SP 800-39 «Managing Information Security Risk: Organization, Mission, and Information System View» («Управление риском информационной безопасности: Уровень организации, миссии, информационной системы») предлагает вендоро-независимый, структурированный, но гибкий подход к управлению рисками ИБ в контексте операционной деятельности компании, активов, физических лиц и контрагентов. При этом риск-менеджмент должен быть целостным процессом, затрагивающим всю организацию, в которой практикуется риск-ориентированное принятие решений на всех уровнях. Управление риском определяется в данном документе как всеобъемлющий процесс, включающий в себя этапы определения (frame), оценки (assess), обработки (respond) и мониторинга (monitor) рисков. Рассмотрим эти этапы подробнее.

1. На этапе определения рисков организации следует выявить:

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

2. На этапе оценки рисков организации следует выявить:

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

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

Для обеспечения процесса оценки рисков организация предварительно определяет:

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

3. На этапе реагирования на риск организация выполняет следующие работы:

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

Для обеспечения возможности реагирования на риски организация определяет типы возможной обработки рисков (принятие, избегание, минимизация, разделение или передача риска), а также инструменты, технологии и методологии для разработки планов реагирования, способы оценки планов реагирования и методы оповещения о предпринятых мерах реагирования в рамках организации и/или внешних контрагентов.

4. На этапе мониторинга рисков решаются следующие задачи:

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

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

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

На уровне организации осуществляются выработка и внедрение функций управления, согласующихся с бизнес-целями организации и с нормативными требованиями: создание функции риск-менеджмента, назначение ответственных, внедрение стратегии управления рисками и определение риск-толерантности, разработка и реализация инвестиционных стратегий в ИТ и ИБ.

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

На уровне информационных систем следует обеспечить выполнение решений, принятых на более высоких уровнях, а именно обеспечить управление рисками ИБ на всех этапах жизненного цикла систем: инициализации, разработки или приобретения, внедрения, использования и вывода из эксплуатации. В документе подчеркивается важность стойкости (resilience) ИТ-систем, которая является показателем жизнеспособности бизнес-функций компании.

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

• принятие (acceptance) риска не должно противоречить выбранной стратегии риск-толерантности организации и её возможности нести ответственность за возможные последствия принятого риска;
• избегание (avoidance) риска является зачастую самым надежным способом обработки рисков, однако может идти вразрез с желанием компании широко применять ИТ-системы и технологии, поэтому рекомендованным подходом является целесообразный и всесторонне взвешенный выбор конкретных технологий и ИТ-сервисов;
• разделение (share) и передача (transfer) рисков — это соответственно частичное или полное разделение ответственности за последствия реализованного риска с внутренним или внешним партнером в соответствии с принятой стратегией, конечная цель которой — успешность бизнес-процессов и миссии организации;
• минимизация (или смягчение) (mitigation) рисков подразумевает применение стратегии минимизации рисков ИБ на всех трех уровнях организации и непосредственное задействование систем ИБ для смягчения возможных последствий реализации рисков. Организации следует выстраивать бизнес-процессы в соответствии с принципами защиты информации, архитектурные решения должны поддерживать возможность эффективной минимизации рисков, минимизация рисков в конкретных системах должна быть реализована с применением средств и систем защиты информации, а политики, процессы и средства ИБ должны быть достаточно универсальными и гибкими для применения их в динамичной и разнородной среде организации, с учетом непрерывно меняющегося ландшафта угроз ИБ.

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

NIST SP 800-37

Теперь перейдем к документу NIST SP 800-37 «Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy» («Фреймворк управления рисками для информационных систем и организаций: жизненный цикл систем для обеспечения безопасности и конфиденциальности»).

Актуальный документ имеет ревизию №2 и был обновлен в декабре 2018 с тем, чтобы учесть современный ландшафт угроз и акцентировать внимание на важности управления рисками на уровне руководителей компаний, подчеркнуть связь между фреймворком управления рисками (Risk Management Framework, RMF) и фреймворком кибербезопасности (Cybersecurity Framework, CSF), указать на важность интеграции процессов управления конфиденциальностью (англ. privacy) и управления рисками цепочек поставок (англ. supply chain risk management, SCRM), а также логически увязать список предлагаемых мер защиты (контролей, англ. controls) с документом NIST SP 800-53. Кроме этого, выполнение положений NIST SP 800-37 можно использовать при необходимости провести взаимную оценку процедур риск-менеджмента компаний в случаях, когда этим компаниям требуется обмениваться данными или ресурсами. По аналогии с NIST SP 800-39, рассматривается управление рисками на уровнях организации, миссии, информационных систем.

В NIST SP 800-37 указано, что Risk Management Framework в целом указывает на важность разработки и внедрения возможностей по обеспечению безопасности и конфиденциальности в ИТ-системах на протяжении всего жизненного цикла (англ. system development life cycle, SDLC), непрерывной поддержки ситуационной осведомленности о состоянии защиты ИТ-систем с применением процессов непрерывного мониторинга (continuous monitoring, CM) и предоставления информации руководству для принятия взвешенных риск-ориентированных решений. В RMF выделены следующие типы рисков: программный риск, риск несоответствия законодательству, финансовый риск, юридический риск, бизнес-риск, политический риск, риск безопасности и конфиденциальности (включая риск цепочки поставок), проектный риск, репутационный риск, риск безопасности жизнедеятельности, риск стратегического планирования.

Кроме этого, Risk Management Framework:

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

В документе указаны 7 этапов применения RMF:

1. подготовка, т.е. определение целей и их приоритизация с точки зрения организации и ИТ-систем;
2. категоризация систем и информации на основе анализа возможного негативного влияния в результате потери информации (кроме негативного влияния, NIST SP 800-30 также указывает еще 3 фактора риска, учитываемых при проведении оценки риска: угрозы, уязвимости, вероятность события);
3. выбор базового набора мер защиты и их уточнение (адаптация) для снижения риска до приемлемого уровня на основе оценки риска;
4. внедрение мер защиты и описание того, как именно применяются меры защиты;
5. оценка внедренных мер защиты для определения корректности их применения, работоспособности и продуцирования ими результатов, удовлетворяющих требованиям безопасности и конфиденциальности;
6. авторизация систем или мер защиты на основе заключения о приемлемости рисков;
7. непрерывный мониторинг систем и примененных мер защиты для оценки эффективности примененных мер, документирования изменений, проведения оценки рисков и анализа негативного влияния, создания отчетности по состоянию безопасности и конфиденциальности.

Далее в публикации NIST SP 800-37 перечисляются задачи, которые следует выполнить на каждом из этапов применения RMF. Для каждой из задач указывается название задачи (контроля), перечисляются входные и выходные (результирующие) данные процесса с привязкой к категориям соответствующих контролей CSF, приводится список ответственных и вспомогательных ролей, дополнительное описание задачи, а также при необходимости даются ссылки на связанные документы NIST.

Перечислим далее задачи для каждого из этапов применения RMF.

Задачи этапа «Подготовка» на уровне организации включают в себя:

• определение ролей для управления рисками;
• создание стратегии управления рисками, с учетом риск-толерантности организации;
• проведение оценки рисков;
• выбор целевых значений мер защиты и/или профилей из документа Cybersecurity Framework;
• определение для ИТ-систем общих мер защиты, которые могут быть унаследованы с более высоких уровней (например, с уровня организации или бизнес-процессов)
• приоритизацию ИТ-систем;
• разработку и внедрение стратегии непрерывного мониторинга эффективности мер защиты.

Задачи этапа «Подготовка» на уровне ИТ-систем включают в себя:

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

Задачи этапа «Категоризация» включают в себя:

• документирование характеристик системы;
• категоризацию системы и документирование результатов категоризации по требованиям безопасности;
• пересмотр и согласование результатов и решений по категоризации по требованиям безопасности.

Задачи этапа «Выбор набора мер защиты» включают в себя:

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

Задачи этапа «Внедрение мер защиты» включают в себя:

1. внедрение мер защиты в соответствии с планами обеспечения безопасности и конфиденциальности;
2. документирование изменений в запланированные меры защиты постфактум, на основании реального результата внедрения.

Задачи этапа «Оценка внедренных мер защиты» включают в себя:

• выбор оценщика или команды по оценке, соответствующих типу проводимой оценки;
• разработку, пересмотр и согласование планов по оценке внедренных мер защиты;
• проведение оценки мер защиты в соответствии с процедурами оценки, описанными в планах оценки;
• подготовку отчетов по оценке, содержащих найденные недочеты и рекомендации по их устранению;
• выполнение корректирующих действий с мерами защиты и переоценку откорректированных мер;
• подготовку плана действий на основании найденных недочетов и рекомендации из отчетов по оценке.

Задачи этапа «Авторизация» включают в себя:

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

Задачи этапа «Непрерывный мониторинг» включают в себя:

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

NIST SP 800-30

Специальная публикация NIST SP 800-30 «Guide for Conducting Risk Assessments» («Руководство по проведению оценок риска») посвящена процедуре проведения оценки риска, которая является фундаментальным компонентом процесса управления риском в организации в соответствии с NIST SP 800-39, наряду с определением, обработкой и мониторингом рисков. Процедуры оценки рисков используются для идентификации, оценки и приоритизации рисков, порождаемых использованием информационных систем, для операционной деятельности организации, её активов и работников. Целями оценки рисков являются информирование лиц, принимающих решения, и поддержка процесса реагирования на риск путем идентификации:

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

Конечным результатом является вычисление детерминанты (значения) риска, т.е. функции от размера ущерба и вероятности возникновения ущерба. Оценку риска можно проводить на всех трех уровнях управления рисками (уровни организации, миссии, информационных систем), по аналогии с подходом, применяемым в NIST SP 800-39 и NIST SP 800-37. Подчеркивается, что оценка рисков — это непрерывный процесс, затрагивающий все уровни управления рисками в организации, а также требующий включения в жизненный цикл разработки систем (англ. system development life cycle, SDLC) и проводимый с частотой, адекватной целям и объему оценки.

Процесс оценки рисков включает в себя:

• подготовку к оценке рисков;
• проведение оценки рисков;
• коммуницирование результатов оценки и передачу информации внутри организации;
• поддержание достигнутых результатов.

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

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

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

• угрозы;
• уязвимости;
• негативное влияние;
• вероятность;
• предварительные условия.

При этом некоторые факторы риска могут быть декомпозированы до более детальных характеристик, например, угрозы можно декомпозировать до источников угроз (англ. threat sources) и событий угроз (англ. threat events).

Угроза — это любое обстоятельство или событие, имеющее потенциал негативного влияния на бизнес-процессы или активы, сотрудников, другие организации путем осуществления несанкционированного доступа, разрушения, разглашения или модификации информации и/или отказа в обслуживании. События угроз порождаются источниками угроз. Источником угроз может быть намеренное действие, направленное на эксплуатацию уязвимости, или ненамеренное действие, в результате которого уязвимость была проэксплуатирована случайно. В целом, типы источников угроз включают в себя:

• враждебные кибератаки или физические атаки;
• человеческие ошибки;
• структурные ошибки в активах, подконтрольных организации;
• природные или техногенные аварии или катастрофы.

Детальность определения событий угроз зависит от глубины построения модели рисков. В случае детального рассмотрения модели рисков можно строить сценарии угроз, которые являются набором из нескольких событий угроз, приводящих к негативным эффектам, атрибутированных к определенному источнику угроз (или нескольким источникам) и упорядоченных по времени; при этом рассматривается потенциальная вероятность последовательной эксплуатации нескольких уязвимостей, приводящей к успешной реализации атаки. События угроз в кибер- или физических атаках характеризуются набором тактик, техник и процедур (англ. tactics, techniques, and procedures, TTPs), о которых мы уже говорили ранее.

Рассматриваемый документ также говорит о таком понятии, как «смещение угрозы» (англ. threat shifting), под которым понимается изменение атакующими своих TTPs в зависимости от мер защиты, предпринятых компанией и выявленных атакующими. Смещение угрозы может быть осуществлено во временном домене (например, попытки атаковать в другое время или растянуть атаку во времени), в целевом домене (например, выбор менее защищенной цели), ресурсном домене (например, использование атакующими дополнительных ресурсов для взлома цели), домене планирования или метода атаки (например, использование другого хакерского инструментария или попытки атаковать иными методами). Кроме этого, подчеркивается, что атакующие зачастую предпочитают путь наименьшего сопротивления для достижения своих целей, т.е. выбирают самое слабое звено в цепи защиты.

Уязвимость — это слабость в информационной системе, процедурах обеспечения безопасности, внутренних способах защиты или в особенностях конкретной реализации/внедрения той или иной технологии или системы. Уязвимость характеризуется своей опасностью в контексте расчётной важности её исправления; при этом опасность может быть определена в зависимости от ожидаемого негативного эффекта от эксплуатации этой уязвимости. Большинство уязвимостей в информационных системах организации возникают или из-за не примененных (случайно или нарочно) мер ИБ, или примененных неверно. Важно также помнить и об эволюции угроз и самих защищаемых систем — и в тех, и в других со временем происходят изменения, которые следует учитывать при проведении переоценки рисков. Кроме уязвимостей технического характера в ИТ-системах, следует учитывать и ошибки в управлении организацией и в архитектуре систем.

Предварительное условие (англ. predisposing condition) в контексте оценки рисков — это условие, существующее в бизнес-процессе, архитектуре или ИТ-системе, влияющее (снижающее или увеличивающее) на вероятность причинения ущерба угрозой. Логическими синонимами будут термины «подверженность» (англ. susceptibility) или «открытость» (англ. exposure) риску, означающие, что уязвимость может быть проэксплуатирована угрозой для нанесения ущерба. Например, SQL-сервер потенциально подвержен уязвимости SQL-инъекции. Кроме технических предварительных условий, следует учитывать и организационные: так, местоположение офиса в низине увеличивает риск подтопления, а отсутствие коммуникации между сотрудниками при разработке ИТ-системы увеличивает риск её взлома в дальнейшем.

Вероятность возникновения (англ. likelihood of occurrence) угрозы — фактор риска, рассчитываемый на основе анализа вероятности того, что определенная уязвимость (или группа уязвимостей) может быть проэксплуатирована определенной угрозой, с учетом вероятности того, что угроза в итоге причинит реальный ущерб. Для намеренных угроз оценка вероятности возникновения обычно оценивается на основании намерений, возможностей и целей злоумышленника. Для ненамеренных угроз оценка вероятности возникновения, как правило, зависит от эмпирических и исторических данных. При этом вероятность возникновения оценивается на определенную временную перспективу — например, на следующий год или на отчетный период. В случае, если угроза практически стопроцентно будет инициирована или реализована в течение определенного временного периода, при оценке рисков следует учесть ожидаемую частоту её реализации. При оценке вероятности возникновения угрозы следует учитывать состояние управления и бизнес-процессов организации, предварительные условия, наличие и эффективность имеющихся мер защиты. Вероятность негативного влияния означает возможность того, что при реализации угрозы будет нанесен какой-либо ущерб, вне зависимости от его величины. При определении общей вероятности возникновения событий угроз можно использовать следующие три этапа:

1. Оценка вероятности того, что событие угрозы будет кем-либо инициировано (в случае намеренной угрозы) или случится само (в случае ненамеренной).
2. Оценка вероятности того, что возникшая угроза приведет к ущербу или нанесет вред организации, активам, сотрудникам.
3. Общая вероятность рассчитывается как комбинация первых двух полученных оценок.

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

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

1. Процесс, используемый для определения негативного влияния.
2. Предположения, используемые для определения негативного влияния.
3. Источники и методы получения информации о негативном влиянии.
4. Логическое обоснование, использованное для определения негативного влияния.

Кроме этого, при расчете негативного влияния организации должны учитывать ценность активов и информации: можно использовать принятую в компании систему категорирования информации по уровням значимости или результаты оценок негативного влияния на конфиденциальность (англ. Privacy Impact Assessments).

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

С учетом вышесказанного, модель риска можно описать как следующую логическую структуру:

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

Документ дает также рекомендации по использованию процесса агрегирования рисков (англ. risk aggregation) в целях объединения нескольких разобщенных или низкоуровневых рисков в один более общий: например, риски отдельных ИТ-систем могут быть агрегированы в общий риск для всей поддерживаемой ими бизнес-системы. При таком объединении следует учитывать то, что некоторые риски могут реализовываться одновременно или чаще, чем это прогнозировалось. Также следует учитывать взаимосвязи между разобщенными рисками и либо объединять их, либо, наоборот, разъединять.

В NIST SP 800-30 также описаны основные способы оценки рисков: количественный (англ. quantitative), качественный (англ. qualitative) и полуколичественный (англ. semi-quantitative).

Количественный анализ оперирует конкретными цифрами (стоимостью, временем простоя, затратами и т.д.) и лучше всего подходит для проведения анализа выгод и затрат (англ. Cost–benefit analysis), однако является достаточно ресурсоёмким.

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

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

Наконец, в документе также описаны три основных способа анализа факторов рисков: угрозо-центричный (англ. threat-oriented), ориентированный на активы (англ. asset/impact-oriented) или уязвимости (англ. vulnerability-oriented).

Угрозо-центричный способ сфокусирован на создании сценариев угроз и начинается с определения источников угроз и событий угроз; далее, уязвимости идентифицируются в контексте угроз, а негативное влияние связывается с намерениями злоумышленника.

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

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

Итак, как мы уже указали выше, по NIST SP 800-30 процесс оценки рисков разбивается на 4 шага:

• подготовка к оценке рисков;
• проведение оценки рисков;
• коммуницирование результатов оценки и передача информации внутри организации;
• поддержание достигнутых результатов.

Рассмотрим подробнее задачи, выполняемые на каждом из этапов.

1. Подготовка к оценке рисков.

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

1.1. Идентификация цели оценки рисков: какая информация ожидается в результате оценки, какие решения будут продиктованы результатом оценки.
1.2. Идентификация области (англ. scope) оценки рисков в контексте применимости к конкретной организации, временного промежутка, сведений об архитектуре и используемых технологиях
1.3. Идентификация специфичных предположений и ограничений, с учетом которых проводится оценка рисков. В рамках этой задачи определяются предположения и ограничения в таких элементах, как источники угроз, события угроз, уязвимости, предварительные условия, вероятность возникновения, негативное влияние, риск-толерантность и уровень неточности, а также выбранный способ анализа.
1.4. Идентификация источников предварительной информации, источников угроз и уязвимостей, а также информации о негативном влиянии, которая будет использоваться в оценке рисков. В этом процессе источники информации могут быть как внутренними (такими, как отчеты по инцидентам и аудитам, журналы безопасности и результаты мониторинга), так и внешними (например, отчеты CERTов, результаты исследований и прочая релевантная общедоступная информация).
1.5. Идентификация модели рисков, способа оценки рисков и подхода к анализу, которые будут использоваться в оценке рисков.

2. Проведение оценки рисков.

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

2.1. Идентификация и характеризация актуальных источников угроз, включая возможности, намерения и цели намеренных угроз, а также возможные эффекты от ненамеренных угроз.
2.2. Идентификация потенциальных событий угроз, релевантности этих событий, а также источников угроз, которые могут инициировать события угроз.
2.3. Идентификация уязвимостей и предварительных условий, которые влияют на вероятность того, что актуальные события угроз приведут к негативному влиянию. Ее целью является определение того, насколько рассматриваемые бизнес-процессы и информационные системы уязвимы перед идентифицированными ранее источниками угроз и насколько идентифицированные события угроз действительно могут быть инициированы этими источниками угроз.
2.4. Определение вероятности того, что актуальные события угроз приведут к негативному влиянию, с учетом характеристик источников угроз, уязвимостей и предварительных условий, а также подверженности организации этим угрозам, принимая во внимание внедренные меры защиты.
2.5. Определение негативного влияния, порожденного источниками угроз, с учетом характеристик источников угроз, уязвимостей и предварительных условий, а также подверженности организации этим угрозам, принимая во внимание внедренные меры защиты.
2.6. Определение риска от реализации актуальных событий угроз, принимая во внимание уровень негативного влияния от этих событий и вероятность наступления этих событий. В Приложении «I» к данному стандарту приведена таблица I-2 для расчета уровня риска в зависимости от уровней вероятности и негативного влияния.

3. Коммуницирование результатов оценки рисков и передача информации.

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

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

4. Поддержание достигнутых результатов.

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

4.1. Проведение непрерывного мониторинга факторов риска, которые влияют на риски в операционной деятельности организации, на её активы, сотрудников, другие организации. Данной задаче посвящен стандарт NIST SP 800-137, который мы рассмотрим далее.
4.2. Актуализация оценки рисков с использованием результатов процесса непрерывного мониторинга факторов риска.

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

NIST SP 800-137

Перейдем теперь к обзору документа NIST SP 800-137 «Information Security Continuous Monitoring for Federal information Systems and Organizations» («Непрерывный мониторинг информационной безопасности для федеральных информационных систем и организаций»).

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

Как и прочие документы серии SP, в данной публикации приведен рекомендуемый процессный подход к выстраиванию системы мониторинга ИБ, состоящий из:

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

В документе также даются следующие рекомендации по выбору инструментов обеспечения непрерывного мониторинга ИБ:

• поддержка ими большого количества источников данных;
• использование открытых и общедоступных спецификаций (например, SCAP — Security Content Automation Protocol);
• интеграция с другим ПО, таким как системы Help Desk, системы управления инвентаризацией и конфигурациями, системами реагирования на инциденты;
• поддержка процесса анализа соответствия применимым законодательным нормам;
• гибкий процесс создания отчетов, возможность «проваливаться» (англ. drill-down) в глубину рассматриваемых данных;
• поддержка систем Security Information and Event Management (SIEM) и систем визуализации данных.

UPD: Продолжение данной статьи — тут.

Актуальность исследования

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

Цель исследования

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

Задача исследования

Комплексная система, обеспечивающая защиту ИС на предприятии, должна иметь в виду таковые цели как предупреждение кражи, утечки, потери, модифицирования. Фальсификации информации, отведение противоправных поступков по искоренению, видоизменению, искривлению, имитированию, снятию с блокировки информации, а также предупреждению прочих противопоказанных вторжений в информационные ресурсы и информационные системы.
Проведение анализа рисков для каждой организации индивидуален. Индивидуальность, один из основных параметров, которые оценивает размер ущерба. Ведь индивидуальность связана с информационными ресурсами и с оценкой важности, которая уникальна у каждого предприятия.
В процесс проведения анализа рисков входит определение того что необходимо защищать в первую очередь и какими методами, с учётом рассмотрения всех возможных рисков, сортировать их в зависимости от потенциального размера ущерба. Данный процесс состоит из множества экономических решений. [1, c.46]

Ниже будут представлены требования к специалисту, который производит оценку рисков на основе британского стандарта BS 7799:3 «Руководство по управлению рисками ИБ» и ISO/IEC 27005:2008 «Информационная технология»:
— Знание бизнеса и готовность принятия данный уровень риска в процессе.
— Знание концепции риска
— Способность проведения аналитический действий
— Понимание уязвимостей и угроз
— Коммуникабельность
— Знание типов контрольных механизмов ИБ
— Способность находить необходимые контактные лица

Из предложенного этого списка, умение оперировать уязвимостями и угрозами не занимает первое место и не является основным навыком.
Проведение анализа рисков в сфере ИБ может быть количественным и качественным. Количественный анализ более точнее, что позволяет получить точные значения рисков, но проведение такого анализа занимает большее количество времени, что не оправдано. Уровень качественного анализа отличается в разных методам оценка, но всё сводится к тому, чтобы выявить самые серьёзные угрозы. [2, c.35]

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

В задачи сотрудников отдела ИБ входят обязанности оповещения руководящих лиц организации о имеющихся и потенциальных угрозах. Отчёты должны сопровождаться аналитическими выкладками, показателями, фактами. Это самый эффективный метод довести информацию до глав предприятия.
Анализ рисков состоит в том, чтобы определить имеющиеся риски и оценить из величины.
Процесс анализа предусматривает решение следующих задач:
1. Определение основных ресурсов ИС.
2. Определение Важности различных ресурсов для организации
3. Идентификация имеющихся угроз и уязвимостей безопасности, возможные осуществления угроз.
4. Расчёт рисков, связанных с реализацией угроз безопасности.

Средства ИС выделяются на следующие категории:
• Ресурсы ИС
• Программное обеспечение
• Техническое обеспечение (сетевое оборудование, сервера, дата центр, рабочие компьютеры и.т.п)
• Человеко-ресурсы

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

Основная цель управления рисками состоит в выборе обоснованного комплекса мер, позволяющих снизить уровень рисков нанесения угрозы до минимального уровня. Затраты на реализацию должна не должна превышать величину возможного ущерба. Отличию между величиной возможного ущерба и реализации контрмер должна быть противоположной вероятности причинения ущерба. [3, c.195]

Метод на основании анализа информационных рисков организации наиболее значимые для обеспечения безопасности ИС, это значит, что эффективно управлять ИБ организации позволяет только после проведения анализа риска. Для начала проведения работ по анализу риска нужно определить, что именно следует защитить на предприятии, какие области ИС подвержены высокому риску несанкционированной атаке. Анализ риска проводится, основываясь на непосредственные цели и задачи по защите определённого вида конфиденциальной информации. Самая из важнейших задач в рамках обеспечения защиты информации является обеспечение её доступности и целостности. Но не стоит забывать, что нарушение целостности может произойти и от непреднамеренных действий пользователей системы, но и по ряду других причин:
• Технический сбой, ведущий к потере или искажению информации
• Физическое воздействие (наводнение, землетрясение и других стихийных бедствий)
• Ошибки программных продуктов
При проведении анализа риска разрабатываются:
• Общий план или стратегия проведений операций против нарушителей.
• Предположительные способы проводимых атак комплексную систему защиты и обработки информации
• План осуществления противоправных действий против хакерских атак
• Технические характеристики каналов связи утечки информации.
• Тип нарушения
• Способы оценки ИБ
Для того что бы разработать надёжную комплексную систему защиты информации предприятия необходимо:
• Определить все возможные угрозы защиты, которые могут привести несанкционированной атаке
• Дать оценку последствий проявлений угроз
• Разработать необходимые методы и средства защиты учитывая нормативные требования нормативных документов.
• Экономическая целесообразность, бесконфликтность, совместимость с используемым ПО.
• Оценка эффективности выбранного метода и средств защиты
Анализ риска проводится строго следующей методике, по сценарию которая изображена на рисунке 1.

На данном изображении представлены 6 этапов проведения анализа рисков. При выполнении первого и второго этапа определяются сведения, в которые разрабатываются для организации коммерческую тайну и которые следует защищать.
На третьем этап анализа риска производится построение каналов доступа, воздействия или каналов утечки на ресурсы ИС. Каждый канал связи имеются уязвимости и требуют применения средств недопущения несанкционированного доступа к информации.
Четвертый этап — это разработка методов защиты всех уязвимых точек доступа, любая имеющаяся уязвимость может неблагоприятно сказаться на защищённость системы.
Пятый этап – на основе всех известных и имеющихся данных, методов, средств, определяются вероятности осуществлении угроз на все имеющиеся уязвимых точек атак.
Заключительным шестым этапом проводится оценка нанесённого ущерба предприятия в ходе реализации атак, который с оценками уязвимости позволяет получить сгруппированный список угроз ИС. Конечным выводом выполненной работы отображаются в виде, приятного для восприятия и выработки решений. Но при этом каждый ресурс ИС может быть подвержен негативному воздействия нежелательных атак.
На основе имеющихся фактов выясняется, что проблемы в IT-безопасности предприятия бывают не только технические, но и управленческие. Большую часть рисков можно сократить управленческими решениями, рассматривая риски в качестве операционных, а другие риски можно минимизировать программным обеспечением или техническими средствами. Мало известно, но что, как и когда необходимо реализовать все запланированные мероприятия точно в срок.
В большинстве организациях КСЗИ разрабатываются по принципу «заблокировать доступ», что сказывается на неудобстве в работе пользователей, наиболее важное это может послужить причиной медлительного развития организации, так как корпоративные знания не доступны или имеют ограничения. Большое количество запретительных мероприятий порождает способы обмена информацией в обход защищённых каналов, что сводит все усилия по защите информации к нулю, тем самым бизнес процессы компании перестраиваются в обход всех запретительных мер.
Дальнейшее проведения цикла анализа рисков даёт возможность определить необходимые эффективные мероприятия для минимизации и предотвращении рисков, а какие нет. На основе проведённого анализа эффективности корректируется понимание риска, оценка и необходимых действий. Анализ эффективности предоставит возможность увидеть минимизированные параметры уязвимости и общий ущерб всех рисков, что усилит режим безопасности IT организации. Проведение оценки эффективности КСЗИ является системным процессом получения объективной оценки данных о текущем состоянии системы. На данном этапе мониторинг проводится заранее установленных мероприятий, направленных на уменьшение совокупности убытка или частоты появления рисков. Эффективность мероприятий по защите необходимо оценивать на этапе разработки, для получения оптимальных показателей работы комплексной системы в целом. [4, c.98]
Эффективность механизма защиты оценивается на этапе разработки и в процессе эксплуатации системы защиты. При оценке механизма защиты, в зависимости от применяемых способов и показателей получения, выделяют три подхода:
-официальный
-экспериментальный
-классический
Классический подход к оценке эффективности подразумевает использование критериев эффективности, получаемых из показателей эффективности. Показатели эффективности получают путём моделирования и рассчитываются по характеристикам действующей автоматизированной системы. Данный подход используется при создании или модификации КСЗИ. В силу ряда причин, возможности классических методов оценивания эффективности весьма ограничены. Большое количество вероятных неопределённых исходных данных, сложность формализации процессов, отсутствие общепринятых методов вычисления показателей эффективности и определение критериев оптимальности образуют значительную трудность для использования стандартных методов оценки эффективности.
Особую значимость имеет подход к эффективности, который условно может считаться официальным. Стратегия безопасности ИТ проводится государством и должна основываться на нормативные акты.
Под понятием экспериментального подхода проведения анализа понимается организация процесса определения эффективности КСЗИ методом преодоления защитных элементов системы разработчиками системы, выступающие в роли злоумышленников. Подобные исследования проводится дальнейшим способом. Для проведения такого исследования в качестве злоумышленника выбирается один или более специалистов в сфере ИТ-безопасности с высшей степени квалификации. Прорабатывается стратегия проведения эксперимента, определяются этапы и материально-техническое обеспечение по обнаружению уязвимых звеньев в системе защиты. При этом имитируются действия схожие со злоумышленником: от неопытного злоумышленника, не имеющего официального доступа к автоматизированной системы, до высококвалифицированного сотрудника отдела ИТ-безопасности.
Идеальные значения оценки эффективности защиты имеет выбор базы с целью сравнения или определения степени эффективности, принимаемые за нормативный. Так же можно выбрать несколько подходов, которые могут дифференцированно использоваться к определённым случаям. Один из случаем приводится к сравнению с показателями, определяющими эффективность эталонного образца защиты системы.
Эталонный образец может быть спроектирован и разработан с применением известных методов и средств проектирования систем защиты, опираясь на современные методы и технологии других организаций.
Но также могут возникнуть определённые трудности использования указанных подходов, которые необходимо обеспечивать сопоставимо со сравниваемыми вариантами. По этой причине вместо них используется экспертная оценка комплексного уровня анализируемой и разрабатываемой системы, а также отдельных субъектов и принимаемых проектных решений, или комплексная оценка системы обеспечения защиты, основывающаяся на применении количественно-качественного подхода, позволяющий оценивать механизм защиты по большей совокупности обстоятельств. Так же экспертная оценка является составным элементом комплексной оценки эффективности механизма защиты системы, использующая все подходы к отдельным субъектам подсистемы, так и всей системы в целом. [5, c.60]
Эффективности системы защиты информации оценивается при помощи показателей эффективности, иногда именуемый термином – показатель качества.
Значения качества характеризуют степень совершенства какого-либо товара. Оборудования, машины. В отношении совокупности использование человеко-машинных систем желательнее использовать термин показатель эффективности функционирования, представляющий из себя уровень соответствия системы защиту необходимым требованьям.
Термин показателя эффективности можно охарактеризовать двумя научными методами:
• Эксперимент (испытание)
• Математическое моделирование (именуемым как вычислительными экспериментом).
По отношению к механизмам защиты информации показатели значимости (восходящие: снизу-вверх) разделяются на:
• Системные
• Надсисистемные (ценностные)
• Технические
• Информационные (датчики)
Технически, применительно к защите от утечки, это выглядит примерно таким образом: сигнал/шум – риск обнаружения – источника информации – вероятность обнаружения – источника информации – вероятность его вскрытия – ущерб утечки информации, при этом все показатели между собой связаны.
Для проведения оценки эффективности комплексной системы защиты информации или сравнения системы по их показателям эффективности, необходимо указать предпочтения. Данное правило или соотношение основывается на использовании показателей эффективности. Для получения характеристики эффективности с использование K-показателей используют ряд методов. При синтезе системы может возникнуть проблема при решении ряд задач с показателями.
Подход к проведению оценки эффективности комплексной системы защиты информации
Определение эффективности комплексных систем защиты информации относится к задачам оценки множеств характеристик, данную сложную системы невозможно в полной мере и достаточно правильно охарактеризовать с помощью единичного показателя. Поэтому использование при оценке эффективности комплексной системы защиты множество показателей будет характеризовать эффективность более подробно. К этим недостаткам относятся те оценки имеющие следующие характеристики методик:
1) Конечный результат данных будут изображены в виде шкалы оценок предполагаемых угроз и последствий. Данная методика отображает приблизительные значения показателей, основывающиеся на анализе статистики нарушений на экспертных оценках. Что бы определить значения необходим большой набрать большой объём статического материала, то есть оценка не может быть применена для оценки эффективности и выбора методов защиты информации.
2) Ri10(Si*V-4), S показатель частоты проявления угрозы выбирается из интервала от 0 до 7, значение равное 0 случай когда угроза не возникает, значение 7 когда угроза возникает раз в год, V – показатель объёма ущерба который назначается от значения S и принимает от 1 до 1 миллиона долл. В связи с тем, что оценка очень приближена с действительной, необходимо сконденсировать значительный объём статистического материала, значение не может быть использовано для оценки эффективности и выбранных мер, методов защиты информации.

Параметр Wi обозначает субъективный коэффициент необходимости j характеристики защиты информации, n – количественное значение характеристик, Gi – обозначенная экспертным путём значения каждой характеристики. Для получения приблизительной оценки эффективности необходимо использовать выражение, которое может быть использовано при отсутствии необходимых исходных данных для наиболее точной оценки.
С использованием счётного количества показателей WiGi(Wi), i1, n, значение n – это количество показателей, с помощью которого оценка эффективности будет проводится полная оценка с учётом правильности выбора характеристик и количества выбранных показателей.
Проводя оценку эффективности, в которой показатель эффективности выражается в неточных значениях защиты ИС, в виде условных обозначений, именуемых как:
• Абсолютная незащищённая или защищённая
• Защищённая
• Недостаточная или достаточная защищённость
• Защищённость
С определением таких обозначений формируется необходимая и достаточная картина защищённости от несанкционированного доступа как в качественной, так и в количественной оценке, что является положительным свойством, имеющим превосходство над всеми известными методиками.
При таком подходе, принадлежность уровня безопасности будут определятся в [0,1] значений, и показатели надёжность будут функцией принадлежности μA(xi), где xi – элемент множества, X – требование безопасности, а A – множество значений, определение выполнения требований безопасности выполняется по следующей формуле:

Пара является «функцией принадлежности / элемента», то возможно произвести оценку эффективности, по точно определённым характеристикам ИБ следующим образом:
Допустим массив X= {1,2,3,4,5} в котором заданы набор требований защиты системы, то неточное множество оценки безопасности системы, имеющие определённые характеристики будут:
А = (0,2/1) + (0,4/2) + (0,6/3) + (0,8/4) + (1/5)
Это необходимо определить следующим образом, что система, имеющая в совокупности набор выполненных требований:
• 1 – абсолютной незащищённой
• 2 – недостаточно защищённая
• 3 – защищённая с имеющимся набором выполненных требований
• 4 – достаточно защищённая система
• 5 – абсолютная защищённая система
Причем «5» набор является «абсолютной защищённой» системой к ней причисляются и другие. Другие различные состояния безопасности выделяют в виде подмножеств неопределённого подмножества А. Риск взлома оцениваемой системы, может соответствовать конкретному числу неопределённого множества, конкретно:
X= {1, 2, 3, 4, 5}; А = (0,2/1) + (0,4/2) + (0,6/3) + (0,8/4) + (1/5);
Card A = |A|=3, т.е вероятность взлома будет 3k, значение k – значение соответствия.
Каждый из выше перечисленных терминов имеют определённые значения в диапазоне от 0 до T, где T – максимальное количество требований в комплексной системе защиты информации, набор требований может быть в диапазоне от 0 до 20, набор «1» будет множеством выполненных требований.
Несомненно, что при данном подходе при оценке эффективности АС защиты от несанкционированного доступа необходимы данные о требованиях защищённости и данные о выполнении требований защиты. Выше описанная технология даёт возможность её использования при проведении оценки эффективности системы защиты с использованием нейросетевых программных обеспечений.
С использованием данных технологий совместно с программно-аппаратным комплексом системы защиты информации можно достичь:
• Мониторинг состояния АС ИБ;
• Прогнозирование возможных или осуществляемых атак, путём имитации угроз;
• Предотвращение или затруднение (создание помех, преград) реализации угроз;
Комплекс системы защиты может так же обладать возможностью перевода режима ИБ к наиболее высокому уровню эффективности.
Вывод.
Предложенная методика разработки политики информационной безопасности современного предприятия позволяет полностью проанализировать и документально оформить требования, связанные с обеспечением информационной безопасности, избежать расходы на дополнительные меры безопасности, возможные при субъективной оценке рисков, оказать помощь в планировании и реализации защиты на всех стадиях жизненного цикла информационных систем, представить обоснование для выбора мер противодействия, оценить эффективность контрмер, сравнить различные варианты контрмер.

Библиографический список

1. Баранова Е.К., Мальцева Л.Н. Анализ рисков информационной безопасности для малого и среднего бизнеса // Директор по безопасности. — 2015. — № 9. — С. 58—63.
2. Баранова Е.К. Методики анализа и оценки рисков информационной безопасности // Вестник Московского университета им. С.Ю. Витте. Серия 3: Образовательные ресурсы и технологии. – 2015. – № 1(9). – С. 73-79.
3. Баранова Е.К., Бабаш Л. В. Информационная безопасность и защита информации: Учеб, пособие. — 3-е изд., перераб. и доп. — М.: РИОР: ИНФРА-М, 2016. — 322 с. — (Высшее образование). — http://www.dx.doi.org/10.12737/1 1380
4. Сабанов А.Г. Многоуровневый анализ угроз безопасности процессов аутентификации //Вопросы защиты информации. – 2014. – № 1(104).
5. Баранова Е.К., Забродоцкий А.С. Процедура применения методологии анализа рисков OCTAVE в соответствии со стандартами серии ИСО/МЭК 27000-27005 // Вестник Московского университета им. С.Ю. Витте. Серия 3: Образовательные ресурсы и технологии. – 2015. – № 3(11). – С. 73-77.

Количество просмотров публикации: Please wait

Все статьи автора «WireMan»