The first thing is to determine the protection needs of data in transit and at rest. For example, passwords, credit card numbers, health records, personal information, and business secrets require extra protection, mainly if that data falls under privacy laws, e.g., EU's General Data Protection Regulation (GDPR), or regulations, e.g., financial data protection such as PCI Data Security Standard (PCI DSS). [1]
Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation)
Personal Data as defined in GDPR
- Name and surname
- Home address
- Email address
- Identification card number
- Location data (for example on a mobile phone)
- Internet Protocol (IP) address
- ...
§ Articles 2, 4(1) and(5) and Recitals (14), (15), (26), (27), (29) and (30)
Sensitive Personal Data as defined in GDPR
- Personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs
- Trade-union membership
- Genetic data, biometric data processed solely to identify a human being
- Health-related data
- Data concerning a person's sex life or sexual orientation
§ Article 4(13), (14) and (15) and Article 9 and Recitals (51) to (56)
PCI DSS is the global data security standard adopted by the payment card brands for all entities that process, store or transmit cardholder data and/or sensitive authentication data.
| Goals | Requirements |
|---|---|
| Secure Network and Systems | Firewall; No default credentials |
| Protect Cardholder Data | Protect stored data; encrypt transmissions |
| Vulnerability Management | Anti-Malware/-Virus; Secure Development |
| Strong Access Controls | Need-to-know access; Authentication; Restrict physical access |
| Monitoring & Testing | Monitor network and data access; Test systems/processes |
| Security Policy | Maintain Information Security policy for all personnel |
- Clear text data transmission (e.g. HTTP, SMTP, FTP)
- Using old or weak cryptographic algorithms or protocols
- Using default crypto keys or generate/re-use weak ones
- Lack of proper key management or rotation
- Crypto keys are checked into source code repositories
- No enforcement of encryption, e.g. missing security directives or headers
ℹ️ External internet traffic is hazardous. Verify all internal traffic, e.g., between load balancers, web servers, or back-end systems.
- Insufficient certificate and trust chain validation
- Ignoring, reusing or generating insecure initialization vectors for the cryptographic mode of operation
- Using an insecure mode of operation such as ECB
- Not using authenticated encryption when appropriate
- Use passwords as cryptographic keys in absence of a password base key derivation function
- Using insecure randomness functions or seed them weakly
- Using deprecated (e.g. MD5 or SHA1) or non-cryptographic hash functions or deprecated cryptographic padding methods (e.g. PKCS number 1 v1.5)
- Allow cryptographic error messages or side channel information to become exploitable, for example in the form of padding oracle attacks
| CWEs Mapped | Max Incidence Rate | Avg Incidence Rate | Avg Weighted Exploit | Avg Weighted Impact | Max Coverage | Avg Coverage | Total Occurrences | Total CVEs |
|---|---|---|---|---|---|---|---|---|
| 29 | 46.44% | 4.49% | 7.29 | 6.81 | 79.33% | 34.85% | 233,788 | 3,075 |
- Classifying data processed, stored, or transmitted by an application
- Identify sensitive data according to privacy laws, regulatory requirements, or business needs
- Not storing sensitive data unnecessarily and discarding it as soon as possible 💯
- Encrypting all sensitive data at rest
- Ensuring up-to-date and strong standard algorithms, protocols, and keys are in place while using proper key management
- Encrypting all data in transit with secure protocols (e.g. TLS with forward secrecy (FS) ciphers), cipher prioritization by the server, and secure parameters
- Enforcing encryption with directives like HTTP Strict Transport Security (HSTS)
- No caching of responses that contain sensitive data
- Applying required security controls as per the data classification
- Not using legacy protocols (e.g. FTP and SMTP) for transporting sensitive data
- Storing passwords using strong adaptive and salted hashing functions with a work factor (delay factor)
- Verifying independently the effectiveness of configuration and settings
| Class | Description | Examples |
|---|---|---|
| Public | Information without any confidentiality requirements. | User documentation, news, press releases, lunch menus |
| Internal | Common information inside an organization. | Memos, system documentation or meeting minutes |
| Confidential | Information or compartmental data with restricted access. Disclosure might induce damage. | Customer, HR, financial or PII data; source code, credentials, logfiles |
| Secret | Highest confidentiality and integrity requirements. Damaging to organization if disclosed. | Business secrets, secret formulae, planned mergers/acquisitions |
For each classification level decide if the listed practices should be allowed (:heavy_check_mark:) or strictly forbidden (:x:). Use footnotes to describe preconditions (if necessary).
| Practice | Public | Internal | Confidential | Secret |
|---|---|---|---|---|
| Publish on Internet | ||||
| Publish on Intranet | ||||
| Print on 🖨️ | ||||
| Share with third parties | ||||
| Copy to USB key |
For each classification level define restrictions (:red_circle:) and/or recommendations (:o:) for the listed lifecycle phases.
| Phase | Public | Internal | Confidential | Secret |
|---|---|---|---|---|
| Permanent storage |
||||
| Transfer (internal network) |
||||
| Transfer (public network) |
||||
| Disposal |
HTTP Strict Transport Security (HSTS) is an opt-in security enhancement that is specified by a web application through the use of a special response header. Once a supported browser receives this header that browser will prevent any communications from being sent over HTTP to the specified domain and will instead send all communications over HTTPS. It also prevents HTTPS click through prompts on browsers.
Strict-Transport-Security: max-age=16070400; includeSubDomains- Only store sensitive data that you need
- Use strong approved Authenticated Encryption
- Store a one-way and salted value of passwords
- Ensure that the cryptographic protection remains secure even if access controls fail
- Ensure that any secret key is protected from unauthorized access
- Follow applicable regulations on use of cryptography
Perfect forward secrecy means that a piece of an encryption system automatically and frequently changes the keys it uses to encrypt and decrypt information, such that if the latest key is compromised, it exposes only a small portion of the user’s sensitive data. Encryption tools with perfect forward secrecy switch their keys as frequently as every message in text-based conversation, every phone call in the case of encrypted calling apps, or every time a user loads or reloads an encrypted web page in his or her browser.
ℹ️ Examples of crypto protocols (used for instant messaging conversations) providing PFS are OTR (Off-the-record) Messaging and Double Ratchet (used within Signal).
| Scenario | Practice | 🔑 Length |
|---|---|---|
| Key exchange | Diffie-Hellman | 2048+ bits |
| Message Integrity | HMAC-SHA2 | - |
| Message Hash | SHA2 | 256 bits |
| Asymetric encryption | ECC (Curve25519), RSA | 2048 bits (RSA) |
| Symmetric-key algorithm | AES | 128-256 bits |
| Password Hashing | Argon2id, scrypt, PBKDF2 | - |
- Access a confidential document (:star:)
- Retrieve as many clear text user passwords as you can (:star::star::star::star:)
- Visit the Token Sale page before it officially goes live (:star::star::star::star::star:)
- Retrieve both the 🐇 easter eggs (⭐⭐⭐⭐)
- Solve the steganography challenge (:star::star::star::star:)
- Solve the non-existent challenge #999 (:star::star::star::star::star::star:)