security project that is already underway, but needs

Project 3 CST620 Project 3: Mobile Application Threat Modeling [MUSIC PLAYING] 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 underway, 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.” Step 1. Describe Your Mobile Application Architecture In your role as a cyber threat analyst, you will identify for senior management how a particular mobile application of your choosing conforms to mobile architectures where you are asked to describe device-specific features used by the application, wireless transmission protocols, data transmission mediums, interaction with hardware components, and other applications. You will identify the needs and requirements for application security, computing security, and device management and security. You will describe the operational environment and use cases, and 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. Be sure to use APA citation format. This will be part of your final report. To guide you in your completion of this task, click the following links and review the topics and their resources: • network security threats • threat modeling • mobile architectures • application security • operating system security • enclave/computing environment Begin by first reviewing the OWASP Mobile Security Project Testing Guide. 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 are to address a number of questions as they apply to your selected mobile application. 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 protocols and security, mobile security vulnerabilities, and related technologies and their security. Related technologies can include hardware and software that are 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 architecture considerations for mobile applications and architecture. Then, in your report to senior management, include those that are relevant to your mobile application. 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. OWASP Mobile Security Project: Security 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. Plea
se 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 o 3G/4G o WiFi o Bluetooth o Near Field Communication (NFC) o 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? o credit card transactions and/or stored payment information o in-app purchasing of goods or features • Monitor and identify the hardware components that the application may potentially interact with the following: o NFC o Bluetooth o GPS o camera o microphone o 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: o telephony (SMS, phone) o contacts o Google Wallet o iCloud o social networks (i.e., Facebook, Twitter, LinkedIn, Google+) o Dropbox o Evernote o e-mail • Can you determine anything about the server-side application environment? o hosting provider (AWS, App Engine, Heroku, Rackspace, Azure, etc.) o development environment (Rails, Java, Django, ASP.NET, etc.) o Does the application leverage Single Sign On or Authentication APIs (Google Apps, Facebook, iTunes, OAuth, etc.)? o 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. o leaking credentials o resources not exposed through the UI o error messages o 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. o extract the application from the device o follow the appropriate steps for your platform’s application reverse engineering o 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: o are up to date o are free of vulnerabilities o 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. o from web service calls o receiving data from other apps and on-device services o inbound SMS messages o 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. • Dete
rmine if the application utilizes information beyond username/password, such as the following: o contextual information (i.e., device identifiers, location) o certificates o tokens • Does the application utilize visual swipe or touch passwords vs. conventional usernames and passwords? o 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)? o Does the application properly authenticate the remote user or peer prior to granting access to device resources? o How does the application handle excessive failed attempts at authentication? • Single sign-on o OAuth o Facebook o Google Apps • SMS o How is the sender authenticated?  password  header information o Are one-time passwords (OTP) used, or is other sensitive account data transmitted via SMS?  Can other applications access this data? • Push notifications o 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. o Identify if the application has role-specific functionality within the mobile application. o 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 o Find places within an application that were not anticipated being directly accessed without following the application’s intended workflow. • Licensing o 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)? o Does the code suggest that licensed content is served with a nonlicensed app but restricted by UI controls only? o Are licensing checks performed properly by the server or platform licensing services? o 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 o Are the algorithms used “best of breed,” or do they contain known issues? o Based on the algorithms and approaches used to encrypt data, do implementation issues exist that degrade the effectiveness of encryption? o 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: o places with limited access control granularity (SD card, tmp directories, etc.) o directories that may end up in backups or other undesired locations (iTunes backup, external storage, etc.) o 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: o credentials  username and password  API keys  authentication tokens o payment information o patient data o 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: o the certificate has not expired o the certificate was issued by a valid certificate authority o 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 o Does the application log sensitive information to a globally shared log? o Can any of the logged information be considered a privacy violation? • Caches o predictive text o location information o browser cache • Exceptions o Does sensitive data leak in crash logs? • Third-party libraries and APIs o What permissions do they require? o Do they access or transmit sensitive information? o 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 Step 2: Define the Requirements for Your Mobile Application In the previous step, you described your app’s architecture. For Step 2 and in the second section of your report, you will define what purpose the mobile app serves from a business perspective and what data the app will store, transmit, and receive. It’s also important to include a data flow diagram to determine exactly how data is 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: • What is the business function of the app? • What data does the application store/process (provide data flow diagram)? o This diagram should outline network, device file system, and application data flows o How is data transmitted between third-party APIs and app(s)? o Will there be remote access and connectivity? Read this resource about mobile VPN security, and include any of these security issues in your report. o Are there different data-handling requirements between different mobile platforms? (iOS/Android/Blackberry/Windows/J2ME) o Does the app use cloud storage APIs (e.g., Dropbox, Google Drive, iCloud, Lookout) for device data backups? o Does personal data intermingle with corporate data? o Is there specific business logic built into the app to process data? • What does the data give you (or an attacker) access to? Think about data at restand data in motion as they relate to your app. Do stored credentials provide authentication? Do stored keys allow attackers to break crypto functions (data integrity)? • Third-party data: Is it being stored and/or transmitted? What are the privacy requirements of user data? Consider, for example, a unique device identifier (UDID) or geolocation being transmitted to a third party. Are there regulatory requirements to meet specific-to-user privacy? • How does other data on the device affect the app? Consider, for example, authentication credentials shared between apps. • Compare the impacts of jailbroken devices (i.e., a device with hacked or bypassed digital rights software) and non-jailbroken devices. How does the differences affect app data? This can also relate to threat agent identification. When you have defined the 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 mobile app’s requirements, you will define its threats. In Section 3 of the report, you will identify possible threats to the mobile application and also identify the threat agents. Additionally, you will outline the process for defining what threats apply to your mobile application. For an example of threat agent identification, review Threat Agent Identification Example. For a list of threat agents, review List of Threat Agents. After you’ve identified threats and threat agents, move to the next step, where you will consider the kinds of ways an attacker might use to reach your app’s data. Step 4: Identify Method
s 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. This data can be sensitive information to the device or something sensitive to the app itself. Read these resources on cyberattacks and provide senior management with 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. 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, Badger, Waltermire, Snyder, & Skorupka, 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. Cyberattacks can be prevented or their risks minimized if organizations who have faced attack share information with others so that they can deploy resources to combat the threat. Reference Johnson, C., Badger, L., Waltermire, D., Snyder, J., & Skorupka, C. (2016). Computer security: Guide to cyber threat information sharing.(NIST Special Publication 800-150, 2nd draft). Retrieved from Resources • A Copyright Protection Scheme for Digital Images Based on Shuffled Singular Value Decomposition and Visual Cryptography • Spoofing Attacks on Packets and Methods For Detection and Prevention of Spoofed Packets • Insecure Randomness • Digital Watermarking • Robust Image Watermarking Theories and Techniques: A Review • Cache Poisoning • Cyber Attacks Explained: Cryptographic Attacks • SQL Injection Prevention Cheat Sheet • Testing for Padding Oracle • Stochastic Image Warping for Improved Watermark Desynchronization • Covert Encryption and Document Authentication Using Texture Coding • Video Multiple Watermarking Technique Based on Image Interlacing Using DWT • Lossy Compression of Noisy Images Based on Visual Quality: A Comprehensive Study • Anticollusion Attack Noninteractive Security Hierarchical Key Agreement Scheme in WHMS • Collusion-Resistant Audio Fingerprinting System in the Modulated Complex Lapped Transform Domain • Intrusion Recovery for Database-backed Web Applications • Collusion-Tolerable and Efficient Privacy-Preserving Time-Series Data Aggregation Protocol • A Network of Internet Probes for Fighting Cyber Attacks • A Reliable Image Watermarking Scheme Based on Redistributed Image Normalization and SVD • Analysis of Insiders Attack Mitigation Strategies Step 5: Analyze Mobile Application Threats 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. Note: You will use the tools in Workspace for this step. If you need help outside the classroom, you can register for the CLAB 699 Cyber Computing Lab Assistance (go to the Discussions List for registration information) in which you can access resources to enable you to complete this project successfully. Click here to access the instructions for Navigating the Workspace and the Lab Setup. Click here to access the Project 3 Workspace Exercise Instructions. Explore the tutorials and user guides to learn more about the tools you will use. Then, enter Workspace. After you have analyzed threats, you will take a look at controls in the next step. Step 6: Controls You’ve just 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 need to address only the areas that apply to the application you have chosen. • What are the controls to prevent an attack? Conduct independent research, then define these controls by platform (e.g., Apple iOS, Android, Windows Mobile, BlackBerry). • 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) o 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 who want to achieve a certain level of risk management based on the threats and vulnerabilities Step 7: Complete Your Threat Model You’ve just discussed the controls to prevent attacks. By now you should have completed all the components of your report. Now, you will compile all your findings and produce your threat model. When you have completed the Workspace exercise, provide a 8-10 page double-spaced Word document including your findings and any recommendations for mitigating the threats found with citations in APA format. The page count does not include figures, diagrams, tables or citations. Submit your threat model report to the Assignments folder. Before you submit your assignment, review the competencies below, which your instructor will use to evaluate your work. A good practice would be to use each competency as a self-check to confirm you have incorporated all of them in your work. • 1.1: Organize document or presentation in a manner that promotes understanding and meets the requirements of the assignment. • 1.2: Develop coherent paragraphs or points to be internally unified and function as part of the whole document or presentation. • 1.3: Provide sufficient, correctly cited support that substantiates the writer’s ideas. • 1.4: Tailor communications to the audience. • 2.1: Identify and clearly explain the issue, question, problem under consideration. • 2.2: Locate and access sufficient information to investigate the issue or problem. • 2.5: Develop well-reasoned ideas, conclusions, checking against relevant criteria. • 6.3: Specify security solutions based on knowledge of principles, procedures, & tools of data mgmt, such as modeling techniques, data backup, data recovery, data directories, data warehousing, data mining, data disposal, & data standardization processes.

Leave a Reply

Your email address will not be published. Required fields are marked *