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

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

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

Интересное наблюдение описано в статье на 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