Сертифицированные СЗИ НСД для защиты от целевых атак - Форум по вопросам информационной безопасности

Вебинар: «Технология настройки механизмов защиты КСЗИ «Панцирь+» от актуальных угроз атак. Предоставляемые услуги»
Время проведения – 17.07.18 в 12.00 (мск.).
Ведущий – проф. А.Ю. Щеглов
В рамках проводимого вебинара предполагается рассмотрение следующих ключевых вопросов:
1. Осуществление  настроек системы защиты от наиболее актуальных сегодня угроз атак, в том числе, целевых. Подобная настройка осуществляется в три этапа:
- реализация настроек на тестовом компьютере;
- корректировка настроек в режиме опытной эксплуатации;
- формирование настроек для эксплуатации защищенной информационной системы.
2. Предоставляемые нашей компанией услуги.
- Участие в настройках системы защиты. Цель – обучение специалистов, эксплуатирующих систему защиты, решаемым задачам, возможностям защиты  и принципам настройки системы.
В результате предоставления данной услуги администратор безопасности информационной системы должен понимать не только то, как настроить систему защиты, но и то, с какой целью он настраивает соответствующие механизмы, какие задачи защиты он при этом решает. Без необходимой квалификации администратора безопасности какие-либо затраты на безопасность не имеют смысла! Эта услуга направлена, в первую очередь, на повышение уровня квалификации администраторов безопасности!
- Участие в анализе инцидентов (отказов в доступе). Состоит в анализе по зафиксированным данным аудита причин отказов доступе, что предполагает соответствующее моделирование критичных событий на нашем стенде, с формированием экспертного решения специалистов по каждому конкретному событию отказа в доступе.
 
Приглашаем к участию!
Записаться на вебинар можно, отправив заявку на участие по адресу: ots@npp-itb.spb.ru, указав в теме письма «На вебинар».

Вебинар: «Технология настройки механизмов защиты КСЗИ «Панцирь+» от актуальных угроз атак. Предоставляемые услуги»
Время проведения – 17.07.18 в 12.00 (мск.).
Ведущий – проф. А.Ю. Щеглов

В рамках проводимого вебинара предполагается рассмотрение следующих ключевых вопросов:
1. Осуществление настроек системы защиты от наиболее актуальных сегодня угроз атак, в том числе, целевых. Подобная настройка осуществляется в три этапа:
- реализация настроек на тестовом компьютере;
- корректировка настроек в режиме опытной эксплуатации;
- формирование настроек для эксплуатации защищенной информационной системы.
2. Предоставляемые нашей компанией услуги.
- Участие в настройках системы защиты. Цель – обучение специалистов, эксплуатирующих систему защиты, решаемым задачам, возможностям защиты и принципам настройки системы.
В результате предоставления данной услуги администратор безопасности информационной системы должен понимать не только то, как настроить систему защиты, но и то, с какой целью он настраивает соответствующие механизмы, какие задачи защиты он при этом решает. Без необходимой квалификации администратора безопасности какие-либо затраты на безопасность не имеют смысла! Эта услуга направлена, в первую очередь, на повышение уровня квалификации администраторов безопасности!
- Участие в анализе инцидентов (отказов в доступе). Состоит в анализе по зафиксированным данным аудита причин отказов доступе, что предполагает соответствующее моделирование критичных событий на нашем стенде, с формированием экспертного решения специалистов по каждому конкретному событию отказа в доступе.


Приглашаем к участию!
Записаться на вебинар можно, отправив заявку на участие по адресу: ots@npp-itb.spb.ru, указав в теме письма «На вебинар».

Выложили на сайте презентацию, иллюстрирующую отличия КСЗИ "Панцирь+" от иных сертифицированных СЗИ от НСД: http://www.npp-itb.ru/images/docs/alldocs/otlich.pdf

Несколько вопросов по презентации.
1. Что есть автоматическая разметка создаваемых файлов? Атрибуты безопасности устанавливаемые по умолчанию?
2. А что, процессы у нас сами по себе существуют? На сколько я помню любой процесс в ОС запускается от имени пользователя (за исключением системных). Не пойму в чем ноу-хау?
3. Каким способом разделительная политика доступа определяет к какому объекту субъект может получить доступ, а к какому нет?
4. Насколько мне известно все существующие СЗИ НСД (сертифицированные ФСТЭК) обеспечивают самозащиту. Так чем же конкретно КСЗИ "Панцирь+" лучше того же DL или SNS?

1. Нет. Каждый файл при его создании размечается - в его альтернативный поток записывается каким субъектом (пользователем, процессом) создан этот файл (либо пользователем с какой меткой безопасности при мандатном контроле доступа).
2. Субъект доступа ко всем объектам задается парой сущностей пользователь, процесс. Одному и тому же пользователю для различных процессом могут назначаться различные права доступа к одним и тем же объектам.
3. Разделительная, а не разграничительная. Разграничивается доступ не к конкретным объектам, а между объектами. Например системным процессам и службам одним правилом запрещается доступ ко всем файлам созданным интерактивными пользователями, аналогично для системного администратора, то же для процессов, например, браузеру запрещается доступ ко всем файлам, созданным иными приложениями и т.д. Для этого и реализуется автоматическая разметка создаваемых файлов.
4. Эта тема недавно обсуждалась в ветке "СРАВНЕНИЕ ЭФФЕКТИВНОСТИ СРЕДСТВ ЗАЩИТЫ ИНФОРМАЦИИ ОТ НЕСАНКЦИОНИРОВАННОГО ДОСТУПА". Там развернутый материал с примерами. КСЗИ "Панцирь+" предполагает и возможность защиты от атак на системные процессы и службы, в том числе, с использованием в них уязвимостей нулевого дня. Решение этой задачи предполагает реализацию самозащиты, не позволяющей воздействовать на защиту системным процессам и службам, что и реализовано в КСЗИ "Панцирь+".
Детали можете посмотреть на странице продукта http://www.npp-itb.ru/products/armourp там много развернутых презентаций по отдельным решаемым задачам защиты и результаты пентеста.

*в сторону*
Хотел выложить еще вчера ночью, да форум, походу, испытал переполнение буфера в базе (SQL-запросы базы явно на веб-форме отображались). Поэтому отсылка будет к бессоннице и проч. побуждениям в 3 часа ночи по Мск...

В эту безлунную ночь в эфире программа "Не спалось..."
Сразу признаюсь, что ламер в анализе сетевого трафика и использовании wireshark, но тем не менее, считаю, что терпение и труд всех отъ*бут...
Тест проводился для Демо-версии Панцирь+ x64 и х32, загруженной с сайта http://www.npp-itb.ru/products/armourp.
Серверная часть - VirtualBox 5.2.16, Windows Server 2008 R2 x64, роль DC отсутствует, иные роли тоже.
Клиентская часть - VirtualBox 5.2.16, Windows 7 Professional x64 без лишних сервисов и сетевых приложений.
В качестве промежуточного звена сервер-шлюза используется VirtualBox 5.2.16, Debian 8.11.0 Jessie, wireshark 1.12.1. Клиентская ОС подключена через виртуальный интерфейс типа "внутренняя сеть", ОС сервер-шлюза - два интерфеса ("внутренняя сеть" и "сетевой мост"), Серверная ОС - интерфейс типа "сетевой мост". Сервер-шлюз производит NAT-трансляцию (masquerading) всех запросов от клиента вовне. Фильтрация трафика не используется (все запросы транслируются на внешний интерфейс и далее).
Предполагается, что нарушитель действует на сервер-шлюзе или в одном сегменте сети с клиентом (не принципиально).
Правило для wireshark банальное до безобразия: host ip-адрес-сервера and port 43981 (по документации Панцирь+ - порт сетевых соединений с Сервером управления от Клиентов).

1. Сервер. Замечания и вопросы.
- Служба "сервер-аудит" имеется, а вот службы непосредственно сервера управления КСЗИ отсутствует. Т.е. запуск производится вручную (или автоматически через автозагрузку ОС) при входе определенного пользователя в систему + ввода первично заданного пароля для вызова оснастки сервера управления. Так и задумано? Или это ограничения демо-версии?
- при работе через NAT клиент определяется по внешнему ip-адресу сервер-шлюза. Т.е., чтобы избежать дублирования клиентов (если их более 1, ага), необходимо добавлять клиентов по netbios-именам хостов. Так и задумано? Не похоже на ограничение демо-версии. Суть в том, что использовать в качестве идентификаторов ip-адрес или netbios-имя на текущий момент моветон. Правильнее было бы использовать некий устойчивый ID клиента, назначаемый ему при установке Клиентской части Панцирь+.
- NMAP показывает кучу открытых tcp-портов на сервере при активном Сервере управления кроме штатных 43981/tcp и 3050/tcp. Так и задумано?
Discovered open port 47001/tcp on 192.168.0.120
Discovered open port 49155/tcp on 192.168.0.120
Discovered open port 49152/tcp on 192.168.0.120
Discovered open port 43981/tcp on 192.168.0.120
Discovered open port 49161/tcp on 192.168.0.120
Discovered open port 49157/tcp on 192.168.0.120
Discovered open port 49153/tcp on 192.168.0.120
Discovered open port 49154/tcp on 192.168.0.120
Discovered open port 49159/tcp on 192.168.0.120
Discovered open port 3050/tcp on 192.168.0.120

2. Клиент. Замечания и вопросы.
- после установки отсутствуют какие-либо ярлыки консоли управления установленной КСЗИ (трей, рабочий стол, start-menu). Так и задумано? Или это ограничения демо-версии?

3. Результаты поверхностного анализа пакетов с применением wireshark и моих кривых рук. Пока анализировалась связь между клиентом и сервером в idle-режиме (ОС клиента загрузилась, вход в систему произведен не был) и пакеты только со стороны клиента. Могу ошибаться, но все же:
- наблюдается весьма разнородный timestamp, хотя в настройках (по умолчанию) выставлен период опроса клиент-сервер и сервер-клиент в 10 секунд. Разброс периодически достигает от 7 до 25 секунд. Положим, всему виной потери пакетов при их обработке виртуальными интерфейсами кучи запущенных VirtualBox через хост-ядро гипервизора (Linux Mint 17)...
- пересылаемые данные о состоянии клиентов пересылаются, конечно, не в открытом виде, но маска их передачи всегда одна и та же, что дает возможность предположить: для связи сервера со всеми клиентами используется один и тот же криптоключ (алгоритм шифрования пока не ясен), очевидно, захардкоженный. Потому что он не меняется ни после перезагрузки клиента, ни после перезагрузки сервера.
- idle-данные передаются пакетом длиной 76 байт из которых поле нагрузочных данных - 22 байта. При этом в поле данных пакета не удалось обнаружить следов уникального ID-клиента (того же ip-адреса, netbios-имени и т.д.). Т.е. клиент передает однородные данные, аналогичные любому другому клиенту "в режиме ожидания". Очевидно, это следствие желания снизить нагрузку на сервер управления. И, очевидно, Сервер управления оперирует ip-адресом или иной информацией об активной tcp-сессии, не удостоверяя пакеты от клиентов по информации внутри поля нагрузочных данных.
- более того, в idle-режиме каждый клиент отсылает на сервер всего 2 пакета, различающихся полем данных: очевидно "флаг" своего состояния и "флаг" ожидания нового сеанса связи (нечто похожее). При этом сервер аналогично отвечает всегда одним и тем же полем данных на оба запроса (длина ответного пакета - 314 байт, длина поля данных - 260 байт).
Все вышесказанное нас к мысли, что нарушитель, имея возможность перехвата и анализа сетевого трафика на участке "клиент-сервер" (тем более, что заявлена поддержка NAT - т.е. не только в пределах одного адресного пространства сети) может выдать себя за клиента и, как минимум, дезинформировать Сервер управления о реальном статусе клиента (вплоть до маскировки отказа системы защиты). При этом ему достаточно перехватить всего два типа пакетов. Еще веселее, что за счет перенаправления трафика (или подмены DNS, если сервер задан в настройках клиента по DNS-имени) возможно "убедить" клиента в работоспособности сервера в idle-режиме. Т.е. фальсифицировать ответы сервера на запросы клиента. Что тоже делается элементарно за счет первичного перехвата типовых ответов сервера к конкретному клиенту. Для этого даже нет необходимости вскрывать ключ шифрования...
Пока, навскидку, во всем этом деле явно не хватает дополнительных "маркеров" в каждом запросе-ответе клиента и сервера, как то: timestamp, ID и какая-нибудь "соль", чтобы нарушителю жизнь медом не казалась...

На очереди активный тест: попытка "убедить" сервер в доступности клиента в idle-режиме при фактически отключенном клиенте. Заодно прокачаю собственный скилл IP-spoofing и подмены TCP-пакетов. Чувствую, правда, что займусь не скоро, - бессонница вещь переходящая (и хорошо, ага)...

1. Вы смотрите версию, в которой все механизмы отключены, выложена исключительно для иллюстрации интерфейсов и настройки.

2. Естественно, что просто так удаленно с сервера через NAT Вы не пробьетесь - для того он и создан. Можно фиксировать только обрыв соединения любого клиента с сервером. Для более точной идентификации состояний можно воспользоваться трансляцией портов.

3. Относительно удаленного администрирования, например, из облака. Речь об архитектурных особенностях Панциря. Естественно, что этот канал должен защищаться сертифицированной СКЗИ, это иная задача, подобных средств сегодня достаточно и они в обязательном порядке используются в защищенных облаках (задача решена до нас). А вообще речь о принципиальных возможностях. Если рынок это примет, то здесь есть над чем подумать и куда "идти".

4. Относительно ярлыков - нас то просят их оставить, то убрать. Для работы они не нужны - для администрирования есть сервер, а для тестирования они делаются за одну минуту.

to А.Ю. Щеглов
А по существу вопросов вы можете что-нибудь сказать?
Про отсутствие защитных механизмов в демо-версии в курсе - только тогда зачем в ней шифрование связи между Клиентом и Сервером, причем столь убогое? Или в оф.релизе оно другое?
Технологию NAT тоже знаю, спасибо. Речь шла не о пробросе трафика от Сервера к Клиенту "в обратный NAT" и уж тем более не про PAT, а про то, что Сервер идентифицирует Клиентов либо по IP, либо по NetBios-name. Что в первом случае через NAT не имеет смысла, а во втором - принцип из разряда "чтобы было", а не реальный механизм идентификации клиент-серверных подключений в Сертифицированном и Распределенном Средстве Защиты Информации...
Опус про архитектурные особенности и СКЗИ ни к селу, ни к городу. Если механизм "запрос-ответ" между Клиентом и Сервером в демо-версии не отличается от оф.релиза, то у вас большие проблемы на уровне локальной сети, а не только при наличии удаленных площадок и сторонних ИТКС. Тем более, что вы заявляете в Панцире возможность защиты от действий сист.администраторов. Которые, как известно, в своем сегменте локальной сети могут любой трафик в любой момент подменить или перенаправить. Да и не только они (сисадмины), а любой достаточно грамотный инсайдер. И с этой проблемой рассмотренные выше механизмы взаимодействия Клиента и Сервера Панцирь+ явно не справляются. Либо тогда уж в ТУ пишите обязаловку СКС, СКЗИ внутри сети, контроля и мониторинга трафика и т.п. перед внедрением сетевой версии Панцирь+, ага...
С ярлыками вообще чушь собачья (цитирую: <просят их оставить, то убрать>). Клиентская версия Панцирь+ одна и для сетевого режима, и для автономной работы. И, если в случае с наличием в сети Сервера управления отсутствие ярлыков после установки Клиента на рабочей станции я еще могу понять, то в случае развертывания Клиента на автономной машине отсутствие ярлыков Консоли управления вызывает, мягко говоря, недопонимание. Причем ни в стартовом меню, ни на рабочем столе, нигде. Будь добр, сам лезь в C:\Program Files\SPC ITB\Armour\bin и ищи там ctrliface.exe. User frieandly interface, ага...

ЗЫ Над повсеместным упоминанием слова "облако" вне контекста децентрализованных сервисов уже давно (года два-три, как бум прошел) смеется добрая половина безопасников-практиков и безопасников-теоретиков (учителей) в стране. Так что "не советую, съедят" (с)