Около корпоративной архитектуры

O-ESA: от политики безопасности к её исполнению

Архитектура безопасности, управляемая политиками: рамка и шаблон, а не перечень контролей. Два блока — Security Governance (принципы, политики, стандарты и процедуры, принуждение, постоянная оценка) и Security Technology Architecture. Парная школа к SABSA в том же домене.

Тип: Рамка архитектуры безопасности на основе политик

Служебные сведения

Редакция: The Open Group Guide G112, April 2011 (ISBN 1-931624-94-1)

91артефакт

Зачем это нужно

Почему политика безопасности лежит в папке, а доступ выдают по привычке

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

Опубликованная политика и исполняемая политика — разные вещи. Между «принципом» и кнопкой «запретить» лежит несколько переводов: принцип → политика → стандарт → решение → исполнение, и на каждом смысл может потеряться. O-ESA (Open Enterprise Security Architecture) — рамка и шаблон ровно для этой цепочки. Один блок — управление безопасностью: принципы, политики, стандарты и процедуры, обеспечение исполнения, аудит, непрерывная оценка. Второй — технологическая архитектура безопасности, где службы (администрирование идентичностей, аутентификация, авторизация, журналирование, аудит, криптография и другие) описаны на концептуальном, логическом и физическом уровнях, а к ним приложены артефакты проектирования: модель угроз, поверхность атаки, модель контрмер.

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

Об источнике честно: это руководство The Open Group 2011 года (G112), выросшее из NAC ESA Guide 2004-го, и часть определений служб устарела — антивирус нацелен на загрузочные записи и макросы, офлайновая авторизация названа «будущим направлением», о чём руководство само предупреждает. В реестре школа стоит около корпоративной архитектуры: одна предметная область. Её пара — SABSA: та выводит архитектуру безопасности из бизнес-рисков через матрицу 6×6, O-ESA даёт шаблон, из чего архитектура состоит и как политика доходит до исполнения. Читать их стоит вместе.

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

Кому это полезно

Аналитику — чтобы вопрос «кому и к чему можно» задавать в понятиях инициатора, цели, среды и правила, а не в терминах ролей одной системы.
Архитектору — чтобы службы безопасности были описаны на трёх уровнях — концептуальном, логическом, физическом — и не сводились к списку купленных продуктов.
Руководителю — чтобы видеть, что за политикой должны стоять полномочия (PMA), механизм исполнения и регулярная оценка, иначе документ ничего не меняет.

Чем это не является

Это не перечень контролей: За контролями идите в ISO/IEC 27002 — руководство само на него ссылается, а не дублирует. O-ESA отвечает на другой вопрос: как контроли складываются в архитектуру, от принципа до точки исполнения в конкретном приложении.
Это не SABSA и не её замена: SABSA — метод: вывести архитектуру безопасности из бизнес-рисков, заполняя матрицу 6×6. O-ESA — шаблон компонентов и цепочки политики. SABSA отвечает «зачем и что», O-ESA — «из чего состоит и как исполняется». Вместе они закрывают предметную область; по отдельности каждая оставляет дыру.
Это не актуальный каталог технологий: Издание 2011 года: определение антивируса говорит о загрузочных записях и макросах, офлайновая авторизация названа направлением на три-пять лет вперёд. Берите структуру — уровни, классы служб, точки решения и исполнения, — а не содержимое отдельных строк.

Как устроен подход

Исследуйте основные части: у каждой свой вопрос, смысл и место в примере.

O-ESA

Выберите элемент схемы — откроются объяснение и пример.

Принципы

Какие основания направляют решения?

Верх лестницы и единственный элемент, с которым обязано быть согласовано всё остальное — «All policies, standards, architectures, designs, operations, and other components of the technology process should align with these principles unless a governance body grants an exception». Оговорка про исключение — рабочая часть определения, а не вежливость: принцип, от которого нельзя отступить по решению органа руководства, на деле уже стандарт.

В нашем примере

Доступ предоставляют для служебной задачи с понятной ответственностью.

Связанные карточки

Принципы ↗

Выборочный авторский навигатор по подходу. Схема упрощена для объяснения; полный состав записей и источники — в каталоге ниже.

Общий доступ сотрудников к данным клиентов

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

01
Согласовать правило
Связываем принцип с конкретной политикой доступа к данным клиента.
Результат
Владельцы понимают, какое поведение обязательно.
Принципы ↗
02
Определить точки решения и исполнения
Разделяем управление политикой, принятие решения и его применение в приложениях.
Результат
Понятно, где изменить правило и где проверить его выполнение.
Политики ↗
03
Проверять исключения
Сопоставляем фактический доступ с политикой, разбираем отклонения и их основания.
Результат
Политика не остаётся документом без контроля исполнения.
Стандарты ↗

Связанные подходы

SABSA ↗

Метод построения архитектуры информационной безопасности, ведомой риском и бизнес-требованиями. Не заменяет другие стандарты безопасности и не конкурирует с ними, а даёт надстроечную рамку, под которую они встраиваются. Шесть слоёв на шесть вопросов дают матрицу 6 × 6, и белая книга прямо называет её заполнение сутью метода: «a process of populating all of these thirty-six cells».

Где теряется смысл подхода

Считать публикацию политики завершением работы

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

Не договориться о результате

Перед проработкой согласуйте вопрос: Какие основания направляют решения? Ответ должен быть понятен участникам рассматриваемой работы.

Не проверить на конкретном случае

Пройдите весь пример от исходной ситуации до результата: Политика не остаётся документом без контроля исполнения.

Сопоставление с частями предприятия

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

Есть сопоставление с 4 осями из 17

Ось реестра	В O-ESA	Сопоставление	Пояснение
Управление архитектурой, нормы и соответствие	Program Managementдомен	С осью пересекается частично.	Внешнее кольцо программы безопасности: требования, стратегия, планирование, риски, обучение. ОБЪЯВЛЕНО ВНЕ РАМОК O-ESA самим руководством: «The program management functions identified in the outer ring … are considered outside the main scope of this O-ESA Guide’s security architecture focus». Домен всё же заполнен, а не оставлен пустым, по двум причинам: инвариант листа требует домен у каждой строки предметной оси, и ложного покрытия это не создаёт — тот же нейтральный домен уже закрыт строкой Security Governance, которая в рамках школы.
Безопасность и риски + Управление архитектурой, нормы и соответствие	Security Governanceдомен	С осью пересекается частично.	Принципы, политики, стандарты, аудит и обеспечение соблюдения — это нормы и соответствие, но только в пределах безопасности. Свести к одному нейтральному домену нельзя: потеряется либо отраслевая рамка, либо вид деятельности.
Безопасность и риски + Технологическая ИТ-инфраструктура	Security Technology Architectureдомен	С осью пересекается частично.	Службы безопасности, их концептуальная, логическая и физическая архитектуры — инфраструктурный домен, суженный до безопасности.
Безопасность и риски + Деятельность: функции и процессы	Security Operationsдомен	С осью пересекается частично.	Администрирование, управление событиями, инцидентами, уязвимостями и соответствием — это процессы эксплуатации, суженные до безопасности.
Делит по другому признаку	Conceptual Frameworkуровень абстракции	Вне общих осей	Уровень детализации описания, а не предметный домен (разд. 4.1: «four levels of abstraction»). ОСОБЫЙ СЛУЧАЙ: те же четыре имени стоят строками № 9–12 на листе артефактов O-ESA — потому что рис. 3 рисует их прямоугольниками, а легенда документа говорит «the rectangular boxes represent components or deliverables». Это не двойной счёт, а два прочтения, объявленные самим изданием — тот же случай, что аспект-модели DEMO.
Делит по другому признаку	Conceptual Architecture · Logical Architecture · Physical Architectureуровень абстракции	Вне общих осей	Уровень детализации описания, а не предметный домен. См. оговорку в строке Conceptual Framework.
Делит по другому признаку	Business Policyслой	Вне общих осей	Слой перевода политики сверху вниз (разд. 6.1, рис. 22), а не предметный домен. Глава 6 перспективная: источник говорит о ней «the future arrows on the right of the diagram represent magic».
Делит по другому признаку	Security Policy (ISO/IEC 27001/2 policy domains)слой	Вне общих осей	Слой перевода политики, а не предметный домен. Отсылка к доменам политик ISO/IEC 27001/2 — чужая сетка, в наш нейтральный набор она не переводится без самого ISO/IEC 27001/2.
Делит по другому признаку	Management Standardsслой	Вне общих осей	Слой перевода политики, а не предметный домен. Источник сам выводит этот слой за свои рамки: «The management standards themselves are outside the scope of what is being addressed here».
Делит по другому признаку	Technical Standardsслой	Вне общих осей	Слой перевода политики, а не предметный домен. Самый нижний из четырёх: его реализация даёт электронное представление деловой политики.

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

С чего начать: O-ESA за неделю

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

День первый. Принципы.
Пять-семь принципов на страницу — например, «доступ предоставляют для служебной задачи с понятной ответственностью». Назовите орган управления, который вправе давать исключения. Всё, что появится дальше, должно быть согласовано с этой страницей.
День второй. Одна политика.
Возьмите одну область — доступ к данным клиентов. Запишите политику: широкое утверждение о том, что обязательно, — роль и контекст сотрудника определяют допустимую работу с данными. Назначьте орган управления политикой (PMA): кто её ведёт — человек или приложение.
День третий. Стандарты.
Переведите политику в директивы предприятия: требования к идентификации, к журналированию, к хранению свидетельств. Это внутренние документы; на ISO/IEC 27001 и 27002 они ссылаются, но не подменяются ими.
День четвёртый. Точки решения и исполнения.
По каждому приложению: где принимается решение и по каким входам — инициатор, цель, среда, правило, — и где оно исполняется: разрешить, заблокировать, сохранить свидетельство. Отметьте, где решение и исполнение слиты, и осознанно ли. Заведите репозиторий политик — одно место для правил.
День пятый. Сверка и оценка.
Сравните фактические назначения доступа с политикой; выпишите исключения и их основания. Договоритесь о ритме непрерывной оценки — не только «соблюдается ли», но и «годится ли ещё политика». Выберите одну метрику безопасности, которую будете смотреть регулярно.

Как понять, что получилось

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

Где ещё ошибаются

Спутать стандарт предприятия с отраслевым

В O-ESA стандарт — обязательная внутренняя директива: как идентифицировать, что журналировать. ISO/IEC 27001 — внешний ориентир, на который директива может ссылаться. Если в вашем списке стандартов одни номера ISO и ни одной собственной директивы, средняя ступень лестницы пуста, и политика не доходит до приложений.

Слить точку решения и точку исполнения молча

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

Что ещё спрашивают

Чем O-ESA отличается от ISO/IEC 27001?

ISO/IEC 27001 — требования к системе менеджмента информационной безопасности, 27002 — перечень контролей; O-ESA на них ссылается, а не дублирует. O-ESA — архитектурный шаблон: как принципы и политики доходят до точек решения и исполнения и из каких служб состоит технологическая архитектура. Грубо: 27001 говорит, что должно быть, O-ESA — как это устроено внутри.

Нужен ли отдельный инструмент?

Для первой недели — нет. Хватит таблиц: принципы, политика, стандарты, реестр точек решения и исполнения по приложениям. Репозиторий политик — по определению «место, а не содержимое», им может быть и вики. Автоматический перевод политики в конфигурации устройств — глава 6 — то, что руководство само называет будущим.

Подходит ли небольшой компании?

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

Раздатка · PDF

O-ESA простыми словами

18 страниц: что это и чем не является, устройство подхода, 48 карточек словаря, учебный пример и план первой недели.

Устройство подхода: 6 частей с вопросами и примерами
Словарь: 48 карточек простыми словами из 91 на странице
Учебный пример: Общий доступ сотрудников к данным клиентов
Типичные ошибки, план первой недели и ответы на вопросы

18 страниц · 0,74 МБ · A4

Пришлём ссылку сразу после отправки формы

Артефакты

Дословные выписки из стандарта с переводом.

Security Technology Architecture разд. 4

редакция заменена64 строки

Security Operations разд. 5

редакция заменена12 строк

Security Governance разд. 3

редакция заменена8 строк

Policy Automation Vision разд. 6

редакция заменена7 строк

В той же категории

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

GERAM

Обобщённая эталонная архитектура и методология (зонтичная рамка)

RAMI 4.0

Эталонная архитектурная модель

IT4IT

Эталонная архитектура ИТ как бизнеса

O-AA — Петля гибкой архитектуры вокруг продукта

O-AA

Стандарт гибкой корпоративной архитектуры

ISO 42010

Стандарт описания архитектуры

MEMO

Многоракурсный метод моделирования предприятия

История редакций

Родословная объявлена в предисловии: значимым достижением Network Applications Consortium стала публикация руководства NAC Enterprise Security Architecture (ESA) Guide в 2004 году. В конце 2007 года NAC влился в Security Forum консорциума The Open Group, и его участники, признав ценность руководства и одновременно то, что практика безопасности с 2004 года ушла вперёд, начали проект его обновления.

Настоящее руководство и есть это обновление: оно, в частности, заменяет лицензированную выдержку из британского кодекса практики по управлению информационной безопасностью ссылками на действующие ISO/IEC 27001 и 27002. Издано The Open Group в апреле 2011 года под номером G112 (ISBN 1-931624-94-1).

14 дней бесплатно

Опишите архитектуру своей компании в Storm

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

Попробовать бесплатно Без банковской карты

Это же в StormАрхитектура систем и интеграций База знаний и вики Реестр процессов