What is the role of Threat Modeling in performing a vulnerability assessment quizlet?

Why is threat modeling necessary?

As organizations become more digital and cloud-based, IT systems face increased risk and vulnerability. Growing use of mobile and Internet of Things (IoT) devices also expands the threat landscape. And while hacking and distributed-denial-of-service (DDoS) attacks repeatedly make headlines, threats can also come from within--from employees trying to steal or manipulate data, for example.

Smaller enterprises are not immune to attacks either--in fact they may be more at risk because they don't have adequate cybersecurity measures in place. Malicious hackers and other bad actors make risk assessments of their own and look for easy targets.

What are the benefits of threat modeling?

The process of threat modeling can:

• Provide an enhanced view of systems. The steps involved in threat modeling--creating data flow diagrams (DFDs) and graphical representations of attack paths, as well as prioritizing assets and risks--help IT teams gain a deeper understanding of network security and architecture.
• Help enable better collaboration on security. Proper threat modeling requires input from many stakeholders. Participating in the process can help instill cybersecurity consciousness as a core competency for all participants.
• Facilitate risk prioritization. Businesses can use the threat data provided by modeling to make decisions about which security risks to prioritize--a helpful process for understanding where to allocate people and budget resources.

Does threat modeling require special software?

While basic threat modeling can be performed in a brainstorming session, larger enterprises with more potential vulnerabilities can use software and hardware tools to improve the security of complex systems with multiple points of entry. Software helps provide a framework for managing the process of threat modeling and the data it produces. It can also help with risk and vulnerability assessment and suggest remediation.

What is involved in the threat modeling process?

Steps involved in threat modeling include:

• Identify assets. An asset could be account data, intellectual property, or simply the reliable functioning of a system.
• Diagram the system. DFDs provide a high-level, asset-centric view of systems and the data flows of attacks. An attack tree, or graphic representation of an attack path, illustrates the possible origins and paths of attacks.
• Analyze threats. Use threat modeling methods to further analyze specific threat types, identify potential threats, map data flows, and quantify risk.
• Perform risk management and prioritization. Many threat modeling tools produce threat scores and data for calculating risk. Stakeholder input is essential to this step.
• Identify fixes. Once you identify the areas, assets, or threats that matter most to the organization, the next steps may be apparent. Changing firewall, encryption, or multi-factor authentication settings are examples of steps to address a threat.

How do I measure the effectiveness of threat modeling?

Two ways to measure effectiveness are:

• Common Vulnerability Scoring System (CVSS). CVSS produces standardized scores for application vulnerabilities, IT systems and elements, and IoT devices; the scores can be calculated with a free online tool. For additional perspective, scores can be compared against a database of existing scores crowdsourced from similar enterprises.
• Penetration testing. Sometimes referred to as "ethical hacking," penetration testing is the process of staging dummy attacks on a system to measure its strengths and weaknesses. Pen tests may require a good deal of time-consuming data analysis, so organizations should be wary of running too many tests, or tests on assets that are not sufficiently high-risk to justify the cost.

Is threat modeling available as a service?

Yes. Threat modeling as a service (TMaaS) can allow an organization to focus on remediation and high-level network architecture decisions, while leaving necessary data-crunching to TMaaS providers. TMaaS also can perform continuous threat modeling, automatically running testing anytime a system is updated, expanded, or changed. TMaaS solutions incorporate threat intelligence--such as data about threats and attacks crowdsourced from organizations worldwide--that can inform threat hypotheses for networks and improve network security.

Threat modeling methods create these artifacts:

• An abstraction of the system
• Profiles of potential attackers, including their goals and methods
• A catalog of threats that could arise

Threat modeling works by identifying the types of threat agents that cause harm to an application or computer system. It adopts the perspective of malicious hackers to see how much damage they could do. When conducting threat modeling, organizations perform a thorough analysis of the software architecture, business context, and other artifacts (e.g., functional specifications, user documentation). This process enables a deeper understanding and discovery of important aspects of the system. Typically, organizations conduct threat modeling during the design stage (but it can occur at other stages) of a new application to help developers find vulnerabilities and become aware of the security implications of their design, code, and configuration decisions. Generally, developers perform threat modeling in four steps:

• Diagram. What are we building?
• Identify threats. What could go wrong?
• Mitigate. What are we doing to defend against threats?
• Validate. Have we acted on each of the previous steps?

When performed correctly, threat modeling can provide a clear line of sight across a software project, helping to justify security efforts. The threat modeling process helps an organization document knowable security threats to an application and make rational decisions about how to address them. Otherwise, decision-makers could act rashly based on scant or no supporting evidence.

Overall, a well-documented threat model provides assurances that are useful in explaining and defending the security posture of an application or computer system. And when the development organization is serious about security, threat modeling is the most effective way to do the following:

• Detect problems early in the software development life cycle (SDLC)—even before coding begins.
• Spot design flaws that traditional testing methods and code reviews may overlook.
• Evaluate new forms of attack that you might not otherwise consider.
• Maximize testing budgets by helping target testing and code review.
• Identify security requirements.
• Remediate problems before software release and prevent costly recoding post-deployment.
• Think about threats beyond standard attacks to the security issues unique to your application.
• Keep frameworks ahead of the internal and external attackers relevant to your applications.
• Highlight assets, threat agents, and controls to deduce components that attackers will target.
• Model the location of threat agents, motivations, skills, and capabilities to locate potential attackers in relation to the system architecture.

As a security process, threat modeling is subject to several misconceptions. Some people believe threat modeling is only a design-stage activity, some see it as an optional exercise for which penetration testing or code review can substitute, and some think the process is simply too complicated. The following should help dispel some of these misconceptions:

Penetration testing and code reviews can’t substitute for threat modeling. Penetration testing and secure code review are two activities that are effective for finding bugs in code. However, security assessments (e.g., threat modeling) are better at uncovering design flaws.

There’s a good reason to conduct a threat model after deployment. Understanding the issues in the current deployment influences future security architecture strategy, and monitoring weaknesses allows for faster and more effective remediation. Without understanding the potential threats an application faces, you can’t ensure that you’re addressing all risks.

Threat modeling isn’t that complicated. Many developers are intimidated by the idea of threat modeling. At first glance, it can seem daunting. However, if you break up the tasks into workable steps, performing a threat model on a simple web application—or even a complex architecture—becomes systematic. The key is to start with basic best practices.

The killer application of threat modeling is promoting security understanding across the whole team. It’s the first step toward making security everyone’s responsibility. Conceptually, threat modeling is a simple process. So consider these five basic best practices when creating or updating a threat model:

1. Define the scope and depth of analysis. Determine the scope with stakeholders, then break down the depth of analysis for individual development teams so they can threat model the software.

2. Gain a visual understanding of what you’re threat modeling. Create a diagram of the major system components (e.g., application server, data warehouse, thick client, database) and the interactions among those components.

3. Model the attack possibilities. Identify software assets, security controls, and threat agents and diagram their locations to create a security model of the system (see Figure 1). Once you’ve have modeled the system, you can identify what could go wrong (i.e., the threats) using methods like STRIDE.

4. Identify threats. To produce a list of potential attacks, ask questions such as the following:

                    Are there paths where a threat agent can reach an asset without going through a control?

                    Could a threat agent defeat this security control?

                    What must a threat agent do to defeat this control?

5. Create a traceability matrix of missing or weak security controls. Consider the threat agents and follow their control paths. If you reach the software asset without going through a security control, that’s a potential attack. If you go through a control, consider whether it would halt a threat agent or whether the agent would have methods to bypass it.

Synopsys software security services include threat modeling, which can identify potential weaknesses that may increase your system’s susceptibility to an attack, including secure design violations, security control omissions, or control misconfiguration, weakness, or misuse.

The Synopsys high-level approach

As Figure 2 shows, the Synopsys high-level approach to threat modeling adheres to the following steps:

• Model the system.
• Conduct a threat analysis.
• Prioritize the threats.

System modeling consists of two parts:

1. Creating a component diagram with a control flow graph (which shows all possible execution paths in a program)
2. Identifying assets, security controls, trust zones, and threat agents

Perhaps the most important activity in threat modeling is identifying threats. Most approaches fall into two categories:

• Checklist-based approaches. Many threat modeling approaches involve a checklist or a template. For example, STRIDE recommends you consider six types of threats—spoofing, tampering, repudiation, information disclosure, denial of service, and escalation of privilege—for all dataflows that cross a trust boundary.
• Non-checklist-based approaches. These approaches generally use creative methods (e.g., brainstorming) to identify attacks.

Synopsys threat analysis uses a quasi-checklist approach: It uses a template to drive the core analysis but still leaves the opportunity for creative analysis. Synopsys uses pre-baked application protocol threat analysis for commonly used application-level protocols, such as OAuth, SAML, OIDC, Kerberos, password-based authentication, and others. This list is not exhaustive, but it allows you to start thinking about areas of concern to analyze.

What is the role of Threat Modeling in performing a vulnerability assessment?

What is the primary goal of the Vulnerability assessment and REmediation?

How are dashboards used as part of systems monitoring or incident response?