Module 6 Secure Software Development PDF

BS IN INFORMATION TECHNOLOGY BS IN COMPUTER SCIENCE FLEX Course Material At the end of the lesson(s), students must be able to: Identify secure software design principles. Identify issues and common errors made by...

BS IN INFORMATION TECHNOLOGY BS IN COMPUTER SCIENCE FLEX Course Material At the end of the lesson(s), students must be able to: Identify secure software design principles. Identify issues and common errors made by developers. Assurance and Describe the importance of code Security review and threat modeling. Identify methodologies in code review and threat modeling. Secure Software Development Perform simple threat modeling. SECURITY AND SYSTEM ADMINISTRATION CLUSTER College of Computing and Information Technologies  FOCAL POINTS The system development life cycle is the overall process of developing, implementing, and retiring information systems through a multistep process from initiation, analysis, design, implementation, and maintenance to disposal. There are many different SDLC models and methodologies, but each generally consists of a series of defined steps or phases. For any SDLC model that is used, information security must be integrated into the SDLC to ensure appropriate protection for the information that the system will transmit, process, and store. Code review aims to identify security flaws in the application related to its features and design, along with the exact root causes. Threat modeling is an in-depth approach for analyzing the security of an application. It is a structured approach that enables employees to identify, quantify, and address the security risks associated with an application. Threat modeling is not an approach to reviewing code, but it complements the secure code review process by providing context and risk analysis of the application. Lesson 1 P4 Principles of Secure Software Development ? Lesson 2 P14 Overview of Code Review Lesson 3 P22 Overview of Threat Modeling INSIDE #1 Principles of Secure Software Development Understanding Secure Software Development System Development Life Cycle The system development life cycle is the overall process of developing, implementing, and retiring information systems through a multistep process from initiation, analysis, design, implementation, and maintenance to disposal. There are many different SDLC models and methodologies, but each generally consists of a series of defined steps or phases. For any SDLC model that is used, information security must be integrated into the SDLC to ensure appropriate protection for the information that the system will transmit, process, and store. Applying the risk management process to system development enables organizations to balance requirements for the protection of agency information and assets with the cost of security controls and mitigation strategies throughout the SDLC. Risk management processes identify critical assets and operations, as well as systemic vulnerabilities across the organization. Risks are often shared throughout the organization and are not specific to certain system architectures. Some of the benefits of integrating security into the system development life cycle include: ❑ Early identification and mitigation of security vulnerabilities and problems with the configuration of systems, resulting in lower costs to implement security controls and mitigation of vulnerabilities; ❑ Awareness of potential engineering challenges caused by mandatory security controls; ❑ Identification of shared security services and reuse of security strategies and tools that will reduce development costs and improve the system’s security posture through the application of proven methods and techniques; ❑ Facilitation of informed executive decision making through the application of a comprehensive risk management process in a timely manner; ❑ Documentation of important security decisions made during the development process to inform management about security considerations during all phases of development; ❑ Improved organization and customer confidence to facilitate adoption and use of systems, and improved confidence in the continued investment in government systems; and ❑ Improved systems interoperability and integration that would be difficult to achieve if security is considered separately at various system levels. 4 Initiation Phase. During the initiation phase, the organization establishes the need for a system and documents its purpose. Security planning should begin in the initiation phase with the identification of key security roles to be carried out in the development of the system. The information to be processed, transmitted, or stored is evaluated for security requirements, and all stakeholders should have a common understanding of the security considerations. The Information System Security Officer (ISSO) should be identified as well. Security considerations are key to the early integration of security, and to the assurance that threats, requirements, and potential constraints in functionality and integration are considered. Requirements for the confidentiality, integrity, and availability of information should be assessed at this stage. Federal agencies should apply the provisions of Federal Information Processing Standard (FIPS) 199, Standards for Security Categorization of Federal Information and Information Systems, and FIPS 200, Minimum Security Requirements for Federal Information and Information Systems. These standards require agencies to categorize their information systems as low-impact, moderate-impact, or high- impact for the security objectives of confidentiality, integrity, and availability and to select appropriate security controls. Any information privacy requirements should be determined as well. Early planning and awareness will result in savings in costs and staff time through proper risk management planning. In this phase, the organization clearly defines its project goals and high-level information security requirements, as well as the enterprise security system architecture. 5 Development/Acquisition Phase. During this phase, the system is designed, purchased, programmed, developed, or otherwise constructed. A key security activity in this phase is conducting a risk assessment and using the results to supplement the baseline security controls. In addition, the organization should analyze security requirements; perform functional and security testing; prepare initial documents for system certification and accreditation; and design the security architecture. Another essential element is the development of security plans, which establish the security requirements for the information system, describe security controls that have been selected, and present the rationale for security categorization, how controls are implemented, and how use of systems can be restricted in high-risk situations. Security plans document the decisions made in the selection of controls and are approved by authorized officials. The developmental testing of the technical and security features and functions of the system ensure that they perform as intended, prior to launching the implementation and integration phase. Implementation Phase. In the implementation phase, the organization configures and enables system security features, tests the functionality of these features, installs or implements the system, and obtains a formal authorization to operate the system. Design reviews and system tests should be performed before placing the system into operation to ensure that it meets all required security specifications. In addition, if new controls are added to the application or the support system, additional acceptance tests of those new controls must be performed. This approach ensures that new controls meet security specifications and do not conflict with or invalidate existing controls. The results of the design reviews and system tests should be fully documented, updated as new reviews or tests are performed and maintained in the organization’s official records.. Operations/Maintenance Phase. In this phase, systems and products are in place and operating, enhancements and/or modifications to the system are developed and tested, and hardware and software components are added or replaced. The organization should continuously monitor performance of the system to ensure that it is consistent with pre-established user and security requirements, and that needed system modifications are incorporated. Configuration management (CM) and control activities should be conducted to document any proposed or actual changes in the security plan of the system. Information systems are in a constant state of evolution with upgrades to hardware, software, firmware, and possible modifications in the surrounding environment. Documenting information system changes and assessing the potential impact of these changes on the security of a system are essential activities to assure continuous monitoring and prevent lapses in the system security accreditation. Disposal Phase. In this phase, plans are developed for discarding system information, hardware, and software and making the transition to a new system. The information, hardware, and software may be moved to another system, archived, discarded, or destroyed. If performed improperly, the disposal phase can result in the unauthorized disclosure of sensitive data. When archiving information, organizations should consider the need for and the methods for future retrieval. The disposal activities ensure the orderly termination of the system and preserve the vital information about the system so that some or all of the information may be reactivated in the future, if necessary. Particular emphasis is given to proper preservation of the data processed by the system so that the data is effectively migrated to another system or archived in accordance with applicable records management regulations and policies for potential future access. The removal of information from a storage medium, such as a hard disk or tape, should be done in accordance with the organization’s security requirements 6 Secure Software Development Life Cycle Implementing SDLC security affects every phase of the software development process. It requires a mindset that is focused on secure delivery, raising issues in the requirements and development phases as they are discovered. This is far more efficient—and much cheaper—than waiting for these security issues to manifest in the deployed application. Secure software development life cycle processes incorporate security as a component of every phase of the SDLC. While building security into every phase of the SDLC is first and foremost a mindset that everyone needs to bring to the table, security considerations and associated tasks will vary significantly by SDLC phase. Phase 1: Requirements In this early phase, requirements for new features are collected from various stakeholders. It’s important to identify any security considerations for functional requirements being gathered for the new release. ✓ Sample functional requirement: user needs the ability to verify their contact information before they can renew their membership. ✓ Sample security consideration: users should be able to see only their own contact information and no one else’s. 7 Phase 2: Design This phase translates in-scope requirements into a plan of what this should look like in the actual application. Here, functional requirements typically describe what should happen, while security requirements usually focus on what shouldn’t. ✓ Sample functional design: page should retrieve the user’s name, email, phone, and address from CUSTOMER_INFO table in the database and display it on screen. ✓ Sample security concern: we must verify that the user has a valid session token before retrieving information from the database. If absent, the user should be redirected to the login page. Phase 3: Development When it’s time to implement the design and make it a reality, concerns usually shift to making sure the code well-written from the security perspective. There are usually established secure coding guidelines as well as code reviews that double-check that these guidelines have been followed correctly. These code reviews can be either manual or automated using technologies such as static application security testing (SAST). That said, modern application developers can’t be concerned only with the code they write, because most modern applications aren’t written from scratch. Instead, developers rely on existing functionality, usually provided by free open-source components to deliver new features and therefore value to the organization as quickly as possible. In fact, 90%+ of modern deployed applications are made of these open-source components. Phase 4: Verification The Verification phase is where applications go through a thorough testing cycle to ensure they meet the original design & requirements. This is also a great place to introduce automated security testing using various technologies. The application is not deployed unless these tests pass. This phase often includes automated tools like CI/CD pipelines to control verification and release. Verification at this phase may include: ▪ Automated tests that express the critical paths of your application ▪ Automated execution of application unit tests that verify the correctness of the underlying application ▪ Automated deployment tools that dynamically swap in application secrets to be used in a production environment Phase 5: Maintenance and Evolution The story doesn’t end once the application is released. In fact, vulnerabilities that slipped through the cracks may be found in the application long after it’s been released. These vulnerabilities may be in the code developers wrote but are increasingly found in the underlying open-source components that comprise an application. This leads to an increase in the number of “zero-days”—previously unknown vulnerabilities that are discovered in production by the application’s maintainers. These vulnerabilities then need to be patched by the development team, a process that may in some cases require significant rewrites of application functionality. Vulnerabilities at this stage may also come from other sources, such as external penetration tests conducted by ethical hackers or submissions from the public through what’s known as “bug bounty” programs. Addressing these types of production issues must be planned for and accommodated in future releases. 8 Secure Software Design Principles Good software development results in secure products that meet all design specifications. Some common place security principles includes: Keep design simple and small Access decisions by permission not exclusion Every access to every object checked for authority Design depends on possession of keys/passwords Protection mechanisms require two keys to unlock Programs/users utilize only necessary privileges Minimize mechanisms common to multiple users Human interface must be easy to use so users routinely/automatically use protection mechanisms Software Development Security Problems Some software development failures and errors result in software that is difficult or impossible to deploy in a secure fashion. The most common of these failures have been identified as “deadly sins in software security.” ▪ Buffer Overruns. Buffers are used to manage mismatches in the processing rates between two entities involved in a communication process. During a buffer overrun, an attacker can make the target system execute instructions or take advantage of some other unintended consequence of the failure. Sometimes this is limited to a DoS attack. In any case, data on the attacked system loses integrity. ▪ Command Injection. The problem of command injection is caused by a developer’s failure to ensure that command input is validated before it is used in the program. ▪ Cross-Site Scripting (XSS) Cross-site scripting allows the attacker to acquire valuable information, such as account credentials, account numbers, or other critical data. Often an attacker encodes a malicious link and places it in the target server, making it look less suspicious. ▪ Failure to Handle Errors.What happens when a system or application encounters a scenario that it is not prepared to handle? Does it attempt to complete the operation (reading or writing data or performing calculations)? Does it issue a cryptic message that only a programmer could understand? Or does it simply stop functioning? Failure to handle errors can cause a variety of unexpected system behaviors. Programmers are expected to anticipate problems and prepare their application code to handle them. Y ▪ Failure to Protect Network Traffic. With the growing popularity of wireless networking comes a corresponding increase in the risk that wirelessly transmitted data will be intercepted. Most wireless networks are installed and operated with little or no protection for the information that is broadcast between the client and the network wireless access point. This is especially true of public networks found in coffee shops, bookstores, and hotels. Without appropriate encryption such as that afforded by WPA, attackers can intercept and view your data. ▪ Failure to Store and Protect Data Securely. Storing and protecting data securely is a large enough issue to be the core subject of this entire text. Programmers are responsible for integrating access controls into programs and keeping secret information out of them. Access controls, the subject of later chapters, regulate who, what, when, where, and how users and systems interact with data. Failure to properly implement sufficiently strong access controls makes the data vulnerable. Overly strict access controls hinder business users in the performance of their duties, and as a result the controls may be administratively removed or bypassed. The integration of secret information—such as the “hard coding” of passwords, encryption keys, or other sensitive information—can put that information at risk of disclosure. ▪ Failure to Use Cryptographically Strong Random Numbers. Most modern cryptosystems, like many other computer systems, use random number generators. However, a decision support system that uses random and pseudorandom numbers for MonteCarlo method forecasting does not require the same degree of rigor and the same need for true randomness as a system that seeks to implement cryptographic procedures. These “random” number generators use a mathematical algorithm based on a seed value and another system component (such as the computer clock) to simulate a random number. Those who understand the workings of such a “random” number generator can predict particular values at particular times. ▪ Format String Problems. Computer languages often are equipped with built-in capabilities to reformat data while they output it. The formatting instructions are usually written as a “format string.” Unfortunately, some programmers may use data from untrusted sources as a format string. An attacker may embed characters that are meaningful as formatting directives (such as %x, %d, %p, etc.) into malicious input. ▪ Neglecting Change Control. Developers use a process known as change control to ensure that the working system delivered to users represents the intent of the developers. Early in the development process, change control ensures that developers do not work at cross purposes by altering the same programs or parts of programs at the same time. Once the system is in production, change control processes ensure that only authorized changes are introduced and that all changes are adequately tested before being released. 10 ▪ Improper File Access. If an attacker changes the expected location of a file by intercepting and modifying a program code call, the attacker can force a program to use files other than the ones it is supposed to use. This type of attack could be used either to substitute a bogus file for a legitimate file (as in password files) or trick the system into running a malware executable. The potential for damage or disclosure is great, so it is critical to protect not only the location of the files but the method and communications channels by which these files are accessed. ▪ Improper Use of SSL. Programmers use Secure Sockets Layer (SSL) to transfer sensitive data, such as credit card numbers and other personal information, between a client and server. While most programmers assume that using SSL guarantees security, they often mishandle this technology. SSL and its successor, Transport Layer Security (TLS), both need certificate validation to be truly secure. Failure to use Hypertext Transfer Protocol Secure (HTTPS) to validate the certificate authority and then the certificate itself, or failure to validate the information against a certificate revocation list (CRL), can compromise the security of SSL traffic. ▪ Information Leakage. One of the most common methods of obtaining inside and classified information is directly or indirectly from one person, usually an employee. ▪ Integer Bugs (Overflows/Underflows). Although mathematical calculation theoretically can deal with numbers that contain an arbitrary number of digits, the binary representations used by computers are of a particular fixed length. The programmer must anticipate the size of the numbers to be calculated in any given part of the program. An integer bug can result when a programmer does not validate the inputs to a calculation to verify that the integers are of the expected size. ▪ Race Conditions. A race condition is a failure of a program that occurs when an unexpected ordering of events in its execution results in a conflict over access to the same system resource. This conflict does not need to involve streams of code inside the program because current operating systems and processor technology automatically break a program into multiple threads that can be executed simultaneously. If the threads that result from this process share any resources, they may interfere with each other. ▪ SQL Injection. SQL injection occurs when developers fail to properly validate user input before using it to query a relational database. ▪ Trusting Network Address Resolution The DNS is a function of the World Wide Web that converts a URL like www.course.com into the IP address of the Web server host. This distributed model is vulnerable to attack or “poisoning.” DNS cache poisoning involves compromising a DNS server and then changing the valid IP address associated with a domain name into one the attacker chooses, usually a fake Web site designed to obtain personal information. 11 ▪ Unauthenticated Key Exchange One of the biggest challenges in private key systems, which involve two users sharing the same key, is securely getting the key to the other party. Sometimes an “out of band” courier is used, but at other times a public key system, which uses both a public and private key, is used to exchange the key. However, an unauthorized person might receive a key that was copied onto a USB device and shipped. This person might not work for the company, but was simply expecting the delivery and intercepted it. The same scenario can occur on the Internet, where an attacker writes a variant of a public key system and makes it available as “freeware,” or corrupts or intercepts the function of someone else’s public key encryption system, perhaps by posing as a public key repository. ▪ Use of Magic URLs and Hidden Forms HTTP is a stateless protocol in which computer programs on either end of the communication channel cannot rely on a guaranteed delivery of any message. This makes it difficult for software developers to track a user’s exchanges with a Web site over multiple interactions. ▪ Use of Weak Password-Based Systems Failure to require sufficient password strength and to control incorrect password entry is a serious security issue. Password policy can specify the acceptable number and type of characters, the frequency of mandatory changes, and even the reusability of old passwords. Similarly, a system administrator can regulate the permitted number of incorrect password entries that are submitted and further improve the level of protection. Systems that do not validate passwords, or that store passwords in easily accessible locations, are ripe for attack. ▪ Poor Usability Employees prefer doing things the easy way. When faced with an “official way” of performing a task and an “unofficial way”—which is easier—they prefer the latter. The best solution to address this issue is to provide only one way—the secure way! Integrating security and usability, adding training and awareness, and ensuring solid controls all contribute to the security of information. Allowing users to choose easier solutions by default will inevitably lead to loss. 12 #2 Overview of Code Review Understanding Principles of Code Review Introduction Code review aims to identify security flaws in the application related to its features and design, along with the exact root causes. With the increasing complexity of applications and the advent of new technologies, the traditional way of testing may fail to detect all the security flaws present in the applications. One must understand the code of the application, external components, and configurations to have a better chance of finding the flaws. Such a deep dive into the application code also helps in determining exact mitigation techniques that can be used to avert the security flaws. It is the process of auditing the source code of an application to verify that the proper security and logical controls are present, that they work as intended, and that they have been invoked in the right places. Code review is a way of helping ensure that the application has been developed to be “self-defending” in its given environment. Secure code review allows a company to assure application developers are following secure development techniques. A general rule of thumb is that a penetration test should not discover any additional application vulnerabilities relating to the developed code after the application has undergone a proper security code review. At the least very few issues should be discovered. All security code reviews are a combination of human effort and technology support. At one end of the spectrum is an inexperienced person with a text editor. At the other end of the scale is an expert security team with advanced static analysis (SAST) tools. Unfortunately, it takes a serious level of expertise to use the current application security tools effectively. They also don’t understand dynamic data flow or business logic. SAST tools are great for coverage and setting a minimum baseline. Tools can be used to perform this task, but they always need human verification. They do not understand context, which is the keystone of security code review. Tools are good at assessing large amounts of code and pointing out possible issues, but a person needs to verify every result to determine if it is a real issue, if it is exploitable, and calculate the risk to the enterprise. Human reviewers are also necessary to fill in for the significant blind spots, which automated tools, simply cannot check. 14 Code Review versus Secure Source Code Review A secure source code review is an enhancement model for the standard source code review process. In contrast with source code reviews, the service model eyes on security considerations and standards. It adequately covers all security-related risks present in the codebase, ensuring an accurate context to the reviewers. A source code review focuses on code quality, consistency, maintainability and performance. On the other hand, a secure code review service assures the most required security aspect as a sign of maturity for your application. Code Reviews and Regulatory Compliance Many organizations with responsibility for safeguarding the integrity, confidentiality and availability of their software and data need to meet regulatory compliance. This compliance is usually mandatory rather than a voluntary step taken by the organization. Compliance regulations include: ▪ PCI (Payment Card Industry) standards ▪ Central bank regulations ▪ Auditing objectives ▪ HIPPA Code Review Do’s And Dont’s This list is not comprehensive but a suggestion starting point for an enterprise to make sure code reviews are effective and not disruptive and a source of discourse. If code reviews become a source of discourse within an organization the effectives of finding security, functional bugs will decline, and developers will find a way around the process. Being a good code reviewer requires good social skills and is a skill that requires practice just like learning to code. ▪ You don’t have to find fault in the code to do a code review. If you always fine something to criticize your comments will lose credibility. ▪ Do not rush a code review. Finding security and functionality bugs is important but other developers or team members are waiting on you, so you need to temper your do not rush with the proper amount urgency. ▪ When reviewing code, you need to know what is expected. Are you reviewing for security, functionality, maintainability, and/or style? Does your organization have tools and documents on code style or are you using your own coding style? Does your organization give tools to developers to mark unacceptable coding standards per the organizations own coding standards? ▪ Before beginning a code review does your organization have a defined way to resolve any conflicts that may come up in the code review by the developer and code reviewer? ▪ Does the code reviewer have a define set of artifacts that need to be produce as the result of the code review? ▪ What is the process of the code review when code during the code review needs to be changed? ▪ Is the code reviewer knowledgeable about the domain knowledge of the code that is being reviewed? Ample evidence abounds that code reviews are most effective if the code reviewer is knowledgeable about the domain of the code ex. Compliance regularizations for industry and government, business functionality, risks, etc. 15 Understanding Secure Code Review Methodology The methodology for securing a healthy code standard and eradicating potential threats relies on expert security professionals involved in the process. It requires experts to evaluate, identify and prioritize software vulnerabilities detected in the testing phase of the review process. Phase 1: Business Requirement and Functional Content Business requirements are the critical activities of an enterprise that must be performed to meet the organizational objective(s) while remaining solution independent. Functional requirements are very detailed and provide information on how business needs and goals will be delivered through a specific project. Below are the steps in this phase: ▪ Design Risk Analysis ▪ User Risk Analysis ▪ Architecture Risk Analysis 16 Application Features and Business Rules The reviewer should understand all the features currently provided by the application and capture all the business restrictions/rules related to them. There is also a case for being mindful of potential future functionality that might be on the roadmap for an application, thereby future-proofing the security decisions made during current code reviews. What are the consequences of this system failing? Shall the enterprise be affected in any great way if the application cannot perform its functions as intended? Context - All security is in context of what we are trying to secure. Recommending military standard security mechanisms on an application that vends apples would be overkill and out of context. What type of data is being manipulated or processed, and what would the damage to the company be if this data was compromised? Context is the “Holy Grail” of secure code inspection and risk assessment. Sensitive Data - The reviewer should also make a note of the data entities like account numbers and passwords that are sensitive to the application. The categorizing the data entities based on their sensitivity will help the reviewer to determine the impact of any kind of data loss in the application. User Roles and Access Rights - It is important to understand the type of users allowed to access the application. Is it externally facing or internal to “trusted” users? Generally, an application that is accessible only for the internal users of an organization might be exposed to threats that are different than the one that is available for anyone on the Internet. Hence, knowing the users of the application and its deployed environment would allow the reviewer to realize the threat agents correctly. In addition to this, the different privileges levels present in the application must also be understood. It would help the reviewer to enumerate different security violations/privilege escalation attacks that can be applicable to the application. Application Type - This refers to understanding whether the application is browser-based application, a desktop based standalone application, a web-service, a mobile applications or a hybrid application. Different type of application faces different kinds of security threats and understanding the type of the application would help the reviewer to look for specific security flaws, determine correct threats agents and highlight necessary controls suitable to the application. Code - The language(s) used, the features and issues of that language from a security perspective. The issues a programmer needs to look out for and language best practices from a security and performance perspective. Design - Generally, web applications have a well-defined code layout if they are developed using MVC design principle. Applications can have their own custom design, or they may use some well- known design frameworks like Struts/Spring etc. Where are the application properties/configuration parameters stored? How is the business class identified for any feature/URL? What types of classes get executed for any processing any request? (e.g., centralized controller, command classes, view pages etc.) How is the view rendered to the users for any request? Company Standards and Guidelines - Many companies will have standards and guidelines dictated by management. This is how the management (ultimately responsible for the organizations information security) control what levels of security are applied to various functions, and how they should be applied. For example, if the company has a Secure Coding Guidelines document, reviewers should know and understand the guidelines and apply them during the code review. 17 Collecting all the required information of the proposed design including flow charts, sequence diagrams, class diagrams and requirements documents to understand the objective of the proposed design. The design is thoroughly studied mainly with respect to the data flow, different application component interactions and data handling. This is achieved through manual analysis and discussions with the design or technical architect’s team. The design and the architecture of the application must be understood thoroughly to analyze vulnerable areas that can lead to security breaches in the application. Illustration below highlights some questions that can be asked of the architecture and design to aid secure code reviews. After understanding the design, the next phase is to analyze the threats to the design. This involves observing the design from an attacker’s perspective and uncovering the backdoors and insecure areas present in it. 18 Phase 2: Conduct Threat Assessment Static code analysis commonly refers to running static code analysis tools that attempt to highlight possible vulnerabilities within the ‘static’ (non-running) source code. Ideally static code analysis tools would automatically find security flaws with few false positives. That means it should have a high degree of confidence that the bugs that it finds are real flaws. However, this ideal is beyond the state of the art for many types of application security flaws. Thus, such tools frequently serve as aids for an analyst to help them zero in on security relevant portions of code so they can find flaws more efficiently, rather than a tool that finds all flaws automatically. Bugs may exist in the application due to insecure code, design or configuration. Automated analysis can be carried on the application code to identify bugs through either of the following two options: 1. Static code scanner scripts based on a pattern search (in-house and open source). 2. Static code analyzers (commercial and open source). 1Y Phase 4: Prepare Executive Summary and Detailed Report An executive summary that provides a high-level view of vulnerabilities detected and even provides a security “score,” and a more detailed report that pinpoints which line of code looks troublesome and the vulnerability that was detected. Code Review Reports A standard report template will provide enough information to enable the code reviewer to classify and prioritize the software vulnerabilities based on the applications threat model. This report does not need to be pages in length, it can be document based or incorporated into many automated code review tools. A report should provide the following information: ▪ Date of review. ▪ Application name, code modules reviewed. ▪ Developers and code reviewer names. ▪ Task or feature name, (TFS, GIT, Subversion, trouble ticket, etc.). ▪ A brief sentence(s) to classify and prioritize software vulnerability if any and what if any remedial tasks need to be accomplished or follow up is needed. ▪ Link to documents related to task/feature, including requirements, design, testing and threat modeling documents. ▪ Code Review checklist if used, or link to organization Code Review Checklist. (see Appendix A) ▪ Testing the developer has carried out on the code. Preferably the unit or automated tests themselves can be part of the review submission. ▪ If any tools such as FxCop, BinScope Binary Analyzer, etc. were used prior to code review. 20 #3 Overview of Threat Modeling Understanding Threat Modeling Introduction Threat modeling is an in-depth approach for analyzing the security of an application. It is a structured approach that enables employees to identify, quantify, and address the security risks associated with an application. Threat modeling is not an approach to reviewing code, but it complements the secure code review process by providing context and risk analysis of the application. Images Retrieved from https://www.eccouncil.org/threat-modeling/ When source code analysis is performed outside the Secure-SDLC, such as on existing applications, the results of the threat modeling help in reducing the complexity of the source code analysis by promoting a risk-based approach. Instead of reviewing all source code with equal focus, a reviewer can prioritize the security code review of components whose threat modeling has ranked with high-risk threats. 22 Threat Modeling Methodologies While adopting a threat modeling methodology, it is equally important to understand the difference in the approach, process, and objectives. There are several cyber threat modeling methodologies used to improve cybersecurity and threat intelligence practices. To ensure that the threat intelligence is actionable, information security professionals or cyber threat intelligence analysts must decipher which method aligns with their specific business goals and objectives. Here are some of the six most common threat modeling methodologies that are used to access and prioritize threats to your IT assets: STRIDE is an approach to threat modeling developed by Loren Kohnfelder and Praerit Garg in 1999 to identify potential vulnerabilities and threats to your products. STRIDE is a mnemonic for a set of threats – Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service (DoS), and Elevation of Privilege as described in the table below. Images Retrieved from https://www.eccouncil.org/threat-modeling/ 23 PASTA is a seven-step methodology to create a process for simulating attacks to IT applications, analyzing the threats, their origin, the risks they pose to an organization, and how to mitigate them. The objective of this model is to identify the threat, enumerate them, and assign a score. By following this method, the organization can determine the appropriate countermeasures that must be deployed to mitigate the risk. TRIKE is an open-source threat modeling methodology that is used when security auditing from a risk management perspective. TRIKE threat modeling is a fusion of two models namely – Requirement Model and Implementations Model. The requirement model is the base of TRIKE modeling that explains the security characteristics of an IT system and assigns acceptable levels of risk to each asset. This model also enables coordination among different security teams and stakeholders by providing a conceptual framework. After this comes the implementation model. In this model, a Data Flow Diagram (DFD) is created to illustrate the flow of data and the user performed actions within a system. In this model, threats are analyzed to enumerate and assign a risk value. Based on this, security controls or preventive measures defined to address the threats as per the priority and assigned risks. Images Retrieved from https://www.eccouncil.org/threat-modeling/ 24 VAST (Visual, Agile, and Simple Threat) methodology is based on automated threat modeling that covers the software development life cycle across the organization with proper integration with tools and collaboration with all key stakeholders like developers, architects, security professionals, and leaders across the organization. DREAD methodology is used to assess, analyze, and find the probability of risk by rating the threats as described in the image below. Images Retrieved from https://www.eccouncil.org/threat-modeling/ 25 OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) is an approach to identify, assess, and manage risks to IT assets. This process identifies the critical components of information security and the threats that could affect their confidentiality, integrity, and availability. This helps them understand what information is at risk and design a protection strategy to reduce or eliminate the risks to IT assets. Images Retrieved from https://www.eccouncil.org/threat-modeling/ 26 When do You Threat Model? As a Developer Because the security landscape of an application is ever changing, as new threats are discovered every day, it is difficult to say that you are 100% covered from all the threats the first time through. Thus, threat modeling should initially be done as early as possible in the development life cycle, revisited any time there is a change to the system's architecture, and after any security incident or new vulnerabilities are introduced. As a Penetration Tester/Security Engineers Threat modeling helps to build the understanding of an application in depth without any prior knowledge of it. It helps a tester see how things really connect and communicate and where they can be exploited. Threat Modeling Tools Microsoft Threat Modeling Tool Microsoft’s Threat Modelling Tool is free and allows software architects to identify and mitigate most likely security issues at an early stage when they are comparatively easy and cost-effective to fix. Thus, reducing the total cost of development. OWASP Threat Dragon OWASP Threat Dragon is an open-source threat modeling tool (both web application and desktop) that is used to create threat model diagrams, record the most likely threats, and decide the action to mitigate said threats. Threat Dragon is both an online threat modeling web application and a desktop application. It includes system diagramming as well as a rule engine to auto-generate threats and their mitigations. 27 Threat Modeling Approach Threat modeling is an approach you can use to help you identify threats, attacks, vulnerabilities, and countermeasures that might be relevant to your application. The Threat Modeling activity helps you to recognize and identify the following: ▪ Your security objectives ▪ Relevant threats ▪ Relevant vulnerabilities and countermeasures Key Terms It helps to know the following terms when you are working through Threat Modeling: ▪ Threat. A threat is an undesired event or potential occurrence, often best described as an effect that could damage or compromise an asset or objective. It may or may not be malicious in nature. ▪ Attack (or exploit). An attack is an action taken that uses one or more vulnerabilities to realize a threat. This could be someone following through on a threat or exploiting a vulnerability. ▪ Vulnerability. A vulnerability is a weakness in some aspect or feature of a system that makes an attack possible. Vulnerabilities can exist at the network, host, or application level and include operational practices. ▪ Countermeasure. A countermeasure addresses a vulnerability to reduce the probability of attack or the impact of a threat. A countermeasure does not directly address a threat. Instead, it addresses the factors that define the threat. Countermeasures range from improving application design or improving code, to improving an operational practice. ▪ Asset. An asset is a resource that has value. It varies by perspective. To your business, an asset might be the availability of information or the information itself, such as customer data. It might be intangible, such as your company’s reputation. To an attacker, an asset could be the ability to misuse your application for unauthorized access to data or privileged operations. 28 Step 1: Identify Security Objectives Security objectives are goals and constraints related to the confidentiality, integrity, and availability of your data and application. They include: ▪ Confidentiality. This includes protecting against unauthorized information disclosure. ▪ Integrity. This includes preventing unauthorized information changes. ▪ Availability. This includes providing the required services even while under attack. To determine your security objectives, consider the following questions: ▪ What client data do you need to protect? For example, does your application use user accounts and passwords, customer account details including personalization information, financial history and transaction records, customer credit card numbers, bank details, or travel itineraries? ▪ Do you have compliance requirements? Compliance requirements may include security policy, privacy laws, regulations, and standards. ▪ Do you have specific quality of service requirements? Quality of service requirements include availability and performance requirements. ▪ Are there intangible assets that you need to protect? Intangible items include your company’s reputation, trade secrets, and intellectual property. The following are examples of some common security objectives: ▪ Prevent attackers from obtaining sensitive customer data, including passwords and profile information. ▪ Meet service-level agreements for application availability. ▪ Protect the company’s online business credibility. 2Y Step 2: Create an Application Overview Your goal is to identify your application’s key functionality, characteristics, and clients. To create an application overview: ▪ Draw the end-to-end deployment scenario. ▪ Identify roles. ▪ Identify key usage scenarios. ▪ Identify technologies. ▪ Identify application security mechanisms. Note Remember that threat modeling is an iterative process. Do not let this step block your progress. Identify as much detail as you can and then add more detail as your design evolves. Draw the End-to-End Deployment Scenario Use a whiteboard to draw the end-to-end deployment scenario. First, draw a rough diagram that describes the composition and structure of your application, its subsystems, and its deployment characteristics. Your deployment diagram should generally include the following: ▪ End-to-end deployment topology. Show the layout of the servers and indicate intranet, extranet, or Internet access. Start with logical network topologies, and then refine this to show physical topologies when you have those details. You can add or remove threats depending on your choice of specific physical topologies. ▪ Logical layers. Show where the presentation layer, business layer, and data access layers reside. Refine this to include physical server boundaries when you know them. ▪ Key components. Show the important components within each logical layer. Refine this to include actual process and component boundaries when you know them. ▪ Key services. Identify any important services. Show these as processes when you know them. ▪ Key services. Identify any important services. Show these as processes when you know them. ▪ Communication ports and protocols. Show which servers, components, and services communicate with each other and how they do it. Show the specifics of inbound and outbound information packages when you know them. ▪ Identities. Show the main identities used for the application and any relevant service accounts if you have this information. ▪ External dependencies. Show the dependencies that your application has on external systems. Later in the modeling process, this will help you identify vulnerabilities that can arise if any assumptions you make about the external systems are false or if the external systems change in any way. Identify Roles Identify your application’s roles: that is, identify who can do what within your application. What can your users do? What higher-privileged groups of users do you have? Use role identification to determine both what is supposed to happen and what is not supposed to happen. Identify Key Usage Scenarios What are the important features of your application? What does it do? Use your application’s use cases to derive this information. Identify the dominant application functionality and usage, and capture the Create, Read, Update, and Delete aspects. 30  Identify Technologies Where you can identify them, list the technologies and key features of the software and technologies that you use. Identify the following: ▪ Operating systems ▪ Web server software ▪ Database server software ▪ Technologies used in the presentation, business, and data access layers ▪ Development languages Identifying technologies helps you to focus on technology-specific threats later in the threat modeling activity. It also helps you determine the correct and most appropriate mitigation techniques. Identify Application Security Mechanisms The purpose of this effort is to identify interesting details and be able to add detail where necessary, or to identify where you might need to learn more. Identify any key points that you know about the following: ▪ Input and data validation ▪ Authentication ▪ Authorization ▪ Configuration management ▪ Sensitive data ▪ Session management ▪ Cryptography ▪ Parameter manipulation ▪ Exception management ▪ Auditing and logging Step 3: Decompose Your Application In this step, you break down your application to identify trust boundaries, data flows, entry points, and exit points. The more you know about the mechanics of your application, the easier it is to uncover threats and discover vulnerabilities. To decompose your application: ▪ Identify trust boundaries. ▪ Identify data flows. ▪ Identify entry points. ▪ Identify exit points. 31 Identify Trust Boundaries Identify your application’s trust boundaries to help focus your analysis on areas of concern. Trust boundaries indicate where trust levels change. You can think of trust from the perspective of confidentiality and integrity. To help identify trust boundaries: ▪ Start by identifying your outer system boundaries. ▪ Identify access control points or the key places where access requires additional privileges or role membership. ▪ Identify trust boundaries from a data flow perspective. For each subsystem, consider whether the upstream data flow or user input is trusted, and if it is not, consider how the data flow and input can be authenticated and authorized. Knowing which entry points exist between trust boundaries allows you to focus your threat identification on these key entry points. Identify Entry Points The entry points of your application also serve as entry points for attacks. Entry points can include the front-end Web application listening for HTTP requests. This entry point is intended to be exposed to clients. Other entry points, such as internal entry points exposed by subcomponents across the layers of your application, may exist only to support internal communication with other components. Consider the trust levels required to access an entry point and the type of functionality exposed by the entry point. Identify Exit Points Identify the points where your application sends data to the client or to external systems. Prioritize the exit points where your application writes data that includes client input or includes data from untrusted sources, such as shared databases. Identify Data Flows Trace your application’s data input through the application from entry to exit. You do this to understand how your application interacts with external systems and clients and how internal components interact. Pay particular attention to data flow across trust boundaries and how that data is validated at the trust boundary entry point. Also pay close attention to sensitive data items and how these flow through your system, where they are passed over a network, and where they are persisted. A good approach is to start at the highest level and then deconstruct the application by analyzing the data flow between individual subsystems. The Data Flow Diagram (DFD) should be made based on input from team members in an interactive threat modeling session. It is important to get input and cooperation from a wide range of team members, including technical/non-technical, developers/non-developers, testers, Product Owners, and any other people and roles with knowledge of the application. 32 Step 4: Identify Threats and Vulnerabilities In this step, you identify threats and attacks that might affect your application and compromise your security objectives. These threats are the bad effects that could happen to your application. You can use two basic approaches: ▪ Start with common threats and attacks. With this approach, you start with a list of common threats grouped by application vulnerability categories. Next, apply the threat list to your own application architecture. While doing this, use the data you gathered. ▪ Use a question-driven approach. A question-driven approach can help you identify relevant threats and attacks. The STRIDE categorization includes broad categories of threats, such as spoofing, tampering, repudiation, information disclosure, and denial of service. This is a goal- based approach, where you consider the goals of an attacker. While identifying threats, examine the application tier by tier, layer by layer, and feature by feature. By focusing on vulnerability categories, you focus on the areas where security mistakes are most frequently made. The threats identified at this stage do not necessarily indicate vulnerabilities. Identify potential threats and the actions that an attacker might try to use to exploit the application. During this step, you perform the following tasks: ▪ Identify common threats and attacks. ▪ Identify threats along use cases. ▪ Identify threats along data flows. Identify Common Threats and Attacks There are several common threats and attacks that rely on common vulnerabilities. As a starting point, create a cheat sheet of common threats and attacks, and you can build on it and modify from real usage, and you can socialize with experts to supplement your information. Identify Threats Along Use Cases Examine each of your application’s key use cases that you identified earlier and examine ways in which a user could maliciously or unintentionally coerce the application into performing an unauthorized operation or into disclosing sensitive or private data. Ask questions and try to think as an attacker would. Examples of the types of question you should ask include the following: ▪ How can a client inject malicious input here? ▪ Is data being written out based on user input or on non-validated user input? ▪ How could an attacker manipulate session data? ▪ How could an attacker obtain sensitive data as it is passed over the network? ▪ How could an attacker bypass your authorization checks? 33  Identify Threats Along Data Flows Review the key use cases and scenarios and analyze the data flows. Analyze the data flow between individual components in your architecture. Data flow across trust boundaries is particularly important. A piece of code should assume that any data from outside the code’s trust boundary is malicious. The code should perform thorough validation of the data. When identifying threats associated with data flows, ask the following questions: ▪ How does data flow from the front end to the back end of your application? ▪ Which components call which components? ▪ What does valid data look like? ▪ Where is validation performed? ▪ How is the data constrained? ▪ How is data validated against expected length, range, format, and type? ▪ What sensitive data is passed between components and across networks, and how is that data secured while in transit? As a next step, STRIDE threat modeling against each component (known as component-based STRIDE threat modeling) can be performed with two approaches: ▪ Think of potential threats per component, and assign a STRIDE threat type (i.e., assign Spoofing, or Tampering, etc.). ▪ Per component, think of Spoofing threats specifically, then Tampering threats, then Repudiation threats, etc. So, in order of STRIDE, go through the list and think of potential threats limited to the STRIDE threat type. OWASP Threat Type Security Property Explanation Target Vulnerability Spoofing is a type of threat whereby an attacker maliciously Processes impersonates (or pretends to be) a different user (or system). You External Spoofing Authentication A07:2021 can also use Spoofing more loosely during STRIDE threat Entities modeling to classify threats related to users and access rights. People Tampering is a type of threat whereby an attacker maliciously Data Stores A03:2021 Integrity/Access modifies data. You can also use Tampering more loosely during Tampering Data Flows A05:2021 Control STRIDE threat modeling to classify threats related to the security Processes A08:2021 of data. Repudiation relates to the ability to prove or disprove that an action or activity was performed by a specific user (or not). Repudiation Non-repudiation Process A09:2021 Repudiation is thus a type of threat whereby an attacker denies having performed a malicious action. Information Disclosure is a type of threat whereby the attacker Data Stores Information A02:2021 Confidentiality gains access to information that should be confidential or secret Data Flows Disclosure A05:2021 (and not available to an attacker). Processes Denial of Service is a type of threat whereby an attacker will Data Stores A02:2021 Denial-of- prevent a system (or application) from working for valid users. Availability Data Flows A05:2021 Service This is often achieved by overloading a system with fake requests Processes A06:2021 so that no time or resources remain for legitimate users. Elevation of Privilege is a type of threat whereby an attacker will elevate their current level of access privilege. This can include A01:2021 Elevation of Authorization/Least elevating access privileges where an attacker has no privileges at Process A02:2021 Privilege Privilege all (i.e., not a user) or elevating access privileges where an A05:2021 attacker already has ‘some’ privileges (i.e., a basic user). 34 Step 5: Rate and Prioritize Threats DREAD methodology is used to rate, compare and prioritize the severity of risk presented by each threat that is classified using STRIDE. To determine the ranking of a threat, the threat analyst must answer basic questions for each factor of risk. Images Retrieved from https://www.eccouncil.org/threat-modeling/ Step 6: Identify Countermeasures and Mitigations Once threats have been identified, compared and prioritized using threat modeling method it is time to define countermeasures to those threats. Note that countermeasures to threats can also be called security requirements or threat mitigations. When using STRIDE, the following threat-mitigation table can be used to identify techniques that can be employed to mitigate the threats. Threat Type Security Property Controls Spoofing Authentication Authentication Stores, Strong Authentication Mechanism Hashes, Digital Signatures, Access Control List Tampering Integrity/Access Control (ACLs)/Permissions Repudiation Non-repudiation Logging, Digital Signatures, Secure Time Stamps Access Control List (ACLs)/Permissions, Cryptography, Information Disclosure Confidentiality Encryption, Isolation Access Control List (ACLs)/Permissions, Filters, Quotas, Denial-of-Service Availability Redundancy, Failovers, QoS, Bandwidth Throttle Roles (RBAC, DACL, MAC), Privileges , Sudo, UAC, Input Elevation of Privilege Authorization/Least Privilege Validations 35  An Example to Threat Modeling Threat Model is usually a visual representation with documentation explaining each process and any threats associated with it. There are also options of how the threat might be fixed and a good threat model should also give a numerical value to the issues to help communicate the overall threat landscape of the project. Threat Modeling Activity Summary Steps Inputs Outputs Business Requirements Identify Security Objectives Security Policies Key Security Objectives Compliance Requirements Deployment Scenario Key Scenarios Deployment Diagrams Create An Application Overview Roles Use Cases Technologies Functional Specifications Application Security Mechanisms Trust Boundaries Entry Points Decompose Application Data Flow Diagram Exit Points Data Flows Common Threats and STRIDE Model (Component-based Identify Threats and Vulnerabilities Vulnerabilities Approach) Rate and Prioritize Threats Component-based Threats DREAD Model Identify Countermeasures and Component-based Threats Countermeasure List Mitigations The above table is meant to summarize the general tasks to be performed in this threat modeling example. 36 Identify Security Objectives The initial step in the threat modeling example is to gather as much background information as possible (which sounds obvious but is still worth mentioning). Potential information that may help in later threat modeling steps: ▪ Architectural diagrams and overviews of the proposed application design: Such architectural diagrams can provide threat modelers and team members with an understanding of key components within the design, technology used, communication flows, etc. ▪ Requirements of the solution: Requirements often contain the business and IT requirements that explain what the application must be capable of doing. The amount and quality of requirements may vary in quality from project to project. There may even be some security requirements that can help with the later STRIDE threat modeling steps. ▪ Project documentation: Project documentation will explain how the application will be built, who is involved, how long the project will take, etc. Pay attention to the inclusion of security as part of the project. This will indicate whether security is an integral part of the project (and thus resulting application), or whether it is a ‘forgotten’ quality. ▪ Team overview and governance: Understanding the key players in a project is very important. Pay attention to the security team members involved (i.e., security champions, security department representatives, etc.). Business Case Description Health care insurance provider, within the health care and Company and Industry insurance industry. Company is in the process of developing a new web application called ‘MyHealth’. It will allow customers to view their medical Solution Requirements data, billing, appointments with healthcare providers, and potential deals that customers can purchase. Compliance Requirements HIPAA Complaint Quality of Service Requirements 24x7 Systems Availability and Support Assets Medical and Billing Records Various DevOps teams are involved in the project, as well as business driving the transformation to provide as many health Team insurance services through the newly developed web application Prevent attackers from obtaining sensitive customer data. Security Objective Meet service-level agreements for application availability. Protect the company’s business credibility. 37 Create an Application Overview In this step, you outline what your Web application does. Your goal is to identify your application’s key functionality, characteristics, and clients. Draw a rough diagram that describes the composition and structure of your application, its subsystems, and its deployment characteristics. 38  Application Overview Description Customer: Accesses the application via a web application or app. Roles Employee/Account: Accesses the application for support purposes. Customer: The end customer using the application. The customer is a health insurance recipient (paying a monthly health insurance fee and receiving health insurance coverage). Key Usages Employees: Employees access the application as well as customers. Employees provide support to customers via a helpdesk and other channels. Employees can see more data than customers, including access to many different customers. MyHealth web application will be hosted via cloud which runs Technologies on a Linux server running Apache, Bootstrap framework front- end and MySQL Database in the back-end. Authentication, Integrity, Non-Repudiation, Confidentiality, Security Mechanism Availability, Authorization Decompose Your Application In this step, you break down your Highlights of the diagram (and its main components): application to identify trust boundaries, ▪ Customer: The end customer using the application. The data flows, entry points, and exit points. customer is a health insurance recipient (paying a monthly The more you know about the health insurance fee and receiving health insurance mechanics of your application, the coverage). easier it is to uncover threats and ▪ Employees: Employees access the application as well as discover vulnerabilities. customers. Employees provide support to customers via a helpdesk and other channels. Employees can see more data Architectural diagrams and overviews than customers, including access to many different of the proposed application design help customers. in creating a DFD. ▪ Application: This is the main application in the scope of the threat modeling exercise. It is shown here as one icon. However, the application has many sub-components, backend, frontend, etc. ▪ Customer Data: The new application will have a new database environment to store some of the relevant customer data. ▪ Medical Procedures and Activities: Data provided to the customer includes medical procedures, activities, etc. This data is stored in a legacy database and system. This data will not be sent to the Customer Data database. ▪ Billing Data: Billing data is managed in a separate system but is shown via the application (to the customer). 3Y Identify Threats and Vulnerabilities In this step, you identify threats and attacks that might affect your application and compromise your security objectives. These threats are the bad effects that could happen to your application. STRIDE methodology introduced by Microsoft can be used to identify threats. As a next step, STRIDE threat modeling against each component (known as component-based STRIDE threat modeling) can be performed with two approaches: ▪ Think of potential threats per component, and assign a STRIDE threat type (i.e., assign Spoofing, or Tampering, etc.). ▪ Per component, think of Spoofing threats specifically, then Tampering threats, then Repudiation threats, etc. So, in order of STRIDE, go through the list and think of potential threats limited to the STRIDE threat type. Application Component The following STRIDE threats apply to the web application, as part of the STRIDE threat modeling example. STRIDE Identified Threats Spoofing Threat 1: A user could possibly access data from other users. There are lots of sources of data that are shared within the web application. There are also lots of features within the application that access different parts of the data. Spoofing Spoofing Threat 2: The application needs to be accessible to customers. Therefore, the login feature, and its related features (i.e., password reset, etc.), need to be easy to use. However, the ease of use must not introduce a threat which allows an attacker to circumvent or misuse login features (and thus gain access to user credentials). Tampering Threat 1: The application has limited data entry features, because most of the features are read-only. There is Tampering a potential threat of other people, except for the current user, tampering with user data. Repudiation No Repudiation threats identified. Information Disclosure Threat 1: Medical data is extremely confidential, and subject to various regulations (i.e., HIPAA). There is a threat that users may access medical data of other users, through lack of access controls. Information Disclosure Threat 2: There is a potential threat of employees accessing health data inappropriately via the Information Disclosure web application (other applications already have strict controls). Information Disclosure Threat 3: There is a threat that attackers, may target customers to try and gain access to their data. Think phishing attacks against our customers, social engineering, etc.. Denial of Service Threat 1: The application has very high Availability requirements. There is a threat that criminal gangs Denial of Service will target the company with Distributed Denial of Service (DDoS) attacks. The company has been a target of such attacks in the past. Elevation of Privilege No Elevation of Privilege threats identified. 40 Rate and Prioritize Threats DREAD methodology is used to rate, compare and prioritize the severity of risk presented by each threat that is classified using STRIDE. To determine the ranking of a threat, the threat analyst must answer basic questions for each factor of risk. A sample is shown in the illustration. RATING DREAD HIGH (3) MEDIUM (2) LOW (1) Damage The attacker can subvert the Leaking sensitive information. Leaking trivial information. Potential security system. The attack can be reproduced The attack cab be reproduced but The attack is very difficult to Reproducibility every time and does not require a only with a timing window and a reproduce, even with knowledge timing window. particular race situation. of the security hole. An extremely skilled person and A novice programmer could A skilled programmer could make Exploitability have in-depth knowledge in make the attack in a short time. the attack, then repeat the steps. exploits. Very small percentage of users, All users, default configuration, Some users, non-default Affected Users obscure features; affects key customers configuration anonymous users. The vulnerability is found in the The vulnerability is in a seldom- The bug is obscure, and it is Discoverability most common used feature and is used part of the system, and only a unlikely that users will work out very noticeable. few users should come across it. damage potential. Calculations: Score = (Damage + Reproducibility + Exploitability + Affected Users + Discoverability) Risk Rating:  HIGH 11 - 15  MEDIUM 6 - 10  LOW 1 – 5 TYPE OF RATING THREATS COMPONENT THREAT (STRIDE) D R E A D SCORE A user could possibly access data from other users. There are lots of sources of data that are shared within the web APPLICATION S application. There are also lots of features within the application that access different parts of the data. The application has limited data entry features, because most of the features are read-only. For example, users cannot edit billing data, or edit registered medical procedures. But some core information about the user can be edited, such as current APPLICATION T address, which bank account or credit card must be used, etc. There is a potential threat of other people, except for the current user, tampering with user data. Medical data is extremely confidential, and subject to various regulations (i.e., HIPAA). There is a threat that users may access APPLICATION I medical data of other users, through lack of access controls. The application has very high Availability requirements. There is a threat that criminal gangs will target the company with APPLICATION D Distributed Denial of Service (DDoS) attacks. The company has been a target of such attacks in the past. 41 Identify Countermeasures and Mitigations Once threats have been identified, compared and prioritized using threat modeling method it is time to define countermeasures to those threats. Note that countermeasures to threats can also be called security requirements or threat mitigations. APPLICATION COMPONENT Threat Threat Type Security Property Mitigation A user could possibly access data from other users. There are lots of sources of data that are shared within the web Multi-factor Authentication Spoofing Authentication application. There are also lots of features Require re-authentication for sensitive data. within the application that access different parts of the data. The application has limited data entry features, because most of the features are read-only. For example, users cannot edit Enforce Least Privileges billing data, or edit registered medical Deny by Default procedures. But some core information Integrity/Access Tampering Validate the Permissions on Every Request about the user can be edited, such as Controls Prefer Attribute and Relationship Based Access current address, which bank account or credit card must be used, etc. There is a Control over RBAC potential threat of other people, except for the current user, tampering with user data. Medical data is extremely confidential, and subject to various regulations (i.e., HIPAA). Access Control List (ACLs)/Permissions, There is a threat that users may access Information Disclosure Confidentiality Cryptography, Encryption, Isolation medical data of other users, through lack of access controls. The application has very high Availability Limit server-side session time based on requirements. There is a threat that inactivity and a final timeout. criminal gangs will target the company Denial-of-Service Availability Input Validations with Distributed Denial of Service (DDoS) attacks. The company has been a target of Redundancy Failover such attacks in the past. Once threats and corresponding countermeasures are identified, it is possible to derive a threat profile with the following criteria: ▪ Non mitigated threats: Threats which have no countermeasures and represent vulnerabilities that can be fully exploited and cause an impact. ▪ Partially mitigated threats: Threats partially mitigated by one or more countermeasures and can only partially be exploited to cause a limited impact. ▪ Fully mitigated threats: These threats have appropriate countermeasures in place and do not expose vulnerabilities. 42  SUMMARY The system development life cycle is the overall process of developing, implementing, and retiring information systems through a multistep process from initiation, analysis, design, implementation, and maintenance to disposal. For any SDLC model that is used, information security must be integrated into the SDLC to ensure appropriate protection for the information that the system will transmit, process, and store. Secure systems require secure software Some common place security principles includes: o Keep design simple and small o Access decisions by permission not exclusion o Every access to every object checked for authority o Design depends on possession of keys/passwords o Protection mechanisms require two keys to unlock o Programs/users utilize only necessary privileges o Minimize mechanisms common to multiple users o Human interface must be easy to use so users routinely/automatically use protection mechanisms ▪ Code review aims to identify security flaws in the application related to its features and design, along with the exact root causes. ▪ A secure source code review is an enhancement model for the standard source code review process. In contrast with source code reviews, the service model eyes on security considerations and standards. ▪ Threat modeling is an in-depth approach for analyzing the security of an application. It is a structured approach that enables employees to identify, quantify, and address the security risks associated with an application. Threat modeling is not an approach to reviewing code, but it complements the secure code review process by providing context and risk analysis of the application. 43  KEY TERMS ▪ Buffer Overruns ▪ Command Injection ▪ Cross-site Scripting (XSS) Phreaker ▪ Cryptosystems ▪ Format String ▪ Change Control ▪ File Access ▪ Secure Sockets Layer (SSL) ▪ Hypertext Transfer Protocol Secure (HTTPS) ▪ Information Leakage ▪ Integer Bugs ▪ Race Conditions ▪ SQL Injection ▪ Poor Usability ▪ Code Review ▪ Secure Code Review ▪ Static Application Security Testing (SAST) ▪ PCI (Payment Card Industry) ▪ HIPPA ▪ Design Risk Analysis ▪ User Risk Analysis ▪ Architecture Risk Analysis ▪ Threat Model ▪ STRIDE ▪ DREAD  REFERENCES ▪ Whiteman, et.al. “Principles of Information Security”, 3rd Edition ▪ Radack, S. (2009), The System Development Life Cycle (SDLC), ITL Bulletin, National Institute of Standards and Technology, Gaithersburg, MD, [online], https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=9 02622 (Accessed November 6, 2022) ▪ ValueMentor, “Source Code Review: Why and When? Why Is It Important?”, https://valuementor.com/blogs/source- code-review- why-and-when-why-is-it-important/ ▪ OWASP Foundation, “OWASP Code Review Guide”, 2017, PDF https://owasp.org/www-project-code-review- guide/assets/OWASP_Code_Review_Guide_v2.pdf ▪ EC-Council, “Threat Modeling”, Website, https://www.eccouncil.org/threat-modeling/ ▪ Josh Fruhlinger, 2020, "Threat modeling explained: A process for anticipating cyber attacks", Website, https://www.csoonline.com/article/3537370/threat- modeling- explained-a-process-for-anticipating-cyber- attacks.html ▪ Nick, 2022, "STRIDE Threat Modeling Example for Better Understanding and Learning", Website, https://threat- modeling.com/stride-threat-modeling-example/ ▪ Nick, 2022, "STRIDE Threat Modeling", Website, https://threat-modeling.com/stride-threat-modeling/ ▪ Dhanushchinnappa, 2022, “ASF & STRIDE Countermeasure”, https://securitywebexploit.wordpress.com/asf- stride- countermeasure/ ▪ JD Meier, 2022, “How To Use Threat Modeling to Explore Threats and Countermeasures”, https://jdmeier.com/how-to-use-threat-modeling/ ▪ Secure SDLC | Secure Software Development Life Cycle. (n.d.). Snyk. Retrieved November 22, 2023, from https://snyk.io/learn/secure-sdlc/ 45