PURP

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

Ого! На нас подписан самый крутой чел в кибербезе 💗

Победители розыгрыша:
1. Алексей
2. Виктор Глебов
3. Богатырь
4. n1Mp
5. L

Грац всем! Вам напишет @ancotir в ближайшее время чтобы по доставке уточнить инфу. И только она. Если кто-то пишет другой — хекайте.

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

пс, там это, во вторник уже журналы дарить будем, еще есть возможность поучаствовать 🏃‍♀️

Судя по вашим ответам я щас дичайше вкину на вентилятор 😂
Если какие проблемы к автору вопроса идем в канал @architect_insights и беседуем 👊

➡️ Итак, правильный вариант — третий. Но я не сомневался, что вы ответите как ответили.

Тот случай, когда обе стороны говорят по делу, просто спорят о разном. Обезличивание — это не бинарное суждение «данные защищены / не защищены». У него есть уровни, и разница между ними принципиальная:

▶️ Псевдонимизация — например, заменили ФИО на «сотрудник №1247». Данные все еще связаны между собой, и по связям возможно восстановить человека;
▶️ Анонимизация — связи разорваны так, что восстановить исходную личность невозможно;
▶️ Синтетика — данные полностью сгенерированы, примерно отображают реальные данные, но ими не являются.

В нашем кейсе инженер сделал именно псевдонимизацию, а называет это обезличиванием. Это не одно и то же — и вот тут безопасник прав, потому что матрица прав — это не просто табличка, это целая карта организации. По ней читается, сколько у вас отделов, кто с чем работает, где узкие места, у кого концентрируются критичные доступы. ФИО убрали, а структура осталась — для того, кто будет планировать атаку, это намного ценнее списка фамилий.

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

Так почему третий вариант, а не четвертый?

Потому что вводных данных здесь достаточно — нам известно и что уходит в модель (матрица прав), и в каком виде (псевдонимизированном), и зачем. Не хватает не данных, а правильно поставленного вопроса. Спор «пускать ИИ или не пускать» ложный. Настоящий вопрос — как пускать:

▶️ локально развернутая модель, из которой наружу не уходит ничего;
▶️ выборка вместо всего массива — открытая модель предлагает подход на фрагменте, а вся дальнейшая обработка выполняется вручную.

Два варианта, при которых инженер получает свой каркас, а безопасник — свой периметр.

Вы действительно решили спросить у народа, кто прав — разрабы или безопасники?

Ставьте ❤️ если вы за iOS и 🔥 если за Android, посмотрим сколько нас!

🏃‍♀️ Ну чо народ, погнали с новой задачкой?

Придумали вам тут с Александром @architect_insights ситуацию. @Lobrigate просьба не подсказывать, я и так знаю что ты вкинешь.

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

Инженер предлагает ускорить разбор всего этого через выгрузку обезличенной матрицы прав (без ФИО, без реальных логинов — только «сотрудник №1247, отдел, набор доступов») и скормить ее LLM, чтобы та помогла выявить паттерны и предложить черновик ролевой модели. Дальше все делается руками, глазами, через ревью там всякие и прочее. Но стартовать хочется не с чистого листа, а с предложенного иишкой каркаса.

Безопасник резко против, поскольку наружу уходит структура прав компании. Хоть и обезличенная, но это карта того, кто к чему имеет доступ.

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

➡️ Товарищи знатоки, внимание, вопрос. Кто прав?

Вариант 1
Инженер. Безопасник для перестраховки перебарщивает с запретами и ограничениями, что сильно тормозит процессы разработки.

Вариант 2
Безопасник. Структура прав — слишком важная информация даже в обезличенном виде. Желание инженера ускориться создает слишком много рисков для компании.

Вариант 3
Оба правы, с оговорками.

Вариант 4
Данных недостаточно для однозначного ответа.

UPD: Вариант 5
Подписчек слезно умоляет добавить вариант «Оба дундуки, всех заменить дипсиком». Кто мы такие, чтобы ему отказывать?

— 🔥 — если правильный первый вариант,
— ❤️ — второй,
— 👍 — третий,
— 🤔 — четвертый,
— 💩 — пятый.

Завтра дадим вам правильный ответ. ⏳

Ну все, теперь короче все хорошие ибешники объединятся в одного большого ибешника и победят всех нехороших ибешников хакеров и мошенников и наступит мир и благодать на Земле.

Запомните этот твит.

Коллеги из Бастиона наконец-то закончили пошаговый подробный гайд по созданию РБПО в случаях когда бюджет на ИБ составляет 50 апельсинок на карте Пятерочки.

Это не прям чтобы совсем «без бюджета» история, как заявляет автор цикла, скорее с минимальными затратами по сравнению с тем, каких денег могут стоить зрелые проработанные пайплайны. РБПО итоговый базовые нужды закрывает. В любом случае, это гораздо лучше, чем когда у вас совсем ничего нет.

Читаем и берем на вооружение.

➡️ Что такое РБПО, зачем нужна и как выглядит минимальный конвейер.

➡️ Про создание виртуальных машин в VirtualBox для сервисов безопасной разработки ПО.

➡️ Про разворачивание самих сервисов.

➡️ Базовую конфигурацию: настройку GitLab и GitLab Runner, подготовку Nexus к приему артефактов и т.д.

➡️ Написание GitLab CI/CD-конвейера, автоматизирующего сборку приложения и проверки безопасности.

➡️ Подготовку диска для хранения бэкапов и автоматизацию создания резервных копий виртуальных машин.

➡️ Проверку уязвимого приложения Reactvulna через собранный пайплайн.

#blue_team

Итак, правильный вариант — четвертый. ⭐️

И @glinkinivan оч подробно объяснил, почему. Мотаем на ус.

Есть 4 варианта работы с рисками:

— Принять риски (оставить как есть),
— Уменьшить риски (митигация) — оставить риск, но внедрить, например мониторинг,
— Отказ от риска (полное его исключение),
— Передача риска (например, в страховую компанию).

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

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

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

Если понравилась такая тема, ставь ❤️, будем с @Lobrigate еще подобные истории искать.

Не стесняйтесь свои задачки мне или @Lobrigate в лс присылать, тоже будем в канал закидывать на саморазвитие.

#red_team

Мы тут вместе с @glinkinivan сидели за чаечком и решили, что вам слишком скучно живется. 😁 Решили немного погрузить в нашу работу и подкинуть тему на обмозговать из собственной практики.

➡️➡️➡️ Ситуация

Представьте, что вы проводите тестирование на проникновение и оценку защищенности среднего размера компании. В ходе работы вы обнаружили неправильную настройку (с вашей точки зрения) СКС, которая позволяет любому пользователю из одного VLAN беспрепятственного общаться с другим VLAN: видеть хосты и их открытые порты, заходить на внутренние ресурсы и т.д. Межсетевой экран (firewall) отсутствует, сетевой доступ никак не ограничен и сеть, по факту, является плоской.

Исследователи доложили Заказчику о найденной уязвимости, подкрепили это PoC и рисками, которая несет данная уязвимость.

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

Вот вам четыре варианта ответов.

➡️➡️➡️ Вопрос: при изложенных обстоятельствах, как вы думаете, кто прав в данной ситуации:

Вариант 1

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

Вариант 2

Заказчик — ему известно о данной особенности СКС, а данная сеть специально так настроена для удобства, оперативности работы и прибыли. ИБ осуществляет мониторинг всего трафика и держит его под контролем. Указание исполнителя на необходимость срочного исправления является желанием показать свою работу и получить «легкие» деньги.

Вариант 3

Оба варианта являются верными с небольшими оговорками.

Вариант 4

Недостаточно данных для дачи правильного ответа.

В лимиты телеги они не влезают, так что вместо опроса голосуем эмодзами:

— 🔥 — если правильный первый вариант,
— ❤️ — второй,
— 👍 — третий,
— 🤔 — четвертый.

Завтра дадим вам правильный ответ. ⏳