Common Assessing and Rating Security Vulnerability Systems

I. Common Vulnerability Scoring System (CVSS)

CVSS is a framework for assessing and rating the severity of security vulnerabilities. It provides a standardized method for measuring the impact and exploitability of vulnerabilities, enabling organizations to prioritize their response and allocate resources accordingly. The framework assigns a numerical score from 0 to 10 (the most severe vulnerability). CVSS consists of three metric groups:

1. Base Metrics: These metrics evaluate the intrinsic qualities of a vulnerability, such as the attack vector, complexity, and impact on the system. The base score reflects the fundamental characteristics of the vulnerability.

2. Temporal Metrics: These metrics capture the aspects of a vulnerability that may change over time, such as the availability of exploit code, the remediation level, and the urgency of applying patches. The temporal score reflects the current state of the vulnerability.

3. Environmental Metrics: These metrics allow organizations to customize the CVSS score based on their specific environment. Factors such as the importance of the affected asset, the value of the data at risk, and the security controls in place are taken into account to calculate the environmental score.


II. Open Web Application Security Project (OWASP)

The OWASP Top 10 is a renowned list of the most critical web application security risks. Published by OWASP, a nonprofit organization focused on software security, it guides developers, security professionals, and organizations in prioritizing web application security. The latest is the OWASP Top 10 vulnerabilities 2021, released in September 2021with the following changes (From A01:2021 To A10:2021)

1. Broken Access Control is now the most serious web application security risk, with numerous occurrences of vulnerabilities related to it.

2. Cryptographic Failures, previously known as Sensitive Data Exposure, focuses on cryptography-related failures that can lead to data exposure or system compromise.

3. Injection, although still significant, slides down to the third position.

4. Insecure Design is a new category that emphasizes design flaws and the need for secure design principles and architectures.

5. Security Misconfiguration moves up and now includes XML External Entities (XXE) vulnerabilities.

6. Vulnerable and Outdated Components, previously titled Using Components with Known Vulnerabilities, rises in importance due to the difficulty of testing and assessing its risk.

7. Identification and Authentication Failures, formerly Broken Authentication, includes CWEs related to identification failures and benefits from standardized frameworks.

8. Software and Data Integrity Failures is a new category that focuses on assumptions regarding software updates, critical data, and CI/CD pipelines.

9. Security Logging and Monitoring Failures, previously Insufficient Logging & Monitoring, expands to encompass more failure types that can impact visibility and incident response.

10. Server-Side Request Forgery, added from the community survey, highlights its importance despite the relatively low incidence rate in the available data.


III. Common Vulnerabilities and Exposures (CVE)

CVE (Common Vulnerabilities and Exposures) is a system that tracks known vulnerabilities in software and hardware. It assigns unique identifiers (CVE IDs) to each vulnerability, providing a standardized naming scheme. Managed by the MITRE Corporation, CVE IDs are used by security professionals, researchers, and organizations to reference and communicate vulnerability information. An example CVE ID is CVE-2021-1234, where "CVE-2021" represents the year and "1234" is the unique identifier.

CVE IDs help to improve the awareness and understanding of vulnerabilities across the cybersecurity community. They enable organizations to track and manage vulnerabilities effectively, apply appropriate patches and mitigations, and ensure the security of their systems and networks. Additionally, CVE IDs facilitate the exchange of vulnerability information and support the coordination of vulnerability disclosures and remediation efforts.

Comments

Post a Comment

Popular posts from this blog

QUALITY MANAGEMENT PRINCIPLES & PRACTICES

Image
  I.       QUALITY MANAGEMENT PRINCIPLES 1.      Meeting Customer Expectations : o    Detail : Quality is defined by how well a product or service meets the needs and expectations of customers. This means understanding what your customers value and ensuring your offerings align with those values. o    Example : If you are developing a software product, quality means delivering a bug-free, user-friendly application that performs the functions your customers need. Regularly gathering customer feedback and making improvements based on their input is crucial.   2.      Everyone's Responsibility : o    Detail : Quality is not just the responsibility of the quality assurance team; it involves every employee in the organization. Each person must ensure that their work meets the required standards and contributes to the overall quality. o    Example : In yo...
Read more

KPIs EXAMPLES

  Corporate Quality, Security, Software Development Life Cycle, Hardware Development Life Cycle, Manufacturing KPIs (Key Performance Indicators) Examples Key  Performance Indicators (KPIs) are specific metrics that are used to evaluate the performance of an organization, team, or individual in achieving their objectives. These metrics are quantifiable and directly linked to strategic goals, allowing for monitoring progress and making informed decisions. KPIs usually include primary owners, secondary owners, key objectives, measurements, due dates, status updates, percentage completions, comments etc. Here are some examples of KPIs: I.                QUALITY KPIs:   1. Customer Satisfaction Index (CSI):    - Definition: CSI measures how satisfied customers are with a company's products or services.    - Calculation: CSI can be calculated through surveys, feedback forms, o...
Read more

Firmware Development and Debugging

An Approach To Firmware Development and Debugging 1. Understand the Hardware: Before writing firmware, you need a deep understanding of the hardware you're working with. Study the datasheets, reference manuals, and schematics for the microcontroller or embedded system you're using. This will help you understand the available peripherals, memory layout, and other hardware-specific details. 2. Choose a Programming Language: Firmware can be written in various programming languages, with C and C++ being the most common due to their low-level capabilities and efficiency. Choose a language that is supported by the microcontroller's toolchain and suits the project's requirements. 3. Set Up the Development Environment: - Install the necessary Integrated Development Environment (IDE) or text editor. - Install the toolchain (compiler, linker, debugger) that supports your microcontroller. - Set up any necessary drivers for programming and debugging hardware. 4. Start Writing Code:...
Read more