[Смешанные] Сборка пользовательских/официальных правил для nuclei [1777 файлов]

Многих нет в официальном репозитории nuclei-templates (последняя смешка с оф.репозитория добавлялась сюда три релиза назад)

https://gitlab.com/gitlab-com/support/toolbox/strace-parser

"A tool to analyze raw strace data.
Similar to output provided by the -c flag, but with more detail and capable of handling multiple PIDs.
It can generate the following metrics:

A summary of the top processes, including total syscalls and time spent
Statistics on each type of syscall made for a given number of proccesses
Details of a process, including the statistics, files opened, and related PIDS
A list of all programs executed in session
A list of all file opened in session
A list of the duration spent opening files in a directory and its children
A list of all read/write calls made in session
A histogram showing the quantized distribution of execution times for a given syscall
A pstree style graph of traced processes

The parser will attempt to find all sibling threads of traced processes. For a command executed with or after
the start of the trace this will always be accurate. On existing processes some threads may not be found.
The parser checks for futex calls with a *_PRIVATE flag that share an uaddr; if these do not occur the
parser cannot relate the processes."

_______________________________

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

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

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

Threat Modelling & Supply-Chain (Part 1: Assets)

Безопасность разработки стала весьма широким доменом в плане охватываемых проблемных зон и инструментов. За последние полгода в одну из решаемых задач попала митигация рисков, связанных с атаками на цепочку поставок (supply-chain attack). Для тех, кто следит за новостями, сразу вспоминаются атаки на SolarWinds (хотя в реальности примеров подобных атак значительно больше). Тем не менее, как связать примеры подобных атак с собственной инфраструктурой и цепочкой поставок не всегда очевидно (чем активно пользуются производители решений SCA).

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

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

Раскидывая все процессы разработки на схеме (мне нравится обычный draw.io с плагином dfd) мы имеем архитектуру нашего сборочного конвейера совместно с этапом раскатки. Детализация схемы зависит от вашего погружения вместе с DevOps командами. Модель угроз можно декомпозировать вплоть до всех компонентов Kubernetes. Чтобы точно убедиться, что мы ничего не пропустили, мы можем расписать процессы отдельно:

CI Master:
- Вызов сборки
- Конфигурация сборки
- Получение секретов git из встроенного хранилища секретов
- ....

К каждому процессу подписываются защищаемыми нами активы:

A01: секреты git
A02: код бизнес-приложения
A03: итоговый артефакт
A04: зависимость
...

Совместно с определением процессов и активов рекомендуется определить так называемые доверенные зоны (trusted zones). Они помогают определить логические границы, за которых ответственны те или иные администраторы систем, а также поверхности атаки злоумышленника в случае, если он окажется внутри инфраструктуры.

#threatmodeling #dev #ops #talks

Threat Modelling & Supply-Chain (Part 2: Threats & Threat Actors)

Следующим этапом определим пользователей наших процессов. Эти же пользователи будут нашими потенциальными нарушителями (threat actors). Рассматривая атаки на цепочки поставок это могут быть внутренние нарушители (разработчики, администраторы CI и CD систем, администраторы кластера, сопровождение ОС и так далее) и внешние (пользователь, который может повилять на общедоступные репозитории).Также на этом этапе мы понимаем, где еще могут использоваться наши защищаемые активы (секреты и код на рабочих станциях).

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

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

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

В следующих постах мы поговорим про приоритизацию угроз и формирование требований ИБ по результатам модели угроз. Если вы уже хотите попрактиковаться, то можете почитать пример моделирования угроз для облачного приложения в AWS с использованием STRIDE. Хорошим материалом является также Threat Modeling Training от компании Segment, где есть простые и понятные слайды по всем этапам моделирования угроз.

#threatmodeling #dev #ops #talks

bilibili/LastOrder-Dota2
Dota2 AI bot
Language: Python
Stars: 85 Issues: 0 Forks: 5
https://github.com/bilibili/LastOrder-Dota2

Искуственный интеллект™ (модель машинного обучения) переводит просьбы на английском языке в питон-код для обработки и представления данных.

Срочно нужен такой же для перевода с русского на 1С.

https://github.com/deepklarity/jupyter-text2code

https://github.com/MaksimDzhangirov/complete-gRPC/blob/main/SSL_TLS_lecture_rus.md
Подробное описание SSL/TLS и его криптографической системы

Exo - инструмент для логирования и работы с процессами в системе.

https://github.com/deref/exo
https://github.com/deref/exo/blob/main/doc/guide.md

#Exo

Обновил реализацию Web Ring для Telegram.
Из основного: переделал систему управления кольцом. Теперь все управление лежит на плечах Ring Master - для этого в бота были добавлены удобные кнопочки управления.
Также, исправил какие-то баги и что-то улучшил.

линк на Github проекта
линк текст про Web Ring

StackFinder: A VSCode extension to help you find and use Stack Overflow answers

/r/datascience
https://redd.it/p0e2zb