Интересно посмотреть на перспективы WAF в контексте API. Задача WAF - противостоять инъекциям, но если не получается составить белый список разрешённых значений, то эта задача практически невыполнима: пытливые умы так или иначе найдут способ обойти чёрный. И если бичом WAF для web-приложений были ложноположительные срабатывания (Волки! Волки!), то для API им стали ложноотрицательные (что ещё хуже). При этом в OWASP Top 10 API Security этого года инъекции уже не вошли…
Всё постепенно синеет): есть letsdefend; появился трек SOC у OffSec для сертификации Defense Analyst (OSDA); HTB продвигают свой Certified Defensive Security Analyst (CDSA)… Да и в Red Team давно поняли, что у синих надо учиться не шуметь как слон в посудной лавке, а Blue team, в свою очередь, наблюдает за тем, как скан сети превращается в Kill Chain... Win-win!
Принцип secure-by-design безусловно рабочий, но требует наличия опытных архитекторов безопасности и при этом довольно субъективен, т.к. у каждого свой багаж знаний. Так же присутствует человеческий фактор - легко упустить угрозы из виду. Сейчас, похоже, тренд на мониторинг угроз в реальном времени (EPSS, KEV) с учётом спецификаций (SBOM, VEX). Причём появление новых методов не отменяет классическое моделирование угроз или ревью кода, а дополняет их, т.к. панацеи пока не придумали, а ландшафт угроз всё разрастается…
PS: если вместо C++ использовать более безопасные по памяти языки типа Rust, - не поможет решить проблему? Или большое наследие библиотек и пр. не позволяет?
Почему заголовок про аутентификацию, а всё остальное - про авторизацию? Ведь перед тем, как предоставить доступ, пользователя нужно сначала идентифицировать, аутентифицировать, определить полномочия в системе и только потом организовать сессию. Для аутентификации средствами OAuth2 нужно реализовать ещё один поток (OIDC) с ID-токеном (он тоже JWT). Неплохое введение в картинках есть, например, на https://habr.com/ru/companies/flant/articles/475942/.
Есть идея более раннего и плотного включения Security Champions в цикл разработки. Называется continuous threat modelling. Уже на этапе обсуждения историй и фич Security Champions приучают команду задаваться вопросом «Что может пойти не так?», формулируя угрозы и требования безопасности, их компенсирующие. Помните, как в мультике про кота Леопольда мыши просили Золотую рыбку: «Мы хотим, чтобы мы летали» (история пользователя), а после реализации угрозы добавляли: «…и не падали» (требование безопасности)? В Agile эта техника называется behaviour-driven development. Сформированные требования после реализации историй и фич проверяются на приемке в Прод. Если какой-либо тест не прошел, фиксируется дефект. Соотношение количества дефектов к требованиям, а также время их устранения можно сделать показателями эффективности Security Champion и команды в целом.
Механизм разрешений для этого не подходит, т.к. API для разработчиков предоставляет им намного больше возможностей, чем есть в разрешениях. Что логично, т.к. не спрашивать же у пользователя, разрешать ли каждому приложению определять дату последнего изменения файла, громкость звука или доступные языки на клавиатуре. Чтобы пользователям не пришлось отвечать на несколько десятков вопросов, по каждому приложению, Apple берёт этот труд на себя.
И всё-таки губит физиков снобизм по отношению к другим наукам и вообще ко всем непосвящённым. Никто не отрицает сложности и великих заслуг физики, но неумение (часто выдаваемое за нежелание) просто и ясно объяснить суть явлений, описывающих их матмоделей и пр., отталкивает новое поколение. Не хватает популяризаторов, какими были Фейнман и Ландау.
Снобизм по отношению к философии, отчасти, сформировался из-за недостатка в хороших преподавателях, и, как следствие, неправильных ожиданий от философии как науки. Её задача - научить не бояться подвергать сомнению предпосылки, лежащие в основе наук (e.g. «параллельные прямые не пересекаются», «квадратный корень из отрицательного числа не существует», «частица или волна?», etc.), заполняя пробелы между сформировавшимися областями познания и расширяя их. Также отторжение философии, видимо, вызвано тем, что трудно научить быть смелым, если от природы ты к этому не склонен. Но этим, наверное, и отличаются хорошие учёные от великих…
Смысл в ограничении использования API не по назначению. Есть разница между приложением, опрашивающим только нужные ему API для настройки своих функций, и приложением, опрашивающим все доступные API, с целью получить уникальный слепок устройства, для возможности негласно следить за действиями его владельца без его согласия (и/или продавать эту информацию другим, что чаще всего и происходит).
Интересно, а кто-нибудь проводил сравнительный анализ по количеству инцидентов безопасности до аудита по ОУД и после его успешного прохождения? Если выполнение требований требует серьезных затрат времени и ресурсов, но не приводит к заметному улучшению безопасности на практике, то, мне кажется, сегодня многие предпочтут натренировать нейросеть готовить правдоподобные отчеты к каждому аудиту… Занятные размышления на эту тему недавно опубликовал основатель OWASP.
Спасибо за материал, хочу добавить, что как и для проверки конфигурации K8s, в качестве стандарта безопасности для конфигурации образов контейнеров можно использовать CIS Benchmark, он также неплохо описан у aqua). А кроме SCA/SAST многие компании уже внедряют в конвеер Continuous fuzzing (раз, два, три), где обратная связь по найденным уязвимостям реализуется за счёт инструментов Observabilitу.
Немного мутная история. С одной стороны, «ваш продукт хочет купить», с другой - сферические «300 требований» в вакууме. Если вы хотите продать свой продукт, то при его разработке наверняка закладывали возможные пожелания потенциальных клиентов по производительности, безопасности и интеграции, интересовались, какие преимущества есть у конкурентов, и лучше клиентов знаете, какие из сотен требований безопасности релевантны для вашего продукта, от чего они защищают и как снижать риски от актуальных угроз… Т.е. либо каждый раз писать под архитектуру заказчика, учитывая его ландшафт, тех.стеки, протоколы и требования безопасности, которые ставятся до начала разработки и именно они и проверяются при приемке в эксплуатацию; либо вы заранее поддерживаете наиболее распространенные требования, и тогда сможете продавать бОльшему числу клиентов…
Security Champions — это про дополнительные бонусы, которые получит организация
А какие бонусы получает сам Security Champion кроме дополнительной работы и постоянного конфликта интересов (свой среди чужих/ чужой среди своих)? Поделитесь опытом, как вы их рекрутируете, развиваете компетенции, удерживаете в команде (от перехода в ИБ)?
А я готовился по книге Peter Gregory CISM All-in-One Exam Guide, которую выбрал из-за хороших отзывов. К ней прилагался диск с тестовыми вопросами, которые помогли закрепить материал. Параллельно готовился к CISSP по книге Eric Conrad CISSP Study Guide, которая неплохо дополняет предыдущую. Сдал с первого раза и то и другое с интервалом в неделю. Итого на оба сертификата потратил три месяца без отрыва от работы. Другие источники не использовал.
Мне кажется, для пентеста нужно перенимать опыт площадок bug bounty по условиям приёмки отчётов, оплачивая только эксплойты с PoC, реализующие недопустимые события. Их, конечно, сначала надо ещё сформулировать, что само по себе полезное упражнение для любой компании, чтобы знать врага в лицо. Ну или попросить пентестера доказать, что обнаруженная им уязвимость приводит к такому событию, хотя оно и не было предусмотрено в условиях изначально.
И ещё. Триада КЦД - не угрозы, а фундаментальные свойства ИБ. Вы привели пример БДУ, назвав банк данных угроз уязвимостями, и их там точно больше трёх.
Интересно посмотреть на перспективы WAF в контексте API. Задача WAF - противостоять инъекциям, но если не получается составить белый список разрешённых значений, то эта задача практически невыполнима: пытливые умы так или иначе найдут способ обойти чёрный. И если бичом WAF для web-приложений были ложноположительные срабатывания (Волки! Волки!), то для API им стали ложноотрицательные (что ещё хуже). При этом в OWASP Top 10 API Security этого года инъекции уже не вошли…
Keychain у Apple. У Lockheed Martin Kill Chain.
Всё постепенно синеет): есть letsdefend; появился трек SOC у OffSec для сертификации Defense Analyst (OSDA); HTB продвигают свой Certified Defensive Security Analyst (CDSA)… Да и в Red Team давно поняли, что у синих надо учиться не шуметь как слон в посудной лавке, а Blue team, в свою очередь, наблюдает за тем, как скан сети превращается в Kill Chain... Win-win!
Принцип secure-by-design безусловно рабочий, но требует наличия опытных архитекторов безопасности и при этом довольно субъективен, т.к. у каждого свой багаж знаний. Так же присутствует человеческий фактор - легко упустить угрозы из виду. Сейчас, похоже, тренд на мониторинг угроз в реальном времени (EPSS, KEV) с учётом спецификаций (SBOM, VEX). Причём появление новых методов не отменяет классическое моделирование угроз или ревью кода, а дополняет их, т.к. панацеи пока не придумали, а ландшафт угроз всё разрастается…
PS: если вместо C++ использовать более безопасные по памяти языки типа Rust, - не поможет решить проблему? Или большое наследие библиотек и пр. не позволяет?
Почему заголовок про аутентификацию, а всё остальное - про авторизацию? Ведь перед тем, как предоставить доступ, пользователя нужно сначала идентифицировать, аутентифицировать, определить полномочия в системе и только потом организовать сессию. Для аутентификации средствами OAuth2 нужно реализовать ещё один поток (OIDC) с ID-токеном (он тоже JWT). Неплохое введение в картинках есть, например, на https://habr.com/ru/companies/flant/articles/475942/.
Про безопасность JWT можно почитать на https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.html.
Есть идея более раннего и плотного включения Security Champions в цикл разработки. Называется continuous threat modelling. Уже на этапе обсуждения историй и фич Security Champions приучают команду задаваться вопросом «Что может пойти не так?», формулируя угрозы и требования безопасности, их компенсирующие. Помните, как в мультике про кота Леопольда мыши просили Золотую рыбку: «Мы хотим, чтобы мы летали» (история пользователя), а после реализации угрозы добавляли: «…и не падали» (требование безопасности)? В Agile эта техника называется behaviour-driven development. Сформированные требования после реализации историй и фич проверяются на приемке в Прод. Если какой-либо тест не прошел, фиксируется дефект. Соотношение количества дефектов к требованиям, а также время их устранения можно сделать показателями эффективности Security Champion и команды в целом.
Механизм разрешений для этого не подходит, т.к. API для разработчиков предоставляет им намного больше возможностей, чем есть в разрешениях. Что логично, т.к. не спрашивать же у пользователя, разрешать ли каждому приложению определять дату последнего изменения файла, громкость звука или доступные языки на клавиатуре. Чтобы пользователям не пришлось отвечать на несколько десятков вопросов, по каждому приложению, Apple берёт этот труд на себя.
И всё-таки губит физиков снобизм по отношению к другим наукам и вообще ко всем непосвящённым. Никто не отрицает сложности и великих заслуг физики, но неумение (часто выдаваемое за нежелание) просто и ясно объяснить суть явлений, описывающих их матмоделей и пр., отталкивает новое поколение. Не хватает популяризаторов, какими были Фейнман и Ландау.
Снобизм по отношению к философии, отчасти, сформировался из-за недостатка в хороших преподавателях, и, как следствие, неправильных ожиданий от философии как науки. Её задача - научить не бояться подвергать сомнению предпосылки, лежащие в основе наук (e.g. «параллельные прямые не пересекаются», «квадратный корень из отрицательного числа не существует», «частица или волна?», etc.), заполняя пробелы между сформировавшимися областями познания и расширяя их. Также отторжение философии, видимо, вызвано тем, что трудно научить быть смелым, если от природы ты к этому не склонен. Но этим, наверное, и отличаются хорошие учёные от великих…
Смысл в ограничении использования API не по назначению. Есть разница между приложением, опрашивающим только нужные ему API для настройки своих функций, и приложением, опрашивающим все доступные API, с целью получить уникальный слепок устройства, для возможности негласно следить за действиями его владельца без его согласия (и/или продавать эту информацию другим, что чаще всего и происходит).
Интересно, а кто-нибудь проводил сравнительный анализ по количеству инцидентов безопасности до аудита по ОУД и после его успешного прохождения? Если выполнение требований требует серьезных затрат времени и ресурсов, но не приводит к заметному улучшению безопасности на практике, то, мне кажется, сегодня многие предпочтут натренировать нейросеть готовить правдоподобные отчеты к каждому аудиту… Занятные размышления на эту тему недавно опубликовал основатель OWASP.
Спасибо за материал, хочу добавить, что как и для проверки конфигурации K8s, в качестве стандарта безопасности для конфигурации образов контейнеров можно использовать CIS Benchmark, он также неплохо описан у aqua). А кроме SCA/SAST многие компании уже внедряют в конвеер Continuous fuzzing (раз, два, три), где обратная связь по найденным уязвимостям реализуется за счёт инструментов Observabilitу.
Немного мутная история. С одной стороны, «ваш продукт хочет купить», с другой - сферические «300 требований» в вакууме. Если вы хотите продать свой продукт, то при его разработке наверняка закладывали возможные пожелания потенциальных клиентов по производительности, безопасности и интеграции, интересовались, какие преимущества есть у конкурентов, и лучше клиентов знаете, какие из сотен требований безопасности релевантны для вашего продукта, от чего они защищают и как снижать риски от актуальных угроз… Т.е. либо каждый раз писать под архитектуру заказчика, учитывая его ландшафт, тех.стеки, протоколы и требования безопасности, которые ставятся до начала разработки и именно они и проверяются при приемке в эксплуатацию; либо вы заранее поддерживаете наиболее распространенные требования, и тогда сможете продавать бОльшему числу клиентов…
А какие бонусы получает сам Security Champion кроме дополнительной работы и постоянного конфликта интересов (свой среди чужих/ чужой среди своих)? Поделитесь опытом, как вы их рекрутируете, развиваете компетенции, удерживаете в команде (от перехода в ИБ)?
Исследование поверхности атак на ML-алгоритмы - https://towardsdatascience.com/how-to-attack-machine-learning-evasion-poisoning-inference-trojans-backdoors-a7cb5832595c
Если важна безопасность, лучше почитать про атрибуты cookie в WSTG: https://github.com/andrettv/WSTG/blob/master/WSTG-ru/4-Web_Application_Security_Testing/06-Session_Management_Testing/02-Testing_for_Cookies_Attributes.md.
А я готовился по книге Peter Gregory CISM All-in-One Exam Guide, которую выбрал из-за хороших отзывов. К ней прилагался диск с тестовыми вопросами, которые помогли закрепить материал. Параллельно готовился к CISSP по книге Eric Conrad CISSP Study Guide, которая неплохо дополняет предыдущую. Сдал с первого раза и то и другое с интервалом в неделю. Итого на оба сертификата потратил три месяца без отрыва от работы. Другие источники не использовал.
На рисунке с треугольником на всех чёрных плашках первой буквой должна быть “C” (Common)
Мне кажется, для пентеста нужно перенимать опыт площадок bug bounty по условиям приёмки отчётов, оплачивая только эксплойты с PoC, реализующие недопустимые события. Их, конечно, сначала надо ещё сформулировать, что само по себе полезное упражнение для любой компании, чтобы знать врага в лицо. Ну или попросить пентестера доказать, что обнаруженная им уязвимость приводит к такому событию, хотя оно и не было предусмотрено в условиях изначально.
И ещё. Триада КЦД - не угрозы, а фундаментальные свойства ИБ. Вы привели пример БДУ, назвав банк данных угроз уязвимостями, и их там точно больше трёх.