Что же должны уметь межсетевые экраны по мнению ФСТЭК?
Согласно Информационному сообщению «Об утверждении методических документов, содержащих профили защиты межсетевых экранов» от 12 сентября 2016 г. N 240/24/4278 разработаны Профили защиты типов:
- межсетевой экран уровня сети (тип «А») – межсетевой экран, применяемый на физической границе (периметре) информационной системы или между физическими границами сегментов информационной системы. Межсетевые экраны типа «А» могут иметь только программно-техническое исполнение;
- межсетевой экран уровня логических границ сети (тип «Б») – межсетевой экран, применяемый на логической границе (периметре) информационной системы или между логическими границами сегментов информационной системы. Межсетевые экраны типа «Б» могут иметь программное или программно-техническое исполнение;
- межсетевой экран уровня узла (тип «В») – межсетевой экран, применяемый на узле (хосте) информационной системы. Межсетевые экраны типа «В» могут иметь только программное исполнение и устанавливаются на мобильных или стационарных технических средствах конкретного узла информационной системы;
- межсетевой экран уровня веб-сервера (тип «Г») – межсетевой экран, применяемый на сервере, обслуживающем сайты, веб-службы и веб-приложения, или на физической границе сегмента таких серверов сервера). Межсетевые экраны типа «Г» могут иметь программное или программно-техническое исполнение и должны обеспечивать контроль и фильтрацию информационных потоков по протоколу передачи гипертекста, проходящих к веб-серверу и от веб-сервера;
- межсетевой экран уровня промышленной сети (тип «Д») – межсетевой экран, применяемый в автоматизированной системе управления технологическими или производственными процессами. Межсетевые экраны типа «Д» могут иметь программное или программно-техническое исполнение и должны обеспечивать контроль и фильтрацию промышленных протоколов передачи данных (Modbus, Profibus, CAN, HART, Industrial Ethernet и (или) иные протоколы).
Для типов А, Б и В имеются требования к межсетевым экранам от первого до шестого класса защиты, для типов Г и Д — только от шестого до четвертого
Прежде всего об уровнях защищенности. Согласно Информационному сообщению «Об утверждении Требований к межсетевым экранам» от 28 апреля 2016 г. No 240/24/1986.
Межсетевые экраны, соответствующие 6 классу защиты, применяются в государственных информационных системах 3 и 4 классов защищенности*, в автоматизированных системах управления производственными и технологическими процессами 3 класса защищенности**, в информационных системах персональных данных при необходимости обеспечения 3 и 4 уровней защищенности персональных данных***.
Межсетевые экраны, соответствующие 5 классу защиты, применяются в государственных информационных системах 2 класса защищенности*, в автоматизированных системах управления производственными и технологическими процессами 2 класса защищенности***, в информационных системах персональных данных при необходимости обеспечения 2 уровня защищенности персональных данных**
Межсетевые экраны, соответствующие 4 классу защиты, применяются в государственных информационных системах 1 класса защищенности*, в авто матизированных системах управления производственными и технологическими процессами 1 класса защищенности**, в информационных системах персональных данных при необходимости обеспечения 1 уровня защищенности персональных данных***, в информационных системах общего пользования II класса****.
Межсетевые экраны, соответствующие 3, 2 и 1 классам защиты, применяются в информационных системах, в которых обрабатывается информация, содержащая сведения, составляющие государственную тайну.
* Устанавливается в соответствии с Требованиями о защите информации, не составляющей государственную тайну, содержащейся в государственных информационных системах, утвержденными приказом ФСТЭК России от 11 февраля 2013 г. No17.
** Устанавливается в соответствии с Требованиями к обеспечению защиты информации в автоматизированных системах управления производственными и технологическими процессами на критически важных объектах, потенциально опасных объектах, а также объектах, представляющих повышенную опасность для жизни и здоровья людей и для окружающей природной среды, утвержденными приказом ФСТЭК России от 14 марта 2014 г. No 31.
*** Устанавливается в соответствии Требованиями к защите персональных данных при их обработке в информационных системах персональных данных, утвержденными постановлением Правительства Российской Федерации от 1 ноября 2012г., No 1119.
**** Устанавливается в соответствии с Требованиями о защите информации, содержащейся в информационных системах общего пользования, утвержденными приказом ФСБ России и ФСТЭК России от 31августа 2010 г. No 416/489.
Можно предсказать, что как в случае с антивирусами сертифицированных продуктов для классов защиты ниже четвертого не будет. Поэтому рассмотрим Профиль защиты для четвертого класса защиты. Нужно сказать, что требования для всех типов достаточно похожи, поэтому для примера требований возьмем Профиль типа В (если будет интерес, можно будет добавить отличия для иных типов). Данный профиль доступен здесь
Что есть межсетевой экран согласно Профилю?
программное средство, реализующее функции контроля и фильтрации в соответствии с заданными правилами проходящих через него информационных потоков.
Согласно Профилю МЭ должен противодействовать следующим угроза безопасности информации:
- несанкционированный доступ к информации, содержащейся в информационной системе в связи с наличием неконтролируемых сетевых подключений к информационной системе;
- отказ в обслуживании информационной системы и (или) ее отдельных компонентов в связи с наличием неконтролируемых сетевых подключений, уязвимостями сетевых протоколов, недостатками настройки механизмов защиты, уязвимостями в программном обеспечении программно-аппаратных средств ИС. Здесь интересен способ реализации угрозы — «установление не предусмотренных технологией обработки информации в информационной системе сетевых соединений с информационной системой и (или) ее отдельными компонентами для отправки множества сетевых пакетов (запросов) до заполнения ими сетевой полосы пропускания канала передачи данных или отправки специально сформированных аномальных сетевых пакетов (запросов) больших размеров или нестандартной структуры». Получается, что МЭ должен иметь средства защиты от DDoS? Странно, что иных возможностей реализации угрозы установления неразрешенных соединений нет;
- несанкционированная передача информации из информационной системы в информационно-телекоммуникационные сети или иные информационные системы в связи с внедрением вредоносного программного обеспечения для несанкционированной отправки защищаемой информации на средства вычислительной техники нарушителя или отправкой защищаемой информации на средства вычислительной техники нарушителя пользователем информационной системы;
- несанкционированное воздействие на МЭ, целью которого является нарушение его функционирования, включая преодоление или обход его функций безопасности в связи с отправкой специально сформированных сетевых пакетов на интерфейсы МЭ.
В том числе в МЭ должны быть реализованы следующие функции безопасности:
- контроль и фильтрация;
- идентификация и аутентификация;
- регистрация событий безопасности (аудит);
- обеспечение бесперебойного функционирования и восстановление;
- тестирование и контроль целостности;
- управление (администрирование);
- взаимодействие с другими средствами защиты информации — сертифицированными на соответствие требованиям безопасности информации по соответствующему классу защиты.
Раскроем эти требования более подробно:
- МЭ должен «осуществлять фильтрацию сетевого трафика для отправителей информации, получателей информации и всех операций перемещения контролируемой МЭ информации к узлам информационной системы и от них». При этом фильтрация должна распространяться «на все операции перемещения через МЭ информации к узлам информационной системы и от них». Если первая часть требований вполне логична, то вторая утопична, так как требует раскрытия файрволом всех протоколов и любых недокументированных возможностей перемещения информации (например передачи информации вредоносными программами через DNS).
Интересно, что в разделе FW_ARP_EXT.2 уточняется, что МЭ должен иметь возможность по блокированию неразрешенного информационного потока по протоколу передачи гипертекста — о иных протоколах нет указаний. Должен ли МЭ блокировать передачу информации по ним? Кстати вполне возможно, что данный пункт попал в документ из Профиля типа Г — там достаточно много внимания уделяется именно этому протоколу;
- МЭ должен осуществлять фильтрацию по следующим признакам: сетевой адрес узла отправителя, сетевой адрес узла получателя, сетевой протокол, транспортный протокол, порты источника и получателя в рамках сеанса (сессии), разрешенные (запрещенные) команды, разрешенный (запрещенный) мобильный код, разрешенные (запрещенные) протоколы прикладного уровня. МЭ также должен иметь возможность «осуществлять политику фильтрации пакетов с учетом управляющих команд от взаимодействующих с МЭ средств защиты информации других видов». Также МЭ должен иметь возможность определять ПО, осуществляющее соединения и назначать для него разрешительные и (или) запретительные атрибуты безопасности с целью последующего осуществления фильтрации;
- МЭ должен иметь «возможность осуществлять проверку каждого пакета по таблице состояний для определения того, не противоречит ли состояние (статус, тип) пакета ожидаемому состоянию»;
- МЭ должен иметь «возможность осуществлять проверку использования сетевых ресурсов, содержащих мобильный код, для которого администратором МЭ установлены разрешительные или запретительные атрибуты безопасности». Означает ли это, что МЭ должен иметь возможность удаленной проверки сетевых ресурсов ", содержащих отдельные типы мобильного кода "? Странное требование, применимое больше к антивирусам. Скорее всего это должна выть отдельная операция, производимая по запросу. По результатам проверки МЭ должен иметь возможность разрешать и запрещать доступ к таким ресурсам;
- МЭ должен иметь «возможность разрешать/запрещать информационный поток, основываясь на результатах проверок». Не уточняется, на основании каких проверок должен запрещаться или разрешаться информационный поток. Логично было бы, если бы запреты или разрешения были на уровне предопределенных правил;
- МЭ должен иметь как возможность регистрации и учета выполнения проверок информации сетевого трафика, так и возможность чтения таких записей — в том числе с возможностью использования поиска и фильтрации. В соответствии с Профилем должны регистрироваться события ", которые в соответствии с национальным стандартом Российской Федерации ГОСТ Р ИСО/МЭК 15408-2-2013 «Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные компоненты безопасности» включены в базовый уровень аудита";
- МЭ должен поддерживать роли администраторов и возможность идентификации и аутентификации администратора для выполнения разрешенных данному администратору действий;
- МЭ должен иметь возможность создания и назначения различных профилей (настроек);
- МЭ должен иметь возможность ведения таблицы состояний каждого соединения с указанием его статуса;
- МЭ должен иметь «возможность обеспечения перехода в режим аварийной поддержки, который предоставляет возможность возврата МЭ к штатному режиму функционирования» и «возможность тестирования (самотестирования) функций безопасности МЭ (контроль целостности исполняемого кода МЭ)»;
- МЭ должен иметь «возможность осуществлять выдачу предупреждающих сообщений пользователю МЭ», позволяющих возможность «осуществить блокирование доступа к средству вычислительной техники».
В общем все. Требования к функционалу заканчиваются на странице 28 и до конца документа (размером в 78 страниц) идут повтор ранее написанного и требования к процедурам по выпуску, документированию и поддержке ПО.
В профиле указывается, что функциональные требования безопасности для МЭ составлены на основе требований ГОСТ Р ИСО/МЭК 15408-2-2013 «Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные компоненты безопасности» и достаточно сильно напоминают требования Профилей антивирусной защиты.
К сожалению в открытую часть не попали схемы, указывающие, где должен располагаться сертифицированный МЭ типа В. Но даже из списка функционала видно, что защита домашних машин пользователей, мобильных пользователей, а также защита мобильных устройств ФСТЭК'ом на данный момент не рассматривается.
В связи с тем, что МЭ, предназначенные для защиты рабочих станций и попадающие под тип В часто имеют функционал защиты от вторжений, интересно иметь требования и к этому функционалу. В рассмотренных Профилях таких требований нет, но они есть в Методическом документе ФСТЭК «Меры защиты информации в государственных информационных системах». Согласно данному документу МЭ:
- антивирусная защита и защита от спама должны применяться на средствах межсетевого экранирования (требования АВЗ.1 и ОЦЛ.4);
- в информационной системе должна осуществляться кластеризация средств защиты информации (в случаях, когда это технически возможно), включая средства межсетевого экранирования;
- обнаружение (предотвращение) вторжений должно осуществляться на внешней границе информационной системы (системы обнаружения вторжений уровня сети) и (или) на внутренних узлах (системы обнаружения вторжений уровня узла) сегментов информационной системы (автоматизированных рабочих местах, серверах и иных узлах), определяемых оператором
Указывается, что средства защиты от вторжений должны иметь возможность анализа трафика, обновления правил и централизованного управления. Правила должны иметь возможность редактирования.
Итого, что мы имеем? На первый взгляд базовая функциональность персонального файрвола описана. Но:
- Несмотря на то, что данный тип МЭ должен применяться в составе информационной системы — требований по централизованному управлению нет. Требуется только обеспечить доверенный канал управления в составе среды функционирования. Напомним, что в профилях антивирусных решений есть отдельные профили для централизованно управляемых решений и для отдельно стоящих;
- Несмотря на требование по фильтрации соединений от конкретных приложений — нет требований по наличию баз профилей приложений. Без таких баз правил администратору придется настраивать каждое новое соединение. Не есть хорошо и удобно;
- Нет требований по режимам работы — все запрещено/разрешено/режим обучения. Предполагается настраивать каждое соединение по одному?;
- Нет списка контролируемых протоколов. Упоминается только один — HTTP. Скажем как контролировать соединения по разрешенным протоколам (типа DNS), нужно ли фильтровать соединения, инкапсулирующиеся в разрешенные протоколы — вопросов много;
источник картинки
- Нет требований по функционалу защиты от сетевых атак. Естественно ожидать внутри сети DDoS не стоит, но уведомления от скажем перебора портов вещь не слишком ненужная. По сути сейчас большинство персональных файрволов имеют такой функционал. Вопрос не праздный. За любую сертификацию берут деньги — и достаточно большие. Но об этом чуть ниже;
- Несмотря на требование наличия процедур обновления — в функционале нет требований по наличию функций обновлений. Не будем говорить об уязвимостях, но те же вредоносные программы не стоят на месте и список используемых ими протоколов изменяется;
- Совершенно непонятное требование по взаимодействию с иными средствами защиты. Единого протокола для средств защиты нет — хотя производители тех же SIEM от него не отказались бы. Возможно это требование под конкретный продукт? Возможно это требование под МЭ с антивирусным плагином. Но такие продукты не составляют большинство на рынке. Как правило дело обстоит наоборот — для защиты станций ставятся антивирусы с модулем файрвола;
- Сообщения должны отправляться пользователям. Зачем они им в корпоративной сети? Обычно такие уведомления идут администраторам, а для пользователей скрываются. Нет требований по типам уведомлений администраторам — или они должны по мнению ФСТЭК круглосуточно сидеть за мониторами рабочих станций, ожидая уведомлений?
По требованиям ФСТЭК с 1 декабря 2016 г. разрабатываемые, производимые и поставляемые межсетевые экраны должны соответствовать описанным в Профилях требованиям. Межсетевые экраны, установленные до 1 декабря 2016 г., могут эксплуатироваться без проведения повторной сертификации на соответствие требованиям.
И тут потребителей ожидает засада. До выхода Профилей для защиты рабочих станций можно было использовать сертифицированный антивирус, в составе которого шел файрвол — как компонент антивируса тоже сертифицированный. Теперь так нельзя. Получается или производителям антивируса платить еще одну стоимость сертификации (и отбивать ее конечно) — а дальнейшем возможно и еще одну за СОВ или пользователям покупать три отдельных продукта — и тем самым требовать от руководства увеличения бюджета. Возможности для производителей антивирусов расширить сертификат не предусмотрено, а значит вариантов не так много:
- закладывать в бюджет средства и на сертифицированный антивирус и на сертифицированный МЭ;
- продлить ранее купленный сертифицированный антивирус на много лет вперед, так как ранее закупленные МЭ могут продолжать использоваться;
- надеяться, что ФСТЭК одумается.
Пячаль в любых вариантах.
До 1 декабря осталось немного, интересно, кто успеет провести сертификацию
Комментарии (41)
OlegAndr
28.09.2016 13:05До выхода Профилей для защиты рабочих станций можно было использовать сертифицированный антивирус, в составе которого шел файрвол — как компонент антивируса тоже сертифицированный.
— Каким это образом было можно так делать? Это явно не запрещалось большими буквами для тупых, но никак вы не могли в модели угроз указать что у вас антивирусную защиту осуществляет компонент МЭ, не имеющий сертификацию на САВЗ.
Но видимо многие талантливые люди так делали, потому что Лютиков особенно негодовал и настаивал на включении этого пункта в докуемнты. В итоге теперь разработчики попали на необходимость физического разделения модулей и вырезания вспомогательных модулей из сертифицируемого продукта…
Возможности для производителей антивирусов расширить сертификат не предусмотрено
— опять же кто это сказал.
teecat
28.09.2016 13:16Именно так, поскольку требований по персональным файрволам не было, то молча разрешалось использование компонента сертифицированного антивируса. На самом делен все было не так страшно. Дело в том, что сертификация по Профилям включает проверку на НДВ. Соответственно файрвол был как минимум сертифицирован по НДВ
Расширить сертификат можно в процессе ИК, но расширить по функционалу. Включить соответствии иным парофилям — такой процедуры насколько мне известно нетOlegAndr
28.09.2016 17:12Вы не правы по всем пунктам.
teecat
28.09.2016 17:31Процедура сертификация по профилям антивирусной защиты включает тестирование на отсутствие недекларируемых возможностей. Это как бы прописано в требованиях. Тех же Профилях
Если продукт сертифицирован на соответствие одному типу Профилей, то в ходе ИК можно добавить иной класс или уровень защиты этого типа Профилей, но не соответствие иному Профилю, так как сертификация производится на соответствие конкретному Профилю
В чем я не прав?
teecat
28.09.2016 13:11Естественно сделать можно все. Вопрос сколько будет это стоить. Теоретически можно разобрать любые протоколы и собрать любую информацию. По факту же, если скажем злоумышленники найдут возможность передачи информации через использование стандартного протокола (на уровне пакетов или инкапсуляцией) — сможет используемый файрвол без обновлений отфильтровать ранее неизвестный путь выхода или входа?
OlegAndr
28.09.2016 13:15p.s. Схемы были в презентации на зимнем ТБФоруме.
teecat
28.09.2016 13:18Это не те схемы. В ДСПшной части хорошие схемы, где расписаны где и что по типам нужно ставить. Не понимаю, что там страшного в открытии таких схем.
imbasoft
28.09.2016 13:32Остальные классы защиты описываются в документах с грифом ДСП и широкой публике недоступны.
МЭ 1-3 классы для защиты государевой тайны, а следовательно и не должны публиковать в открытом доступе, так как данные сведения в соответствии с законом о гос. тайне — должны являться гос. тайной.
Можно предсказать, что как в случае с антивирусами сертифицированных продуктов для классов защиты ниже четвертого не будет.
Далеко не факт. Различия между классами есть достаточно существенные, а с учетом что подавляющие большинство информационных систем персональных данных (ИСПДн) имеет 3-й уровень защищенности, то МЭ 6 класса вполне хватит для защиты перс. данных в общем случае.
Поэтому рассмотрим Профиль защиты для четвертого класса защиты. Нужно сказать, что требования для всех типов достаточно похожи, поэтому для примера требований возьмем Профиль типа В
Различия в требованиях есть и они довольно существенны, например в МЭ А4 требуется маскирование сетевых адресов, да и само описание требований, если читать имеет различия.
К сожалению в открытую часть не попали схемы, указывающие, где должен располагаться сертифицированный МЭ типа В.
А как вы хотели чтоб они попали? У всех сети разные. Требования о наличии МЭ указаны в нормативных документах, например приказы ФСТЭК 17 и 21, во исполнении этих приказов разрабатывается Тех. задание на систему защиты, в котором и указывается размещение МЭ
Получается, что МЭ должен иметь средства защиты от DDoS?
Кроме DDoS разве нет атак на отказ в обслуживании? А TCP Syn flood?
Касательно настроекНет требований по режимам работы — все запрещено/разрешено/режим обучения. Предполагается настраивать каждое соединение по одному?;
Сертифицированные СЗИ настраиваются в соответствии с ТЗ, в котором прописаны все разрешенные информационные потоки. Предпроектная стадия в профилях защиты не рассматривается, да и в общем не должна рассматриваться для данного уровня доверия (ОУД3).
И тут потребителей ожидает засада. До выхода Профилей для защиты рабочих станций можно было использовать сертифицированный антивирус, в составе которого шел файрвол — как компонент антивируса тоже сертифицированный.
Такого не было и раньше. Если по вашему проекту защиты требовалось применение МЭ, то вы должны были использовать средство защиты информации (СЗИ), на которое есть формуляр в котором указан номер сертификата, в кортом в свою очередь указано что это сертифицированный МЭ. Хочу отметить что раньше были сертифицированные СЗИ имеющие сертификат как антивирус, как МЭ и как СОВ. Но это ни в коем случае не обозначает что можно использовать сертифицированный антивирус как МЭ
Пячаль в любых вариантах.
Странный вывод, Сертифицированные СЗИ могут использоваться до окончания сроков действия сертификатов, так есть и было всегда. Постулат об использование одного типа СЗИ как другого (антивирус как МЭ) вообще не выдерживает критики.
А вообще ФСТЭК молодцы. Да в документах есть баги, да и в общей системе классификации экранов тоже есть нюансы, например почему выделили МЭ типа «Г» для веб-серверов, но не сделали отдельный тип для SQL-серверов. Есть мнение что, планировалось описать МЭ уровня приложений, но по каким-то причинам сделать это не удалось. Но! Данные требования к МЭ являются существенным шагом вперед по сравнению с документами 1995 г.
teecat
28.09.2016 13:45например в МЭ А4
Вот что зря попало в ДСП, так это таблицы по функционалу по классам и уровням защиты. Я не против помещения части информации под ДСП — закон есть закон. Но на мой взгляд часть информации можно было вынести для наглядности.
Сертифицированные СЗИ настраиваются в соответствии с ТЗ, в котором прописаны все разрешенные информационные потоки
Это утопия:
— специалисты на местах не знают как скажем сейчас шифровальщики выходят в интернет. Я бы бы очень за, если бы ФСТЭК поддерживал актуальную модель угроз, по которой можно было бы создавать и поддерживать такое ТЗ. ПО факту же такое ТЗ с учетом не только информационных потоков организации, но и методов работы злоумышленников сейчас отсуствует
— на местах квалификация администраторов недостаточна, чтобы провести полноценный аудит. Увы
Хочу отметить что раньше были сертифицированные СЗИ имеющие сертификат как антивирус, как МЭ и как СОВ
Возможно я что-то пропустил. Какие сертифицированные МЭ были для рабочих станций?
Сертифицированные СЗИ могут использоваться до окончания сроков действия сертификатов
Я собственно против этого ничего не имею. Я говорю про то, что необходимость иметь два сертифицированных продукта вместо одного — это рост размера бюджета, тогда как по регионам он на этот год срезан процентов на 20
imbasoft
28.09.2016 14:14Это утопия:
— специалисты на местах не знают…
— на местах квалификация администраторов недостаточна ...
Это не утопия, это нормальная работа. Другое дело, что за квалификацию нужно платить. Специалисты на местах, администраторы должны имееть соответвующее образование. Просто админ не имеет права заниматься обеспечением ИБ (у госиков),
Возможно я что-то пропустил. Какие сертифицированные МЭ были для рабочих станций?
Как минимум VIPNET, Континент-АП
Сам пользовался http://www.securitycode.ru/products/security_studio_endpoint_protection/ но тут тру печаль, Outpost купил Яндекс, данный продукт походу свернули. На этот софт были самые лучшие сертификаты — как АВ, СОВ и МЭ
Я говорю про то, что необходимость иметь два сертифицированных продукта вместо одного — это рост размера бюджета
,
Еще раз повторюсь, так было всегда.teecat
28.09.2016 14:49Полностью согласен, что за квалификацию нужно платить — с чем сейчас на рынке проблемы. Я не спорю с тем, что должно быть. Я говорю, что по факту.
Но даже если есть бюджет — этого мало — нужны знания. Те же методики, курсы, типовые модели угроз. А их сейчас на рынке в области ИБ по сути нет. Теоретически они конечно есть, но я лично не видел ни одной нормальной модели угроз в части вредоносных файлов. Если у вас есть — готов проверить — скидывайте в личку. По моей статистике 19 из 20 организаций не знают вообще о неизвестных угрозах и назначении антивируса
Аутпост действительно был. С удовольствием пользовался. Жаль.
imbasoft
28.09.2016 16:02Курсы нормальные есть, надо просто понять что вам нужно.
Если нужны знания нормативки и методик: УЦ МАСКОМ, Информзащита, АИС, Сюретль — welcome получите корочки которые подойдут для регуляторов.
Если нужно качнуть практическую безопасность — PentestIT, кстати они есть на Хабре или буржуйские CEH и др.
Главное понимать что за один курс невозможно стать и специалистом по методикам и практическим безопасником.
По моей статистике 19 из 20 организаций не знают вообще о неизвестных угрозах и назначении антивируса
Очень хотелось бы работать в организации которая знает о неизвестных угрозах, пока что все живем в мире известного :)
но я лично не видел ни одной нормальной модели угроз в части вредоносных файлов.
И не уведите, так как предметом для моделей является вредоносный код, а не вредоносный файл. Для понимания разницы можно ознакомиться с описанием вируса slammer — это первое.
Второе, а что в этой модели вы хотите увидеть? Перечисление всех зловредов? Классификацию зловредов?
Это делать бесполезно — даказано историей. Все классификации вирусов, которые когда либо пытались сделать на практике рушатся, поскольку вирусмейкерам глубоко плевать, что их творение не вписываеться в те рамки, которые им придумали «умные дяди».
На практике, вредоносный код рассматривается как абстракция, которая имеет функционал нарушающий свойства безопасности информации (целостность, доступность и т.д.).
Детализироваться внутрь особого практического смысла не имеет, поскольку по сути нет разницы зашифрует ли ваши данные вирус, или же уничтожит или перешлет куда либо, главное что будут нарушены свойства безопасности информации, для поддержания которых и строится система защиты.
Современная практика обеспечения защиты от вредоносного кода базируются на борьбе с проникновением и выполнением вредоносного кода на защищаемом объекте, в вот это достигается уже большим числом способов. Начиная с антивирусов, организацией замкнутой программной среды, блокирование каналов проникновения вредоносного кода (Интернет, флешки) и др.
В заключение хочу ответить что модель угроз, сама в себе большого смысла не имеет, она нужна для формирования технического задания на построение системы защиты.teecat
28.09.2016 16:14Да не вопрос. Если все известно и есть все курсы — просьба ответить на простой вопрос — зачем нужен антивирус (именно антивирус, а не антивирусная система защиты. Разница есть и существенная) на:
— рабочей станции
— почтовом сервере
— шлюзе
Кстати вы уже ошиблись в описании назначения в предпоследнем абзаце. Антивирус не может обеспечить нормального уровня защиты от проникновения
imbasoft
28.09.2016 17:55Простой вопрос: зачем нужен антивирус. Ответ на него каждый делает сам.
Для меня как потребителя, антивирус является частью комплексной системы защиты от вредоносного кода.
Антивирусная защита не является темой статьи.teecat
29.09.2016 09:36Ответ на него каждый делает сам.
Я бы не сказал. Защита от вредоносного кода — часть должностных обязанностей и в информационной системе и антивирус и МЭ имеют строго определенные роли
occam
28.09.2016 22:30-1Во первых, какое, FUCK, «долгожданное событие»? ФСТЭК запланировал вернуть всем разработчикам деньги за сертификацию по схеме, которая ВНЕЗАПНО стала старой? ФСТЭК — это такой рэкет 21 века?
occam
28.09.2016 22:38-1Во2х, в знак протеста против нарушения правила «закон обратной силы не имеет» никогда в жизни больше не потрачу не минтуы своего времени на очередную сертификацию по очередным нормативам фстэк и всех, уверенных в качестве своего ПО, поддержу в таком же бойкоте.
occam
28.09.2016 22:49-1В3их, уровень терминологии фстэк приобретает все более кретиноийдный характер. Что такое программно-техническое исполнение? Уровень логических границ? Всегда ли узел (хост) можно отличить от уровня веб-сервера? Кто-то в испытательной лаборатории может дать гарантии об отсутствии риска отказа в обслуживании в связи с наличием уязвимостей в сетевых протоколах? фстэк из своего бюджета компенсирует потери при наступлении у пользователя таких рисков? И еще 200 вопросов. Требования к фильтрации — просто доисторические. Бездельники, вы бы хоть не поленились — доехали до KasperLab, GroupIB, Positive — таких много, поспрашивали бы для приличия каким должен быть нормальный современный fw. Посмотрите как работают fw в виртуальных серверах, в кластерах, в звене с другими секьюрностями. Просто нет слов, в отличии от обшего тренда на модернизацию машины госуправления в лучшую сторону, храбрый фстэк деградирует на глазах. Грустно, был ведь неплохим fw для дырявого софта ((((
occam
28.09.2016 23:11-1В4х, ставлю $100, что не меньше, чем два из первых 10 сертификатов по новой схеме будут вручены MS или другому резиденту шша.
Beowulf
29.09.2016 07:58Остальные классы защиты описываются в документах с грифом ДСП и широкой публике недоступны.
Мне одному это режет глаз? Как бы ДСП — не гриф. Или эта информация тоже теперь «недоступна широкой публике»? ))imbasoft
29.09.2016 09:34ДСП — не гриф, это все знают :), это пометка конфиденциальности не имеющая под собой юридической силы.
На текущий момент есть грифы: коммерческая тайна, секретно, сов. секретно, особой важности.
Все это прописано в действующих Федеральных законах и Постановлениях Правительства.
teecat
29.09.2016 09:46-1Конечно не гриф. Информация ограниченного распространения. Но огрести за ее утечку можно не меньше, чем за секретную
occam
29.09.2016 21:51В-шестых. Когда неплохие люди начинают делать дела плохих парней, то с ними обращаются как с плохими парнями. То что сделал фстэк — это вымогательство, соответствующая ст. есть в криминальном УК. Не надо думать, что новая звезда на плечах добавляет интеллекта.
Либо фстэк включает заднюю, либо вольные стрелки будут проверять каждый, вновь сертифицированный образец, и передавать эти результаты другим людям. Резюме: партнерство или самоликвидация.
teecat
30.09.2016 09:53На самом деле документ не плохой. По сравнению с требованиями к антивирусам — даже отличный. Хорошо проработан в частях по документации и аудиту. Но вот в части функционала… Да, тут явно определили только направления
occam
02.10.2016 08:31А вот здесь не могу согласиться. В целом топик отличный и очень своевременный. Большое спасибо! Жаль, что в своих первых комментариях эмоции опередили логику. Попробую за сегодня последовательно и без лишнего внимания объяснить причины роста негатива к действиям ФСТЭК, а такого негатива накопилось уже немало. Отмечаюсь здесь, тк предметом моего интереса остаются только МСЭ, как ключевой узел любой сетевой архитектуры и не планирую выходить за рамки обсуждения данной предметной области.
На дворе, действительно, 2016 год. Вспомним лето 1997 года ФСТЭК выпустил нормативную и методическую базу по межсетевым экранам. Для того времени это были поистине революционные документы, в которых системно, предметно, зачастую в предельно точных формулировках была описана модель (почти ТЗ) практически идеального stateful firewall. Точнее российские требования к такому решению, учитывающие лучшие на тот момент мировые практики (кстати, с профессиональным, а не «машинным» переводом) и адаптированные на отечественные ИКТ. Может быть, именно благодаря тому комплекту 1997 по состоянию на сегодня, по числу команд разработки межсетевых экранов мы делим с Израилем второе место в мире. Просто для примера: в маленькой Чехии две команды антивирусописателей и у нас две. Firewall в Чехии тоже два, а у нас — более 30 (включая персональные и поглощенные более крупными вендорами). Причем наиболее активный рост в появлении новых производителей приходится именно на нулевые. Каждый разработчик тогда работал в своей рыночной нише, сертификация требовалась лишь единицам, выбор сетевого экрана был делом добровольным. Технологии очень динамично развивались.
Потом, как это обычно бывает, кому-то захотелось больше золота. Сначала появился проект ЗПДа, затем одним из надзорных органов был определен ФСТЭК, а спустя некоторое время практически всем операторам пришлось задуматься о сертифицированных средствах защиты, в том числе, и МСЭ. Здесь и кончается золотое время как отечественного firewall-строения, так и ФСТЭК.
Из полусекретной, сфокусированной на конкретных задачах, академичной и кабинетной работы ему пришлось переходить в публичную область, требующую не только понимания большого спектра интересов, коммерческих навыков, но и междисциплинарных знаний в том, числе в областях гуманитарных и коммерческих, включая самомаркетинг (в хорошем смысле этого слова). Задачи стали абстрактными, постановщиков задач прибавляться, а стабильности в их требованиях убавляться. Об этом чуть ниже.
По правде сказать, для внешнего наблюдателя, в новом публичном статусе работа ФСТЭК пошла сначала превосходно. Особенно если бы штат был увеличен раз в 10. Но сказок на госслужбе не бывает и по объективным причинам довольно скоро появление ФСТЭК на радарах превратилось в анонсирование обновлений нормативной базы, сообщения об очередных сроках переноса выпуска, анонсированных ранее материалов, попытки наладить системную работу по устранению уязвимостей в СЗИ. Времени и возможности для сфокусироваться на системной проработке нормативной базы не осталось совсем. Никто бы не позавидовал.
В это же время быстро изменялась вся отрасль ИБ. К привычными АВЗ, МСЭ, ЗНСД и ПЭМИН добавилась необходимость разбираться в снежном коме новых технологий: SIEM, IDS, IPS, DLP, IAM, сканеры уязвимостей, цифровые отпечатки. В таких условиях любому легко свернуть с правильного, но трудного пути на скользкую дорожку…occam
02.10.2016 23:16Документы ФСТЭК теряют системность и становятся все менее конкретными. Вернемся к пакету новых требований к МСЭ. Первое изменение, которое видно невооруженным глазом — проведена сегментация на 5 типов. teecat уже грамотно описал их в своем топике. Оукей, запасемся терпением и дождемся официальной расшифровки термина «программно-техническое исполнение», жутко интересно с какого момента дистрибутив fw становится программно-техническим.
Но закрыть глаза на «физические» и «логические» границы уже не получается. Скажите, пожалуйста, когда заместитель городской администрации с мобильного устройства через гостиничный Wi-Fi подключается к муниципальной СЭД, имея при этом массу permissions на почту, ftp и другие сервисы, где в этот момент оказывается физическая граница ИС? Или ему просто нужно возить всегда с собой аппаратный МЭ типа «А»? Или ему вообще нельзя удаленно подключаться? А на вопрос мэра: «Заапрувишь распоряжение по уборке снега?», отвечать: «Спокойно, босс, вот вернусь и все будет». Ладно, пусть параллельно с нашей реальностью с MDM и BYOD сосуществуют «периметры физических, логических», прочих виртуальных границ. Пусть, не будем грустить. Откроем любой профиль защиты. Мне как-то вот приглянулся: «МСЭ типа «А» четвертого класса защиты».
Опять же совершенно справедлив комментарий teecat, что конкретика не занимает и трети документа. Первое впечатление от пролистывания профиля просто таки конспирологическое. Начинает казаться, что у кого-то из больших боссов стоял KPI: гармонизация требований к МСЭ с ГОСТ Р ИСО/МЭК 15408. (И почему, можно спросить, незаслуженно забыт ГОСТ Р 50922 2006 «Защита-информации.Основные термины и определения»?) Что и было сделано на отлично. До 13й страницы есть конкретные требования, далее немного об угрозах, политиках и предположениях, а с 27й страницы (из 89) идет практически полная дубликация текста выше в аббревиатурах ИСО 15408 (и еще пары нормативных документов ФСТЭК). Данному15408 (переведенному с англоязычного ISO IEC 15408) уже более 10 лет, на секундочку (если вести отсчет от редакции 2006 года, которая не претерпела значительных изменений). И еще, некстати, этот же стандарт так же давно считается мягко сказать неконкретным (и весьма затратным в применении на проектах), чего только стоит понятие «информационный поток», который может быть и электронным письмом, и спамом, и запросом пользователя, и дидос-атакой, и загрузкой обновлений, и еще 100500 вариантов трафика, все из которых для простоты называются одним общим словом: «информационный поток».
Нам предлагается профиль защиты на критериях прошлого десятилетия, казалось бы, а вот и нет. При более глубоком прочтении обнаруживаются просто таки революционные изменения! Итак, барабанная дробь… МСЭ по типу «А», четвертого класса защиты с 2016 года должен включать такой новый фу-у-ункцио-о-онал…, как: маскирование, сигнализация о попытках нарушения правил межсетевого экранирования, возможность кластеризации, возможность осуществлять фильтрацию пакетов с учетом управляющих команд от других СЗИ, возможность осуществлять проверку использования сетевых ресурсов, содержащих мобильный код. И еще штук примерно 20 новых фантастических опций. Примерами мобильного кода считается использование Java, JavaScript, ActiveX, PDF, Postscript, Flashанимация, VBScript. Это когда на дворе 2016 год, в котором некоторые fw распознают сигнатуры трафика тысяч приложений, контролируют уязвимости и умеют адаптироваться в real-time к сетевым аномалиям.
Признаться когда прочитываешь «маскирование» сразу вспоминается инновационный TrapX, умеющий создавать ловушки, которые имитируют ценные информационные активы. Но нет, не надо бежать перед паровозом, маскирование — это всего лишь: «возможность маскирования наличия МЭ способами, затрудняющими его выявление нарушителями». И конечно, по традиции: «в МЭ не должно содержаться программ, не выполняющих функций безопасности или не предназначенных для обеспечения функционирования МЭ (сторонних программ)». И как же без старой доброй: «возможность осуществлять проверку каждого пакета по таблице состояний для определения того, не противоречит ли состояние (статус, тип) пакета ожидаемому состоянию". Появился там ролевой доступ для администраторов, режим аварийной поддержки, кластеризация. Зачем, кстати, она. Задачи отказоустойчивости и производительности вошли в приоритеты ФСТЭК? А если каждый разработчик начнет писать в ТУ, что для полноценной работы жизненно необходим кластер из n устройств? Рынок от этого, конечно, подрастет. Но в некоторых муниципалитетах служащие из дома на рабочее место приносят А4 бумагу и это не художественное преувеличение. Не думаю, что дополнительные затраты такой муниципальной организации на продукты и сервисы по требованиям ФСТЭК вызовут прилив одобрения в этих кругах.
Авторы профилей защиты похоже решили пойти своим путем, в котором нет места анализу технологических трендов, запроса пользователей, обмена опытом с профессиональным сообществом и разумной необходимости. Сделан выбор в пользу максимальной уверенности в единственно верном понимании необходимого, такого как, например: «возможность осуществлять посредничество в передаче информации сетевого трафика, основанное на типе сетевого трафика». Хочется спросить разработчиков, это понятно, что имелось ввиду?occam
03.10.2016 07:43А как влияет ФСТЭК на мир разработчиков?
ФСТЭК ведет реестр сертифицированных решений, для того чтобы в нем оказаться разработчику нужно прибыть в кафкианский замок под вывеской «добровольная сертификация». Дальше он будет с интересом погружаться в мир заявителей, органов по сертификации, испытательных лабораторий, документационного обеспечения, аттестаций, регламентов и субординации. Такой процесс может занимать до 2 лет. До самого последнего дня перед подписанием сертификата ни у кого не будет уверенности в 100% успешном результате. Отказано может быть просто по причинам, которые не принято называть, назовем их политическими.
Провайдерами рынка МСЭ в России можно обозначить три группы. Первую условно назовем «зубры» ИБ, сюда входит решения (их можно пересчитать по пальцам), которые считаются информационным щитом в борьбе с иностранными разведками. Вторая группа — это зарубежные вендоры, здесь можно было насчитать до 35-40 игроков, которым в той или иной степени интересен российский рынок. Легко проверить, кстати, что в прошлом были периоды, в которых зарубежные производители МСЭ получали сертификатов больше и быстрее, чем их российские конкуренты. Преимущественным каналом сбыта этой группы был сегмент Enterprise. И, наконец, третья группа — это около 15 разработчиков из сегмента российского малого бизнеса. Преимущественно небольшие команды, которые начинали с какого-то узкого сегмента и постепенно собрали свой современный, в чем-то уникальный файрвол. Именно здесь находится передний край технологий. Именно эти ребята лучше «зубров» понимают по каким законам развивается тиражное ПО, как держать руку на пульсе завтрашних потребностей пользователей, ездят по конференциям, активно изучают передовой опыт и не боятся динамично добавлять новый функционал, пробовать работу на западных рынках. Здесь же нужно понимать, что эти команды, назовем их «Моторины», на своем домашнем рынке конкурируют с глобальными транснациональными корпорациями, чьи ресурсы на R&D и маркетинг в тысячи раз больше. И тем не менее моторы у «моториных» крутились, они работали на своей волне и не сильно задумывались и «бумажной» безопасности.
Так примерно было. С приходом Закона о персональных данных стали наблюдаться следующие изменения. Решения «зубров» практически на автомате получили все нужные бумаги и отправились на свободный рынок, спрос рос геометрически. Только, как это всегда бывает при переходе из стадии штучных проектов в тиражное ПО, оказалось, что их показатели функциональности и стабильности не столь безупречны, как это казалось ранее.
«Кучка» западных вендоров стала еще более могучей, многим казалось, что перспективы оснащения десятков тысяч операторов ПД своими решениям — это какой-то невероятный клондайк, конкуренция на рынке СЗИ стала обострятся.
А перед «моториными» встала необходимость добыть себе сертификат ФСТЭК, тк каждый третий клиент начал про это спрашивать. Вот здесь начинается засада
В итоге почти все «моторины» сертификаты получили. Но какой ценой? Легко проследить по событийным лентам таких компаний, как с момента выхода новости о начале процесса сертификации часто выхода новых версий и функциональных улучшений заметно снижается. Процесс сертификации, кроме прямых финансовых вложений, требует много человеческих ресурсов: нужно выстроить взаимодействие с испытательной лабораторией, обучиться эзоповому языку, на котором принято описывать функционал для органа по сертификации, начинать перестраивать свой продукт под полное соответствие требованиям руководящих документов и много чего еще. Какой может быть agile, когда ответа на простой вопрос можно ждать 1-2 недели и это не потому, что испытательная лаборатория медленная, просто там принято любую позицию по новым вопросам согласовать внутри своего сообщества и только потом транслировать наружу.
Есть и другие примеры, когда связной с замком «добровольная сертификация» сначала начинал задумываться о том, как страшен мир киберугроз, потом общаться на эзоповом языке с командой, чтобы наконец однажды прийти и сказать: «Парни у нас вообще все не правильно, нужно пересматривать всю архитектуру, начиная с ядра». На попытки объяснить, что у команды нет ресурсов на разработку нового продукта и сопровождение двух архитектур, что требования датируются 1997 годом, что нужно немного подождать и будут новые подходы, в которые возможно все впишется идеально, такой человек мог как спуститься обратно на землю, так и навсегда покинуть команду, чтобы переехать в Замок.
Это всю лирика. Реальность в другом. Посмотрим на финансовую сторону вопроса. Если «моторин» потратил миллион на сертификацию (не считая косвенных издержек), то на какую сумму ему нужно продать сертифицированного ПО, чтобы выйти на точку безубыточности? На миллион? На полтора? Правильный ответ: не меньше четырех, так как в цене сертифицированного ПО, кроме затрат на сертификацию, зашиты еще инвестиции в разработку самого продукта, тестирование, техническую поддержку, дистрибуцию. Сертификат действует три года, но на достижение такого финансового результата у «моторина» есть только два, тк на третий год будет необходимо либо подтвердить начало работ по продлению сертификата, либо приготовиться к отказам заказчиков. Если за эти два года произошли существенные функциональные обновления — нужен новый сертификат (ННС), если вышла новая версия — ННС, если закончилась партия сертифицированных продуктов — ННС.
При этом нужно понимать, что бизнес разработчика ПО несколько отличается от классического понимания бизнеса. Здесь критически важно обеспечивать постоянный положительный денежный поток, чтобы не допустить кассового разрыва. Талантливым людям, которые очень востребованы на рынке, очень сложно объяснять почему произошли проблемы с зарплатой и нужно подождать. Зачастую именно таланты — это единственный актив разработчика и никакие банки не принимаю этот актив в качестве залога, чтобы выдать краткосрочный овердрафт для расчетов с командой. В это же время у «зубров» и западных корпораций проблем такой остроты финансовых рисков практически нет, у них постоянно в стадии сертификации находится какой-нибудь очередной дистрибутив, для них это естественный процесс развития компании.
Чтобы не быть голословным в остроте проблематики кассового разрыва у разработчика. Все помнят уникальную пермскую компанию, попавшую в Gartner по квадранту BI? А все ли знают в какой финансовой стадии сейчас находится этот разработчик, еще недавно входивший в российский ТОП-20?
Неудивительно, что малый разработчик относится к сертификации практически, как молодая семья к ипотеке. Просчитать все риски, спрогнозировать потенциальный спрос, который обычно окажется ниже, тк сертификат ФСТЭК уже не является конкурентным преимуществом, провести работу с командой, которая не всегда понимает почему все лучшие опции нужно будет выпиливать — это самый минимум дел, которые ждут разработчика перед принятием решения о сертификации.
В итоге к 2016 году почти все разработчики из группы «моториных» сертификат ФСТЭК получили. И в этом же 2016 году ФСТЭК говорит: «мы все придумали. Все такие сертификаты 1 декабря 2016 года превращаются в тыкву, начинайте готовиться к новым сертификационным испытаниям, кстати, теперь уже типов МСЭ стало пять вместо одного». Это примерно как если бы другой надзорный орган — Банк России сказал всем ипотечникам: «Ваша ипотека аннулирована, квартиру нужно вернуть, ничего страшного, так надо, программа ипотечного кредитования будет продолжена, там правда ставка будет в 5 раз выше, но это нормально, это важно в интересах нации».occam
06.10.2016 17:41Есть еще очень много вопросов. Надзор почему-то решил, что вся буза на рынке связана с командой, играющей за импортозамещение. Нет и еще раз нет. Если кто-то из противоположного лагеря (наряду с огромным числом единомышленников) тратил свое время на противодействие лоббизму ЗПО (западного ПО), это еще не означает, что в мире МСЭ должно быть только РПО (российское). Для меня, например, проблема набрала критическую массу, когда я понял, что с определенного момента времени вся эшелонированная оборона критических объектов ИТ-инфраструктуры будет состоять из продуктов «зубров» и международных корпораций. К сожалению, не только у меня нет такого безраздельного доверия ни к тем, ни к другим. Поэтому, когда «из зала» сообщают о том, что в первой десятке сертификатов уже 4 предполагается для американских СЗИ, здесь дело уже начинает брать серьезный оборот. А может сразу добавить «китайца» и добить до 5:5? А что хороший счет.
Или вот еще независимое мнение (напрямую российского разработчика): «Нам сейчас нужно будет не просто пройти новую сертификацию. Во-первых, нужно написать всю это никому не нужную макулатуру по процедурам выпуска и поддержки ПО, которую никто и никогда не увидит. Но написать ее самостоятельно нереально — обращаемся в компанию. А компании разводят руками и говорят — «мы эту хрень тоже еще не умеем писать — вы первые сертифицируетесь. Идите в ABC, они могут». Но и это фигня. Ладно бы то, что в процессе сертификации продукты даже не запускаются и баги сборки, проведенной в присутствии сертификаторов и забранной ими с собой вылазят после получения сертификата. Но теперь деньги берут не просто за сертификат, а за поддержку конкретных ос с точной версией. Сколько Линуксов останется за бортом? Грусть и печаль. Но это увы уже за рамками публичных жалоб. Ибо тут имена и обиды»".
В Управлении вы все еще думаете, что тема раздута каким-то отдельным девелопером? А можно представить, что есть такие же идейные и патриотичные люди, которым не все равно?
Тема так-то набирает обороты, уже и в СМИ. И ведь правда, когда появятся первые сертификаты, может стать не до шуток от понимания того, в интересах каких все это было затеяно. Это очень серьезный шаг, чтобы начать переформатирование такого большого сегмента рынка, должен быть крайне критически аргументированный мотив, imho.occam
07.10.2016 10:37Если переключиться в конструктивную плоскость, что можно предложить. Просто как одно из тысячи мнений, очень крупными штрихами без глубокой аргументации.
1. Новые требования по МСЭ признать промежуточными и отправить в доработку.
2. Правило выдачи сертификата на 3 календарных года сохранить.
3. Классификацию составить по трем объектам защиты: ГТ, АСУ ТП, все остальное (ведомственные, муниципальные, корпоративные сети с конфиденциалкой, ПД и тд).
По классу ГТ предложений нет в силу отстуствия понимания этой области. Что-то подсказывает, что здесь не нужна публичность, только адресная работа с пользователеями и вендорами. А также — необходимость развивать конкуренцию по стоимости и функционалу, при этом обеспечивая отсуствие зависимости ои западного ПО.
В классе АСУ ТП необходим технический комитет (ТК) из реальных Заказчиков-пользователей, есть уверенность, что желающих и заинтересованных качественно обеспечивать защищенность технологических процессов более, чем достаточно. ТК формулирует и на ежегодной основе актуализирует требования к «промышленным» МСЭ. Обмен отраслевым опытом, библиотеки лучших практик, совместные действия по обнаружению уязвимостей и слабых мест — все как обычно.
По классу МСЭ общего назначения (для всего, что не ГТ и АСУ ТП) доработать базовые требования, например, в части обеспечения защищенного удаленного доступа. Уровни сертификации сформировать по стоимости ущерба от хищения защищаемой информации. Например, до 1 млн руб, до 10 млн, до 100 и тд. Оценку рисков ущерба выполняют сами Заказчики-пользователи, исходя из оценки они же самостоятельно выбирают МСЭ, соответствующего уровня. Не надо много думать за пользователя (требования по отказоустойчивости, надежности, кластеризации) он вполне способен самостоятельно выбрать продукт, которые наиболее точно удовлетворяет его требования. А также не душить прогресс разработчиков (как например, требования о попакетной проверке или о «не должно содержаться программ, не выполняющих функций безопасности или не предназначенных для обеспечения функционирования МЭ»). Потому как таким подходом отрасль может навсегда застрять в 90-х.
На постоянной основе по каждому классу отладить систему мониторинга угроз.
Процедуру сертификации упростить, сократить по времени. Напомню, что несмотрю на все чемоданы «бумаг» никто из всех участников процесса не несет отвественности за обнаружение «дыр» в сертифицированном ПО, даже если выясняется, что есть единый универсальный пароль «remoteservicemode», работающий на любом сервере данного производителя ПО. Итак: либо сохранять все формальные уровни сертификации и ужесточать отвественность коллег по цеху, либо упрощать процедуры и повышать оперативность реагирования на вновьвыявленные уязвимости, вплоть до push-уведомлений всем текущим пользователям данного ПО.
Взаимодействие с профессиональным сообществом, формирование общей базы терминов и определений (например, по ГОСТ Р 50922-2006), «зеленые коридоры» для продления сертификатов на продукты, по которым за период не было ни одной уязвимости — это уже совсем высокая детализация. В общем, сторон в какую сторону можно менять много. Можно оставаться все как есть, но даже у металлов есть «усталость». Спасибо за внимание. Всем Удачи!
jedai
там, кстати, не написано, что означает это словосочетание? может они имели в виду «программно-аппаратное»?
что в этом утопичного? вполне себе вменяемое требование для продукта подобного рода. другое дело, как это реализовать технически.
Ну а вообще, с такими требованиями, производительность сети… гхм… о какой производительности тут вообще можно говорить? Странные они)
OlegAndr
Разработчики документов ориентировались на DPI и next-gen firewall, что в принципе оправданно для защиты серьёзной инфраструктуры. Вообще никто не не требует чтобы между сегментами были именно сертифицированные продукты — как модель угроз будет составлена.
Производительность кажется решалась требованием для периметровых фаерволов уметь разделять нагрузку, емнип.
teecat
Между сегментами — это тип Б. В статье рассмотрен тип В — для установки на рабочие станции. Тут разделение нагрузки не пройдет
jedai
Возможно. Но вешать все только на программное исполнение — вот это утопичное требование.
occam
Эти муфлоны вообще понимают, что ngfw это просто маркетинговый термин, придуманный агентством из 4 человек за не очень-то большие деньги? Они в принципе способны без заглядывания в нет отличить ngfw от скажем NGSWG?? Кто гарант уровня экспертизы этих муфлонов?