4.3 Vulnerability scanning

Question 1

Vulnerability scanning

Answer 1

• 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

Question 2

Static code analyzers

Answer 2

• 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.

Question 3

Dynamic analysis (fuzzing)

Answer 3

• 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

Question 4

Fuzzing engines and frameworks

Answer 4

• 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/b

Question 5

Package monitoring

Answer 5

• 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