Monday, May 30, 2022

chaos engineering

  •  Chaos engineering techniques


One simple test, for instance, simply deletes half of the data packets coming through the internet connection. Another might gobble up almost all the free memory so the software is scrambling for places to store data.


The tests are often done at a higher level. DevSecOps teams may simply shut down some subset of the servers to see if the various software packages running in the constellation are resilient enough to withstand the failure. Others may simply add some latency to see if the delays trigger more delays that snowball and eventually bring the system to its knees


Almost any resource such as RAM, hard disk space, or database connections is fair game for experimentation. Some tests cut off the resource altogether and others just severely restrict the resource to see how the software behaves when squeezed


Buffer overflow problems, for instance, are relatively easy for chaos tools to expose by injecting too many bytes into a channel. 


Fuzzing is also adept at revealing flaws in parsing logic. Sometimes programmers neglect to anticipate all the different ways that the parameters can be configured, leaving a potential backdoor

Bombarding the software with random and semi-structured inputs can trigger these failure modes before attackers find them


Some researchers moved beyond strictly random injection and built sophisticated fuzzing tools that would use knowledge of the software to guide the process using what they often called “white box” analysis



One technique called grammatical fuzzing would begin with a definition of the expected data structure and then use this grammar to generate test data before subverting the definition in hope of identifying a parsing flaw.


Chaos engineering tools

The tools that began as side projects and skunkworks experimentation for engineers, and now growing into trusted parts of many CI/CD pipelines.  Many of the tools are staying open-source projects produced by other DevSecOps specialists and shared openly


https://www.csoonline.com/article/3646413/how-chaos-engineering-can-help-devsecops-teams-find-vulnerabilities.html


  • Chaos Engineering is the discipline of experimenting on a system in order to build confidence in the system’s capability to withstand turbulent conditions in production.


Even when all of the individual services in a distributed system are functioning properly, the interactions between those services can cause unpredictable outcomes. Unpredictable outcomes, compounded by rare but disruptive real-world events that affect production environments, make these distributed systems inherently chaotic.


Systemic weaknesses could take the form of:

improper fallback settings when a service is unavailable

retry storms from improperly tuned timeouts

outages when a downstream dependency receives too much traffic

cascading failures when a single point of failure crashes


An empirical, systems-based approach addresses the chaos in distributed systems at scale and builds confidence in the ability of those systems to withstand realistic conditions. We learn about the behavior of a distributed system by observing it during a controlled experiment. We call this Chaos Engineering.


CHAOS IN PRACTICE


To specifically address the uncertainty of distributed systems at scale, Chaos Engineering can be thought of as the facilitation of experiments to uncover systemic weaknesses. These experiments follow four steps:


Start by defining ‘steady state’ as some measurable output of a system that indicates normal behavior.

Hypothesize that this steady state will continue in both the control group and the experimental group

Introduce variables that reflect real world events like servers that crash, hard drives that malfunction, network connections that are severed, etc.

Try to disprove the hypothesis by looking for a difference in steady state between the control group and the experimental group.


The harder it is to disrupt the steady state, the more confidence we have in the behavior of the system. 

If a weakness is uncovered, we now have a target for improvement before that behavior manifests in the system at large



ADVANCED PRINCIPLES


Build a Hypothesis around Steady State Behavior

Focus on the measurable output of a system, rather than internal attributes of the system. Measurements of that output over a short period of time constitute a proxy for the system’s steady state. The overall system’s throughput, error rates, latency percentiles, etc. could all be metrics of interest representing steady state behavior. By focusing on systemic behavior patterns during experiments, Chaos verifies that the system does work, rather than trying to validate how it work


Vary Real-world Events

Prioritize events either by potential impact or estimated frequency.

Any event capable of disrupting steady state is a potential variable in a Chaos experiment.


Run Experiments in Production

Since the behavior of utilization can change at any time, sampling real traffic is the only way to reliably capture the request path. To guarantee both authenticity of the way in which the system is exercised and relevance to the current deployed system, Chaos strongly prefers to experiment directly on production traffic.


Automate Experiments to Run Continuously


Minimize Blast Radius

While there must be an allowance for some short-term negative impact, it is the responsibility and obligation of the Chaos Engineer to ensure the fallout from experiments are minimized and contained



Where other practices address velocity and flexibility, Chaos specifically tackles systemic uncertainty in these distributed systems.


https://principlesofchaos.org/


  • Chaos engineering is the practice of testing a system's response to turbulent behavior, such as infrastructure failures, unresponsive services, or missing components.

The goal is to break the system to correct its architecture, understand its weak points, and anticipate failures and how the system and the people might behave


By using the following principles, you can adopt chaos engineering in many difficult environments and organizations. The principles are relevant to all organizations that want to implement chaos engineering and benefit from the high availability and resilience that it enables


Strengthen reliability disciplines

Understand the system

Experiment on every component

Strive for production

Contain the impact

Measure, learn, improve

Increase complexity gradually

Socialize continuously

Sometimes the terminology is the problem, and executives prefer to replace chaos engineering with continuous disaster recovery to promote its adoption


https://www.ibm.com/cloud/architecture/architecture/practices/chaos-engineering-principles/


  • “Chaos Engineering is the discipline of experimenting on a distributed system in order to build confidence in the system’s capability to withstand turbulent conditions in production.” 


For VictorOps, SRE is a scientific practice which aims to make data-driven decisions to improve a system’s reliability and scalability—as observed by the customer.


We knew that all simulated service disruptions were going to be taken in our pre-production environment in order to increase our confidence that it wouldn’t impact users.


What if a service in our staging environment is actually talking to something in our production environment? We are still learning its reality. However, we need to “reduce the blast radius” as they say, so our initial exercises will take place in our pre-production “staging” environment.


This means that we need to ask questions about how we can make staging behave (as closely as possible) to the customer-facing environment. 


Principles of Chaos:


    Build a Hypothesis around Steady State Behavior

    Vary Real-world Events

    Run Experiments in Production

    Automate Experiments to Run Continuously

    Minimize Blast Radius


What is the goal of Chaos Day?


Using the principles of chaos engineering we will learn how our system handles failure, then incorporate that information into future development.


What is the goal of our experiments?


This time around, we’re verifying our first round of Black-box Alerts in our staging environment.


What happens if we actually break Staging in a way which takes longer than a day to fix?


We’re aiming to avoid this with back-out criteria for experiments and reset criteria for bad/overloaded data. If, however, a long recovery time is needed, we’ll communicate this and make arrangements with affected teams.


Chaos Team Roles


Recorder

Documenting as much as possible was the first role we wanted to assign—we needed a recorder


Driver

Someone should be responsible for driving the experiments as well:


Incident Commander (Tech Lead)

A technical lead (typically the council representative) would assume the role of the incident commander to be the main point of contact and to maintain a high-level holistic awareness for the experiments


Commander for the day

In addition to team incident commanders, one engineer played the role of the event I.C., communicating across all experiments throughout the day


https://www.splunk.com/en_us/observability/resources/sre-guide-toc/chaos-engineering.html

  • The core tenets on which SRE works are as follows 

Observability
In order to conduct experiments, one must be able to have deep introspection into the functionalities of the system. 

Experimentation
Tightly define scope, time, and duration of experiments. Choose experiments where the risk/reward ratio is in your favor

Reporting
Chaos Engineers should do deep dives into codebases to determine sources of problems and work with engineers to fix problems and increase reliability. 

Culture
Chaos engineering, like DevOps, is a cultural paradigm shift that provides incentives for engineers to design systems with reliability in mind. 

Chaos Engineering increases reliability and uptime by surgically attacking the infrastructure to detect weak spots, thereby increasing resilience to service degradation.
This is a notch higher than the conventional approach of typical Incident Response – Prevention lifecycle. Experiments are run, data is collected, and fixes are made. Instead of hoping that disaster recovery and failover work as expected
https://www.digitalonus.com/sre-chaos-engineering/

  • The principles of observability turn your systems into inspectable and debuggable crime scenes, and chaos engineering encourages and leverages observability as it seeks to help you pre-emptively discover and overcome system weaknesses.

The Value of Observability
As systems evolve increasingly rapidly, they become more complex and more susceptible to failure. Observability is the key that helps you take on responsibility for systems where you need to be able to interrogate, inspect, and piece together what happened, when, and—most importantly—why. 

“It’s not about logs, metrics, or traces, but about being data driven during debugging and using the feedback to iterate on and improve the product,” Cindy Sridharan writes.

Observability helps you effectively debug a running system without having to modify the system in any dramatic way.

You can think of observability as being a super-set of system management and monitoring, where management and monitoring has traditionally been great at answering closed questions such as, “Is that server responding?” Observability extends this power to encompass answering open questions such as, “Can I trace the latency of a user interaction in real time?”, or, “How successful was a user interaction that was submitted yesterday

Great observability signals help you become a “system detective:” someone who is as able to shine a light on emergent system behavior and shape the mental models of operators and engineers evolving the system.

You are able to grasp, inspect, and diagnose the conditions that are the conditions of a rapidly changing, complex, and sometimes failing system.

The Value of Chaos Engineering

Chaos engineering seeks to surface, explore, and test against system weaknesses through careful and controlled chaos experiments.

Chaos Engineering Encourages and Contributes to Observability

Chaos engineering and observability are closely connected
To confidently execute a chaos experiment, observability must detect when the system is normal and how it deviates from that steady-state as the experiment’s method is executed.

When you detect a deviation from the steady-state, then an unsuspected and unobserved system behavior may have been found by the chaos experiment. At this point the team responsible for the system will be looking to the system’s observability signals to help them unpack the causes and contributing factors to this deviation.



https://www.oreilly.com/library/view/chaos-engineering-observability/9781492051046/ch01.html


  • In the practice of Chaos Engineering, observability plays a key role. Validation of hypothesis, steady state behaviour, simulating real-world events, optimizing blast radius are all those stages of your experiments where observability plays a key role


Sources of Observable Data


The four golden signals in a service mesh, viz. latency, traffic, errors & saturation provide us the fundamental data set used for observations


Traffic can be observed across all three pillars for observability.


Latency is observable by measuring the time difference between request and response and analyzing the distribution of that across various actors like client, server, network, communication protocols, etc. 


Errors provide insights into configuration issues, your application code and broken dependencies.


Saturation provides insights into the utilization and capacity of your resources.


Logging is a very granular way of observing the data


Metrics complement logging 


Traces provide a deep understanding of how data flows in your system.


Observability in Action in a Chaos Experiment

Platform: AWS

Target: Microservice deployed in ECS Cluster

Observability: AppDynamics APM

Chaos Tool: Gremlin

Load Generator: HP Performance Center

Attack Type: Network Packet Loss (Egress Traffic)

Blast Radius: 100% (3 out of 3 containers)

Duration: 29 Minutes


Every dependency in a distributed application is its de-facto Chaos Injection Point


In this article, we specifically demonstrate a scenario of incremental network packet loss for a microservice known as ‘chaosM’ running as part of an AWS ECS cluster


The microservice is running behind a fleet of web-servers. It has 3 task definitions (ECS), balanced across 3 AWS AZs


From a functional view, ‘chaosM’ receives business requests from NAB’s On-Prem Apps, applies the necessary transformation logic before delivering the transformed output to a 3rd-party system, residing outside NAB network


It’s a backend type microservice.


Observed metrics in Steady-state and their deviations in Experiment-state help us validate the hypothesized behaviour of the concerned service.


To observe the steady-state of our micro service, we use metrics called KPIs: Traffic, Errors, Latency & Saturation


our sample ‘chaosM’ micro service is a business integration service designed for data transformation & enrichment. Unlike customer facing services, it does not have business metrics like logins/sec, submission/minute, etc.


Hypothesis


Based on the service’s observability, we make a couple of hypothesis about the microservice:


The incremental Packet Loss attacks of 40%, 60% & 80%, which tries to simulate varying degree of network reliability, will result in a steady increase in latency along with its corresponding error rates (HTTP 500 in this case).

At 100% Packet Loss (a.k.a Blackhole), which simulates a downstream outage, we should be able to validate a 5 sec TCP connect timeout as configured in the ‘chaosM’ microservice


Gremlin’s Failure-as-a-Service (FaaS) Platform is used to design & launch the scenario where we execute 4 incremental network packet loss attacks with increasing intensity i.e. 40%, 60%, 80% & 100% packet loss 


Each attack lasts 3 minutes. Also, a 3-minute delay is kept between each successive attack to isolate the observations and allow the service to fall back to steady state between each attack.


Therefore, the total attack window is (3 mins duration x 4 attacks) + (3 mins delay x 3) = (12 + 9) = 21 minutes.


In our observations, we also take into consideration 4 mins before & after the experiment. Hence, total observation window is 29 minutes


The experiment state dashboard represents the same KPIs which helps understand the behaviour of the ‘chaosM’ micro service when it is under attack. We will perform a comparative analysis between steady-state and experiment-state to validate the hypothesis.


Comparative Analysis

The technical insights generated out of the comparative analysis objectively identifies potential weaknesses (in design, coding & configurations) in the system with respect to specific categories of failures



Chaos Engineering experiments do not necessarily make your service totally immune to outages. On the contrary, among many other things, they help you uncover the known-unknowns to validate the robustness of your services.


Latency & Traffic

For the ease of comparison, we have put the SLIs from Steady and Experiment States side-by-side


This rise in Latency is proportional to the magnitude of the Packet Loss attacks, which validates our first hypothesis.

This validates our second hypothesis.


Errors per minute metric has increased exponentially from 0 Error in Steady State to 8 Errors at 40% Packet Loss, 18 Errors at 60% and 56 Errors at 80% Packet Loss


Saturation: CPU, Memory


In Steady state, the CPU utilization metric was reporting 1% across all 3 containers. The same metric in Experiment state has gone up to 2% irrespective of the magnitude of Packet loss.

Experiment has hardly made any difference to memory utilization


Saturation: Network


While the incoming metric shows 300~400 KB/s of incoming data, the corresponding network outgoing metric shows 8000 KB/s during the same time window. Due to these observations, we also concluded that unreliable network, in this case, does not affect resource utilization of our container infrastructure


Observability for a Developer


However, these metrics sometimes show the symptoms of the issue and not necessarily its underlying cause.


An APM monitoring solution can give us insights about the target micro service at the code level & exposes the vulnerable code segments, if any, from a Developer’s perspective.


The code segment Spring Bean — chaosMethod:416 took 38,805 ms or 38.8 Seconds in Experiment State which represents 99.8% of the total execution time. Whereas the same code segment only took 269 ms in Steady State. The 38.8 seconds represents the impact of the packet loss attacks on the code segment Spring Bean — chaosMethod:416.


This code level insights along with the system level visibility coming out of a monitoring (AppDynamics) helps us understand the internal workings of a micro service under various stress conditions & failure scenarios simulated through Chaos Engineering experiments


Observability is only of value when you better understand the data. When you look inside and answer the ‘whys’. You can find answers for both Operators and Developers.


You can discover the known-unknowns and unknown-unknowns once you conduct experiments on your hypothesis.

https://medium.com/@nabtechblog/observability-in-the-realm-of-chaos-engineering-99089226ca51


  • The prevailing wisdom is that you will see failures in production; the only question is whether you'll be surprised by them or inflict them intentionally to test system resilience and learn from the experience. The latter approach is chaos engineering.



The idea of the chaos-testing toolkit originated with Netflix’s Chaos Monkey and continues to expand. Today many companies have adopted chaos engineering as a cornerstone of their site reliability engineering (SRE) strategy



https://techbeacon.com/app-dev-testing/chaos-engineering-testing-34-tools-tutorials

Thursday, May 26, 2022

analysis paralysis

  •  What is analysis paralysis?

Analysis paralysis is an affliction people get when they overthink a problem or situation and can't make a decision

The affliction can affect individuals or groups of people as they encounter multiple options or solutions and need to choose the best one


If your options seem equally helpful to you, it can be a challenge to decide which option is best. For example, if one option increases a business's profit, but the other increases its customer outreach, it might be difficult to know which one is better. If your research parameters are too broad, narrowing your options down can also be a challenge. For example, it's more difficult to find an answer to the question, "Where should I run my advertisements?" versus "Where should I run my advertisements that will generate the most customer interest?"


8 tips for combating analysis paralysis


1. Recognize it

One way to recognize it is by comparing it to your other decision-making processes

Examine the last decision you made when someone gave you multiple options. Remember the steps you took to decide and how long the process took. 

If the current decision you need to make is taking a long time and if the steps you used previously aren't working, you might be overthinking the situation.

Once you recognize that you're overthinking it, try to determine why.

if you realize you're overthinking a decision because you're worried about the outcome affecting you negatively, then try to focus on the positive outcomes.


2. Prioritize the decisions

If you have to make a lot of decisions in one day, you might tire yourself and increase your chance of overthinking certain situations

For instance, if you notice you get more tired in the afternoon, try to schedule the tougher decisions for the morning


3. Take a break

When you give yourself a break, it's important to try to not think about the problem or situation. 


4. Ask someone for advice

For example, if you're trying to decide which car you should purchase, consider talking with a friend or family member who recently purchased a car or who has experience with 


5. Make quick decisions

This can help you feel confident in making decisions without overthinking them.


6. Set a deadline

When you set a deadline for a project or solution, it can help force you to make a decision. 


7. Understand your goals

For example, let's say a company is trying to decide on two options: One that will increase their revenue short term and one that will increase their customer outreach long term.

 If it's hoping to grow and develop the business, it might be better to increase its customer outreach. However, if its goal is to generate money more quickly to use it for research and development, it might be better to increase the company's revenue.

 

8. Limit your information intake

Sometimes, too much information can actually affect how much you overthink a situation or problem.

 It's important to know if any option comes with risks, but once you have the basic knowledge you need, try to make the decision right away.


https://www.indeed.com/career-advice/career-development/analysis-paralysis

  • Analysis paralysis (or paralysis by analysis) describes an individual or group process when overanalyzing or overthinking a situation can cause forward motion or decision-making to become "paralyzed", meaning that no solution or course of action is decided upon within a natural time frame. A situation may be deemed too complicated and a decision is never made, or made much too late, due to anxiety that a potentially larger problem may arise. A person may desire a perfect solution, but may fear making a decision that could result in error, while on the way to a better solution. Equally, a person may hold that a superior solution is a short step away, and stall in its endless pursuit, with no concept of diminishing returns. On the opposite end of the time spectrum is the phrase extinct by instinct, which is making a fatal decision based on hasty judgment or a gut reaction.


In software development, analysis paralysis typically manifests itself through the waterfall model with exceedingly long phases of project planning, requirements gathering, program design, and data modeling, which can create little or no extra value by those steps and risk many revisions

Analysis paralysis can occur when there is a lack of experience on the part of workers such as systems analysts, project managers or software developers, and could be due to a rigid and formal organizational culture.

Analysis paralysis can also arise from extensive experience or expertise, which serves to increase the number of options and considerations that appear at every decision point.

Agile software development methodologies explicitly seek to prevent analysis paralysis, by promoting an iterative work cycle that emphasizes working products over product specifications, but requires buy-in from the full project team. In some instances, Agile software development ends up creating additional confusion in the project in the case where iterative plans are made with no intention on having the team following through.

https://en.wikipedia.org/wiki/Analysis_paralysis

Sunday, May 8, 2022

data lake

  • ChatGPT
A data lake is a centralized repository designed to store large volumes of raw, unstructured, and structured data in its native format. It is a critical component in modern data architectures, particularly for handling big data and enabling advanced analytics. Here’s a comprehensive explanation:

Key Concepts of a Data Lake

1. Storage of Raw Data

  • Raw Data: Data lakes store data in its raw form, without the need for pre-processing or transformation before storage. This can include structured data (like relational databases), semi-structured data (like JSON or XML), and unstructured data (like text documents, images, or videos).

  • Flexibility: Unlike traditional databases or data warehouses, data lakes do not enforce a schema-on-write, meaning that data is stored as-is and schema is applied when the data is read (schema-on-read).

  • 2. Scalability

    • Big Data Handling: Data lakes are designed to handle large volumes of data, scaling horizontally by adding more servers or storage as needed. This makes them suitable for big data applications and scenarios where data volume grows rapidly.

    3. Storage Cost Efficiency

    • Cost-Effective Storage: Storing large amounts of data in a data lake is often more cost-effective compared to traditional databases or data warehouses, especially when using cloud-based solutions.

    4. Data Accessibility

    • Centralized Repository: Data lakes act as a central repository where all data, regardless of type or source, can be stored and accessed. This provides a single source of truth for data analysis and business intelligence.

    5. Advanced Analytics and Machine Learning

    • Data Exploration: Analysts and data scientists can explore and analyze data from a data lake using various tools, including SQL queries, machine learning algorithms, and big data processing frameworks.

    • Integration with Analytical Tools: Data lakes integrate with data processing and analytics tools like Apache Hadoop, Apache Spark, and other big data frameworks, enabling complex data processing and advanced analytics.

 

Components of a Data Lake

  1. Data Ingestion:

    • Mechanisms for collecting and importing data from various sources into the data lake. This can include batch processing, real-time streaming, and data integration tools.
  2. Data Storage:

    • Storage infrastructure that can handle different types of data formats and volumes. In cloud environments, services like Amazon S3, Azure Data Lake Storage, or Google Cloud Storage are commonly used.
  3. Data Management:

    • Tools and frameworks for organizing, cataloging, and managing the data stored in the lake. This includes metadata management, data governance, and data quality tools.
  4. Data Processing:

    • Technologies and frameworks for processing and analyzing the data. This can include data transformation, ETL (Extract, Transform, Load) processes, and big data processing engines.
  5. Data Access and Security:

    • Mechanisms to ensure secure access to the data, including authentication, authorization, and encryption. Data lakes implement policies and controls to protect sensitive information and manage user access.

Advantages of a Data Lake

  • Flexibility: Can store diverse data types and formats, allowing organizations to adapt to changing data needs and use cases.
  • Scalability: Easily scalable to accommodate growing data volumes and processing requirements.
  • Cost Efficiency: Typically more cost-effective for large-scale data storage compared to traditional databases.
  • Advanced Analytics: Supports advanced analytics and machine learning by providing access to large volumes of raw data.

Challenges of a Data Lake

  • Data Quality and Governance: Managing and ensuring the quality of data can be challenging due to the volume and diversity of data stored.
  • Complexity: Requires robust data management and processing frameworks to effectively handle and analyze the data.
  • Security: Ensuring data security and compliance can be complex given the wide range of data types and sources.

Summary

A data lake is a powerful tool for organizations to store and manage large volumes of raw data from various sources. It provides the flexibility to handle diverse data types, supports scalability and advanced analytics, and offers cost-effective storage solutions. However, managing data quality, governance, and security remains essential to leveraging the full potential of a data lake.

  • What is a data lake?

A data lake is a centralized repository designed to store, process, and secure large amounts of structured, semistructured, and unstructured data. It can store data in its native format and process any variety of it, ignoring size limits.


A data lake provides a scalable and secure platform that allows enterprises to: ingest any data from any system at any speed—even if the data comes from on-premises, cloud, or edge-computing systems; store any type or volume of data in full fidelity; process data in real time or batch mode; and analyze data using SQL, Python, R, or any other language, third-party data, or analytics application.

https://cloud.google.com/learn/what-is-a-data-lake#:~:text=A%20data%20lake%20is%20a,of%20it%2C%20ignoring%20size%20limits.



  • Four key differences between a data lake and a data warehouse


Data Lake Data Warehouse

Data Structure Raw Processed

Purpose of Data Not yet determined Currently in use

Users Data scientists Business professionals

Accessibility Highly accessible and quick to update More complicated and costly to make changes


Organizations often need both. Data lakes were born out of the need to harness big data and benefit from the raw, granular structured and unstructured data for machine learning, but there is still a need to create data warehouses for analytics use by business users


https://www.talend.com/resources/data-lake-vs-data-warehouse/#:~:text=Data%20lakes%20and%20data%20warehouses,processed%20for%20a%20specific%20purpose.





Wednesday, April 13, 2022

Security Service Edge (SSE)

  •  What Is a Security Service Edge (SSE)?

 SSE is a collection of integrated, cloud-centric security capabilities that facilitates safe access to websites, software-as-a-service (SaaS) applications and private applications. 

SSE-related security capabilities include Zero Trust Network Access (ZTNA), cloud secure web gateway (SWG), cloud access security broker (CASB), and firewall-as-a-service (FWaaS) technologies.


Zero Trust Network Access (ZTNA)

Zero Trust Network Access (ZTNA) is a category of technologies that provides secure remote access to applications and services based on defined access control policies. Unlike virtual private networks (VPNs), which grant complete access to a LAN, ZTNA solutions default to deny, providing only the access to services the user has been explicitly granted.


When looking at the full capability set that comprises a comprehensive SSE strategy, ZTNA provides a multi-layered, remote-access, security approach that provides redundant layers of inspection and enforcement, specifically:


Secure Web Gateway (SWG)

A secure web gateway (SWG) protects users from web-based threats in addition to applying and enforcing corporate acceptable use policies. Instead of connecting directly to a website, a user accesses the SWG, which is then responsible for connecting the user to the desired website and performing functions such as URL filtering, web visibility, malicious content inspection, web access controls and other security measures


SWGs are an important part of a comprehensive SSE strategy as they provide users secure internet access when they are disconnected from the business VPN


Cloud Access Security Broker (CASB)

CASBs help organizations discover where their data is across multiple software-as-a-service (SaaS) applications and when it’s in motion across cloud environments, on-prem data centers or accessed by mobile workers. A CASB also enforces an organization’s security, governance and compliance policies allowing authorized users to access and consume cloud resources while enabling organizations to effectively and consistently protect their data across multiple locations. There are two types of CASBs available: traditional CASBs and integrated CASBs.


An effective SSE strategy uses an integrated CASB to help organizations keep pace with the SaaS explosion.


Firewall-as-a-Service (FWaaS)

FWaaS enables firewalls to be delivered as part of a company’s cloud infrastructure to protect cloud-based data and applications.


An SSE strategy uses FWaaS capabilities to enable organizations to aggregate traffic from multiple sources – whether from on-site data centers, branch offices, mobile users or cloud infrastructure

https://www.paloaltonetworks.com/cyberpedia/what-is-security-service-edge-sse


  • What is security service edge?

a convergence of network security services delivered from a purpose-built cloud platform.
SSE can be considered a subset of the secure access service edge (SASE) framework with its architecture squarely focused on security services.

Secure access to the internet and web by way of a secure web gateway (SWG)
Secure access to SaaS and cloud apps via a cloud access security broker (CASB)
Secure remote access to private apps through zero trust network access (ZTNA)

What has driven the need for SSE?

 As organizations adopt software and infrastructure as a service (SaaS, IaaS) offerings as well as other cloud apps, their data becomes more distributed outside their on-premises data centers. In addition, growing populations of users are mobile and remote, connecting from everywhere, over any connection, to their cloud apps and data.

Securing cloud apps and mobile users is difficult with traditional network security approaches because:
Anchored to the data center, legacy technologies can't follow connections between users and cloud apps.
Relaying ("hairpinning") user traffic to a data center via traditional VPN for inspection slows everything down.
VPNs are easy to exploit due to a lack of patching.

What's the difference between secure access service edge (SASE) and security service edge (SSE)?
You can look at a SASE platform in two slices. The SSE slice focuses on unifying all security services, including SWG, CASB, and ZTNA. The other, the WAN edge slice, focuses on doing so for networking services, including software-defined wide area networking (SD-WAN), WAN optimization, quality of service (QoS), and other means of improving routing to cloud apps.

Advantages of SSE over traditional network security

1. Better risk reduction
SSE also improves visibility across users—wherever they are—and data, regardless of the channels accessed

2. Zero trust access
SSE platforms (along with SASE) should enable least-privileged access from users to cloud or private apps with a strong zero trust policy based on four factors: user, device, application, and content. 

3. User experience
4. Consolidation advantages
SSE can deliver many key security services—SWG, CASB, ZTNA, cloud firewall (FWaaS), cloud sandbox, cloud data loss prevention (DLP), cloud security posture management (CSPM), and cloud browser isolation (CBI)—all in one platform

Top SSE use cases

1. Secure access to cloud services and web usage
Enforcing policy control over user access to the internet, web, and cloud applications (historically performed by a SWG) is one of the primary use cases for the security service edge.Another key capability is cloud security posture management (CSPM), which protects your organization from risky misconfigurations that can lead to breaches.

2. Detect and mitigate threats
SSE platform must have advanced threat prevention capabilities, including cloud firewall (FWaaS), cloud sandbox, malware detection, and cloud browser isolation. CASBs enable inspection of data within SaaS apps and can identify and quarantine existing malware before it inflicts damage. Adaptive access control, whereby an end user's device posture is determined and access is adjusted accordingly, is also a key component.

3. Connect and secure remote workers
Providing secure access to private and cloud apps without needing to open firewall ACLs or expose apps to the internet is key here. SSE platforms should enable native inside-out app connectivity, keeping apps "dark" to the internet

4. Identify and protect sensitive data 
Cloud DLP enables sensitive data (e.g., personally identifiable information [PII]) to be easily found, classified, and secured to support Payment Card Industry (PCI) standards and other compliance policies. SSE also simplifies data protection, as you can create DLP policies just once and apply them across inline traffic and data at rest in cloud apps via CASBs.

The most effective SSE platforms also deliver high-performance TLS/SSL inspection to address encrypted traffic (that is, most data in transit). Also key for this use case is shadow IT discovery, which allows organizations to block risky or sanctioned applications across all endpoints.

https://www.zscaler.com/resources/security-terms-glossary/what-is-security-service-edge

  • sase is combination of network as a service and security as a service capabilities.
sase is delivered as a service business model to the cloud.
Thin Edge Users -> application aaS + data center + SaaS + IaaS + Internet -> Remote Off-Network Users
Secure Access Service Edge(SASE) vs VPN-only

Network as a Service + Security as a Service -> SASE
Network as a Service -> Peering - > Direct network connection and traffic exchange across the internet
Security as a Service -> NGFW or cloud-based Firewall as a Service
NGFW or cloud-based Firewall as a Service - > Physical Device or cloud-based
  Full stack security
IPS
Anti-Malware
SSL Inspection
Sandbox
Secure Web Gateway   - > Filter Malware
  Enforce internet security and compliance policies
Zero Trust Network Access(ZTNA)   - > Identify users and devices and authenticate and authorize
  Technologies
Multi-Factor Authentication(MFA)
Network Access Control(NAC)
Access Policy Enforcement
Data Loss Prevention(DLP)     - > Prevents moving key information outside the network authorize
  Informs content inspection of messaging and email applications
Domain Name System(DNS)   - > Informs SASE with detailed threat detection capabilities
  Analyze and assess risky domains   
  
https://training.fortinet.com/pluginfile.php/1622279/mod_scorm/content/1/story_content/external_files/NSE%202%20SASE%20Script_EN.pdf








Thursday, March 31, 2022

MVP vs POC vs prototype

  •  Proof of Concept (POC)


Approach: Is the idea feasible? 


Implementation: Developing a POC is the quickest and most accurate way to validate or invalidate assumptions about your target users and app concept. 



Mobile App Prototype


Approach: How will this product function? 


Implementation: Mobile app prototyping is a form of user research to validate the strategic design direction of a product. A prototype is a preliminary visualization of a working product. Prototypes build an understanding of the mobile app’s look and feel, which helps test how customers use and react to the overall user experience (UX) design. Using a prototype for usability testing gives you enough time to make changes to critical design issues before the product reaches development and it’s too late (and too expensive) to make major changes to the UX. 



Minimum Viable Product (MVP)


Approach: What are the product’s core functionalities and value proposition? 


Implementation: A mobile app MVP is a minimal and usable form of your complete product to release and test in the app market. The MVP development method allows your team to learn how the product’s target users experience and respond to the app’s core business purpose. Using the insight and learnings from real users, you can allocate your time, effort and budget to areas that best satisfy your overall business objectives. Building an MVP is an iterative process designed to identify user pain points and determine the proper functionality to address those needs over time.


What is a POC? 

A POC will provide a definitive “yes” or “no” answer; either the concept is viable or it’s not.

The POC approach to product validation is about demonstrating functionality and verifying whether a particular idea is feasible for development.

Even if a POC proves that the concept won’t work, it’s possible to find other solutions from the same starting point. 


What is a Mobile App Prototype? 

While a POC shows a product concept can be done, a mobile app prototype shows how it will be done.

The purpose of a prototype is to communicate a product’s design and navigation flow to maximize the efficiency of development. Prototyping is a valuable exercise which results in visualization of how the app will function by demonstrating user flows and depicting a working design and layout. Naturally, there will be errors in a prototype, but discovering these errors during the early stages of a project is one of the purposes of a prototype. 


What is a Minimum Viable Product?

Prototypes often influence an MVP and the two work together to create a successful end product.

An MVP is a minimal form of your complete product that is tested in the market.

This approach to development allows you to learn how your users will react to your product before you waste a lot of money and resources building something no one wants or needs.

While prototypes solve problems during the early stages of development, an MVP’s iterative process is designed to identify users’ pain points when the product is actually tested in the market. 

The risk of developing more (or less) than you need is why validating your product assumptions with an MVP is so important. 

Starting with a core feature, learning how users react to that feature and building in accordance with user feedback is essential for determining the appropriate amount of functionality your product needs to acquire and retain users. Over time, the learnings that come from an MVP define your product roadmap and guide the evolution of your app. 


An MVP is a version of a product that includes only the features it needs to be marketable. With the MVP process, you can verify the following: 


    Product viability 

    Product assumptions 

    Usability 

    Market demand 


MVPs provide immediate value while minimizing development costs.

Ultimately, an MVP allows you to build a product with minimal features and iteratively build it out to create a better, more polished product while leveraging user intelligence to make the best decisions possible. With every release version, the product evolves to maximize ROI and move towards a fully mature application. 



https://clearbridgemobile.com/beginners-guide-poc-vs-mvp-vs-prototype/











  • What is the Difference Between MVP vs POC vs Prototype and why does it matter?


Factor:Role 


POC

Is this concept even feasible? The POC can be used to validate assumptions about the idea.

Prototype:

How will the product or solution actually function?

MVP:

What is the value proposition of the product and how will it function?



Factor:Development


POC

Demonstrates that a solution could be built

Prototype:

Shows how the solution will be built and how it will work.

MVP:

Is a built version of the product that tests the market for it.


Factor:Audiences


POC

Tends to be rather small and used internally to showcase an idea.

Prototype:

Usually used internally to see how the development work will be carried out.

MVP:

Is used externally to gauge market interest and see how it could be improved.


Factor:Issues


Prototype:

Deals with issues at the early stage of development.

MVP:

Takes an iterative approach to development looking at issues the client has with the product when it is in the market.


Factor: Function


POC

Does not function as a fully working product.

Helps to understand whether it is feasible to go ahead with the product.

Prototype:

Does not function as a fully working product.

Helps to see how the product will look and how it will feel for the user.

MVP:

Functions fully as a working product using the basic but most essential functionality.

Helps to see how the product will be used.


Factor: Feedback


POC

Does not provide an opportunity for feedback from actual or possible customers. Might sometimes be used with investors to attract funding.

Prototype:

Can allow the firm to get feedback from a few possible customers.

MVP:

Allows the firm to gather feedback from a lot of customers, potentially.


Factor: Customer growth


POC

Does not grow the customer base.

Prototype:

Does not grow the customer base.

MVP:

Grows the customer base at the same time as iterative development is taking place.


Factor: Revenues


POC

Will not bring in revenues from customers.

Prototype:

Will not bring in revenues from customers.

MVP:

Can bring in revenues from customers.


https://enkonix.com/blog/mvp-vs-poc-vs-prototype/

Tuesday, March 1, 2022

Cyber Threat Modelling

 

  • Definition of threat modeling

Threat modeling is a structured process with these objectives: identify security requirements, pinpoint security threats and potential vulnerabilities, quantify threat and vulnerability criticality, and prioritize remediation methods. Threat modeling methods create these artifacts:

    An abstraction of the system
    Profiles of potential attackers, including their goals and methods
    A catalog of threats that could arise

How does threat modeling work?
Threat modeling works by identifying the types of threat agents that cause harm to an application or computer system.
Typically, organizations conduct threat modeling during the design stage (but it can occur at other stages) of a new application to help developers find vulnerabilities and become aware of the security implications of their design, code, and configuration decisions. Generally, developers perform threat modeling in four steps:

    Diagram. What are we building?
    Identify threats. What could go wrong?
    Mitigate. What are we doing to defend against threats?
    Validate. Have we acted on each of the previous steps?


Advantages of threat modeling

When performed correctly, threat modeling can provide a clear line of sight across a software project, helping to justify security efforts. The threat modeling process helps an organization document knowable security threats to an application and make rational decisions about how to address them


Overall, a well-documented threat model provides assurances that are useful in explaining and defending the security posture of an application or computer system

    Detect problems early in the software development life cycle (SDLC)—even before coding begins.
    Spot design flaws that traditional testing methods and code reviews may overlook.
    Evaluate new forms of attack that you might not otherwise consider.
    Maximize testing budgets by helping target testing and code review.
    Identify security requirements.
    Remediate problems before software release and prevent costly recoding post-deployment.
    Think about threats beyond standard attacks to the security issues unique to your application.
    Keep frameworks ahead of the internal and external attackers relevant to your applications.
    Highlight assets, threat agents, and controls to deduce components that attackers will target.
    Model the location of threat agents, motivations, skills, and capabilities to locate potential attackers in relation to the system architecture.

Misconceptions of threat modeling
Penetration testing and code reviews can’t substitute for threat modeling.
There’s a good reason to conduct a threat model after deployment.

Best practices of threat modeling
1. Define the scope and depth of analysis
Determine the scope with stakeholders, then break down the depth of analysis for individual development teams so they can threat model the software.
2. Gain a visual understanding of what you’re threat modeling. 
Identify software assets, security controls, and threat agents and diagram their locations to create a security model of the system 
3. Model the attack possibilities
Identify software assets, security controls, and threat agents and diagram their locations to create a security model of the system
4. Identify threats. 
To produce a list of potential attacks, ask questions such as the following:
                    Are there paths where a threat agent can reach an asset without going through a control?
                    Could a threat agent defeat this security control?
                    What must a threat agent do to defeat this control?
5. Create a traceability matrix of missing or weak security controls
Consider the threat agents and follow their control paths. If you reach the software asset without going through a security control, that’s a potential attack. If you go through a control, consider whether it would halt a threat agent or whether the agent would have methods to bypass it.

the Synopsys high-level approach to threat modeling adheres to the following steps:

    Model the system.
    Conduct a threat analysis.
    Prioritize the threats.


Model the system

System modeling consists of two parts:

    Creating a component diagram with a control flow graph (which shows all possible execution paths in a program)
    Identifying assets, security controls, trust zones, and threat agents

Conduct a threat analysis 

Checklist-based approaches. Many threat modeling approaches involve a checklist or a template. For example, STRIDE recommends you consider six types of threats—spoofing, tampering, repudiation, information disclosure, denial of service, and escalation of privilege
Non-checklist-based approaches. These approaches generally use creative methods (e.g., brainstorming) to identify attacks.


https://www.synopsys.com/glossary/what-is-threat-modeling.html
  • Threat Modeling
Threat modeling is a core element of the Microsoft Security Development Lifecycle (SDL). It’s an engineering technique you can use to help you identify threats, attacks, vulnerabilities, and countermeasures that could affect your application. You can use threat modeling to shape your application's design, meet your company's security objectives, and reduce risk.

There are five major threat modeling steps:
 Defining security requirements.
 Creating an application diagram.
 Identifying threats.
 Mitigating threats.
 Validating that threats have been mitigated.

https://www.microsoft.com/en-us/securityengineering/sdl/threatmodeling
  •  A threat model is essentially a structured representation of all the information that affects the security of an application. In essence, it is a view of the application and its environment through security glasses.
 Threat modeling enables informed decision-making about application security risk. 
 In addition to producing a model, typical threat modeling efforts also produce a prioritized list of security improvements to the concept, requirements, design, or implementation.
 
 Objectives of Threat Modeling

Threat modeling is a family of activities for improving security by identifying objectives and vulnerabilities, and then defining countermeasures to prevent, or mitigate the effects of, threats to the system. A threat is a potential or actual undesirable event that may be malicious (such as DoS attack) or incidental (failure of a Storage Device). Threat modeling is a planned activity for identifying and assessing application threats and vulnerabilities.

Threat Modeling - Generic Steps
Following is a four question framework that helps understand threat modeling:

    What are we working on?
    What can go wrong?
    What are we going to do about it?
    Did we do a good job?

The basic threat modeling process consists of the following generic steps. The process of exploring the search space is iterative and constantly refined based on what you have done so far. So, for example, starting with all possible vulnerabilities is usually pointless, as most of them are not attackable by the threat agents, protected by a safeguard, or do not lead to a consequence. Therefore, it’s generally best to start with the factors that make a lot of difference.

Assessment Scope - The first step is always to understand what’s on the line. Identifying tangible assets, like databases of information or sensitive files is usually easy
Identify Threat Agents and Possible Attacks - A key part of the threat model is a characterization of the different groups of people who might be able to attack your application.
Understand Existing Countermeasures - The model must include the existing countermeasures
Identify Exploitable Vulnerabilities - Once you have an understanding of the security in the application, you can then analyze for new vulnerabilities.
Prioritized Identified Risks - Prioritization is everything in threat modeling, as there are always lots of risks that simply don’t rate any attention. For each threat, you estimate a number of likelihood and impact factors to determine an overall risk or severity level
Identify Countermeasures to Reduce Threat - The last step is to identify countermeasures to reduce the risk to acceptable levels.

Benefits
The threat model allows security decisions to be made rationally, with all the information on the table
The threat modeling process naturally produces an assurance argument that can be used to explain and defend the security of an application. An assurance argument starts with a few high level claims, and justifies them with either subclaims or evidence

https://owasp.org/www-community/Threat_Modeling
  • Threat modeling is a process by which potential threats, such as structural vulnerabilities or the absence of appropriate safeguards, can be identified, enumerated, and mitigations can be prioritized. The purpose of threat modeling is to provide defenders with a systematic analysis of what controls or defenses need to be included, given the nature of the system, the probable attacker's profile, the most likely attack vectors, and the assets most desired by an attacker. Threat modeling answers questions like “Where am I most vulnerable to attack?”, “What are the most relevant threats?”, and “What do I need to do to safeguard against these threats?”.
https://en.wikipedia.org/wiki/Threat_model
  • Application Threat Modeling
Threat modeling can be applied to a wide range of things, including software, applications, systems, networks, distributed systems, things in the Internet of things, business processes, etc. 

Most of the time, a threat model includes:

    A description / design / model of what you’re worried about
    A list of assumptions that can be checked or challenged in the future as the threat landscape changes
    A list of potential threats to the system
    A list of actions to be taken for each threat
    A way of validating the model and threats, and verification of success of actions taken

The inclusion of threat modeling in the SDLC can help

    Build a secure design
    Efficient investment of resources; appropriately prioritize security, development, and other tasks
    Bring Security and Development together to collaborate on a shared understanding, informing development of the system
    Identify threats and compliance requirements, and evaluate their risk
    Define and build required controls.
    Balance risks, controls, and usability
    Identify where building a control is unnecessary, based on acceptable risk
    Document threats and mitigation
    Ensure business requirements (or goals) are adequately protected in the face of a malicious actor, accidents, or other causes of impact
    Identification of security test cases / security test scenarios to test the security requirements


4 Questions
Most threat model methodologies answer one or more of the following questions in the technical steps which they follow:

What are we building?
As a starting point you need to define the scope of the Threat Model. To do that you need to understand the application you are building, examples of helpful techniques are:

    Architecture diagrams
    Dataflow transitions
    Data classifications
    You will also need to gather people from different roles with sufficient technical and risk awareness to agree on the framework to be used during the Threat modeling exercise

What can go wrong?
This is a “research” activity in which you want to find the main threats that apply to your application
There are many ways to approach the question, including brainstorming or using a structure to help think it through. Structures that can help include STRIDE, Kill Chains, CAPEC and others.

What are we going to do about that?

Did we do a good enough job?
Finally, carry out a retrospective activity over the work you have done to check quality, feasibility, progress, and/or planning

Process

The technical steps in threat modeling involve answering questions:

    What are we working on - What can go wrong - What will we do with the findings
    Did we do a good job? The work to answer these questions is embedded in some sort of process, ranging from incredibly informal Kanban with Post-its on the wall to strictly structured waterfalls
https://owasp.org/www-community/Application_Threat_Modeling

  • What Is Threat Modeling?
Threat modeling is the process of using hypothetical scenarios, system diagrams, and testing to help secure systems and data. By identifying vulnerabilities, helping with risk assessment, and suggesting corrective action, threat modeling helps improve cybersecurity and trust in key business systems.

What are the benefits of threat modeling?

Provide an enhanced view of systems. The steps involved in threat modeling--creating data flow diagrams (DFDs) and graphical representations of attack paths, as well as prioritizing assets and risks--help IT teams gain a deeper understanding of network security and architecture.

Help enable better collaboration on security. Proper threat modeling requires input from many stakeholders. Participating in the process can help instill cybersecurity consciousness as a core competency for all participants.

Facilitate risk prioritization. Businesses can use the threat data provided by modeling to make decisions about which security risks to prioritize--a helpful process for understanding where to allocate people and budget resources.

Does threat modeling require special software?
While basic threat modeling can be performed in a brainstorming session, larger enterprises with more potential vulnerabilities can use software and hardware tools to improve the security of complex systems with multiple points of entry

What is involved in the threat modeling process?

Identify assets. An asset could be account data, intellectual property, or simply the reliable functioning of a system.

Diagram the system. DFDs provide a high-level, asset-centric view of systems and the data flows of attacks. An attack tree, or graphic representation of an attack path, illustrates the possible origins and paths of attacks.

Analyze threats. Use threat modeling methods to further analyze specific threat types, identify potential threats, map data flows, and quantify risk.

Perform risk management and prioritization. Many threat modeling tools produce threat scores and data for calculating risk. Stakeholder input is essential to this step.

Identify fixes. Once you identify the areas, assets, or threats that matter most to the organization, the next steps may be apparent. Changing firewall, encryption, or multi-factor authentication settings are examples of steps to address a threat.

How do I measure the effectiveness of threat modeling?

Common Vulnerability Scoring System (CVSS). CVSS produces standardized scores for application vulnerabilities, IT systems and elements, and IoT devices; the scores can be calculated with a free online tool. For additional perspective, scores can be compared against a database of existing scores crowdsourced from similar enterprises.

Penetration testing. Sometimes referred to as "ethical hacking," penetration testing is the process of staging dummy attacks on a system to measure its strengths and weaknesses.

Is threat modeling available as a service?
Threat modeling as a service (TMaaS) can allow an organization to focus on remediation and high-level network architecture decisions, while leaving necessary data-crunching to TMaaS providers. TMaaS also can perform continuous threat modeling, automatically running testing anytime a system is updated, expanded, or changed. TMaaS solutions incorporate threat intelligence--such as data about threats and attacks crowdsourced from organizations worldwide--that can inform threat hypotheses for networks and improve network security.

Threat modeling methods and tools

CIA method
For example, there may be sensitive customer information (confidentiality), company operational or proprietary data (integrity), or reliability of a service such as a web portal (availability).

Attack trees
Attack trees are a graphic representation of systems and possible vulnerabilities. The trunk of the attack tree is the asset, while entry points and threats are branches or root

STRIDE
one of the oldest and most widely used frameworks for threat modeling. STRIDE is a free tool that will produce DFDs and analyze threats.

PASTA
PASTA (process for attack simulation and threat analysis) is a framework designed to elevate threat modeling to the strategic level, with input from all stakeholders, not just IT or security teams. PASTA is a seven-step process that begins with defining objectives and scope. It includes vulnerability checks, weakness analysis, and attack modeling, and ends with risk and impact analysis expressed through scoring

Trike
An open-source tool available as a spreadsheet template or stand-alone program, Trike consists of a matrix combining assets, actors, actions, and rules. When parameters and data are entered in this matrix, the program produces a score-based analysis of risks and probabilities.

VAST
VAST (visual, agile, and simple threat) modeling consists of methods and processes that can be easily scaled and adapted to any scope or part of an organization. The results produce benchmarks that can be used to make reliable comparisons and measurements of effective risk across a whole organization.

Persona non grata
This method is similar to criminal profiling in law enforcement. To anticipate attacks in more detail, brainstorming exercises are performed to create a detailed picture of a hypothetical attacker, including their psychology, motivations, goals, and capabilities.

LINDDUN

The LINDDUN framework focuses on analysis of privacy threats, based on the categories that form its acronym: linkability, identifiability, non-repudiation, detectability, disclosure of information, unawareness, and non-compliance. It uses threat trees to help users choose the relevant privacy controls to apply.
https://www.cisco.com/c/en/us/products/security/what-is-threat-modeling.html
  • Threat Modeling: 12 Available Methods

STRIDE and Associated Derivations
Invented in 1999 and adopted by Microsoft in 2002, STRIDE is currently the most mature threat-modeling method.

PASTA
The Process for Attack Simulation and Threat Analysis (PASTA) is a risk-centric threat-modeling framework developed in 2012.

LINDDUN
LINDDUN (linkability, identifiability, nonrepudiation, detectability, disclosure of information, unawareness, noncompliance) focuses on privacy concerns and can be used for data security.

CVSS
The Common Vulnerability Scoring System (CVSS) captures the principal characteristics of a vulnerability and produces a numerical severity score

Attack Trees
Using attack trees to model threats is one of the oldest and most widely applied techniques on cyber-only systems, cyber-physical systems, and purely physical systems. Attack trees were initially applied as a stand-alone method and has since been combined with other methods and frameworks.

Persona non Grata
Persona non Grata (PnG) focuses on the motivations and skills of human attackers

Security Cards
Security Cards identify unusual and complex attacks. They are not a formal method but, rather, a kind of brainstorming technique.

hTMM
The Hybrid Threat Modeling Method (hTMM) was developed by the SEI in 2018. It consists of a combination of SQUARE (Security Quality Requirements Engineering Method), Security Cards, and PnG activities.

Quantitative Threat Modeling Method
This hybrid method consists of attack trees, STRIDE, and CVSS methods applied in synergy.

Trike
Trike was created as a security audit framework that uses threat modeling as a technique. It looks at threat modeling from a risk-management and defensive perspective.

VAST Modeling
The Visual, Agile, and Simple Threat (VAST) Modeling method is based on ThreatModeler, an automated threat-modeling platform.

OCTAVE
The Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) method is a risk-based strategic assessment and planning method for cybersecurity.

https://insights.sei.cmu.edu/sei_blog/2018/12/threat-modeling-12-available-methods.html
  • STRIDE, VAST, TRIKE, & MORE: WHICH THREAT MODELING METHODOLOGY IS RIGHT FOR YOUR ORGANIZATION?

OCTAVE (Practice Focused)
Though OCTAVE threat modeling provides a robust, asset-centric view, and organizational risk awareness, the documentation can become voluminous. OCTAVE lacks scalability – as technological systems add users, applications, and functionality, a manual process can quickly become unmanageable.
This method is most useful when creating a risk-aware corporate culture. The method is highly customizable to an organization’s specific security objectives and risk environment.

Trike Threat Modeling (Acceptable Risk Focused)
The foundation of the Trike threat modeling methodology is a “requirements model.” The requirements model ensures the assigned level of risk for each asset is “acceptable” to the various stakeholders.
However, because Trike threat modeling requires a person to hold a view of the entire system to conduct an attack surface analysis, it can be challenging to scale to larger systems.

P.A.S.T.A. Threat Modeling (Attacker Focused)
The output provides threat management, enumeration, and scoring.
The PASTA threat modeling methodology combines an attacker-centric perspective on potential threats with risk and impact analysis. 
The outputs are asset-centric.
PASTA threat modeling works best for organizations that wish to align threat modeling with strategic objectives because it incorporates business impact analysis as an integral part of the process and expands cybersecurity responsibilities beyond the IT department.
This alignment can sometimes be a weakness of the PASTA threat modeling methodologies. Depending on the technological literacy of key stakeholders throughout the organization, adopting the PASTA methodology can require many additional hours of training and education.

STRIDE Threat Modeling (Developer Focused)
The primary focus of that directive is to help ensure that Microsoft’s Windows software developers think about security during the design phase.
The STRIDE threat modeling goal is to get an application to meet the security properties of Confidentiality, Integrity, and Availability (CIA), along with Authorization, Authentication, and Non-Repudiation.
Once the security subject matter experts construct the data flow diagram-based threat model, system engineers or other subject matter experts check the application against the STRIDE threat model classification scheme.

VAST Threat Modeling (Enterprise Focused)
The founding principle is that, in order to be effective, threat modeling must scale across the infrastructure and entire DevOps portfolio, integrate seamlessly into an Agile environment and provide actionable, accurate, and consistent outputs for developers, security teams, and senior executives alike.
A fundamental difference of the VAST threat modeling methodology‍ is its practical approach. 
Recognizing the security concerns of development teams are distinct from those of an infrastructure team, this methodology calls for two types of threat models.


VAST: Application Threat Models
Application threat models for development teams are created with process flow diagrams (PFD). Process flow diagrams map the features and communications of an application in much the same way as developers and architects think about the application during an SDLC design session.

VAST: Operational Threat Models
Operational threat models are designed for the infrastructure teams
Though more similar to traditional DFDs than application threat models, the data flow information is presented from an attacker – not a data packet – perspective. 
By relying on PFDs rather than DFDs, VAST threat models do not require extensive systems expertise.

The most significant difference of the VAST threat modeling methodology, however, is its ability to allow organizations to scale across thousands of threat models
The pillars of a scalable threat modeling practice – automation, integration, and collaboration – are foundational to VAST threat modeling.
 As the organization matures and new threats arise, these pillars help to develop a sustainable self-service threat modeling practice driven by the DevOps teams rather than the security team

https://threatmodeler.com/threat-modeling-methodologies-overview-for-your-business/
  • Threat Modeling Methodologies

When performing threat modeling, there are multiple methodologies you can use. The right model for your needs depends on what types of threats you are trying to model and for what purpose.

STRIDE threat modeling
STRIDE is a threat model, created by Microsoft engineers, which is meant to guide the discovery of threats in a system

STRIDE is an acronym for the types of threats it covers, which are:

    Spoofing—a user or program pretends to be another
    Tampering—attackers modify components or code
    Repudiation—threat events are not logged or monitored
    Information disclosure—data is leaked or expose
    Denial of service (DoS)—services or components are overloaded with traffic to prevent legitimate use
    Privilege escalation—attackers grant themselves additional privileges to gain greater control over a system


Process for Attack Simulation and Threat Analysis (PASTA)
PASTA is an attacker-centric methodology with seven steps

The steps of a PASTA threat model are:

    Define business objectives
    Define the technical scope of assets and components
    Application decomposition and identify application controls
    Threat analysis based on threat intelligence
    Vulnerability detection
    Attack enumeration and modeling
    Risk analysis and development of countermeasures

Common Vulnerability Scoring System (CVSS)
CVSS is a standardized threat scoring system used for known vulnerabilities.

This system is designed to help security teams access threats, identify impacts, and identify existing countermeasures. It also helps security professionals assess and apply threat intelligence developed by others in a reliable way.

CVSS accounts for the inherent properties of a threat and the impacts of the risk factor due to time since the vulnerability was first discovered. It also includes measures that allow security teams to specifically modify risk scores based on individual system configurations.

Attack trees
Attack trees are charts that display the paths that attacks can take in a system. These charts display attack goals as a root with possible paths as branches.

Security Cards
Security Cards is a methodology based on brainstorming and creative thinking rather than structured threat modeling approaches. It is designed to help security teams account for less common or novel attacks.

The methodology uses a set of 42 cards, which help analysts answer questions about future attacks, such as who might attack, what their motivation could be, which systems they might attack, and how they would implement an attack.

Hybrid Threat Modeling Method (hTMM)
hTMM is a methodology developed by Security Equipment Inc. (SEI) that combines two other methodologies:

    Security Quality Requirements Engineering (SQUARE)—a methodology designed to elicit, categorize and prioritize security requirements.
    Persona non Grata (PnG)—a methodology that focuses on uncovering ways a system can be abused to meet an attacker’s goals.


https://www.exabeam.com/information-security/threat-modeling/
  • STRIDE is a mnemonic for a set of threats – Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service (DoS), and Elevation of Privilege as described in the table below.
https://www.eccouncil.org/threat-modeling/

  • Developed by Microsoft, STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) is one of the oldest and most widely used frameworks for threat modeling. STRIDE is a free tool that will produce DFDs and analyze threats
https://www.cisco.com/c/en/us/products/security/what-is-threat-modeling.html#~methods-and-tools
  • STRIDE is a model of threats .It provides a mnemonic for security threats in six categories. (First letters)


The threats are:
    Spoofing
    Tampering
    Repudiation
    Information disclosure (privacy breach or data leak)
    Denial of service
    Elevation of privilege

Each threat is a violation of a desirable property for a system
Spoofing  Authenticity
Tampering  Integrity
Repudiation  Non-repudiability
Information disclosure  Confidentiality
Denial of Service  Availability
Elevation of Privilege  Authorization 

https://en.wikipedia.org/wiki/STRIDE_%28security%29



  • The Process for Attack Simulation and Threat Analysis (PASTA) is a risk-centric threat modeling methodology that provides a step-by-step process to inject risk analysis and context into an organization’s overall security strategy from the beginning. PASTA encourages collaboration across all stakeholders, creating an environment focused on security

PASTA allows for collaboration between developer and business stakeholders to truly understand your application’s inherent risk, its likelihood of attack, and the business impact if there was a compromise

Benefits of PASTA Threat Modeling:
Contextualized approach that always ties back to business context
Simulates and tests the viability of evidence-based threats
Takes the perspective of an attacker
Leverages existing processes from within the organization
Collaborative process that can quickly scale up or down

Stage One: Define the Objectives

Governance and Compliance To Include in Your Threat Model:
External Framework – CoBit, ISO, NIST, SANS, CAG, CIS
Internal Standards – Crypto, Authentication, .NET security, JAVA security
External Regulations – PCI-DSS, NERC CIP, FIPS 140-2, FedRAMP
Internal Process/Artifacts – Risk Assessments, Vulnerability Assessments, SAST/DAST report

Stage Two: Define the Technical Scope
Stage two of PASTA is to understand your attack surface by defining your technical scope: know what you are protecting.
Attack Surface Component Examples:
API endpoints
Web application
Network infrastructure
OS Settings
DNS server
Certificate server
Mobile client
3rd party SW/Library
Data storage device
Application Framework
Kubernetes configuration
Docker configuration
Service configuration


Stage Three: Decompose the Application
Stage three goes further by creating context around how everything communicates, how it all comes together.
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 doesn’t illustrate to a developer or to an engineer what they should be worried about, it provides a map for analysis.

Stage Four: Analyze the Threats
The main output for stage four is to understand what the application does and what sort of threats are affecting your defined attack surface.

Dos:

Make your own threat intel utilizing internal/external researchers or internal logs
Know where your threat sources come from, it’s relevant, and cross validated

Don’ts:

Use one source of threat intel data
Use your competitors threat intelligence as a basis for industry related threats
Let the threat analysis reveal assets you didn’t consider in stages 2 and 3 (this means you did those steps wrong”

Stage Five: Vulnerability Analysis
Stage five correlates the application’s vulnerabilities to the application’s assets
The key differentiator with PASTA is focusing on risks that will have the most impact to the business

Stage Six: Attack Analysis
The key objective for stage six of PASTA, is to prove that the things we found vulnerable in stage five, are actually viable.
Using attack trees allows you to map known vulnerabilities to a node on the attack tree to determine it’s likelihood.
The parent node of your attack tree is typically your threat objective.

Stage Seven: Risk and Impact Analysis
PASTA threat modeling is about reducing risks.
The end goal for stage seven, is to build countermeasures that mitigate the threats that are important.

https://versprite.com/blog/what-is-pasta-threat-modeling/
  • The Process for Attack Simulation and Threat Analysis (PASTA) is a seven-step, risk-centric methodology


It provides a seven-step process for aligning business objectives and technical requirements, taking into account compliance issues and business analysis. The intent of the method is to provide a dynamic threat identification, enumeration, and scoring process. Once the threat model is completed security subject matter experts develop a detailed analysis of the identified threats. Finally, appropriate security controls can be enumerated. This methodology is intended to provide an attacker-centric view of the application and infrastructure from which defenders can develop an asset-centric mitigation strategy.
https://en.wikipedia.org/wiki/Threat_model
  1. TRIKE is an open-source threat modeling methodology that is used when security auditing from a risk management perspective. TRIKE threat modeling is a fusion of two models namely – Requirement Model and Implementations Model. The requirement model is the base of TRIKE modeling that explains the security characteristics of an IT system and assigns acceptable levels of risk to each asset. This model also enables coordination among different security teams and stakeholders by providing a conceptual framework. After this comes the implementation model. In this model, a Data Flow Diagram (DFD) is created to illustrate the flow of data and the user performed actions within a system. In this model, threats are analyzed to enumerate and assign a risk value. Based on this, security controls or preventive measures defined to address the threats as per the priority and assigned risks.
https://www.eccouncil.org/threat-modeling/

  • Trike is an open source threat modeling methodology and tool. The project began in 2006 as an attempt to improve the efficiency and effectiveness of existing threat modeling methodologies, and is being actively used and developed.
http://www.octotrike.org/#:~:text=Trike%20is%20an%20open%20source,being%20actively%20used%20and%20developed.




  • VAST
The Visual, Agile and Simple Threat (VAST) methodology[12], is based on ThreatModeler, a commercial automated threat-modeling platform. VAST requires creating two types of models: application threat models and operational threat models. Application threat models use process-flow diagrams, representing the architectural point of view. Operational threat models are created from an attacker point of view based on DFDs. This approach allows for the integration of VAST into the organization's development and DevOps lifecycles
https://en.wikipedia.org/wiki/Threat_model





  • OCTAVE
OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation) is an approach to identify, assess, and manage risks to IT assets. This process identifies the critical components of information security and the threats that could affect their confidentiality, integrity, and availability. This helps them understand what information is at risk and design a protection strategy to reduce or eliminate the risks to IT assets.

https://www.eccouncil.org/threat-modeling/




  • DREAD
DREAD methodology is used to assess, analyze, and find the probability of risk by rating the threats as described in the image below.
https://www.eccouncil.org/threat-modeling/

















  • Persona non grata
This method is similar to criminal profiling in law enforcement. To anticipate attacks in more detail, brainstorming exercises are performed to create a detailed picture of a hypothetical attacker, including their psychology, motivations, goals, and capabilities.
https://www.cisco.com/c/en/us/products/security/what-is-threat-modeling.html#~methods-and-tools
  • Attack trees are conceptual diagrams showing how an asset, or target, might be attacked. Attack trees have been used in a variety of applications. In the field of information technology, they have been used to describe threats on computer systems and possible attacks to realize those threats.
https://en.wikipedia.org/wiki/Attack_tree
  • GDPR enforces the implementation of Privacy-by-Design and Privacy-by-Default paradigms to be embedded within the software development lifecycle. But how should you execute a thorough privacy assessment of your software system?

LINDDUN is a privacy threat modeling methodology that supports analysts in systematically eliciting and mitigating privacy threats in software architectures.
LINDDUN provides support to guide you through the threat modeling process in a structured way.
In addition, LINDDUN provides privacy knowledge support to enable also non-privacy experts to reason about privacy
https://www.linddun.org/
  • VAST
VAST (Visual, Agile, and Simple Threat) methodology is based on automated threat modeling that covers the software development life cycle across the organization with proper integration with tools and collaboration with all key stakeholders like developers, architects, security professionals, and leaders across the organization.
https://www.eccouncil.org/threat-modeling/