Weakness, What Weakness? Find the Root Cause

I suspect most security practitioners think of weaknesses as primarily being vulnerabilities and misconfigurations. That is understandable because removing vulnerabilities and misconfigurations is an important and constant battle. Besides, we have tons of vulnerability and misconfiguration information; so much information that the MITRE Corporation created the Common Vulnerabilities and Exposures (CVE) dictionary of known information security vulnerabilities and exposures, and a Common Vulnerability Scoring System (CVSS).

But weaknesses are more than vulnerabilities and misconfigurations. They include much more; for example, incomplete knowledge of the hardware and software active on a network, insufficient user training, and careless credential management.

If we don’t want to be impacted tomorrow by weaknesses we failed to address today, we must ask ourselves, “Why does this weakness exist?”

If we don’t want to be impacted tomorrow by weaknesses we failed to address today, we must ask ourselves, “Why does this weakness exist?” In many cases the answer may be simple. In other cases, the answer may look simple, but actually be more complex. I encourage you to ask “Why does this weakness exist?” five times, and drill up, not down, to gain a broad perspective.

Control weaknesses

The goal of drilling up is to identify any control weakness that opened the door for the specific symptom you are investigating. I like ISACA’s definition of a control weakness:

A deficiency in the design or operation of a control procedure (emphasis mine). Control weaknesses can potentially result in risk relevant to the area of activity not being reduced to an acceptable level. Control weaknesses can be material when the design or operation of one or more control procedures does not reduce to a relatively low level the risk that misstatements caused by illegal acts or irregularities may occur and not be detected by the related control procedures.

Asking “why?” may not uncover a control weakness, but if it does, you have hit the jackpot because correcting the control weakness is correcting the root cause that, if uncorrected, could result in a security or compliance incident.

Design vs. operation

Consider an example. Assume that you have detected a privileged account on a financial system; an account that hasn’t been used for thirteen months. You could address the weakness by deleting the account and waiting to see if anyone complains. That would remove the weakness with brute force action. However, what if you asked yourself, “Why do we still have a privileged account that hasn’t been accessed for more than one year?”

Now assume that you determined that the account belonged to Susan, a system administrator, who left the organization eleven months ago. Next, you need to drill up and ask, “Why haven’t we removed an account for someone who is no longer with our organization?” This may prompt you to examine your off-boarding process to see if it includes a procedure to remove a departing employee’s accounts. If not, you discovered a deficiency in the design of a control procedure. If the off-boarding process does include a procedure to remove a departing employee’s account, then you have discovered a deficiency in the operation of a control procedure.

Help from security frameworks

I see a growing interest in the adoption of security frameworks, such as the Center for Internet Security’s Critical Security Controls, the NIST Framework for Improving Critical Infrastructure Cybersecurity (CSF), and the ISO/IEC 27001 standard for Information Security Management. Adoption of these standards focuses an organization’s security resources on the design and operation of security controls rather than focusing on removing the symptoms resulting from lacking or loosely followed control procedures.

Focus on the design and operation of security controls rather than on removing symptoms.

Each of the above security frameworks includes multiple control objectives/procedures for access control that, if followed, would have precluded the discovery of a privileged account that should have been removed upon an employee’s departure. Their high-level access control objectives are:

• Critical Security Controls: Actively manage the lifecycle of system and application accounts – their creation, use, dormancy, deletion – in order to minimize opportunities for attackers to leverage them.
• NIST: CSF: Access to assets and associated facilities is limited to authorized users, processes, or devices, and to authorized activities and transactions.
• ISO/IEC 27001: A formal user registration and de-registration process shall be implemented to enable assignment of access rights.

Drill up!

Ask “Why does this weakness exist?” five times, and drill up, not down, to gain a broad perspective.

When you find a vulnerability, misconfiguration, or other weakness that shouldn’t exist on your network, drill up by asking “why?” five times. You may uncover an underlying control design or operation deficiency that is the root cause. Correcting a root cause is always more effective than removing the symptom.