4.3 Vulnerability Scanning Flashcards
Vulnerability scanning
Usually minimally invasive
– Unlike a penetration test
* Port scan
– Poke around and see what’s open
* Identify systems
– And security devices
* Test from the outside and inside
– Don’t dismiss insider threats
* Gather as much information as possible
– We’ll separate wheat from chaff later
Static code analyzers
Static Application Security Testing (SAST)
– Help to identify security flaws
* Many security vulnerabilities found easily
– Buffer overflows, database injections, etc.
* Not everything can be identified through analysis
– Authentication security, insecure cryptography, etc.
– Don’t rely on automation for everything
* Still have to verify each finding
– False positives are an issue
Dynamic analysis (fuzzing)
Send random input to an application
– Fault-injecting, robustness testing, syntax testing,
negative testing
* Looking for something out of the ordinary
– Application crash, server error, exception
* 1988 class project at the University of Wisconsin
– “Operating System Utility Program Reliability”
– Professor Barton Miller
– The Fuzz Generator
Fuzzing engines and frameworks
Many different fuzzing options
– Platform specific, language specific, etc.
* Very time and processor resource heavy
– Many, many different iterations to try
– Many fuzzing engines use high-probability tests
* Carnegie Mellon Computer
– Emergency Response Team (CERT)
– CERT Basic Fuzzing Framework (BFF)
– https://professormesser.link/bff
Package monitoring
Some applications are distributed in a package
– Especially open source
– Supply chain integrity
* Confirm the package is legitimate
– Trusted source
– No added malware
– No embedded vulnerabilities
* Confirm a safe package before deployment
– Verify the contents
Threat intelligence
Research the threats
– And the threat actors
* Data is everywhere
– Hacker group profiles, tools used by the attackers,
and much more
* Make decisions based on this intelligence
– Invest in the best prevention
* Used by researchers, security operations teams,
and others
Open-source intelligence (OSINT)
Open-source
– Publicly available sources - A good place to start
* Internet - Discussion groups, social media
* Government data
– Mostly public hearings, reports, websites, etc.
* Commercial data
– Maps, financial reports, databases
Proprietary/third-party intelligence
Someone else has already compiled the threat
information - You can buy it
* Threat intelligence services
– Threat analytics
– Correlation across different data sources
* Constant threat monitoring
– Identify new threats
– Create automated prevention workflows
Information-sharing organization
Public threat intelligence
– Often classified information
* Private threat intelligence
– Private companies have extensive resources
* Need to share critical security details
– Real-time, high-quality cyber threat information sharing
* Cyber Threat Alliance (CTA)
– Members upload specifically formatted
threat intelligence
– CTA scores each submission and validates across
other submissions
– Other members can extract the validated data
Dark web intelligence
Dark web
– Overlay networks that use the Internet
– Requires specific software and configurations to access
* Hacking groups and services
– Activities
– Tools and techniques
– Credit card sales
– Accounts and passwords
* Monitor forums for activity
– Company names, executive names
Penetration testing
Pentest - Simulate an attack
* Similar to vulnerability scanning
– Except we actually try to exploit the vulnerabilities
* Often a compliance mandate
– Regular penetration testing by a 3rd-party
* National Institute of Standards and Technology
– Technical Guide to Information Security
– Testing and Assessment
– https://professormesser.link/800115 (PDF download)
Rules of engagement
An important document
– Defines purpose and scope
– Makes everyone aware of the test parameters
* Type of testing and schedule
– On-site physical breach, internal test, external test
– Normal working hours, after 6 PM only, etc.
* The rules
– IP address ranges
– Emergency contacts
– How to handle sensitive information
– In-scope and out-of-scope devices or applications
Exploiting vulnerabilities
Try to break into the system
– Be careful; this can cause a denial of service or
loss of data
– Buffer overflows can cause instability
– Gain privilege escalation
* You may need to try many different vulnerability types
– Password brute-force
– Social engineering
– Database injections
– Buffer overflows
* You’ll only be sure you’re vulnerable if you
can bypass security
– If you can get through, the attackers can get through
The process
Initial exploitation
– Get into the network
* Lateral movement
– Move from system to system
– The inside of the network is relatively unprotected
* Persistence
– Once you’re there, you need to make sure there’s a way back in
– Set up a backdoor, build user accounts, change or verify
default passwords
* The pivot
– Gain access to systems that would normally not be accessible
– Use a vulnerable system as a proxy or relay
Responsible disclosure program
It takes time to fix a vulnerability
– Software changes, testing, deployment, etc.
* Bug bounty programs
– A reward for discovering vulnerabilities
– Earn money for hacking a system
– Document the vulnerability to earn cash
* A controlled information release
– Researcher reports the vulnerability
– Manufacturer creates a fix
– The vulnerability is announced publicly
Dealing with false information
False positives
– A vulnerability is identified that doesn’t really exist
* This is different than a low-severity vulnerability
– It’s real, but it may not be your highest priority
* False negatives
– A vulnerability exists, but you didn’t detect it
* Update to the latest signatures
– If you don’t know about it, you can’t see it
* Work with the vulnerability detection manufacturer
– They may need to update their signatures for your
environment
Prioritizing vulnerabilities
Not every vulnerability shares the same priority
– Some may not be significant
– Others may be critical
* This may be difficult to determine
– The research has probably already been done
* Refer to public disclosures and vulnerability databases
– The industry is well versed
– Online discussion groups, public disclosure mailing lists
CVSS
National Vulnerability Database: http://nvd.nist.gov/
– Synchronized with the CVE list
– Enhanced search functionality
* Common Vulnerability Scoring System (CVSS)
– Quantitative scoring of a vulnerability - 0 to 10
– The scoring standards change over time
– Different scoring for CVSS 2.0 vs CVSS 3.x
* Industry collaboration
– Enhanced feed sharing and automation
CVE
The vulnerabilities can be cross-referenced online
– Almost all scanners give you a place to go
* National Vulnerability Database: http://nvd.nist.gov/
– Common Vulnerabilities and Exposures (CVE):
– https://cve.mitre.org/cve/
* Microsoft Security Bulletins:
– https://www.microsoft.com/technet/security/
current.aspx
* Some vulnerabilities cannot be definitively identified
– You’ll have to check manually to see if a system is
vulnerable
– The scanner gives you a heads-up
Vulnerability classification
The scanner looks for everything
– Well, not everything - The signatures are the key
* Application scans
– Desktop, mobile apps
* Web application scans
– Software on a web server
* Network scans
– Misconfigured firewalls, open ports, vulnerable
devices
Exposure factor
Loss of value or business activity if the
vulnerability is exploited
– Usually expressed as a percentage
* A small DDoS may limit access to a service
– 50% exposure factor
* A buffer overflow may completely disable a service
– 100% exposure factor
* A consideration when prioritizing
– Worst possible outcome probably gets priority
Environmental variables
What type of environment is associated with this
vulnerability?
– Internal server, public cloud, test lab
* Prioritization and patching frequency
– A device in an isolated test lab
– A database server in the public cloud
– Which environment gets priority?
* Every environment is different
– Number and type of users (internal, external)
– Revenue generating application
– Potential for exploit
Industry/organizational impact
Some exploits have significant consequences
– The type of organization is an important consideration
* Tallahassee Memorial HealthCare - February 2023
– Ransomware - closed for two weeks
– Diverted emergency cases, surgeries canceled
* Power utilities - Salt Lake City, LA County CA - March 2019
– DDoS attacks from an unpatched known vulnerability
Risk tolerance
The amount of risk acceptable to an organization
– It’s impractical to remove all risk
* The timing of security patches
– Patching immediately doesn’t allow for proper
testing
* Testing takes time
– While you’re testing, you’re also vulnerable
* There’s a middle ground
– May change based on the severity
Patching
The most common mitigation technique
– We know the vulnerability exists
– We have a patch file to install
* Scheduled vulnerability/patch notices
– Monthly, quarterly
* Unscheduled patches
– Zero day, often urgent
* This is an ongoing process
– The patches keep coming
– An easy way to prevent most exploits
Insurance
Cybersecurity insurance coverage
– Lost revenue
– Data recovery costs
– Money lost to phishing
– Privacy lawsuit costs
* Doesn’t cover everything
– Intentional acts, funds transfers, etc.
* Ransomware has increased popularity of
cybersecurity liability insurance
– Applies to every organization
Segmentation
Limit the scope of an exploit
– Separate devices into their own networks/VLANs
* A breach would have limited scope
– It’s not as bad as it could be
* Can’t patch?
– Disconnect from the world
– Air gaps may be required
* Use internal NGFWs
– Block unwanted/unnecessary traffic between VLANs
– Identify malicious traffic on the inside
Physical segmentation
Separate devices - Multiple units, separate infrastructure
Logical segmentation with VLANs
Virtual Local Area Networks (VLANs)
– Separated logically instead of physically
– Cannot communicate between VLANs without a
Layer 3 device / router
Compensating controls
Optimal security methods may not be available
– Can’t deploy a patch right now
– No internal firewalls
* Compensate in other ways
– Disable the problematic service
– Revoke access to the application
– Limit external access
– Modify internal security controls and software firewalls
* Provide coverage until a patch is deployed
– Or similar optimal security response
Exceptions and exemptions
Removing the vulnerability is optimal
– But not everything can be patched
* A balancing act
– Provide the service, but also protect the data and
systems
* Not all vulnerabilities share the same severity
– May require local login, physical access, or other criteria
* An exception may be an option
– Usually a formal process to approve
Validation of remediation
The vulnerability is now patched
– Does the patch really stop the exploit?
– Did you patch all vulnerable systems?
* Rescanning
– Perform an extensive vulnerability scan
Audit
– Check remediated systems to ensure the patch
was successfully deployed
* Verification
– Manually confirm the security of the system
Vulnerability Remediation Reporting
Ongoing checks are required
– New vulnerabilities are continuously discovered
* Difficult (or impossible) to manage without
automation
– Manual checks would be time consuming
* Continuous reporting
– Number of identified vulnerabilities
– Systems patched vs. unpatched
– New threat notifications
– Errors, exceptions, and exemptions
