Section 5.6 Classifying Vulnerability Information
As you study this section, answer the following questions:
- What steps can you take to validate the results of a vulnerability scan?
- What are some benefits of vulnerability management reporting?
- How do you interpret the risk score to prioritize remediation actions for discovered vulnerabilities?
- What are some KPIs that an organization can use to measure the effectiveness of its cybersecurity efforts?
- What should an action plan include in response to a vulnerability report?
- Why is it important for security teams and organizational leaders to work together as an organization grows and changes?
- Why do some organizations continue to use legacy systems, and what are some risks involved in doing so?
The key terms for this section include:
| Term | Definition |
|---|---|
| Vulnerability risk score | A score calculated on things like the nature, severity, and potential impact of a vulnerability. |
| Key performance indicators (KPIs) | Metrics used to measure progress toward goals and identify areas for improvement. In cybersecurity, they can include things like incidents, detection time, threats, and resource allocation. |
| Configuration management | The process of tracking and controlling changes in a system's configuration to ensure that systems remain consistent, compliant, and secure. |
| Organizational governance | The system of rules, practices, and processes an organization uses to control its operations and the strategic direction it pursues. |
| Legacy systems | Outdated systems or software applications that are still in use but may have limited compatibility with newer systems, programs, or applications. |
| Proprietary systems | Specialized systems designed for a specific purpose and tailored to an organization's individual needs. |
This section helps you prepare for the following certification exam objectives:
| Exam | Objective |
|---|---|
| CompTIA CySA+ CS0-003 | 1.4 Compare and contrast threat-intelligence and threat-hunting concepts
2.1 Given a scenario, implement vulnerability scanning methods and concepts
2.3 Given a scenario, analyze data to prioritize vulnerabilities
2.5 Explain concepts related to vulnerability response, handling, and management
4.1 Explain the importance of vulnerability management reporting and communication
|
| TestOut CyberDefense Pro | 2.1 Perform threat analysis
3.1 Implement security controls to mitigate risk
4.3 Analyze indicators of compromise
|
5.6.1 Vulnerability Management Life Cycle
Click one of the buttons to take you to that part of the video.
Vulnerability Management Life Cycle 00:00-00:49 Every business has sensitive information that hackers can use to put the company and its employees at risk. Even a non-malicious user, like an ignorant employee, can cause problems if proper security isn't in place. Unless a business physically unplugs their computers and never uses them again, they can become a target for hackers. For this reason, every organization should implement vulnerability management, as it evaluates and controls the risks and vulnerabilities on their systems.
In this lesson, I'm going to talk about the vulnerability management life cycle. This is the process security analysts use to protect organizations. There are six phases in the cycle: baseline creation, vulnerability assessment, risk assessment, remediation, verification, and recommendation.
Baseline Creation 00:49-01:51 The first step is pre-assessment. Start by looking at the current security policies' effectiveness. Establish risks by evaluating how the policies are enforced and which vulnerabilities might've been overlooked. Try to see what the organization looks like from an outsider's and an insider's point of view. No organization is immune to security gaps.
Set goals with management. Make sure you plan start dates and end dates. Determine which systems to begin testing, set up testing standards, get approval in writing, and keep management informed as you go through this part of the process. For your own protection, it's important to make sure that everything you do is performed with full disclosure. The correct people need to know—and approve—what you're going to test, how you'll test, and when. This disclosure protects you and reassures the organization's management of your integrity and professionalism. It's also crucial to know the organization's goals so that you're able to address their specific concerns. This also helps you know where to begin and what your employer expects of you.
Vulnerability Assessment 01:51-02:36 After you've established a baseline, move on to the vulnerability assessment phase. This is when you identify vulnerabilities in the organization's infrastructure, including in the operating system, web applications, and web server. It's important to decide the best times to test, as you don't want to risk shutting systems down during peak business hours or other sensitive times. You must also choose the best security assessment tools for each system. Be sure that you completely understand each tool you use, as you can easily damage a system by using the wrong tools for the job.
Everything you do as a security analyst depends on your ability to do effective assessment. This is the key phase. If you don't conduct the correct tests with the correct tools, you can't accurately assess security vulnerabilities.
Risk Assessment 02:36-03:20 Let's move on to the next phase, which is risk assessment. The risk assessment phase is when risks are identified, characterized, and classified along with techniques you plan to mitigate them with. Here you take the vulnerability tests' results, organize them according to risk level, and categorize them by sensitivity and access.
You need to create reports that clearly identify the problem areas to present to management. Then, you need to produce an action plan to control weaknesses, protect information, and harden systems. In this phase, it's critical to communicate clearly with management about your findings and subsequent recommendations. You'll be protected as you receive written approval to implement your remediation plans.
Remediation 03:20-04:03 Let's define remediation. Remediation means the steps you take to mitigate risks, such as evaluating vulnerabilities, locating potential entry points, and designing responses for vulnerabilities. In this phase, you actually implement the controls from your action plan. Begin with the highest-impact and highest-likelihood security problems, and then work down to the lower-risk issues.
Finding weaknesses is only valuable if you're able to correct the problems and harden the system. It makes the most sense to protect the organization's most vulnerable areas first. It's impossible to catch every single vulnerability, but that's why it's essential to establish the most urgent issues based on things like business sense and legal compliance.
Verification 04:03-04:35 Once you've completed the planned remediation, it's important to verify your work. The verification phase helps a security analyst determine whether all the previous phases are effectively employed or not. It wouldn't make sense to patch systems without testing to validate that the problems are actually fixed.
So, in this phase, you re-test the systems for verification. Even though you might be sure that you've corrected all the important issues, you want to prove your work to management and have evidence to show that your techniques were effective. You increase your service value when you can show your work's validity.
Recommendation 04:35-05:22 After you've verified your work, move on to the post-assessment phase, which is also known as the recommendation phase. At this point, recommend ongoing monitoring and routine testing to proactively protect the organization and its clients.
It might be tempting for an organization to feel secure after going through the process of penetration testing and hardening corrections you've performed, but it's important for you to help them understand that hackers have time on their side. There'll always be new security threats, so it's critical for the organization to have monitoring tools and regularly scheduled maintenance testing in place. And remember, to be a good security analyst, you need to stay within the life cycle order we've discussed. Your consistency will pay off in the end when management senses their system's newfound security advantage.
Summary 05:22-05:46 That's it for this lesson. In this lesson, we learned about the vulnerability management life cycle and each of its phases. The phases are: create a baseline, complete a vulnerability assessment, complete a
risk assessment, implement a remediation process, verify the remediation, and suggest continuous monitoring.
5.6.2 Vulnerability Management Life Cycle Facts
Every business has sensitive information that, if accessed by hackers, could be used in ways that could put the company and its employees at risk. Even a non-malicious user, such as an untrained employee, could cause problems if proper security is not in place. Unless a business physically unplugs its computers and never uses a network, the company can be a target. Therefore, vulnerability management should be implemented in every organization to identify, evaluate, and mitigate risks and vulnerabilities.
This lesson covers the following topics:
- Vulnerability management life cycle
Resources for baseline creation*
Vulnerability Management Life Cycle
The following table describes the vulnerability management life cycle a network security analyst uses to protect an organization.
| Phase | Description |
|---|---|
| Baseline creation | A configuration baseline describes a list of requirements regarding how a device, operating system, or software is configured to operate. A configuration baseline outlines the minimum set of requirements. For security, this means the minimum amount of protection a device must have in place to be considered safe. Baseline requirements vary between organizations and are developed in parallel to risk management. High-risk environments will have long and detailed baseline requirements, whereas low-risk environments may use simple checklists. Best-practice security baselines are available from several sources, such as device manufacturers, software vendors, and industry expert groups. Regardless of the baseline's source, it represents a "measuring stick" analysts can use to determine if an endpoint is configured correctly. The life cycle starts by defining the effectiveness of the current security policies and procedures. The following steps can help you establish a baseline from which you can begin vulnerability management:
It is crucial to know the goals of the organization so that you can to address specific concerns. This will also help you to know where to begin and what is expected of you. |
| Vulnerability assessment | The vulnerability phase refers to identifying vulnerabilities in the organization’s infrastructure, including the operating system, web applications, and web server. This is the phase where penetration testing begins. It is important to decide the best times to test. You do not want to risk having systems shut down during peak business hours or other sensitive times. You must also choose the best security assessment tools for the systems you choose to test. Be sure that you understand what each option of every tool does before you use it. This helps you avoid damaging the systems. Everything you do as an ethical hacker depends on your ability to perform effective penetration testing. You must conduct the correct tests with the correct tools to assess the security vulnerabilities accurately. All remaining phases depend on the effectiveness of this vulnerability assessment phase. |
| Risk assessment | In this phase, you organize the results of your vulnerability testing according to risk level and then categorize them by levels of sensitivity and access. You will need to create and present reports that clearly identify the problem areas, then produce a plan of action to address weaknesses, protect information, and harden systems. At this phase, it is critical to communicate with management about your findings and your recommendations for locking down the systems and patching problems. You will be protected and valued as you communicate and receive written approval for implementing the suggested remediation. |
| Remediation | Remediation refers to the steps taken regarding vulnerabilities, such as evaluating vulnerabilities, locating risks, and designing responses. In this phase, you implement the controls and protections from your plan of action. Begin with the highest-impact and highest-likelihood security problems, then work through the lower-impact and lower-likelihood issues. It makes the most sense to first protect the organization from its most vulnerable areas and then work on the less likely and less impactful areas. It may be impossible to identify and fix every single vulnerability that exists in an organization. That is why it is essential to start with the most urgent issues based on what makes the most business sense, what management expects from you, and compliance with regulations. |
| Verification | The verification phase helps the security analyst verify whether all the previous phases have been effectively executed. In this phase, you retest the systems for verification. Even though you may be certain that you have corrected vulnerability issues and are confident in your work, it benefits you to prove your work to management and have verifiable evidence to show that your patching and hardening implementations have been effective. You will increase the value of your services when you can show the validity of your work. |
| Monitoring | After verifying your work, move on to the post-assessment phase, also known as the recommendation phase. At this point, recommend ongoing monitoring and routine penetration testing to proactively protect the organization and its customers or clients. It may be tempting for an organization to feel secure after going through the process of penetration testing, implementing changes, and hardening the system. However, it is important for you to help management understand that hackers have time on their side, and there will always be ongoing and new threats to security. Therefore, it is critical that the organization has monitoring tools in place and regularly schedules vulnerability maintenance testing. |
Resources for Baseline Creation
Center for Internet Security (CIS)
As well as vendor-supplied templates, you might use third-party or regulatory configuration baselines. The Center for Internet Security (CIS) ( cisecurity.org ) is a not-for-profit organization that publishes and maintains Critical Security Controls (or system design recommendations). At the time of writing, the current version of the Critical Security Controls is comprised of the following items:
- Inventory and Control of Enterprise Assets
- Inventory and Control of Software Assets
- Data Protection
- Secure Configuration of Enterprise Assets and Software
- Account Management
- Access Control Management
- Continuous Vulnerability Management
- Audit Log Management
- Email and Web Browser Protections
- Malware Defenses
- Data Recovery
- Network Infrastructure Management
- Network Monitoring and Defense
- Security Awareness and Skills Training
- Service Provider Management
- Application Software Security
- Incident Response Management
- Penetration Testing
Department of Defense (DoD) Security Technical Implementation Guides (STIGs)
The Defense Information Systems Agency (DISA) is part of the U.S. Department of Defense (DoD). It is a combat support organization that provides information technology and communication services to all parts of the DoD. DISA oversees the technical side of delivering, organizing, and managing defense-related information, including the Security Technical Implementation Guide (STIG) standards. Additional details regarding STIGs are available from https://public.cyber.mil/stigs/ .
DISA STIG compliance has three categories, each of which reflects the severity of the risk of failing to address a vulnerability:
Category I - Any vulnerabilities that will immediately cause a breach of confidentiality, availability, or integrity. These exposures can grant unapproved access to confidential information, disrupting service. These threats are the most dangerous and may result in death, damage to facilities, or a failure of a mission. Category II - Any vulnerabilities resulting in loss of confidentiality, availability, or integrity and can lead to a Category I vulnerability, injury, damage to equipment, or degrade a mission. Category III - Any vulnerabilities that degrade controls implemented to protect against the loss of confidentiality, availability, or integrity and can lead to a Category II vulnerability, delay recovery from an outage or negatively affect the accuracy of data.
5.6.3 Vulnerability Reporting Overview
Click one of the buttons to take you to that part of the video.
Vulnerability Reporting Overview 00:00-00:33 Knights riding into battle may have felt very protected when wearing plate armor, but their savvy opponents would know where the weak points in armor were, like the backs of the knees and armpits. Smart knights would take extra precautions in how they fought to protect these vulnerable areas.
As a cybersecurity specialist, you know that no matter what security measures your network may have, there will always be vulnerabilities. And just like the smart knights that took extra precautions to protect their vulnerabilities, you'll want to take extra precautions with the vulnerable areas of your network.
Vulnerability Scanners 00:33-00:57 So, where could a network be vulnerable? Each network is unique, so it's important to use tools like vulnerability scanners to determine the weaknesses in your network.
A vulnerability scan is an automated process performed by a computer program to discover security weaknesses such as open ports, misconfigured firewalls, unpatched software, cross-site scripting, and many more common weaknesses.
Vulnerability Validation 00:57-01:30 Even though these scanners are essential tools, their findings may not be completely accurate. So, it's important to validate the findings. For example, the scan results may identify vulnerable software, but closer inspection reveals that the software is no longer on the specified endpoint.
Another consideration is the scope of the scan. For example, knowing whether the scan was performed externally or internally will help to interpret the findings. Internal traffic differs from external traffic, affecting the interpretation of the scan results.
Vulnerability Scan Results 01:30-02:15 Scans can produce false positive, true positive, false negative, or true negative results. False positive means the scan incorrectly indicates a vulnerability is present when it's not. A true positive result means that the scanner correctly identified a vulnerability.
A false negative result means the scanner incorrectly shows that a vulnerability doesn't exist. This result is the most concerning issue as it represents the failure of the scanning tool to report on a legitimate issue. You can mitigate this issue by using multiple scanning tools because the scan outputs of each tool can be correlated to identify vulnerabilities. A true negative result means that the scan correctly indicates that a system doesn't have a vulnerability.
Risk Score and Priority 02:15-03:09 Scanners may include a risk score for each vulnerability it finds. Risk scores help measure the risk posed by a particular system, application, or individual vulnerability in terms of being successfully hacked or breached. The score depends on many factors, including the nature and quantity of discovered vulnerabilities, their severity, potential impact, and the likelihood of successful exploitation.
The vulnerability risk score can be used to prioritize work and to identify vulnerabilities that require immediate attention, such as critically severe, actively exploited, and zero-days vulnerabilities. Actively exploited critical and zero-day vulnerabilities typically warrant focused attention and should be tracked in a dashboard. The time between when a zero-day is published and when a patch is available is critical, as organizations are effectively defenseless during this time.
Vulnerability Management Reporting 03:09-04:28 Once you've validated the scan results, you'll want to report your findings to your organization. These vulnerability reports range from simple summaries of existing vulnerabilities to detailed reports outlining specific steps to reduce potential risks. Vulnerability reporting increases awareness so that leaders can make informed decisions on securing their networks and get back to the work of their business.
Vulnerability reporting also provides metrics designed to track the progress and effectiveness of vulnerability management efforts.
Vulnerability management reporting capabilities are also required to maintain compliance with regulations, laws, data privacy legislation, and security standards.
Vulnerability reports are often the output of vulnerability scanning platforms designed to identify host vulnerabilities in various products, including operating systems, hypervisors, databases, desktop applications, mobile devices, web platforms, network devices, and many others. Vulnerability reports can include data collected and organized from other sources too.
For example, a compliance manager may compile reports based on audit findings, third-party assessments, or physical security risks. Security teams may manually evaluate endpoints using software tools and then generate reports based on their analysis.
Vulnerability Report Content 04:28-05:43 Now that we've looked at interpreting scan results and the benefits of vulnerability management reporting, let's look closer at what the report should include. The report should detail identified vulnerabilities, such as missing patches, incorrect configuration settings, and weak passwords, and include details regarding the type of vulnerability, the number of instances, the affected systems, the risk levels, and mitigation recommendations. By taking a risk-based approach that considers the severity of the vulnerability and its potential impact, vulnerability reports can help organizations prioritize their efforts and allocate resources more effectively.
Mitigation recommendations include things like identifying a patch or describing a workaround. Some vulnerabilities require workarounds that are either permanent or temporary. A permanent workaround addresses a fundamental flaw that's unpatchable, whereas a newly discovered vulnerability may need a temporary workaround until a patch is available.
Vulnerability reports must provide actionable recommendations for remediation and mitigation, including specific steps organizations can take to address vulnerabilities, reduce risks, and improve the overall security posture.
Vulnerability Report Best Practices 05:43-06:28 When creating your reports, use consistent formats, standard color coding, and report on a regular schedule. It's also important to use automation in as many processes as possible to make the entire process more consistent, reliable, efficient, and easy to maintain.
You may want to use a top ten style list to highlight potential problems, focus on important activities, or environmental changes. Putting the top ten list into a dashboard with charts or graphs can be an effective way to present your findings.
Well, that's it for this lesson. In this lesson, we reviewed vulnerability management reporting. We talked about validating and interpreting vulnerability scan findings. Then, we talked about what a vulnerability report should include and some best practices for creating and presenting them.
5.6.4 Validating Vulnerabilities
This lesson covers the following topics:
- Vulnerability scans
- Validating vulnerabilities
Vulnerability Scans
A vulnerability scan is an automated process performed by a computer program designed to discover security weaknesses in networks, applications, and computers. Vulnerability scans check for things like:
- Open ports
- Protocol compliance
- Misconfigured firewalls or routers
- Unpatched software
- Cross-site scripting (XSS) problems
- SQL injection weaknesses
The vulnerability scanning software creates simple informative output or a formal report identifying the vulnerabilities it discovered. Scan targets can include an individual system, a subnet, or a logical grouping of assets, such as databases, web, application servers, or perhaps industrial control systems. It is essential to save reports to establish trends over time that demonstrate the effectiveness of the vulnerability management program.
Validating Vulnerabilities
A step-by-step analysis of vulnerability scanning results is needed to validate the report's content because some items may be inaccurate. For example, the report may identify vulnerable software, but closer inspection may reveal that the software is not present on the endpoint specified.
Another important consideration is the scope of the scan. For example, was the scan performed externally or internally? Is the internal network part of the overall enterprise network, or is it an isolated network such as one used for an industrial control system (ICS)? An external scan focuses on the view of an organization's systems from the internet. Any system directly accessible from the internet is bombarded continuously with many different scans, probes, and exploits. Any vulnerability in an externally accessible system is hugely concerning, as the probability of it being quickly exploited is very high. Vulnerabilities identified on externally accessible systems are often treated with a "patch first, test second" approach because concerns over successful exploitation frequently supersede concerns over potential glitches or bugs introduced by a patch.
Internal scans focus on the view of systems from within the private network, for example, the view of other internal systems from a trusted server or desktop computer. Vulnerabilities from this viewpoint are still concerning but typically require a more measured approach to remediation than external systems. It is essential to consider the ramifications of an attacker successfully obtaining access to an internal system or the actions of a malicious insider (such as a staff member) and the damage that could result from their efforts. These concerns are balanced by monitoring infrastructure. An internal network should have various monitoring tools, watching for and alerting on signs of malicious activity. This approach differs somewhat from external system monitoring because external traffic is riddled with port scans, injection attacks, and other frequent and expected malicious activity. However, the internal network should not contain this type of activity, so identifying suspicious activity or network traffic is more concise. Additionally, keeping internal systems up and running is a high priority, so remediating vulnerabilities identified on internal systems often require more time and planning to ensure that patches will not introduce any new problems.
Security analysts must review vulnerability scan reports carefully to confirm or refute the findings. Ideally, the vulnerability scan provides detailed information regarding all vulnerabilities in the scanned systems and devices. Realistically, handling the report as trusted guidance pending further inspection is a better approach. While CVSS scores are instrumental in defining the severity of a vulnerability, they are not a perfect solution.
While CVSS scores help define the potential impact of a vulnerability, they can lead to problems if not used correctly. CVSS scores are based on many assumptions and can be challenging to interpret. For example, a vulnerability receiving an 8.3 CVSS score will be regarded as a critical vulnerability, whereas a vulnerability scoring 7.8 will be interpreted as a high-level vulnerability. Many organizations understandably focus intensely on critical vulnerabilities identified by their scanning tools. However, without a deep understanding of the underlying assumptions of the scores, it can be challenging to assess whether they are wholly accurate. For example, suppose vulnerabilities are identified on a completely isolated host or hosts on an isolated network. In that case, this might overshadow concerns about vulnerabilities exploited via a network attack vector. Combining the CVSS score with other factors, such as the type of vulnerability, the likelihood of an attack, the purpose of the system involved, and business criticality, results in a more accurate interpretation.
A vulnerability scan may produce any of the results below. A security analyst's challenge is to identify them in a scan report.
| Result | Description |
|---|---|
False positive | When a vulnerability scan incorrectly indicates that a vulnerability or misconfiguration is present when it is not. For example, a scanner may identify that vulnerable software is present on an endpoint, but closer inspection reveals that it is not installed. This can sometimes happen when software uninstall routines leave traces of the original software. False positives are frustrating and waste valuable analyst time. |
True positive | When a vulnerability scan correctly identifies a vulnerability. For example, a true positive would be when a scan correctly identifies the presence of default credentials on network equipment. |
False negative | When a vulnerability scan incorrectly identifies that a vulnerability does not exist. For example, when a vulnerability scan identifies that a web server is using compliant cipher suites when it is not if the scanner is misconfigured or uses an outdated signature engine during evaluation. False negatives are the most concerning issue as they represent a failure of the scanning tool to report on a legitimate issue. Using multiple scanning tools can mitigate the risk of false negatives because the scan outputs of each tool can be correlated to identify vulnerabilities more confidently. |
True negative | A vulnerability scan that correctly indicates that a system or device does not have a vulnerability. |
5.6.5 Vulnerability Management Reporting Facts
Vulnerability reporting helps ensure an organization is aware of the risks associated with its IT infrastructure and can appropriately mitigate them. Effectively conveying important vulnerability management information can be a difficult task. Vulnerability reports can range from simple summaries of existing vulnerabilities to detailed reports outlining specific steps to reduce potential security risks.
This lesson covers the following topics:
Vulnerability management reporting benefits*
Vulnerability management report types*
- Understanding vulnerability report findings
Vulnerability Management Reporting Benefits
Vulnerability management reporting has many benefits, including the following:
| Benefit | Explanation |
|---|---|
| Increased awareness | A vulnerability management program helps organizations identify potential weaknesses in systems, software, and networks to help organizations reduce their risk of cyberattacks and ensure that the environment remains secure. |
| Improved response | Organizations can reduce the time it takes to respond to cybersecurity incidents by incorporating vulnerability management into their incident response plan to respond more effectively to cyber threats. For example, using incident response processes to help quickly mitigate newly identified, critical vulnerabilities. |
| Improved security posture | Vulnerability management reporting provides metrics and measures designed to track the progress and effectiveness of vulnerability management efforts. |
| Better compliance | Vulnerability management reporting capabilities are required to maintain compliance with regulations, laws, data privacy legislation, and security standards. |
Types of Vulnerability Management Reports
The following table includes three types of vulnerability management reports that you may work with.
| Type | Description |
|---|---|
| Vulnerability management dashboard | Dashboards provide a live view of critical data and are composed of graphs, charts, status indicators, and other visual representations. When properly designed, dashboards are valuable because they can convey much information in a single view and are easily accessed.  DescriptionA pie chart on the top left updated 17 hours ago shows exploitable vulnerability summary by severity. It is shaded in different color for critical, high, medium, low, and info. An area graph on the top right updated 13 hours ago shows 1-month trend of vulnerabilities. It is shaded in different colors for low, medium, high, and critical vulnerability. A table below the pie chart and the area graph lists the name and severity of the meaningful priorities. Image of a vulnerability dashboard. (Image © 123RF.com.) |
| Vulnerability summary report | A vulnerability management summary report provides a simple and concise description highlighting significant security concerns at a high level. A summary report provides a quick overview and helps provide status updates to leadership and compliance managers. |
| Detailed vulnerability report | A detailed vulnerability report is a more in-depth vulnerability management report outlining detailed security vulnerability information. This report typically includes specific, granular details on each system or application, including recommended remediation steps for each identified issue. |
Understanding Vulnerability Report Findings
Vulnerability reports are often the output of vulnerability scanning platforms designed to identify host vulnerabilities in various products, including operating systems, hypervisors, databases, desktop applications, mobile devices, web platforms, network devices, and many others. Vulnerability reports can include data collected and organized from other sources too. For example, a compliance manager may compile reports based on audit findings, third-party assessments, or physical security risks. Security teams may manually evaluate endpoints using software tools and then generate reports based on their analysis.
Reports generally use one of five common formats to list affected hosts: plain text, CSV, XML, HTML, or PDF. Plain text reports are simple text reports that many vulnerability management tools can quickly generate. Text reports can be helpful when using command line tools because they are easy to search. CSV and XML-based reports provide a standardized output that is often helpful in sharing and uploading vulnerability data to other analysts or reporting products. HTML-based reports are more visually appealing than plain text reports and can be viewed in a browser. PDF reports are visually similar to HTML reports but are easy to print and distribute.
Description
The drop downs on the right read Report and Export. The dropdown for Report reads, HTML and CSV. The tab at the top shows 496 Hosts. The table below lists the hosts and their respective vulnerabilities.
Image of a vulnerability report export.
5.6.6 Vulnerability Report Best Practices Facts
This lesson covers the following topics:
- Vulnerability report best practices
- Vulnerability report content
- Risk score and priority
- Mitigations
- Top 10 lists
- Compliance reports
- Effectiveness and relevancy
Vulnerability Report Best Practices
Several common approaches should be incorporated to maximize the effectiveness of vulnerability reporting.
- Use appropriate tools - Identify the reporting needs first and select the best tools suited to those needs.
- Consistency - Develop policies and procedures for generating vulnerability reports on a regular schedule.
- Follow best practices - Improve the effectiveness of reports by using consistent formats, standard color-coding to highlight important information, and staying focused on critical information.
- Automate - Use automation in as many processes as possible to make the entire process more consistent, reliable, efficient, and easy to maintain.
Vulnerability Report Content
The report should detail identified vulnerabilities, such as missing patches, incorrect configuration settings, and weak passwords, and include the following:
- Details regarding the type of vulnerability
- The number of instances
- The affected systems
- The risk levels
- Recommendations
Sometimes, vulnerabilities identified in an old report will reoccur in a future report even though they were previously addressed. Often recurrence is caused by an incomplete or inaccurate asset inventory, especially if vulnerability reports are manually completed. The asset inventory is a critical component of the vulnerability report as it identifies the systems to be evaluated. If the asset inventory is inaccurate, then so is the vulnerability report. When the asset inventory is corrected by adding previously missing assets, the newly added assets will reintroduce old problems.
Another cause of recurrence is misconfigured scans. The vulnerability report will be inaccurate if the scan does not evaluate all required assets during the assessment. Sometimes scans are misconfigured and run improperly due to invalid credentials, improper scan settings, invalid hostnames or IP addresses, or other similar mistakes. Once the scan is updated to include previously missing assets or correct scanner misconfigurations, old vulnerabilities will reoccur in the new report.
Risk Score and Priority
Risk scores help measure the risk posed by a particular system, application, or individual vulnerability in terms of being successfully hacked or breached. The score depends on many factors, including the nature and quantity of discovered vulnerabilities, their severity, potential impact, and the likelihood of successful exploitation.
The vulnerability risk score can be used by organizations to prioritize work and to identify vulnerabilities that require immediate attention, such as critically severe and actively exploited vulnerabilities and zero-days. Actively exploited critical and zero-day vulnerabilities typically warrant focused attention and should be tracked in a dashboard. The time between when a zero-day is published and when a patch is available is critical, as organizations are effectively defenseless during this time.
Security teams must develop methods to detect any activity related to reconnaissance or active exploitation of known zero-day vulnerabilities and have incident response plans ready if they discover evidence of an attack. Once work-arounds or patches are released, they must be implemented quickly!
The vulnerability risk score can also be used to compare the security posture of different organizations in the same sector. By comparing risk scores, security analysts can identify vulnerabilities that may be more common among specific organizations and use this information to help raise awareness.
Additionally, organizations can use risk scores to determine if their security posture is adequate compared to other organizations in the same sector. Risk scores can help leadership teams understand the effectiveness of their security strategy and make changes if needed to ensure that systems and data remain secure.
Mitigations
Detailed vulnerability reports include recommended mitigations, such as identifying a patch or describing a workaround. Some vulnerabilities require workarounds that are either permanent or temporary. A permanent workaround addresses a fundamental flaw that is unpatchable, whereas a newly discovered vulnerability may need a temporary workaround until a patch is made available. For example, after identifying critical severity CVE-2019-19781, Citrix provided a workaround while developing a permanent solution. More information regarding this vulnerability is available at https://support.citrix.com/article/CTX267027/cve201919781-vulnerability-in-citrix-application-delivery-controller-citrix-gateway-and-citrix-sdwan-wanop-appliance .
Top 10 Lists
Using top 10 style lists (or top 5, 15, 20, etc.) can help highlight potential problems or focus on important activities, trends, or environmental changes. Some examples of top 10 lists include traffic volume by device, protocols by volume, inbound traffic protocols by volume, outbound protocols, top external IP connections, email volume by user, malware alerts by user, and many other metrics. These types of metrics are very effective when used in a dashboard similar in appearance to this:
Description
Image of a Top N Dashboard.
Compliance Reports
Compliance reports provide a detailed overview of how an organization adheres to the laws, regulations, and standards of its operations. They are typically used to evaluate the effectiveness of an organization's compliance practices, assess its compliance with applicable laws, and provide important information to stakeholders and regulators. Organizations can use compliance reports to demonstrate their commitment to compliance and help ensure that legal and regulatory requirements are followed.
- Regulatory compliance reports - Prepared by qualified personnel and often include information on policies and procedures, internal audit results, employee training records, risk assessments, and other relevant data. The law, policy, contract, or regulation mandating the compliance report dictates its content.
- Internal compliance reports - Include assessments of endpoints to validate configuration per required secure configuration baselines, employee adherence to established procedures, vendor management practices, change management practices, user account management, and many other areas.
The data collected in the compliance report can help organizations identify potential areas of noncompliance, identify potential risks, and develop strategies to address them. Compliance reports often also identify areas of improvement, such as strengthening internal controls or improving communication with stakeholders.
Effectiveness and Relevancy
Vulnerability reports provide context and analysis around trends, critical vulnerabilities, and zero-day vulnerabilities. Reports can analyze trends over time to understand where vulnerabilities are most prevalent and where remediation efforts should be prioritized. Information provided in a report can also highlight critical vulnerabilities that pose the most significant risk to an organization and provide recommendations for addressing them.
Additionally, reports can include analysis and recommendations for newly discovered zero-day vulnerabilities with no available patch. By taking a risk-based approach that considers the severity of the vulnerability and its potential impact, vulnerability reports can help organizations prioritize their efforts and allocate resources more effectively.
Vulnerability reports must provide actionable recommendations for remediation and mitigation, including specific steps organizations can take to address vulnerabilities, reduce risks, and improve the overall security posture.
5.6.7 Action Plans
Click one of the buttons to take you to that part of the video.
Action Plans 00:00-00:56 Vulnerability reporting is essential for evaluating and communicating to organization leadership the areas in your network most at risk.
The next step is to present your recommendations for remediation, called an action plan. Action plans provide direction and focus. They should outline the steps, resources, and timelines to achieve specific goals.
An action plan should begin with a clear statement of the desired outcome followed by a detailed description of the steps and resources needed to reach the desired result. Include measurable goals and objectives in the action plan to track progress.
Once the action plan is in place and you're tracking progress, adjust the plan as warranted to ensure goals are realistic and achievable. Sometimes tasks progress differently than the original plan. When this happens, it may indicate that the plans need to be adjusted, the time frames are unrealistic, or that additional resources are needed to stay on track.
Security Policies and Training 00:56-01:32 Now, let's look at some steps your action plan may include. Often the first place to start is with security policies and training. Writing out requirements in policies and procedures leaves little doubt for staff about expectations. Policies also give leadership teams a way to enforce these expectations effectively.
Basic policies should include strong password requirements, limited access to sensitive data, change management, user account management, Software provisioning and deprovisioning, and incident response. One of the best ways to protect against attacks is to train employees to recognize security issues and know how to respond to them.
Software Patching 01:32-02:10 Another important step is to keep track of patch releases and regularly scan the environment to identify any missing patches. Patches can be applied manually, through automatic updates, or through a centrally administered patch deployment system. Applying patches manually gives you the most control. For example, it allows you to test a patch on one endpoint before applying it to all endpoints. The advantage of automatic updates is that they're applied immediately, so there's less time for the vulnerability to be exploited and less of a chance that the update will be missed. A centrally administered patch deployment system is helpful in a network environment where software consistency throughout a large network is desirable.
Compensating Controls 02:10-02:37 Sometimes your Action Plan will need to include compensating controls. Compensating controls are typically used when an organization cannot implement a more traditional security measure due to cost, complexity, or other factors, like location.
For example, if an organization can't afford to implement a biometric authentication system, they may instead use compensating controls such as two-factor authentication. Compensating controls can also be used when a security measure isn't available, such as in the case of legacy systems.
Changing Business Requirements 02:37-03:11 Your action plan will also need to consider any changing business requirements. The security approaches and capabilities may need to change as an organization changes.
A classic example is merger and acquisition activity. When one organization acquires another, each organization may have different approaches to security.
Leadership teams will be eager to integrate systems to streamline operations and reduce operating costs. In contrast, security teams may push back on integration efforts until after security assessments and issue remediation activities are complete.
Key Performance Indicators (KPIs) 03:11-04:03 Once you've determined the steps of your action plan, it's important to identify the key performance indicators or KPIs you'll use to measure the progress toward your security goals.
Some important KPIs include number of incidents, detection times, indicators of compromise, and detected threats.
They can also include resource allocation, which can help an organization see which areas use the most resources. KPIs can be measured using either a manual or automated tracking system.
Automated tracking systems pull information from various locations like SIEM platforms, vulnerability scanners, patch management systems, network monitoring tools, and more.
You can track KPIs using spreadsheets, databases, or specialized platforms. And just as you need to validate vulnerabilities found through a vulnerability scan, you'll need to evaluate the incidents and data from your KPIs because the incidents and data pulled can be subjective.
Service Level Objectives 04:03-04:31 So far, your action plan has been focused on remediation steps and KPIs that'll allow you to measure the effectiveness of your action plan steps.
But your plan should also include service level objectives, or SLOs. These objectives provide a benchmark to measure the performance of your security team to help ensure you're meeting the organization's leadership's expectations. Be sure that the objectives are measurable and achievable. They should include details like response times, costs, and performance metrics.
Summary 04:31-04:48 Well, that's it for this lesson. In this lesson, we went over action plans. We talked about the steps to include in an action plan. Then, we looked at key performance indicators and how they can help measure the progress of your action plan steps. We finished this lesson, by reviewing service level objectives.
5.6.8 Key Performance Indicators Facts
This lesson covers the following topics:
- Key Performance Indicators (KPIs)
- KPI examples
- KPI measurements
- KPI challenges
- Service Level Objectives (SLOs)
Key Performance Indicators (KPIs)
KPIs help organizations measure progress toward goals and identify areas for improvement in operations. They can also provide insight into the effectiveness of the organization's cybersecurity programs. Organizations can better protect their systems and data by understanding how their security efforts are performing. Any stage of the cybersecurity life cycle—prevention, detection, or response—can use KPIs. KPIs are essential for organizations to understand how their cybersecurity efforts are performing, and they can also use them to determine areas where the organization needs to improve. Organizations should choose metrics that are easy to track and reflect their goals and objectives when selecting KPIs. The metrics should also be relevant to the cybersecurity program.
Organizations need accurate data to understand the effectiveness of their cybersecurity strategies. KPIs provide this data by tracking metrics, such as the number of security incidents and the time it takes to detect them. KPIs also allow organizations to compare their cybersecurity efforts against other organizations and industry averages. This comparison can help identify where cybersecurity efforts exceed expectations and areas where they need to catch up. By tracking KPIs, organizations can determine if additional cybersecurity staff or equipment resources are required or if existing resources are working sufficiently.
KPI Examples
There are several KPIs that organizations can use to measure the effectiveness of their cybersecurity efforts. The following are examples of KPIs that organizations can track:
- Incidents -This KPI indicates the number of incidents an organization experiences, such as data breaches and cyberattacks. Organizations can track this KPI over time to determine if there is an upward or downward trend in incidents.
- Detection Time - This KPI indicates the average time it takes to detect incidents. Organizations can use this metric to track how their incident response efforts are improving over time. They can also compare the detection time to industry averages to see where to improve.
- Indicators of Compromise (IoCs) - This KPI indicates the number of IoCs that organizations have in their systems and networks or have identified in others' systems. Organizations can track this KPI over time to determine if the IoCs are increasing in their environment.
- Threats - This KPI indicates the number of threats organizations know about and have identified. Organizations can track this KPI over time to determine if the number of threats increases.
- Risk Assessment - This KPI indicates the organization's risk assessment results. Organizations can compare their risk assessments with those of other organizations to see if they are on par.
- Resource Allocation - This KPI indicates the percentage of cybersecurity resources organizations allocate to different areas, such as prevention and detection. Organizations can track this KPI over time to determine if they are allocating an appropriate percentage of resources to each function.
KPI Measurements
KPIs can be measured using either a manual or automated tracking system. Manual tracking systems require employees to enter data manually. Automated tracking systems record information by pulling data from various locations like SIEM platforms, vulnerability scanners, patch management systems, network monitoring tools, and many other sources. Organizations can track KPIs using multiple methods, such as spreadsheets, databases, or specialized platforms.
KPI Challenges
As with any metric, KPIs can present challenges for cybersecurity organizations. Some of these challenges include the following:
- Incidents can be subjective - Due to the subjective nature of classifying incidents, it can be challenging to determine the actual number of incidents. Organizations can use different scales to assess each incident's severity level. The scales are generally not standardized; therefore, comparing the number of incidents among organizations can be challenging.
- False positives - The automated tracking systems may record false positives, skewing the data.
- Inaccurate cybersecurity landscape data - This can occur when organizations need more effective tools for capturing accurate data about current threats and trends.
- Irrelevant data - KPI data might not be relevant to the organization, making it difficult to determine its cybersecurity efforts' effectiveness. Organizations must select KPIs that reflect their current cybersecurity landscape.
- KPI-based decision-making is complicated - KPI data is often complex. Organizations must often use data analytics and advanced software tools to understand the data and make informed decisions.
Service Level Objectives (SLOs)
Service Level Objectives (SLOs) are essential in any customer-oriented operation. SLOs provide a benchmark by which security operations can measure their performance and help ensure they meet leadership's expectations. Service Level Objectives must be measurable, achievable, and realistic, like any goal-setting initiative. This means that security operation teams should set attainable and challenging targets to foster growth. Additionally, SLOs should be flexible and adaptable as the cybersecurity landscape and organization's capabilities change over time.
5.6.9 Action Plans Facts
This lesson covers the following topics:
- Common security vulnerabilities
- Action plans
- Common response approaches*
Common Security Vulnerabilities
In response to vulnerability reports, leadership teams should establish action plans that define clear objectives and timelines. Security vulnerabilities often manifest in a few common ways, including the following:
- Unpatched software - Applying the most recent security patches released by the software vendor can mitigate most vulnerabilities.
- Weak passwords - Passwords are often the first line of defense in protecting systems and data. When passwords are easy to guess or crack, they expose systems to unauthorized access.
- Outdated operating systems - Legacy operating systems do not receive security patches and often have many easily exploitable vulnerabilities. Replacing or upgrading operating systems can be difficult, and it is not uncommon to find legacy operating systems still in use by many organizations despite the risks they pose.
- Inadequate infrastructure protection - When firewalls, anti-malware tools, and access controls are not correctly configured or maintained, they leave networks vulnerable.
- Misconfigurations - Working under time constraints, staff frequently provision services using default settings, guessing, or using Google for help. Additionally, staff often disable secure settings to resolve problems in response to trouble tickets.
Action Plans
Action plans are a critical component in response to a vulnerability report. When a vulnerability report identifies that problems exist in the environment, the race is on to implement fixes!
Action plans provide direction and focus, enabling organizations to achieve strategic goals and objectives. Action plans help frame how to measure progress because they outline the steps, resources, and timelines required to achieve specific goals. Action plans should be tailored to each organization's unique needs and regularly updated to reflect changes in the business environment.
An action plan should begin with a clear statement of the desired outcome followed by a detailed description of the steps and resources needed to reach the desired result. Including measurable goals and objectives in the action plan ensures that leadership can track progress.
Once the action plan is in place, leadership must track progress and adjust the plan as warranted to ensure goals are realistic and achievable. Sometimes tasks progress differently than the original plan. When this happens, it may indicate that the plans need to be adjusted, the time frames are unrealistic, or that additional resources are needed to stay on track.
Leadership teams use several approaches to reduce risks, like investing in new security software, making configuration changes, updating organizational policies, and many other options.
Besides these changes, training staff to understand existing organizational policies, recognize potential security issues, and use best practices approaches in their work is very important.
Common Response Approaches
Some common approaches used by security and leadership teams in response to these risks include the following:
- Regularly testing systems - It is essential to regularly test systems to ensure they operate correctly and identify potential weaknesses. Testing should include internal and external systems maintained by providers that the organization is dependent on.
- Limiting access - Limiting who has access to systems and networks that store or process sensitive data is an effective way to protect it.
- Monitoring - This includes monitoring internal systems, such as servers, and externally accessible systems, such as web servers. Regularly scanning systems for vulnerabilities and quickly repairing issues is an effective way to guard against data breaches.
5.6.10 Action Plan Outcomes Facts
This lesson covers the following topics:
- Security policies and training
- Software patching
- Compensating controls
- Configuration management
- Changing business requirements
Security Policies and Training
An essential method to improve security is establishing robust security policies and procedures within an organization. Writing down requirements and expectations in policies and procedures leaves little doubt for staff trying to understand expectations. Additionally, leadership teams can effectively enforce expectations when they are properly documented.
Policies and procedures should include the following:
- Strong password requirements
- Limited access to sensitive data
- Change management
- Software and services provisioning or de-provisioning
- User account management
- Patch scanning
- Incident response
It is also critical to regularly evaluate the effectiveness of policies and procedures to ensure that they are working as intended.
It has been well established that one of the best ways to protect against attacks is to train employees to recognize security issues and know how to respond to them. Awareness and skills development training are essential, but training on existing organizational policies and procedures is also critical. It is also necessary to regularly test employees to ensure they have retained the information or developed the skills addressed in their training.
Software Patching
Security patches released by developers are often the first line of defense against successfully exploiting software vulnerabilities. It is essential to keep track of patch releases and regularly scan the environment to identify any missing patches. Timely application of patches ensures that software remains secure and up to date.
Patches are applied to software using many approaches, including automatic updates, manual installation, and centrally administered patch deployment systems. Automatic updates are highly effective because they ensure that patches are applied as soon as they are released. Despite this, organizations must test most patches before deployment to ensure they do not cause problems or introduce bugs. Manual installation is less effective because patches may not be promptly applied, but this approach offers the highest amount of control.
Compensating Controls
Compensating controls address security risks when traditional measures, such as software upgrades, multifactor authentication, encryption, and other similar controls, are not viable. This can happen when systems do not support modern security features or when these changes break business-critical operations. Many organizations use complicated and highly integrated systems that are extremely difficult to change, upgrade, and maintain. Compensating controls provide additional layers of security to protect against malicious or accidental breaches.
Compensating controls are typically used when an organization cannot implement a more traditional security measure due to cost, complexity, or other factors. For example, if an organization cannot afford to implement a biometric authentication system, it may use compensating controls such as two-factor authentication instead . Compensating controls can also be used when a security measure is not available, such as in the case of legacy systems.
Compensating controls provide protection when circumstances prevent the use of primary security measures. Compensating controls act as an alternative method of protection. That is not to say that compensating controls cannot, or should not, be used together with primary controls. Compensating controls offer layered protections and keep systems and software safe by providing redundancy. If one control fails, there is another still providing protection.
Compensating controls should be tailored to the organization's specific security needs and be regularly reviewed and updated to ensure they remain effective. Because they address specific risks, compensating controls should be evaluated individually and implemented with the same level of care and diligence as any other security measure.
Configuration Management
Configuration management tracks and controls changes in a system's configuration. It is a critical component of security governance and often works as the cornerstone of systems management. Configuration management assists with planning, organizing, and controlling the development and maintenance of systems and services.
Configuration management helps security teams ensure that systems remain consistent, compliant, and secure. Organizations can ensure their systems are up-to-date, reliable, and secure by implementing proper configuration management processes and tools. Configuration management also helps organizations maintain compliance with industry standards.
Description
The page shows 4 tables titled, secure configuration compliance checks, detected software, top subnets with compliance concerns, and compliance concerns. All the information is last updated 3 hours ago.
Image of a configuration manager.
Changing Business Requirements
Organizations are constantly growing, changing, and adapting, so leaders must be mindful of how this evolution impacts the cybersecurity program. Generally, as the organization changes, so must its security approaches and capabilities. Often, security teams and organizational leaders work independently from each other. This is a risk because the leadership teams may make decisions about operations that severely impact the environment's security. Likewise, when security teams work independently of operations teams, they may not fully comprehend the impacts their security-focused decisions have on staff productivity.
A classic example is merger and acquisition activity. When one organization acquires another, each organization may have different approaches to security. Leadership teams will be eager to integrate systems to streamline operations and reduce operating costs.
A classic example of this type of problem can be seen in the Marriot acquisition of Starwood. https://www.csoonline.com/article/3441220/marriott-data-breach-faq-how-did-it-happen-and-what-was-the-impact.html
In contrast, security teams may push back on integration efforts until after security assessments and issues remediation activities are complete. Another example is changing business requirements stemming from new partnerships. A security team that has successfully managed security operations for many years may discover that they are subject to many new rules when the organization starts working with a defense contractor with stringent supply chain controls.
5.6.11 Inhibitors to Vulnerability Remediation
Click one of the buttons to take you to that part of the video.
Remediation Inhibitors 00:00-00:15 On the surface, remediating vulnerabilities seems straightforward; find problems, identify the fixes, implement the fixes, and then move on.
Legacy Systems 00:15-01:15 The reality is much more complicated. Organizations and their employees carry a heavy burden of conflicting priorities, many of which impede their ability to implement important security changes. In this lesson, we'll look at some inhibitors to vulnerability remediation. First, let's look at a few potential issues with your systems.
For example, you may be working with a legacy system. Legacy systems are outdated systems or software applications that have been in use for an extended period. Legacy systems are built on obsolete technologies and struggle to keep up with changing technological trends.
Many organizations still rely on legacy systems because of the replacement cost or the complexity of transitioning to a new system.
Legacy systems are rarely updated and often contain code that's difficult to maintain, making them vulnerable to security threats. Modernizing legacy systems is often daunting and may require significant time, money, and resources to migrate data and make changes to the code.
Proprietary Systems 01:15-01:45 Next, you may encounter proprietary systems. These systems are designed to serve a specific purpose and are tailored to an organization's needs. Proprietary systems can range from simple software programs to complex networks and databases. They're often developed in-house, which depends on the skill and productivity of the organization's own developers.
Poor architectural design choices early in the development process can create huge problems when security changes are needed. Security vulnerabilities discovered in the system often require complicated security remediation.
Degraded Functionality 01:45-02:16 Another vulnerability that can be harder to identify is degraded functionality. This is an issue that often arises in software and hardware.
It happens when system performance decreases due to various factors, like environmental changes, age, or lack of maintenance. Sometimes the security patch itself is flawed and creates even more issues than the one it was intended to fix. A degradation of functionality caused by applying security patches can frustrate employees and increase remediation costs.
Business Process Interruption 02:16-02:52 Vulnerabilities in legacy and proprietary systems can cause degraded functionality and can also cause business process interruption. A business process interruption is a disruption to an organization's normal operations.
Business process interruption can also be caused by events like natural disasters, power outages, technical glitches, human error, breaches, or cyberattacks. Each of these causes can have inhibitors to remediation and are unique to the situation.
For example, a natural disaster can present a variety of causes for interruption that can be challenging to remediate.
Memorandum of Understanding (MoU) 02:52-03:30 Remediation efforts can also be inhibited by agreements, policies, rules, and business practices.
For example, your organization may have a memorandum of understanding which is an agreement between two or more parties that outlines the expectations and obligations of each party involved.
This could be during a merger or acquisition while a business is still running, but not all the details have been created in a legally binding document yet.
While these MoUs can be helpful to clarify how some processes will work, they may also create challenges for security teams who may not be given the freedom or resources they need to keep the network secure.
Service-Level Agreements (SLA) 03:30-03:54 Another agreement that can have an impact on how security teams do their job is a service-level agreement, or SLA.
A service-level agreement is a legally binding contract between two or more parties that defines the level of service to be provided by one party to another.
It outlines the services provided, the terms of service, the responsibilities of each party, and the penalties for failing to meet them.
Organizational Governance 03:54-04:51 The last area that we'll mention here that may inhibit how security teams do their jobs is organizational governance. Organizational governance is the system of rules, practices, and processes an organization uses to control its operations.
It defines the roles and responsibilities of the board of directors, management, and other stakeholders in achieving the organization's objectives.
The dynamics and pressures of organizational governance often overshadow security initiatives. When new security tools and software investments have high costs or security teams want to slow down operations to perform security evaluations and other similar activities, the board of directors may push back and override these plans.
Security initiatives can often disrupt existing strategic plans, cause conflicts in the governance board, and upset stakeholders.
While the process of remediating vulnerabilities can be complicated, understanding what some of the inhibitors are can help you be prepared for the challenges they may present.
Summary 04:51-05:21 That's it for this lesson. In this lesson, we looked at several areas that may be problematic in your security efforts. First, we looked at legacy systems and proprietary systems. Then we talked about degraded functionality and business process interruption. Next, we reviewed two documents that can impact your efforts: a memorandum of understanding and a service-level agreement. We finished this lesson by discussing how organizational governance may include rules, practices, and agendas of competing groups that can impact a security team's ability to act.
5.6.12 Inhibitors to Vulnerability Remediation
On the surface, remediating vulnerabilities seems straightforward; find problems, identify the fixes, implement the fixes, and then move on. The reality is much more complicated. Organizations and their employees carry a heavy burden of conflicting priorities, many of which impede their ability to implement important security changes.
This lesson covers the following topics:
- Memorandum of understanding (MoU)
- Service-level agreements (SLA)
- Organizational governance
- Business process interruption
- Degraded functionality
- Legacy systems
- Proprietary systems
Memorandum of Understanding (MoU)
A memorandum of understanding (MoU) is a legal document that outlines the terms and conditions of an agreement between two or more parties. It is an agreement that is not legally binding but serves as a document of understanding and good faith among the parties involved. A memorandum of understanding usually outlines the agreement's objectives and each party's duties and responsibilities.
The main purpose of a memorandum of understanding is to ensure that all parties involved in the agreement understand each other's expectations and obligations. It serves as a clear guide to the parties involved and helps ensure everyone is on the same page. It also serves as a reference point for the parties to use in a dispute.
Once the memorandum of understanding is signed, it is considered a binding document. Both parties must understand the terms and conditions of the agreement and make sure to adhere to its provisions. The memorandum of understanding should also be reviewed and updated regularly to ensure that everyone still agrees with the terms of the agreement.
An MoU might outline uptime, data access, response times, and other performance or access characteristics that conflict with the changes or maintenance tasks identified in response to mitigating vulnerabilities.
Service-Level Agreements (SLA)
A service-level agreement (SLA) is a legally binding contract between two or more parties that defines the level of service to be provided by one party to another. It often governs the relationship with a third-party service provider. It outlines the services provided, the terms of service, the responsibilities of each party, and the penalties for failing to meet them. It is essential to have a service-level agreement in place when providing any service, as it serves to protect both parties and helps to manage expectations.
Service-level agreements should include details such as:
- Quality of service.
- Response time.
- Cost.
- Time frame for the service delivery.
- Contact information for both parties.
- Payment terms.
- Performance metrics for measurement of quality of service.
The stringent nature of an SLA and the potential for significant financial impacts for failing to meet its requirements often overshadow security needs. If mitigations even hint at impacting the conditions outlined in an SLA, leadership teams will often block their implementation.
Organizational Governance
Organizational governance is the system of rules, practices, and processes an organization uses to control its operations and the strategic direction it pursues. It defines the roles and responsibilities of the board of directors, management, and other stakeholders in achieving the organization's objectives. Organizational governance aims to ensure that the organization is well-managed, accountable, and compliant with applicable regulatory requirements. It also helps to ensure that the organization is guided by a set of values and principles consistent with its mission and objectives.
Organizational governance begins with the board of directors. The board of directors is responsible for setting the organization's overall direction, setting policies and procedures, and overseeing the organization's management. The board of directors is also responsible for setting the prevailing standards for organizational governance, such as selecting leaders, creating ethics policies, establishing a code of conduct, and monitoring operational performance.
In addition to the board of directors, other stakeholders, including shareholders, regulators, and the public, are involved in organizational governance. Shareholders are responsible for ensuring that the organization is accountable to them and that their investments are responsibly managed. Regulators ensure that the organization complies with applicable laws and regulations. The public is responsible for holding the organization accountable for its actions and ensuring that it follows its mission and objectives.
The dynamics and pressures of organizational governance often overshadow security initiatives. When new investments in security tools and software have high costs, or security teams want to slow down operations to perform security evaluations and other similar activities, the board of directors may push back and override these plans. Security initiatives can often disrupt existing strategic plans, cause conflicts in the governance board, and upset stakeholders.
Business Process Interruption
Business process interruptions can significantly impact a business's bottom line. Financial losses can occur due to lost revenue, increased costs, and missed opportunities. Furthermore, interruptions can negatively impact customer service, employee morale, and brand reputation. The costs of a business process interruption can be far-reaching, with the potential to cause long-term damage to a company's reputation and profitability.
Southwest Airlines experienced a significant outage during holiday travel at the end of 2022 with estimated costs of $825 million: https://www.bizjournals.com/houston/news/2023/01/04/southwest-airlines-flight-cancellation-debacle.html
Degraded Functionality
Degraded functionality is an issue that often arises in software and hardware. It occurs when system performance decreases due to various factors, such as environmental changes, age, lack of maintenance, and sometimes from applying security patches. It can also result from a design flaw, lack of resources, or inadequate testing.
Degraded functionality causes employee frustration, decreased efficiency, reduced performance, and increased costs due to repairs and replacements. Furthermore, it can cause safety issues due to the system's inability to perform as required.
Patches released to address the Spectre vulnerability caused significant issues:
https://www.cnet.com/tech/computing/intel-stops-some-chip-patches-unexpected-reboot-meltdown-spectre/
https://www.zdnet.com/article/meltdown-spectre-more-businesses-warned-off-patching-over-stability-issues/
Legacy Systems
Legacy systems are rarely updated and often contain code that is difficult to maintain. As such, they are often vulnerable to security threats. Moreover, these systems often lack the ability to integrate with newer platforms, which is a significant problem for organizations that need to grow and adapt their capabilities to changing operating requirements.
Modernizing legacy systems is frequently daunting, and upgrades require significant time, money, and resources to migrate data and make changes to the code.
Proprietary Systems
Proprietary systems are specialized systems designed to serve a specific purpose and are tailored to an organization's needs. Proprietary systems can range from simple software programs to complex networks and databases. A company or organization often develops proprietary systems to provide a unique solution to a specific problem or challenge. They are often developed in-house, with the organization's staff, rather than using outside vendors. This allows the organization to control the system and ensure it meets its specific needs. In-house developed software depends on the skill and productivity of its own developers.
When security vulnerabilities are identified in these systems, they often create overwhelming trouble for in-house teams. Security changes are often complicated and depend on the application's architectural structure. Poor architectural design choices made early in development can create huge problems when security changes are needed.