CST 620 Project

CST620 Project 3 Resources

 

Deliverables by May 13th

• Threat Model Report: An eight- to 10-page double-spaced Word document with citations in APA format. The report should include your findings and any recommendations for mitigating the threats found. The page count does not include figures, diagrams, tables, or citations.
• Lab Report: A Word document sharing your lab experience along with screenshots. (I will Provide).

 

Mobile Application Threat Modeling

You are a cyber threat analyst at a mobile applications company. One morning, your supervisor, Dan, tells you about a mobile application security project that is already under way, but needs more guidance. Because of your success on previous projects, he wants your help.

Your expertise and oversight will enable the mobile app team to meet its approaching deadline. “Mobile applications and their security are on the technology roadmap for our organization. Of course, this means we need to be well-informed of mobile application security management,” Dan says.

“Without the proper threat modeling, leadership can’t be sure of the issues that lie ahead. I want you to oversee the project and manage the team,” Dan says. “We’d also like you to contribute to this project by preparing a report for senior management.” The report should include threat models to this technology as well as remediation for management to consider. The report should give senior management a greater understanding of mobile application security and its implementation.

Your report should consist of the following sections: mobile application architecture, mobile data, threat agent identification, methods of attack, and possible controls. The goal is to convince senior managers that your proposals will benefit the company. If you succeed, leadership will move forward with its plan for mobile applications. The report is due in two weeks.

Threat modeling begins with a clear understanding of the system in question. There are several areas to consider when trying to understand threats to an application. The areas of concern include the mobile application structure, the data, identifying threat agents and methods of attack, and controls to prevent attacks. The threat model should be created with an outline or checklist of items that need to be documented, reviewed, and discussed when developing a mobile application.

In this project, you will create a threat model. There are seven steps that will lead you through this project, beginning with the scenario as it might occur in the workplace, and continuing with Step 1: “Describe Your Mobile Application Architecture.” Most steps in this project should take no more than two hours to complete, and the project as a whole should take no more than two weeks to complete.

Step 1: Describe Your Mobile Application Architecture

In your role as a cyber threat analyst, senior management has entrusted you to identify how a particular mobile application of your choosing conforms to mobile architecture standards. You are asked to:

1. Describe device-specific features used by the application, wireless transmission protocols, data transmission media, interaction with hardware components, and other applications.
2. Identify the needs and requirements for application security, computing security, and device management and security.
3. Describe the operational environment and use cases.
4. Identify the operating system security and enclave/computing environment security concerns, if there are any.

This can be fictional or modeled after a real-world application. This will be part of your final report. Click the following links and review the topics and their resources. These resources will guide you in completing this task:

Network Security Threats

Threats or vulnerabilities to network security can be broadly classified into three categories: accidental disclosures, deliberate penetrations, and physical attacks (Ware, n.d.). Accidental disclosures can occur due to hardware/software failures, or improper actions of users with access to secure data. Deliberate penetrations can happen because of active infiltration by insiders who are authorized to access confidential data. Physical attacks refers to risks posed on physical infrastructure or environment, usually by outsiders.

References

Ware, W. (n.d.). Security controls for computer systems: Report of defense science board task force on computer security, RAND report R-609-1. http://www.rand.org/pubs/reports/R609-1/index2.html#C

Threat Modeling

Threat modeling is performed to identify, analyze, and mitigate security risks to systems and applications. According to the Open Web Application Security Project (OWASP) Foundation, there are three steps of threat modeling for applications (OWASP, n.d.):

Step 1: Decompose the application. The first step in the threat modeling process is concerned with gaining an understanding of the application and how it interacts with external entities.
Step 2: Determine and rank threats. Critical to the identification of threats is using a threat categorization methodology.
Step 3: Determine countermeasures and mitigation. A lack of protection against a threat might indicate a vulnerability whose risk exposure could be mitigated with the implementation of a countermeasure.

Effective and well-documented threat modeling can prevent attacks and secure confidential information.

References

The OWASP Foundation. (n.d.). Application threat modeling. https://www.owasp.org/index.php/Application_Threat_Modeling

Mobile Architectures

Several organizations are adopting centralized mobile device management approaches, which use client/server architecture to control the use of personal and work-issued devices and protect the security of confidential data. The architecture consists of single or multiple centralized servers that connect with clients using the applications installed on their devices (which are always running in the background). According to the National Institute of Standards and Technology (Souppaya&Scarfone, 2013):

If the device is organization issued, the client application typically manages the configuration and security of the entire device. If the device is BYOD, the client application typically manages only the configuration and security of itself and its data, not the entire device. The client application and data should be sandboxed from the rest of the device’s applications and data in a secure container, both helping to protect the enterprise from a compromised device and helping to preserve the privacy of the device’s owner. (p. 7)

References

Souppaya, M., &Scarfone, K. (2013). Guidelines for managing the security of mobile devices in the enterprise: Special Publication 800-124, Revision 1. National Institute of Standards and Technology.  http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-124r1.pdf

Application Security

Application security testing is performed by organizations to ensure that their applications and software contain no errors or vulnerabilities and interact with users and other applications securely. According to the National Institute of Standards and Technology’s guideline document (Scarfone et al., 2008):

Application security assessment should be integrated into the software development life cycle of the application to ensure that it is performed throughout the life cycle. For example, code reviews can be performed as code is being implemented, rather than waiting until the entire application is ready for testing. Tests should also be performed periodically once an application has gone into production; when significant patches, updates, or other modifications are made; or when significant changes occur in the threat environment where the application operates. (p. C-1)

The application security testing techniques can be broadly classified into white box and black box techniques. White box techniques are implemented by directly analyzing the source code, whereas black box techniques are implemented using the binary executable code.

References

Scarfone, K., Souppaya, M., Cody, A., &Orebaugh, A. (2008). Technical guide to information security testing and assessment: Special Publication 800-115. National Institute of Standards and Technology. .  http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-115.pdf

Operating System Security

Operating systems (OSs) are prone to several threats, including viruses, malware, snooping, spoofing, and denial of service. The three main aspects of OS security are confidentiality or prevention of theft, integrity or prevention of damage, and availability or prevention of service denial (Heiser, 2008).

It is worth noting that users pose one of the biggest threats to security:

The weakest point within any system is often the end user. It comes as no surprise, therefore, that a large percentage of security breaches over the last decade have come from the inside of an organization, often unknowingly by the user… Whether through careless actions or by deliberate intent, this is something that should be considered first and foremost in securing an OS. (Carnaghan, n.d.)

References

Heiser, G. (2008). Security: An advanced introduction. University of New South Wales (UNSW). http://www.cse.unsw.edu.au/~cs9242/08/lectures/06-security.pdf

Carnaghan, I. (n.d.). Operating systems security: Protection measures analysis. https://www.carnaghan.com/2015/10/operating-systems-security-protection-measures-analysis/

Enclave/Computing Environment

Enclave refers to a part of the network which is divided from the network, so that there is restricted access and sharing of confidential data. According to Mikkelsen and Jacobsen (2016):

The main principle relies upon the concept of a protected memory container, also referred to as an enclave. The enclave can be created through application code, where sensitive data are explicitly marked. When the application is executed, a sensitive part of the application’s memory space is encapsulated within an enclave. (p. 218)

Enclaves do not interact with the other parts of the network, so the enclave computing environment promotes security and integrity of data and reduces threats.

References

Mikkelsen, S. A., & Jacobsen, R. H. (2016). Securing the home energy management platform. http://cdn.intechopen.com/pdfs-wm/50458.pdf

Begin by first reviewing the OWASP Mobile Security Project Testing Guide

OWASP Mobile Security Project Testing Guide

Introduction

A major priority of the OWASP Mobile Security Project is to help standardize and disseminate mobile application testing methodologies. While specific techniques exist for individual platforms, a general mobile threat model can be used to assist test teams in creating a mobile security testing methodology for any platform. The outline which follows describes a general mobile application testing methodology which can be tailored to meet the security tester’s needs. It is high-level in some places, and over time will be customized on a per-platform basis.

This guide is targeted towards application developers and security testers. Developers can leverage this guide to ensure that they are not introducing the security flaws described within the guide. Security testers can use it as a reference guide to ensure that they are adequately assessing the mobile application attack surface. The ideal mobile assessment combines dynamic analysis, static analysis, and forensic analysis to ensure that the majority of the mobile application attack surface is covered.

On some platforms, it may be necessary to have root user or elevated privileges in order to perform all of the the required analysis on devices during testing. Many applications write information to areas that cannot be accessed without a higher level of access than the standard shell or application user generally has. For steps that generally require elevated privileges, it will be stated that this is the case.

This guide is broken up into three sections:

• Prerequisites/Planning: tasks and requirements before conducting the mobile security assessment
• Information Gathering: describes the steps and things to consider when you are in early-stage reconnaissance and mapping phases of testing as well as determining the application’s magnitude of effort and scoping
• Static Analysis: analyzing raw mobile source code, decompiled, or disassembled code
• Dynamic Analysis: executing an application either on the device itself or within a simulator/emulator and interacting with the remote services with which the application communicates. This includes assessing the application’s local interprocess communication surface, forensic analysis of the local filesystem, and assessing remote service dependencies.

How To Use This Resource

In this current draft release, the guide is a work in progress. We need additional contributors to help fill in the blanks. If you think something is missing (there certainly is), add it.

As this guide is not platform specific, you will need to know the appropriate techniques and tools for your target platform. The OWASP Mobile Security Project has also developed a number of other supporting resources that you may be able to leverage for your needs.

The steps required to properly test an Android application are very different than the steps to properly test an iOS application. Likewise, Windows Phone is very different from the other platforms. Mobile security testing requires a diverse skillset over many differing operating systems and a critical ability to analyze various types of source code.

In many cases, a mobile application assessment will require coverage in all three areas identified within this testing reference. A dynamic assessment will benefit from an initial thorough attempt at information gathering, some level of static analysis against the application’s binary, and a forensic review of the data created and modified by the application’s runtime behavior.

Please use this guide in an iterative fashion, where work in one area may require revisiting previous testing steps. As an example, after completing a transaction you may need to perform additional forensic analysis on the device to ensure that sensitive data is removed as expected and not cached in an undesired fashion. As you learn more about the application at runtime, you may wish to examine additional parts of the code to determine the best way to evade a specific control. Likewise, during static analysis, it may be helpful to populate the application with certain data in order to prove or refute the existence of a security flaw.

In the future, contributors to the testing guide should consider adding entries under each section relevant to a specific platform. Over time, OWASP contributors will write platform-specific guides and expand upon this body of knowledge.

If a specific area of interest is not covered in this guide, please feel free to take either of the following actions:

• write the material yourself by registering for a wiki account and contributing content
• bring this up as a topic on the Mobile Project’s mailing list

Collaboration on building the guide is being performed within Google Docs.

Information Gathering

As a result of this initial information gathering exercise, the tester will be better prepared for the future testing phases. The sad truth is, testers (i.e., developers, QA, and security) often fail to take the time to learn the target application and supporting infrastructure, opting to dive in blind, possibly losing valuable time and missing possible attack vectors. Without a solid understanding of how the application should work as well as the technologies in use, the tester will not be able to identify when the application behaves in a manner that it shouldn’t.

Prerequisites of this phase may require specific operating systems, platform-specific software development kits (SDKs), rooted or jailbroken devices, and the ability to man-in-the-middle secure communications (i.e., HTTPS) and bypass invalid certificate checks.

• Proxy and sniff all network traffic from either a physical mobile device or an emulator/simulator. Begin recording and logging traffic (if your proxy tool permits logging, which most should).
• Register for and/or provision test accounts. Ideally, you will want two accounts per user role to ensure proper testing of vertical and horizontal privilege escalation attack vectors.
• Manually navigate through the running application to understand the basic functionality and workflow of the application. This can be performed on a real device or within a simulator/emulator.
• Identify the networking interfaces used by the application
  • 3G/4G
  • WiFi
  • Bluetooth
  • Near Field Communication (NFC)
  • Virtual Private Network (VPN)
• Is all functionality available over 3G/4G, or is WiFi required for actions such as data synchronization?
• What networking protocols are in use? Are secure protocols used where needed? Can they be switched with insecure protocols?
• Does the application perform commerce transactions?
  • credit card transactions and/or stored payment information
  • in-app purchasing of goods or features
• Monitor and identify the hardware components that the application may potentially interact with the following:
  • NFC
  • Bluetooth
  • GPS
  • camera
  • microphone
  • sensors
• Perform open-source intelligence gathering (search engines, source code repositories, developer forums, etc.) to identify source code or configuration information that may be exposed (i.e., third party components integrated within the application).
• Identify if the application appears to interact with any other applications, services, or data such as:
  • telephony (SMS, phone)
  • contacts
  • Google Wallet
  • iCloud
  • social networks (i.e., Facebook, Twitter, LinkedIn, Google+)
  • Dropbox
  • Evernote
  • e-mail
• Can you determine anything about the server-side application environment?
  • hosting provider (AWS, App Engine, Heroku, Rackspace, Azure, etc.)
  • development environment (Rails, Java, Django, ASP.NET, etc.)
  • Does the application leverage Single Sign On or Authentication APIs (Google Apps, Facebook, iTunes, OAuth, etc.)?
  • Any other APIs in use?
    • payment gateways
    • SMS messaging
    • social networks
    • cloud file storage
    • ad networks
• Perform a thorough crawl of exposed web resources and sift through the requests and responses to identify potentially interesting data or behavior.
  • leaking credentials
  • resources not exposed through the UI
  • error messages
  • cacheable information

Static Analysis

There are two primary ways static analysis will generally be performed on a mobile application:

• analyzing source code obtained from development team (prefered)
• Using a compiled binary: Some level of static analysis should be performed for both dynamic and forensic analysis, as the application’s code will almost always provide valuable information to the tester (i.e., logic, backend targets, APIs, etc).

In scenarios where the primary goal is to identify programmatic examples of security flaws, your best bet is to review pure source code as opposed to reverse engineering compiled software. For source code reviews, it is highly beneficial to have access to either a development or production instance of any web services. This includes both source code and a working test environment to perform the assessment within in order to expedite understanding of the code.

Getting Started

• If the source is not directly available, decompile or disassemble the application’s binary.
  • extract the application from the device
  • follow the appropriate steps for your platform’s application reverse engineering
  • some applications may require decryption prior to reverse engineering
• Review the permissions the application requests as well as the resources that it is authorized to access (i.e., AndroidManifest.xml, iOS Entitlements).
• Are there any easy-to-identify misconfigurations within the application found within the configuration files? Debugging flags set, world readable/writable permissions, etc.
• Identify the libraries in use including both platform-provided as well as third party. Perform a quick review on the web to determine if these libraries meet the following conditions:
  • are up to date
  • are free of vulnerabilities
  • expose functionality that requires elevated privileges (access to location or contact data)
• Does the application check for rooted/jailbroken devices? How is this done? How can this be circumvented? Is it as easy as changing the case of a file name or path?
• Determine what types of objects are implemented to create the various views within the application. This may significantly alter your test cases, as some views implement web browser functionality while others are native UI controls only.
• Is all code expected to run within the platform’s standard runtime environment, or are some files/libraries dynamically loaded or called outside of that environment at runtime?
• Attempt to match up every permission that the application requests with an actual concrete implementation of it within the application. Often, developers request more permission than they actually need. Identify if the same functionality could be enabled with lesser privileges.
• Locate hard-coded secrets within the application such as API keys, credentials, or proprietary business logic.
• Identify every entry point for untrusted data entry and determine how it enforces access controls, validates and sanitizes inbound data, and passes the data off to other interpreters.
  • from web service calls
  • receiving data from other apps and on-device services
  • inbound SMS messages
  • reading information from the filesystem

Authentication

• Locate the code that handles user authentication through the UI. Assess the possible methods of user impersonation via vectors such as parameter tampering, replay attacks, and brute force attacks.
• Determine if the application utilizes information beyond username/password, such as the following:
  • contextual information (i.e., device identifiers, location)
  • certificates
  • tokens
• Does the application utilize visual swipe or touch passwords vs. conventional usernames and passwords?
  • Assess the method of mapping the visual objects to an authentication string to determine if adequate entropy exists.
• Does the application implement functionality that permits inbound connections from other devices (i.e., WiFi Direct, Android Beam, network services)?
  • Does the application properly authenticate the remote user or peer prior to granting access to device resources?
  • How does the application handle excessive failed attempts at authentication?
• Single sign-on
  • OAuth
  • Facebook
  • Google Apps
• SMS
  • How is the sender authenticated?
    • password
    • header information
  • Are one-time passwords (OTP) used, or is other sensitive account data transmitted via SMS?
    • Can other applications access this data?
• Push notifications
  • If the application consumes information via push notifications, how does the application verify the identity of the sender?

Authorization

• Review file permissions for files created at runtime.
• Determine if it is possible to access functionality not intended for your role.
  • Identify if the application has role-specific functionality within the mobile application.
  • Locate any potential flags or values that may be set on the client from any untrusted source that can be a point of privilege elevation, such as the following:
    • databases
    • flat files
    • HTTP responses
  • Find places within an application that were not anticipated being directly accessed without following the application’s intended workflow.
• Licensing
  • Can licensing checks be defeated locally to obtain access to paid-for data resources (i.e., patching a binary, modifying it at runtime, or by modifying a local configuration file)?
  • Does the code suggest that licensed content is served with a nonlicensed app but restricted by UI controls only?
  • Are licensing checks performed properly by the server or platform licensing services?
  • How does the application detect tampering and respond to tampering?
    • Are alerts sent to and expected by the developer?
    • Does the application fail open or fail closed?
    • Does the application wipe its data?

Session Management

• Ensure that sessions time out locally as well as server-side.
• Is sensitive information utilized within the application flushed from memory upon session expiration?

Data Storage

• Encryption
  • Are the algorithms used “best of breed,” or do they contain known issues?
  • Based on the algorithms and approaches used to encrypt data, do implementation issues exist that degrade the effectiveness of encryption?
  • How are keys managed and stored on the device? Can this reduce the complexity of breaking the encryption?
• Identify if the application utilizes storage areas external to the sandboxed locations to store unencrypted data, such as the following:
  • places with limited access control granularity (SD card, tmp directories, etc.)
  • directories that may end up in backups or other undesired locations (iTunes backup, external storage, etc.)
  • cloud storage services such as Dropbox, Google Drive, or S3
• Does the application write sensitive information to the file system at any point, such as the following:
  • credentials
    • username and password
    • API keys
    • authentication tokens
  • payment information
  • patient data
  • signature files
• Is sensitive information written to data stores via platform exposed APIs, such as contacts?

Transport Layer Protection

• Does the application properly implement certificate pinning?
• Are certificates validated to determine the following:
  • the certificate has not expired
  • the certificate was issued by a valid certificate authority
  • the remote destination information matches the information within the certificate?
• Identify if code exist to alter the behavior for traffic transiting different interfaces (i.e., 3G/4G comms vs. WiFi)? If so, is encryption applied universally across each of them?

Information Disclosure

• Logs
  • Does the application log sensitive information to a globally shared log?
  • Can any of the logged information be considered a privacy violation?
• Caches
  • predictive text
  • location information
  • browser cache
• Exceptions
  • Does sensitive data leak in crash logs?
• Third-party libraries and APIs
  • What permissions do they require?
  • Do they access or transmit sensitive information?
  • Can their runtime behavior expose users to privacy issues and unauthorized tracking?
    • by the application

Web Application Issues

• XSS and HTML injection
• command injection (if the application utilizes a shell)
• CSRF
• SQL injection
• cookies
• HTML5

Architecture Considerations

Although mobile applications vary in function, they can be described in general as follows:

• wireless interfaces
• transmission type
• hardware interaction
• interaction with on device applications/services
• interaction with off device applications/services
• encryption protocols
• platforms

In Section 1 of your research report, you will focus your discussion on the security threats, vulnerabilities, and mitigations of the above considerations.

The following resources will continue to educate your management about mobile devices and mobile application security: mobile platform security.

Mobile Platform Security

The rapidly rising demand for mobile devices is also accompanied by an increase in mobile platform options and the need for high security. Examples of malware on the popular platforms include DroidDream (Android), Ikee (iOS) and Zitmo (Windows and Android) (Mitchell, 2016).

The Open Web Application Security Project (OWASP) Mobile Top 10 2016 includes “Improper Platform Usage” as one of the top 10 risks to mobile security (OWASP, 2016):

This category covers misuse of a platform feature or failure to use platform security controls. It might include Android intents, platform permissions, misuse of TouchID, the keychain, or some other security control that is part of the mobile operating system.

The impacts of this risk are hard to describe. Mobile platforms provide many different services, from authentication to secure data storage to secure network communications. Failing to use some part of the platform correctly, therefore, could expose data, allow connections to untrusted hosts, or enable fraudulent payments. Privacy and permissions in mobile apps are also the domain of the platform. Thus, a failure to use the platform’s features could expose the end user to a privacy risk.

References

Mitchell, J. (2016), Mobile platform security models. https://crypto.stanford.edu/cs155/lectures/17-mobile-platforms.pdf

Open Web Application Security Project (OWASP). (2016). Mobile top 10 2016-top 10. https://www.owasp.org/index.php/Mobile_Top_10_2016-Top_10

Mobile Protocols and Security

Security protocols can be implemented to encrypt the data transmitted from mobile devices and prevent unauthorized access to confidential data. The Cyber Security Division of the Department of Homeland Security (DHS) focuses on mobile internet infrastructure security by “developing security protocols for the existing Internet infrastructure (browsers and routers, essential to daily Internet operation) so that users are not redirected to unsafe websites or pathways by malicious actors” (US Department of Homeland Security, n.d.).

In addition, mobile users should update the protection on their devices to detect new suspicious activities.

References

US Department of Homeland Security. (n.d.). Mobile security R&D program guide. https://www.dhs.gov/sites/default/files/publications/CSD 2016 Mobile Security R%26D Program Guide Vol 1.pdf

mobile security vulnerabilities, and related technologies and their security. Related technologies can include the hardware and software needed to interoperate with mobile devices and mobile applications.

Include an overview of these topics in your report.

Use Mobile Application and Architecture Considerations to review the architectural considerations for mobile applications and architecture.

Mobile Application and Architecture Considerations

Use this document to review the various architecture considerations for mobile applications and architecture.

Note: Not all of the following may apply to your mobile app. You will need to address only those areas that apply to the particular application you have chosen.

1. What is the design of the architecture (network infrastructure, web services, trust boundaries, third-party APIs, etc.)?
   • Carrier
     • Data
     • SMS
     • Voice
   • Endpoints
     • Web Services
       • RESTful or SOAP-based
       • Third Party (Example: Amazon)
     • Websites
       • Does the app use or integrate the “mobile web” version of an existing web site?
     • App Stores
       • Google Play
       • Apple App Store
       • Windows Mobile
       • BlackBerry App Store
     • Cloud Storage
       • Amazon/Azure
     • Corporate networks (via VPN, SSH, etc.)
   • Wireless interfaces
     • 802.11
     • NFC
     • Bluetooth
     • RFID
   • Device
     • App layer
     • Runtime environment (VM, framework dependencies, etc.)
     • OS platform
   • Apple iOS
   • Android
   • Windows Mobile
   • BlackBerry
     • Baseband
2. What are the common hardware components?
   • GPS
   • Sensors (accelerometer)
   • Cellular radios (GSM/CDMA/LTE)
   • Flash memory
   • Removable storage (i.e.- SD)
   • USB ports
   • Wireless interfaces
     • 802.11
     • Bluetooth
     • NFC
     • RFID
   • Touch screen
   • Hardware keyboard
   • Microphone
   • Camera
3. What are the authentication specifics?
   • Method
     • Knowledge-based
     • Token-based
     • Biometrics
   • Input Type
     • Keyboard
     • Touch screen
     • Hardware peripheral
   • Decision Process
     • Local (on device)
     • Remote (off device)
4. Define the app architecture relative to OS stack + security model
   • What should or shouldn’t the app do?

Then, include those that are relevant to your mobile application in your report to senior management. Address the following questions:

1. What is the design of the architecture (network infrastructure, web services, trust boundaries, third-party APIs, etc.)?
2. What are the common hardware components?
3. What are the authentication specifics?
4. What should or shouldn’t the app do?

You will include this information in your report.

When you have completed the work for Section 1, describing the architecture for your app, move on to the next step, where you will define the requirements for the app.

Step 2: Define the Requirements for Your Mobile Application

In the previous step, you described your app’s architecture. In Step 2, you will define what purpose the mobile app serves from a business perspective and what data the app will store, transmit, and receive. Include a data flow diagram to showing exactly how data are handled and managed by the application. You can use fictional information or model it after a real-world application. Here are some questions to consider as you define your requirements:

1. What is the business function of the app?
2. What data does the application store/process? (provide data flow diagram)
   1. This diagram should outline network, device file system, and application data flows
   2. How are data transmitted between third-party APIs and app(s)?
   3. Will there be remote access and connectivity? Read this resource about mobile VPN security, and include any of these security issues in your report.

Mobile VPN Security

A mobile virtual private network (VPN) “is a virtual network, built on top of existing physical networks, that can provide a secure communications mechanism for data and other information transmitted” between a mobile device and network (Frankel et al., 2008).

 

Mobile VPNs protect the confidentiality, integrity, access, and availability of sensitive data and are always connected, although the networks and locations may change. Mobile VPNs differ from other VPNs, including secure sockets layer (SSL) VPNs, which connect users to web browsers, and IPsec VPNs, which connect fixed endpoints (Frankel et al., 2008, and Frankel et al., 2005).

 

References

Frankel, S., Kent, K., Lewkowski, R., Orebaugh, A. D., Ritchey, R. W., & Sharma, S. R.  (2005). Guide to IPsec VPNs (Special Publication 800-77). National Institute of Standards and Technology. US Department of Commerce. http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-77.pdf

 

Frankel, S., Hoffman, P., Orebaugh, A., & Park, R. (2008). Guide to SSL VPNs (Special Publication 800-113). National Institute of Standards and Technology. US Department of Commerce. http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-113.pdf

1. Are there different data-handling requirements between different mobile platforms? (iOS/Android/Windows/J2ME)
2. Does the app use cloud storage APIs (e.g., Dropbox, Google Drive, iCloud, Lookout) for device data backups?
3. Does personal data intermingle with corporate data?
4. Is there specific business logic built into the app to process data?

3. What does the data give you (or an attacker) access to? Think about data at rest and data in motion as they relate to your app.

Data at Rest

Data at rest refers to data stored on end-user devices, such as computers and phones, or removable storage media, such as memory cards, external hard drives, and USBs. According to the National Institute of Standards and Technology (NIST), there are several threats to stored data (Scar fone et al., 2007):

Some threats are unintentional, such as human error, while others are intentional. Intentional threats are posed by people with many different motivations, including causing mischief and disruption, and committing identity theft and other fraud. A common threat against end-user devices is device loss or theft. Someone with physical access to a device has many options for attempting to view or copy the information stored on the device. Another concern is insider attacks, such as an employee attempting to access sensitive information stored on another employee’s device. Malware, another common threat, can give attackers unauthorized access to a device, transfer information from the device to an attacker’s system, and perform other actions that jeopardize the confidentiality of the information on a device. (p. ES 1)

Encryption, authentication and backup, and disaster recovery systems are the main security measures that are commonly undertaken to restrict access to and maintain confidentiality of stored data.

 

References

Scarfone, K., Souppaya, M., & Sexton, M. (2007). Guide to storage encryption technologies for end user devices: Special Publication 800-111.. National Institute of Standards and Technology. http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-111.pdf

Data in Motion

Data in motion or data in transit refers to data that is transferred, generally over a network or on the internet. As multiple users access the transmitting resources, data may be exposed to several threats, and it is essential to ensure that the data is accessed only by the intended users. As discussed by Vesperman, encryption and authentication can be used to minimize unauthorized access to data in motion (2002):

The secure transmission of data in transit relies on both encryption and authentication—on both the hiding or concealment of the data itself, and on ensuring that the computers at each end are the computers they say they are. (p. 1)

References

Vesperman, J. (2002). Introduction to securing data in transit. http://www.tldp.org/REF/INTRO/SecuringData-INTRO.pdf

1. Do stored credentials provide authentication?
2. Do stored keys allow attackers to break crypto functions (data integrity)?

1. Are third-party data being stored and/or transmitted?
   1. What are the privacy requirements of user data? Consider, for example, a unique device identifier (UDID) or geolocation being transmitted to a third party.
   2. Are there user privacy-specific regulatory requirements to meet?
2. How do other data on the device affect the app? Consider, for example, authentication credentials shared between apps.
3. Compare between jailbroken (i.e., a device with hacked or bypassed digital rights software) and nonjailbroken devices.
   1. How do the differences affect app data? This can also relate to threat agent identification.

In this step, you defined the app’s requirements. Move to the next step, where you will identify any threats to the app’s operation.

Step 3: Identify Threats and Threat Agents

 

Now that you have identified the relevant requirements for your mobile app architecture and described the purpose and applicability of the app from a business perspective, you will define its threats in this step. Remember that it is your responsibility to present to senior executives about how integrating mobile app security into your strategy is essential to protecting your users and the overall network infrastructures.

In addition, your ability to identify threats and associated threat agents here is an important step to help you identify specific methods of attack, analyze mobile application threats, and discuss implementations of security controls in the remaining steps.

In Section 3 of the report, you will fulfill the following requirements:

• Identify possible threats and specific threat agents to the mobile application
• Outline the process for defining what threats apply to your mobile application

The major areas associated with these threat concepts are application vulnerabilities, server-side injection attacks, client-side attacks, secure coding principles, input validation, and applications hardening. Some common mobile app security threats that you should be aware of include reverse engineering, weak passwords, outdated encryption algorithms, and lack of multifactor authentication. However, it’s important to note that this list is by no means exhaustive. You would realize by completing this project that this is practically the case in real life.

An excellent source of information that is geared toward web applications security and that will help you complete this step is the Open Web Application Security Project (OWASP)—a nonprofit foundation that works to improve security of software applications. Particularly, the OWASP top 10 is a standard document for web application security awareness and represents a broad consensus about the most critical security risks to web applications (OWASP, 2021). In other words, the main goal is to provide specific details about web application security risks and mitigation strategies to prevent potential attacks.

To help you better appreciate threat model identification and mitigation strategies, review the following OWASP websites:

Top 10 Web Application Security Risks

A1:2017-Injection: Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

A2:2017-Broken Authentication: Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities temporarily or permanently.

A3:2017-Sensitive Data Exposure: Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data may be compromised without extra protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser.

A4:2017-XML External Entities (XXE): Many older or poorly configured XML processors evaluate external entity references within XML documents. External entities can be used to disclose internal files using the file URI handler, internal file shares, internal port scanning, remote code execution, and denial of service attacks.

A5:2017-Broken Access Control: Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users’ accounts, view sensitive files, modify other users’ data, change access rights, etc.

A6:2017-Security Misconfiguration: Security misconfiguration is the most commonly seen issue. This is commonly a result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information. Not only must all operating systems, frameworks, libraries, and applications be securely configured, but they must be patched/upgraded in a timely fashion.

A7:2017-Cross-Site Scripting XSS: XSS flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping, or updates an existing web page with user-supplied data using a browser API that can create HTML or JavaScript. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.

A8:2017-Insecure Deserialization: Insecure deserialization often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks.

A9:2017-Using Components with Known Vulnerabilities: Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts.

A10:2017-Insufficient Logging & Monitoring: Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.

Threat Modeling

Overview

The term “Threat Modeling” has become quite popular. Microsoft has published their process and includes threat modeling as a key activity in their Secure Development Lifecycle (SDL).

A threat model is essentially a structured representation of all the information that affects the security of an application. In essence, it is a view of the application and its environment through security glasses.

Threat modeling is a process for capturing, organizing, and analyzing all of this information. Threat modeling enables informed decision-making about application security risk. In addition to producing a model, typical threat modeling efforts also produce a prioritized list of security improvements to the concept, requirements, design, or implementation.

Objectives of Threat Modeling

Threat modeling is a family of activities for improving security by identifying objectives and vulnerabilities, and then defining countermeasures to prevent, or mitigate the effects of, threats to the system. A threat is a potential or actual undesirable event that may be malicious (such as DoS attack) or incidental (failure of a Storage Device). Threat modeling is a planned activity for identifying and assessing application threats and vulnerabilities.

Threat Modeling Across the Lifecycle

Threat modeling is best applied continuously throughout a software development project. The process is essentially the same at different levels of abstraction, although the information gets more and more granular throughout the lifecycle. Ideally, a high-level threat model should be defined in the concept or planning phase, and then refined throughout the lifecycle. As more details are added to the system, new attack vectors are created and exposed. The ongoing threat modeling process should examine, diagnose, and address these threats.

Note that it is a natural part of refining a system for new threats to be exposed. For example, when you select a particular technology – such as Java for example – you take on the responsibility to identify the new threats that are created by that choice. Even implementation choices such as using regular expressions for validation introduce potential new threats to deal with.

Threat Modeling – Generic Steps

For a threat to an application to exist, there must be a combination of the following where the combined likelihood and impact are important enough to do something about. Following is a four question framework that helps understand threat modeling:

• What are we working on?
• What can go wrong?
• What are we going to do about it?
• Did we do a good job?

There are many ways to answer each of these questions.

To understand whether an application is secure enough or not, you have to search out combinations of these ingredients that lead to realistic threats.

There is no “right” way to evaluate the search space of possible threats. But there are better or worse ways. Attempting to evaluate all the possible combinations of threat agent, attack, vulnerability, and impact is often a waste of time and effort. Note that many of the automated tools take this approach – gathering lots of data and producing thousands of possible threats. Generally it is more productive to focus on finding high likelihood and high impact threats.

The basic threat modeling process consists of the following generic steps. The process of exploring the search space is iterative and constantly refined based on what you have done so far. So, for example, starting with all possible vulnerabilities is usually pointless, as most of them are not attackable by the threat agents, protected by a safeguard, or do not lead to a consequence. Therefore, it’s generally best to start with the factors that make a lot of difference.

• Assessment Scope – The first step is always to understand what’s on the line. Identifying tangible assets, like databases of information or sensitive files is usually easy. Understanding the capabilities provided by the application and valuing them is more difficult. Less concrete things, such as reputation and goodwill are the most difficult to measure, but are often the most critical.

• Identify Threat Agents and Possible Attacks – A key part of the threat model is a characterization of the different groups of people who might be able to attack your application. These groups should include insiders and outsiders, performing both inadvertent mistakes and malicious attacks.

• Understand Existing Countermeasures – The model must include the existing countermeasures.

• Identify Exploitable Vulnerabilities – Once you have an understanding of the security in the application, you can then analyze for new vulnerabilities. The search is for vulnerabilities that connect the possible attacks you’ve identified to the negative consequences you’ve identified.

• Prioritized Identified Risks – Prioritization is everything in threat modeling, as there are always lots of risks that simply don’t rate any attention. For each threat, you estimate a number of likelihood and impact factors to determine an overall risk or severity level.

• Identify Countermeasures to Reduce Threat – The last step is to identify countermeasures to reduce the risk to acceptable levels.

Benefits

Done right, threat modeling provides a clear “line of sight” across a project that justifies security efforts. The threat model allows security decisions to be made rationally, with all the information on the table. The alternative is to make knee-jerk security decisions with no support. The threat modeling process naturally produces an assurance argument that can be used to explain and defend the security of an application. An assurance argument starts with a few high level claims, and justifies them with either subclaims or evidence.

ThreatModel SDK

The ThreatModel SDK (https://github.com/stevespringett/threatmodel-sdk) is a minimalistic Java library that provides a basic vendor-neutral object model along with the ability to parse reports generated from common threat modeling tools. It currently supports:

• Microsoft Threat Modeling Tool 2016

And plans to support:

• Mozilla SeaSponge

References

• Microsoft’s Security Development Process (https://www.microsoft.com/en-us/securityengineering/sdl)
• Microsoft Threat Modeling (https://www.microsoft.com/en-us/securityengineering/sdl/threatmodeling)

Threat Modeling Cheat Sheet

Introduction

Threat modeling is a structured approach of identifying and prioritizing potential threats to a system, and determining the value that potential mitigations would have in reducing or neutralizing those threats. This cheat sheet aims to provide guidance on how to create threat models for both existing systems or applications as well as new systems.

You do not need to be a security expert in order to implement the techniques covered in this cheat sheet. All developers, software and system designers, and architects should strive to include threat modeling in their software development life cycle. Optimally, you will create your threat models and determine which mitigations are needed during an early stage of the development of a new system, application, or feature. Assessing potential threats during the design phase of your project can save significant resources that might be needed to refactor the project to include risk mitigations during a later phase of the project.

When you produce a threat model, you will:

• Document how data flows through a system to identify where the system might be attacked.
• Document as many potential threats to the system as possible.
• Document security controls that may be put in place to reduce the likelihood or impact of a potential threat.

Note that throughout the document, the terms “systems” and “applications” are used interchangeably. The principles in the document apply equally to designing and building systems such as network infrastructures or server clusters as they do to designing or developing desktop, mobile, or web applications.

Threat Modeling Terminology

You should be familiar with the following terms that will be used throughout this cheat sheet.

A threat agent is an individual or group that is capable of carrying out a particular threat. It is fundamental to identify who would want to exploit the assets of a company, how they might use them against the company, and if they would be capable of doing so. Some threats require more expertise or resources, and thus raise the level of threat actor needed. For example, if a threat requires hundreds of thousands of dollars of computing power to implement, it is likely that only organized corporate, criminal, or government actors would be valid threat actors for such a threat. However, with the rise of cloud computing and the prevalence of attack software on the internet, other threats may be easy to implement with relatively little skill and few resources.

Impact is a measure of the potential damage caused by a particular threat. Impact and damage can take a variety of forms. A threat may result in damage to physical assets, or may result in obvious financial loss. Indirect loss may also result from an attack, and needs to be considered as part of the impact. For example, if your company’s website were defaced this could cause damage to your company’s reputation, which may in turn cause a loss of business because of the loss of confidence by your users. Depending on the business you are in, attacks that expose user information could potentially result in a physical threat of harm or loss of life to your users, greatly raising the impact of threats that would allow such exposure.

Likelihood is a measure of the possibility of a threat being carried out. A variety of factors can impact the likelihood of a threat being carried out, including how difficult the implementation of the threat is, and how rewarding it would be to the attacker. For example, if a threat required a skilled threat actor with tens of thousands of dollars of computing resources to implement, and the only reward was that they were able to gain access to information that is already public in some other form, the likelihood is low. However, if the threat is relatively easy to accomplish, or if the attacker were to gain valuable information from which they could profit, the likelihood may be higher.

Controls are safeguards or countermeasures that you put in place in order to avoid, detect, counteract, or minimize potential threats against your information, systems, or other assets.

Preventions are controls that may completely prevent a particular attack from being possible. For example, if you identify a threat that your users’ personal information may be identified by certain application logging, and you decide to completely remove that logging, you have prevented that particular threat.

Mitigations are controls that are put in place to reduce either the likelihood or the impact of a threat, while not necessarily completely preventing it. For example, if you store your user’s passwords as hashes in a database, two users who have the same password will have the same hash. Thus, if an attacker has access to the hashed passwords and is able to determine the password associated with one hash, he is easily able to find all the other users who share the same password simply by looking for the same hash. However, if you add salts to each user’s password, the cost of this particular attack is greatly increased, as the attacker must crack each password individual. An increase in cost reduces the likelihood, and thus has mitigated the attack.

A data flow diagram is a depiction of how information flows through your system. It shows each place that data is input into or output from each process or subsystem. It includes anywhere that data is stored in the system, either temporarily or long-term.

A trust boundary (in the context of threat modeling) is a location on the data flow diagram where data changes its level of trust. Any place where data is passed between two processes is typically a trust boundary. If your application reads a file from disk, there’s a trust boundary between the application and the file because outside processes and users can modify the data in the file. If your application makes a call to a remote process, or a remote process makes calls to your application, that’s a trust boundary. If you read data from a database, there’s typically a trust boundary because other processes can modify the data in the database. Any place you accept user input in any form is always a trust boundary.

Getting Started

Define Business Objectives

Before starting the threat modeling process it is important to identify business objectives of the applications you are assessing, and to identify security and compliance requirements that may be necessary due to business or government regulation. Having these objectives and requirements in mind before the threat assessment begins will help you to evaluate the impact of any threat you find during the risk analysis process.

Identify application design

Early in the threat modeling process, you will need to draw a data flow diagram of the entire system that is being assessed, including its trust boundaries. Thus, understanding the design of the application is key to performing threat modeling. Even if you are very familiar with the application design, you may identify additional data flows and trust boundaries throughout the threat modeling process.

A thorough understanding of how the system is designed will also help you assess the likelihood and potential impact of any particular threat that you identify.

When you are assessing an existing system that has existing design documentation, spend time reviewing that documentation. The documentation may be out of date, requiring you to gather new information to update the documentation. Or, there may be not documentation at all, requiring you to create the design documents.

In the optimal case, you are performing your assessment during the design phase of the project, and the design documentation will be up-to-date and available. In any event, this cheat sheet outlines steps you can take to create design documents if they are needed.

Create design documents

There are many ways to generate design documents; the 4+1 view model is one of the matured approaches to building your design document.

Reference to 4+1 view model of architecture is at https://en.wikipedia.org/wiki/4%2B1_architectural_view_model.

Please note that the 4+1 is comprehensive, you may use any other design model during this phase.

The following subsections show the details about 4+1 approach and how this could help in the threat modeling process:

Logical View

Create a logical map of the Target of Evaluation.

Audience: Designers.

Area: Functional Requirements: describes the design’s object model.

Related Artifacts: Design model

Implementation View

Audience: Programmers.

Area: Software components: describes the layers and subsystems of the application.

Related Artifacts: Implementation model, components

Please refer to the image in the appendix section for sample design for the implementation view.

Process View

Audience: Integrators.

Area: Non-functional requirements: describes the design’s concurrency and synchronization aspects.

Related Artifacts: (no specific artifact).

Deployment View

Create a physical map of the Target of Evaluation

Audience: Deployment managers.

Area: Topology: describes the mapping of the software onto the hardware and shows the system’s distributed aspects.

Related Artifacts: Deployment model.

Use-Case View

Audience: All the stakeholders of the system, including the end users.

Area: describes the set of scenarios and/or use cases that represent some significant, central functionality of the system.

Related Artifacts: Use-Case Model, Use-Case documents

Decompose and Model the System

Gain an understanding of how the system works to perform a threat model, it is important to understand how the system works and interacts with its ecosystem. To start with creating a high-level information flow diagram, like the following:

1. Identify the trusted boundaries of your system/application/module/ecosystem that you may want to start off with.
2. Add actors – internal and external
3. Define internal trusted boundaries. These can be the different security zones that have been designed
4. Relook at the actors you have identified in #2 for consistency
5. Add information flows
6. Identify the information elements and their classification as per your information classification policy
7. Where possible add assets to the identified information flows.

Define and Evaluate your Assets

Assets involved in the information flow should be defined and evaluated according to their value of confidentiality, integrity and availability.

Consider Data in transit and Data at rest

Data protection in transit is the protection of this data while it’s traveling from network to network or being transferred from a local storage device to a cloud storage device – wherever data is moving, effective data protection measures for in-transit data are critical as data is often considered less secure while in motion.

While data at rest is sometimes considered to be less vulnerable than data in transit, attackers often find data at rest a more valuable target than data in motion.

The risk profile for data in transit or data at rest depends on the security measures that are in place to secure data in either state. Protecting sensitive data both in transit and at rest is imperative for modern enterprises as attackers find increasingly innovative ways to compromise systems and steal data.

Create an information flow diagram

Whiteboard Your Architecture

It is important to whiteboard system architecture by showing the major constraints and decisions in order to frame and start conversations. The value is actually twofold. If the architecture cannot be white-boarded, then it suggests that it is not well understood. If a clear and concise whiteboard diagram can be provided, others will understand it and it will be easier to communicate details.

Manage to present your DFD in the context of MVC

In this step, Data Flow Diagram should be divided in the context of Model, View, Controller (MVC).

Use tools to draw your diagram

If you don’t like to manually draw your DFD; there are several tools available that could be used:

OWASP THREAT DRAGON

The OWASP Threat Dragon project is a cross platform tool that runs on Linux, macOS and Windows 10. Threat Dragon (TD) is used to create threat model diagrams and to record possible threats and decide on their mitigations using STRIDE methodology. TD is both a web application and a desktop application; in active development with version 1.1 released in March 2020.

POIROT

The Poirot tool isolates and diagnoses defects through fault modeling and simulation. Along with a carefully selected partitioning strategy, functional and sequential test pattern applications show success with circuits having a high degree of observability.

MS TMT

The Microsoft Threat Modeling Tool (TMT) helps find threats in the design phase of software projects. It is one of the longest lived threat modeling tools, having been introduced as Microsoft SDL in 2008, and is actively supported; version 7.3 was released March 2020. It runs only on Windows 10 Anniversary Update or later, and so is difficult to use on macOS or Linux.

Define Data Flow over your DFD

Define Data Flows over the organization Data Flow Diagram.

Define Trust Boundaries

Define any distinct boundaries (External boundaries and Internal boundaries) within which a system trusts all sub-systems (including data).

Define applications user roles and trust levels

Define access rights that the application will grant to external entities and internal entities.

Highlight Authorization per user role over the DFD

Highlight Authorization per user role, for example, defining app users’ role, admins’ role, anonymous visitors’ role…etc.

Define Application Entry points

Define the interfaces through which potential attackers can interact with the application or supply them with data.

Identify Threat Agents

Define all possible threats

Identify Possible Attackers threat agents that could exist within the Target of Evaluation. Use Means, Motive, and Opportunities to understand Threats posed by Attackers. Then associate threat agents with system components they can directly interact with.

Work on minimizing the number of threat agents by:

• Treating them as equivalent classes.
• Considering the attacker’s motivation when evaluating likelihood.
• Consider insider Threats

The user of this cheat can depend on the following list of risks and threat libraries sources to define the possible threats an application might be facing:

1. Risks with OWASP Top 10.
2. Testing Procedure with OWASP ASVS.
3. Risks with SANS Top 25.
4. Microsoft STRIDE.

Map Threat agents to application Entry points

Map threat agents to the application entry point, whether it is a login process, a registration process or whatever it might be and consider insider Threats.

Draw attack vectors and attacks tree

During this phase conduct the following activities:

• Draw attack vectors and attacks tree.
• Identify Use Cases/Abuse Cases.
• Re-Define attack vectors to consider multi-step attacks.

Mapping Abuse Cases to Use Cases

TODO

Re-Define attack vectors

In most cases after defining the attack vectors, the compromised user role could lead to further attacks into the application. For example, assuming that an internet banking user credentials could be compromised, the user of this cheat sheet has to then redefine the attack vectors that could result from compromising the user’s credentials and so on.

Write your Threat traceability matrix

Define the Impact and Probability for each threat

Enumerate Attacks posed by the most dangerous attacker in designated areas of the logical and physical maps of the target of evaluation.

Assume the attacker has a zero-day because he does. In this methodology, we assume compromise; because a zero-day will exist or already does exist (even if we don’t know about it). This is about what can be done by skilled attackers, with much more time, money, motive and opportunity that we have.

Use risk management methodology to determine the risk behind the threat

Create risks in risk log for every identified threat or attack to any assets. A risk assessment methodology is followed in order to identify the risk level for each vulnerability and hence for each server.

Here we will highlight two risk methodology that could be used:

DREAD

DREAD is about evaluating each existing vulnerability using a mathematical formula to retrieve the vulnerability’s corresponding risk. The DREAD formula is divided into 5 main categories:

• Damage – how bad would an attack be?
• Reproducibility – how easy it is to reproduce the attack?
• Exploitability – how much work is it to launch the attack?
• Affected users – how many people will be impacted?
• Discoverability – how easy it is to discover the threat?

DREAD formula is:

Risk Value = (Damage + Affected users) x (Reproducibility + Exploitability + Discoverability).

Then the risk level is determined using defined thresholds below.

PASTA

PASTA, Attack Simulation & Threat Analysis (PASTA) is a complete methodology to perform application threat modeling. PASTA introduces a risk-centric methodology aimed at applying security countermeasures that are commensurate to the possible impact that could be sustained from defined threat models, vulnerabilities, weaknesses, and attack patterns.

PASTA introduces a complete risk analysis and evaluation procedures that you can follow to evaluate the risk for each of the identified threat. The main difference in using PASTA Approach is that you should evaluate the impact early on in the analysis phase instead of addressing the impact at the step of evaluating the risk.

The idea behind addressing the impact earlier in PASTA approach is that the audience that knows impact knows the consequences on a product or use case failures more than participants in the threat analysis phase.

Application security risk assessments are not enough because they are very binary and leverage a control framework basis for denoting risks. It is recommended to contextually look at threats impacts, probability and effectiveness of countermeasures that may be present.

R = (T * V * P * I) / Countermeasures

Rank Risks

Using risk matrix rank risks from most severe to least severe based on Means, Motive & Opportunity. Below is a sample risk matrix table, depending on your risk approach you can define different risk ranking matrix:

• Risk Value: 01 to 12 → Risk Level: Notice
• Risk Value: 13 to 18 → Risk Level: Low
• Risk Value: 19 to 36 → Risk Level: Medium
• Risk Value: 37 to 54 → Risk Level: High

Determine countermeasures and mitigation

Identify risk owners and agree on risk mitigation with risk owners and stakeholders. Provide the needed controls in forms of code upgrades and configuration updates to reduce risks to acceptable levels.

Identify risk owners

For the assessors: After defining and analyzing the risks, the assessor should be working on the mitigation plan by firstly identifying risk owners which is the personnel that is responsible for mitigating the risk. i.e. one of the information security team or the development team.

For the designers or the architects: they should assign the risk mitigation to the development team to consider it while building the application.

Agree on risk mitigation with risk owners and stakeholders

TODO

Build your risk treatment strategy

• Reduce: building controls if the form of code upgrades, confirming a specific design for the application or building a specific configuration during the deployment phase to make sure that application risk is reduced.
• Transfer: For a specific component in the application the risk can be transferred to an outsourced third party to develop that component and making sure that the third party is doing the right testing for the component; or during the deployment phase, outsourcing a third party to do the deployment and transferring that risk to that third party.
• Avoid: an example of avoiding the risk is disabling a specific function in the application that is the source for that risk.
• Accept: if the risk is within acceptable criteria set earlier, in that case, the designer risk owner can accept that risk.

For the assessor, this is considered as the last step in the assessment process. The following steps should be conducted by the risk owner, however, the assessor shall engage in 6.5 (Testing risk treatment) to verify the remediation.

Select appropriate controls to mitigate the risk

Selecting one of the controls to reduce the risk, either by upgrading the code, or building a specific configuration during the deployment phase and so on.

Test risk treatment to verify remediation

Mitigation controls will not vanish the risk completely, rather, it would just reduce the risk. In this case, the user of this cheat sheet should measure the value of the risk after applying the mitigation controls. The value of the risk should be reduced to the acceptable criteria set earlier.

Reduce risk in risk log for verified treated risk

After applying the mitigation and measuring the new risk value, the user of this cheat sheet should update the risk log to verify that risk has been reduced.

Periodically retest risk

The OWASP standard awareness document throws more light on the OWASP Top 10 vulnerabilities list, including some common web application vulnerabilities an attacker might target — a critical component for the development of your project.

After you have identified threats and threat agents, move on to the next step, where you will consider the ways an attacker might compromise your app’s data.

References

OWASP (2021). OWASP top ten: Globally recognized by developers as the first step towards more secure coding. https://owasp.org/www-project-top-ten

Step 4: Identify Methods of Attack

In the previous step, you identified threat agents. In this step and in Section 4 of the report, you will identify different methods an attacker can use to reach the data. These data can be sensitive information to the device or something sensitive to the app itself.

Read these resources on cyberattacks.

Cyberattacks

Cyberattacks refer to attacks launched against computer systems, networks, and infrastructure with the intention of committing theft of sensitive data, gaining unauthorized access, and sniffing passwords. These attacks are implemented by individuals, groups, or states and may use malicious software like viruses and worms. The problem of cyberattacks has been acknowledged by the National Institute of Standards and Technology (Johnson et al., 2016).

Cyberattacks have increased in frequency and sophistication, resulting in significant challenges for organizations in defending their data and systems from capable threat actors. These actors range from individual, autonomous attackers to well-resourced groups operating in a coordinated manner as part of a criminal enterprise or on behalf of a nation-state. These actors can be persistent, motivated, and agile, and they employ a variety of tactics, techniques, and procedures (TTPs) to compromise systems, disrupt services, commit financial fraud, and expose or steal intellectual property and other sensitive information. (p. 1)

Cyberattacks can be prevented or their risks minimized if organizations that have faced attack share information with others so that they can deploy resources to combat the threat.

References

Johnson, C., Badger, L., Waltermire, D., Snyder, J., &Skorupka, C. (2016). Computer security: Guide to cyber threat information sharing: Special Publication 800-150, 2nd draft. National Institute for Standards and Technology. http://csrc.nist.gov/publications/drafts/800-150/sp800_150_second_draft.pdf

 

Provide senior management an understanding of the possible methods of attack of your app.

When you have identified the attack methods, move to the next step, where you will analyze threats to your app.

Step 5: Analyze Mobile Application Threats (Lab I will Provide)

You just learned to identify threats and methods of attacks on mobile applications. Now, apply what you have learned by analyzing sample threats using tools in the lab. Identify threat agents and ways they may try to attack your mobile application. Review any previous resource that might help you.

Step 6: Consider Controls

You have identified the methods of attack, and now you will discuss the controls to prevent attacks. Consider the following questions:

Note: Not all of the following may apply. You will address only the areas that apply to the application you have chosen.

• What are the controls to prevent an attack? Conduct independent research and then define these controls by platform (e.g., Apple iOS, Android, Windows Mobile).
• What are the controls to detect an attack? Define these controls by platform.
• What are the controls to mitigate/minimize impact of an attack? Define these controls by platform.
• What are the privacy controls (i.e., controls to protect users’ private information)? An example of this would be a security prompt for users to access an address book or geolocation.
• Create a mapping of controls to each specific method of attack (defined in the previous step)
  • Create a level of assurance framework based on controls implemented. This would be subjective to a certain point, but it would be useful in guiding organizations that want to achieve a certain level of risk management based on the threats and vulnerabilities.

In the next step, you will complete work on the threat model.

Step 7: Complete Your Threat Model

You have just discussed the controls to prevent attacks. You have completed all the components of your report. Now, compile your findings and produce your Threat Model Report.

The following are the deliverables for this project:

Deliverables

• Threat Model Report: An eight- to 10-page double-spaced Word document with citations in APA format. The report should include your findings and any recommendations for mitigating the threats found. The page count does not include figures, diagrams, tables, or citations.
• Lab Report (I will Provide): A Word document sharing your lab experience along with screenshots.