Концепция GRC стала очередным этапом развития рынка ИБ

Концепция «Governance, Risk, Compliance» (GRC) стала очень актуальной и востребованной на рынке ИТ. Не проходит и месяца, как анонсируются очередные услуга, проект или продукты, которые способствуют достижению стандартов GRC. Компании, работающие на рынке информационной безопасности, с удовольствием эксплуатируют эту тему, поскольку она позволяет обратиться уже к бизнес-уровню заказчика с предложением своих услуг и решений. Как и в любой маркетинговой кампании, в случае с GRC уже пора отделить реальное наполнение от громких слов.

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

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

Процессы GRC

Источник: Oracle, 2008

Интерес к GRC подогревается с трех сторон. С одной стороны, требования таких документов как SOX, Basel-II и др. прямо указывают на необходимость создания внутренних систем управления, гарантирующих адекватный менеджмент рисков, независимость аудита и персональную ответственность руководства компании за недостоверность финансовых данных.

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

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

Только комплексная система позволяет достичь целей GRC

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

Компоненты GRC

Источник: Oracle, 2008

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

Решения GRC

Из вышесказанного понятно, что никакое отдельное ИТ-решение не в состоянии в полном объеме обеспечить построение системы GRC. Однако, на рынке имеется целый ряд продуктов от Oracle, OpenPages, Paisley и других вендоров, которые могут облегчить решение этой задачи.

Классификация продуктов для построения системы GRC

Источники: Burton Group, Oracle, 2008

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

Как правильно выбрать GRC-систему?

На взгляд автора, следующие несложные правила позволят избежать разочарования при выборе GRC-приложений:

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

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

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

Полезно также изучение состояния дел с интеграцией GRC-системы с имеющимися бизнес-приложениями (например, ERP-системами). Одно дело, вручную прописывать политики Segregation of Duties (SoD) в ERP-системе на основании декларативной рекомендации GRC-системы. И совсем другое: автоматически реализовать SoD на базе предопределенных правил GRC, учитывающих особенности данной ERP-системы.

Немаловажным является выяснение того, на каких уровнях ИТ-инфраструктуры работают предлагаемые GRC-приложения. Если предложенный стек GRC-приложений оперирует на максимальном количестве уровней ИТ-системы: от ОС и СУБД до бизнес-приложений. Это гарантирует эффективный контроль над соблюдением требований и реализаций лучших практик без ”белых пятен”;

И напоследок, не помешает обратить внимание на репутацию вендора, его финансовые показатели, стратегию развития и отзывы аналитиков. GRC - не та область, где можно довериться “кустарям”.