Ваш план киберзащиты: 18 шагов к безопасности

Существуют ключевые контроли, которые должна выполнять служба безопасности, известные как CIS Top 18 и какими продуктам их можно осуществить. 

№	Контроль	Описание	Классы продуктов/сервисов
1	Инвентаризация и контроль корпоративных активов	Управление всеми корпоративными активами	ITAM, CMDB, NAC, NDR, VM
2	Инвентаризация и контроль программных активов	Управление всем ПО в сети	SAM, SCCM, EDR, VM
3	Защита данных	Шифрование, защита целостности, предотвращение утечек	DCAP, DBF, DAM, DLP, IRM, шифрование, например Гарда DBF
4	Безопасная конфигурация активов и ПО	Установка и поддержка безопасных конфигураций	SCM, SCCM, SCAP
5	Управление учетными записями	Безопасное управление учетными записями	IAM, PAM, SSO
6	Управление контролем доступа	Контроль привилегий, MFA	IAM, PAM, MFA
7	Непрерывное управление уязвимостями	Оценка и устранение уязвимостей	VM, SIEM, Patch Management
8	Управление журналами аудита	Сбор и анализ журналов	SIEM, Log Management
9	Защита электронной почты и веб-браузеров	Повышение безопасности основных инструментов	SEG, SWG, CASB
10	Защита от вредоносных программ	Предотвращение установки и выполнения вредоносных программ	AV, EDR, XDR
11	Восстановление данных	Резервное копирование и восстановление	Backup & Recovery, DRaaS
12	Управление сетевой инфраструктурой	Управление сетевыми устройствами	NMS, IPAM, SDN
13	Мониторинг и защита сети	Обнаружение и реагирование на угрозы в сети	NIDS/NIPS, NDR, NBAD, Deception например Гарда NDR
14	Обучение по вопросам безопасности	Программы повышения осведомленности	SAT, Phishing Simulation
15	Управление поставщиками услуг	Оценка безопасности третьих сторон	VRM, TPRM
16	Безопасность прикладного ПО	Управление жизненным циклом безопасности ПО	SAST, DAST, SCA
17	Управление реагированием на инциденты	Обнаружение, управление и восстановление после инцидентов	SOC, SOAR, IRP, SIEM
18	Тестирование на проникновение	Регулярная проверка эффективности мер безопасности	Penetration Testing Tools, Red Team Tools

Ссылка на полное руководство по CIS Top 18

Аббревиатуры в колонке "Классы продуктов/сервисов" расшифровываются следующим образом (отсортировано по алфавиту)

Аббревиатура	Название	Описание
AV	Antivirus	Антивирусные решения для защиты от вредоносных программ.
CASB	Cloud Access Security Broker	Решения для обеспечения безопасности облачных сервисов.
CMDB	Configuration Management Database	База данных для управления конфигурацией IT-активов.
DAST	Dynamic Application Security Testing	Инструменты для динамического тестирования безопасности приложений.
DAM	Data Access Management	Управление доступом к данным и их защитой.
DLP	Data Loss Prevention	Решения для предотвращения утечек данных.
DRaaS	Disaster Recovery as a Service	Услуги восстановления после катастроф в облаке.
DCAP	Data-Centric Audit and Protection	Классификация и защита данных в организации.
EDR	Endpoint Detection and Response	Решения для обнаружения и реагирования на угрозы на конечных устройствах.
IAM	Identity and Access Management	Управление идентификацией и доступом пользователей.
IPAM	IP Address Management	Управление IP-адресами в сети.
IRM	Information Rights Management	Управление правами на информацию и данные.
NDR	Network Detection and Response	Обнаружение и реагирование на угрозы в сети.
NAC	Network Access Control	Контроль доступа к сети.
NIDS/NIPS	Network Intrusion Detection/Prevention System	Системы обнаружения/предотвращения вторжений в сеть.
NMS	Network Management System	Системы управления сетевой инфраструктурой.
PAM	Privileged Access Management	Управление привилегированным доступом к системам и данным.
SAM	Software Asset Management	Управление программными активами компании.
SAT	Security Awareness Training	Обучение сотрудников вопросам безопасности.
SAST	Static Application Security Testing	Инструменты для статического тестирования безопасности приложений.
SCM	Security Configuration Management	Управление безопасной конфигурацией активов и ПО.
SCAP	Security Content Automation Protocol	Протокол автоматизации контента безопасности.
SEG	Secure Email Gateway	Защита электронной почты от угроз.
SIEM	Security Information and Event Management	Управление информацией и событиями безопасности.
SSO	Single Sign-On	Решения для единого входа в системы и приложения.
SOAR	Security Orchestration, Automation and Response	Оркестрация, автоматизация и реагирование на инциденты безопасности.
SWG	Secure Web Gateway	Защита веб-трафика от угроз и вредоносного контента.
TPRM	Third-Party Risk Management	Управление рисками, связанными с третьими сторонами.
VM	Vulnerability Management	Управление уязвимостями в системах и приложениях.
VRM	Vendor Risk Management	Управление рисками поставщиков услуг.
XDR	Extended Detection and Response	Расширенное обнаружение и реагирование на угрозы в кибербезопасности.

Цифровой щит России: сотни организаций получили защиту от ГРЧЦ

В России внедрен инновационный механизм защиты организаций от киберугроз.

Ежедневно специалисты обнаруживают около 60 новых уязвимостей в программном обеспечении, что создает серьезный вызов для служб информационной безопасности. Успевает ли ваша организация? Для решения этой проблемы ГРЧЦ запустил специализированный внешний сканер безопасности, работающий по принципу External attack surface management (EASM). Этот инструмент проверяет внешние IP-адреса компаний на наличие потенциальных угроз, доступных через интернет.

Ключевая задача для специалистов по безопасности - опережать злоумышленников в обнаружении уязвимостей. При этом ИТ-отделы должны своевременно обновлять и настраивать системы для минимизации рисков внешнего доступа к уязвимостям. Этот комплексный подход, известный как Vulnerability Management, стал необходимым стандартом кибербезопасности.

Понимая, что не все организации имеют ресурсы для постоянного внешнего мониторинга, Центр мониторинга и управления сетью связи общего пользования (ЦМУ ССОП) ФГУП «ГРЧЦ» взял на себя эту функцию. На данный момент более 300 организаций получили уведомления о выявленных уязвимостях в их системах, что позволило им принять необходимые меры защиты. Такой подход существенно укрепляет как безопасность отдельных компаний, так и киберзащиту страны в целом.

Эту информацию представил Сергей Хуторцев, директор ЦМУ ССОП ФГУП «ГРЧЦ», во время своего выступления на СПЕКТР ФОРУМЕ, который прошел 23-24 октября 2024 года в Сочи.

Статистика по DDoS атакам на Россию в 2023 и 2024 году

В России развернута Национальная система противодействия DDoS-атакам (НСПА) и она показывает свою эффективность уже два года.

Самая масштабная DDoS-атака 

• 2023 год: 150 гигабит в секунду и 16 миллионов пакетов в секунду 
• 2024 год: 1730 гигабит в секунду и 155 миллионов пакетов в секунду 

Самая продолжительная DDoS-атака

• 2023 год: 24 часа 
• 2024 год: 73 часа 

Статистику по атакам предоставил Центр мониторинга и управления сетью связи общего пользования (ЦМУ ССОП) ФГУП «ГРЧЦ» на конференции СПЕКТР ФОРУМ 23-24 октября 2024 года.

Текущее состояние производительности NGFW у российских поставщиков

В части производительности NGFW рекомендую посмотреть публичное тестирование компании Jet Infosystems 

Здесь видно как расходятся публичные данные из рекламы и реальные результаты тестов. Ideco в тесте серьезно просело по производительности с 5 официальных до 0,75 реальных Гбит/с.

Производительность PT NGFW на 10.10.24

 Путевые заметки рынка России в NGFW

10 октября 2024 Денис Кораблев показал результаты внутренних тестов PT NGFW.

Для такой маленькой коробки на Intel Atom без вентиляторов - 880 Гбит/с в режиме все включено это очень быстро.

То же самое для 2 юнитовой железки 96 Гбит/с - это тоже очень быстро.

Человек с юмором придумал обозначение L8. Такого термина нет в науке. Зато в PT есть )

Как поменять дату файла в каждой картинке, которую вы скачали с Google Takeout

Ситуация c Google Photo

После скачивания архива картинок из Google Photo через Google Takeout (Google Архиватор) у многих встает проблема, что все файлы с картинками и видео имеют текущую дату создания, а не реальную дату, когда фотка была сделана.

Реальную дату, когда фотка снята можно посмотреть в EXIF полях самого JPG файла. Время будет указано по часовому поясу той локации, где вы находились. Для этого в MacOS кликните два раза на сам файл JPG и когда картинка откроется для просмотра, нажмите кнопку i

Одновременно, если посмотреть json файл, приложенный к данной картинке добрыми программистами Google, то в нем есть дата и время:

  "photoTakenTime": {

    "timestamp": "1540712405",

    "formatted": "28 окт. 2018 г., 07:40:05 UTC"

  },

Однако, эта дата еще и испорчена - она написана в часовом поясе UTC (единое мировое время). И время по UTC тоже есть в EXIF заголовке. (Кстати, для меня загадка почему время не совпадает между EXIF полями в самом JPG файле: 7:39 и 15:40 - разница в 1 минуту)

Получается, чтобы поправить время из JSON файла в UTC надо еще считать и GPS координаты и поменять на нужный часовой пояс. Они там тоже есть:

 "geoData": {

    "latitude": -8.500833300000002,

    "longitude": 114.96166670000001,

    "altitude": 39.0,

    "latitudeSpan": 0.0,

    "longitudeSpan": 0.0

  },

И если вы хотите сделать все даты верными, то это грандиозный труд над 363 гигабайтами архивов, как у меня.

Что делать?

1. За 24 доллара купить MetaData Fixer for Google Takeout. Данная утилита возьмет ваши ZIP файлы, разархивирует и сама поменяет время и затем вторым шагом справит время на соответствующую Тime Zone. Это выглядит для меня странно - зачем два раза обращаться к файлу, если можно было сразу и время поменять и временную зону.

2. За 20 долларов купить Photo Exifer прямо из Apple Store:

3. Есть описание ручного и бесплатного метода. Для этого нужно скачать ExifTool и запустить команду

exiftool -r -d %s -tagsfromfile "%d/%F.json" "-GPSAltitude<GeoDataAltitude" "-GPSLatitude<GeoDataLatitude" "-GPSLatitudeRef<GeoDataLatitude" "-GPSLongitude<GeoDataLongitude" "-GPSLongitudeRef<GeoDataLongitude" "-Keywords<Tags" "-Subject<Tags" "-Caption-Abstract<Description" "-ImageDescription<Description" "-DateTimeOriginal<PhotoTakenTimeTimestamp" -ext "*" -overwrite_original -progress --ext json <DirToProcess>

или

exiftool -R -d %s -tagsfromfile "%d/%F.json" "-GPSAltitude<geodataaltitude" "-gpslatitude<geodatalatitude"="" "-gpslatituderef<geodatalatitude"="" "-gpslongitude<geodatalongitude"="" "-gpslongituderef<geodatalongitude"="" "-keywords<tags"="" "-subject<tags"="" "-caption-abstract<description"="" "-imagedescription<description"="" "-datetimeoriginal<phototakentimetimestamp"="" "-filecreatedate<phototakentimetimestamp"="" -overwrite_original="" -progress="" -ext="" "*"="" <dirtoprocess="">

4. Можно написать самому программу на Python. Вот что советует ChatGPT

import os

import json

from datetime import datetime

from PIL import Image

from PIL.ExifTags import TAGS

# Укажите путь к папке с изображениями и json файлами

folder_path = '/path/to/folder'

# Функция для обновления EXIF даты изображения

def update_image_date(image_path, creation_date):

    try:

        image = Image.open(image_path)

        # Форматирование даты в подходящий формат

        exif_date = datetime.strptime(creation_date, '%Y-%m-%dT%H:%M:%S.%fZ')

        formatted_date = exif_date.strftime('%Y:%m:%d %H:%M:%S')

        # Получение текущих метаданных EXIF (если есть)

        exif_data = image.getexif()

        exif_data[306] = formatted_date  # Tag 306 - DateTime

        # Сохранение изменений

        image.save(image_path, exif=exif_data)

        print(f'Дата обновлена для {image_path}')

    except Exception as e:

        print(f'Ошибка при обновлении {image_path}: {e}')

# Просмотр всех файлов в папке

for file_name in os.listdir(folder_path):

    if file_name.endswith('.json'):

        json_path = os.path.join(folder_path, file_name)

        

        # Чтение json файла

        with open(json_path, 'r') as json_file:

            data = json.load(json_file)

            if 'photoTakenTime' in data:

                creation_time = data['photoTakenTime']['timestamp']

                

                # Поиск соответствующего изображения

                image_name = file_name.replace('.json', '')

                for extension in ['.jpg', '.jpeg', '.png']:  # Поддерживаемые форматы

                    image_path = os.path.join(folder_path, image_name + extension)

                    if os.path.exists(image_path):

                        update_image_date(image_path, creation_time)

                        break

Важные ссылки:

Формат файла JSON из Google Takeoit описан здесь.
Все опции утилиты ExifTool описаны здесь.
Утилита на Python, которая разделяет фото и видео по двум папкам

Как правильно проводить нагрузочные тесты для NGFW: советы и рекомендации

В реальных сетях невозможно, чтобы все устройства устанавливали все сессии одновременно. Даже при тестировании на скорости 400 Гбит/с нельзя подавать все 400 Гбит/с и одновременно открывать 1 000 000 сессий в секунду, так как это приведет к DDoS-атаке, которая может вывести из строя NGFW без должной защиты. NGFW подвержены атакам, основанным на большом количестве новых сессий. Чтобы предотвратить это, разработчики внедряют защиту от DoS на интерфейсах.

Для эффективного тестирования NGFW необходимо использовать стадию RAMP UP, которая предполагает постепенное увеличение количества новых соединений через тестируемое устройство.

Этапы тестирования Throughput на IXIA

Тестирование Throughput включает три ключевых этапа: RAMP UP, STEADY и RAMP DOWN.

1. RAMP UP: На этом этапе происходит плавный рост всех параметров. Например, открывается 100 новых сессий в секунду с целью достичь 1000 одновременных сессий. Этот процесс занимает несколько минут.
2. STEADY: На основном этапе мы продолжаем подавать необходимый трафик в уже установленные сессии, имитируя типичную работу сети. Это может длиться от нескольких минут до суток, чтобы удостовериться в стабильности устройства под максимальной нагрузкой. Если тест STEADY длится всего несколько минут, это может свидетельствовать о неуверенности поставщика. Длительное тестирование позволяет выявить утечки памяти, что может привести к перезагрузке устройства.
3. RAMP DOWN: На заключительном этапе мы плавно завершаем все сессии через TCP FIN или RST. Этот процесс также занимает несколько минут.

При тестировании двух NGFW в режиме HA Active-Passive, когда активное устройство выходит из строя, весь трафик перенаправляется на резервное устройство. Даже в этом случае не все сессии будут пытаться открываться одновременно. Если первая попытка не удалась, сессия будет повторно запускаться через несколько секунд.

Если ваша цель — тестирование на CPS, возможно, вам потребуется создать 1000 новых сессий в секунду, чтобы оценить реакцию устройства, его процессора, буферов памяти, лог-коллекторов и дисков. Важно также учитывать, какой функционал включен для каждой сессии. Показатель CPS будет снижаться по мере увеличения объема анализа, выполняемого NGFW, включая DPI, URL, OCSP, SSL, IPS, AV и TI.

Bi.Zone протестировал межсетевые экраны Кода Безопасности: посмотрите результаты с IPS и без

Выражаю благодарность компании Bi.Zone и Код Безопасности за достаточно смелую публикацию результатов тестирования. Поскольку я фанат NGFW и занимаюсь защитой сетей с 1998 года, то мне было интересно узнать подробности. 

PS: Ко мне обратились коллеги из Кода Безопасности.  Оказалось, что схема стенда в отчете - верна только для тестов с 5 по 10. Тесты с 1 по 3 проводились на том же стенде, где включен один межсетевой экран. По 4 тесту сейчас без схемы непонятно что там было с чем соединено и как физически и логически тестировался LAG.

Аппаратная часть

Коллеги создали мощный стенд:

• кластер из двух L3 коммутаторов Eltex MES5500-32 версия ПО — 6.6.2.9;
• кластер из двух сетевых балансировщиков DS Integrity-100G (каждый разделен логически пополам);
• кластер из 16 устройств межсетевого экранирования IPC-R3000 версия ПО — 4.1.9
• и система управления с той же версией.

Получилось всего 21 устройство. 

Схему стенда показывали сотрудники Бизон на презентации в студии 

В качестве генератора трафика были выбраны генераторы трафика Ixia Cloud Storm и Novus 100G с генератором XGS2-HSL2 с карточками L4 и L7. Напомню, что IXIA использует FPGA для ускорения работы.

Устройство IXIA.

Функционал межсетевого экрана

Само межсетевое экранирование производилось по IP портам, то есть функционал блокирования приложений движком DPI не тестировался.

Я, конечно, хотел уже дальше не читать отчет... И я думаю вы тоже.. но природная любознательность заставила... Причина проста: большинство приложений сегодня работает по 443 порту и вам обязательно нужна контентная фильтрация, потому что по портам вы либо просто запрещаете этот порт, либо просто разрешаете. И это уже не работает. Чтобы не повторяться: прошу прочитать про это статью "Межсетевой экран нового поколения - это маркетинг", где приведены какие это 173 приложения работают на 443 порту из реальной сети. То же самое с 80 портом.

Число правил для теста выбрано 1000, что подходит для небольших заказчиков.

Но поскольку производительность ожидалась 400 Гбит/с, то 1000 правил я бы поменял на 10000. Самое большое количество правил, что я видел в своей жизни - 120000. А сколько вы видели? )
Предлагаю сделать такой же тест на 10000 и 100000 правил.

Тесты

В ходе проверок было проведено 10 различных тестов.

Основные тесты это:
1. Максимальное число успешно открытых новых TCP соединений в секунду в режиме L4;
2. Максимальное число одновременных TCP соединений в памяти в режиме L4;
3. Максимальная пропускная способность в режиме L7 (DPI) без маршрутизации, с маршрутизацией, с NAT и без NAT, с IPS и без IPS; 
4. Проверка потерь сессий при выходе из строя устройства;
5. Максимальная пропускная способность в режиме L4 на UDP;
И еще пять, что описано на 11 странице отчета.

Результат 26 Гбит/с в режиме DPI и SNAT на 1 межсетевом экране

Поскольку было 73000 транзакций в секунду, то это в среднем 35Кб на транзакцию.

Сам поток трафика состоял из различных приложений, вот их список и процент разбивки в самом потоке.

19.21% 115348 байт транзакции TLS 1.2, без расширования
15.37% 26184 байт транзакции Google Search GET Home Page - я так понимаю это тоже TLS
14.09% 6267 байт транзакции Yahoo Search GET Home Page - я так понимаю это тоже TLS
12.81% 12450 байт транзакции TLS 1.2, без расшифрования 

2.56% 217403 байт транзакции GMAIL и это тоже TLS

В итоге 64% трафика был зашифрованный поток данных в TLS, в котором чаще всего нечего проверять фильтру контента, кроме TLS Handshake где можно глянуть версии TLS, SNI и URL категории. Это все не проверялось. По распределению TLS 1.2 и TLS 1.3 в интернет лучше посмотреть на сайте ssllabs.com/ssl-pulse/ на момент прочтения статьи.

Скриншот из интерфейса IXIA, где показаны настройки тестового трафика.

Результат 4 Гбит/с IPS на 1 устройстве

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

В других тестах мы выявляли, что при подаче трафика IPS перестает блокировать атаки. И поэтому я бы добавил еще в тест страйки IXIA. И именно так - только вместе с атаками мы понимаем максимальную производительность IPS.

Скриншот IXIA где показано сколько атак заблокировано и сколько пропущено.

Павел Луговов на конференции SSTA в Бизон отлично рассказал как правильно тестировать атаки и вирусы в трафике. Также Владислав Закревский на той же конференции показывал как падает производительность Suricata при подаче трафика.

Четыре неожиданных результата

1. Выяснилось, что сам генератор IXIA максимально может выжать 200 Гбит/с в режиме L7. Поэтому пришлось выключать генерацию трафика приложений и переходить на режим L3 без проверки, что сессии были реально уставлены. 

Если кто-то из производителей говорит, что у него больше 200 Гбит/с NGFW, то спросите их чем они трафик приложений генерировали. ;-) Вдруг yandex-tank. 

Что, в общем, совпадает с datasheet этого вендора.



2. Выяснилось, что пакетный брокер тоже пропускает не бесконечно много трафика: он достиг производительность 400 Гбит/с для двунаправленного трафика. Поэтому если вы тестируете такой трафик, то вам нужно ЧЕТЫРЕ пакетных брокера. 

3. Одна система управления не справляется с журналированием такого объема трафика: 400 Гбит/с.

4. Уперлись в ограничения BGP в коммутаторе Eltex. Ну и какие-то проблемы с ICMP (подробнее описывает 32 страница отчета).

Вывод

Ставить 16 межсетевых экранов и балансировать их - непростое решение для технических специалистов. Как написано в отчете Bi.Zone, отлаживать проблемы было почти невозможно - не проходил ICMP длиной 64 байта через стенд, не было возможности запустить сниффер трафика на Eltex. В эксплуатацию я бы такое не принял.

Тестирование на UDP трафике - это самое странное, что можно делать при выборе межсетевого экрана, ведь в реальной сети такого трафика нет. Тестировать то, чего не бывает? Чтобы что? ) Я догадываюсь, что для того, чтобы впечатлить непрофессионалов. Это все равно что, тестировать производительность поликлиники, где люди входят и сразу выходят. Очень быстрая поликлиника. Скоро видимо у нас и такие будут. А полечиться? Впрочем, я уже писал про это.

Поэтому если вам где-то пишут производительность на UDP 1500 байт (или в PPS или FPS) - шлите их лесом. Так делают Check Point и Fortinet? Вот их и шлите. Это делают их люди из маркетинга. И скажите этим людям то, что написано ниже:

Самое важное в NGFW - это
Threat Protection или Threat Prevention Troughput.

Это тот самый параметр производительности, который нужен заказчику. 

Рынок РФ должен целиться в создание высокоростных устройств: которые в одном устройстве дают нужную производительность. 

В итоге, я бы лучше купил PA-3440 две штуки и поставил в кластер HA, чем всю эту огромную конструкцию из 21 устройств. Во первых займет всего 2 юнита, во-вторых производительность даже больше в тесте trhoughput и new sessions, в третьих и питания нужно меньше. И самое главное - там будет настоящий HA где будут синхронизироваться состояния сессий. А в данном решении такого не было.

Посмотрите, число одновременных сессий у Palo Alto 3 000 000, но как мы знаем это в режиме L7, когда запоминается состояние приложений L7. Число одновременных сессий в режиме L4 и L7 отличается минимум в 10 раз, потому что в режиме L7 на состояние сессий нужен буфер большего обмена при той же памяти устройства. Поэтому 10 0000 000 сессий в тесте выше в режиме L4 будет падать до 1 миллиона сессий в режиме L7.

PS: Одна важная вещь

Когда вы смотрите datasheet или когда вы смотрите тесты независимой лаборатории, то учитывайте, что все строки - это РАЗНЫЕ тесты. Не существует такого устройства, которое одновременно дает 10 миллионов TCP сессий, одновременно при этом 150000 новых сессий и одновременно при этом 28 Гбит/с. Это все результаты трех РАЗНЫХ тестов на РАЗНОМ трафике, пусть для одного и того же устройства. Подавался разный трафик и тестировалось РАЗНОЕ. В реальной жизни эти числа достигнуты НЕ БУДУТ все одновременно.

Например, тут - три разных теста. 

Для погружения в тестирование NGFW рекомендую серию из трех видеороликов

Как проходит тестирование

Как смотрят параметры CC, CPS, Throughput разные поставщики

Разбираемся с размером транзакций через тесты NSS Labs