Threat Modeling - Must Ask these questions !

The following baseline set of questions to put into Threat Modeling and Analysis in securing any piece of software is very critical.

Authentication and Authorization 

  • How do users and other actors in the system, including clients and servers, authenticate each other so that there is a guarantee against impersonation? 
  •  Do all operations in the system require authorization, and are these given to only the level necessary, and no more (for example, a user accessing a database has limited access to only those tables and columns they really need access to)?

Third-party libraries and components

  • Are all dependencies (both direct and transitive):
  • Updated to mitigate all known vulnerabilities?
  • Obtained from trusted sources (e.g., published by a well-known company or developer that promptly addresses security issues) and verified as originating from the same trusted source?
  • Code-signing for libraries and installers is highly recommended—has code-signing been implemented?
  • Does the installer validate checksums for components downloaded from external sources?
  • Is there an embedded browser (embedded Chromium, Electron framework, and/or Gecko)? If so, please see the “API” entry at the end of this table.

Hardening

  • Has the system design taken into consideration that the system must run in a hardened environment (closed egress ports, limited file system permissions, etc.)?
  • Do the installer and application processes require only the minimum privileges needed to run? Do they drop privileges whenever possible?
  • Are hardened images being used on cloud platforms?
  • Does the app load libraries only using absolute paths?
  • Was isolation of the service (containerization, limiting consumption of host resources, sandboxing) considered in the system’s design?

Cloud services

  • Have the known best practices been followed in design and use of cloud services?
  • Role requirements and secure policies
  • Use of MFA where appropriate
  • A plan for API key rotation
  • Has root access (to your cloud provider management system) been correctly hardened, managed, and configured?
  • Have permissions been tightened for each cloud service?
  • Is all back-channel (server-to-server, internal APIs) communication being routed internally via VPC peering (i.e., back-channel traffic does not go over the public internet)?

Dev/stage/prod practices

  • Are the environments adequately protected?
  • For nonproduction testing environments (especially staging/integration), is test data sourced from production? If so, is sensitive data (e.g., personally identifiable information or customer data) scrubbed or masked before nonproduction use?
  • Is email functionality always tested using company-managed email accounts (i.e., not using public email providers such as test@gmail.com)?
  • Are code reviews performed per commit, by a qualified person (no direct commits to release or main branches)?
  • Is any security feature (login, encryption, object rights management) not covered by unit/function tests?

API

  • Should you be looking into CORS if your API will be made available to browsers?
  • Are you using the right mode of authentication and authorization?
  • Are you considering impersonation? Injection?

Denial of Service 

  • Consider multitenancy—can one tenant generate a computation or I/O that would preclude other tenants from working?
  • Consider storage—can one tenant fill up all storage and stop others from working?

Configuration Management 

  • Is the system set up to be managed by a centralized configuration management tool and/or process, with backed-up and protected configuration files?

Resiliency 

  • Does the system depend on any single point of failure that could suffer a denial-of-service attack?
  • If the system is distributed among many service nodes, is it possible to isolate a part of them, degrading the service but not interrupting it, in case of a localized security breach?
  • Does the system provide feedback controls (monitoring) to allow it to call for help as a denial of service or system probing takes place?

Injection

  • Are all inputs coming from outside the system being inspected for malformed or dangerous input? (This is especially relevant to systems accepting data files; input that gets displayed as part of web pages, binaries, or scripts, or input that gets directly incorporated into SQL queries; and systems that embed interpreters of, among others, Lua, JavaScript, and LISP).

Data minimization and Privacy

  • If we are saving personal data, are we protecting it according to all needed standards and compliance requirements?
  • Do we need to minimize and/or anonymize retained data?

Data retention

  • Together with the issue of data protection in transit and at rest, are we saving and retaining more data than we need?
  • Is data being retained for the time and in the manner required by compliance requirements?

Data encryption in transit and at rest

  • Is all the important data in the system, the crown jewels, protected when it is transmitted between parts of the system and when it is being stored—both from external and internal attackers?

Defense of secrets

  • What are the tokens, keys, credentials, secrets, etc. in your system?
  • How are they protected?
  • Are any secrets distributed with the application (hardcoded)?
  • Are well-established and tested systems being used to store secrets?
  • Are any secrets (API or SSH keys, client secrets, AWS access keys, SSL private keys, chat client tokens, etc.) stored unencrypted in repositories, document shares, container images, local storage in browser, etc.?
  • Are secrets passed in through environmental variables as part of any build/deploy procedures?
  • Are secrets and sensitive data scrubbed from memory as soon as they are used, or is there a possibility that they would be logged?
  • Can keys be easily rotated?

Cryptography

  • Are keys of a sufficient length, and algorithms in use known to be good (no collisions, no easy brute-forcing, etc.)?
  • Are all implementations of crypto well tested and up to their latest known secure patch, and is there no use of cryptography developed in house?
  • Can cryptography be easily configured/updated to adapt to changes?

Auditing

  • Are security-relevant operations being logged?
  • Are logging best practices being followed: no PII, secrets are logged. Logging to a central location, compatible with industry standards such as SIEM, RFC 5424 and 5427, and OWASP. Is AWS CloudTrail being properly used?

Trust Boundaries

  • Can you clearly identify where the levels of trust change in your model?
  • Can you map those to access control, authentication, and authorization?

Access Control 

  • Is access granted in a role-based fashion? Are all access decisions relevant at the time access is performed (token/permissions updated with state-changing actions; token/permissions checked before access is granted)?
  • Are all objects in the system subject to proper access control with the appropriate mechanisms (files, web pages, resources, operations on resources, etc.)?
  • Is access to sensitive data and secrets limited to only those who need it?

Comments

Popular posts from this blog

sde-interview-ramp-up

Installing YUM on OpenSUSE

Youtkit - Java Profiler