Strengthening the Shield: Best Practices for Application Security

Introduction

In an ever-evolving threat landscape, safeguarding the integrity of applications is a real concern. The consequences of a single security breach can be devastating, leading to data links, financial losses, and irreparable damage to a company’s reputation. Organizations across industries must equip themselves with reasonable defense mechanisms to fortify their applications against malicious actors. Here is a list of best practices for Application Security to help enhance your cybersecurity awareness.

Key Points¹

• Use accounts with only the minimum necessary permissions to perform the task
• Use TLS for every connection, even internally and especially for legacy applications.²
• Avoid accounts that are shared across multiple applications, services or departments.
• When possible, prefer delegation over the implementation of authentication and authorization. 
  • Leverage existing methodologies and implementations such as:
    • OAuth
    • Cloud Identity and Access Management (IAM) (Auth0, AWS, Azure, Google, etc…) 
    • On-Premise IAM (Keycloak, Gluu, OpenAM, Ory Ecosystem)
• Use a secret manager (Hashicorp Vault, AWS Secrets Manager, Azure Key Vault, Google Secret Manager, etc…)
  • These then help facilitate the good practice of rotating secret keys or passwords
• Use long, random passwords (if applicable)

Password Storage

If your application stores credentials for users, you should never store them where you can reveal their actual value. Always use a one-way hashing function and store the output from that instead of storing the actual password.

Just choosing a hashing function isn’t enough though, you need to make sure you are using responsible parameters to ensure you are maximizing the value of the risk mitigation the hash function is offering.

Hash algorithms in order of preference:

• Argon2id
  • Recommended starting parameters
    • 19 MiB of memory
    • Iteration Count: 2
    • Degree of Parallelism: 1
• Scrypt
  • Recommended starting parameters
    • cpu/memory cost 2^17
    • Minimum block size: 8 (1024 bytes)
    • Parallelization: 1
• Bcrypt
  • Recommended starting parameters
    • Work factor: 10
    • Password Limit: 72 bytes
• If FIPS-140 compliance is required, use PBKDF2 with a work factor at or over 600k and the hash function using HMAC-SHA-256.

Please note that FIPS-140 compliant methods should only be used if you are required to adhere to FIPS-140 for compliance purposes. In most cases, there are better alternatives if FIPS-140 is not required.

Understand the Attack Surface

If you store credentials in a file or directly in the source code, consider what steps would be necessary to gain access to them. 

• Can a non-admin, but authenticated user, access them?
  Try migrating to reading the credentials from environment variables in your source code. This decouples the storage and retrieval of the credentials from the application, allowing you to migrate to retrieving the credentials from a secure source and providing them to the application through the relevant environment variables.
  
• If you can’t modify the source, restrict access to the file(s) through file system permissions.
• If you are forced to rely on reading credentials from a file, look at adding File Integrity Monitoring to the system to monitor changes to those sensitive files.

Do you have to be a member of a group to access the credentials file? 

• Monitor that group for changes with a SIEM.

Do you know every time the account is used or the file is accessed?

• Monitor authentication events with a SIEM. You can also leverage built-in features of most modern operating systems to monitor file access and send those logs to a SIEM as well.

Does your application run on Microsoft Windows? With advanced auditing policies ³ , you can enable file system auditing. ⁴

If your application runs on Linux, auditd ⁵ can provide, among other features, file access auditing.

Is the account used by multiple applications or services?

• Creating new accounts is easier and cheaper than recovering from a breach. Create dedicated accounts and avoid sharing them with other services.

Encryption

There are two fundamental forms of encryption, transport and data.

• Transport encryption, such as TLS and some VPN software (WireGuard, IPSec) provides communication security over a computer network.
• Data encryption addresses the security of data whether it is at rest or in transit. 

Transport encryption is not a replacement for data encryption nor is data encryption an alternative to transport encryption.

Transport Encryption

Transport encryption, which will typically happen over an open network connection where any listening party can at the very least, capture the packets, will prevent those listening parties from identifying what was transmitted during the session. 

Those listening parties can still identify (in most cases) who (the source) was sending something and where it was going (the destination) but the actual data going from one to the other would have been safe.

Thus, transport encryption, when configured appropriately ⁶ , mitigates eavesdropping or man-in-the-middle attacks on network traffic.

Data Encryption 

Data encryption mitigates the ability to read data while it is at rest, meaning that no one is trying to read/write to a file or using a computer that has disk encryption.

Good data encryption practices result in having 3 components to encrypt and decrypt something, commonly referred to as envelope encryption ^{7 8} :

1. A data encryption key (DEK), which is used to encrypt/decrypt the data
   • Kept near the data it encrypts
   • Ideally use a separate DEK every time you write data, thus avoiding the need to rotate the DEK.
2. A key encryption key (KEK), which is used to encrypt/decrypt the DEK.
   • Stored centrally
   • Rotate regularly
3. A passphrase to decrypt the KEK
   • This is usually a password that is run through what is called a key derivation hash function (KDF or KDHF), similar to the one-way hash described under Password Storage.
   • The output of the KDF is the actual decryption key for the KEK.

For envelope encryption to work, the key encryption key needs to be kept separate from the data encryption key.

Data encryption can be applied at a number of different levels in your application stack, such as:

• At the application level
• At the database level
• At the system level (files, file system and hardware)

Application-level Encryption

Encrypting data at the application level addresses the threat that exists when transmitting data over an insecure medium, such as in an e-mail or text message. Typically these services also employ transport encryption but data encryption ensures that only the intended recipient can read the actual message contents. 

It’s important to understand the limitations of certain services and what the mitigations or preventions you implement actually do.

For instance, when sending an e-mail, if you did not encrypt the message body, then any server along the path before the message was delivered to the recipients mail server, also the copy of the message stored in your sent items and the copy that the recipient received, is readable by anyone with access to those servers. 

If you had encrypted the message body, then only the e-mail headers attached to the message, which are required to deliver the message to the recipient, would be readable by those servers and staff, but not the message contents.

Database-level Encryption

Similar to system-level encryption (described below), most forms of database encryption operate only on the data and logs associated with the database. In order for the database to be of any use, those are decrypted while it is running and then encrypted when it is not.

In most cases, sensitive data that needs to be retrieved (unlike the output from a one-way hash function) should be encrypted following envelope encryption best practices. 

System-level Encryption

The threat that encryption performed at the filesystem and hardware level are addressing, is typically one of physical security. 

Consider a scenario where your bag was stolen and it had your laptop in it. If your laptop was encrypted at the hardware or filesystem level and powered off, as long as you have a strong, brute-force resistant password that secures the key for decrypting the laptop, you theoretically have prevented any unintended parties from gaining access to your data.

However, if someone stole your laptop while it was powered on and you were logged in, most device encryption is rendered useless. This is because in order for the majority of systems to function, the data or disks need to be decrypted in order for you to use them.

Another good use case for encryption at rest is with remote backups. Encrypting the backups stored in a remote location, prevents unintended parties from reading the backup data.

For this reason, encryption at the system level must be used in conjunction with strong operational security and proven IT policies.

Threat Modeling ^{9 10}  

This is a structured approach for identifying and prioritizing potential threats to a system and determining the value that potential mitigations would have in reducing or neutralizing those threats.

Threat modeling is a complex topic, so we won’t dive into details, however the key takeaways are:

• Identify the threat agents or actors who would want to exploit the assets of your company
• Measure the Impact a potential threat could cause.
• Measure the Likelihood of a threat being carried out.
  • Does an attacker need access to a physical key that remains locked in a safe except once a year during disaster recovery testing? The likelihood of the attack succeeding is then extremely low. But also consider auditing that the key is in the safe and ensure that the safe combination is rotated when new people are hired or leave the company. 
• Build Controls to avoid, detect, counteract and minimize potential threats.
  • Preventions are controls that should completely prevent a particular attack path from being possible.
  • Mitigations are controls for reducing the likelihood or impact of threat but may not completely prevent it.

¹ Sedara does not endorse any vendors or products listed here.
²https://en.wikipedia.org/wiki/Stunnel
³ https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/advanced-security-audit-policy-settings
⁴https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/audit-file-system
⁵https://linux.die.net/man/8/auditd
⁶https://en.wikipedia.org/wiki/Forward_secrecy
⁷https://cloud.google.com/kms/docs/envelope-encryption
⁸https://docs.aws.amazon.com/kms/latest/cryptographic-details/crypto-primitives.html
⁹https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html
¹⁰https://www.threatmodelingmanifesto.org/