Module 1 - Threat Modeling Overview PDF

Module 1 - Threat Modeling Overview IT024 - Cyber Threat Modeling Threat Modeling Overview - Definition, Origin, and Use Threat Modeling  It is a strategic process aimed at considering possible attack scenarios and vulnerabilities within a proposed or existing application environment for...

Module 1 - Threat Modeling Overview IT024 - Cyber Threat Modeling Threat Modeling Overview - Definition, Origin, and Use Threat Modeling  It is a strategic process aimed at considering possible attack scenarios and vulnerabilities within a proposed or existing application environment for the purpose of clearly identifying risk and impact levels.  Each major function within the threat modeling process requires a great deal of consideration and anticipation of multiple risk factors influenced by threat, vulnerability, and impact levels.  The first emphasized term, strategic, describes a quality of threat modeling reflected in its ability to anticipate threats via calculated and simulated attack patterns. Threat Modeling Overview – Definition, Origin, and Use Process  It is one of threat modeling’s key distinguishing qualities.  A chain-like reaction of tactical events is conducted across multiple domains (business objectives, system/database administration, vulnerability management, etc.)  Where additional review, input, and contribution is provided by other stakeholders within the process all in relation to a protected application environment. Threat Modeling Overview Definition, Origin, and Use Attack  Reflects a major science to threat modeling  The discipline of researching how attack patterns can potentially exploit software vulnerabilities and/or poorly designed countermeasures.  The hierarchy of an attack becomes dissected via threat modeling techniques, exposing faults in application design and/or software development, as well as other practical yet key areas, such as unveiling plausible motives for which an attacker initially sought to launch their assault. Threat Modeling Overview Definition, Origin, and Use Vulnerabilities  It is a term used far more prevalently within other information security efforts.  In the scope of threat modeling, its use extends the manner in which software vulnerabilities are understood.  Vulnerabilities at the platform and software levels are aggregated and correlated to possible attack scenarios. Threat Modeling Overview Definition, Origin, and Use Application Environment  The application environment expression serves as the object of the threat modeling process.  Other traditional security procedures simply address a single aspect of an entire application environment, thereby negating a more holistic approach to application security.  This is not to state that these more isolated procedures are not important, but rather that the sum of their individual benefits is encompassed in the process of threat modeling and applied to the entire application environment. Threat Modeling Overview Definition, Origin, and Use Risk  The term risk serves as the object of key interest to threat modeling.  Threat modeling, as a supportive role in fulfilling business objectives, seeks to identify risks associated with the cumulative effects of an ever- evolving threat environment, compounded by software/network vulnerabilities, and fueled by attack motives or interest in business information – all managed and/or driven by an application environment. Threat Modeling Overview Definition, Origin, and Use Threat modeling  Threat modeling provides greater precision in conveying risk by providing a clear path on how a business application environment could be compromised and the probability of the actual risk.  In essence, the risk becomes the common glue that unifies security and business professionals in a collaborative effort to protect the enterprise. Threat Modeling Overview Definition, Origin, and Use Impact  impact is the ability to answer the question  “How bad is it?” Unless security professionals consider all possible threat scenarios in order to generate a prioritized, risk-based analysis, they cannot provide an effective and credible answer. Threat Modeling Overview Definition, Origin, and Use Art of Espionage  Surveying internal readiness is parallel to the necessity of gathering information about an enemy’s intent and capabilities.  Threat models must account for various critical factors such as an enemy’s attack motive, capabilities, vulnerabilities or flaws, and amount of information.  The complexity of threat modeling lies in expedient analysis and process development.  Adding to the complexity, sometimes reconnaissance efforts do not yield credible information.  Misinformation can derail a threat model. Following an incorrect set of attack scenarios also misleads defense efforts from designing an effective countermeasure. Threat Modeling Overview Definition, Origin, and Use External information sources  may include application/platform vulnerabilities, as well as a thorough attack library containing current and past exploits that could be used in the form of an attack. Attack library  It would encompass the exploit or series of exploits that are necessary for the attack to be successfulto an evolving threat model, software architects and developers will also have to consider flexibility in their products so they can respond to changing threat scenarios presented via application threat modeling.  This makes threat modeling a “living” or ever-changing process that requires updating. An already constructed threat model is rigid in form but assumes greater flexibility by the inputs it receives in terms of threat intelligence. Threat Modeling Overview Definition, Origin, and Use Designing Countermeasures  Designing effective countermeasures in software applications is one of the key differentiators of application threat modeling over other traditional security efforts (which may only address a portion of the overall threat and associated risk).  Designing good countermeasures in ballistic defense systems involves not only addressing perceived threats via good information and attack assumptions but also foreseeing how the same threat may evolve or assume a different form. At times, attack patterns may revert to historical, classic attacks that are perceived to be ineffective.  This perception provides a false sense of security and a way for attackers to revert to more classic attack patterns. Threat Modeling Overview - Rationale and Evolution of Security Analysis  Cyber warfare … zero-day … botnets. These terms depict the insurmountable challenges facing information security professionals today.  This quotation for many should simply be a trite expression of the obvious – a dire need to secure information borders within the public and private sectors. Threat Modeling Overview Rationale and Evolution of Security Analysis Environmental Threat Factors  The opportunities for exploitation and/or well-defined attack motives can be greatly influenced by these environmental conditions and ultimately alter the following characteristics of an attack: 1. Intensity of a planned attack. 2. Sophistication of an attack. 3. Probability for successful exploit. 4. Ability to distort/eliminate forensic evidence. Threat Modeling Overview Rationale and Evolution of Security Analysis Product of the Environment  The term environment is not to be confused by the application domain or application environment, which is limited by the functions of its authorized and unauthorized user base.  It describes the social, political, economic, belief-based, and/or financial factors that serve as key drivers upon which software adversaries act.  Revenge, spite, corporate espionage, and fraud are motives fueled by environmental conditions such as war, layoffs, recessions, financial distress, social injustices, and much more. This is just a short list of environmental examples for which hypothetical attack plans can evolve into mature attack plans. Threat Modeling Overview Rationale and Evolution of Security Analysis Environmental factors  Environmental factors tremendously facilitate attack windows of opportunity similar to how they inspire attacks.  Events in the social, political, environmental, or economic climate can provide a ripe occasion for conducting attacks.  Threat Modeling Overview  Figure 1.1 provides a visual representation of how environmental factors serve as additional intelligence when identifying probable attack scenarios during application threat modeling. Threat Modeling Overview Rationale and Evolution of Security Analysis  Table 1.1 lists examples across multiple industry segments and relates them to possible attack motives. Threat Modeling Overview Rationale and Evolution of Security Analysis Judging by Motives  Behind every threat is a motive, even if the motive is simple curiosity.  Application-based attacks differ no less. Before a scan is run, payload is altered, or business logic is abused, the attack design must have an objective.  Even seemingly benign attack probes or reconnaissance efforts against an application environment carry their own set of motives, quite possibly ulterior motives. Threat Modeling Overview Threat Modeling Overview Rationale and Evolution of Security Analysis  Table 1.2 reveals how threat scenarios line up with motives and a subset of attack vectors.  Table 1.2 reveals how threats encompass motives, target assets, and possible attack vectors to be used against an application environment.  The table is meant to serve as a template for future use by threat modelers and risk analysts in beginning to correlate environmental factors to the vectors in which an attack would ultimately be introduced. Threat Modeling Overview Rationale and Evolution of Security Analysis Practical Application  Environmental factors provide improved calculations on attack probabilities as well as the prognosis on severity levels of observed attacks, either before, during, or after they have taken place.  Constantly changing conditions heightens the probability for attack scenarios and their associated impact levels.  The frequencies and scopes are driven largely by the overall historical and future sense of cyber-attacks against an organization’s many application environments Threat Modeling Overview Rationale and Evolution of Security Analysis Threat Modeling Overview Rationale and Evolution of Security Analysis Sources of information  During these periodic assessments will also vary greatly and be spurred by available resources. Internal personnel will ultimately be required to conduct analysis of internal factors to the organization. These may include the following types of evaluations:  HR Meetings: Interviews with HR to identify cases where previously reported personnel cases provide a level of indication that certain employees may wish to act against the organization or its objectives. Obtaining information on disgruntled employees, for example, may provide early threat detection capabilities for certain types of information and operational threats.  Personnel Surveys: Any HR surveys that seek to identify personnel viewpoints on the organization. Threat Modeling Overview Rationale and Evolution of Security Analysis  Threat Feeds: Threat feeds from external sources in which data reflects recent and aggregated attacks against similar companies, companies within the same industry sector, and companies of similar cultural and organizational makeup.  Third-Party Assessments: External assessments performed by third parties help identify environmental factors and possible insider attack motives that would not have been discovered via internal assessments or employee surveys.  Ingress Traffic Analysis: Comprehensive review of ingress traffic across multiple entry points and correlated by geographic source, date/time, protocol, and separated by authorized IP sources (authorized third-party vendors) and unknown/unrecognized sources. Threat Modeling Overview Rationale and Evolution of Security Analysis  Access Audits: Sensitive applications with logs set to record successful and failed logins. Correlate successful logins to time of day and frequency and perform the same correlation for failed events.  Socioeconomic Analysis: A review of external environment factors outside of the organization will ultimately affect employees in order that they behave either more or less rational with respect to their job functions and the due care that they would need to have with application environments used within their job functions. Threat Modeling Overview Building a Better Risk Model  The Inherent Problem  The problem with measuring risk today is that it is clouded by fear. Perception and subsequent reaction to perceived threats draw misguided conclusions for many attempting to mitigate risk.  Table 1.4 is not meant to be a comprehensive listing of variables that lead to certain failures in application security, but instead a synopsis of commonly observed factors that inhibit a more strategic approach to app_sec. Threat Modeling Overview Threat Modeling Overview Building a Better Risk Model Business Case for Threat Modeling  The following is a list of key benefits in developing and sustaining threat modeling efforts within an enterprise. 1. Business Applications as Attack Vectors: Software applications are low- hanging fruit for cybercriminals since software vendors do not have the same level of maturity in testing and patching as platform vendors for various operating systems. 2. Reduced Remediation Time and Efforts: Anything that equates to more time in business also equates to additional cost. 3. Collaborative Approach: Security risk assessments have historically taken an adversarial approach to both finding and addressing security risks in application environments. Threat Modeling Overview Building a Better Risk Model 4. Building Security In: Contrary to security requirements previously established and socialized by separate and adverse groups (in either security governance or security architecture), security requirements now become an innate part of software development. Threat Modeling Overview Building a Better Risk Model Improved Application Design  Application design has been more of a conceptual idea versus an actual work effort funded by most IT organizations. This may explain the poor state of application security that we find ourselves in, or at the very least serve as one of its contributing factors.  Even when implemented, application design considerations always seem to be one sided or built primarily around software features, diluting other variables that should influence the overall application design, including key business, IT, and security objectives for the application. Threat Modeling Overview Building a Better Risk Model Scalability  One key aspect of improved application design is the ability of the application environment to accommodate changes, such as future business needs, infrastructure, and security requirements.  As all of these factors may require code modifications, the impact (whether good or bad) on scalability is ever-present.  Figure 1.2 shows the overall metrics for application threat modeling that need to encompass the following requirements. Threat Modeling Overview  Threat Modeling Overview  Figure 1.3 provides a graphical representation of these influential variables to software scalability. Threat Modeling Overview Building a Better Risk Model Support  Supporting software, such as any other IT-related process, must be properly aligned to a business objective. Such a lofty, idealistic goal may seem impractical if all support efforts will be validated against a broadly defined business or IT objective.  Ensuring that support efforts on software applications are in alignment to these objectives, however, will ensure that not all supportive product efforts deviate from principal features of an application.  Table 1.5 shows summary of the key members at the focal point of supporting software, examples of their related work efforts, and the benefits reaped from application threat modeling (ATM). Threat Modeling Overview Threat Modeling Overview Building a Better Risk Model Security  Application Threat Modeling yields improved application design, driven by security efforts via strategic, streamlined, application hardening efforts, ideally all within the context of a secure software development process. Threat Modeling Overview Threat Anatomy  It is important to understand the hierarchy of terminology used particularly motives, threats, and attacks, as they each represent both a unique and interrelated component to the application threat model.  In software applications, a threat is very much like risk in that it will never be zero or nonexistent.  There always is a degree of risk primarily due to the fact that threats are always present within or around an application.  With enough motive, threats serve as mobilizing agents to conduct attacks against software environments.  Figure 1.4 is the motive geared toward creating a diversion for a simultaneous or delayed threat or attack. Threat Modeling Overview Threat Modeling Overview Threat Anatomy The Threat Wrapper  Threats’ complexities lie in bundling varying degrees or attack types, vulnerabilities, and impact levels, and there is variation among application types.  It is a handful of threats and varying types of application environments, and dissect the encompassing attacks that could accompany them.  A very simple threat model that expresses a highly generic flow of input/output from a user base, between two trust boundaries, to a target information source. Threat Modeling Overview Threat Anatomy  In this case, the trust boundaries are neatly drawn between the client or user environment and the application environment. At this point, although we have not defined the business or IT objectives that should provide governance, we are proceeding to understand how the imminent threat should be addressed.  Figure 1.5 shows the data flow and identifies how data sources can be leaked via the boundaries of the application environment. Threat Modeling Overview Threat Anatomy Threat Modeling Overview Threat Anatomy  Motives trigger actions on behalf of malicious individuals or irresponsible employees to create some degree of threat.  These threats may be geared toward target assets or information sources, as part of their objective and will ultimately rely on intel to discover software vulnerabilities or misconfigurations to exploit via attacks.  As the threat traverses across public, semipublic, private, and restricted application zones, other variables related to threat begin to take form such as probability of successful exploitation, business impact of compromised business data, presence, or void of security countermeasures, and much more.  Figure 1.6 shows some of the components enveloped within a threat. Threat Modeling Overview Threat Anatomy Threat Modeling Overview Threat Anatomy  Most private or commercial organizations do not have an attacker profile database; however, government or military IT operations may find this worthwhile in order to predict attack patterns based on commonalities in attack patterns.  Banks and financial institutions may also find this essential.  Threat classes are preventive in the sense that they help classify types of threats from any security control that provides both alerting and logging of actions taken against a system.  Threat classes help to create “bins” for organizing attack data into decipherable forms of attack. Injection attacks, elevation of privilege attempts, and DoS attacks all become organized into appropriate classes for analysis and reporting.  Coupled with external threat feeds, any organization has the ability to prioritize concretely their security controls. Threat Modeling Overview Threat Anatomy Brief Introduction to Threat Classification Models  Some threat classification models include STRIDE and DREAD – two Microsoft-originated threat classification models focused on identifying business impact and risk, in varying degrees  The Web Application Security Consortium (WASC) periodically revises its threat classification, which is a great technical reference for grouping various types of threats by their technical nature in lieu of any business impact or risk model.  The WASC’s listing is more of a technical briefing of the latest web application-related threats, and less of a threat classification model. Threat Modeling Overview Threat Anatomy Brief Introduction to Threat Classification Models  The Open Web Application Security Project (OWASP), which also releases a top ten list of threats aimed at web applications. The OWASP top ten listing is updated every few years and reflects the most prevalent threats to web applications and is an excellent start for a technical-based threat class model.  Several threat models may also be built with the help of product-based security solutions from both open source and commercial grade products today.  Many network- and host-based solutions have threat intelligence modules or feeds. Threat Modeling Overview Threat Anatomy  Figure 1.7 provides a visual synopsis of how threat classes can organize a laundry list of attacks and vulnerabilities. This simplified figure depicts how threat classes cannot only encompass elements of the threat, such as attacks and vulnerabilities, but also the countermeasures or controls that mitigate their associated risks. Threat Modeling Overview Threat Anatomy Vulnerabilities – The Never-Ending Race  Dissecting any given threat reveals a number of vulnerabilities that serve as windows of opportunity.  Hackers and cybercriminals value their time as much as anyone else does, and if no clear vulnerabilities in process or technical controls are present, it is very likely that they will threaten other information doorways.  The evolution of vulnerabilities has migrated in overwhelming numbers from platforms to applications, making vulnerability management exponentially more difficult to track and manage simply due to the sheer number of applications that are present across enterprises.  As a result, threat modeling is a bit more complex, needing a more extensive and up-to-date vulnerability listing. Threat Modeling Overview Threat Anatomy  The Figure 1.8 shows the following suggested workflow reveals the necessary steps needed to leverage vulnerability data within an application threat model. Threat Modeling Overview Threat Anatomy  Apart from product-based security solutions that specialize in vulnerability scanning, multiple external data sources help any security operations group to build a “living” vulnerability database that can be used and correlated to an asset inventory of both platforms and software.  The National Institute of Standards (NIST) also provides a National Vulnerability Database (NVD) that includes a free listing of up-to- date vulnerabilities across multiple platforms.  NIST’s site lists all vulnerabilities by their Common Vulnerability and Exposures (CVE) reference, which is a useful data identifier that allows for some interoperability among security products and solutions. Threat Modeling Overview The hypothetical example aims to dissect a particular threat to the level of isolating related vulnerabilities that should be encompassed within the threat model.  GIVEN: Employees use the MiFARE Classic Smart Card to gain access to various control rooms where power distribution is controlled and managed. The data that it stores and transmits to physical receivers is related to authorized personnel.  THREAT OBJECTIVE: Gain illegitimate access to one of these control rooms by leveraging a legitimate key code from a Smart Card.  ATTACK VECTOR: Wireless transmission of Smart Card over the air broadcasts.  VULNERABILITY: The card uses a weak cryptographic scheme for encrypting data over the air (OTA). As a result, data-transmitted OTA can be intercepted and cracked.  ATTACK: An off-the-shelf reader can be used to query or probe the card for its information. Vulnerabilities in smart card Threat Modeling Overview In the single vulnerability mapping that is accomplished in Figure 1.9 Threat Modeling Overview Threat Anatomy Attacks  Attacks are difficult to predict and understand uniquely. This takes us back to the motive discussion – something rarely addressed in information security and honestly not a traditional component to most threat models, although it does have a parent component to identify attack motives at the root node of an attack tree.  Some governments are investing in such efforts to thwart possible attacks before they happen, recognizing that their adversaries are in the planning stages and waiting for an opportunity or particular data. Threat Modeling Overview Threat Anatomy  Counter-hacking units have been developed in Great Britain to detect and counteract threats from Russia and China as well as many other countries.  Great Britain’s MI5 (Military Intelligence Group, Section 5), as well as the Singapore Intelligence Agency, have established counter-hacking units that are responsible for such efforts.  Profiling attackers helps to derive plausible attack vectors that could be sought to achieve such motives. Threat Modeling Overview Threat Anatomy Identifying Attacks  Attacks carry out threats, while threats are driven by motives. Digressing into application-based attacks within a threat model will encompass a greater deal of structure and formality.  Once all possible application threats are clearly understood, an attack tree encompasses all of an attack’s characteristics, as depicted in Table 1.7. Threat Modeling Overview  Threat Modeling Overview Threat Anatomy  As shown in Figure 1.10, not all attack vectors introduce exploitable technical vulnerabilities.  Some of the attacks take advantage of process-related weaknesses that are very difficult to mitigate, therefore making them more attractive to attackers.  For example, a vishing attack is a technical threat introduced via an e- mail that lists a phone number for the target user to call. The exploit is deceitful messaging and the vulnerability is a trusting reader.  Note: vishing- voice phishing PII- Personal Identifiable Information, VRU – Voice Response Unit Threat Modeling Overview Threat Anatomy Threat Modeling Overview Crowdsourcing Risk Analytics  Threat modeling provides the opportunity to reshape all of these inefficiencies. From a process standpoint, many groups benefit from threat modeling efforts as they receive valuable insight into risk factors associated with any application environment.  Process-wise, threat modeling fosters a high degree of collaboration across the following groups: Developers QA Engineers Governance Leaders Project Managers Business Analysts System Administrators Security Operations Network Engineers Risk Management Security/IT Architects Threat Modeling Overview Crowdsourcing Risk Analytics QA Engineers  Quality assurance efforts test functionality using test scripts and manual methods. QA engineers or analysts have a pivotal role in identifying bugs within their test cases.  They test newly developed features and functions from the development team and are theoretically awarded the ability to accept or reject new builds depending on the outcome of their test cases. Threat Modeling Overview Threat Modeling Overview Crowdsourcing Risk Analytics Threat Modeling Overview Crowdsourcing Risk Analytics