В крупной компании, где количество рабочих мест, на которых используются сложные корпоративные информационные системы, исчисляется тысячами, крайне сложно обеспечить серьезный уровень информационной безопасности без автоматизации управления рисками. О применяемых на Магнитогорском металлургическом комбинате (ММК) подходах к классификации, оценке ИТ-рисков и снижению вероятности их возникновения нам рассказал начальник отдела информационной безопасности предприятия Сергей Голяк.
Управление рисками на уровне комбината
Проблемой управления рисками специалисты ММК занимаются уже давно. В компании утверждены политика в этой области и внутренний стандарт, карта рисков, а кроме того, внедряется комплексная система управления рисками (КСУР), представляющая собой методологию, направленную на обеспечение стратегической и оперативной устойчивости бизнеса предприятия. Для автоматизации КСУР на ММК используется модуль Oracle Internal Controls Manager, адаптированный под требования комбината. В соответствии с действующим стандартом под риском на ММК понимается вероятность возникновения ситуации, которая может привести к финансовому ущербу, упущенной выгоде или невозможности достичь поставленной цели. А под управлением рисками понимается осуществляемый руководством и работниками процесс выявления таких ситуаций. При этом основными считаются ценовые, рыночные, кредитные и операционные риски. ИТ-риски относятся к операционным, т. е. внутренним рискам предприятия, которые хоть и не в полном объеме, но в подавляющем большинстве своём поддаются управлению. Операционные риски для комбината связаны с обеспечением непрерывности бизнес-процессов и могут быть отнесены к наиболее контролируемым. К тому же руководство компании уделяет им особое внимание. А безопасность - наиболее важный элемент операционных рисков.
По отношению к рискам возможны следующие действия:
- принять риск, если убытки от него являются незначительными и не приведут к существенным последствиям;
- отказаться от риска, если он неприемлем для компании;
- передать риск, например, страховой компании или контрагенту;
- снизить риск, скажем, внедрив средства, уменьшающие вероятность его возникновения или тяжесть последствий.
Упрощенно можно сказать, что оптимальный способ поведения по отношению к риску определяется соотношением цена - эффект. Матрицу рисков для их градации по возможным способам контроля можно видеть на рис. 1. По горизонтальной оси откладывается вероятность возникновения рисков, а по вертикальной - возможные потери от их наступления. В итоге математическая модель управления рисками на комбинате подразделяет их на четыре класса. Риски с низкой вероятностью возникновения и низкими возможными потерями принимаются, риски с высокой вероятностью должны быть уменьшены, а те риски, возможные потери от которых велики, но вероятность их наступления незначительна, могут быть транслированы.
Кроме того, на ММК существуют следующие принципы управления рисками:
- правила управления рисками должны быть едины для всей компании и обеспечивать целостный взгляд на ситуацию;
- контроль за программой управления рисками должен быть централизованным, чтобы можно было отслеживать вклад каждого подразделения в обеспечение соответствия требованиям;
- управление рисками и их контроль должны вестись непрерывно, и это касается каждого сотрудника.
ИТ-риски
Описываемая ниже информационная система предназначена для работы с ИТ-рисками, которые, как было сказано выше, на ММК рассматриваются в качестве подвида рисков операционных. Заметим, что проект еще не завершен, все алгоритмы сейчас работают в пилотной зоне, не получив пока распространения на всё предприятие, и реализованы только для некоторой части бизнес-процессов. Все ИТ-риски комбината делятся на две большие категории. Первая - это риски, вызванные действиями персонала. Сюда относится управление доступом к ресурсам, обеспечение его в строгом соответствии с выполняемыми сотрудником функциями и контроль использования ресурсов. Второй тип - риски технологические, куда относятся сбои или отказы оборудования. В рамках управления этим видом рисков обеспечивается непрерывность предоставления пользователям ИТ-сервисов надлежащего качества. Наибольшая доля рисков, конечно, связана с людьми. Невозможно полностью защититься от собственных сотрудников, так как для выполнения задач им необходим доступ к ресурсам, а следовательно, они даже невольно могут нанести ущерб предприятию.
Как уже говорилось, при оценке риска используются два основных параметра - вероятность возникновения и величина ущерба. Очевидно, что от точности их измерения зависит точность оценки и соответственно выбор того или иного решения. Проблема, однако, состоит в том, что на сегодняшний день даже по ИТ-рискам невозможно получить все необходимые для анализа данные, поскольку собранной статистики недостаточно, а ставить эксперименты на действующих системах можно далеко не всегда. С учётом этого обстоятельства в создаваемой системе предусмотрен механизм формирования экспертных оценок.
Программная архитектура системы
При создании пилотной зоны управления ИТ-рисками ММК весь функционал был реализован на основе продуктов Computer Associates, которые уже широко используются на комбинате. Например, AllFusion Process Modeller (BPWin) позволяет описать бизнес-процессы в соответствии с рекомендованной ГОСТом методологией. В CA CMDB содержится единая база описания конфигурационных элементов, формирующих ИТ-инфраструктуру предприятия. С помощью CA Policy and Configuration Management (eTrust Policy Compliance) ведется база уязвимостей и проверка конфигураций ИТ-ресурсов на их наличие.
Aion Business Rules Expert (BRE) отвечает за формирование экспертных оценок путём анкетирования (CA Workflow) и анализа рисков на основе динамически определяемых правил (Rules Management). Эта программа является основным центром принятия решений в системе оценки рисков (см. рис. 2). Она позволяет оценивать риски с помощью динамически задаваемых правил, определяемых аналитиком, который может их менять и ветвить в зависимости от ситуации. С точки зрения реализации правил, используемых при анализе, Aion BRE поддерживает как прямую, так и обратную последовательность их выполнения. Прямая последовательность позволяет проверять условия описанных правил и формировать результирующие оценки. При обратной последовательности анализ ведется исходя из окончательной оценки, то есть здесь рассчитываются те значения входных параметров, при которых в соответствии с описанной бизнес-логикой наступит определённая вероятность возникновения риска. Но для того, чтобы система смогла произвести подобную оценку, ей на вход требуется подать дополнительную информацию из других подсистем. Именно этому служит комплекс перечисленных выше решений. Во-первых, для оценки величины возможного ущерба от реализации угрозы необходимо описать те бизнес-процессы комбината, для которых оценивается риск. Без использования информационных сервисов при реализации того или иного бизнес-процесса связанный с ИТ риск просто не может возникнуть. В создаваемой системе данную задачу предлагается решать с помощью BPWin, где описываются как сам бизнес-процесс, так и ИТ-сервисы, используемые для его выполнения. В BPWin стоимость процесса задается экспертно, но при этом специалист пытается по возможности обосновать свою оценку статистическими данными из других подсистем. Получив описание бизнес-процесса с указанием его стоимости и применяемых ИТ-сервисов, можно переходить к следующему шагу - выявлению угроз, связанных с использованием этих сервисов. С помощью базы данных конфигурационных единиц (CMDB) сервисы раскрываются, т. е. описывается состав ресурсов, необходимых для их предоставления. В приложениях Catalog и Asset, которые можно видеть в правой части схемы, описываются ресурсы, сервисы и договоренности об уровне обслуживания (SLA). Далее эти описания попадают на вход продукта eTrust Policy Compliance, анализирующего потенциальные уязвимости каждого ресурса на основе соответствующей информации из централизованных источников. На ММК такими источниками являются базы знаний CERT и Microsoft Security.
Теперь обратите внимание на левую часть схемы. Чтобы подсчитать вероятность риска в целом, сначала нужно рассчитать вероятность всех его составляющих. На этом шаге тоже приходится пользоваться экспертной оценкой, а статистическую поддержку решения ММК обеспечивает служба Service Desk, регистрирующая все инциденты. Инциденты попадают в базу двумя путями - либо по заявкам персонала, либо через систему автоматического мониторинга инфраструктуры CA Network and System Management. В случае технической поломки серверов или коммутационного оборудования локальной сети система автоматически пересылает инцидент в Service Desk для принятия решения. А Service Desk в свою очередь представляет в удобном виде статистику для специалистов, которым делегировано право подсчета вероятности рисков на основе этих данных и собственного опыта.
Разумеется, не все уязвимости носят чисто технический характер, и в системе управления рисками следует учесть большое количество организационных моментов, которые технически получить невозможно. Примером здесь могут служить регламенты и их соблюдение, назначенные для выполнения работ сотрудники и т. д. Для хранения подобной информации на ММК существует модуль по управлению анкетами. Специально выделенные сотрудники заносят в анкеты данные, после чего информация по всем видам рисков, как техническим, так и организационным, передается в Aion BRE. На данный момент на комбинате существует два вида числового выражения значимости рисков: по рейтинговым значениям и через денежный эквивалент. В результате проведения описанных выше работ предприятие получает список максимально критичных уязвимостей, в отношении которых согласно полученной оценке необходимо принять первоочередные меры. Именно по этой результирующей модели ИТ-служба готовит для руководства комбината обоснование расходов на управление ИТ-рисками.
Неотвратимость наказания
Существенная часть ИТ-рисков, как правило, возникает в результате неправомочных действий сотрудников, которые могут быть и неумышленными, вызванными недостаточной квалификацией или халатностью, что, однако, не уменьшает ущерб от них. На ММК считают, что из всех известных на сегодняшний день методов защиты от них наиболее эффективным является сознание неотвратимости наказания. Суть этого метода состоит в построении такой системы контроля, которая позволит гарантированно выявлять неадекватные действия персонала и на основании имеющейся информации предпринимать репрессивные меры. Иными словами, каждый сотрудник должен знать, что все его действия контролируются и фиксируются, так что любая попытка нправомочного поведения будет выявлена и он понесет соответствующее наказание.
Неотвратимость наказания нарушителей предполагает аудит и ведение базы данных, которая впоследствии позволит доказать, кто совершил то или иное действие. Вся цепочка фиксации событий в системе выглядит так: сбор и консолидация данных аудита; обработка собранных данных на основе предопределенных политик с последующей визуализацией полученных результатов; определение принадлежности действий конкретному физическому лицу; анализ контекста выявленных событий и формирование доказательной базы как для внутренних исследований, так и для внешнего разбирательства в случае серьезных нарушений. Сначала собираются журналы различных систем. А поскольку событий фиксируется очень много, то нужен продукт, фильтрующий их по каким-то заданным политикам, чтобы можно было прийти к разумному количеству записей, по которым в случае необходимости будет проводиться расследование.
Проиллюстрировать сказанное можно на примере данных, полученных за некий усредненный рабочий день. Ориентировочно за отчетный период 65 тысяч сообщений поступает в систему аудита из системных журналов UNIX, миллион с небольшим - из журналов Windows, еще 100 тысяч - из журналов Intrusion Detection System и логов доступа, около 787 тысяч сообщений формируют межсетевые экраны и 12 тысяч - антивирусные системы. Итого без дополнительной обработки пришло бы просматривать порядка трех миллионов сообщений. Но на этапе выделения взаимосвязанных событий они группируются в 15 тысяч записей, после фильтрации на предмет их значимости с точки зрения информационной безопасности их остается только 24, а немедленной реакции требуют восемь. Эту работу по консолидации данных выполняет eTrust Audit (Security Command Center). Коннекторы с другими программными системами позволяют ему в режиме реального времени или с минимальной задержкой собрать все сообщения из множества источников в свою центральную коллекцию. Причем исходными данными аудита в этом случае являются технические записи вида: поле такое-то изменило значение на такое-то, - и далеким от системного администрирования людям не всегда понятно, что это за поля. При написании же коннекторов записи аудита переводятся в ясные для сотрудников бизнес-подразделений термины, например, в поля «оплата», «производительность» и т. п. В результате на этапе анализа уже значительно легче будет разобраться, что же на самом деле произошло. На следующем шаге Security Command Center позволяет построить отчеты: сгруппировать данные аудита по пользователям, по системам, по событиям и другим категориям. Информация становится наглядной. Определить, кому принадлежат те или иные действия, поможет система учета прав доступа пользователей информационных ресурсов ММК. Именно через неё пользователям централизованно предоставляется доступ к информационным ресурсам предприятия. Соответственно здесь можно сопоставить записи журнала авторизации и понять, кто отвечает за произошедшее.
Взгляд со стороны бизнеса
Мы рассмотрели подходы к управлению рисками и архитектуру создаваемой системы. На самом же высоком уровне абстракции последовательность работы выглядит так. Сначала применительно к компонентам информационных ресурсов определяются уязвимости, после чего выясняется, какие ИТ-сервисы опираются на эти компоненты и какие бизнес-процессы в свою очередь опираются на эти ИТ-сервисы. Это позволяет оценить значимость риска. Как мы уже говорили, оценки существуют в двух вариантах: в рейтинговых и денежных значениях. Связь бизнес-процесса с ИТ-сервисом более подробно описывается в BPWin, в каталоге сервисов. Информация о влиянии этого бизнес-процесса, т. е. о его значимости - там же. Например, в каталоге сервисов для услуги «Бюджетное планирование и консолидированная отчетность» даётся ее категория (Oracle Financial Analyzer), описание, документация, соглашение об уровне сервиса и т. д. Определяется множество параметров услуги, в том числе говорится, какие ИТ-сервисы используются в качестве подлежащих. Так становится возможным донести чисто техническую информацию об ИТ-рисках предприятия до руководства, подкрепив там, где позволяют обстоятельства, экспертные оценки сотрудников ИТ-службы статистическими данными из информационных систем.