Design

Threat Assessment and Security Requirements

For every application built, we shall consider “what could go wrong?” and “How can this happen?” with mitigating factor like “How should we mitigate this from happening?”.

We use the S.T.R.I.D.E. security threat model to identify various types of threats the application is susceptible to during the design phase. Identifying the threats is the first step in a proactive security analysis process. Threats are identified based on the design of the application. The next steps in the process are identifying the vulnerabilities in the implementation and then taking measures to close security gaps. S.T.R.I.D.E. stands for:

• Spoofing of user identity
• Tampering with data
• Repudiability
• Information disclosure (privacy breach)
• Denial of Service (D.o.S.)
• Elevation of privilege

Threat modeling is a team exercise, including everyone from product owners, architects, security professionals and developers, it is integrated into our standard SDLC program and part of our developer culture.

• We use an agreed-upon risk classification that everyone understands.
• The risk classification covers critical aspects of business risks the organization is facing.
• The organization has an inventory for the applications in scope.

Our most important tool to start threat modeling is a whiteboard, smartboard, or a piece of paper. We should always aim for security awareness, a simple process, and actionable outcomes that we agree upon within our team.

What application and data is in scope for the assessment

The first step is to identify what the application does and what kind of data it processes. We shall take note if the application in scope falls under some regulatory demands for us as a business.

Project readme

You shall answer the following questions in the projects README.md file

• The business requirement for this application (description)
• Functional requirements
• Regulatory compliance that might apply
• Security standards in use
• Data classification that is applicable (PII etc. see our data classification section)
• Availability of the application according to the Asset Classification

Determine the applications Privacy Impact Rating (Ex. PII)

Investigate the work needed and how you can lower the applications overall privacy-risk before you invest time in a design or implementation. Higher risk translates to higher development and support cost. For more information regarding our classifications, see our data classification section

• Do we store personally identifiable information (PII) or transfers it from the user’s computer? TS Strictly Confidential information
• Do we continuously monitor the user? TS Strictly Confidential information
• Do we transfer anonymous data? TS Confidential information

If any of the above applies, you shall take the following into account and specify the answers in the README file of the project.

• Describe the PII you store or data you transfer
• Describe your compelling user value proposition and business justification
• Describe your notice and consent experiences
• Describe how users will access your public disclosure
• Describe how you will prevent unauthorized access to PII

Note: A penetration test shall be requested and conducted for every case where a new type of PII or sensitive customer data is ingested.

Note: Projects with an impact rating of TS Strictly Confidential information shall hold a design review with a privacy advisor before investing in implementation.

Some guidelines about data and privacy we follow

• Collect user data only if you have a compelling business and user value
• Collect the smallest amount of data for the shortest period of time
• Collect the least sensitive form of data
• Provide a prominent notice and obtain explicit consent before transferring personal data from the user’s possession
• Prevent unauthorized access to personal data
• Get parental consent before collecting and transferring a child’s personal data
• Provide administrators (at the customer) with a way to prevent transfers
• Honor the terms that were in place when the data was originally collected
• Provide users access to their stored personal data in a structured way
• Respond promptly to user questions about privacy

Risks and benefits

Consider the risk of:

• Unjustifiable Collection of Data (without consent)
• Inappropriate Use of Data (outdated, used in unexpected ways)
• Lost or stolen, unjustifiably accessed, transferred, shared or published

In some cases the benefit to have the data oversights the risks. See CIPL Risk matrix. The range of benefits should include:

• Benefits to individuals (e.g. ability to complete a transaction, obtain a desired good or service, be protected from fraud, enjoy greater efficiency or convenience, and access improved medical treatment and prevention).
• Benefits to the organization (e.g. ability to attract customers, deliver goods or services more efficiently, ensure compliance with other laws and reduce fraud and other legal and commercial risks).
• Benefits to society more broadly (e.g. use of data for social good and development, such as reducing the spread of infectious diseases; enhancing research in health care and other areas that benefit the public; guarding against terrorism, fraud, cyber crimes and other crimes; reducing environmental waste; delivering services to the public with greater efficiency and fairness; etc.).

Technical scope of the assessment

You need to understand the attack surface of the application, this is not just limited by the api exposure itself, but also need to take administrations paths into account etc. You should know what you are runnings, how it is managed and how it is deployed, but also take in to account what dependencies it has.

Following information shall be covered in the projects README

• Application framework
• 3rd party library
• Data store solution
• API endpoints (public facing or internal)
• Network infrastructure (DNS, IPs, certificates etc. for environments)
• Compute infrastructure (app service, functions, etc.)

Design phase

We should previously have built context around what we are running and context around how everything communicates. The key output of this exercise is to understand if you have implicit trust models and where they are. It may be an IoT device talking to the cloud, or an embedded device talking to an automobile component. You may have an implicit trust model that could be a good conduit for exploitation.

In the design phase it is best to work with your architecture to understand the calls and integrations you discovered earlier. Data flow diagrams alone are not threat modeling. A data flow diagram shows the flow of data between callers across trust boundaries, but it has no depiction of threats. It does not illustrate to a developer or to an engineer what they should be worried about. However, it provides a map for analysis.

Goals

• Develop a clear picture of how your system works
• List every service consumed by your system
• Enumerate all the assumptions about the environment and default security configurations
• Create a data-flow diagram that uses the right context depth level

You shall create a Data Flow Diagram and C4 models using DrawIO in in Confluence at the Enterprise Architecture Center 

Ask as many questions as possible about your system. Here are a few questions to consider:

Important: This list is extensive, but not exhaustive. Speak with your colleagues and security team to capture all relevant context for the system.

Break phase

The break phase is where you use the data-flow diagram to find potential threats against your system. The process help you find the most common threats and ways to protect against them.

The scope is based upon your technology selection defined in stage two. You also need to consider your data type, your data model, and your data consumption model. What sort of threats are more pervasive based upon how you’re consuming data? As a threat modeler and security champion, you shall first understand what threats are relevant to you by analyzing threat intelligence that might provide an insight into attack behavior against our industry and our technology footprint. From here, we can start to build and use our internal threat library.

A threat model template shall be used for new applications and new features. The completed documentation shall be stored for new applications in its project readme and for new features together with the Epic description of the feature.

Some useful resources for threat library

• Threat model template
• CAPEC 

Fix phase

The fix phase is where the fate of all threats is decided. Each S.T.R.I.D.E. threat maps to one or more security controls, which offer different functions and types to choose from.

Based on the output from the break phase, Security Officers leverage the classification to define the risk profile to build a centralized inventory of risk profiles and manage accountability. This inventory gives Product Owners, Managers, and other organizational stakeholders an aligned view of the risk level of our application in order to assign appropriate priority to security-related activities. You might also define what triggers updating your threat model, for example, a technology change or deployment of an application in a new environment.

Note: Confluence and Jira shall be used to track and prioritize threats and the tasks to address them.

Verify phase

The verify phase is the last step of the threat-modeling process, which often happens before the system is deployed. It involves ensuring requirements are met, assumptions are validated, and security controls are in place.

Goals

• Confirm that the system satisfies all previous and new security requirements
• Configure cloud provider, operating system, and components to meet security requirements
• Ensure that all issues are addressed with the right security controls
• Take the system through manual and automated verification before deployment

Secure by design. Architecture and principals

People often take the path of least resistance in developing, deploying or operating a software solution. New technologies are often included when they can facilitate or speed up the effort or enable the solution to scale better. These new technologies might, however, introduce new risks to the organization that you need to manage.

Identify the most important technologies, frameworks, tools and integrations being used for each application. Use the knowledge of the architect to study the development and operating environment as well as artefacts. Then evaluate them for their security quality and raise important findings to be managed.

Note: A penetration test shall be requested and conducted for every case where we change or update the access control of a system.

Note: We use centralized single-sign-on services, access control and entitlements services, logging and monitoring services with application-level firewall that everyone shall adhere to.

Authentication

Depending on the classification of the application the required authentication will vary from username password to Entra ID with enforced MFA.

Authorization

What the different type users of the application are allowed to do shall be covered in the documentation for the application. Strive for the Principle of Least Privilege each component and user is granted only the minimal level of access necessary to perform their functions. This limits the damage if an account or component is compromised.

Logging

We should always strive to have centralized log collection and management system in use (SIEM or SEM). See technology we use

Each log entry shall include sufficient information for the intended subsequent monitoring and analysis. It could be full content data, an extract, or just a summary.

The application logs shall record “when, where, who and what” for each event.

When - Always use UTC time if possible.

Where - Setup what application and instance this derive from.

Who - Service or User account, if the later use a tokenization for identification (no PII data).

What - Action taken, what happened.

Always setup to log at least the following

• Input validation failures (note: be advised to not log the user input to avoid log injection attacks)
• Output validation failures (e.g. database record set mismatch etc).
• Authentication successes and failures
• Authorization (access control) failures
• Session management failures
• Application errors and system events e.g. syntax and runtime errors
• Connectivity problems
• Third party errors
• Performance issues
• Configuration changes
• Application and related systems start-ups and shut-downs
• Higher-risk functionality (account and secrets management)

Note: Never log data unless it is legally sanctioned. For example intercepting some communications, monitoring employees, and collecting some data without consent may all be illegal.

Level of logging

Log formatting

Where possible record data in a standard format, or at least ensure it can be exported/broadcast using an industry-standard format. Logging functionality shall be included in code review, application testing and security verification processes.

Secure Error handling

We should

• Follow the list of recommended technologies used in or in support of each application
• Identify and track technological risks (vetting 3rd party libs etc.)
• Ensure the risks to these technologies are in line with the organizational baseline

Code Quality and Secure Code Review

The four eyes principle is enforced on all pull requests to development and production branches using branch protection rules in GitHub. The project should use regular static analysis tools to help catch security issues early on see the list of recommended technologies.

Architectural patterns to adhere to

The project should adhere to the following patterns when they are applicable:

• SOLID 
• DRY 
• YAGNI 
• KIS