Security: теория

Взлом matrix.org – пример очень показательного взлома с точки зрения базовой безопасности. Нарушено куча важнейших принципов, описанных ниже. Сам хакер очень подробно все описал.

https://archive.md/MfrjB
в матриксе крутили на х.ю самые обычные бестпрактисы. Молодцы, че 

I noticed in your blog post that you were talking about doing a postmortem and steps you need to take. As someone who is intimately familiar with your entire infrastructure, I thought I could help you out.

• Отсутствие 2FA для ssh (я после этой истории поставил 😉)

[SECURITY] 2FA is gud
2FA is often touted as one of the best steps you can take for securing your servers, and for good reason! If you'd deployed google's free authenticator module (sudo apt install libpam-google-authenticator), I would have never been able to ssh into any of those servers.
Alternatively, for extra security, you could require yubikeys to access production infrastructure. Yubikeys are cool. Just make sure you don't leave it plugged in all the time, your hardware token doesn't do as much for you when it's always plugged in and ready for me to use.
Alternate-Alternatively, if you had used a 2FA solution like Duo, you could have gotten a push notification the first time I tried to ssh to any of your hosts, and you would have caught me on day one. I'm sure you can setup push notifications for watching google-authenticator attempts as well, which could have at least given you a heads up that something fishy was going on.
Anyways, that's all for now. I hope this series of issues has given you some good ideas for how to prevent this level of compromise in the future. Security doesn't work retroactively, but I believe in you and I think you'll come back from this even stronger than before.
Or at least, I hope so -- My own information is in this user table... jk, I use EFNet.

• Лишние привилегии (даешь рут для всех :/)

[SECURITY] Principle of Least Privilege
Escalation could have been avoided if developers only had the access they absolutely required and did not have root access to all of the servers. I would like to take a moment to thank whichever developer forwarded their agent to Flywheel. Without you, none of this would have been possible.

• Отсутствие аудита логов безопасности

[SECURITY] Monitor log files to avoid relying on external whitehats
Let's face it, I'm not a very sophisticated attacker. There was no crazy malware or rootkits. It was ssh agent forwarding and authorized_keys2, through and through. Well okay, and that jenkins 0ld-day. This could have been detected by better monitoring of log files and alerting on anomalous behavior. Compromise began well over a month ago, consider deploying an elastic stack and collecting logs centrally for your production environment.

• Отсутствие постоянных обновлений критичных для безопасности систем (CI Jenkins)

После первого взлома командой Matrix был опубликован отчёт, в котором указано, что взлом был совершён через уязвимость в необновлённой системе непрерывной интеграции Jenkins. 

• Прямой доступ из интернета НА ВСЕ СЕРВЕРА без каких то глупых VPN/reverse-proxy/bastion-host
  • на SSH сервера
  • на сервер CI Jenkins

[SECURITY] Controlled Production Access
I was able to login to all servers via an internet address. There should be no good reason to have your management ports exposed to the entire internet. Consider restricting access to production to either a vpn or a bastion host.

[SECURITY] Jenkins Slave listening to SSH on the internet
Once I was in the network, a copy of your wiki really helped me out and I found that someone was forwarding 22226 to Flywheel. With jenkins access, this allowed me to add my own key to the host and make myself at home. There appeared to be no legitimate reason for this port forward, especially since jenkins tunnel was being used to establish the communication between Themis and Flywheel.

Ну и чуть более сложные:

• Хранение ключей для создания подписей СВОИХ МЕГА БЕЗОПАСНЫХ ПРИЛОЖЕНИЙ на рабочих серверах, а не на изолированном хосте

[SECURITY] Signing keys in production?!?
There I was, just going about my business, looking for ways I could get higher levels of access and explore your network more, when I stumbled across GPG keys that were used for signing your debian packages. It gave me many nefarious ideas. I would recommend that you don't keep any signing keys on production hosts, and instead do all of your signing in a secure environment.

• Включенный “проброс ключа ForwardAgent” в ssh – позволяет с одного сервера подключаться на другой без пароля, форвардом ключа от первого сервера второму

[SECURITY] SSH Agent Forwarding
Complete compromise could have been avoided if developers were prohibited from using ForwardAgent yes or not using -A in their SSH commands. The flaws with agent forwarding are well documented.

• Хранение в Git репозитории всех важных данных и полностью репа заливалась на хосты, хотя по факту в этом нужды не было

[SECURITY] Git is not a secret store
The internal-config repository contained sensitive data, and the whole repository was often cloned onto hosts and left there for long periods of time, even if most of the configs were not used on that host. Hosts should only have the configs necessary for them to function, and nothing else.

 

 

Источники

• Большая часть информации ниже взята из открытых источников, которые изучались по мере прохождения:
  • прекрасного базового курса Coursera от Google по безопасности
  • материалов для подготовки к новому Cisco CCNP/CCIE Security (SCOR, SNCF экзамены)
• Очень хороший github repo h4cker.org в котором Omar Santos (автор курса SCOR) собрал разную информацию в контексте сетевой безопасности. Например там есть,
  • хорошая таблица по тому, какие алгоритмы хеширования и шифрование рекомендуется/не рекомендуется использовать. Какие являются будущим.
  • довольно полный список разных утилит для reverse-engineering

 

А теперь перейдем от практики к непосредственно теории.

 

Стандартизация

• NIST Cybersecurity Framework (National Institute of Standards and Technology) – совокупность индустриальных стандартов и наилучших практик для защиты организаций в контексте кибербезопасности от гос. органа США (всего более 500 штук). Одной из основных целей стандартизации является управление рисками кибербезопасности критической инфраструктуры эффективно и не дорого. Framework может использоваться как основа для любой организации. В целом публикации NIST охватывают широкий круг вопросов безопасности (от контроля доступа до беспроводной безопасности) и являются очень ценным источником информации.

• ISO/EIC 27000 (ISO27k) – набор стандартов (порядка 50) о информационной безопасности от ISO (International Organization for Standardization) и IEC (International Electrotechnical Commission). Первые же 6 документов рассматривают большой пул вопросов касающихся развертывания/поддержки/мониторинга/аудита систем управления ИБ (ISMS). Организации могут/проходят процедуру соответствия этим сертификациям.

 

Терминология (словарь/dictionary)

• CIA triad (confidentiality, integrity, availability) – ключевые аспекты безопасности. Каждый из аспектов можно раскрыть подробнее, например
  • конфиденциальность подразумевает что данные видимы только тем, кто авторизован их видеть. Требует совокупность мер для реализации – шифрование, ограничения физического и логического доступа и даже контроль маршрутизации трафика. Чаще всего технически задача конфиденциальности решается шифрованием. В общем случае задача конфиденциальности решается тремя общими концепциями:
    • определение того, какая информация нуждается в контроле
    • определение лиц, которые авторизованы и не авторизованы в получения доступа к этой информации
    • контроль доступа к информации только авторизованным пользователям 

• • целостность подразумевает что данные защищены от порчи, подмены (имитозащита). Чаще всего технически задача целостности решается хешированием. Так же шифрованием, цифровыми подписями, контролем процессов, тестированиями кода, анализ логов, мониторинг (напр. контроль целостности файлов), тренинги персонала.
    
    • Воровство пароля админа в последующим изменением конфигурации сервисов/серверов/устройств – тоже атака на целостность.
    • Malware которое модифицирует/уничтожает системные файлы, необходимые для загрузки – пример неавторизованной манипуляции, атаки на целостность.
    • Подмена/удаление медицинских или банковских данных.
  • доступность подразумевает что сервис доступен (напр. сайт online retailing, ISP provider, cloud provider) для легитимных пользователей. Самой частой атакой против доступности является DoS (denial-of-service). Показателем доступности является uptime (сколько времени в процентах сервис доступен), например ISP/датацентры часто публикуют данные/подписывают договоры (SLA) с 99.999% доступностью (99.999% uptime). В среднем мы более уязвимы к проблемам доступности в сравнении с проблемами конфиденциальности и целостности. Методы митигации угроз доступности включают контроль доступа, мониторинг, отказоустойчивость, виртуализация, административные меры (процедуры, планирование).

Какой из этих аспектов CIA triad более важен? Во первых они связаны – например, потеря пароля может привести к проблемам по любому из аспектов. Во вторых компания должна решать сама на основе ее целей, сервисов, регламентов и соглашений.

• Атаковать сложнее чем защищать – атакующему зачастую достаточно провести успешно только одну атаку из 100, чтобы взломать систему. При этом защищающийся может успешно отразить 99 атак и система все равно будет взломана.
• Risk (риск, управление рисками) – возможность понести потери в случае атаки на систему (реализации угрозы). Безопасность вся основывается на рисках – определение рисков, определение вероятности атак, разработка/проектирование систем для минимизации рисков этих атак (простейший пример из жизни – переход дороги). В контексте безопасности есть аксиома, что невозможно полностью исключить риск (полностью безопасная система – отключенная от сети, питания, к ней нет доступа ни у кого). Лучшее, что можно сделать, это идентифицировать риск, принять меры по уменьшению и мониторить, приняв его как остаточный риск (residual risk). С риском ассоциируются понятия assets (активы), threats (угрозы) и vulnerabilities (уязвимости). Для “работы” с рисками правительство США разработало risk management framework (RMF) на базе публикации NIST 800-37.

• • Assets (активы) – любой предмет, который представляет какую либо ценность. Может быть реальным – роутеры, сервера, ноутбуки и проч; может быть и виртуальным – формулы, базы, таблицы, торговые секреты. Независимо от типа актива его потеря может привести к финансовым потерям компании.
• • Risk assessment (оценка рисков) – начинается с threat modeling (моделирования угроз). Подразумевается идентификация возможных источников угроз (векторов атак, таких, как уязвимости) для систем (критичных систем/критичных данных) с точки зрения потенциального атакующего, приоритизация этих угроз в зависимости от вероятности и серьезности (например, для уязвимости – можно ли использовать ее удаленно, вероятность ее использования, тип доступа, который получит атакующий в результате эксплойта). 

• Trade-off (компромис) – во многих темах безопасности встречаются темы компромиссов между безопасностью и удобством:
  • безопасный  пароль ! = пароль который легко запомнить,
  • максимальная длина ключа != максимальная скорость работы,
  • цена/безопасность аппаратной реализации != цена/безопасность программной
  • безопасность 3FA != удобству 1FA
  • удаленный доступ со своего девайса (вместо rdp/VM) != безопасный доступ
  • и так далее

• Vulnerability (уязвимость) – недостаток в системе (программной или аппаратной), который может быть использован для компроментации системы. Уязвимость не всегда имеет эксплойт (особенно публичный) и не всегда даже может быть эксплуатирована (подробнее ниже). Уязвимость может быть обнаружена в любой системе (application, OS, hardware) – не существует полностью неуязвимых систем. Вендоры/исследователи обычно после обнаружения уязвимости назначают ей номер CVE (Common Vulnerabilities and Exposure) и исправляют, но это не всегда так – вендор/пользователь может не исправлять уязвимость из-за простого отсутствия финансов. Так же уязвимость может не исправляться т.к. библиотека уже всеми забыта. Поддержкой CVE базы занимается организация MITRE. Пример конкретной уязимости CVE-2017-3881. Пример аппаратных уязвимостей – Spectre, Meltdown. Пример базы с уязвимостями ФСТЭК. 

Не все уязвимости имеют Exploit, такие уязвимости часто называют “theoretical vulnerabilities”, но нужно всегда иметь ввиду, что если вы не нашли или не придумали эксплойт, это не значит его нельзя найти (напр. глубоко в darkweb) или придумать и скрытно использовать (напр. спецслужбами). Поэтому в природе не бывает полностью “theoretical vulnerabilities”.

• 0-day vulnerability, zero-day exploit – уязвимость нулевого дня – уязвимость, которая неизвестна производителю продукта, но известна хакеру. 0 дней подразумевает за сколько нужно ее починить (или сколько дней известно о уязвимости) 😀 По факту зачастую даже после патча чинится куда дольше – нужно время для его “разливки”.

• Exploit – софт или набор шагов, который использует (эксплуатирует) уязвимость в системе. 

Пример базы с exploit-ами – популярный http://exploit-db.com/ от Offensive Security или github. Есть так же очень удобный command-line tool “searchsploit“, который позволяет выгрузить копию exploit database и в консоли искать эксплойты. Exploit’ы чаще всего продают в dark web. Exploit’ы не всегда выкладываются для злого умысла или зарабатывания денег – они являются proof-of-concept (POC).

• Threat – в общем случае это любая потенциальная угроза. Это может быть угроза использования уязвимости (возможная атака), угроза отказа в обслуживании, угроза воровства данных, отказа объекта КИИ (stuxnet), угроза пожара или другого катаклизма и проч. В общем случае угроза может приводить к любым проблемам CIA (Confidentiality, Integrity, Availability). Сущность, получающая профит от использования уязвимости известна как malicious actor (threat actor – подробнее отдельно), а путь используемый этим actor для осуществления атаки известен как threat agent/threat vector.

• Threat actor, malicious actor – личность или группа личностей, осуществляющих атаку или ответственные за security инцидент. Типы:
  • script kiddies (используют написанные другими инструменты),
  • organized crime groups (в основном занимаются воровством информации и зарабатыванием денег),
  • state governments (серьезные ребята),
  • hacktivists (занимаются этим по идеологическим причинам),
  • terrorist groups (групп мотивированные политическими или религиозными целями). 

• Attack vector (вектор атаки) – метод или механизм, которые атакующий может использовать для атаки сети/системы. Примеры векторов атак – вложения в почте, сетевые протоколы/сервисы. В зависимости от используемого приложения могут быть наиболее “актуальные” те или иные веторы атак, к примеру есть очень известный список OWASP TOP-10 (линк на непосредственно сайт OWASP – Open Web Application Security Project), в который включены самые опасные атаки на WEB приложения (SQL injection, auth implementation problems,  sensitive data exposure, XXE, XSS, url, deserialization, security misconfiguration, unsecure components, using components with known vulnerabilities, insufficient logging & monitoring, etc).

Для тренировки с уязвимостью XSS и другими WEB-уязвимостями, которые рассмотрены в проекте OWASP можно использовать тулзу OWASP Juice Shop, можно на практике посмотреть уязвимости OWASP top 10 и другие (подробнее в XSS).

• Attack scope (совокупность векторов атаки) – совокупность векторов атак

• Attack – непосредственно атака на систему
• Defense in depth (эшелонированная защита) – концепция наличия нескольких наложенных систем защиты. Может быть реализована даже в рамках одного продукта (например, Firewall). 1) Нельзя полагаться на одну систему (SPOF) 2) Каждый из элементов защиты может быть не идеален, но он является потенциальным барьером, который может помочь отразить атаку. Как в замке.

Отказоустойчивость в вопросе безопасности зачастую так же критична (а иногда и критичнее), чем работа непосредственно сервиса. Причем система может не упасть и ты не будешь знать что она не работает, а кто-то тем временем будет пользоваться уязвимостью в ней. К примеру,

• • Яркий пример – это куча эксплойтов у ведущих вендоров, позволяющих обойти аутентификацию. Почему ОБЯЗАТЕЛЬНО нужно закрывать доступ к устройствам на уровне протоколов (ACL), использовать серую адрессацию, а не только полагаться на аутентификацию в соотвествующих протоколах (SSH, SNMP, telnet, etc).

  • best practice настраивать и sshd_config и iptables для защиты подключения по ssh на сервер
  • как бы плохи антивирусы не были, они хорошо защищают от популярных известных атак (модель blacklist). Конечно, с точки зрения безопасности лучше иметь binary whitelisting software (bit9) – который будет запрещать все, кроме того что явно не разрешено (концепция implicit deny ниже), но это очень неудобно, особенно если он не полагается на signing PKI (концепция trade-off выше ;)), но недостаток есть и у них – если доверять всему подписанному, не смотря внутрь, то, в тот момент, когда подделают подпись – тебе хана (примеры подобных атак были).
  • как бы не были плохо функции защиты port security и MAC authentication, если они не накладывают серьезных недостатков в поддержании актуальными баз адресов – они могут быть полезны
  • То же самое и про firewall – помимо классических сетевых устройств, должны быть и host-based firewall, у которых будут примерно такие же правила, как у классического устройства или даже больше (защита внутри сети от зараженных устройств внутри сети за файрволом) или защита mobile юзера.
    • Implicit deny/whitelisting – концепция о том, что нужно отключать/удалять ненужные сервисы (или ограничивать к ним доступ) или не давать лишние доступы (всем права админа – это не соответствует best practice концепции “least privilege”). Встречается везде и нужно использовать везде – даже на клиентских устройствах (host-based firewall). Отсюда например вытекает implicit deny в ACL (на роутерах Cisco или в iptables на INBOUNT) – концепция из сетевого мира, которая подразумевает, что все, что явно не разрешено, должно быть запрещено – это относится как к входящему трафику, так и к исходящему. Это намного более безопасная концепция, чем black listing, хотя и менее удобная. 
    • Internal Attack Team – есть во многих организациях, включая Google. Хакеры в белых шляпах.
    • OSINT (Open sourceintelligence) — Разведка на основе анализа открытых источников информации, разведывательная дисциплина, включающая в себя поиск, выбор и сбор разведывательной информации из общедоступных источников, а также её анализ. Примером можно считать avinfobot telegram бот, который из открытых источников агрегирует информацию по номерам авто/телефонам или ФИО.
    • Survival Time системы без защиты, патчей (что не менее важно) и с неактуальной версией системы (Windows XP, god forbid), смотрящие “голо” в интернет – час. Потом ее хакнут. Поэтому безопасность – это важно.
    • Security Misconfiguration – неправильная конфигурация продукта с точки зрения безопасности (напр. использование устаревших типов шифрования, устаревших методов аутентификации). Частая проблема, особенно в свете того, что дефолтные конфиги зачастую уже имеют заложенные недостатки с точки зрения безопасности.
    • Security Education – обучение по безопасности, обязательно в компаниях, которые заботятся о своей безопасности. Обучать нужно всех сотрудников, не только сотрудников SoC/IRP. Должно включать самые распространенные способы атаки (почтовые вложения, зеркала, пароли) и способы защиты от них. 
    • Third party security – безопасность сторонней организации с которой взаимодействует твоя организация. Нужно проверять сторонние организации на соответствие политикам безопасности (внутренним внутри организации и зачастую даже твоим политикам) через VSAQ (Vendor security assessment questionnaries, быстрый и эффективный способ) или даже тестировать (audit, vulnerability test, pentest) их решения на безопасность. Пример VSAQ от Google.
    • Zero Trust не доверяем никому и ничему по умолчанию (пользователям, приложениям, трафику, данным или узлам) до тех пока не проведем их проверку.

    Концепция Zero Trust появилась, когда современные подходы, основанные, в первую очередь, на защите периметра, стали давать сбой. Когда к внутренним ресурсам стали подключаться различные клиенты, партнеры, контрагенты, когда компании начали активно уходить в облака и использовать мобильные устройства, прежняя концепция – защита периметра – перестала справляться. Возникла новая необходимость защитить и данные, и пользователей, и устройства, которые постоянно меняют свое местоположение. Именно тогда была предложена концепция Zero Trust. Она как раз и означает, что мы изначально не доверяем никому: пользователям, приложениям, трафику, данным, узлам. Не доверяем до того момента, пока не проведем проверку. Эта проверка производится либо постоянно, либо через небольшие интервалы времени, чтобы убедиться, что злоумышленники не смогли подменить пользователя, устройство, трафик, данные, узел и т.д.

    • Bastion host – хост, на входе в какую то (какие-то) IT системы. Позволяет получить доступ к каким то системам с себя/через себя, но на него наложены политики безопасности (аутентификации/авторизации, логгирования, мониторинга).
    • Advanced Persistent Threat (APT) – атака с внедрением в сеть и незаметным там нахождением существенное время. Advanced – потому что зачастую это таргетированная атака, при которой нет почти ограничения по времени/ресурсам. Чаще всего угроза постоянна – поэтому persistent. Примеры таких атак – Stuxnet, атака на RSA SecurID в 2011 (потенциально на Lockheed Martin).
    • Data leak prevention (DLP) – системы предотвращения данных. Могут анализировать любую активность, включая даже данные, копируемые по RDP.
     
    • Персональные данные (personally identifiable information, PII) – данные которые позволяют идентифицировать персону. Защищаются законами в большинстве стран и требуют ‘особую’ защиту (напр. ГОСТ шифрование). Потеря таких данных может стать причиной судебного преследования компании, помимо потери доверия клиентов. Примеры персональных данных/информации:
      • PII – personally identifiable information,
      • NPPI – nonpublic personal information,
      • PCI – payment card information,
      • PHI – personal health information.

     

    Разведка угроз (Threat Intelligence)

    Разведка угроз (Threat Intelligence) – это знания о существующих и появляющихся угрозах к активу (asset). Основное применение – информирование бизнеса относительно рисков и последствий угроз для актива. Threat Intelligence включает информацию о активе, внутренних и внешних угрозах, контекст (context), механизмы (mechanisms), индикаторы компрометации (Indicators of Compromise, IoCs), последствия (implications), действия (actionable advice). Вся эта информация является критической для Security Operations Centers (SOC).

    В целом использование опыта других – это полезно (немного капитаним).

    Процесс threat intelligence можно разбить на этапы: планирование (planning), сбор (collection), обработка (processing), подготовка/аналитика/внедрение (analysis and production) и распространение (dissemination).

    Существует ряд стандартов разработанных в контексте Threat Intelligence. Первые три основаны MITRE, поддерживаются сейчас OASIS.

    • STIX – Structured Threat Information eXpression – язык для обмена информацией о атаках, может включать IP адреса/домены контрольных серверов (Command-and-control, C2, CNC), хеши malware и прочее. 
    • TAXII – Trusted Automated eXchange of Indicator Information – отрытый транспортный механизм, который стандартизировал автоматический обмен информацией о гибер-угрозах. Использует формат STIX для передачи cyber threat intelligence (CTI).
    • CybOX – Cyber Observable eXpression
    • OpenIOC – Open Indicators of Compromise – информация о гибер-угрозах в машинном виде (machine-digestible format).
    • OpenC2 – Open Command and Control

     

    Cybersecurity & Information Security (InfoSec)

    Кибербезопасность включает в себя традиционные вопросы информационной безопасности, но и добавляет дополнительные требования – контроль всех соединений, контроль данных на этапе хранения/передачи и обработки, управление софтом и аппаратным обеспечением, управление инцидентами.

     

    ОЦЕНКА уровня угроз (CVSS)

    Common Vulnerability Scoring System (CVSS) – оценка уровня угрозы (совокупность рисков) конкретной уязвимости. Можно встретить двух версий – CVSSv2, CVSSv3 (чаще). CVSS является стандартом, используемым security специалистами во всем мире и поддерживается организацией FIRST (Forum of Incident Response and Security Teams). Примеры расчета оценок CVSS на основе анализа реальных уязвимостей есть у самого FIRST.

    CVSS оценка имеет градацию на низкий/средний/высокий/критический уровень. Во ФСТЭК градация почти аналогичная CVSSv3. Примером критичной уязвимости можно считать уязвимость, которая позволяет атакующему удаленно компроментировать систему и получить полный контроль над ней. 

    CVSS
    Textual severity ratings of None (0), Low (0.1-3.9), Medium (4.0-6.9), High (7.0-8.9), and Critical (9.0-10.0)[10] were defined, similar to the categories NVD defined for CVSS v2 that were not part of that standard .[11]
    
    ФСТЭК
    - низкий уровень, если 0,0 ≤ V ≤ 3,9;
    - средний уровень, если 4,0 ≤ V ≤ 6,9;
    - высокий уровень, если 7,0 ≤ V ≤ 9,9;
    - критический уровень, если V = 10,0.

    Нужно понимать, что CVSS относится к конкретной уязвимости, но зачастую, особенно в случае APT-атак, уязвимости эксплотируются в цепочке и несколько минорных уязвимостей могут в итоге стать серьезной проблемой, когда их эксплуатируют одновременно. Анализ последствий таких атак крайне сложен.

    CVSS оценка состоит из трех компонентов, каждый из которых имеет свою оценку от 0 до 10 и описывает различные характеристики уязвимости и то, как атакующий может эти характеристики использовать:

    • Базового (base)
    • Временного (temporal)
    • Среды (environmental)

    Подробнее о каждом:

    • • Базовый (base) – самый важный компонент и единственный обязательный (mandatory) компонент, представляет собой характеристики, присущие уязвимости, которые неизменны со временем и не зависят от пользовательской среды. Сам компонент состоит из трех метрик:
        
        • Эксплуатируемость (exploitability) – условия, при которых возможна эксплуатация уязвимости.
          • Вектор атаки (Attack Vector, AV) – уровень доступа к уязвимой системе, при которых возможна эксплуатация уязвимости. Бывает четырех типов:
            • Сетевой (Network, N)
            • Смежный (Adjacent, A)
            • Локальны (Local, L)
            • Физический (Physical, P)
          • Сложность атаки (Attack Complexity, AC) – описывает условия, которые не контролируются атакующим, которые должны существовать для эксплуатации уязвимости.
            • Низкая сложность (Low, L)
            • Высокая сложность (High, H)
          • Требуемые привелегии (Privileges Required, PR) – представляет из себя уровень привилегий, которыми атакующий должен обладать на уязвимой системе.
            • Не требуются (None, N)
            • Низкие (Low, L)
            • Высокие (High, H)
          • Взаимодействие с пользователем (User Interaction, UI) – требуется ли взаимодействие с пользователем для осуществления атаки.
            • Не требуется (None, N)
            • Требуется (Requred, R)
        • Влияние на CIA (impact) – влияние на ключевые аспекты безопасности (CIA)
          • Влияние на Конфиденциальность (Confidentiality, C)
            • Низкое (Low, L)
            • Среднее (Medium, M)
            • Высокое (High, H)
          • Влияние на Целостность (Integrity, I)
            • Низкое (Low, L)
            • Среднее (Medium, M)
            • Высокое (High, H)
          • Влияние на Доступность (Availability, A)
            • Низкое (Low, L)
            • Среднее (Medium, M)
            • Высокое (High, H)
        • Зависимые системы (scope change, S) – влияние на другие системы, которые не имеют уязвимости, но зависимы от уязвимой (напр. из-за “падения” роутера с уязвимостью страдают все подключенные к нему устройства, если не имеют backup)
          • Нет влияния (Unchanged, U)
          • Есть влияние (Changed, C)
    • • Временный (temporal) – изменяемые характеристики уязвимости, зафиксированные на момент оценки
        
        • Наличие эксплойтов (Exploit Code Maturity, E)
        • Наличие средств защиты от уязвимости (Remediation Level, RL) 
        • Полнота знаний об уязвимости (Report Confidence, RC)
    • • Среды (environmental) – характеристики уязвимости с учетом среды организации
        • Требования к безопасности (Security Requirements CR, IR, AR) для уязвимой и зависимых систем
        • Модифицируемые метрики (Modified Base Metrics,  MAV, MAC, MAPR, MUI, MS, MC, MI, MA) на основе конкретной среды организации

    Пример определения значений показателей базового компонента без расчета CVSS на базе атаки, в которой атакующий может вызвать сбой (crash) удаленного хоста особым пакетом сетевого трафика.

    • Attack vector (AV) – Network т.к. атакующий потенциально может находится где угодно и отправить созданный пакет (вообще, зачастую спорно, если 1) хост в изолированном сегменте 2) пакет нужно послать L2)
    • Attack complexity (AC) – Low т.к. создать пакет не сложно (напр. используя Scapy)
    • Privilege Required (PR) – None т.к. не требуется привилегий на уязвимой системе
    • User Interaction (UI) – None т.к. не требуется взаимодействия между атакующим и пользователем уязвимой системы
    • Scope (S) – Unchanged т.к. от хоста не зависят другие системы
    • Confidentiality Impact (C) – None т.к. атака нацелена на Availability
    • Integrity Impact (I) – None т.к. атака нацелена на Availability
    • Availability Impact (A) – High т.к. устройство полностью недоступно после эксплуатации уязвимости