BIS Journal №1(36)/2020

3 апреля, 2020

«Перемен! – требуют наши сердца»

Для нынешнего этапа развития информационных систем, как корпоративных, так и государственных, характерно состояние осмысления: набралась «критическая масса» проектов информатизации с таким интегральным уровнем сложности, который требует радикальных мер для снижения этой сложности. По мнению Сергея Вихорева, слияние реального мира и мира ИТ уже произошло, и теперь законы, придуманные когда-то специально для виртуального мира ИТ, работают плохо. Сергей Викторович рассказал BIS Journal, почему пришла пора пересмотреть «нишевые» законы ИБ в сторону философских, общечеловеческих, взяв в качестве примера нынешний подход к созданию модели угроз – ключевого элемента, лежащего в основе требований ИБ к создаваемым ИТ-системам.

 

СЛИШКОМ ВИРТУАЛЬНАЯ СУЩНОСТЬ

- Модель угроз изначально задумывалась как некоторое комплексное описание. В чём Вы видите ограниченность принятого подхода?

- Я бы говорил, скорее, не об ограниченности модели, а о её неадекватности сегодняшним практическим задачам. Давайте вспомним, что в своё время вообще не было никаких жёстких требований, и практически каждый оператор (компания, которая работает с данными)  вырабатывал свои требования  самостоятельно, исходя из своего понимания угроз безопасности информации. Это был, образно говоря, «индпошив» моделей для каждого оператора. Потом пришла «промышленная» эпоха: появились определённые требования к конкретным классам защищённости, классификация информационных систем. Собственно, всё множество приказов ФСТЭК России. Но там везде в них декларируется: необходимость выбора требований на основе модели угроз. Вот только процедура выбора требований не включает моделирования угроз как конкретное действие. Модель оказывается этакой «бестелесной» сущностью, которая парит над требованиями, не касаясь их своими «крыльями». Вот пример из приказа ФСТЭК № 17 (Рисунок 1).

Рисунок 1. Пример из приказа ФСТЭК № 17

 

- Вы считаете это недостатком?

- Сама идея - использовать модель угроз при формировании требований абсолютно верная. Однако, не отрицая важности самого процесса оценки угроз безопасности информации при выборе адекватных мер защиты, необходимо отметить, что многолетняя практика моделирования угроз для каждого конкретного объекта показывает свою неэффективность. Потому что у оператора, как правило, нет специалистов, которые обладают достаточной компетенцией для правильного проведения анализа факторов, влияющих на реализацию угрозы. В связи с этим процесс моделирования зачастую носит формальный характер и не отражает реального положения дел, а разрабатываемые модели угроз мало способствуют оптимальному выбору необходимых средств защиты. Они просто не находят практического применения («документ ради документа»), так как критерии выбора средств защиты слабо увязаны с критериями оценки угроз. Производители средств защиты ориентируются не на угрозы безопасности информации, а на реализацию функций безопасности, оставляя выбор необходимых функций оператору. Но на уровне практической реализации возникает ситуация, которую я называю «парадокс свободы выбора».

 

- В чём заключается парадокс?

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

 

- Все участники процесса, вроде, решают одну большую задачу?

- Да, в этом есть единство: все обеспечивают решение одной задачи – создание надёжно защищённой информационной системы. Но мои задачи как конструктора системы защиты и задачи вендора инструментов ИБ – диаметрально противоположны. Производители хотят максимально универсализировать задачу, снабдив продукт максимальным количеством всяческих функций. Это мы видим на рынке: появляются умные межсетевые экраны, которые уже включают не только функции фильтрации, но и DLP-систему, и систему обнаружения вторжений, и антивирусное ПО и многое другое. А у меня обратная задача – я хочу иметь конкретное средство, точно нацеленное на мои конкретные требования. Двух одинаковых информационных систем нет, каждая уникальна по-своему! Но и средств защиты, покрывающих мой уникальный набор требований защиты, тоже нет! Эту ситуацию я и назвал парадоксом свободы выбора: я должен либо построить неоптимальную систему, но которая будет соответствовать требованиям. Либо я должен построить оптимальную систему, которая не будет соответствовать требованиям.

 

- Стандарт общих критериев ГОСТ Р ИСО/МЭК 15408 имеет в виду, в конечном итоге, некий механизм выработки индивидуальных профилей защиты. Разве нет?

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

 

- Почему?

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

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

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

 

ПРИНЦИП ХОЛИЗМА И МОДЕЛЬ УГРОЗ

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

- Принцип холизма здесь ярко проявляется. Сейчас происходит именно так: например, для каждой системы, обрабатывающей персональные данные (а их у оператора может быть несколько), строится своя отдельная модель. А теперь давайте посмотрим на архитектуру ЦОД: на одной инфраструктуре сидит несколько различных информационных систем. Причем, каждая использует одно и то же серверное оборудование, одни и те же коммутаторы и средства сегментирования. Работаем с частным, не видим общего!

Способы сегментирования сети стремительно развиваются: сначала использовались мосты, потом маршрутизаторы (коммутаторы третьего уровня), дальше на смену подходу, основанному на физическом ограничении сетей и применении маршрутизаторов для организации связи между сегментами, пришла технология построения виртуальных сетей VLAN. Более того, виртуальные конструкции типа контейнеров вообще являются чисто логическими объектами, физически относящимися к одному и тому же оборудованию. Имеет ли смысл создать различные модели угроз, относящиеся к различным ИС, если, по сути, все они – лишь виртуальные семантические сущности?

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

 

- Но для этого, прежде всего, нужно понять, где в нынешней ИТ-инфраструктуре у нас целое, а где – частное. Что здесь целое, а что частное?

- На одном гипервизоре может быть развёрнуто N-ое количество информационных систем. Что тогда мы должны защищать? В каждом конкретном случае – гипервизор, но по-своему? Абсурд. Получается, что надо защитить инфраструктуру, на которой развёрнут этот гипервизор, это в философском смысле целое. Кстати, это направление прослеживается в некотором смысле в новой редакции приказа ФСТЭК России  № 17 от 11 февраля 2013 г. В частности, применительно к инфраструктуре ЦОД, в котором размещается ГИС, указывается, что  класс защищённости ЦОД должен быть не ниже класса, требуемого для ГИС. И этот посыл очень правильный, я считаю.

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

 

ИТ-ИНФРАСТРУКТУРА КАК КЛЮЧЕВОЙ ЭЛЕМЕНТ МОДЕЛИ ЗАЩИЩЁННОСТИ

- Получается, что нужно переходить к модели защищённости ЦОД?

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

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

 

- Звучит парадоксально. Получается, что именно ИТ-ландшафт – это ключевой элемент системы защиты современных ИТ-систем?

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

Раньше мы говорили о сегментировании сети. Принцип сегментирования: разделяй и властвуй, - это, действительно, один из важнейших принципов защиты информации. И мы добивались разграничения доступа к информации именно с помощью выделения сегментов, и эти сегменты были физическими: отдельные серверы, отдельные базы данных и проч. А теперь у нас совсем другая конструкция: есть некоторая платформа, и на этой платформе работает, например,  ERP-система или СУБД. Вообще-то произошла некоторая революция: мы, скажем так, разсегментировали сеть и начали оперировать некоторыми семантическими сущностями. Что теперь мы должны защищать?

 

- СУБД?

- Зачем защищать саму по себе СУБД? Мы защищаем информацию! Если в компьютере нет никакой информации, то сам по себе он имеет некоторую материальную ценность, но не более того.

 

«ИДЕАЛЬНАЯ» ИНФОРМАЦИЯ С ПОЗИЦИЙ ЗАЩИТЫ

- Конечно, виртуальная информация имеет материальную составляющую. Например, она нагружена содержанием, смыслом, то есть имеет семантическую ценность. Она виртуальная, но мы можем ощутить ее ценность – она выражается, например, в конкретном количестве денежных знаков. Нужно определиться с философскими понятиями идеального и материального и решить, что мы защищаем: материальную ценность информации или идеальное понятие информации?

- Природа информации загадочна. Норберт Винер, отец мировой кибернетики, говорил так: «Информация – это не энергия и не материя, информация – это информация». Информация - это, действительно, уникальный предмет, который одновременно содержит в себе и идеальное и материальное начало. Этакий дуализм. С точки зрения двойственной материальной и идеальной природы информации, я бы сказал так: в философском смысле она идеальна, но проявляет свои свойства, циркулируя в определённой среде. Вот почему мы  должны защищать именно ту материальную среду, в которой проявляет себя -  циркулирует - информация.

 

О ТОМ, КОГДА ИС ЗАЩИЩАТЬ НЕ НУЖНО

- Есть идеи, как к этому подойти?

- Идея так называемой доверенной среды.

 

- Поясните, пожалуйста, на примере. Например, я владелец бизнеса. Арендую в ЦОДе пару виртуальных серверов и размещаю там несколько своих ИТ-систем. Вы отвечаете в компании за ИБ. Как Вы будете строить систему защиты?

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

 

- Как такой подход меняет весь механизм решения задачи обеспечения защищённости?

- Думаю, на уровень конкретных регламентов сейчас уходить не стоит. Это отдельная и довольно большая тема. Скажу только, что всё будет проще.

 

- За счёт чего?

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

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

Первое, что мы должны обеспечить, это защита ЦОД. Затем - защита канала. А ещё мы должны контролировать, чтобы на конкретном рабочем месте не произошло никаких изменений без нашего ведома. Чтобы было установлено только то программное обеспечение, которое должно быть, чтобы оно вовремя обновлялось и всегда оставалось в полном порядке. Образно говоря, нужные порты открыты, ненужные закрыты. Всё это мы должны контролировать. 

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

 

- Завершая разговор, скажите, на чём, на Ваш взгляд, сегодня нужно сфокусировать внимание?

- Сейчас нужно пересмотреть традиционные подходы к защите информации через призму более общих философских законов. Мир един, и нужно учиться применять  к проблемам защиты информации философские законы общечеловеческого плана. Один из ярких тому примеров - модель угроз. Мы видим, что если правильно применить общие философские законы, становится очевидным: нам не нужно строить 10 или 50 моделей угроз. Нам нужна одна модель угроз – для инфраструктуры. А это означает экономию времени и средств для обеспечения защиты информации.

 

- За счёт того, что такая модель упрощает ситуацию?

- Да. Меняется всё окружение, и срабатывает принцип диалектического единства: модель – проще, реализация защищённости – проще. Ведь информационная система, которая находится на этой инфраструктуре, уже полностью соответствует требованиям всей этой инфраструктуры. Она изначально защищена инфраструктурно. В этом и есть философская составляющая рассматриваемой проблемы. С одной стороны – онтологический холизм, то есть верховенство целостности перед отдельными элементами. С другой стороны, закон единства и борьбы противоположностей. С третьей стороны, метод дедукции - от общего к частному.

Смотрите также