Есть у нас в 17-м и 21-м приказах ФСТЭК такая защитная мера как УПД.3 и звучит она как "Управление (фильтрация, маршрутизация, контроль соединений, однонаправленная передача и иные способы управления) информационными потоками между устройствами, сегментами информационной системы, а также между информационными системами". Для среды виртуализации есть требование аналогичное - ЗСВ.4 - "Управление (фильтрация, маршрутизация, контроль соединения, однонаправленная передача) потоками информации между компонентами виртуальной инфраструктуры, а также по периметру виртуальной инфраструктуры". Что значат эти требования? Как их реализовывать?
Одно из критических замечаний к обоим приказам ФСТЭК было именно то, что перечисленные защитные меры слишком высокоуровневые и не совсем понятно, как трактовать то или иное требование? Кстати, аналогичная высокоуровневость присуща и 382-П Банка России. Там также прописано общее требование, а механизм его реализации отдан на откуп самого участнику Национальной платежной системы. В случае с ФСТЭК на самотек ничего не пущено и сейчас готовится отдельный документ, который разъясняет, как можно реализовывать ту или иную защитную меру. Вспомните иерархию нормативных актов по защите госорганов в США. У нас, по ходу, идея такая же.
Что же понимают американцы под управлением информационными потоками (Information Flow Enforcement)? У них, ни много ни мало, а в SP800-53 21 механизм реализации этой защитной меры. Очко! Это у нас под управлением потоками часто и неправильно понимают только использование межсетевого экрана или его замены в виде списков контроля доступа на маршрутизаторах или VLAN'ов на коммутаторах. Но традиционное и слишком узкое восприятие термина "управление информационными потоками". В США это всего лишь последний, 21-й механизм - "physical/logical separation of information flows". Обратите внимание нет ни слова про межсетевые экраны, ACL, VLAN... Почему? Да потому что нельзя ограничить управление потоками только этими тремя мезанизмами. Это только в локальной сети Ethernet и на традиционном IP-периметре это сработает. А что делать в сетях хранения данных (SAN)? Там нет VLANов. Но там есть VSAN. Там есть soft/hard zoning. Там есть LUN masking. А в MPLS сетях какие механизмы управления потоками? VRF! А в виртуализированных средах? Там для управления потоками свои атрибуты безопасности, зачастую отличные от IP-адресов. В SP800-53 использование атрибутов безопасности - это самый первый механизм управления потоками. А работа с атрибутами - это вообще отдельная защитная мера, которая может быть реализована с помощью 12-ти различных механизмов. Но вернемся к управлению потоками. Что еще наши заокеанские "друзья" включили в свой "17-й приказ" (выборочно):
А ведь есть еще такое понятие как мандатное разграничение доступа на уровне сети. Разумеется, на самом деле оно называется не совсем так, но суть у него именно такая. На информационный поток вешается метка (security group tag, SGT), которая и позволяет управлять потоками в одной сетевой инфраструктуре, не давая им пересекаться, и являясь более гибкой и динамичной схемой, чем статические метки VLAN. Это управление информационными потоками? Да. Но, что тут сертифицировать? Тут нет одной железки, которая стоит на периметре? Тут вся инфраструктура осуществляет управление потоками. Физические и виртуальные коммутаторы, маршрутизаторы, точки беспроводного доступа, межсетевые экраны - все это и управляет потоками.
Кстати, идеология SGT показывает, что традиционный, периметро-ориентированный взгляд на управление потоками сегодня уже устарел. Есть периметр, на нем поставили МСЭ и вуаля - дело в шляпе. А как быть, когда у нас нет явно очерченного периметра или сегментация нужна внутри сети. Тут и помогает security group tagging, в этом случае у нас отсутствует одна точка контроля, как на периметре. А значит и подходы к оценке такого рода механизмов тоже надо менять. Причем как к оценке соответствия в форме сертификации, так и к оценке в форме аттестации. Прийти и спросить: "А где у вас тут стоит файрвол?" уже не получится.
А если пойти выше сетевого уровня и поговорить об управлении потоками в сети не физической, а виртуальной? Как реализовать меру ЗСВ.4 из 17-го и 21-го приказа? Нужны средства управление потоками в виртуализированной среде. Межсетевые экраны или виртуальные коммутаторы, которые с этой задачей справятся, но как видно из иллюстрации ниже, они не стоят на периметре. Есть варианты, когда виртуальный межсетевой экран ставится на каждый физический сервер. Есть варианты, когда виртуальный межсетевой экран просто ставится на виртуальную машину и он один контролирует трафик между другими виртуальными машинами на разных физических серверах (например, у нас так построен Cisco Virtual Security Gateway). Тут, главное, идеологию и мировозрение поменять - управление потоками может быть не только сетевым и не только на периметре.
А если посмотреть еще дальше - на SDN (программно конфигурируемые сети)? В них управление потоками и вовсем отделено от самих устройств и реализуется программно. Зачастую само прикладное приложение может управлять информационными потоками. И такой механизм тоже попадает под требования 17/21-го приказов. Вот только как их сертифицировать непонятно. По крайней мере, пока непонятно.
Вот такая картина вырисовывается только с одной из нескольких десятков защитных мер, предусмотренных новыми документами ФСТЭК. Очень глубокие документы и очень гибкие. Главное, чтобы ФСТЭК не загнала эти преимущества в жесткие рамки слишком приземленных требований и не стала требовать одинакого уровня сертификации для разного класса реализуемых механизмов управления потоками. Все-таки отдельно стоящий и выделенный под задачи безопасности межсетевой экран и функциональность сегментация виртуального коммутатора (например, Cisco Nexus 1000V) - это две большие разницы и предъявлять к ним одинаковые требования не совсем разумно. Более того, основная нагрузка смещается с отдельного устройства на уровень систем управления или отдельных контроллеров. Именно от того, что делается там зависит, как будут защищены информационные потоки. И это тоже надо будет учитывать как тем, кто будет реализовывать управление потоками, так и тем, кто будет проводить оценку соответствия или разрабатывать требования по оценке соответствия.
Одно из критических замечаний к обоим приказам ФСТЭК было именно то, что перечисленные защитные меры слишком высокоуровневые и не совсем понятно, как трактовать то или иное требование? Кстати, аналогичная высокоуровневость присуща и 382-П Банка России. Там также прописано общее требование, а механизм его реализации отдан на откуп самого участнику Национальной платежной системы. В случае с ФСТЭК на самотек ничего не пущено и сейчас готовится отдельный документ, который разъясняет, как можно реализовывать ту или иную защитную меру. Вспомните иерархию нормативных актов по защите госорганов в США. У нас, по ходу, идея такая же.
Что же понимают американцы под управлением информационными потоками (Information Flow Enforcement)? У них, ни много ни мало, а в SP800-53 21 механизм реализации этой защитной меры. Очко! Это у нас под управлением потоками часто и неправильно понимают только использование межсетевого экрана или его замены в виде списков контроля доступа на маршрутизаторах или VLAN'ов на коммутаторах. Но традиционное и слишком узкое восприятие термина "управление информационными потоками". В США это всего лишь последний, 21-й механизм - "physical/logical separation of information flows". Обратите внимание нет ни слова про межсетевые экраны, ACL, VLAN... Почему? Да потому что нельзя ограничить управление потоками только этими тремя мезанизмами. Это только в локальной сети Ethernet и на традиционном IP-периметре это сработает. А что делать в сетях хранения данных (SAN)? Там нет VLANов. Но там есть VSAN. Там есть soft/hard zoning. Там есть LUN masking. А в MPLS сетях какие механизмы управления потоками? VRF! А в виртуализированных средах? Там для управления потоками свои атрибуты безопасности, зачастую отличные от IP-адресов. В SP800-53 использование атрибутов безопасности - это самый первый механизм управления потоками. А работа с атрибутами - это вообще отдельная защитная мера, которая может быть реализована с помощью 12-ти различных механизмов. Но вернемся к управлению потоками. Что еще наши заокеанские "друзья" включили в свой "17-й приказ" (выборочно):
- Контроль использования зашифрованного трафика
- Контроль инкапсулированного трафика
- Контроль метаданных
- Однонаправленная передача (в индустриальных системах часто применяются такие межсетевые экраны, в которых на физическом уровне обеспечивается только односторонняя передача трафика. Она, кстати, упомянута в 17-м и 21-м приказах ФСТЭК)
- Использование фильтров безопасности (в качестве критериев применяется не только и не столько IP-адресация источника и получателя и не порты источника и получателя, а длина передаваемого файла, его тип или расширение, ключевые слова и т.п. Фильтры могут работать как со структурированными данными, так и с неструктурированными.
- Человеческий контроль (да-да, есть и такой механизм).
- И т.д.
А ведь есть еще такое понятие как мандатное разграничение доступа на уровне сети. Разумеется, на самом деле оно называется не совсем так, но суть у него именно такая. На информационный поток вешается метка (security group tag, SGT), которая и позволяет управлять потоками в одной сетевой инфраструктуре, не давая им пересекаться, и являясь более гибкой и динамичной схемой, чем статические метки VLAN. Это управление информационными потоками? Да. Но, что тут сертифицировать? Тут нет одной железки, которая стоит на периметре? Тут вся инфраструктура осуществляет управление потоками. Физические и виртуальные коммутаторы, маршрутизаторы, точки беспроводного доступа, межсетевые экраны - все это и управляет потоками.
Кстати, идеология SGT показывает, что традиционный, периметро-ориентированный взгляд на управление потоками сегодня уже устарел. Есть периметр, на нем поставили МСЭ и вуаля - дело в шляпе. А как быть, когда у нас нет явно очерченного периметра или сегментация нужна внутри сети. Тут и помогает security group tagging, в этом случае у нас отсутствует одна точка контроля, как на периметре. А значит и подходы к оценке такого рода механизмов тоже надо менять. Причем как к оценке соответствия в форме сертификации, так и к оценке в форме аттестации. Прийти и спросить: "А где у вас тут стоит файрвол?" уже не получится.
А если пойти выше сетевого уровня и поговорить об управлении потоками в сети не физической, а виртуальной? Как реализовать меру ЗСВ.4 из 17-го и 21-го приказа? Нужны средства управление потоками в виртуализированной среде. Межсетевые экраны или виртуальные коммутаторы, которые с этой задачей справятся, но как видно из иллюстрации ниже, они не стоят на периметре. Есть варианты, когда виртуальный межсетевой экран ставится на каждый физический сервер. Есть варианты, когда виртуальный межсетевой экран просто ставится на виртуальную машину и он один контролирует трафик между другими виртуальными машинами на разных физических серверах (например, у нас так построен Cisco Virtual Security Gateway). Тут, главное, идеологию и мировозрение поменять - управление потоками может быть не только сетевым и не только на периметре.
А если посмотреть еще дальше - на SDN (программно конфигурируемые сети)? В них управление потоками и вовсем отделено от самих устройств и реализуется программно. Зачастую само прикладное приложение может управлять информационными потоками. И такой механизм тоже попадает под требования 17/21-го приказов. Вот только как их сертифицировать непонятно. По крайней мере, пока непонятно.
Вот такая картина вырисовывается только с одной из нескольких десятков защитных мер, предусмотренных новыми документами ФСТЭК. Очень глубокие документы и очень гибкие. Главное, чтобы ФСТЭК не загнала эти преимущества в жесткие рамки слишком приземленных требований и не стала требовать одинакого уровня сертификации для разного класса реализуемых механизмов управления потоками. Все-таки отдельно стоящий и выделенный под задачи безопасности межсетевой экран и функциональность сегментация виртуального коммутатора (например, Cisco Nexus 1000V) - это две большие разницы и предъявлять к ним одинаковые требования не совсем разумно. Более того, основная нагрузка смещается с отдельного устройства на уровень систем управления или отдельных контроллеров. Именно от того, что делается там зависит, как будут защищены информационные потоки. И это тоже надо будет учитывать как тем, кто будет реализовывать управление потоками, так и тем, кто будет проводить оценку соответствия или разрабатывать требования по оценке соответствия.
