Связность (coupling) и сплоченность (cohesion)

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

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

Разница между связностью и сплоченностью

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

Как оценивается связность (coulping)

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

• Data Coupling: Если зависимость между модулями основана на том, что они взаимодействуют, передавая только конкретные данные друг другу, то говорят, что модули связаны по данными. В случае такой связи модули практически независимы друг от друга. Отличный примером может являться то, когда между ИТ и ИБ в части патчинга существует такой интерфейс: вторые присылают первым название сервера и перечень нужных патчей, первые после патчинга выдают ок или не ок. В данном случае ИТ и ИБ связаны по данным.

• Stamp Coupling: Такая связь между модулями возникает, когда модули используют какую-то одну структуру данных (возможно разные части этой структуры). Тут ситуация несколько запутанная, и, как правило, заключается в последовательном использовании и изменении данной структуры из-за чего происходят различные негативные side-эффекты. Например, отчет о сканировании получает сначала отдел рисков, у которого есть свои механизмы для исключения не важных с точки зрения оценки рисков уязвимостей. Они эту информацию удаляют из отчета и пересылают отчет в SOC, который не предполагает, что из отчёта было что-либо удалено, и не проводит анализ логов на предмет того, могли ли эти удаленные рисковиками уязвимости быть использованы злоумышленником ранее.

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

• External Coupling: Внешняя связность выражается в том, что два или много модулей одновременно зависят от одного внешнего фактора. Например, два отдела пользуются одной системой (или аутсорсером, аутстаффером и т.д.). Один из отделов вносит значимые изменения в систему, из-за которых второй отдел не может выполнять свою работу.

• Common Coupling: Модули используют общие (глобальные) структуры данных. Например, совместно используют результаты сканирования на уязвимости для принятия различных решений (SOC — что мониторить, отдел рисков — для переоценки рисков). Ошибка в таких данных может привести к принятию неверных решений в обоих отделах. А если вдруг SOC потребовались, к примеру, данные сканирования в другой нотации, то ему потребуется подождать, пока к соответствующему варианту подготовится отдел управления рисками (переделает свои процедуры).

• Content Coupling: Например, есть отдел, который занимается управлением активами (инвентаризация, уязвимости и т.д.), и есть другой отдел, который занимается расчётом рисков. Очевидно, что они используют одну и ту же структуру — какой-то инвентаризационный лист активов. Если вдруг, первый отдел решит изменить свой подход к ведению данного инвентаризационного листа, то неизбежно изменится и качество оценки рисков (предположительно, для возврата к нормальному состоянию потребуется изменение процедур оценки рисков). Или, и SOC и отдел рисков используют общую базу инцидентов, в которую вносят каждый свои изменения. Рисковики могут дополнить такую базу, какими-то специфическими инцидентами для корректного принятия решений по рискам, а SOC в своем post-mortem анализе вдруг видит что-то не совсем то, что ожидалось.

Как оценивается сплочённость (cohesion)

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

• Functional Cohesion: В одном модуле собираются все необходимые (важные) элементы, чтобы выполнять какое-либо одно конкретное действие (или ряд похожих). Как пример, это может быть объединение под одну крышу управления активами с оценкой рисков, так как последнее зависит от того, как происходит управление активами. Так можно быть увереным, что результаты оценки рисков не будут чем-то тёплым на лопате, как минимум из-за плохих данных по активам.

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

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

• Procedural Cohesion: Функции группируются в один модуль, потому что они выполняются в определенной последовательности, согласно некой процедуре. Хорошим примером может быть реагирование на инциденты, где у нас последовательно выполняются функции регистрации иницдента, обработки инцидента, взаимодействия с третьими лицами, репортинг, post-mortem (последовательность и содержание этапов может варьироваться в зависимости от компании).

• Temporal Cohesion: Различные функции модуля объединются только во время определенного интервала. Например, результаты аудита могут запустить все функции (в зависимости от результатов аудита), связанные с устранением выявленных проблем, как в управлении доступом, так и, к примеру, в управлении инцидентами или уязвимостями. Лучше всего это объясняется на примере человека, который собирается пойти спать: ему нужно почистить зубы (модуль «здоровье»), проверить двери (модуль «безопасность»), выключить электронные приборы (модуль «финансы»), прочитать молитву (модуль «душа»).

• Logical Cohesion: Функции модуля связаны только логически, но не функционально. Здесь довольно тяжело привести пример из мира кибербезопасности, так как такие связи встречаются очень редко. Ну, допустим, есть функция пен-теста и функция выявления информации об уязвимостях из открытых источников (мониторинг новостей вендоров, форумов и т.п.). Обе функции логически про одно — найти уязвимости. Но выполняются абсолютно по разному и друг с другом функционально не связаны.

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

Ну ок и что дальше?

Вспоминая начало:

Считается, что связность (coupling) должна быть низкой, а сплоченность (cohesion) высокой.

Идеальной ситуацией для нас было бы такое разделение функций, чтобы между отделами у нас был data / stamp coupling, а внутри отделов у нас все функции были functional / sequential / communicational cohesion. Как же этого добится? Универсальных способов нет. Покажу пару своих подходов.

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

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

Cohesion: хорошей практикой выглядит взять стандарт с максимальным количеством контролей (идеальным будет NIST 800-53) и смотреть, как функции безопасности в нём распределены по различным семействам, Как правило, внутри группы (семейства) контролей существует или sequential cohesion, или communicational cohesion. Для упрощенных вариантов можно взять меры из ФСТЭКовских документов, но там есть группа ЗИС (Защита информационной (автоматизированной) системы и ее компонентов), в которой такая каша...

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

Итого и немного про силос

Конечно, организационная структура часто размечается исходя из других факторов, например:

• амбиции отдельных членов вашей команды («или так, или ухожу»),
• их компетенции (тяжело отдать управление уязвимостями от человека, который собаку на этом съел, другому, кто этим не занимался только ради какого-то эфемерного functional cohesion),
• размера команды, когда среди пары десятков человек (или вообще пары человек) проводить какой-либо coupling / cohesion анализ равно разогревать океан кипятильником.

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

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

Silo mentality — a mindset present when certain departments or sectors do not wish to share information with others in the same company (википедия) // образ мысли, когда отделы не желают делиться информацией друг с другом.

То есть отделы перестают иметь какие-то общие цели в своих действиях и каждый фокусируется исключительно на своих целях (возникает плохой Security Experience (SX)). Как правило, такая ситуация возникает не сразу, а через какое-то время накопления конфликтов между руководителями. Решение этого вопроса не всегда простое и как правило базируется на переключении менеджеров из менталитета «мой отдел» в менталитет «наша организация». Есть различные методы, как попробовать это сделать, но об этом в другом посте.