Topic Specific Guidance

Discovery Method

In January 2014 the Verizon RISK team had a question about what discovery method to use for a particular incident. In this case the customer had purchased antivirus protection but had failed to update the signatures. The antivirus company detected malicious activity from the victim network another way and notified them. What is the discovery method in this case?

  • Int - antivirus
  • Ext - Monitoring Service
  • Ext - Unrelated party

The RISK team quickly eliminated antivirus as an option. Although it was their antivirus company that detected the malware, the detection was not internal and shouldn't be listed that way. The question of whether to use monitoring service or unrelated party came about because the victim does not pay for a monitoring service. However, since there is a business relationship with the antivirus company it seems like unrelated party isn't a good choice either. In the end, the RISK team decided that the notification of the victim happened because the victim was a customer of the antivirus company and the monitoring was a 'value-add' that they got from being an antivirus customer. So we decided to use External Monitoring Service.

But let's say for the sake of example that we know the device was stolen. Specifically, someone broke into an employee's vehicle and took a corporate-issued laptop from the backseat. This incident is not complex to VERISize because (typically) there will only be one actor, action, and asset. We assume here that the device is password-protected with full disk encryption implemented.

Classification Example: Lost Device

One of the most common incidents reported by organizations or all types and sizes is the loss of mobile devices, such as laptops or mobile phones. This can be either due to employee error or theft of the asset by an external party. In many cases it will be difficult to know if a missing device was lost or stolen, but we suggest classifying it as a 'Loss' (internal.error) rather than 'Theft' (external.physical) unless there is good reason to suspect the latter. This is not a blind/unwarranted assumption; if one is unsure what happened to the device, the variety of 'Loss' is appropriate and historical data shows devices are lost far more often than stolen.

We will focus this example on a lost device scenario, specifically a lost laptop. This incident is one of the least complex to VERISize because (typically) there will only be one actor, action, and asset. We assume here that the device is password-protected with full disk encryption implemented.

It is a very common error to see stolen laptops modeled as a confidentiality loss, but not a corresponding availability loss. Remember, the organization has lost the use of an asset. Availability should be listed in the affected attributes.

Incident Description

Actor: Internal

Motive: N/A

Actor Variety: End-user

Action: Error

Action Variety: Loss

Vector: Carelessness

Asset

Variety: Laptop

Ownership: Victim

Attribute: Confidentiality, Availability

Data dislosure: No

Notes: Laptop was password protected and encrypted

Availabilty Variety: Loss

Rationale

The classification of this everyday incident is pretty straightforward. The actor in this example is assumed to be a typical 'End-user', but could be any other variety of insider or partner as well. The action is simply 'Loss' under the Error category and the asset variety is 'Laptop', which could easily be modified to record lost phones, documents, etc. Since VERIS' attribute of Confidentiality also encompasses the notion of loss of possession or control, it is included for all lost assets. The more obvious attribute of Availability is also recorded unless the device and all data since the last backup can be fully recovered.

In this case, the device is password protected and encrypted, and unless there is positive evidence of data disclosure, we can record 'No' for that variable under Confidentiality. *If* it wasn't password protected and/or encrypted, we'd need to change that to 'Potentially' to account for the fact that our data is now at-risk of disclosure. Moreover, the variety and amount of the data involved would need to be included. *If* we received evidence that data was disclosed to unauthorized parties (e.g., it's posted on the web or used for fraud), we'd need to record 'Yes' for the data_disclosure variable.

JSON output


{
  "action": {
    "error": {
      "variety": [
        "Loss"
      ],
      "vector": [
        "Carelessness"
      ]
    }
  },
  "actor": {
    "internal": {
      "motive": [
        "NA"
      ],
      "variety": [
        "End-user"
      ]
    }
  },
  "asset": {
    "assets": [
      {
        "variety": "U - Laptop"
      }
    ]
  },
  "attribute": {
    "availability": {
      "variety": [
        "Loss"
      ]
    },
    "confidentiality": {
      "data": [
        {
          "amount": 16,
          "variety": "Personal"
        }
      ],
      "data_disclosure": "Potentially",
      "data_total": 16,
      "notes": "",
      "state": [
        "Stored unencrypted"
      ]
    }
  },
  "discovery_method": "Other",
  "impact": {
    "overall_rating": "Unknown"
  },
  "incident_id": "demo001",
  "reference": "http://www.youtube.com/watch?v=_T35QhLx_KI",
  "schema_version": "1.2",
  "security_incident": "Confirmed",
  "summary": "Unencrypted laptop lost or misplaced by a hapless employee.",
  "timeline": {
    "incident": {
      "year": 2013
    }
  },
  "victim": [
    {
      "country": "US",
      "employee_count": "1 to 10",
      "industry": 621111,
      "notes": "",
      "state": "NY",
      "victim_id": "Vandelay Industries"
    }
  ]
}

Classification Example: Stolen Device

A common incident reported by all organizations is the theft of mobile devices, such as laptops or mobile phones. In many cases it will be difficult to know if a missing device was lost or stolen, but we suggest classifying it as a 'loss' (internal.error) rather than 'theft' (external.physical) unless there is good reason to suspect the latter. This is not a blind/unwarranted assumption; if one is unsure what happened to the device, the variety of 'loss or misplacement' is appropriate and historical data shows devices are lost far more often than stolen.

But let's say for the sake of example that we know the device was stolen. Specifically, someone broke into an employee's vehicle and took a corporate-issued laptop from the backseat. This incident is not complex to VERISize because (typically) there will only be one actor, action, and asset. We assume here that the device is password-protected with full disk encryption implemented.

It is a very common error to see stolen laptops modeled as a confidentiality loss, but not a corresponding availability loss. Remember, the organization has lost the use of an asset. Availability should be listed in the affected attributes.

The main difference in classifying a lost laptop versus a stolen laptop is changing the threat actor and the action taken. Rather than an internal actor, the actor is assumed to be external. And instead of Error the action is Physical.

Incident Description

Actor: External

Motive: Financial

Actor Variety: Unaffiliated

Action: Physical

Action Variety: Theft

Location: Personal vehicle

Vector: Disabled controls

Asset

Variety: Laptop

Ownership: Victim

Attribute: Confidentiality, Availability

Data dislosure: No

Notes: Laptop was password protected and encrypted

Availabilty Variety: Loss

Rationale

The classification of this everyday incident is pretty straightforward. The actor in this example is assumed to be a typical thief ('Unaffiliated'), but could be any other variety of external, insider, or partner as well. The action variety is 'Theft' under the Physical action, and we've recorded a vector of 'Disabled controls' and location of 'Personal vehicle' to capture that the thief smashed the window of the employee's card.

A variation on this could be that the thief picked the lock, in which case the physical.vector of 'Bypassed controls' would be more suitable. The location can also be modified if the laptop was stolen from the corporate office ('Victim work area'), a store or restaurant ('Public facility'), or the employee's house ('Personal residence'). And so forth.

The asset variety here is 'Laptop', but that could easily be modified to record stolen phones, documents, etc. Since VERIS' attribute of Confidentiality also encompasses the notion of loss of possession or control, it is included for all lost assets. The more obvious attribute of Availability is also recorded unless the device and all data since the last backup can be fully recovered.

In this case, the device is password protected and encrypted, and unless there is positive evidence of data disclosure, we can record 'No' for that variable under Confidentiality. *If* it wasn't password protected and/or encrypted, we'd need to change that to 'Potentially' to account for the fact that our data is now at-risk of disclosure. Moreover, the variety and amount of the data involved would need to be included. *If* we received evidence that data was disclosed to unauthorized parties (e.g., it's posted on the web or used for fraud), we'd need to record 'Yes' for the data_disclosure variable.

JSON output


{
  "action": {
    "physical": {
      "location": [
        "Personal vehicle"
      ],
      "variety": [
        "Theft"
      ],
      "vector": [
        "Disabled controls"
      ]
    }
  },
  "actor": {
    "external": {
      "motive": [
        "Financial"
      ],
      "variety": [
        "Unaffiliated"
      ]
    }
  },
  "asset": {
    "assets": [
      {
        "variety": "U - Laptop"
      }
    ]
  },
  "attribute": {
    "availability": {
      "variety": [
        "Loss"
      ]
    },
    "confidentiality": {
      "data": [
        {
          "amount": 16,
          "variety": "Personal"
        }
      ],
      "data_disclosure": "Potentially",
      "data_total": 16,
      "notes": "",
      "state": [
        "Stored unencrypted"
      ]
    }
  },
  "discovery_method": "Other",
  "impact": {
    "overall_rating": "Unknown"
  },
  "incident_id": "demo001",
  "reference": "http://www.youtube.com/watch?v=67L0pbneT2w",
  "schema_version": "1.2",
  "security_incident": "Confirmed",
  "summary": "laptop stolen when someone broke into employee car.",
  "timeline": {
    "incident": {
      "year": 2013
    }
  },
  "victim": [
    {
      "country": "US",
      "employee_count": "1 to 10",
      "industry": 522293,
      "notes": "",
      "state": "NY",
      "victim_id": "Art Vandelay, LLC."
    }
  ]
}

Classification Example: Misdelivery

Misdelivery is a type of Error where the actor accidentally sends confidential assets or data to the wrong recipient. This can occur via electronic communication like emails and IMs as well as physical assets like documents and backup tapes. The classification of misdelivery hinges on the motive of the actor; it must be an unintentional action. If the actor intended to send confidential information to an unauthorized person then the action would be considered Misuse rather than error.

We will focus this example on a lost device scenario, specifically a lost laptop. This incident is one of the least complex to VERISize because (typically) there will only be one actor, action, and asset. We assume here that the device is password-protected with full disk encryption implemented.

It is a very common error to see stolen laptops modeled as a confidentiality loss, but not a corresponding availability loss. Remember, the organization has lost the use of an asset. Availability should be listed in the affected attributes.

Incident Description

Actor: Internal

Motive: N/A

Actor Variety: End-user

Action: Error

Action Variety: Misdelivery

Vector: Inadequate processes

Asset

Variety: M - Documents

Ownership: Victim

Attribute: Confidentiality

Data dislosure: Yes

Notes: Documents were mailed to the wrong recipient due to an off-by-one error

Rationale

The actor in this example is assumed to be a typical 'End-user', but could be any other variety of insider or partner as well. The action variety is simply 'Misdelivery' under the Error category and the asset variety is 'M - Documents', which could easily be modified for backup tapes or any other offline asset that might be sent through the mail. If email or 'soft' copies of documents are misdelivered, the asset is likely 'U - Desktop' or 'U - Laptop', since the user most likely composed the email and/or attached documents stored on such devices. Naturally, other varieties of end-user devices and servers can be affected as well; it all depends on where the data was before it was misdelivered.

In terms of attributes, misdeliveries will always compromise the Confidentiality of the asset due to the loss of possession or control. In this case, we'll assume the envelope containing the documents was opened and that the recipient then contacted the organization to let them know about the mix-up. This should be marked as 'Yes' for data disclosure, even if nobody else but that one individual saw it and he/she never did anything malicious with it (i.e., the documents were still seen by an unauthorized party). A variation on this would be encrypted backup tapes sent to the wrong address; unless there is positive evidence to the contrary, we would record 'No' for data disclosure in this scenario.

Many times, misdelivered documents are saved electronically and so the victim organization is not deprived of the use of the asset. If, however, the assets or data cannot be recovered, it is appropriate to include Availability as an affected attribute.

JSON output


{
  "action": {
    "error": {
      "variety": [
        "Misdelivery"
      ],
      "vector": [
        "Inadequate processes"
      ]
    }
  },
  "actor": {
    "internal": {
      "motive": [
        "NA"
      ],
      "variety": [
        "End user"
      ]
    }
  },
  "asset": {
    "assets": [
      {
        "variety": "M - Documents"
      }
    ]
  },
  "attribute": {
    "confidentiality": {
      "data": [
        {
          "amount": 1337,
          "variety": "Personal"
        }
      ],
      "data_disclosure": "Yes",
      "data_total": 1337
    }
  },
  "incident_id": "demo003",
  "reference": "http://youtu.be/icDXNHF-oEw",
  "schema_version": "1.2",
  "security_incident": "Confirmed",
  "summary": "Documents were mailed to the wrong people due to an off-by-one error.",
  "timeline": {
    "incident": {
      "year": 2013
    }
  },
  "victim": [
    {
      "country": "US",
      "employee_count": "1 to 10",
      "industry": "336611",
      "state": "NY",
      "victim_id": "Kramerica Industries"
    }
  ]
}

Classification Example: Publishing Error

Publishing error is a type of Error where the actor puts non-public data in a public forum such as a web site, or a newspaper. Typically this is a mistake that involves non-public data on a server being accidentally placed in a folder that is being served up by web server software.

Incident Description

Actor: Internal

Motive: N/A

Actor Variety: End-user

Action: Error

Action Variety: Publishing error

Vector: Inadequate processes

Asset

Variety: S - Web application

Ownership: Victim

Attribute: Confidentiality

Data dislosure: Yes

Discovery Method: External unrelated party

Rationale

The actor in this example is assumed to be a typical 'End-user', but could be any other variety of insider or partner as well. The action variety is simply 'Publishing error' under the Error category and the asset variety in this example is a web server. The motive is NA for errors because the actor did not intend for anything to happen.

In terms of attributes, misdeliveries will always compromise the Confidentiality of the asset due to the loss of possession or control. However, it is not always certain that a data disclosure has occurred. In this example, the publishing error was reported by an external unrelated party which means that data disclosure must be set to yes because we know that at least one unauthorized person has seen the mispublished data. However, if the error was discovered internally and there isn't any concrete evidence that the document has been viewed by unauthorized persons then this could be set to Potentially.

The vector of the publishing error is inadequate process in this example, although the vector is often unknown. Inadequate process would be an appropriate choice if there was no checking mechanism in place to ensure that only authorized data is being published.

JSON output


{
  "action": {
    "error": {
      "variety": [
        "Publishing error"
      ],
      "vector": [
        "Inadequate processes"
      ]
    }
  },
  "actor": {
    "internal": {
      "motive": [
        "NA"
      ],
      "variety": [
        "End user"
      ]
    }
  },
  "asset": {
    "assets": [
      {
        "variety": "S - Web application"
      }
    ]
  },
  "attribute": {
    "confidentiality": {
      "data": [
        {
          "amount": 1337,
          "variety": "Personal"
        }
      ],
      "data_disclosure": "Yes",
      "data_total": 1337
    }
  },
  "incident_id": "demo004",
  "reference": "http://youtu.be/P-NYDW5whpw",
  "schema_version": "1.2",
  "security_incident": "Confirmed",
  "discovery_method":"Ext - unrelated party",
  "summary": "Spreadsheet containing personal information was saved to a folder that was being indexed by Apache web server.",
  "timeline": {
    "incident": {
      "year": 2013
    }
  },
  "victim": [
    {
      "country": "US",
      "employee_count": "1 to 10",
      "industry": "336611",
      "state": "NY",
      "victim_id": "Kruger Industrial Smoothing"
    }
  ]
}

Classification Example: Email Abuse

It is fairly common to see employees misuse email in a way that compromises the confidentiality of an organization's private data. One common example is when a user emails a sensitive document to a personal email account to work on it from home. This situation can be confusing because there are several action varieties that might describe this, and there is a good argument for more than one affected asset as well. When coding an incident where there is only one action, it is best to find the single most appropriate option.

For example, if an employee uses corporate email for personal use or for sending work documents to apersonal email account against policy, then it is an example of misuse:Email misuse. A similar scenario is where an employee uploads sensitive documents to a service like Dropbox, which is not email abuse but is misuse:Use of unapproved software. Typically, an incident will not include both email misuse and use of unapproved software if there is only one action.

If the organization has a policy in place that mandates, for instance, that all files stored on non-corporate systems must be encrypted, then include “email misuse” OR “unapproved software”AND misuse:data mishandling.

In all of these cases, the affected asset is the workstation that user is using to upload or email documents. Unless the email server itself is compromised it should not be listed among the affected assets.

Incident Description

Actor: Internal

Motive: Convenience

Actor Variety: End-user

Action: Misuse

Action Variety: Email misuse

Vector: LAN access

Asset

Variety: U - Desktop

Ownership: Victim

Attribute: Confidentiality, Availability

Data dislosure: Potentially

JSON output


{
  "action": {
    "misuse": {
      "variety": [
        "Email misuse"
      ],
      "vector": [
        "LAN access"
      ]
    }
  },
  "actor": {
    "internal": {
      "motive": [
        "Convenience"
      ],
      "variety": [
        "End user"
      ]
    }
  },
  "asset": {
    "assets": [
      {
        "variety": "U - Desktop"
      }
    ],
    "ownership": "Victim"
  },
  "attribute": {
    "confidentiality": {
      "data_disclosure": "Potentially"
    }
  },
  "reference": "http://youtu.be/WhWavua-1FI",
  "victim": [
    {
      "country": "US",
      "employee_count": "100 to 1000",
      "industry": "515210",
      "state": "NY",
      "victim_id": "Plaza Cable"
    }
  ]
}