Blockchain/ Distributed Ledger

Expand all | Collapse all

System properties to consider for defender – aka How to deal with attackers/vulnerabilities/threats/risks

  • 1.  System properties to consider for defender – aka How to deal with attackers/vulnerabilities/threats/risks

    Posted Nov 26, 2020 09:24:00 AM
    Edited by Kurt Seifried Nov 26, 2020 10:17:01 AM

    I have been looking at threat and risk modelling a lot recently. One aspect of this is looking at the various major properties of system defenses. I think at the meta level there are 5 primary properties, please note that specific system components and processes can of course provide more than 1 of these properties (indeed some provide all 5).

    The reason for labelling and using these 5 primary properties is it allows us to more easily classify and determine the effectiveness of technical and process controls and technologies that we use to protect systems from attackers. These properties also follow a natural progression that starts with keeping the attacker out and ends in system recovery after everything has gone wrong. As such they can help guide us, for example if a system MUST have confidentiality then we will want to focus on keeping the attacker out and limiting the attackers ability to exfiltrate data for example.

    The 5 main properties are:

    Neutralize - You can neutralize the vulnerability, patching it, workaround, etc. The major aspect of neutralization is that you try to prevent attackers from having the ability to exploit vulnerabilities.

    Detect - You can detect exploitation and then trigger a response (automated/human/both). The major aspect of detect is that you accept that attackers will exploit vulnerabilities and get in, so you detect and trigger a response in order to deal with it.

    Limit - You can limit the impact of exploitation of the vulnerability (e.g. by implementing least privilege across your system). The major aspect of limit is that you accept that attackers will exploit vulnerabilities and get in, and you minimize the impact where possible.

    Forensic - You can log and record information for later use. The major aspect of forensics is that you accept that attackers will exploit vulnerabilities and get in, you want to be able determine what and how it happened and know what systems need recovery so you can return the system to a known good state.

    Recovery - You can implement technology and processes to aid in recovery (backups, etc.). The major aspect of recovery is that you accept that attackers will exploit vulnerabilities and get in, and you want to be able to return the system to a known good state.

    Some simple examples would be:

    • Patching CVE vulnerabilities (Neutralization)
    • Using an IDS/IDP system to both prevent incoming data from containing XSS strings (Neutralization), detect and block outgoing strings containing XSS (Detect leading to Neutralization and/or Limit) and logging of all queries (Forensics)
    • System backups can be used for both forensics (assuming you backed up the system after it got hacked) and for system recovery

    I think these 5 properties embody the main things a defender cares about, but I could of course be wrong. If you have any thoughts or comments please reply here!



    ------------------------------
    Kurt Seifried
    Chief Blockchain Officer and Director of Special Projects
    Cloud Security Alliance
    [email protected]
    ------------------------------


  • 2.  RE: System properties to consider for defender – aka How to deal with attackers/vulnerabilities/threats/risks

    Posted Dec 02, 2020 10:23:00 AM
    Edited by Kurt Seifried Dec 04, 2020 10:35:41 AM
    So with respect to some discussion on "Audit" and "Validation":

    "Audit" is a sub-component of each of these, the ability to audit and confirm a control is in place is necessary, e.g. was the correct configuration made, and did it take effect? Effectively audit is "how do you validate that this control is present/what it will do/etc" and then validation is the actual activity of doing so.

    "Validation" is a sixth property, validation can range from reviewing the business process or configuration file, but can go all the way to an actual DR test of the system (e.g. Netflix Chaos Gorilla, turning an entire cloud availability zone off to simulate a massive failure). Validation implies an active, adversarial test of the control to ensure it is in place. Additionally validation is necessary to ensure that not only are the controls in place as stated, but that they behave and achieve what was intended. For example I looked at our CloudFlare DNS information backups and validated that the DNS information was present, but noticed that the TLS/page rules/etc. data was missing, simply put the backup script I was using only grabs the DNS data, not the associated domain data. This would have been painful to discover while trying to do a recovery (e.g. if I accidentally deleted a domain or made a change that I wanted to roll back). 

    Validation - You need to actively confirm that the control is in place and working as intended. Validation can range from a simple audit style check of a configuration file all the way to a full penetration test that has a red team actively break in and forces the use of neutralization, detection, limitation, forensics and recovery processes for example.

    ------------------------------
    Kurt Seifried
    Chief Blockchain Officer and Director of Special Projects
    Cloud Security Alliance
    [email protected]
    ------------------------------