Skip to main content

Architectural Security Best Practices

After reading Secure Design Best Practices, architects who are part of a software development team may find this page useful as the weaknesses are addressed by known security tactics, helping the architect in embedding security throughout the initial design process.

Note: some concepts can be found, and applied, also as part of the SW Development Security Best Practices.

See References for more technical details about the Architectural Concepts in Common Weakness Enumeration (CWE).

Modular Design​

Modular design (see Architecture, Principles is a software development approach that divides a system/product into smaller modules or components, each responsible for a specific function. This allows easier development, testing and maintenance activities, since any module can be managed independently and possibly reused in different contexts.

The security design principle of modularity extends the above functional modularity to include security considerations based on availability, confidentiality, access control and security policy (see NIST Special Publication: Modularity and Layering).

This approach offers several advantages for the cyber security:

  1. Isolation: each module is isolated from the others by having its own well-defined interface which restricts access to it. If a module/component is compromised, the impact is reduced since the attacker can gather only limited information and privileges. This approach reduces the overall attack surface and the risk that a vulnerability in one module can compromise the entire system.
  2. Access Control: Specific privileges and security policies can be assigned to each module (granting access only to the resources required by the module), improving control and security level for the whole system.
  3. Maintenance and Scalability: modules can be updated or replaced without affecting the entire system, allowing for a quick response to vulnerabilities in specific components, improving the security of the product/system.

Audit & Log Management​

  1. The product does not neutralize or incorrectly neutralize (see Improper Neutralization) output that is written to logs. Ensure a protection mechanism for logs is in place to prevent an attacker from accessing and forging log entries or injecting malicious content into them.

  2. Do not omit security-relevant information.
    From https://www.datadoghq.com/knowledge-center/audit-logging/ : "The difference between audit logs and regular logs (e.g., error logs, operational logs, etc.) is the information they contain, their purpose (provide proof of compliance and operational integrity), and their immutability (secure storage, read-only access). Whereas regular logs are designed to help developers troubleshoot errors, audit logs help organizations document a historical record of activity for compliance purposes and other business policy enforcement".

    Use Audit Trail, not normal logs, in the above context.

  3. Do not log excessive data and do not clearly log data that could disclose relevant information.

  4. Consider the Log Management requirements to define the proper size of the repository (to keep for example a minimum of three months long period) and how to properly manage when it gets exceeded (consider implementing a circular-buffer mechanism). See https://csrc.nist.gov/Projects/log-management .

Authentication​

  1. Use as much as possible OS native and not simple authentication mechanisms. Where possible, support mutual authentication.

  2. Consider managing periodical changes due to password aging.

  3. Consider the benefits of a multi-factor authentication scheme.

  4. Centralize the authentication mechanism on the server side. A client/server product performing authentication within client code but not in server code, allows server-side authentication to be bypassed via a modified client that omits the authentication check.

  5. A capture-replay flaw exists when the design of the product makes it possible for a malicious user to sniff network traffic and bypass authentication by replaying it to the server in question to the same effect as the original message (or with minor changes). Capture-replay attacks are common and can be difficult to defeat without cryptography.

Authorization​

  1. Do not allow one or more system settings or configuration elements can be externally controlled by a user.

Separation of Privilege​

Implement separation of privilege to compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.

Ensure that appropriate compartmentalization is built into the architectural design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.

  1. Analyze and identify access permissions to OS resources and assign the least privileges (Least Privilege principle) only to applications that need (see Need-To-Know principle) to access them.

  2. Security-relevant or critical information/data should be accessed/managed only by applications requiring High privileges whereas most of the other host applications run without them.

  3. Design your system assuming that the logged-in user has the least privileges. Be as much as possible independent of the logged-in user privileges.

Cross-Cutting​

  1. Consider using a standardized method for handling errors throughout the code (see Software Engineering Institute Exceptions and Error Handling, for example).

  2. If the product uses a protection mechanism that relies on the existence of cookies/tokens… it shall support proper authentication, access control (secure storage) and integrity checks.

Data Encryption​

  1. Analyze sensitive/critical information about the product and evaluate how it must be disclosed to authorized users only, both at rest and in transit.

  2. Use only strong industry-standard algorithms.

Identity​

  1. Ensure to support a proper strong PKI or secure storage and validation check of certificates.

  2. Ensure both the source and destination of a communication channel are validated, if possible.

Limit Access​

  1. Prevent a source from transmitting data to a destination when a portion of the data includes sensitive information that should not be accessible to that destination. Sensitive information could include data that is sensitive in and of itself (such as credentials or private messages), or otherwise useful in the further exploitation of the system (such as internal file system structure).

  2. The product should not perform an operation at a privilege level that is higher than the minimum level required (no Least Privilege properly designed).

  3. Prevent the product form allowing user input to control or influence access paths that are used in operations accessing product resources in the file system.

Limit Exposure​

  1. Carefully assess architectures where the product performs an operation that triggers an external module to generate (sensitive) information not directly controlled by the product itself.

Manage User Sessions​

  1. Authenticating a user, or otherwise establishing a new user session, without invalidating any existing session identifier allows an attacker to steal authenticated sessions.

  2. Consider session expiration mechanisms.

Input Validation​

  1. The product receives input from a component, but it does not neutralize or incorrectly neutralize (or ‘sanitize’) special elements that could be interpreted as control elements by the product or cause a Denial of Service (DoS). See Improper Neutralization as an example.

Message Integrity​

  1. Even if the data can be disclosed (not encrypted) it can be required to ensure that it doesn’t get changed by unauthorized users and therefore an integrity check mechanism be supported. Analyze which data requires an integrity check and apply it for both data in transit and at rest (for example before opening, loading or sending product data) scenarios.

References​

Owner: Cyber Security Team