ИБ-оксюморон.

Обращали внимание, что, оказывается, у вредоносного ПО есть полезная нагрузка?

Живите теперь с этим.

Плохие новости, пацаны.

Алгоритмы генерации контекстной рекламы научились определять приближение кризиса среднего возраста.

Машины становятся все умнее 🤔 и нам надо держать их в узде, чтобы знали, кто в доме папа.

Интересно комментируют новость о том, что ВСК оказалась не готова к кибератаке, хотя и занимается киберстрахованием.

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

Таких вопросов можно задать еще много.

Я помню время, когда IDS от ISS SiteProtector был в программном исполнении, устанавливался на WinXP, но категорически не дружил с Service Pack 2 и 3. А это во времена распространения Conficker/Kido. И не особо спешил ISS что-то с этим делать. Им было некогда, они продавались IBM'у. Или как раз продались, точно не помню. Плюс компания взяла тогда курс на ПАКи, заморозив агентские решения, и несекурность своего софтового IDS использовала для апсейла апплаенсов. По крайней мере, так мне виделось со стороны заказчика. Нам тогда пришлось навешивать port ACL на свич для защиты интерфейса управления.

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

Из плюсов: как правило, после такого инцидента у себя либо соседа работа по повышению безопасности кратно возрастает, как и готовность руководства выделять ресурсы.

Как говорят, за одного битого двух небитых дают.

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

В итоге, хвалим ИБшников, или укоризненно покачаем головой?

👍 - хвалим
🤔 - качаем головой
🔥 - чем больше мошеннических объявлений в теневом пробиве, тем быстрее снизится спрос
😁 - да там разница в доли процента, считай, плановая индексация тёмной стороны

Интересное наблюдение описано в статье на securitylab: мошенники постепенно переключаются с пенсионеров на студентов, которые:

- уже разобрались в технологиях, но не всегда способны отличить предложение легитимной работы от мошенничества

- внушаемы и склонны к импульсивным решениям

- готовы вписаться в любой блудняк за компанию, если это считается круто

Почитайте, там довольно подробный разбор и рекомендации, как определить волка в овечьей шкуре.

И обязательно передайте своим детям-студентам, либо младшим товарищам.

Вспомните себя в их годы, и трезво оцените, насколько реально вам было бы устоять против таких методов, если бы за вас взялись целенаправленно. А они еще этого не осознают.

Сегодня, 30 ноября, кроме дня защиты информации, в России отмечается ещё и день матери (последнее воскресенье ноября).

Господа ИБшники, все поздравили своих мам?

Кто забыл - хоть сообщение напишите, если звонить уже поздно, а мама поймет вашу занятость.

В тему open source и вендорских решений вспомнилась одна история.

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

- Закажи такой моторчик, он недорогой, потом вместе поставим.
- Сколько возьмешь с меня за ремонт?
- Да забей ты. Моторчик будешь заказывать - мне тоже закажи такой, у дочки на машине та же болячка.

Заказал моторчик (1300р), потом нашли время опять, поставили его на место и собрали всю конструкцию заново. Лишних деталей не осталось.

Развилка.

Вендорское решение (замена замка на сервисе):
- записываешься в удобное время
- всю работу делают работники
- детали заказывают работники
- пользуешься результатом
- платишь 20-25 тыр
- ни грамма не понимаешь, как оно все устроено

Open source (замена моторчика с соседом):
- очень зависит от надёжного community (сосед, который разбирается и готов помочь)
- требует гораздо больше времени, чтобы состыковаться с соседом 2 раза
- в промежутках ездишь с багажником, который открывается на веревочке изнутри салона, и ничего серьёзного в него не положишь
- полностью управляешь ценообразованием и результатом
- начинаешь понимать, как оно внутри устроено
- готов поддерживать это опять самостоятельно либо с помощью community (соседа)
- стоимость 2600 (по моторчику себе и соседу)

Что выбираете?

Противодействие горизонтальному перемещению (lateral movement) злоумышленника в одной подсети.

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

Какие могут быть механизмы ограничения горизонтального перемещения внутри одной подсети/VLAN:

1. Host-based firewall. 
Зачастую входит в состав EDR-агента/антивируса. Как правило, управление правилами выполняется централизованно с сервера управления AV/EDR. Функционирование и возможность отключения зависит от особенностей самого софта и операционной системы, на которой он установлен.

2. Port ACL на коммутаторах(свичах).
Работает по аналогии ACL на маршрутизаторах, но применяется к L2-портам свича. Поддерживается не всеми производителями и прошивками. Уже не зависит от софта и хостовой ОС, не получится отключить с помощью уязвимостей на них, но система управления из коробки не предоставляется. Придется раскошелиться, либо своими силами организовать централизованное управление и шаблонирование, иначе замучаетесь управлять и траблшутить. Учтите, что коммутатор имеет ограничения памяти, и бурный рост количества строк на каждом порту съедает ее лавинообразно, рискуя создать проблемы в сети.

3. Downloadable ACL. 
По сути, тот же port ACL, только приезжает на порт со стороны RADIUS-сервера после аутентификации и авторизации по 802.1x. В отличие от port ACL, централизованное управление идет из коробки, которой является RADIUS. Но работает только на 802.1x-enabled интерфейсах, и подключаемые к ним устройства должны аутентифицироваться по MAC/certificate/machine_account/user_account. Подробнее я об этом писал ранее. Риск исчерпания памяти аналогичен port ACL.

4. Switchport protected. 
Одна строчка в конфигурации порта - и взаимодействие подключенного хоста с устройствами того же VLAN на том же свиче отключается полностью, по всем портам и протоколам. Но работает это ограничение только в рамках одного коммутатора.

5. Private VLAN. 
Механизм похож на switchport protected, но имеет более комплексные настройки, вариативность в ограничениях, требует выделения VLAN. Работает в пределах всего VLAN, не ограничиваясь одним устройством.

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

Было?

👍 - было
😁 - ну, было пару раз
🤔 - как так можно, это ж нельзя
😎 - было, есть и будет (я сетевик)

Опубликовали презентации с конференции "Сетевая безопасность". Разглядываю их на досуге.
Привожу интересный слайд. Чем интересен - отмечено:

- термином "регуляторный иммунитет"

- тем, что таки называют IPS IPS'ом, не пытаясь использовать новые термины современного ИБ-маркетинга

Фраза дня, подслушанная на конференции AM Live:

Специалистов по инфобезу никогда не заменят искусственным интеллектом, потому что тогда будет наказать и посадить некого

Выдыхаем, пацаны.

Регуляторный иммунитет.

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

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

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

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

Главное - чтобы ниже нуля не получилось, а такое тоже может быть.

Интересные результаты опроса показали вчера на онлайн-мероприятии AM Live "Развитие экосистем кибербезопасности".

Почему-то участники дискуссии не озвучили вывод, который у меня напрашивается сам собой:

За прошедший год заказчики разочаровались в экосистемах кибербезопасности.

Я это понял по сумме процентов ответов, начинающихся на "да, если":

2024 - 58%
2025 - 42%

То есть, разницу не спишешь на погрешность.

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

Это значит, что над текущими экосистемами кибербезопасности еще предстоит хорошо поработать, чтобы они действительно помогли заказчику:

- имели необходимые компоненты для эшелонированной защиты
- снизили порог входа
- сэкономили бюджет
- улучшили измеримые параметры уровня безопасности

Тогда через год маятник качнется в обратную сторону.

Вышел очередной рейтинг ИБ-каналов, ссылку на него можно найти в канале Sachok.

Мой канал попал в этот рейтинг, получив второе место в категории "микроблоги". Меня заинтересовало, почему же категория именно такая, а не "авторские". Я загуглил разницу, и все равно не понял.

Вот такое выдает противоестественный интеллект Яндекса:

Авторский блог (также называется личным, персональным или частным) — это блог, который ведётся одним лицом, как правило, его владельцем. Такие блоги могут быть посвящены разным темам, например политике, быту, здоровью, бизнесу. Авторы делятся мыслями, переживаниями и эмоциями в своих записях.

Микроблог — это блог с краткими записями, которые содержат небольшое количество текста, картинку, цитату, ссылку, видео. Микроблоги созданы для того, чтобы быть в курсе дел друзей или вести публичную деятельность.

Таким образом, основное отличие между понятиями заключается в формате публикуемых материалов: в авторских блогах — это полноценные записи, а в микроблогах — короткие заметки.

Возможно, и был период, когда канал можно было назвать микроблогом, но мне сейчас порой не хватает времени набрать текст за время поездки в метро на работу или с работы (45 минут).

В целом, вопрос классификации не особо критичен, но телеграм-каналы создают те, кто склонен к текстовому эксгибиционизму, поэтому вам пришлось и эти размышления прочитать в довесок к остальным.

Не особо правильный у меня оказался выбор конференций, на которых я выступал с докладом о том, как правильно подготовить свою сеть к защите от DDoS. Создалось ощущение, что аудитория оказалась не того профиля. Но я буду выкладывать здесь свои рекомендации, вы точно читатели что надо. Мои советы подойдут всем, независимо от того, какого провайдера AntiDDoS вы используете.

1. Разные NGFW на стыке с интернет и выполняющие внутреннюю сегментацию

DDoS-атака прилетает со стороны интернета, и может вызвать отказ в обслуживании не только одного сервера, но и всего NGFW. При этом все межсегментные взаимодействия будут нарушены. Поэтому лучше разнести функционал пограничного и межсегментного NGFW на разные устройства, хоть это и будет немного дороже. Но при падении пограничного межсегментные взаимодействия будут работать, как работали.

Обратите внимание на картинку. Я предложил сегменты DMZ1 и DMZ2 приземлить на пограничный NGFW, но это на ваше усмотрение. Более того, если ресурсы из этих DMZ критичны для внутренних сегментов (так не должно быть, на то и DMZ, но мало ли), то лучше их приземлить на внутренний NGFW, а пограничный оставить двуногим. Тогда в случае его падения из-за DDoS потеряется только связь с интернетом. Неприятно, но хоть не парализует работу внутри.

А вы каким бы оставили пограничный МСЭ?
👍 - так, как на картинке
🤔 - двуногим

#NGFW #DDoS

Продолжаем рекомендации по подготовке своего внешнего периметра к отражению DDoS-атак.

2. Разделите сегменты по направлению трафика в/из интернет.

Например:
- MX домена и smarthost
- DMZ-сервера и точки выхода в интернет (NAT-pool, proxy)
- Авторитативный и рекурсивный DNS

должны быть на разных IP-адресах или даже в разных подсетях, чтобы можно было применять к ним правила на центрах очистки от DDoS.

Почему так.

В общем случае TCP-сессия между клиентом и, например, web-сервером, строится в 3 хода (тройное рукопожатие):

SYN (client IP, src port >1024 —> server IP, dst port 80)

SYN/ACK (server IP, src port 80 —> client IP, dst port >1024)

ACK (client IP, src port >1024 —> server IP, dst port 80)

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

См. картинку, на ней слева защищаемые ресурсы.
По легенде и стрелочкам можете определить, кто из них клиент, а кто - сервер.

Соответственно, если в сети находятся только сервера - можно запретить пакеты SYN/ACK полностью. Таким образом защитив ресурсы от SYN/ACK-флуда на 100% и абсолютно не нарушив работу сервиса. Но только в том случае, если сервер сам не инициирует подключение к интернет-ресурсам, превращаясь в клиента.

Аналогично для тех, кто по жизни клиент, можно без вреда запретить чистые SYN- и чистые ACK-пакеты, защитив их от DDoS-атак типа TCP SYN flood и TCP ACK flood на 100%. Но это если на них нет опубликованных сервисов.

Поэтому разделить их и сообщить об этом своему провайдеру защиты от DDoS будет очень разумным решением.

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

Так что, разделяй и властвуй.

Ну как, получается следовать?

👍 - разделяю и властвую
😎 - разгильдяй и господствую над хаосом
🤔 - я только спросить

#DDoS

Продолжаем готовить внешний периметр для устойчивости перед DDoS.

3. Организуйте выход в Интернет серверов DMZ через прокси.

Казалось бы: зачем? Ведь это сервера, и так доступные с улицы, нелогично городить огород с их выходом в интернет через прокси.

Но причины есть. Одну из них я описал в предыдущем сообщении. По сути, это частный случай разделения сегментов по принципу "кто инициирует подключение".

Есть еще одна, менее очевидная, причина, и она касается даже не DDoS, а других аспектов кибербезопасности.

Кто работает с решениям WAF/WAAP, не раз видели в логах попытки эксплуатации уязвимостей RCE, которые пытались запустить wget для скачивания вредоноса с последующим его исполнением. Расчет как раз на то, что сервер с опубликованным на улицу веб-интерфейсом сам имеет доступ в интернет ради получения обновлений. Но если вы обновляете его через корпоративные репозитории, либо хотя бы через прокси, то злоумышленника будет ждать боль и страдание. Даже если RCE проэксплуатируется, то wget, не настроенный на использование прокси, будет долбиться лбом в NGFW, который его не пустит. Если еще и на прокси этому серверу доступ ограничен только к определённому набору ресурсов (а так и надо делать), то даже настроенный на использование прокси wget не даст скачать "полезную нагрузку" зловреда, и информация из лога благополучно пополнит TI-фиды вашего SOC. Который еще и заметит исполнение shell-команды в логах веб-сервера, заставит админов сервера пропатчиться либо применить workaround, а админов WAF - обновить либо написать соответствующее правило для блокировки подобных поползновений.

Ваш SOC ведь собирает подобные логи и имеет правильные плейбуки реагирования? Так ведь?

😎 - еще бы, собираем отовсюду, плейбуков на всех хватит
🤓 - собираем только с веб-серверов, с WAF не собираем, он же сам отразит
😁 - собираем только с WAF, правда, хз, что с этим делать
👍 - все собираем, но только храним
😱 - ничего не собираем
🤔 - да кому я нужен?

#DDoS #SOC

Продолжаем готовить внешний периметр для устойчивости перед DDoS.

4. Синхронизируйте ACL вашего пограничного NGFW и центра очистки от DDoS

Даже если вы уже

- разнесли NGFW на пограничный и внутренний,
- разделили сегменты по принципу "клиент или сервер"
- научили DMZ-сервера ходить в интернет через прокси

то осталась еще немалая часть работы, которая требует поддержания политик на центре очистки в соответствии с правилами вашем пограничном NGFW. У вас появляются новые ресурсы, упраздняются старые, открываются и закрываются протоколы и порты взаимодействия. И так будет постоянно, поэтому необходимо выстроить процесс управления сетевыми доступами, в который на этапе исполнения включается также команда, выполняющая настройки на центре очистки, если хотя бы один из участников сетевого взаимодействия имеет белый IP-адрес. В зависимости от вашей реализации это может быть создание тикета, заявки, либо хотя бы просто письма.

Тогда ACL вашего NGFW и центра очистки будут синхронизированы, весь явно мусорный трафик срежется, и останется только отражать более интеллектуальными алгоритмами DDoS на те протоколы, которые разрешены в ACL.

Готовы?

👍 - готовы
😎 - не только готовы, но и вовсю делаем так
😐 - не готовы
🤔 - многовато действий, как для каких-то там DDoS-атак