WhatsApp в России депутаты обещают заблокировать уже в очень скором времени. Доверие к Telegram у многих довольно сильно было подорвано после публикации расследования одного издания об особенностях их протокола вкупе с подробностями о том, кто владеет их сетевой инфраструктурой и с кем он связан, да и недавнее появление Telegram в реестре РКН тоже оптимизма в их отношении не добавляет. Max - оставим для сумасшедших и безвыходных, учитывая, кто и зачем его создал. Signal - отличный мессенджер и всем хорош, но в России его тоже периодически пытаются заблокировать.

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

В наше время как self-hosted альтернативу популярным мессенджерам часто упоминают Matrix, например, с клиентом Element. На Хабре есть подробные инструкции, например вот эта: https://habr.com/ru/articles/837904/. Я попробовал, и мне не понравилось. Клиенты тормозные, через нестабильный интернет-канал все работает просто отвратительно, а сам сервер просто неповоротливый и укладывает не слишком богатый на процессор и память VPS даже всего с парой клиентов.

И тут мне вспомнилось про XMPP, он же Jabber. Он родом еще из тех времен, когда люди пользовались процессорами на 200-300 мегагерц и подключались к интернету через dial-up модемы - то есть он изначально очень нетребовательный к ресурсам. Между тем, развитие его не замерло на месте, а на сегодняшний день он умеет почти все то что требуется от современного мессенджера: хранение истории, передача файлов, аудио-видео звонки, end-to-end шифрование, и другое.

Привет, Хабр!

В настоящее время в ИТ индустрии крайне актуальна тема построения процесса безопасной разработки ПО (по англ. «Secure SDLC» или «Secure software development life cycle»). Некоторые организации и команды самостоятельно приходят к необходимости такого процесса в своих продуктах, свободно выбирают подходящий фреймворк, инструменты и выстраивают свой вариант безопасной разработки. Другие, подпадающие под внешние регуляции, вынуждены разбираться с конкретными, заранее выбранными регуляторами фреймворками или стандартами. Ко второму варианту относятся многочисленные финансовые организации, деятельность которых регулируется Банком России. В нормативах последнего с мая 2018 года стали фигурировать вопросы анализа уязвимостей и появилась аббревиатура ОУД 4.

Этой статьёй я хочу начать цикл, освещающий процессы безопасной разработки в контексте стандартов серии ГОСТ Р ИСО/МЭК 15408. Моя задача – последовательно, фундаментально и лаконично изложить этот фреймворк, чтобы уменьшить «порог вхождения» в предмет. Материал предназначен для разработчиков, менеджеров, методологов и других людей, которые в силу обстоятельств, вынуждены погружаться в безопасную разработку в контексте ОУД и требований Банка России.

Подробнее под катом…

Популярность Kubernetes растет, порог входа снижается, но вопросам безопасности порой оказывают недостаточное внимание. В этой статье разберём работу двух Open Source-утилит для аудита безопасности кластера от известных экспертов этой области — Aqua Security.

Привет, Хабр! В этой статье я попытаюсь я максимально сжатом и доступном формате рассказать про свой небольшой опыт создания homelab на Minisforum UM 560, с которыми я работаю в последнеее время.

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

О безопасной настройке Kubernetes написано немало статей, однако важно понимать, что недостаточно один раз безопасно настроить. Необходимо периодически проверять уровень защищенности K8s, а в этом лучше всего помогут сканеры безопасности, некоторые из которых мы сегодня и рассмотрим.

Анализ сторонних компонентов ПО становится всё более актуальным в свете увеличения числа уязвимостей в открытом исходном коде. Популярные репозитории содержат более 20 тысяч потенциально опасных пакетов. Сегодня мы поговорим о спецификации SBOM (Software Bill of Material), обсудим, в каких сферах она используется, какими форматами представлена и какое применение находит в информационной безопасности, в частности, в рамках SCA-анализа.

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

Прошло почти полгода с момента предыдущего релиза Dependency‑Track v4.11 (о котором мы также писали в этой статье). 1 октября вышел новый релиз Dependency‑Track v4.12.0, а на днях — релиз v4.12.1. Мы опробовали новый функционал и готовы рассказать о тех изменениях, которые показались нам наиболее интересными.

Этот релиз в основном был посвящен работе с тегами. Также был добавлен новый интерфейс для работы с нарушениями политик и, изменены правила работы с API. Но обо всем по порядку.

Практика ASOC (Application Security Orchestration and Correlation, оркестрация и корреляция безопасности приложений), интегрирующая инструменты анализа защищенности со стеком разработки ПО, сегодня широко известна в сфере безопасной разработки. О ней много писали мы и другие авторы на Хабре. Эта концепция была переосмыслена и вышла на новый уровень. Специалисты Gartner даже ввели для нее новый термин ASPM, обозначающий практику, которая вместе с анализом уязвимостей и прочих задач ASOC включает в себя управление рисками. Особенности этого подхода, а также его реализацию в продукте DefectDojo мы и разберем ниже. 

Привет, Хабр!

Меня зовут Юрий Шабалин, я один из основателей компании "Стингрей Технолоджиз" (входит в группу компаний Swordfish Security), мы разрабатываем платформу анализа защищенности мобильных приложений iOS и Android.

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

Недавно мы публиковали статью «Плагины ChatGPT, которые помогут в работе — и не только программистам». В ней говорилось о плагинах ChatGPT, которые серьёзно облегчают жизнь большинству специалистов, связанных с IT. Сегодня давайте обсудим сервисы, которые предназначены для помощи исключительно программистам. С каждым днём таких сервисов всё больше, и наиболее интересные из них мы разместили в новой подборке.

Всем привет, я не блогер и не люблю писать посты и блоги, пока.

Решил найти решение для Terraform и Proxmox. После не долгих поисков нашёл провайдер под названием terraform-provider-proxmox. Так как на русском документации не было ни где, решил перевести документацию о ресурсах на русский язык как мог. Думаю что кому ни будь будет полезно и избавит от дополнительного труда.

В этом посте:

• Использование terraform модулей
• Организуем структуру каталогов с terraform модулями для terragrunt согласно вашей инфраструктуре
• Создание/Обновление/Удаление инфраструктуры одной terragrunt командой
• Настройка в gitlab ci для запуска и сохранения terraform lock и state в gitlab
• Бекап terraform state из gitlab

Подходы к обмену данными об угрозах находятся в активной фазе формирования и стандартизации. Сегодня есть пара значимых стандартов — MISP и STIX — и целая плеяда менее значимых, которые реже используются или считаются legacy/deprecated: MAEC, IODEF, OpenIOC (Cybox), CAPEC, IODEF, VERIS и множество иных. При этом порядочное количество community-фидов до сих пор распространяется в виде txt или csv, а также в виде человекочитаемых аналитических сводок, бюллетеней и отчетов. 

В статье я разберу более-менее общепринятые практики обмена данными о киберугрозах: специализированные стандарты и форматы общего назначения, предназначенные не только для обмена TI. Какие-то сугубо проприетарные, редкие и «собственные велосипеды» форматов рассматривать не буду. Также пока за бортом оставлю тематические блоги, новостные порталы, сообщества в мессенджерах и иные источники TI в человекочитаемых форматах. Сегодня фокус на машиночитаемых форматах.

Мы в облачном провайдере T1 Cloud уделяем серьезное внимание защищенности клиентских сервисов, поэтому решили подготовить серию материалов о разработке приложений в облаке. Начнем с вводных и расскажем, что собой представляет процесс безопасной разработки программного обеспечения (Secure SDLC) и на какие нюансы стоит обратить внимание в этом контексте.

Привет, Хабр! Я Виктор, техлид продукта CI/CD в Samokat.tech. А это, :(){ :|:& };: fork-бомба, которая создаёт свои дочерние процессы бесконечно. Запуск такой штуки в контейнере без ограничений роняет всю ноду. Не используйте в проде! Если запустить в WSL, то винду тоже укладывает. Как же избежать запуска такой штуки на проде? Помогут квоты.

Давайте разберемся как работают квоты в Kubernetes. Там есть немало граблей. В этой статье поделюсь своим опытом по работе с квотами – расскажу, чем квоты хороши, что у них под капотом, в каких задачах используются и почему нужны даже в среде single-tenant.