Security principles

On this page

Hide internal errors

Hide internal errors - only expected errors are shown to consumer

Why This rule is adopted in 21RISK, to make it impossible for an attacker to gain knowledge about the internals of our application by causing malicious requests.

How In the GraphQl API we do this using our custom Apollo GraphQl server plugin. Here we tap into the “will send response” hook, and only allow a subset of trusted error types to be reported to the user. In the case of an unexpected error, we just inform the user that an unexpected error occurred, and show an error id. On the application level (i.e. Sveltekit), we do the same thing in the handle-error hook . In both places, we also log and rapport the error to our centralized error logging system.

Does a resource exists

Don’t let a malicious actor get information about if resources exists

Why This would make it possible for an attacker to identify if a given resource does not exists, or if the user does not have access to the resource yet, but it indeed does exists.

How Mutation validates targeted resources, to make sure they exists and the user have access.

Principle of Least Privilege

The Principle of Least Privilege (PoLP) is a crucial concept in computer security that recommends that every module (such as a user, program, or process) should have the least privileges necessary to perform its duty. This principle limits the potential damage in the event of a security breach by minimizing the access rights for users, applications, systems, and processes to the bare minimum that they require to perform their function. Why

• Minimized Risk Surface: By ensuring that users, programs, and systems only have access to what they need, you're effectively limiting the number of ways an attacker could exploit a system.
• Reduced Impact of Compromise: If a system or account with limited privileges is compromised, the malicious actor can only access a small portion of your system rather than having the full run of your entire network.
• Simplified Audit Trail: If everyone and everything only has access to what they need, it is easier to monitor and identify unusual or suspicious activity.
• Limit Accidental Misconfigurations: PoLP is not only good for security but also for operations. If users only have the permissions they need, they're less likely to unintentionally misconfigure a service or delete important data.

How

• Assess Access Needs: Identify what each user, application, or process needs access to. This involves understanding their role and responsibilities and the resources they need to fulfill their function.
• Implement Role-Based Access Control (RBAC): Assign permissions based on roles and responsibilities rather than individual users. This simplifies managing and tracking access rights.
• Regular Audits and Adjustments: Regularly review and update permissions to ensure they align with current roles and responsibilities. Remove any unnecessary privileges immediately, especially when users change roles or leave the organization.
• Use User and Privilege Management Tools: There are software solutions available that can help manage user accounts and privileges, helping you to enforce the Principle of Least Privilege efficiently.
• Implement Temporary Elevated Access: If a user or process requires elevated access temporarily, grant it, but make sure it is rescinded once the task is completed.

Regular Updates and Patching

At 21RISK, we hold a strong commitment to the security principle of regular updates and patching. This practice ensures that all our software, systems, and applications stay current with the latest advancements and are fortified against known security vulnerabilities.

Why

• Securing Against Known Vulnerabilities: By ensuring regular software updates, we effectively mitigate the risks posed by known vulnerabilities that are addressed in these updates.
• Preventing Zero-Day Attacks: Our commitment to keep all software up to date helps protect us from zero-day attacks, which exploit previously unknown vulnerabilities.
• Enhancing System Performance: Updates frequently contain improvements to system efficiency. By updating our systems regularly, we not only boost security but also improve overall performance and reliability.
• Staying Compliant: Being in a regulated industry, we need to meet specific compliance requirements, which often include keeping software and systems updated. By doing so, we avoid non-compliance penalties and continue to earn the trust of our clients.

How

• Maintaining a Thorough Asset Inventory: We begin by having a complete understanding of our hardware and software assets, which helps ensure that no system is overlooked when it comes to updates.
• Enabling Automated Updates: Whenever possible, we enable automatic updates, which provides the most straightforward path to ensuring up-to-date software.
• Following a Patching Schedule: For systems where automatic updates aren't suitable or desired, we have established a regular schedule for checking and installing updates and patches.
• Performing Risk Assessment: When patches are released, we assess them based on the vulnerabilities they address and the criticality of the systems they affect to prioritize our patching activities.
• Testing Patches: We test patches in a controlled environment before deploying them to our production systems, to avoid any potential disruptions or conflicts. 24
• Utilizing Patch Management Tools: We employ patch management tools that simplify the process, automate patch deployment, and provide a centralized view of our patch status across our infrastructure.

Encryption at 21RISK

At 21RISK, we consider encryption to be one of the key cornerstones of our data security strategy. Encryption transforms data into a format that can only be read by individuals who have the appropriate decryption key. By doing so, we ensure the confidentiality and integrity of our data, whether it's at rest or in transit.

Why

• Data Confidentiality: Encryption ensures that only authorized individuals can read the data. Even if the data is intercepted during transit or accessed without authorization at rest, it cannot be understood without the decryption key.
• Data Integrity: When data is encrypted, any alterations made to the data while it's in transit will result in decryption errors, alerting us to potential tampering.
• Regulatory Compliance: Many industry regulations and standards require data encryption to protect sensitive information. By encrypting our data, we ensure we meet these regulatory requirements.

How

• Encryption in Transit with Vercel: When data is being transmitted between systems, we utilize the HTTPS protocol enforced by the Vercel platform to ensure secure, encrypted connections. HTTPS uses Transport Layer Security (TLS) or its predecessor, Secure Sockets Layer (SSL), to protect the integrity and confidentiality of data as it moves across the network. This means that any data moving to or from our Vercel deployments is encrypted and secure.
• Encryption at Rest with MongoDB Atlas: For data at rest, we use MongoDB Atlas, which automatically encrypts our stored data at the filesystem level. This means that all our data, including backups, is encrypted using strong encryption methods. MongoDB Atlas uses WiredTiger storage engine's native encryption, providing a high level of security for our data at rest.

Through this approach, we ensure that all data within 21RISK, regardless of whether it's being stored or transmitted, is always encrypted. This is part of our ongoing commitment to protecting the security and integrity of our data, and ultimately, the trust of our customers.