Adventures in the programming jungle

The threat modeling process have 3 phases:

1. model the system for which you want to find the threats.
2. find the threats.
   1. STRIDE model.
   2. attack trees – An attack tree is a hierarchical tree-like structure, which has either an attacker’s objective (e.g., gain administrative level privilege, determine application makeup and configuration, bypass authentication mechanisms, etc.) or a type of attack
      (e.g., buffer overflow, cross site scripting, etc.) at its root node.
3. address each threat found in the previous step. Once identified,each threat must be evaluated according to the risk attached to it. There are several ways to quantitatively or qualitatively determine the risk ranking for a threat. These range from the simple, non-scientific, Delphi heuristic methodology to more statistically sound risk ranking using the probability of impact and the business impact.
4. document and validate.

More details about threat modeling can be found here : Threat Modeling for mere mortals and (My) OWASP BeNeLux Days 2016 Notes – Training Day.

Design Considerations

This part is linked to the Secure Software Concepts and contains how the security software concepts can be applied to have a secured application.

• confidentiality – use cryptographic and masking techniques
• integrity – use hashing (or hash functions), referential integrity design (uses primary keys and related foreign keys in the database to assure data integrity), resource locking (when two concurrent operations are not allowed on the same object (say a record in the database), because one of the operations locks that record from allowing any changes to it, until it completes its operation, it is referred to as resource locking), and code signing.
• availability – replication, fail-over and scalability techniques can be used to design the software for availability.
• authentication – use multi-factor authentication and single sign on (SSO). Rely of already existing mechanism if possible (like the ones offered by the operating system).
• authorization – rely of already existing mechanism if possible.
• accounting (audit) – determine of what elements should be logged and under what circumstances.

• improper implementation of least privilege
• software fails insecurely
• authentication mechanisms are easily bypassed
• security through obscurity
• improper error handling
• weak input validation

Architecture system with secured design principles:

• good enough security – care should be taken to ensure that the security elements are in response with the actual risk associated with the potential vulnerability; do not over-engineer.
• least privilege – use of accounts with non-administrative abilities.
  Modular programming is a software design technique in which the entire program is broken down into smaller sub-units or modules. Each module is discrete with unitary functionality and is said to be therefore cohesive, meaning each module is designed to perform one and only one logical operation.
• separation of duties – the programmer should not be allowed to review his own code nor should a programmer have access to deploy code to the production environment.
• defense in depth
  • use of input validation along with prepared statements or stored
    procedures, disallowing dynamic query constructions using user
    input to defend against injection attacks.
  • disallowing active scripting in conjunction with output encoding
    and input- or request-validation to defend against Cross-Site
    Scripting (XSS).
• fail safe
  • the user is denied access by default and the account is locked out after the maximum number (clipping level) of access attempts is tried.
  • errors and exceptions are explicitly handled and the error messages are non-verbose in nature.
  •  not designing the software to ignore the error and resume next
    operation
• economy of mechanism – trade-off that happens between the
  usability of the software and the security features that need to be designed and built in.
  • Unnecessary functionality or unneeded security mechanisms should be avoided.
  • Strive for simplicity.
  • Strive for operational ease of use.
• complete mediation –
• open design – the inverse of the open design principle is security through obscurity, which means that the software employs protection mechanisms whose strength is dependent on the obscurity of the design.
• least common mechanism – mechanisms common to more than one user or process are designed not to be shared. Design should compartmentalize or isolate the code (functions) by user roles, since this increases the security of the software by limiting the exposure.
• psychological acceptance – security principle that states that security mechanisms should be designed to maximize usage, adoption, and automatic application.The security protection mechanisms:
  • are easy to use,
  • do not affect accessibility.
  • are transparent to the user.
• weakest link – when designing software, careful attention must be
  given so that there are no exploitable components.
• leverage existing components – reusing tested and proven, existing libraries and common components has good security benefits.