Информационная безопасность

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

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

Второй — когда все стандарты формально соблюдены. Именно тогда возникает самый правильный вопрос: «А наша система действительно защищает компанию или мы просто красиво закрываем чек-листы для аудиторов?»

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

Такой инструмент существует.

Всем привет, в этой статье я расскажу, о том как у многих прокатывает обойти белые списки, и в чем вообще корень проблемы, если вы "чайник" и не хотите запариваться со всей настройкой в <a href="#services"> конце статьи</a> привел сервисы которые упоминают в обсуждениях

Прямой коннект VLESS + Reality до Европы (Амстердам, Германия, Финка) почти у всех под шейпингом. ТСПУ освоили новую тактику: они не рвут сессию через RST, а просто «фризят» её. Как только объем данных в одной TCP-сессии переваливает за 15-20 КБ, пакеты перестают приходить. Коннект висит, пока клиент не отвалится по таймауту.

Когда волна компрометаций в NPM накрывает экосистему, выясняется неприятное: «знать свои зависимости» недостаточно, если вредонос успевает отработать ещё на этапе установки и сборки. В этом разборе — почему популярные SCA/SBOM-сканеры то молчат, то шумят ложняками на кейсе Shai-Hulud, как решает (или не решает) вопрос выбор источника уязвимостей, и почему malware-advisories оказываются невидимкой для части инструментов. В итоге речь не про очередной чеклист, а про реальные границы автоматического контроля цепочки поставок.

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

Мы продолжаем серию публикаций, посвященную своду знаний по кибербезопасности - Cybersecurity Body of Knowledge (CyBOK). В Главе 3 данного свода знаний описываются основные регуляторные нормы и принципы международного права, которые имеют отношение к кибербезопасности и могут применяться при оценке киберрисков, управлении ИБ, расследовании киберинцидентов. Сегодня – шестая часть обзора Главы 3 CyBOK, в которой описываются правонарушения, рассматриваемые при оценке рисков привлечения к ответственности за причинение вреда в сфере кибербезопасности.

Это руководство объединяет две методологически таблицы - одну для концептуальных моделей (OSI и TCP/IP) и одну для конкретных протоколов и технологий. При обнаружении ошибок / неточностей - сообщите в комментариях, после проверки действительно ли есть ошибки / неточность - информация дополниться.

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

Размер бюджета на ИБ, вероятно, действительно напрямую влияет на защищенность компании. У больших компаний с дорогими департаментами ИБ дела с защитой действительно обстоят хорошо: больше персонала, выше квалификация, лучше решения (но это не точно). Однако этот факт никак не доказывает того, что в небольших организациях (условно 150–200 хостов) ситуация с защитой от кибератак должна быть обязательно плачевной. 

Парадокс в том, что даже при полном отсутствии средств на ИБ организация всё равно может — и должна — защищаться. Эта статья — не про идеальную безопасность, а про то, что приемлемую ИБ вполне можно построить с использованием бесплатных и встроенных средств. 

Привет, Хабр! Меня зовут Сергей Померанцев, я работаю в компании Avanpost и являюсь владельцем продукта Avanpost SmartPAM.

Я заметил, что на Хабре не так много действительно интересной информации о системах класса PAM (Privileged Access Management). Попробую это исправить и постараюсь периодически, скажем, пару раз в квартал, публиковать что-нибудь любопытное.

Итак, о Privileged Access Management. В целом, этот класс ПО оформился как обособленный, самостоятельный, в начале 2010-х гг, то есть – давно. Как это ни странно для столь зрелого направления, разные продукты абсолютно по-разному реализуют ключевую функцию: встраивание в привилегированную сессию и контроль происходящего там. Как следствие, одна и та же строчка о поддерживаемом протоколе в спецификациях (скажем, что поддерживается HTTP или RDP) у разных производителей означает совершенно разный пользовательский опыт.

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

Очевидно, что для решения задач управления привилегированным доступом PAM должен как-то встроиться в «механику» происходящего в сессиях. При этом привилегированные сессии разных типов имеют колоссальные различия в технологиях, при помощи которых организуются подключения (например, сеанс в конфигураторе 1С с точки зрения технологий – совсем не то же самое, что подключение к веб-консоли администрирования Unisphere дисковых массивов Dell/EMC Unity).

Привет, Хабр! В AKTIV.CONSULTING я руковожу центром технической экспертизы по анализу защищённости.  В фокусе нашей команды — спектр задач по проверке безопасности ПО, тестирование на проникновения внешнего и внутреннего периметра организации, проведение Red Team, расследований киберинцидентов, а также внедрения процесса DevSecOps. Проанализировав результаты сотен тестов на проникновение, мы увидели четкую закономерность: большинство успешных атак объясняются не сложностью инструментов злоумышленников, а игнорированием базовых мер защиты. Реальность такова, что злоумышленники берут то, что плохо лежит: используют слабые пароли, вовремя не закрытые уязвимости и эксплуатируют человеческий фактор. Сложные многоступенчатые атаки чаще бывают исключением. Как правило, злоумышленники используют атаки, выстроенные с помощью стандартных методов и утилит.

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

Каждый раз, скачивая новое приложение, мы своего рода совершаем акт доверия, вручая разработчику ключи от своей цифровой жизни: личные данные, контакты, банковские реквизиты, а иногда и доступ к деньгам. Но что, если вместо безобидного фонарика или игры вы устанавливаете на свой смартфон цифрового шпиона?

В статье расскажем по каким признакам отличить поддельное приложение от настоящего, какие разрешения в вашем смартфоне самые опасные, и почему доступ к фото для игры может быть «троянским конем». А также, как провести аудит разрешений на Android и iOS и отозвать доступ у слишком «любопытных» программ.

Данная статья была впервые опубликована в июле 2024 года. В ней разбирается, пожалуй, самый популярный миф о свободном программном обеспечении. Будто критерии свободы, обозначенные проектом GNU лишь снижают свободу пользователей. Поскольку этот миф столь же живуч, что и иные мифы о свободном ПО, разобранные в статье о соотношении свободы и приватности с безопасностью, — данная работа также не потеряла актуальности. Ее текст остался без изменений, однако, как и в случае с упомянутой статьей, некоторые ссылки на источники были заменены на более удобные.

Привет, Хабр! Меня зовут Дмитрий Федосов, я руковожу отделом наступательной безопасности в Positive Technologies. В этой статье мы с ведущим специалистом нашего отдела Владиславом Дриевым расскажем про автоматизацию рутины в пентесте на основании нашего опыта построения результативной безопасности.

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

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

Привет, Хабр! Меня зовут Александр Колесов, в Бастионе я руковожу направлением развития в департаменте тестирования на проникновение. Мы профессионально ломаем то, что другие старательно защищают. Разумеется, с разрешения владельцев.

Сегодня предлагаю поговорить о внутреннем пентесте — одной из самых недооцененных услуг на рынке. А точнее, о современном подходе к нему — Assumed Breach («предполагаемое нарушение»). В рамках этого метода мы отталкиваемся от предпосылки: «а что, если компания уже скомпрометирована?».

Я уже рассказывал на SOC Forum 2025, почему классический внутренний пентест часто не отвечает на реальные потребности бизнеса и как Assumed Breach позволяет это исправить. В статье поделюсь записью этого доклада и покажу, как максимизировать пользу от внутренних пентестов с помощью Assumed Breach.

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

Меня зовут Арина Волошина, я AppSec-инженер в YADRO и занимаюсь тестированием безопасности телеком-продуктов: базовой станции, контроллера базовых станций и системой управления элементами сети. Мы внедрили много разных видов тестирования в эти продукты, но этого оказалось недостаточно. В своих научных исследованиях я занималась генетическими алгоритмами, поэтому решила применить академические знания на практике и реализовать генетику в фаззинге. Что из этого вышло — читайте под катом.

Мониторинг целостности файлов выглядит простым ровно до тех пор, пока не пытаешься сделать его полезным для расследований и одновременно не убить прод. Сканы пропускают «изменил и откатил», inotify не даёт нужного контекста, auditd начинает стоить слишком дорого. В Datadog пошли через eBPF и получили то, чего не хватало: реальные события с привязкой к процессам и контейнерам — а вместе с ними и новую проблему масштаба, когда счёт идёт на миллиарды событий в минуту. В статье разберем, как они перенесли часть логики фильтрации в ядро, научились отсеивать шум ещё до user space и превратили поток телеметрии в сигнал, который можно выдержать.

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

В этой статье разберём исследование от компании Anthropic, которое демонстрирует практическую возможность вскрытия «черного ящика» больших языковых моделей для обеспечения их контролируемости и безопасности с помощью разреженных автоэнкодеров (SAE — Sparse AutoEncoders). И в конце, попробуем поуправлять поведением модели — заставим думать, что она Санта Клаус 🎅.

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

Всем привет, я Daytrift Newgen, и вот моя простая и весьма смешная история обнаружения байпаса от начала исследований до патча и advisory.

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

В самом конце декабря в Германии прошла 39-я по счету конференция Chaos Communication Congress, по традиции получившая краткое обозначение «39c3». Из всех крупных мероприятий, связанных с информационной безопасностью, Chaos Communication Congress, возможно, единственная сохранила, скажем так, «хакерский дух»: когда потайные особенности работы устройств и программ исследуются не потому, что важно, и не из-за денег, а просто из-за здорового любопытства. Именно «хакерской» стала презентация двух исследователей, которые довольно долго изучали особенности работы стиральных машин.

Сразу отметим, что речь не идет об умных бытовых приборах. Первая половина презентации была посвящена изучению принципов работы стиральной машинки Miele, которой уже больше 20 лет. У автора исследования была простая мотивация — изучить внутреннее устройство стиральной машины: после двух десятилетий работы она перестала отжимать белье. В процессе он разобрал проприетарный протокол коммуникации с устройством, нашел секретные коды для получения доступа к диагностическим данным и даже смог сдампить прошивку устройства.