Agile Application Security (Рубрика #Security)

Три года назад я прочитал книгу "Agile Application Security", чтобы понять как можно встроить безопасность в процессы современной разработки.
Книга оказалась крутой — картинка в моей голове сложилась, но вот написать краткий обзор руки дошли только сейчас:)
Изначально я думал, что книжка поможет мне ознакомиться с текущим состоянием дел в безопасности. Но на самом деле авторы подошли с большим размахом к этой теме. В книге они поставили перед собой задачи:
- Рассказать разработчикам о том, как выглядит современные подходы к безопасности
- Рассказать олдскульным безопасникам как выглядит современная разработка и что запретительный подход из прошлого перестал работать при появлении современных подходов, например, CI/CD
И у авторов получилось:)
Подробности можно прочитать в обзоре https://apolomodov.medium.com/review-agile-application-security-e1c18ed65c19

#Software #SoftwareDevelopment #Security #DevSecOps #ExternalReview

Безопасность разработки в Agile-проектах (Agile Application Security: Enabling Security in a Continuous Delivery Pipeline)

Три года назад я прочитал эту превосходную книгу. Тогда я думал, что книжка поможет мне ознакомиться с текущим состоянием дел в безопасности. Но авторы подошли с большим размахом и поставили перед собой задачу:
- рассказать разработчикам о том, как выглядит современные подходы к безопасности
- рассказать олдскульным безопасникам как выглядит современная разработка и что запретительный подход из прошлого перестал работать при появлении современных подходов навроде CI/CD

В самом начале идет краткий экскурс в современную разработку в главах:
Глава 2. Элементы гибких методик
Глава 3. Революция в методах разработки - присоединяйтесь!
Глава 4. Работа с существующим жизненным цилком разработки
Эти начальные главы дают настолько хороший экскурс, что они будет полезны не только безопасникам, но и самим разработчикам, работающим в рамках гибких подходов, т.к. иногда следование процессам преващается в карго-культ или формопоклонничество как это называл Фейнман:) Поэтому иногда стоит вспоминать, что важен не сам процесс ради процесса, а те результаты, которые он помогает достигать.

Дальше идут главы про безопасность
Глава 5. Безопасность и требования. Тут речь идет о том, что безопасность - это просто еще одна область нефункциональных требований и ее стоит встривать в процесс работы над системой с самого начала как, например, вопросы производительности конечного решения или его удобства
Глава 6. Гибкое управление уязвимостями. Тут речь идет о том, как относится к уязвимостям, как учитывать их и как планировать их устранение, а также как связано тестирование и безопасность
Глава 7. Риск для гибких команд. Вся глава посвящена основам риск менеджмента в контексте вопросов безопасности. Если вы уже знакомы с этой областью знаний, то сложно будет найти что-то новое
Глава 8. Оценка угроз и осмысление атак. Одна из самых содержательных глав по безопасности:)
Глава 9. Построение безопасных и удобных для пользователей систем. Здесь рассматриваются варианты проектирования безопасности так, чтобы она приводила в итоге к продукту, которым нельзя пользоваться, т.к. средства безопасности рушат весь user experience
Глава 10. Инспекция кода в интересах безопасности. Здесь рассматриваются варианты code review причем с точки зрения того, как их использовать правильно, чтобы повысить безопасность конечного решения
Глава 11. Гибкое тестирование в безопасности. Здесь речь о том, как тестировать код, инфраструктур и CI/CD пайплайн в интересах обеспечния безопасности. Авторы упоминают несколько инструментов, которые могут быть полезны практикующим специалистам
Глава 12. Внешние инспекции, тестирование и рекомендации. Лучше всего про содержание этой главы говорит следующая фраза, завершающая главу: "Если вы не собираетесь использовать внешние инспекции, чтобы учиться у экспертов, то только зря тратите их время и свои деньги"
Глава 13. Эксплуатация и безопасность. Здесь рассматриваются вопросы мониторинга и обнаружения вторжений, реакций на инциденты, защиты CI/CD пайплайно и работы с секретами:)
Глава 14. Сообщение нормативным требованиям. Здесь расматриваются 2 подхода:
1. Подход на основе правил (Пример: PCI DSS)
2. Подход на основе результатов (Пример Reg SCI)
Эту главу полезно прочитать, чтобы понять разницу в этих подходах, а заодно ознакомиться с человеческим описанием того, что за правилы описаны в PCI DSS, которые часто поминауются всуе по поводу и без:)
Глава 15. Культура безопасности. Очень хорошо про культуру. Замечательно про "тяни, а не толкай" и принципы эффективности:
1. Содействуй, а не блокируй;
2. Прозрачная безопасность;
3. Не ищите виноватых;
4. Масштабировать безопасность, усиливать фланги;
5. Кто - не менее важно, чем как
Глава 16. Что такое гибкая безопасность. Здесь каждый из 4-х авторов книги рассказывает свою историю и делится тем, как пришел к вопросам безопасности в разработке и кристализует свои мысли относительно темы книги

#Sec #Security #Agile #Processes #Software #SoftwareDevelopment #DevSecOps

It Wasn’t Me - #SecureYourAccount

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

#Security #Humor

[SafeCode Live] Secure by design

Сходил недавно на запись выпуска SafeCode Live, где мы говорили про подход Secure by design (SBD) или конструктивную безопасность в разработке продукта.

Мы интересно пообщались на темы что это такое, зачем нужно, что делать "если уже все сделано небезопасно", как прокачаться в безопасности и так далее:)

На стрим нас было четверо
- Алексей Федулаев, ведущий подкаста, руководитель направления автоматизации безопасной разработки в Wildberries.
- Сергей Рогачев, руководитель отдела разработки безопасной платформы в Лаборатории Касперского.
- Екатерина Рудина, аналитик в Лаборатории Касперского. Работает в департаменте перспективных технологий в области исследования угроз, моделирования и оценки рисков.
- и автор этого канала

Достаточно непривычно было выступать на этот раз не в качестве эксперта, а скорее в качестве гостя, который заинтересован в том, чтобы практики security присутсвовали в SDLC и не в финальной стадии, а начиная с работы с требованиями, оценки рисков, проектирования решения и так далее. В итоге, я сам с удовольствием слушал других спикеров и даже добавил себе в reading list пару книг, что они рекомендовали, но начать решил с базовой «Software Security» от Mathias Payer, которую порекомендовал Сергей.

#Security #SRE #Software #SoftwareDevelopment #SoftwareArchitecture #DistributedSystems #Architecture

The State of Application Security 2023 • Sebastian Brandes • GOTO 2023

Отличный доклад для воскресного утра про Application security от Себастьяна, ко-фаундера и CEO стартапа Heyhack. Доклад носит достаточно практичный характер и в нем не просто рассказывают про базовые концепции и приводят результаты исследования безопасности за 2023 год (что тоже очень интересно), но и демо топовых уязвимостей:)
Доклад состоит из следующих частей:
- Результаты исследования - Авторы исследовали автоматически почти 4 миллиона сервисов из 103 стран, больше 8 тысяч компаний. Для deep dive в результаты автор вспоминает про базу про CVSS (Common Vulnerability Scoring System) для оценки severity уязвимостей. Это нужно, чтобы показать, что 3/4 организаций имеют известные уязвимости высокого severity уровня (7+). Плюс интересно смотреть на распределение уязвимостей по странам (Россия достаточно хорошо выглядит на общем уровне или авторы не особо долбили российские сервисы)
- Deep dive в темы
-- File leaks - у 29% организаций еще были найдены утечки данных (код, бекапы, ключи, конфигурации, ...)
-- Dangling DNS records - Почти четверть компаний оказались с dangling DNS записями, когда доменное имя остается делегировано на ip адрес, который уже не принадлежит компании (например, когда в облаке погасил машинки, на которые делировал поддомен, а делегирование поддомена не убрал). Собственно, автор проводит демо как это может выглядеть и объясняет, что такую висящую DNS запись можно захватить и дальше украсть сессионные куки или повесить фрод на легитимный поддомен.
-- Vulnerable ftp servers - пример уязвимости proFTP 1.3.5 (CVE-2015-3306) и говорит, что 1.5% исследованных компаний имеют эту уязвимость:) А дальше проводит демо как ее эксплуатировать.
-- Cross-site scripting - это тип атаки, который заключается во внедрении в выдаваемую веб-системой страницу вредоносного кода и взаимодействии этого кода с веб-сервером злоумышленника. 4% компаний имеют известные уязвимости такого рода и они часто завязаны на wordpress плагины, nginx модули, keycloak, drupal плагины и вообще любые плагины известных веб-приложений. Здесь автор вспоминает OWASP (Open Worldwide Application Security Project) и конкретно проект OWASP Juice Shop - супер-дырявого приложения, которое специально спроектировали для тренировочных целей. Собственно в своем демо автор его активно использует. Плюс в демо используется BeEF - The Browser Exploitation Framework Project. Демо выглядит очень интересно и показывает на пальцах как выглядят уязвимости и к чему может привести безответственность в вопросах безопасности.
- Разбор кейса с Fortnite и EpicGames - пример того, как комбинация нескольких уязвимостей позволяет сломать систему. В данном случае это было приложение Fortnite. Саму уязвимость нашли ребята из Check Point и у них есть интересный разбор
- WAF и их частичная бесполезность - объяснение того, как работают WAF (web app firewall) и как они легко попадают в ошибки вида false positive и false negative:)

В финале автор рассказывает о главных выводах:
- Надеяться на WAF не стоит
- Нужно проактивно работать с уязвимостями и устранять их до того, как они привели к инцидентам безопасности
- Начать работать над app security просто

Ну и конкретно по вектору web attack предлагается такой план:
- Определить поверхность атаки (внешние домены) и понять уязвимые цели
- Пофиксить висящие DNS записи
- Обновить сервера (Apache, Nginx, ...)
- Настроить continuous testing критичных приложений
- Поработать с разработчиками и интегрировать с их инструментами средства безопасности для устранения найденных уязвимостей
- Протестировать заново найденные уязвимости и убедиться, что они исправлены
- И дальше работать так в цикле

Итого, это очень базовый доклад, но с интересной статистикой и с практичными советами по улучшению ситуации.

#Security #SRE #SoftwareArchitecture #Software #Engineering #Management #Leadership #Processes #SystemThinking #SystemEngineering

Banking Cybersecurity: Battling DeepFakes & AI-powered Scammers - George Proorocu - at NDC Security in Oslo, Norway

Интересное выступление Джорджа из нидерландского банка ING про безопасность в век deepfakes и AI, что могут использовать скаммеры.
Джорд рассматривает 4 сценария:
- C-level impersnation - когда мошенники пытаются выдать себя за топ-менеджера компании и дальше попросить перевести деньги на определенный счет. Кстати, у этого типа атаки есть реальные примеры
- Audio deepfakes - когда мошенники звонят людям и говорят голосом их детей, знакомых или родителей и просят перевести деньги. Эффективность атаки обусловлена тем, что мы, слыша знакомый голос, а также личную информацию верим, что произошло что-то серьезное и готовы последовать просьбе близкого человека.
- Deepfake interviews - пример атаки, когда ваш инженер проходит интервью, ему присылают оффер, он открывает его на рабочем компе (что туповато). Но оказывается, что все это было фейковым и все интервью были проведены мошенниками, которые хотели пробраться в вашу сеть. Интересный вектор атаки, но deepfake interviews сейчас используют и наоборот - интервью проходит один человек с фейк видео другого человека, а на работу выходит тот, чье лицо натягивал на себя интервьюируемый крутой инженер. В итоге, если это сделано ради зарплаты, то это еще полбеды, а если это сделано для того, чтобы получить доступ к системам компании?
- Investment scam - дипфейки в видео с известными людьми, которые рекламируют всякий скам. Здесь мошенничество в том, что эти люди явно бы не стали рекламировать этот скам, но небольшая помощь AI и дальше реклама готова:)

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

P.S.
Джордж показал как выглядели дипфейки год или полтора назад и как они выглядят сейчас и это небо и земля. Если раньше иногда были glitches как в Матрице, например, при вращении головой, то теперь даже это обрабатывается хорошо. Так что этот вектор атаки становится все реальнее.

#Security #Software #AI

Tinkoff CTF (Сapture the Flag)

Продолжая инженерную тему, я хотел бы рассказать про соревнование capture the flag в Тинькофф, которое состоится в 20-21 апреля. Начинается анонс соревнования с такого сетапа

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

Собственно, в этом соревновании надо будет разгадывать уязвимости и разгадывать тайны Гиперкуба, для чего надо обладать хорошими инженерными навыками и не обязательно быть безопасником. Само соревнование будет как онлайн, так и оффлайн в 16 городах России, Беларуси и Казахстана. Плюс перед соревнованием можно потыкать демоверсии заданий и понять уровень сложности и выбрать правильную лигу из двух: для новичков и для опытных. Итого на мероприятии

Вас ждут задания на безопасность в вебе'"\, мобильных приложениях и $инфраструктуре_, крипт0гр4Fию, реверс‑инжиниринг.i64 и хакерскую смекалку

#Software #Security #Engineering

Code of leadership #15 - Interview with Roman Lebed about Information security

В пятнадцатом выпуске подкаста "Code of Leadership" я пообщался с Романом Лебедем, архитектором из департамента информационной безопасности Тинькофф. До Тинькофф Роман руководил командой Red Team и занимался прикладными исследованиями в области безопасности приложений и операционных систем. В этом интервью мы обсуждаем подходы к безопасности в современных технологических компаниях. За 50 минут мы успели рассмотреть следующие моменты

- Как выглядит работа security архитектора в Тинькофф
- Требования к экспертам безопасности
- Как выстроено взаимодействие с командами разработки
- Какие подходы к безопасности существуют в Тинкофф
- Роль архитектора в команде
- Метрики безопасности
- Об "информационной безопасности" как профессии
- Обучение и развитие SDE (software development engineers) и shift left подходы
- Рекомендации для начинающих специалистов

P.S.
У Романа есть свой канал, посвященный безопасности @offensive_thread, на который можно подписаться, а также можно почитать книги, которые он рекомендовал
- Building secure and reliable systems - я про нее уже как-то рассказывал
- How to Linux works
- Android Internals::A Confectioner's Cookbook
- MacOS and iOS Internals (3 тома)
- Компьютерные сети (Таненбаум и ко)

Также у Ромы есть ряд интересных вакансий в его команды
- Архитектор ИБ/ Security Engineer & Architect (SEAR) в команду защиты Core Services
- AppSec TechLead в команду защиты периметра
- DevSecOps инженер в команду защиты периметра
- Разработчики Golang в команду VMP (Vulnerability Management Platform)

Если одна из вакансий вам интересна, то пишите Роме (@Ziv00s3)

#Infosec #Leadership #Architecture #Software #Processes #ProductManagement #Management #Security

Обзор whitepaper "Secure by Design at Google" (Рубрика #Architecture)

Недавно я прочитал интересный whitepaper от Chirstoph Kern на тему security с человеческим лицом от Google, где рассказывалось о том, как создавать безопасный софт на большом масштабе. Начинается статья с того, что для security экспертов самоочевидно, что вопросы безопасности должны рассматриваться как интегральная часть дизайна софтовых продуктов и добавление безопасности уже после создания продукта обычно заканчиваются неудачей. А что с этим можно сделать автор рассказывает уже дальше. И если немного спойлерить, то автор отмечает, что security posture софтверных продуктов и сервисов является эмерджентным свойством developer ecosystem, в рамках которой проектируются, имплементируются и деплоятся приложения. А значит эта экосистема должна быть создана определенным образом так, чтобы позволять на этапе проектирования и написания кода сделать его безопасным by design. В самом whitepaper приводится достаточно много примеров о том, как это сделано в Google.

Подробнее с обзором можно ознакомиться в моем блоге.

P.S.
Я уже участвовал в паре подкастов про безопасность, где мы обсуждали shift left security и secure by design
- [SafeCode Live] Secure by design
- Code of leadership #15 - Interview with Roman Lebed about Information security

и упоминал про пару книг
- Building secure and reliable systems - я про нее уже как-то рассказывал
- Agile Application Security

#Software #Security #Infosec #SystemDesign

Research Insights Made Simple #3 - Обсуждение paper "Security by Design at Google" (Рубрика #Security)

В третьем эпизоде подкаста мы обсуждаем интересный whitepaper "Secure by Design at Google" от Chirstoph Kern на тему security с человеческим лицом от Google, где рассказывалось о том, как создавать безопасный софт на большом масштабе. В разборе мне помогает крутой гость - Артем Мерец, мой коллега. Артем был разработчиком и 10 лет назад перешел в информационную безопасность. Он активно строил AppSec, когда он начал зарождаться в России как стрим, а затем увлекся атаками и несколько лет ломал инфраструктуру и приложения разных компаний в России и за ее пределами. С 2021 года Артем помогает выстраивать защиту Т-Банка в роли архитектора.

Сама научная статья доступна на сайте Google, а в моем блоге есть разбор

В этом выпуске мы обсудили следующие темы
- Общие впечатления от статьи
- Логические уязвимости и подходы Google
- Сложности безопасной разработки
- Концепция Security by Design
- Примеры безопасности из автомобильной индустрии
- Проблемы аудита кода
- Принципы безопасного дизайна
- Проблемы с инвариантами
- Автоматизация и категоризация инвариантов
- Применение инвариантов
- Проблемы безопасности в системах
- Примеры защиты от злонамеренных действий
- Дизайн для безопасности
- Shift left everything в разработке
- Проблемы и решения в безопасности
- Проект Yaga в Т-Банке
- Логические уязвимости
- Безопасная экосистема разработки
- Проблемы с памятью и микросервисной архитектурой
- Проблемы с безопасностью и инфраструктурой
- История о стажере-саботажнике в ByteDance
- Контроль артефактов и безопасность
- Экосистема для разработчиков

#Architecture #Security #CI #CD #Devops #Software #Management #Leadership #Engineering #Podcast

UK cybersecurity agency warns over risk of quantum hackers (Рубрика #Security)

The Guardian написало новость о том, что агенство по кибер-безопасности в UK рекомендует крупным организациям и операторам критической национальной инфраструктуры (такой как энергетическая или транспортная) перейти на пост-квантовые криптографические методы, чтобы предотвратить будущие угрозы безопасности.

Если же заглянуть поглубже, то у Национального центра кибербезопасности Великобритании (NCSC) есть целое комплексное руководство по миграции на постквантовую криптографию (Post-Quantum Cryptography, PQC) и стратегическая дорожная карта, что состоит из трех фаз
- Фаза 1 (до 2028 года): Организации должны определить цели миграции, провести полное обнаружение криптографических зависимостей и разработать первоначальный план миграции. Это включает выявление систем, требующих обновления, и понимание уязвимостей.
- Фаза 2 (2028-2031): Организации должны завершить миграцию на PQC для своих высокоприоритетных систем, обеспечить готовность инфраструктуры и уточнить планы миграции. Этот этап позволяет вносить корректировки по мере развития технологий PQC.
- Фаза 3 (2031-2035): Завершение миграции на PQC во всех системах, сервисах и продуктах. К 2035 году организации должны полностью перейти на квантово-устойчивое шифрование.

Потребность миграции связана с тем, что текущие методы шифрования, такие как RSA, основаны на математических задачах, которые классические компьютеры с трудом решают, но квантовые компьютеры потенциально могут легко взломать. NCSC рекомендует принять одобренные NIST алгоритмы PQC, включая
- ML-KEM (FIPS 203) - Module-Lattice-Based Key-Encapsulation Mechanism
- ML-DSA (FIPS 204) - Module-Lattice-Based Digital Signature Standard
- SLH-DSA (FIPS 205) - Stateless Hash-Based Digital Signature Standard

P.S.
Интересно на этом фоне смотрятся заявления больших компаний типа Microsoft, которые соревнуются в том, кто из них достиг квантового превосходства или совершил прорыв, как было с анонсом Майораны. Условно, практические квантовые компьютеры все ближе, а значит надо бы постепенно в критической инфре перейти на другие алгоритмы.

P.P.S.
Попробовал поискать похожие стандарты в России и не нашел, хотя есть реализации алгоритмов пост-квантового шифрования типа "Криптонит: Шиповник" (ребята хотели крутой нейминг выбрать, а получился кринжовый). Думаю, что у российсих объектов критической инфраструктуры тоже будет роадмап, похожий на тот, что представила NCSC 20 марта 2025 года.

#Security #Processes #Engineering #Software