Hallsville ISD Threat Model Proposal

Summary

In a world where cyber threats continue to grow in complexity and quantity each year, threat modeling is one of the most advantageous and practical tools we can use to shore up security. This threat model is designed to elevate Hallsville ISD’s security posture by cataloguing all assets within a given system that need to be protected, identifying by whom and what directions they might be attacked, and how exactly they can be safeguarded.

Steps

1. Inventory of assets
   The first phase in developing a threat model is identifying what we care about. Before we can protect our systems, we first need a comprehensive understanding of what assets matter most and where they’re operating and stored at all times.
   
   
2. Identify security objectives and non-objectives
   Map out what we’re protecting each asset from, and prioritize our security objectives. To do this, security teams typically conduct a comprehensive audit of their assets against the “CIA triad.” This is a model for assessing three of the most important aspects of security; confidentiality (who has access to the asset), integrity (can the asset be modified), and availability (is the asset protected against denial of service and other attacks).
   
   
3. Lay out an adversary model
   One of the most important questions we need to ask during any threat modeling exercise is, who are our adversaries? Is it someone that has network access to a machine, someone that has physical access, or someone that has software access?
   
   Based on the security objectives we establish in Step 2, our adversary model is essentially a list of attacker personas we need to defend against. It will outline who they are, what their skillsets might be, what level of privilege they have and their attack method of choice.
   
   
4. Pinpoint all relevant threat vectors and attacks
   This is the most time-intensive stage, one that involves staying up to date with both known (legacy) attacks, as well as the cutting edge threats. In this stage, we must understand the data flows of our assets. Where are they stored at rest? Are they encrypted? What about in transition? We must step into the adversary’s shoes and identify every possible attack vector.
   
   Should we be concerned about escalations of privilege in firmware, preventing unauthorized access for turning security features on or off, enabling or disabling debug and flash locks, or downgrading to older, legitimate software versions that are vulnerable to certain attacks? We need to understand if these are risks to our organization to protect against them.
   
   This section of the threat model will include a matrix of all threat vectors and every potential attack for each. One industry resource often used in this process is the CVSS calculator, which enables security teams to align assets with objectives, adversary models, attack vectors, and associated severity level.
   
   
5. Develop the necessary mitigations
   From there, we’ll need to write a mitigation for each of those potential attacks. For instance, we might develop a mitigation that prevents attacks from modifying your firmware by forcing the system to prevent boot if any changes are made that don’t match approved policies. Or, a mitigation might prevent a bad actor from running a malicious driver by blacklisting it. This section of our threat model is essentially a matrix that includes at least one mitigation for each possible attack against every asset we’re trying to defend.

Tips for effective threat modeling
As with any major security process or procedure, there are various best practices we can and should implement to avoid major pitfalls and increase the probability that our threat model will successfully improve Hallsville ISD’s security posture over the long term.

One critical best practice is to share the document broadly within our organization. Without wide circulation among those involved in every stage of product development, the document isn’t of much use. When all teams are operating based on the same threat model we increase the odds of delivering a cohesive, secure product consistent with its assumptions.

Additionally, we must approach threat models as “living documents.” The final and most important step in the threat modeling process is never truly complete. We must commit to re-examining and refining our threat models regularly. As the threat landscape evolves our threat model must be adapted to account for new threats, attack techniques, etc. Failing to do so will result in missed vulnerabilities, unpatched exploits, ignorance about relevant security research, and other security blind spots.

We will also use security validation tools like the open source CHIPSEC project to analyze the platform-level security of hardware, devices, and system firmware configurations. It’s also important to note that following NIST standards (like NIST 800-193) is another way to help ensure that our platforms, software, and products are aligned with a robust threat model.