Notes - MCS
Robust Software
Notes - MCS
Robust Software
  • Robust Software
  • Secure Software Design Principles
    • Motivation
    • Secure and Resilient/Robust Software
    • Best Practices for Resilient Applications
    • Designing Applications for Security and Resilience
    • Architecture for the Web/Cloud
  • Software Security Lifecycle
    • Motivation
    • Secure Development Lifecycle
    • Software Security Touchpoints
    • Software Assurance Forum for Excellence in Code (SAFECode)
    • Secure SW Lifecycle Processes Summary
    • Adaptations of the Secure Software Lifecycle
    • Assessing the Secure Software Lifecycle
    • Recommendations
  • Software Quality Attributes
    • Motivation
    • Software Quality Assurance
    • Software Quality Standards
    • Software Quality Attributes
    • Extra Software Quality Assurance Properties
  • Security Requirements
    • Motivation
    • Security Requirements
    • Threats
    • Defenses
    • Confidentiality
    • Integrity
    • Availability
    • What about other goals/properties?
    • Security Requirements Engineering
    • Types of Security Requirements
    • Security Policy
    • Precision
    • Completeness and Consistency
    • Examples of Non-Functional Requirements
    • Goals and Requirements
    • Measures
    • Requirements Interaction
    • Natural Language Requirements
    • Best Practices
  • Common Software Attacks
    • Objectives
    • 10 Major Cyber-Attacks of 21st Century
    • Software Security Basics
    • Defenses Methods
    • SANS SWAT Checklist
  • Safe Programming
    • Secure Coding Practices
    • Top 10 Secure Coding Practices (CERT/SEI)
    • 7 Pernitious Kingdoms
  • Robustness, PenTest, Fuzzy and Static Code Analysis
    • Security/Robustness Testing
    • Robustness Tests Checklist Example
    • Penetration Testing
    • Penetration Testing Roadmap
    • Tools
    • Fuzz Testing
    • Static Code Analysis
    • Side Channels
  • Safety (and Security)
    • Safety
    • A safety Lifecycle Example
    • Risk Management Process
    • System Definition
    • Hazard Identification and Classification
    • Desk-based Hazard Identification
    • Workshop-based Hazard Identification
    • HAZOP
    • Hazard Identification and Classification
      • Broadly acceptable risks
    • Risk Evaluation and Risk Acceptance
    • Use of codes of practice
    • Use of reference system
    • Explicit risk estimation
    • Qualitative risk estimation
    • Quantitative risk estimation
    • Safety measures
    • Safety requirements
    • Hazard Management
    • Hazard life cycle
    • Independent Assessment
    • Safety Plan
    • Safety Case
    • FMEA Example
    • DevSecOps
Powered by GitBook
On this page
  • Possible Scope
  • Some examples of a Penetration Testing Plan.
  • Network Vulnerability Testing
  • Web Vulnerability Testing
  • Wireless War Driving / Walking
  • Social Engineering Testing
  1. Robustness, PenTest, Fuzzy and Static Code Analysis

Penetration Testing

Penetration testing is a method of evaluating the security of a system or network by simulating an attack from a malicious source.

What is the difference between a Pen Tester and a Hacker?

  • Pen Tester’s have prior approval from Senior Management.

  • Hackers have prior approval from themselves.

  • Pen Tester’s social engineering attacks are there to raise awareness.

  • Hackers' social engineering attacks are there to trick the DMV into divulging sensitive information about the whereabouts of their estranged ex-spouse.

  • Pen Tester’s war driving = geeks driving cars with really long antennas, and license plate reading “r00t3d” while dying their hair green looking to discover the hidden, unapproved networks your users thought it would be OK to install for you.

  • Hackers wireless war driving doesn’t happen so often because 14-year-olds typically don’t have their licenses yet.

Difference between Penetration Testing and Vulnerability Assessment?

  • Vulnerability Assessment:

    • Typically is general in scope and includes a large assessment.

    • Predictable. (Assessment date is known – we are prepared)

    • Unreliable at times and high rate of false positives.

    • Vulnerability assessment promotes debate among the stakeholders.

    • Produces a report with mitigation guidelines and action items.

  • Penetration Testing:

    • Focused in scope and may include targeted attempts to exploit specific vectors. (Both IT and Physical)

    • Unpredictable by the recipient. (Don’t know the “how” and “when”)

    • Highly accurate and reliable. (Actual proof)

    • A real Proof of Concept against vulnerabilities.

    • Produces a result (test outcome).

Possible Scope

  • Targeted exploitation of vulnerable software.

  • Social Engineering exploration (Phishing, pharming, spearphishing).

  • Physical facilities audit exploration (Unlocked terminals, unsecured buildings, and labs).

  • Wireless War Driving.

  • Dumpster Diving exploration.

Some examples of a Penetration Testing Plan.

Network Vulnerability Testing

Assumptions:

  • No impact operations, so no DOS, no offensive disabling of IDS/IPS/Firewalls/etc.

  • The above assumptions impact tests, if you find a vulnerability that'd allow you to bypass IDS/IPS, such findings cannot be used as mitigations.

Rules of Engagement (RoE):

  • Consistent with the RoE document, we don't perform tests if we think they'll damage/interrupt important work.

  • Example: “Damaging” tests turned off in Nessus; SQL injection of production/mission systems; etc.

  • Notify sysadmins/staff for critical and mission systems of the pen-test window, so they can be on hand in case of crashes, etc. (Note: Decreases effectiveness but is a necessary trade-off)

Web Vulnerability Testing

During network testing, check out some of the websites your developers have put together. If possible, get permission to test sites.

Remember, many systems now considered 'critical' are web systems throughout.

Wireless War Driving / Walking

  • Is wireless accessible from outside of where it should be? Have you checked? Can it be cracked?

  • Drive around with Laptops equipped with 802.11, antennas if possible.

  • Record any wireless network NOT authorized.

  • Bluetooth? Do the same! See what wireless shares are being broadcast (short-range) from inside locked buildings to the outsides of the building, lab, etc.

  • Look for “hpsetup”, “Free Public Wifi” (a worm), “linksys” and others.

Social Engineering Testing

  • Users are being socially engineered and phished every day!

  • We are falling for it, pretty regularly.

  • Send users a phishing email with a Remote IP that you monitor.

  • Check which users download the file.

  • Go further! Send them a script to run; the script pings a webserver whose logs you monitor.

  • Again, see who executes the file.

  • Place this file on a USB thumb drive named 'Financials', and drop the drive in the cafeteria.

  • Start a Facebook group... find people on LinkedIn... etc.

  • Remedial training is needed for employees who respond to phishing! Organization training/responsibility.

  • TIP: Don't make your phishing email TOO good. Make it semi-obvious, or you'll get into tension with what you're trying to accomplish. Remember, it's not a 'gotcha!' game, it's “This is what to look for our adversaries doing...”

Last updated 1 year ago