Как писать техстандарт по защите информации для крупной компании28.04.2020 14:33

Любая крупная компания со временем сталкивается с проблемой появления неразберихи в применяемых методах, способах и средствах защиты информации.

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

Первая задача — разобраться, что нужно защищать и как. Чтобы каждый руководитель как «отче наш» знал, какие конкретно меры защиты в отношении каких активов нужно принимать. Важно то, что набор применяемых мер защиты должен быть необходимым и достаточным. То есть безопасно и при этом в бюджете.

Вторая задача — стандартизовать технические решения. Каждая техническая мера защиты в идеале выполняется определённым образом с применением одного или нескольких конкретных средств. Если, например, применяете для защиты хостов антивирусы одного вендора, то можно с большей скидкой (из-за большого объёма) закупать лицензии, не надо держать штат специалистов, обладающих опытом работы с разными решениями. А если стандартизовать множество решений по ИБ, то можно создавать в разных компаниях похожие группы архитектуры и централизовать управление ими, тем самым практически отказаться от локальных подразделений.

Давайте расскажу, как это делали мы. Возможно, вы уже писали что-то подобное у себя, и наша история вам поможет структурировать такие вещи. Ну или просто даст пару идей, как это можно сделать.

Проблематика, что взято за основу, и что получилось по мерам защиты

Что было в самом начале, или какая была проблематика:

Компания хотела реализовывать меры защиты по какому-то одному «источнику правды». Грубо говоря, нужна была единая на весь холдинг таблица с перечнем того, что нужно сделать, чтобы и ИБ обеспечить, и соответствовать всем необходимым требованиям, спускаемым от регуляторов. И чтобы не было ситуаций, что каждая дочка реализует ИБ как ей вздумается, идя порой вразрез с позицией головы.
Экономии расходов и дифференцированный подход к выбору мер защиты — понятная и единая оценка критичности того, что нужно защищать. Сервер с рецептами в столовой, например, достаточно снабдить антивирусом и убедиться, что он не торчит в большой Интернет по RDP (я утрирую). А вот финансовый сегмент или базы данных HR нужно защищать куда сильнее. А к сегменту АСУ ТП нужен особый подход. Очень часто в компаниях руководители не могли точно оценить, что и в какой степени надо защищать, и защищали активы по принципу «всё на всё», т. е. ставим всё, что сказала головная компания, на все информационные системы вне зависимости от того, есть там ценные данные или их нет.
Компании в холдинге не всегда обеспечивали нужные меры ИБ. Возможность проверить — это возможность заставить всех их обеспечивать.
Естественно, очень хотелось сократить расходы. Как я говорил, это крупные моновендорные закупки и возможность поддерживать меньшее количество разных типов средств защиты.
Ещё одна особенность — безопасников очень бесит видеть, как кто-то выкатывает готовое решение, где не были учтены их требования. Дальше несколько отделов вместе придумывают, что же с этим делать. И за серьёзные деньги и время решают. Новый Технический стандарт ИБ позволял сразу выставить требования к проектированию системы ИБ и передать их как части ТЗ всем дочерним компаниям.

В общем, все рано или поздно приходят к необходимости разработки Технического стандарта ИБ. Кто-то делает сам, кто-то использует известные методологии, проверенные практикой и вазелином. В любом случае одним из первых вопросов при разработке техстандарта будет: «Откуда брать меры защиты?» Можно, конечно, самому придумывать, учитывая особенности своей организации. Но так никто не делает: ведь есть множество готовых наборов мер. Можно взять документы ФСТЭК России (приказы 21, 17, 239, 31), можно взять ГОСТ ЦБ. У нас была международная промышленная компания, и мы решили взять за основу Стандарты NIST «Framework for Improving Critical Infrastructure Cybersecurity» и NISTIR 8183 «Cybersecurity Framework Manufacturing Profile». Можно перейти по ссылке, скачать здоровенный PDF и проникнуться тем, до чего может дойти бюрократия в желании прикрыться кучей бумаг. На самом деле не надо пугаться размера шаблона: там всё по делу и всё нужно.

Всё было бы слишком просто, если бы можно было просто потратить время, перевести указанные выше нисты и выдать перевод за готовый техстандарт. У нас компания хоть и международная, но большая часть бизнеса всё же находится в РФ. Соответственно российскую нормативку тоже нужно учитывать. К тому же не все меры защиты из NIST применимы и необходимы (зачем реализовывать то, в чём нет необходимости, мы же не хотим нецелевого использования финансовых средств). Также сложности добавляло то, что компания у нас большая, в холдинге есть и промышленные предприятия, и базы отдыха, и гостиницы, и учётные и сервисные компании. Соответственно имеют место быть и персональные данные, и коммерческая тайна, и объекты КИИ, и АСУ ТП.

Что же мы сделали? Сначала мы сделали свободный перевод указанных выше NIST, убрав оттуда меры, в реализации которых нет необходимости. Это, например, меры, направленные на обеспечение ИБ в технологиях, которые неприменимы в нашем холдинге, или меры, в реализации которых нет необходимости согласно утверждённой в холдинге Матрице рисков и угроз (её тоже мы разрабатывали и, возможно, об этом напишем когда-нибудь пост). Затем мы замапили меры защиты из российских нормативных документов с мерами из NIST. Какие-то меры (по понятным причинам) идеально легли в меры из NIST, какие-то не ложились, и приходилось расширять состав мер. Добавились меры из следующих документов:

Федеральный закон от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»;
Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных»;
Федеральный закон от 29.07.2004 № 98-ФЗ «О коммерческой тайне»;
Постановление Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений»;
Постановление Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»;
Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»;
Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»;
Приказ ФСТЭК России от 21.12.2017 № 235 «Об утверждении Требований к созданию систем безопасности значимых объектов критической информационной инфраструктуры Российской Федерации и обеспечению их функционирования»;
Приказ ФСТЭК России от 14.03.2014 № 31 «Об утверждении Требований к обеспечению защиты информации в автоматизированных системах управления производственными и технологическими процессами на критически важных объектах, потенциально опасных объектах, а также объектах, представляющих повышенную опасность для жизни и здоровья людей и для окружающей природной среды». Здесь важный момент в том, что требования приказа носят рекомендательный характер, т. е. если кто-то не выполнит этих требований — проверка не придёт и никого не накажут. Но многие компании применяют эти требования. Почему? Потому что, если АСУ ТП не является объектом КИИ, то с точки зрения закона её можно никак не защищать, а с точки зрения бизнеса в случае реализации угроз в отношении этой АСУ ТП возможен прямой или косвенный ущерб. Ущерб в бизнесе не любят, и почему надо защищать такие АСУ ТП, понимают.

Ну и после всего перевода и маппинга мы добавили меры, которые нигде не описаны, но необходимы для нейтрализации угроз из упомянутой выше Матрицы рисков и угроз, а также меры, которые полезны и интересны к реализации с точки зрения ИБ-персонала Заказчика (так, например, появились киберучения).

В результате у нас появилась огромная таблица с мерами (на самом деле — две: краткая и подробная с инструкцией по реализации каждой меры), в которой ещё и указывалось, требованиям какого документа какая мера соответствует.

Ниже — картинка с подробным описанием конкретной меры:

А вот краткая таблица с перечнем мер и указанием, для каких типов систем эти меры должны применяться:

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

Итак, какие же меры вошли в эту таблицу? Есть пять функциональных направлений:

Каждое из пяти функциональных направлений ИБ разделено на три–шесть категорий. Суммарно выделяется 22 категории:

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

Процесс выбора мер защиты

Сказать, конечно, проще, чем сделать. И пока я рассказал только про набор мер защиты, а их же нужно как-то выбирать/отсеивать. Ниже — блок-схема процесса выбора мер защиты:

Пройдёмся по каждому шагу.

Определение типов ИС и АСУ ТП

Определение типов ИС и АСУ ТП, функционирующих (или планируемых к реализации) в любой компании холдинга, проводится с учётом того, что в холдинге выделяется пять типов ИС и АСУ ТП, подлежащих защите:

системы обработки персональных данных;
системы, обрабатывающие сведения, составляющие коммерческую тайну;
системы, являющиеся значимыми объектами КИИ;
АСУ ТП (не являющиеся значимыми объектами КИИ);
прочие информационные системы.

Разумеется, мы учитывали, что некоторые системы могут одновременно принадлежать к разным типам. Например, в ИСПДн могут ещё обрабатываться сведения, составляющие коммерческую тайну (КТ). В дальнейшем для таких систем компании обязаны были выполнить набор мер защиты для двух типов систем (ИСПДн и КТ).

В результате определения типов ИС и АСУ ТП формировалась таблица по примеру ниже:

Выбор мер защиты

Тут выбрали подход, максимально близкий к подходу ФСТЭК России. Выбор перечня необходимых к реализации мер защиты информации включает:

определение базового набора мер защиты;
адаптацию базового набора мер защиты;
дополнение адаптированного набора мер защиты мерами, установленными иными нормативными правовыми актами по ИБ;
оценку необходимости применения компенсирующих мер защиты информации.

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

Адаптация — исключение мер, непосредственно связанных с информационными технологиями, не используемыми в ИС и АСУ ТП, или характеристиками, несвойственными функционирующим ИС и АСУ ТП, а также добавление дополнительных мер, направленных на нейтрализацию актуальных угроз (модели угроз готовятся в обязательном порядке на любую систему или группу систем).

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

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

Определение профиля для каждой меры защиты

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

Профиль же определяется в зависимости от критичности системы. Т. е. мало определить класс/уровень защищённости/категорию, необходимо оценить критичность системы для холдинга. Для этого мы разработали отдельную методику, которая учитывает множество параметров (требования по доступности, содержание, объём, ценность обрабатываемой в системе информации, ценность системы в целом и степень её влияния на критичные производственные и бизнес-процессы). Так вот, согласно упомянутой выше методике, определяется класс критичности системы (это обязательный этап процесса инвентаризации и процесса создания новых систем). А в зависимости от класса критичности, согласно правилам Технического стандарта ИБ, выбирается профиль, по которому нужно реализовывать каждую меру защиты.

Формирование итогового набора мер защиты

Таким образом, по результатам прохождения всего алгоритма выбора мер защиты формируется единый необходимый к выполнению перечень мер защиты, который впоследствии может быть включен в ТЗ на создание/модернизацию ИС/АСУ ТП (или их систем защиты). Пример документирования — ниже:

Процесс выбора средств защиты

Итак, меры защиты мы выбрали, полдела сделано. Теперь нужно выбрать средства защиты, которые позволят эти меры реализовать. Выбор средств защиты включает в себя следующую последовательность действий:

определение типа площадки (объекта ИТ-инфраструктуры), к которой относится компания холдинга;
определение типов средств защиты, необходимых к использованию (антивирусы, средства обнаружения вторжений и предотвращения атак, межсетевые экраны, SIEM и др.);
определение области применимости (области внедрения) выбранных средств защиты;
определение конкретных производителей (вендоров) для выбранных средств защиты.

Так как у нас крупный холдинг, то логично, что у такого холдинга может быть несколько типов объектов ИТ-инфраструктуры (типов площадок). Есть ЦОДы, типовые производственные площадки, типовые удалённые площадки, типовые производственные или удалённые площадки вне РФ. На разных типах площадок могут быть внедрены различные компоненты централизованных и локальных средств защиты информации.
По понятным причинам не буду рассказывать, какие типы средств защиты применяются в холдинге и какие их компоненты на каких площадках развёрнуты.

Могу сказать лишь, что в рамках технического стандарта мы выполнили маппинг мер защиты на средства защиты информации. Так что любая компания холдинга, применяя наш технический стандарт, может не только сформировать перечень необходимых к реализации ей мер защиты, но и понять, какие средства защиты каких производителей необходимо применять. Причём так как по многим направлениям защиты применяются централизованные решения, возможна существенная экономия денег на закупках. Т. е. компании холдинга достаточно будет закупить только агентские решения и подключить их (по запросу в сервисную компанию) к серверам управления в ЦОД. Как минимум тратиться на компонент управления не придётся, к тому же управлять средствами защиты можно будет не самим, а доверить это дело сервисной компании холдинга, что позволит сэкономить на поиске, найме и выплате зарплаты профильным специалистам.

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

Результат работы по стандарту

Итак, что же получаем? А получаем, что у нас есть единый «источник правды», по которому любая компания холдинга может выбирать необходимые к реализации меры защиты с учётом специфики своих информационных систем (АСУ ТП) и ИТ-инфраструктуры. Более того, выбрав меры, компания сможет понять, какими средствами защиты эти меры реализовывать. При этом компания может сэкономить на закупке средств защиты, так как понимает, на каких площадках какие компоненты централизованных средств защиты развёрнуты (т. е. понимает, к каким компонентам можно просто подключиться, не тратя денег на их покупку).
Что же касается безопасников, то у них тоже жизнь упростилась. Во-первых, все теперь должны реализовывать требования Технического стандарта (в т. ч. при создании новых систем). Во-вторых, проще проводить проверки, когда определены меры защиты.

В Техническом стандарте очень много шаблонов отчётных форм, т. е. компаниям холдинга не надо придумывать, как документировать результаты работы по стандарту, все уже есть. Например, одно из приложений — форма Декларации применимости мер защиты. Это документ, в который вносятся все результаты работы по стандарту. Он представляет собой таблицу с указанием, какие меры защиты для каких ИС и АСУ ТП применяются, какими техническими решениями реализуются (для технических мер) и в каких внутренних нормативных документах описаны (для организационных мер).

Стандартом получилось несложно пользоваться, шаги там описаны. Пример. Допустим, у нас есть гостиница. Согласно требованиям процесса инвентаризации, она должна провести инвентаризацию активов и определить перечень функционирующих ИС и их критичность. Зная это, представитель ИБ берёт, смотрит, какие системы есть (например, есть ИСПДн с уровнем защищённости 4 и КТ), выбирает необходимые меры защиты, адаптирует и дополняет их (зная актуальные угрозы). Получает конечный набор мер защиты. Далее смотрит ещё в одну таблицу и получает набор средств защиты, необходимых к внедрению на его площадке. Вот и всё. Многие спросят: «А как быть с документами?» Процессы ИБ мы старались сделать централизованными, типовые локальные документы по ИБ для площадок тоже разработали. Разумеется, конкретным компаниям необходимо будет адаптировать документы, спущенные с головы, но это намного проще, чем писать с нуля.

Вместо заключения

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

Сами мы получившийся стандарт апробировали на ряде площадок.

В результате хаоса чуть убавилось, контроля прибавилось. Эффект ещё вырастет по мере закупки средств защиты информации (всё-таки 20 вендоров стандартизовали, и не всё было куплено на момент выпуска Технического стандарта ИБ) и окончательного внедрения процессов ИБ. При создании новых систем ожидаем, что всё будет обходиться без сюрпризов для ИБ.

Думаю, у вас тоже есть похожая документация. Многие стандартизуют только конкретные решения по ИБ без каких-либо методик по выбору таких решений. Некоторые стандартизуют конкретные меры (преимущественно на базе подходов ФСТЭК России или ЦБ РФ).

По адаптации применимости единого стандарта к дочерним организациям тоже много разных подходов. Кто-то вводит специальные уровни защищённости (не путать с уровнями защищённости в ИСПДн), потом делит компании в холдинге на эти уровни, и те по соответствующим уровням реализуют меры защиты. Кто-то все требования ко всем компаниям применяет. Кто-то — избирательно по юридическим лицам или типам компаний. Мы же решили попробовать поиграть с критичностью и типами объектов ИТ-инфраструктуры.

Касаемо мер защиты, подход с выбором мер из NIST, маппингом с требованиями российских регуляторов, добавлением блока по критичности систем показался нам хорошей практикой.

Если у вас есть вопросы по таким задачам, на которые можно отвечать только в частной переписке, то вот моя почта — MKoptenkov@technoserv.com.

Коптенков Михаил, начальник отдела аудита и консалтинга.