Dusan Jevtic
AboutBlogContact

Table of Contents

Reading progress0%
Security FrameworksJan 15, 2025•12 min read

The Ultimate Guide to Cybersecurity Frameworks: MITRE, OWASP, NIST, CWE/CVE, and Compliance

#MITRE#OWASP#NIST#CWE/CVE#Compliance

Introduction

Cybersecurity frameworks provide structured methodologies for understanding, implementing, and managing security controls across modern organizations. They span from technical attack-mapping frameworks to high-level compliance standards, each playing a unique role in the broader security ecosystem.

For security professionals, mastering these frameworks is essential for accurate communication, meaningful risk assessments, and building mature security programs. They establish a shared language, proven best practices, and standardized approaches that help defenders navigate constantly evolving threats.

This guide explores the major cybersecurity frameworks such as MITRE ATT&CK and NIST, along with OWASP’s secure-development resources, vulnerability classification standards like CWE and CVE, and the key compliance frameworks organizations use to validate their security posture.

Understanding how these frameworks align and complement one another enables security teams to design stronger defenses, communicate risks more effectively, and meet regulatory expectations while maintaining operational resilience.

What is MITRE?

MITRE is a nonprofit organization that works closely with governments, researchers, and industry partners to improve global cybersecurity. It is known for creating widely used standards and resources such as ATT&CK, CWE, and CVE. These frameworks help teams understand attacker behavior, classify weaknesses, and track real-world vulnerabilities in a consistent and structured way.

MITRE ATT&CK Framework

The MITRE ATT&CK framework is a knowledge base of real-world cyber attacks maintained by the MITRE Corporation.

It organizes how attackers operate by splitting their behavior into two main parts: Tactics, which describe the attacker’s goal, and Techniques, which show the specific way that goal is carried out. This gives security teams a consistent and structured way to understand, document, and analyze adversary behavior.

Tactics

Tactics explain the purpose behind an attacker’s action - what they want to achieve during each step of an intrusion.

  • •Reconnaissance - gathering information and discovering weaknesses
  • •Execution - running malicious code or commands
  • •Persistence - staying on the system over time
  • •Defense Evasion - avoiding detection and bypassing security controls

Techniques

Techniques describe the actual method an attacker uses to perform a tactic. These are concrete, real-world actions seen in actual incidents.

Examples under the Reconnaissance:

  • •Active Scanning
  • •Checking for known vulnerabilities
  • •Collecting information about accounts, devices, or the environment

Purpose and Use

MITRE ATT&CK helps organizations understand how attacks unfold and improve their defenses. It is commonly used to:

  • •Detect suspicious or known malicious behavior
  • •Map alerts and incidents to known attacker methods
  • •Build better detection rules and defensive strategies
  • •Create realistic red-team and pentesting scenarios
  • •Study how threat groups operate in the wild

There are several ATT&CK matrices:

  • •Enterprise - most widely used (Windows, Linux, macOS, Cloud)
  • •Mobile - for iOS and Android
  • •ICS - for Industrial Control Systems

Related MITRE Frameworks: CWE and CVE

MITRE doesn't just maintain ATT&CK, it also manages CWE and CVE, two of the most important global standards for classifying vulnerabilities and weaknesses.

CWE - Common Weakness Enumeration

CWE is a collection of common software and hardware weakness types. Instead of listing vulnerabilities, it focuses on the underlying mistakes in design or code that can lead to security issues.

CWE ExamplesCommon Weakness Enumeration
ExampleDescription
CWE-79Improper Neutralization of Input During Web Page Generation (Cross-Site Scripting - XSS)
CWE-89Improper Neutralization of Special Elements in SQL Commands (SQL Injection)
CWE-287Improper Authentication

Purpose: Help developers recognize typical security flaws, give a shared naming system for weaknesses, and support tools that scan code for security issues.

In short: CWE explains why vulnerabilities exist.

CVE - Common Vulnerabilities and Exposures

CVE is a list of unique identifiers for specific security vulnerabilities found in real products. Each entry represents one confirmed vulnerability.

CVE ExamplesCommon Vulnerabilities and Exposures
ExampleDescription
CVE-2021-44228Log4Shell - a critical vulnerability in Apache Log4j
CVE-2017-0144EternalBlue - used in WannaCry ransomware
CVE-2019-0708BlueKeep - Remote Desktop vulnerability in Windows

Purpose: Provide a universal ID for each known vulnerability, help teams coordinate patches, and serve as the basis for major vulnerability databases and scanners.

Each CVE entry often references: Its CWE (the underlying weakness), its CVSS score (severity rating), and links to advisories, patches, and affected products.

In short: CVE identifies where a vulnerability exists.

In Summary

  • •MITRE ATT&CK → Describes attacker behavior and techniques
  • •CWE → Describes weaknesses in code or design
  • •CVE → Lists actual, real-world vulnerabilities in software

Together, they form a complete ecosystem: CWE explains why a vulnerability exists, CVE documents that vulnerability in a real product, and MITRE ATT&CK shows how attackers use it in real campaigns.

What Is OWASP?

The Open Worldwide Application Security Project (OWASP) is a non-profit foundation focused on improving the security of software and web applications. It provides free, open resources such as security guides, testing checklists, tools, and awareness standards used globally by developers, security engineers, and organizations.

It's most recognized publication is the OWASP Top 10 - a ranked list of the most critical web application security risks based on real-world data from industry research, vulnerability reports, and bug bounty programs.

Purpose and Goals

OWASP's goal is to make software security visible and measurable, so individuals and organizations can make informed decisions about risks.

It helps: Developers understand and fix security issues early, security teams prioritize testing and remediation, organizations build secure development lifecycles (SDLC), and auditors and assessors evaluate application security posture.

OWASP also maintains projects like:

  • •OWASP Top 10 - key web application risks.
  • •OWASP API Top 10 - API-specific security risks.
  • •OWASP Mobile Top 10 - mobile application vulnerabilities.
  • •OWASP ASVS - Application Security Verification Standard.
  • •OWASP SAMM - Software Assurance Maturity Model.

What Is The OWASP Top 10?

The OWASP Top 10 is a list of the most critical security risks to web applications, curated by the OWASP. It's updated periodically, with the most recent release being the OWASP Top 10:2025 (Release Candidate 1), based on global incident data and CWE mappings to ensure relevance to modern threats.

Each category represents a broad class of vulnerabilities, rather than a single issue. For example, "Injection" covers SQL, NoSQL, and OS command injections - all caused by similar root weaknesses.

OWASP Top 10 (2025 Edition)

OWASP Top 10 Categories2025 Edition
CategoryDescriptionExample
A01:2025 - Broken Access ControlMissing or flawed permission checks allow users to perform actions outside their assigned role.Normal user accessing admin endpoints.
A02:2025 - Security MisconfigurationIncorrectly configured security settings expose systems, APIs, or sensitive information.Debug mode enabled in production.
A03:2025 - Software Supply Chain FailuresCompromised or unverified external software components introduce security risks.Malicious dependency injected into a build pipeline.
A04:2025 - Cryptographic FailuresSensitive data exposed due to missing, weak, or broken encryption.Using outdated or insecure TLS configurations.
A05:2025 - InjectionUntrusted input manipulates commands, queries, or expressions executed by the application.SQL injection extracting database content.
A06:2025 - Insecure DesignSecurity weaknesses baked into architecture or workflows due to missing threat modeling or controls.No rate limiting on authentication routes.
A07:2025 - Authentication FailuresWeak authentication or session handling allows attackers to assume user identities.Session tokens predictable or not invalidated on logout.
A08:2025 - Software and Data Integrity FailuresFailure to verify integrity of data, code, or configurations allows tampering.Unsigned updates allowing malicious code injection.
A09:2025 - Logging & Alerting FailuresInsufficient monitoring prevents timely detection and response to attacks.No alerts for repeated failed login attempts.
A10:2025 - Mishandling of Exceptional ConditionsImproper handling of errors, edge cases, or unexpected inputs leads to unreliable or insecure behavior.Application revealing stack traces or crashing from malformed input.

How OWASP Top 10 Is Built?

The OWASP Top 10 is data-driven and based on aggregated global data. Sources include: Security vendors and application scanners, penetration testing results, bug bounty and responsible disclosure programs, public vulnerability databases (CVE/NVD), and research contributions from the security community.

Each risk is mapped to multiple CWE identifiers (root causes) - for example: A03: Injection → CWE-89 (SQL Injection), CWE-77 (Command Injection) and A01: Broken Access Control → CWE-284 (Improper Access Control).

OWASP then scores and ranks each category using: Exploitability - how easy it is to exploit, Detectability - how easy it is to find, and Impact - potential damage if exploited.

Relationship to CWE and CVE

Framework RelationshipsOWASP, CWE, and CVE
FrameworkFocusExample
OWASP Top 10High-level risk categoriesA03: Injection
CWERoot cause weaknessesCWE-89: SQL Injection
CVESpecific, real-world vulnerabilitiesCVE-2021-44228 (Log4Shell)

How they connect: OWASP defines what kind of security problem it is. CWE defines why that problem happens in the code. CVE identifies where it has occurred in real software.

This allows OWASP Top 10 to stay relevant and data-backed, rather than theoretical.

Why OWASP is Not a Cybersecurity Framework?

Cybersecurity frameworks usually provide a structured, organization-wide approach for managing risk. They define governance requirements, outline security controls, and help teams align processes across areas such as compliance, monitoring, and incident response. Well-known examples include the NIST Cybersecurity Framework, ISO 27001, CIS Controls, and COBIT.

OWASP serves a different purpose. Its projects focus specifically on application-level security, offering guidance, testing standards, and educational resources. Rather than defining an enterprise security program, OWASP concentrates on helping teams secure the software they build and maintain.

How OWASP Fits Into the Broader Cybersecurity Landscape?

OWASP can absolutely be used within cybersecurity frameworks, even though it isn’t one on its own.

Many organizations rely on OWASP resources to strengthen the application-security parts of their security programs. Frameworks like NIST SP 800-53, PCI DSS, and ISO 27001 set requirements around secure coding, testing, and vulnerability management, and OWASP’s guidelines help teams carry out those requirements in practice.

So while OWASP doesn’t function as a full enterprise cybersecurity framework, it remains one of the most influential sources for web and application security guidance. Its projects are often used alongside formal frameworks to improve software security across development and security teams.

NIST: Organizational Security Management

NIST (National Institute of Standards and Technology) focuses on the big-picture management of cybersecurity across an entire organization - not individual vulnerabilities or exploits.

Think of it as the strategy layer that defines how a company should organize, govern, and continually improve its security posture. It's not about code - it's about process, structure, and maturity.

What NIST Does?

NIST defines how to: Identify what assets and data are critical, protect them through policies, controls, and training, detect suspicious activity or attacks early, respond effectively when incidents occur, and recover and improve after incidents.

These five pillars come from the NIST Cybersecurity Framework (CSF) - the foundation of most modern security programs.

Example Use Cases

  • •A bank uses NIST CSF to design its company-wide cybersecurity program.
  • •A CISO uses NIST maturity levels to report progress to executives.
  • •A security team builds an incident response plan based on NIST guidelines.
  • •A government contractor aligns with NIST SP 800-171 to meet compliance.

NIST is strategic - it tells you what to secure and how to manage it.

Why It Matters to Pentesters?

Even though NIST isn't a technical framework like MITRE, understanding it helps you: Speak the same language as executives and compliance teams, understand why certain tests, policies, and controls exist, and map your findings to organizational impact (not just technical flaws).

When pentesters mention NIST in reports, it connects technical findings to business risk, which is exactly what decision-makers care about.

From Security Frameworks to Compliance

After technical frameworks like MITRE ATT&CK (how attackers work) and NIST (how to manage security overall), along with OWASP’s secure-development resources, there's another category you'll constantly hear about in the field - organizational and compliance frameworks.

These don't teach you hacking or defense - they define how companies prove they're secure. They outline how security should be managed, audited, and reported to clients, investors, and regulators.

This is also where penetration testing comes into play. A pentest is only one small part of a company's overall security and compliance program - but it's often the most visible and measurable piece. Most organizations don't do pentests out of curiosity; they do them because frameworks like ISO 27001, SOC 2, or PCI DSS require or recommend them.

Depending on the framework, companies can choose whether to perform a penetration test, vulnerability assessment, or both to demonstrate they're actively identifying and managing security risks.

Why Companies Care About Compliance Frameworks?

Compliance frameworks aren't just paperwork - they're how companies prove to customers, partners, and regulators that their data is safe. Each framework targets a specific audience, industry, or business goal.

Below are the most common ones you'll run into and why organizations need them.

ISO/IEC 27001 - Global Security Certification

Why companies want it: To show customers, investors, and partners that they have a formal, audited information-security program that meets international standards.

Who it's for: Any company (especially SaaS, fintech, or enterprises) that handles sensitive customer data globally.

Business value: Recognized worldwide (EU, US, Asia), helps win enterprise clients who require certification, demonstrates long-term commitment to data protection, and reduces risk and audit duplication - one certificate often satisfies multiple customers.

Penetration testing isn’t explicitly required by ISO/IEC 27001:2022, but it aligns directly with Annex A.8.8 - Management of Technical Vulnerabilities. Most organizations undergoing certification perform at least one annual pentest as part of their vulnerability management process, demonstrating that they identify, test, and address security weaknesses.

In short: Companies get ISO 27001 to prove they take security seriously at an organizational level.

PCI DSS - Payment Card Data Protection

Why companies want it: Because Visa, Mastercard, and other card brands require it. Any business that stores, processes, or transmits cardholder data must comply.

Who it's for: E-commerce sites, payment processors, POS vendors, or any system touching credit/debit card info.

Business value: Keeps card processing privileges, avoids heavy fines or brand bans after breaches, builds trust with customers handling payments, and forces good security practices like segmentation, encryption, and logging.

Pentesting and PCI DSS: Penetration testing is mandatory under Requirement 11.4 (formerly 11.3 in earlier PCI DSS versions). Organizations must perform internal and external pentests at least annually and after any major system change.

In short: PCI DSS is mandatory if you handle payment cards - no compliance, no payments.

SOC 2 - Trust for Service Providers

Why companies want it: To prove to clients (especially B2B and SaaS customers) that their data is handled securely and reliably.

Who it's for: Cloud service providers, SaaS platforms, managed service providers, and data-processing companies.

Business value: Common requirement in vendor-security questionnaires, demonstrates compliance with Trust Service Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy, shows that controls are tested by an independent CPA firm (Type II audit), and often required before signing large contracts.

Pentesting and SOC 2: Pentesting is not explicitly required, but it's a common practice to support the Security and Confidentiality criteria. Most SOC 2 Type II audits expect to see at least annual penetration testing or continuous vulnerability assessments.

In short: SOC 2 is a U.S. assurance report that says, "You can trust us with your data."

HIPAA - Healthcare Data Protection (U.S.)

Why companies want it: Because it's the law if they handle Protected Health Information (PHI). Hospitals, clinics, insurance providers, and even SaaS vendors supporting them must comply.

Business value: Avoids legal penalties and massive fines, protects patient data confidentiality and integrity, and opens the door to working with healthcare clients.

Pentesting and HIPAA: Penetration testing isn't directly mentioned in HIPAA, but it falls under "technical safeguards" for protecting systems and ensuring integrity. Regular pentesting is considered an industry best practice for compliance and risk management.

In short: HIPAA = legal compliance for anything touching U.S. healthcare data.

GDPR - Privacy Law (Europe)

Why companies want it: Because GDPR applies to anyone processing personal data of EU residents, regardless of where the company is based.

Business value: Avoids steep fines (up to 4% of global revenue), builds customer trust through transparency and privacy rights, and required to operate in the EU legally.

Pentesting and GDPR: GDPR doesn't mandate pentesting by name, but Article 32 requires "appropriate technical and organizational measures" to secure data. Pentesting is widely recognized as one of those measures - especially for proving due diligence.

In short: GDPR = mandatory privacy law for handling European user data.

CIS Controls - Practical Security Checklist

Why companies use it: To improve security posture quickly using a prioritized list of 18 technical controls (like asset inventory, patching, MFA, backups).

Who it's for: Organizations that want to harden defenses without complex governance - often used internally or as a starting point before ISO/NIST.

Pentesting and CIS Controls: CIS Controls explicitly include penetration testing (Control 18), but organizations can scale depth/frequency based on their risk profile and implementation group.

In short: CIS Controls = hands-on best practices for day-to-day security hardening.

COBIT - IT Governance and Oversight

Why companies want it: To align IT and cybersecurity with business goals and regulatory requirements. Used by executives and auditors more than engineers.

Business value: Ensures accountability and risk oversight, and integrates with NIST and ISO for governance reporting.

Pentesting and COBIT: Penetration testing is not required under COBIT since it's a governance framework, not a technical one. However, organizations using COBIT often reference pentesting results as part of their risk evaluation process.

In short: COBIT = management and audit-level governance framework.

In Summary

  • •NIST / ISO 27001 / CIS Controls → Build and manage security programs.
  • •PCI DSS / SOC 2 / HIPAA / GDPR → Prove compliance and data protection.
  • •COBIT → Oversee and audit security at the business level.
  • •Penetration testing → Only one part of this ecosystem, but an important one.
  • •Mandatory: PCI DSS
  • •Strongly Recommended: ISO 27001, SOC 2, GDPR, HIPAA, CIS Controls (testing required, but not specifically pentesting, a vulnerability scan can also satisfy the requirement depending on risk)
  • •Not Required: COBIT

Why it matters: Barely anyone performs pentests just "for fun." Most organizations do them because compliance frameworks expect it - it's their way of showing due diligence. Pentesting, vulnerability assessments, and other security tests are how companies demonstrate that their controls actually work, not just that they exist.

Conclusion

Cybersecurity frameworks provide the essential structure and common language needed for effective security management across organizations of all sizes. From technical attack patterns to compliance requirements, these frameworks work together to create comprehensive security postures.

Understanding how MITRE ATT&CK, OWASP, NIST, CWE/CVE, and compliance frameworks interconnect allows security professionals to communicate risks effectively, prioritize defenses, and demonstrate due diligence to stakeholders and regulators.

As the threat landscape continues to evolve, these frameworks provide the foundational knowledge and standardized approaches needed to build resilient security programs that can adapt to new challenges while meeting business objectives and regulatory requirements.

Share this article