Initial commit

00-introduction.md

@@ -0,0 +1,64 @@
+# CL MSS (Cossack Labs Mobile Security Score)
+CL MSS (Cossack Labs Mobile Security Score) is an actionable mobile security verification framework for product security, security assessments, SSDLC, and measuring security posture.
+
+CL MSS is an extension of an industry standard [OWASP MASVS](https://mas.owasp.org/MASVS/).
+
+We developed CL MSS to address specific risks and threats for mobile apps with increased security risk exposure. The framework covers typical security challenges of mobile applications, with focus on secure mobile app architecture, practical cryptography implementation, and data privacy.
+
+## CL MSS goals are:
+
+- to provide guidance for security engineers, quality assurance engineers, software developers, and architects on how to improve the security of mobile applications;
+- to enumerate the most commonly used security controls and scenarios where they are applicable;
+- to make the security posture of the mobile app measurable and its progress trackable over time.
+
+## Contents of CL MSS
+
+The CL MSS has eight core sections, aligning with MASVS. The additional customisable section #9 is designed for project-specific needs. 
+
+CL MSS requirements can be tailored to project or assessment needs. Not all requirements are relevant to every mobile application. Some requirements may be marked as "not applicable", based on the specific internal logic and business goals. If the app has unique security requirements not listed in CL MSS, they can be added to the #9 section and counted toward the mobile security score of the app.
+
+This guide breaks down security requirements into several levels based on how sensitive the app's data is and its threat model. Similar to OWASP MASVS, the multi-layered approach is represented by the following levels of requirements: 
+
+- L1 — Basic Security Level
+- L2 — Advanced Security Level or Defence-in-Depth
+- R1 — Basic Resilience Level
+- R2 — Advanced Resilience Level
+
+L1 requirements describe the basics of mobile application security that are typically relevant to all mobile applications, even if they do not handle sensitive data. We recommend fulfilling at least 80% of L1 requirements (the more - the better) before proceeding to L2 and R1. It's a Pareto principle approach: Focusing on the efforts that deliver the most security benefit. The remaining 20% can be worked on in parallel to L2 and R1. Even if some L1 requirements are challenging to cover, L2 security control can address the same security risk.
+
+Advanced or defense-in-depth security controls are listed in the L2 requirements. They are relevant for applications handling highly sensitive data, for example, private messaging, e-commerce or social media apps. Implementing these security controls might be challenging. They require complex architectural decisions from software developers. Implementing these security controls may involve several teams: mobile, backend and DevOps engineers.
+
+The R1 level describes basic requirements for resilience against reverse engineering and tampering. The core goal is to detect compromised, rooted, or jailbroken devices and make reverse engineering and tampering more difficult.
+
+R2 represents advanced security controls for resilience. These controls are typically sophisticated and challenging to implement, bringing their own reliability risks. Therefore, R2 requirements are usually implemented only when risk assessment and threat modeling explicitly call for that level of protection.
+
+Resilience requirements can be implemented on top of either L1 or L1+L2. For example, gaming mobile applications typically do not process highly sensitive data, but code modification for cheating is a significant threat. A combination of L1 and R-level requirements can be a good fit for a mobile game. Mobile apps with highly sensitive data, like those in finance, banking, or healthcare, require stricter security measures. This means implementing a defence-in-depth protection: L1, L2 and R-level requirements.
+
+## How to use CL MSS
+
+**Pre-security assessment phase**
+
+1. Download CL MSS sheet. 
+2. Conduct risk assessment and threat modelling. 
+    * If necessary, perform the pre-assessment tailoring in Chapter 9, based on identified risks and threats: add security requirements relevant for a particular product, its domain, local regulations, etc, that are not listed in 8 core sections of CL MSS.       
+
+**Assessment phase**
+
+For each chapter: 
+
+3. Identify the application components; 
+4. Determine if the requirement is met; 
+5. Based on the existing application components and identified risks and threats, mark each item as:
+    * Yes (the requirement is met) 
+    * No (the requirement is not met) 
+    * N/A (not applicable or risk acceptable based on the specific internal logic and business goals)
+
+**Post-assessment phase**
+
+6. Record the status: save values showing the percentage of satisfied requirements by levels and by sections. 
+7. Address identified issues 
+8. Update the status accordingly: if the identified issue is fixed, update the requirement status from “No” to “Yes”.
+9. Compare updated status with the previous one, monitor changes over time to identify areas that need more attention.
+
+
+Note: When calculating the security score for the advanced level, be sure to account for the basic level. This means you should add the number of satisfied L1 and L2 requirements and divide it by the total number of L1 and L2 requirements.

01-architecture.md

@@ -0,0 +1,35 @@
+# 1. Architecture and Design
+
+In mature organizations security considerations are tackled at various levels. It all starts with identifying sensitive assets and conducting risk assessments. This focus on security goes all the way down to each individual process. A Secure Software Development Life Cycle (SDLC), including scheduled periodic risk assessment and threat modeling, is expected from mature organisations. Addressing these procedures typically falls outside the scope of standard external security assessments and demands a more thorough examination. Organisations that follow these best practices tend to have more robust security posture.
+
+Privacy regulations have emerged as a prominent topic of discussion in recent years. Both the Apple App Store and Google Play Market regularly update their store policies and guidelines annually to align with global trends. While security engineers cannot offer legal advice, they can recommend application developers to seek legal guidance whenever privacy-related questions arise.
+
+## Risks and Threats
+
+| # | REQUIREMENT | LEVEL |
+| - | - | - |
+| 1.1 | Data considered sensitive in the context of the mobile app is clearly identified. | L1 |
+| 1.2 | Risk assessment, threat modeling and associated countermeasures documentation was created. | L2 |
+| 1.3 | There is an established process for revisiting and maintaining risk assessment, threat modeling and associated countermeasures documentation. | L2 |
+
+## Documentation and processes
+
+| # | REQUIREMENT | LEVEL |
+| - | - | - |
+| 1.4 | Major app components are identified, documented and known to be needed in terms of business logic. | L2 |
+| 1.5 | Security is addressed within all parts of the software development lifecycle. | L2 |
+| 1.6 | The app has a mechanism for enforcing app updates. | L2 |
+| 1.7 | The app notifies security researchers about responsible disclosure policy within security.txt or similar mechanism. | L2 |
+
+## User Privacy
+
+| # | REQUIREMENT | LEVEL |
+| - | - | - |
+| 1.8	| The app receives user consent before sending user sensitive data to the remote endpoint or storing it locally. | L1 |
+| 1.9	| No sensitive data, including PII, is shared with third-parties unless it is required for app's architecture. | L1 |
+| 1.10 | The app doesn't allow account enumeration and prevents guessing of existing user accounts.	| L1 |
+| 1.11 | Collected and shared PII is listed in data privacy section of app's store page. | L1 |
+| 1.12 | Collected and shared PII documentation exists and explicitly specifies purposes of sharing with particular 3rd parties. | L2 |
+| 1.13 | Screenshots published on App Store and Play Market don't contain any PII or sensitive data, e.g. names or user emails.	| L1 |
+| 1.14 | The app collects PII only if it is required for app's functionality.	| L1 |
+| 1.15 | The app complies with privacy laws and regulations. | L1 |

02-data-storage.md

@@ -0,0 +1,36 @@
+# 2. Data Storage and Privacy
+
+Every security assessment includes an evaluation of secure data storage and protection measures for data-at-rest. Mobile device operating systems and specific development frameworks offer various tools for secure data storage. The role of a security engineer is to determine the optimal secure configuration of system-provided storage that can be used within the app. This choice depends on the sensitivity of assets, desired usability and the nature of the data, recognising that security controls for small pieces of data differ from those for large files.
+
+Developing a mobile application for multiple platforms, such as iOS and Android, should consider variations in the implementation of local data storage for different operating systems. Security engineers must ensure that implementations on both platforms are equally secure. Otherwise, attackers may target and exploit the weaker one.
+
+## Data storage business logic	
+
+| # | REQUIREMENT | LEVEL |
+| - | - | - |
+| 2.1 |	The app follows data minimization principle and stores minimum amount of data that is required for app functionality by design. | L1 |
+| 2.2 |	No sensitive data, e.g. user credentials, private keys or other secrets are hardcoded into the app. |	L1 |
+| 2.3 |	The app keeps sensitive data in memory no longer than it is required for app's functionality. |	L2 |
+| 2.4 |	The app doesn't store sensitive data in a local storage unless it is required for app's functionality. | L2 |
+| 2.5 |	If sensitive data needs to be stored in the local storage, the app keeps it in local storage no longer than it is required for app's functionality. | L2 |
+| 2.6 |	Sensitive data should not be stored in external storage unless it is required for app specific features. | L2 |
+| 2.7 |	The app clears sensitive data on app reinstall unless it is required for anti-abuse mechanisms. | L1 |
+
+## System-provided storage	
+
+| # | REQUIREMENT | LEVEL |
+| - | - | - |
+| 2.8 |	Sensitive data, e.g. user credentials and access tokens, is stored encrypted in an internal storage, e.g. iOS Keychain or Android Encrypted Shared Preferences. | L1 | 
+| 2.9 |	If encryption keys are not meant to leave the device, they should be generated in a hardware-backed cryptographic storage, e.g. Android hardware-backed Keystore or iOS Secure Enclave.	| L2 |
+| 2.10 | If the app doesn't support outdated devices, do not allow using alternatives to hardware-backed encryption, e.g. verify that Android Keystore uses hardware-backed encryption and perform key attestation. |	L2 |
+| 2.11 | When storing highly sensitive data, the app should use an advanced level of encryption, encrypting the data with system-provided encryption and a 3rd-party encryption library. |	L2 |
+| 2.12 | The app uses the most strict access policy for local data and keys storages as app functionality allows, such as requiring the user to set a device passcode. | L2 |
+
+## Device and application-level configuration	
+
+| # | REQUIREMENT | LEVEL |
+| - | - | - |
+| 2.13 | Sensitive data is not included in application backups. | L2 |
+| 2.14 | Sensitive data is not written to application logs. | L1 |
+| 2.15 | Keyboard cache is disabled on fields with sensitive data, e.g. passwords. | L1 |
+| 2.16 | Copying text from fields with sensitive data, e.g. password fields, is disabled except it's required by app funcationality. | L1 |

03-cryptography.md

@@ -0,0 +1,42 @@
+# 3. Cryptography
+
+The evaluation of cryptographic code in mobile applications typically involves a few steps: ensuring that the application uses suitable cryptographic primitives tailored to its needs, verifying the presence of an adequate key management process, including key exchange (e.g., between the mobile app and the server), and confirming that the overall cryptographic scheme is suitable for its intended purpose and meets security requirements.
+
+## Cryptographic primitives	
+
+| # | REQUIREMENT | LEVEL |
+| - | - | - |
+| 3.1 |	The app doesn't implement non-standard cryptography unless it is a direct goal of the app.	| L1 |
+| 3.2 |	Encoding, e.g. with Base64, is not used to protect the data instead of encryption.	| L1 |
+| 3.3 |	The app uses modern hash functions, e.g. SHA256 or SHA512 or BLAKE3, instead of weak ones, e.g. MD5.	| L1 |
+| 3.4 |	Encryption keys are derived from a secret value or a passphrase using a key derivation functions, e.g. Argon2 or PBKDF2.	| L1 |
+| 3.5 |	Key derivation functions should have sufficient parameters (number of rounds, threads, memory cost, etc).	| L1 |
+| 3.6 |	For symmetric cryptography, the app uses AEAD encryption algorithms, e.g. AES-GCM, instead of weak ones, e.g. AES-ECB or AES-CBC.	| L1 |
+| 3.7 |	Random values for cryptographic operations are generated using cryptographically secure pseudo-random number generator.	| L1 |
+| 3.8 |	Nonce, IV and salt should be random and unique for each encrypted or derived value.	| L1 |
+| 3.9 |	Cryptographic primitives should be configured with parameters that adhere to industry best practices.	| L1 |
+| 3.10 |	Non-trivial cryptographic operations are covered with unit tests.	| L2 |
+| 3.11 |	Cryptographic secrets are compared in constant time.	| L2 |
+
+## Key management	
+
+| # | REQUIREMENT | LEVEL |
+| - | - | - |
+| 3.12 |	The app does not rely on symmetric cryptography with hardcoded keys as a sole method of encryption.	| L1 |
+| 3.13 |	Each cryptographic key is used for a particular purpose. The same key is not reused for multiple purposes.	| L2 |
+| 3.14 |	Private keys are not transferred over the network unless it is required by the app's architecture.	| L1 |
+| 3.15 |	If transferring private keys over the network is required for app's architecture, they are not transferred in a plaintext.	| L1 |
+| 3.16 |	Symmetric keys are not transferred over the network in a plaintext.	| L1 |
+| 3.17 |	The app implements key rotation, expiration, revocation mechanisms.	| L2 |
+| 3.18 |	System resources (memory, file descriptors, FFI objects, etc) are correctly managed during cryptographic operations for secrets and keys.	| L2 |
+| 3.19 |	Cryptographic secrets are cleared from memory after use, if it is possible for application language and platform.	| L1 |
+
+## Cryptography in business logic	
+
+| # | REQUIREMENT | LEVEL |
+| - | - | - |
+| 3.20 |	For data integrity and authenticity, the app should use digital signature or HMAC instead of simple hash functions (SHA).	| L1 |
+| 3.21 |	For data integrity, authenticity and non-repudiation, the app should use digital signature. HMAC can be used for non-repudiation if key exchange algorithm guarantees non-repudiation.	| L2 |
+| 3.22 |	The app uses application level encryption for storing or transferring highly sensitive data.	| L2 |
+| 3.23 |	For application level encryption, the app uses key derivation algorithm (like Diffie-Hellman Key Exchange) to generate a shared secret without exposing it to the network.	| L2 |
+| 3.24 |	The app complies with encryption export and import regulations if distributed outside the U.S. or Canada.	| L2 |