Практические советы о том, как не сделать плохую архитектуру системы (подсистемы) обеспечения ИБ
Начнем сначала – с терминов и определений, так как автор на собственном опыте неоднократно убеждался, что одни и те же термины люди с различным техническим бэкграундом могут (и обязательно будут) воспринимать по-разному.
Например, термин «архитектура системы». Автор, работая в интеграторе, понимает под этим термином совокупность решений, взаимосвязей между ними, обеспечивающих выполнение определенных задач.
Задачи, решаемые системой (здесь и далее, говоря о системе, будем подразумевать, что это может быть, как система, так и небольшой «кусок» в виде какой-то подсистемы), в свою очередь, должны обеспечивать достижение целей, стоящих перед системой. Собственно говоря, ради чего проектирование и дальнейшая реализация затеваются.
Тут часто кроются первые ошибки – путаница в целях и задачах. Например, фраза: «…целью создания системы межсетевого экранирования является обеспечение сегментирования…» автора этих строк приводит в легкий шок. Позвольте, но ради чего сегментировать? Может, все же, «обеспечивать контроль информационных потоков…»? Обратное тоже может быть верным – не надо ставить цели в задачи.
Раз уж заговорили о целях и задачах, то важно упомянуть, что в идеальной вселенной информационная безопасность (ИБ) в большинстве случаев все же выполняет вспомогательную роль в бизнес-процессах (по классике – помогает обеспечить конфиденциальность, целостность и доступность этих самых процессов). По-хорошему, ответственные за информационную безопасность, совместно с владельцем бизнес-процесса, должны оценивать риски в этом-самом процессе и создавать системы обеспечения ИБ/применять оргмеры, минимизирующие эти риски/делающие их допустимыми. Но, автор понимает, что в реальном мире большинство владельцев бизнес-процессов не рассматривает риски ИБ самостоятельно.
Это все к тому, что на этапе формирования целей и задач системы ИБ легко «забыть» учесть специфику бизнес-процесса и сделать систему ИБ, которая, безусловно, будет решать поставленные задачи, но ответов на простые вопросы: «А, собственно, зачем нам эта система? Что именно она обеспечивает? Безопасность каких именно бизнес-процессов (= информации) обеспечивается этой системой?» не будет. Сделать систему обеспечения ИБ ради обеспечения информационной безопасности можно (и даже можно обосновать бюджет на нее), но зачем?
Сформировав задачи, решаемые потенциальной системой, необходимо сформировать требования, которым система должна соответствовать (= каким образом система должна решать поставленные задачи). Тут легко «смешать в кучу коней и людей» и забыть о том, что есть требования «обязательные» и «желательные».
Например, обязательное требование «система обеспечения антивирусной защиты на файловом сервере должна обеспечивать проверку объекта при операции записи на файловой системе» кажется логичным и разумным, но должна ли эта система обязательно «ограничивать доступ в сеть Интернет на основе репутационных списков» – вопрос дискуссионный.
Хорошей практикой будет формировать список действительно важных требований, остальные же рассматривать в качестве «приятных дополнений». А по-хорошему дополнительно ранжировать «приятные дополнения» по значимости, исходя из специфики компании.
Например, для небольшой компании возможность экспорта журналов работы во внешние системы хранения может быть несущественным (а на самом деле абсолютно ничего не значащим) дополнением, при этом отсутствие этой возможности в компании с развитым SOC’ом с большой вероятностью сделает невозможным применение конкретного решения.
Отходя немного в сторону, требования, конечно, необходимо формировать исходя из решений, представленных на рынке. При этом крайне желательно не поддаваться «синдрому утенка» и трезво оценивать возможности, реализуемые каждым конкретным решением (см. ранжирование критичности требований). Безусловно, любимые производителями и интеграторами дорогие мульти-комбайны делают «все и сразу», но, зачастую, их использование похоже на забивание микроскопом гвоздей.
Определившись с обязательными требованиями, сформировав критерии оценки дополнительных требований, не надо торопиться бежать и покупать решение, которое по даташиту идеально подходит под все требования.
Причина, как обычно, проста и банальна – особенности инфраструктуры и (или) особенности бизнес-процесса, которые могут сделать невозможной работу конкретных решений.
Более того, просто взять и развернуть какие-то решения не всегда бывает достаточным, лучше потратить немного времени и спроектировать с самого начала, как система будет работать, по необходимости, как будет осуществляться миграция со старых решений, как будет масштабироваться, как обновляться и т.д. Т.е. продумать жизненный цикл системы заранее.
Примеров, когда с самого начала не продумывали ответы на вопросы «как?» масса. Например, не учли, что сервер управления планируется размещать в изолированном от внешнего мира сегменте, при том, что серверу управления требуется постоянный доступ в Интернет.
Так что надо стараться при стендовых испытаниях или проверке концепции (PoC, Proof of Concept) какого-то решения смоделировать весь жизненный цикл работы системы, а не только то, что она запускается, и «вот смотрите – ловит eicar». Автор неоднократно сталкивался с тем, что заказчик под определенным термином понимает одно, а производитель решения совершенно другое. Вам же нужно убедиться, что система действительно (в реальной обстановке) будет решать поставленные задачи?
И еще пару слов про проектирование.
Как было сказано выше, надо заранее продумывать всю архитектуру решения, ее интеграцию со смежными информационными системами, протоколы обмена между системами, возможности смежных систем отдавать / принимать необходимую информацию и использовать ее в дальнейшем. Да, это долго, требует привлечения квалифицированных сотрудников, но в итоге поможет создать действительно эффективную систему.
Для кого-то описанное выше может быть очевидными вещами. Но если вы создаете системы обеспечения ИБ по принципу «хорошая презентация решения, попробуем, пожалуй, под него выбить бюджет», то хотя бы примерное следование принципам, описанным выше, поможет создавать системы, приносящие в итоге чуть больше пользы.
На этой (без)радостной ноте, пожалуй, резюмирую.
Не спроектировать явно плохую архитектуру системы вам поможет наличие однозначных и понятных ответов на следующие вопросы:
- Сформированы ли непротиворечивые бизнес-процессу цели существования системы и задачи, способствующие достижению поставленных целей?
- Определен ли список требований для реализации задач?
- Разделен ли этот список требований на действительно важные требования и необязательные требования?
- Ранжируются ли необязательные требования по степени важности?
- Проведены ли стендовые испытания (PoC) конкретных решений в вашей инфраструктуре, с учетом специфики реализации бизнес процесса и может ли система решить необходимые задачи?
- Есть ли полное понимание жизненного цикла системы в компании, смежных инфраструктурных систем?
.png)