Так здОрово, что напрашивается продолжение) Например, про применение теории решёток (ML-KEM, ML-DSS и прочие, устойчивые к алгоритму Шора) и про легковесную криптографию (Ascon и пр.)
NIST выпустил новую версию NICE Framework Components v2.0.0. Исключены категории ролей, связанные с кибероперациями и киберразведкой, добавлена роль, касающаяся промышленной кибербезопасности (OT) обновлены роли, специализирующиеся на анализе цифровых свидетельств и инсайдерских угроз. Исправлены ошибки и опечатки, устранены дублирующие или избыточные формулировки TKS. Актуальную версию NICE можно скачать здесь.
30 октября вышла 9-я версия фреймворка. SFIA 9 включает многочисленные обновления, запрошенные профессиональным сообществом, введены новые навыки, многие существующие доработаны. Изменения коснулись как профессиональных, так и поведенческих навыков и уровней ответственности.
Если есть желание более системно разобраться в том, какие бывают безопасники, предлагаю начать с карты компетенций. Наиболее известная - NIST NICE, я недавно писал о ней здесь. В ней более 50 ролей, каждая из которых состоит из своих задач, навыков и знаний. В зависимости от масштаба компании один специалист может выполнять как несколько ролей сразу, так и часть одной роли. Также можно посмотреть европейскаюую ECSF, состоящую всего из 12 ролевых профилей. В любом случае, у каждой организации своя специфика, и найти готовые описания ролей не получится. Можно воспользоваться каким-то фреймворком как конструктором и собрать из него то, что требуется конкретному бизнесу, адаптируя и добавляя недостающее. Например, роль MLSecOps вы пока там не найдёте. Но уже есть DevSecOps, и добавляя к его требованиям конвейер Continuous Training с DataOps получается что-то похожее на нужную роль.
Более подробно рассмотреть все пять бизнес-функций OWASP SAMM, получить рекомендации и узнать тонкости каждой из практик безопасности можно в бесплатном курсе OWASP SAMM Fundamentals от авторов модели.
CVE - это не угрозы (threats), а уязвимости (vulnerabilities). Уязвимость - свойство или особенность конкретной системы (ресурса, актива), которое может привести к реализации угрозы (т.е. к инциденту). Примеры уязвимостей: heartbleed в openssl, proxylogon в ms exchange, rowhammer в intel и amd, log4shell в java. Угроза - потенциальная причина инцидента, результатом которого может быть нанесение ущерба. Примеры угроз: шифровальщики, MitM, DoS, phishing.
Kill Chain я бы перевел как сценарий или последовательность атаки.
…Теоретически, воспроизводя проделанную авторами работу в модели GenAI, можно придумать обратную связь по качеству датасета… Валидировать имеющийся датасет в строгом соответствии с RFC каждого из протоколов (Ethernet, tcp, ip, http и т.д.)… А дальше либо править настройки конфигурации (можно ту же модель научить - что и где править) и собирать обучающий pcap заново, либо править ранее собранные данные (быстрее, но хуже качество)… С другой стороны, не всегда и не везде возможно настроить строго по спецификации, версии компонентов инфраструктуры меняются как и сами rfc, так что ещё вопрос, что выбрать в качестве эталона для обратной связи…
SFIA в действии можно увидеть на сайте https://www.digitalprofession.gov.au/career-development/aps-career-pathfinder-tool - навигатор по цифровым профессиям в Австралии - карьерные пути, требуемые навыки и курсы обучения подбираются в зависимости от ваших текущих возможностей и интересов.
А рассматривал ли кто-нибудь в качестве одного из критериев «сильного» ИИ критическое отношение к обучающим датасетам, и возможность ИИ дать обратную связь «обучающим» в случаях противоречий, внутренних нестыковок, пропусков, ошибок, недостоверных фактов, и пр. на этапе обучения?
PS: Каюсь, если уже обсуждали, не осилил все комментарии
Уязвимостями бизнес-логики можно также заниматься на этапе разработки сценариев тестирования для новых фич. Если применяется TDD (или BDD), то это делается до начала разработки. Т.е. сразу думать не только о том как проверить работоспособность фичи, но и как ее сломать (abuse) и использовать не по назначению (misuse). Сценарии можно посмотреть в соответствующем разделе WSTG.
Посмотрите, например, https://eprint.iacr.org/2024/1287.pdf
Спасибо за отличный разбор! В копилку по теме могу добавить рекомендации от OWASP (https://cheatsheetseries.owasp.org/cheatsheets/CI_CD_Security_Cheat_Sheet.html) и от WIZ (https://www.wiz.io/academy/ci-cd-security-best-practices).
Так здОрово, что напрашивается продолжение) Например, про применение теории решёток (ML-KEM, ML-DSS и прочие, устойчивые к алгоритму Шора) и про легковесную криптографию (Ascon и пр.)
NIST выпустил новую версию NICE Framework Components v2.0.0. Исключены категории ролей, связанные с кибероперациями и киберразведкой, добавлена роль, касающаяся промышленной кибербезопасности (OT) обновлены роли, специализирующиеся на анализе цифровых свидетельств и инсайдерских угроз. Исправлены ошибки и опечатки, устранены дублирующие или избыточные формулировки TKS. Актуальную версию NICE можно скачать здесь.
30 октября вышла 9-я версия фреймворка. SFIA 9 включает многочисленные обновления, запрошенные профессиональным сообществом, введены новые навыки, многие существующие доработаны. Изменения коснулись как профессиональных, так и поведенческих навыков и уровней ответственности.
Если есть желание более системно разобраться в том, какие бывают безопасники, предлагаю начать с карты компетенций. Наиболее известная - NIST NICE, я недавно писал о ней здесь. В ней более 50 ролей, каждая из которых состоит из своих задач, навыков и знаний. В зависимости от масштаба компании один специалист может выполнять как несколько ролей сразу, так и часть одной роли. Также можно посмотреть европейскаюую ECSF, состоящую всего из 12 ролевых профилей. В любом случае, у каждой организации своя специфика, и найти готовые описания ролей не получится. Можно воспользоваться каким-то фреймворком как конструктором и собрать из него то, что требуется конкретному бизнесу, адаптируя и добавляя недостающее. Например, роль MLSecOps вы пока там не найдёте. Но уже есть DevSecOps, и добавляя к его требованиям конвейер Continuous Training с DataOps получается что-то похожее на нужную роль.
Вот и отлично. Всё же цепи атак - не совсем корректный перевод, правильнее сказать сценарий развития атаки, или её жизненный цикл (https://habr.com/ru/companies/panda/articles/327488/)
Требования к защите WebSockets в стандарте ASVS (см. раздел V13.5) - https://github.com/OWASP/ASVS/blob/master/5.0/en/0x21-V13-API.md
Сценарии тестирования защищённости WebSockets в руководстве WSTG - https://github.com/andrettv/WSTG/blob/master/WSTG-ru/4-Web_Application_Security_Testing/11-Client-side_Testing/10-Testing_WebSockets.md
Более подробно рассмотреть все пять бизнес-функций OWASP SAMM, получить рекомендации и узнать тонкости каждой из практик безопасности можно в бесплатном курсе OWASP SAMM Fundamentals от авторов модели.
CVE - это не угрозы (threats), а уязвимости (vulnerabilities). Уязвимость - свойство или особенность конкретной системы (ресурса, актива), которое может привести к реализации угрозы (т.е. к инциденту). Примеры уязвимостей: heartbleed в openssl, proxylogon в ms exchange, rowhammer в intel и amd, log4shell в java. Угроза - потенциальная причина инцидента, результатом которого может быть нанесение ущерба. Примеры угроз: шифровальщики, MitM, DoS, phishing.
Kill Chain я бы перевел как сценарий или последовательность атаки.
https://habr.com/ru/companies/owasp/articles/817241/
…Теоретически, воспроизводя проделанную авторами работу в модели GenAI, можно придумать обратную связь по качеству датасета… Валидировать имеющийся датасет в строгом соответствии с RFC каждого из протоколов (Ethernet, tcp, ip, http и т.д.)… А дальше либо править настройки конфигурации (можно ту же модель научить - что и где править) и собирать обучающий pcap заново, либо править ранее собранные данные (быстрее, но хуже качество)… С другой стороны, не всегда и не везде возможно настроить строго по спецификации, версии компонентов инфраструктуры меняются как и сами rfc, так что ещё вопрос, что выбрать в качестве эталона для обратной связи…
SFIA в действии можно увидеть на сайте https://www.digitalprofession.gov.au/career-development/aps-career-pathfinder-tool - навигатор по цифровым профессиям в Австралии - карьерные пути, требуемые навыки и курсы обучения подбираются в зависимости от ваших текущих возможностей и интересов.
Спасибо за находку, @dm_fedorov
Главное забыл - там и общий контекст безопасности ИИ, и угрозы при разработке, обучении, и эксплуатации модели.
Ну, в БДУ аж 5 угроз для ИИ указаны уже года 3 (УБИ.218-222).
Хороший обзор видов атак по этапам жизненного цикла моделей (на medium).
PS: ещё один материал по той же теме вышел на следующий день...
Тест может показать наличие ошибок, но ни один тест не может доказать их отсутствия.
(c) Дейкстра
А рассматривал ли кто-нибудь в качестве одного из критериев «сильного» ИИ критическое отношение к обучающим датасетам, и возможность ИИ дать обратную связь «обучающим» в случаях противоречий, внутренних нестыковок, пропусков, ошибок, недостоверных фактов, и пр. на этапе обучения?
PS: Каюсь, если уже обсуждали, не осилил все комментарии
Можно начать перечислять? ) Вот первая десятка угроз: https://owasp.org/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-2023-slides-v1_1.pdf
https://whatpwacando.today
Уязвимостями бизнес-логики можно также заниматься на этапе разработки сценариев тестирования для новых фич. Если применяется TDD (или BDD), то это делается до начала разработки. Т.е. сразу думать не только о том как проверить работоспособность фичи, но и как ее сломать (abuse) и использовать не по назначению (misuse). Сценарии можно посмотреть в соответствующем разделе WSTG.