Security Vulnerabilities

1. Introduction to Security Vulnerabilities

A security vulnerability is a weakness in a system,
application, device, configuration, process or implementation that could be
used to violate a security requirement.

A vulnerability may affect confidentiality, integrity, availability,
authentication, authorization or another security property.

Vulnerabilities exist in many different environments, including websites,
mobile applications, operating systems, cloud infrastructure, networks,
databases and organizational processes.

2. Vulnerability vs Threat

A vulnerability is a weakness.
A threat is a potential source of harm that may take
advantage of a weakness.

For example, an outdated application may contain a vulnerability while an
attacker capable of exploiting that weakness represents a threat.

3. Vulnerability vs Risk

Risk considers the possibility and potential impact of an
undesired event.

A vulnerability may exist without creating the same level of risk in every
environment.

For example, a vulnerable service that is isolated from untrusted networks may
have a different exposure level from the same service directly exposed to the
Internet.

4. Vulnerability vs Exploit

An exploit is a method, technique or code used to take
advantage of a vulnerability.

A vulnerability can exist even when no publicly known exploit is available.
Similarly, the existence of an exploit does not automatically mean that a
particular organization has been compromised.

5. Common Sources of Vulnerabilities

• Programming errors
• Outdated software
• Weak authentication
• Incorrect authorization
• Insecure configurations
• Exposed services
• Unsafe default settings
• Improper input validation
• Insecure dependencies
• Weak cryptographic implementation
• Insufficient logging
• Human and process failures

6. Software Vulnerabilities

Software can contain implementation weaknesses that create security risks.
These weaknesses may be discovered by developers, security researchers,
vendors, customers or other parties.

Software security therefore requires continuous maintenance rather than a
single security review performed only when an application is released.

7. Outdated Software

Software that is no longer receiving security updates can expose organizations
to known vulnerabilities.

Patch management helps organizations identify affected software, evaluate
updates and deploy approved fixes.

8. Patch Management

A basic patch-management process can include:

1. Identify systems and software.
2. Determine currently installed versions.
3. Monitor vendor security advisories.
4. Identify relevant vulnerabilities.
5. Evaluate business impact.
6. Test updates where appropriate.
7. Deploy approved patches.
8. Verify successful installation.
9. Document the result.

9. Configuration Vulnerabilities

Not every vulnerability is caused by defective software.
Incorrect configuration can also create security weaknesses.

Examples include:

• Unnecessary services enabled
• Overly permissive firewall rules
• Default passwords
• Publicly exposed administrative interfaces
• Excessive cloud permissions
• Unnecessary open ports
• Insecure storage permissions

10. Authentication Vulnerabilities

Authentication vulnerabilities can allow unauthorized users to gain access to
accounts or services.

Examples include:

• Weak passwords
• Password reuse
• Missing multi-factor authentication
• Insecure password-reset mechanisms
• Weak session management

11. Authorization Vulnerabilities

Authentication answers:
Who are you?

Authorization answers:
What are you allowed to do?

An application may correctly identify a user but still contain an
authorization vulnerability if it allows that user to access resources beyond
their permissions.

12. Input Validation

Applications often receive input from users, APIs, files or external systems.
Input should be validated according to the expected format and business rules.

Improper input handling can contribute to several classes of application
security vulnerabilities.

13. Injection Vulnerabilities

Injection vulnerabilities can occur when untrusted input is interpreted as
part of a command, query or instruction.

Common categories discussed in application security include:

• SQL injection
• Command injection
• LDAP injection
• Template injection

Secure applications separate data from executable instructions and validate
input according to the application’s requirements.

14. Cross-Site Scripting

Cross-Site Scripting (XSS) occurs when untrusted content is incorrectly
included in a web page and interpreted as executable browser-side content.

Defensive techniques include:

• Context-aware output encoding
• Input validation
• Content Security Policy
• Safe templating practices
• Secure framework defaults

15. Broken Access Control

Broken access control occurs when an application fails to properly enforce
authorization requirements.

Security testing should verify that users can access only resources and
actions appropriate to their roles.

16. Insecure Dependencies

Modern applications often depend on third-party libraries and frameworks.
Those dependencies can introduce security vulnerabilities.

Organizations should maintain an inventory of dependencies and monitor them
for relevant security advisories.

17. Software Supply Chain Security

Software supply-chain security considers the security of components,
dependencies, build processes, development environments and distribution
mechanisms.

Important controls can include:

• Dependency management
• Code review
• Build security
• Access control
• Artifact integrity
• Dependency scanning
• Secure development practices

18. CVE

CVE stands for Common Vulnerabilities and Exposures.
CVE identifiers provide standardized references for publicly disclosed
security vulnerabilities.

A CVE identifier helps security teams communicate about a specific
vulnerability consistently.

19. CVSS

CVSS, or Common Vulnerability Scoring System, is a framework
for describing the severity characteristics of vulnerabilities.

A CVSS score is useful for vulnerability-management processes, but an
organization should not rely on a score alone when deciding remediation
priority.

Business context, exposure, affected assets and compensating controls also
matter.

20. Vulnerability Severity vs Organizational Priority

A vulnerability with a high technical severity may not always be the first
issue an organization addresses if it affects an isolated system with strong
compensating controls.

Conversely, a vulnerability with a lower technical score may deserve urgent
attention if it affects a critical Internet-facing service.

Effective vulnerability management combines technical information with
organizational context.

21. Vulnerability Scanning

Vulnerability scanners are tools that inspect authorized systems for known
weaknesses and configuration problems.

Scanning may identify:

• Outdated software
• Known vulnerabilities
• Weak configurations
• Exposed services
• Missing security updates
• Certificate problems

22. Authorized Scanning

Vulnerability scanning should be performed only against systems for which the
organization has appropriate authorization.

Unauthorized scanning can violate organizational policies, service agreements
or applicable laws.

Students should practice scanning only in dedicated laboratories, test
networks or systems where explicit permission has been provided.

23. Authenticated and Unauthenticated Scanning

An unauthenticated scan evaluates what can be observed without authenticated
access.

An authenticated scan can use authorized credentials to inspect deeper system
configuration and installed software information.

Authenticated scanning can provide additional visibility, but credentials
must be protected carefully.

24. False Positives

A false positive occurs when a security tool reports a
potential vulnerability that is not actually present under the relevant
conditions.

Security teams should validate important findings before making major
remediation decisions.

25. False Negatives

A false negative occurs when a tool fails to identify a
condition that actually exists.

No single security tool can identify every possible vulnerability.

Organizations therefore combine automated tools with secure development,
manual review, configuration management and other security practices.

26. Vulnerability Assessment Process

A structured process can include:

1. Asset discovery
2. Asset classification
3. Vulnerability discovery
4. Validation
5. Risk assessment
6. Prioritization
7. Remediation
8. Verification
9. Documentation

27. Asset Inventory

Organizations cannot effectively manage vulnerabilities in assets they do not
know exist.

An asset inventory may include:

• Servers
• Workstations
• Laptops
• Mobile devices
• Network devices
• Cloud resources
• Applications
• Databases
• Websites

28. Asset Criticality

Not every system has the same business importance.

An organization may classify systems as critical, high, medium or low
importance according to business requirements.

Critical assets often require faster remediation and stronger monitoring.

29. Remediation

Remediation means taking action to remove or reduce the
identified vulnerability.

Examples include:

• Installing a security update
• Changing an insecure configuration
• Removing an unnecessary service
• Restricting access
• Replacing vulnerable software
• Applying a secure configuration

30. Mitigation

Sometimes an immediate permanent fix is not possible.

A mitigation is a temporary or alternative control that
reduces the risk while a permanent remediation is planned.

Examples can include network segmentation, access restrictions or disabling
an affected feature where appropriate.

31. Compensating Controls

A compensating control is an alternative security measure that reduces risk
when the preferred control cannot currently be implemented.

Compensating controls should be documented and reviewed rather than treated
as permanent excuses for unresolved vulnerabilities.

32. Vulnerability Verification

After remediation, the security team should verify that the vulnerability has
actually been addressed.

Verification may include:

• Repeating an authorized scan
• Checking the installed software version
• Reviewing configuration
• Testing the relevant security control
• Reviewing system logs

33. Vulnerability Management Lifecycle

Vulnerability management is an ongoing process rather than a one-time scan.

New vulnerabilities are continuously discovered while organizations deploy
new systems and applications.

A mature program repeatedly discovers, assesses, prioritizes, remediates and
verifies security weaknesses.

34. Secure Development Lifecycle

Security should be considered throughout software development.

Important activities include:

• Security requirements
• Threat modeling
• Secure architecture
• Code review
• Dependency management
• Security testing
• Secure deployment
• Continuous monitoring

35. Configuration Management

Configuration management helps organizations maintain systems according to
approved security standards.

Security teams can compare actual configurations against approved baselines
and investigate deviations.

36. Web Application Vulnerabilities

Web applications can contain vulnerabilities involving authentication,
authorization, input handling, sessions, data protection and business logic.

Developers should use secure coding practices and security testing throughout
the development lifecycle.

37. API Security Vulnerabilities

APIs can expose sensitive operations and data.

Common security concerns include:

• Broken authorization
• Weak authentication
• Excessive data exposure
• Improper input validation
• Rate-limit weaknesses
• Insecure configuration

38. Cloud Vulnerabilities

Cloud environments can introduce configuration and identity-related risks.

Examples include:

• Overly permissive identity policies
• Publicly exposed storage
• Unprotected management interfaces
• Weak secrets management
• Improper network security configuration

39. Container and Virtualization Security

Containers and virtual machines also require security management.

Security teams should consider image vulnerabilities, access controls,
secrets, network configuration and host security.

40. Vulnerability Disclosure

Security researchers may discover vulnerabilities in software and report them
to affected vendors or organizations.

Responsible vulnerability disclosure aims to provide enough information for a
security issue to be understood and addressed without unnecessarily increasing
risk to users.

41. Security Advisories

Security advisories provide information about vulnerabilities, affected
versions, severity and available fixes or mitigations.

Organizations should monitor relevant vendors and trusted security sources
for advisories affecting their technology environment.

42. Vulnerability Prioritization

A practical prioritization process can consider:

• Technical severity
• Internet exposure
• Asset criticality
• Known exploitation activity
• Availability of a fix
• Existing compensating controls
• Potential business impact

43. Synthetic Vulnerability Assessment Example

The following PHP example demonstrates how a training system could classify
fictional vulnerability findings. It does not scan or attack any system.

<?php

$findings = array(
	array(
		'name'       => 'Outdated Web Server',
		'severity'   => 'high',
		'exposed'    => true,
		'critical'   => true,
	),
	array(
		'name'       => 'Unused Service',
		'severity'   => 'medium',
		'exposed'    => false,
		'critical'   => false,
	),
	array(
		'name'       => 'Missing Security Header',
		'severity'   => 'low',
		'exposed'    => true,
		'critical'   => false,
	),
);

foreach ( $findings as $finding ) {

	$priority = 'Normal';

	if (
		'high' === $finding['severity']
		&& $finding['exposed']
		&& $finding['critical']
	) {
		$priority = 'Urgent';
	} elseif (
		'high' === $finding['severity']
		|| $finding['exposed']
	) {
		$priority = 'High';
	}

	echo esc_html( $finding['name'] );
	echo ' — Priority: ';
	echo esc_html( $priority );
	echo '<br>';
}

44. Why Context Matters

A vulnerability-management platform may report hundreds of findings.
Security professionals must determine which findings represent the greatest
organizational risk.

Context prevents teams from treating every alert as equally urgent.

45. Security Vulnerability Scenario

Imagine a fictional organization discovers an outdated web server on an
Internet-facing production system.

The security team should determine:

1. Which version is installed?
2. Is the vulnerability applicable to that version?
3. Is the system exposed to untrusted networks?
4. Is the server business-critical?
5. Is a security update available?
6. Are there temporary mitigations?
7. What is the remediation plan?
8. How will the fix be verified?

46. Vulnerability Reporting

A useful vulnerability report should provide enough information for the
responsible team to understand and address the finding.

Typical information includes:

• Affected asset
• Finding title
• Description
• Evidence
• Severity
• Business impact
• Recommended remediation
• Mitigation if available
• Verification status

47. Common Vulnerability Management Mistakes

• Scanning without maintaining an asset inventory.
• Ignoring false positives.
• Prioritizing only by a numerical score.
• Failing to verify remediation.
• Ignoring cloud configuration.
• Leaving unsupported software in production.
• Failing to document exceptions.
• Performing unauthorized security testing.

48. Authorized Classroom Exercise

Create a fictional vulnerability dataset containing at least ten synthetic
findings.

For each finding, record:

• Asset name
• Vulnerability
• Severity
• Internet exposure
• Asset criticality
• Available remediation
• Temporary mitigation
• Verification status

Students should prioritize the findings and explain the factors that
influenced their decisions.

49. Defensive Vulnerability Management Checklist

• Maintain an accurate asset inventory.
• Track software versions.
• Monitor trusted security advisories.
• Perform authorized vulnerability assessments.
• Validate important findings.
• Prioritize using technical and business context.
• Apply security updates.
• Use compensating controls when necessary.
• Verify remediation.
• Document unresolved risks.
• Review the environment continuously.

50. Review Questions

1. What is a security vulnerability?
2. What is the difference between a vulnerability and a threat?
3. What is the difference between vulnerability and risk?
4. What is an exploit?
5. What does CVE mean?
6. What is CVSS used for?
7. Why should CVSS not be the only prioritization factor?
8. What is vulnerability scanning?
9. Why must vulnerability scanning be authorized?
10. What is a false positive?
11. What is a false negative?
12. What is remediation?
13. What is mitigation?
14. What is a compensating control?
15. Why is verification important after remediation?
16. Why is asset inventory important?
17. How can insecure configuration create vulnerabilities?
18. Why should software dependencies be monitored?
19. What is the role of secure software development?
20. What factors can influence vulnerability priority?

51. Key Takeaways

• A vulnerability is a weakness that may affect security.
• A threat is a potential source of harm.
• Risk considers likelihood and potential impact.
• An exploit is a method of taking advantage of a vulnerability.
• Vulnerabilities can exist in software, hardware, configurations and processes.
• Patch management helps reduce exposure to known software weaknesses.
• CVE provides standardized vulnerability identifiers.
• CVSS helps describe technical vulnerability severity.
• Technical severity is not the same as organizational priority.
• Vulnerability scanning should be authorized.
• Security findings should be validated where appropriate.
• Remediation should be verified after changes are made.
• Asset inventory is a fundamental part of vulnerability management.
• Security must be considered throughout the software development lifecycle.
• Vulnerability management is continuous.

52. Conclusion

Security vulnerabilities are an unavoidable part of complex technology
environments. Effective cybersecurity therefore requires continuous
identification, assessment, prioritization, remediation and verification of
security weaknesses.

Security professionals should combine technical findings with business
context, asset criticality, exposure and available controls when managing
vulnerabilities.

This lesson completes
Module 3 — Cyber Threats and Attacks.

The next module in the Dwallnet Cyber Security course is:
Module 4 — Linux Fundamentals.