Продукты
Продукты
Menu
02
База знаний
05
Услуги
01
О нас
04
2025
Контакты
phone
e-mail:
Обучение
03
Как компания с распределенной ИТ-инфраструктурой подготовила систему защиты к внедрению и испытаниям
Клиент — компания из B2B-сегмента с распределенной ИТ-инфраструктурой и несколькими информационными системами, которые поддерживают ключевые бизнес-процессы.
Для такого бизнеса информационные системы давно перестали быть вспомогательным инструментом. Через них проходят внутренние операции, взаимодействие между подразделениями, работа сотрудников и процессы, остановка которых напрямую влияет на деятельность компании.
13.01.2023
Клиенту требовалось перейти от общего понимания, что системы в принципе нужно защищать, к полноценной инженерной модели: определить защищаемый контур, оценить актуальные угрозы, зафиксировать требования к защите, спроектировать систему защиты информации и подготовить основу для ее дальнейшей проверки.
Проект охватил сразу несколько уровней работы: от обследования инфраструктуры до технической и организационной документации. Это позволило связать реальные ИТ-процессы, требования к защите и конкретные решения в единую систему.
23/07/25
Б-152
Задача
На старте нужно было сформировать проектную основу системы защиты информации.
Для этого предстояло:
Ключевая особенность проекта — нельзя было начинать с выбора конкретных средств защиты.
Покупка СЗИ без обследования и проектирования часто приводит к обратному результату: компания приобретает отдельные продукты, но не может объяснить, какие угрозы они закрывают, где должны быть установлены и достаточно ли выбранного состава для выполнения требований.
Поэтому работа строилась в обратной логике: сначала фактический контур и угрозы, затем требования, проектные решения и только после этого — конкретный состав средств защиты.
Для этого предстояло:
- обследовать информационные системы и определить границы защищаемого контура;
- разобраться, какие системы требуют первоочередного внимания;
- определить актуальные угрозы безопасности;
- разработать технические требования к защите;
- спроектировать архитектуру системы защиты;
- определить состав средств защиты информации;
- закрепить организационные правила эксплуатации;
- подготовить программу и методику будущих испытаний.
Ключевая особенность проекта — нельзя было начинать с выбора конкретных средств защиты.
Покупка СЗИ без обследования и проектирования часто приводит к обратному результату: компания приобретает отдельные продукты, но не может объяснить, какие угрозы они закрывают, где должны быть установлены и достаточно ли выбранного состава для выполнения требований.
Поэтому работа строилась в обратной логике: сначала фактический контур и угрозы, затем требования, проектные решения и только после этого — конкретный состав средств защиты.
Что усложняло проект
Нужно было увидеть весь ИТ-контур, но не проектировать все одинаково
В инфраструктуре клиента работало несколько систем, связанных с разными бизнес-процессами. Для корректной оценки защиты требовалось видеть общую картину: как устроен контур, какие компоненты взаимодействуют между собой и где проходят значимые границы.
При этом одинаково глубоко проектировать защиту всех систем не имело смысла.
Команда Б-152 разделила две задачи:
Такой подход сохранил целостную картину инфраструктуры и одновременно не превратил проект в формальное описание всего подряд.
При этом одинаково глубоко проектировать защиту всех систем не имело смысла.
Команда Б-152 разделила две задачи:
- обследование и анализ проводились с учетом общего ИТ-контура;
- детальное проектирование системы защиты сосредоточили на системах, для которых защита требовалась в первую очередь.
Такой подход сохранил целостную картину инфраструктуры и одновременно не превратил проект в формальное описание всего подряд.
Защиту нужно было встроить в существующую архитектуру
Проектирование СЗИ не происходит в вакууме. У компании уже есть информационные системы, сетевые связи, способы администрирования, учетные записи, рабочие станции и сложившиеся процессы эксплуатации.
Поэтому задача не сводилась к перечню средств защиты.
Нужно было определить:
Именно на этом этапе становится видно различие между формальным комплектом документов и реальным проектированием защиты.
Поэтому задача не сводилась к перечню средств защиты.
Нужно было определить:
- какие угрозы актуальны именно для этого контура;
- какие требования должны выполняться;
- где в архитектуре нужны защитные механизмы;
- как они будут взаимодействовать с существующими системами;
- какие организационные правила должны поддерживать технические решения.
Именно на этом этапе становится видно различие между формальным комплектом документов и реальным проектированием защиты.
Инфраструктура менялась по ходу проекта
Для длительных инженерных проектов это нормальная ситуация: ИТ-контур развивается, отдельные компоненты меняются, появляются новые архитектурные решения.
Но для проекта защиты любое существенное изменение может затронуть сразу несколько документов:
Поэтому команда Б-152 отслеживала изменения не как отдельные технические события, а как факторы, которые могут повлиять на всю проектную логику.
Это помогало сохранять согласованность документов: чтобы модель угроз описывала актуальный контур, проектные решения соответствовали реальной архитектуре, а состав СЗИ оставался связан с требованиями.
Но для проекта защиты любое существенное изменение может затронуть сразу несколько документов:
- границы защищаемого контура;
- модель угроз;
- техническое задание;
- технический проект;
- спецификацию средств защиты;
- программу испытаний.
Поэтому команда Б-152 отслеживала изменения не как отдельные технические события, а как факторы, которые могут повлиять на всю проектную логику.
Это помогало сохранять согласованность документов: чтобы модель угроз описывала актуальный контур, проектные решения соответствовали реальной архитектуре, а состав СЗИ оставался связан с требованиями.
Нужно было сохранить преемственность проектных решений
В ходе продолжительных проектов состав участников с обеих сторон может меняться. В такой ситуации особенно легко потерять логику ранее принятых решений: почему граница контура проведена именно так, откуда появилось конкретное требование и чем обусловлен выбранный состав защиты.
Поэтому отдельное значение имела связность проектной документации.
Модель угроз, техническое задание, технический проект, спецификация и программа испытаний должны продолжать одну и ту же инженерную логику. Тогда новый участник проекта может восстановить ход решений по документам, а не начинать анализ системы заново.
Поэтому отдельное значение имела связность проектной документации.
Модель угроз, техническое задание, технический проект, спецификация и программа испытаний должны продолжать одну и ту же инженерную логику. Тогда новый участник проекта может восстановить ход решений по документам, а не начинать анализ системы заново.
Как строилась работа
1. Обследовали информационные системы и восстановили фактический контур
Первый этап — обследование.
Команда Б-152 собрала информацию об архитектуре, составе информационных систем, их назначении и взаимосвязях. В фокусе были не только технические компоненты, но и реальная эксплуатация:
Этот этап дал основу для всех следующих решений.
Без обследования модель угроз быстро превращается в набор универсальных сценариев, техническое задание в перечень общих требований, а спецификация СЗИ в список продуктов без убедительного обоснования.
Команда Б-152 собрала информацию об архитектуре, составе информационных систем, их назначении и взаимосвязях. В фокусе были не только технические компоненты, но и реальная эксплуатация:
- какие бизнес-процессы поддерживает система;
- какие данные в ней обрабатываются;
- кто работает с системой;
- как организован доступ;
- как происходит администрирование;
- с какими компонентами и внешними контурами система взаимодействует.
Этот этап дал основу для всех следующих решений.
Без обследования модель угроз быстро превращается в набор универсальных сценариев, техническое задание в перечень общих требований, а спецификация СЗИ в список продуктов без убедительного обоснования.
2. Определили приоритетный контур проектирования
После обследования команда разделила общий ИТ-контур и системы, для которых требовалось детальное проектирование защиты.
Это позволило избежать двух крайностей.
Первая — анализировать только одну систему и не замечать связанные с ней компоненты.
Вторая — пытаться проектировать защиту всей инфраструктуры с одинаковой глубиной независимо от приоритетов бизнеса.
В результате клиент получил более точную модель: общий контур был обследован, а проектные усилия сосредоточились там, где защита требовалась в первую очередь.
Это позволило избежать двух крайностей.
Первая — анализировать только одну систему и не замечать связанные с ней компоненты.
Вторая — пытаться проектировать защиту всей инфраструктуры с одинаковой глубиной независимо от приоритетов бизнеса.
В результате клиент получил более точную модель: общий контур был обследован, а проектные усилия сосредоточились там, где защита требовалась в первую очередь.
3. Разработали модель угроз
Следующий этап — моделирование угроз безопасности.
Команда оценивала не абстрактные «киберриски компании», а конкретные условия эксплуатации систем:
Модель угроз стала связующим звеном между обследованием и проектированием.
Именно она отвечает на вопрос, от чего должна защищать система. Без этого невозможно обоснованно определить требования и выбрать меры защиты.
Команда оценивала не абстрактные «киберриски компании», а конкретные условия эксплуатации систем:
- архитектуру;
- точки взаимодействия;
- способы доступа;
- администрирование;
- программные и технические компоненты;
- возможные сценарии действий нарушителя.
Модель угроз стала связующим звеном между обследованием и проектированием.
Именно она отвечает на вопрос, от чего должна защищать система. Без этого невозможно обоснованно определить требования и выбрать меры защиты.
Если у компании похожая задача — несколько ИС, меняющаяся инфраструктура или непонимание, с какого этапа начинать построение защиты, — ее можно предварительно обсудить с экспертами компании Б-152. Для этого достаточно оставить заявку и кратко описать текущий контур: нужна ли модель угроз, проектирование СЗИ, актуализация документов, подбор защитных решений или подготовка к испытаниям.
4. Перевели требования в техническое задание
После определения угроз команда разработала техническое задание.
На этом этапе результаты обследования и моделирования переводятся в конкретные требования к будущей системе защиты.
ТЗ задает проектные рамки:
Для клиента это точка перехода от анализа к проектированию.
Вместо общей задачи «усилить безопасность» появляется конкретный набор требований, который можно использовать при дальнейшем внедрении.
На этом этапе результаты обследования и моделирования переводятся в конкретные требования к будущей системе защиты.
ТЗ задает проектные рамки:
- что именно нужно защищать;
- какие требования должны выполняться;
- какие функции должна обеспечивать система защиты;
- какие ограничения существующей инфраструктуры нужно учитывать;
- какой результат должен быть получен после реализации решений.
Для клиента это точка перехода от анализа к проектированию.
Вместо общей задачи «усилить безопасность» появляется конкретный набор требований, который можно использовать при дальнейшем внедрении.
5. Разработали технический проект
Следующим шагом стал технический проект.
Если ТЗ отвечает на вопрос «что должна обеспечивать защита», технический проект показывает, «как это будет реализовано».
Команда связала требования с архитектурой и определила проектные решения:
Для сложных систем именно технический проект снижает риск хаотичного внедрения. Команда, которая будет реализовывать защиту, получает не набор разрозненных рекомендаций, а связанную архитектуру.
Если ТЗ отвечает на вопрос «что должна обеспечивать защита», технический проект показывает, «как это будет реализовано».
Команда связала требования с архитектурой и определила проектные решения:
- где применяются защитные механизмы;
- как они встраиваются в существующий контур;
- какие компоненты участвуют в защите;
- как распределяются функции;
- какие организационные условия нужны для эксплуатации.
Для сложных систем именно технический проект снижает риск хаотичного внедрения. Команда, которая будет реализовывать защиту, получает не набор разрозненных рекомендаций, а связанную архитектуру.
6. Определили состав средств защиты
На основе обследования, модели угроз и проектных решений была сформирована спецификация средств защиты информации.
Для бизнеса это один из самых прикладных результатов проекта.
Вместо формулировки «требуется усилить защиту» клиент получил ответ на конкретный вопрос: какой состав решений нужен для реализации заложенной модели и выполнения установленных требований.
При этом СЗИ подбирались не отдельно от проекта. Их место и назначение следовали из предыдущих этапов:
контур → угрозы → требования → архитектура защиты → состав СЗИ.
За счет такой последовательности спецификация становится частью проектной модели, а не самостоятельным списком закупок.
Для бизнеса это один из самых прикладных результатов проекта.
Вместо формулировки «требуется усилить защиту» клиент получил ответ на конкретный вопрос: какой состав решений нужен для реализации заложенной модели и выполнения установленных требований.
При этом СЗИ подбирались не отдельно от проекта. Их место и назначение следовали из предыдущих этапов:
контур → угрозы → требования → архитектура защиты → состав СЗИ.
За счет такой последовательности спецификация становится частью проектной модели, а не самостоятельным списком закупок.
7. Подготовили организационные документы
Технические средства не работают сами по себе.
Даже корректно спроектированная система защиты зависит от того, как компания управляет доступом, кто отвечает за эксплуатацию, как сотрудники действуют при изменениях и какие правила поддерживают защитные механизмы.
Поэтому мы подготовили комплект локальных нормативных актов.
Документы закрепили организационную сторону защиты: роли, ответственность, порядок эксплуатации и правила, которые должны поддерживать технические решения после их внедрения.
Этот этап особенно важен для компаний, которые хотят получить устойчивую систему, а не разовый технический результат.
Даже корректно спроектированная система защиты зависит от того, как компания управляет доступом, кто отвечает за эксплуатацию, как сотрудники действуют при изменениях и какие правила поддерживают защитные механизмы.
Поэтому мы подготовили комплект локальных нормативных актов.
Документы закрепили организационную сторону защиты: роли, ответственность, порядок эксплуатации и правила, которые должны поддерживать технические решения после их внедрения.
Этот этап особенно важен для компаний, которые хотят получить устойчивую систему, а не разовый технический результат.
8. Подготовили программу и методику испытаний
Завершающим элементом проектной базы стала программа и методика испытаний.
ПМИ заранее определяет:
Для клиента это дает прозрачность еще до испытаний. Команда понимает, к каким проверкам готовиться, какие проектные решения должны быть реализованы и по каким критериям будет оцениваться результат.
ПМИ заранее определяет:
- что будет проверяться;
- какие методы применяются;
- какие результаты считаются подтверждением выполнения требований.
Для клиента это дает прозрачность еще до испытаний. Команда понимает, к каким проверкам готовиться, какие проектные решения должны быть реализованы и по каким критериям будет оцениваться результат.
Что сделала команда Б-152
Проект охватил полный цикл подготовки системы защиты к внедрению и проверке:
По сути, мы выступили связующим звеном между требованиями к защите, реальной архитектурой клиента и дальнейшей технической реализацией.
Это важный формат работы для компаний, которым нужна помощь не в одном узком вопросе. В одном проекте могут последовательно решаться задачи разной сложности: от обследования отдельной системы до проектирования СЗИ, подготовки организационных документов и базы для испытаний.
- обследование ИТ-контура;
- анализ информационных систем и их взаимосвязей;
- определение приоритетного контура защиты;
- разработку модели угроз безопасности;
- подготовку технического задания;
- разработку технического проекта;
- определение необходимого состава средств защиты информации;
- подготовку спецификации СЗИ;
- разработку локальных нормативных актов;
- подготовку программы и методики испытаний;
- актуализацию проектной логики при изменениях инфраструктуры.
По сути, мы выступили связующим звеном между требованиями к защите, реальной архитектурой клиента и дальнейшей технической реализацией.
Это важный формат работы для компаний, которым нужна помощь не в одном узком вопросе. В одном проекте могут последовательно решаться задачи разной сложности: от обследования отдельной системы до проектирования СЗИ, подготовки организационных документов и базы для испытаний.
Результат
Клиент получил сформированную проектную и организационную основу системы защиты информации.
Главный эффект проекта — переход от отдельных требований и технических задач к целостной инженерной модели защиты.
- Появился понятный защищаемый контур. Компания понимает, какие системы входят в проект и на каких архитектурных предпосылках строится защита.
- Актуальные угрозы связаны с конкретными требованиями и проектными решениями. Защитные меры не существуют отдельно от модели угроз и реальной инфраструктуры.
- Клиент получил техническое задание и технический проект — основу для последовательного внедрения системы защиты без необходимости заново определять архитектуру на каждом следующем этапе.
- Сформирована спецификация необходимого состава СЗИ. У компании есть конкретная база для планирования внедрения вместо абстрактного запроса «усилить защиту».
- Подготовлен комплект организационных документов, который поддерживает технические решения и закрепляет порядок дальнейшей эксплуатации.
- Программа и методика испытаний заранее задают критерии проверки. Это снижает риск ситуации, когда после внедрения выясняется, что команда и проверяющие по-разному понимают требуемый результат.
Главный эффект проекта — переход от отдельных требований и технических задач к целостной инженерной модели защиты.
Что этот кейс показывает рынку
Кейс полезен компаниям, у которых есть собственные информационные системы, распределенная инфраструктура или несколько взаимосвязанных ИТ-контуров.
Первый вывод: проект защиты не стоит начинать с закупки средств.
Пока не определены границы системы, угрозы и требования, невозможно обоснованно сказать, какие СЗИ нужны и где они должны применяться.
Второй вывод: модель угроз, ТЗ, ТП, спецификация, ЛНА и ПМИ должны продолжать одну проектную логику.
Если эти документы готовятся независимо друг от друга, компания получает формальный комплект, в котором требования, архитектура и будущие проверки могут не совпадать.
Третий вывод: изменение инфраструктуры — часть проекта, а не помеха проекту.
Задача команды состоит в том, чтобы понимать, какие изменения требуют пересмотра проектных решений.
Четвертый вывод: роль консультантов может быть шире подготовки документов.
В сложных проектах ценность появляется там, где команда связывает обследование, угрозы, требования, архитектуру, СЗИ, организационные правила и испытания в единый маршрут.
Первый вывод: проект защиты не стоит начинать с закупки средств.
Пока не определены границы системы, угрозы и требования, невозможно обоснованно сказать, какие СЗИ нужны и где они должны применяться.
Второй вывод: модель угроз, ТЗ, ТП, спецификация, ЛНА и ПМИ должны продолжать одну проектную логику.
Если эти документы готовятся независимо друг от друга, компания получает формальный комплект, в котором требования, архитектура и будущие проверки могут не совпадать.
Третий вывод: изменение инфраструктуры — часть проекта, а не помеха проекту.
Задача команды состоит в том, чтобы понимать, какие изменения требуют пересмотра проектных решений.
Четвертый вывод: роль консультантов может быть шире подготовки документов.
В сложных проектах ценность появляется там, где команда связывает обследование, угрозы, требования, архитектуру, СЗИ, организационные правила и испытания в единый маршрут.
Вывод
В этом проекте эксперты Б-152 помогли клиенту пройти путь от разрозненного ИТ-контура до целостной проектной базы системы защиты.
Результатом стали не отдельные документы и не перечень средств защиты, а связанная модель: что защищается, от каких угроз, по каким требованиям, за счет каких решений и как будет проверяться результат.
Именно такой подход делает дальнейшие этапы предсказуемее. У бизнеса появляется инженерная основа для внедрения, у ИТ- и ИБ-команд — понятная архитектура, у руководителей — конкретный состав работ и решений, которые нужны для достижения требуемого уровня защиты.
Результатом стали не отдельные документы и не перечень средств защиты, а связанная модель: что защищается, от каких угроз, по каким требованиям, за счет каких решений и как будет проверяться результат.
Именно такой подход делает дальнейшие этапы предсказуемее. У бизнеса появляется инженерная основа для внедрения, у ИТ- и ИБ-команд — понятная архитектура, у руководителей — конкретный состав работ и решений, которые нужны для достижения требуемого уровня защиты.
Ввод оборотных штрафов за утечки откладывается минимум до 1 июля 2023 года
Материалы по теме