Automotive Security | Modeling — Introduction
Hey there my fellow nerd! Welcome to the second article in the automotive security series I will be working on. This articles/modules topic is on modeling! What I mean by this is that we will be going over some threat modeling techniques to help us rank vulnerabilities we may come across or even poorly developed systems. This article should not be super long but it will count as a module in the series! So, for today’s case, and simple intro question; Why? Well, like every standard vulnerability occurrence, we should always use some form of thread modeling system that can tell us exactly how big or small our vulnerability is. The reason these systems are used are to make sure that data is also organized and can be properly presented when we report our vulnerabilities. So, in today’s case, we will be going over a few standards that work best in the automotive world and why they do as well as how to use them! Before we dive into everything, I want to separate this module into a few sections so we know exactly what we are doing and what we are reading at the time!
Modeling & Rating | Why systems are used: A section that lightly explains why modeling threats is important.
Modeling & Rating | Modern Attack Surfaces: A small section that talks about how massive the attack surface of a car is in today’s world.
Modeling & Rating | Active Threat Models: A section that talks about a threat modeling levels (0–1 Birds-eye-view & receivers) and also explains where these come helpful.
Modeling & Rating| Threat Rating : This section deeply explains what threat rating is, how it works, why it is useful, and the different levels that come out with it.
Modeling & Rating | Rating Systems — DREAD: A section that talks about the DREAD rating system, one of the more popular ones. We will be also bringing up systems such as CVSS, ISO 26262 ASIL, MIL-STD-882E.
Modeling & Rating | Threat Modeling — STRIDE: A section that expands on threat modeling and talks about the STRIDE threat modeling system. We will be demonstrating the use case in the automotive security world.
Modeling & Rating | Summary && Conclusion → Subsection that summarizes and concludes this module.
Modeling & Rating | Ending Note → Primary section that talks about who I am, why I am doing this, organizations and projects I have going on, where you can find me, how you can support me financially and generally, resources to grow your automotive security knowledge.
Since I plan to keep this module a bit more short, I am going to go ahead and just jump right into it!
Automotive Security | Modeling & Rating — What? & Why?
The first thing we should understand is what exactly these two things are. Below are the two terms which are both described differently.
Threat Modeling: Threat Modeling is a bit more of a different process. Threat-modeling involves the process of identifying and modeling or planning out a threat as well as noting key ways to mitigate the threat. The focus of threat modeling is to understand the security structure of a system and identify the possible attack vectors and weaknesses in the design or the implementation. This can help companies or even individual’s understand where their idea’s may be the a huge risk.
Threat Rating: Threat rating is how we can basically prioritize risks based on their potential impact and likelihood which in turn will help organizations or researchers allocate resources efficiently to manage these risks effectively. This also can help when we need to understand vulnerabilities on a deeper level or need to get a concrete plan down to demonstrate the impacts of the vulnerability and organize data collected.
Both rating and modeling steps are extremely important because they allow security researchers to organize their findings, document them and demonstrate how truly big or small the impact is and what needs to be worried about first or last. In the automotive security world, threat modeling and rating is extremely important because security researchers have to be absolutely on their toes with this stuff and they have to know exactly what they are looking at and the severity of it! If you are tracking multiple vulnerabilities, pick the one that will allow full vehicle takeover or lead to that in the further future! Either way, it is primarily important because if security researchers are not on their toes about specific vulnerabilities or even using proper methodology; then human lives are at stake! Now of course we do not have to be all mr-stuck up all the time and that is not at all what I am saying. But when security researchers in the automotive world do find a vulnerability or are searching for one, they need to keep their head on a swivel and know what to look for and how that vulnerability can be rated.
Modeling & Rating | Modern Attack Surfaces
In today’s world, we have cars that can go a hundred miles an hour in under seconds and cars that can also slow down the vehicle if they detect some form of sleepiness behind the wheels, but how does all of this work? Every since the early 2000’s and actually mid 90’s, brands such as Mercedes's have implemented bus protocols such as CAN ( Controller Area Network ). The purpose of automotive protocols such as CAN and networks inside of cars is to tie down the amount of cables that would be needed for a car to- well, work. Because these networks, protocols, systems, and modules have been getting more and more advanced as time goes on, so has the modern day attack surface of a vehicle. For example, take your average and cheaper end 2003 ford focus’s for instance. Those cars, while still using automotive protocols such as CAN, do not fully operate on the network, sure some systems and diagnostics is required and turning the turn blinker on and off will trigger something in the network; but the doors, windows, and a majority of other features in the car were still all mechanical even if they did interact with the network a slight bit. Then take something like a 2019 Audi-A5 Sports-back edition. When you look at that car what exactly do you see? Take the image below of the internals of one for example.
In this picture here, I can already map out a million things that are digital.
The Steering Wheel: The steering wheel is a control panel pretty much in modern day cars. They have systems or mechanisms inside of them to interact with the cars calling system, Bluetooth system, call answering system, volume control for the radio, and other various systems.
Infotainment Console: The infotainment console on most cars today or really every car is digital and relies on the internals of the car to also connect to remote servers and devices such as WiFi and Bluetooth. This type of system may be susceptible to attacks from malicious actors who have access to the WiFi network of the car.
Instrument Cluster: The instrument cluster is a good one. I have mentioned in previous articles that through simulations, we can simulate how instrument clusters rely on the network of a car to feed it information. For example, when working with the seat-belt sensor, every-time the seat-belt in a modern day car with these systems clicks on, it sends a signal to the network and will disable the “seat-belt required” sign in some cars. This console is a good example of how connected cars are with their networks as they rely on these systems and protocols to feed them reliable information.
Doors: The doors also have their own control panel there which as we might see are all remote controls. Its important to note that even if it is on that door, that the door unlock/lock systems may also be sending data over the cars network because if the car is in drive and the car doors are unlocked, the system may need to warn drivers that the car door is not locked through the instrument cluster.
There are also tons of other systems that can be exploited inside of a car, and I am sure you never even thought about monitoring systems such as TP monitoring systems (TPMS/TP = Tire pressure Monitoring System). These types of systems are also not becoming much much more web rounded as well, and you know what that means- mix today’s current horrible web security with a car- yeah, bad; can you imagine? This is why it is important to stand aware, a while back, passwords were a major issue and even today some people still use the smallest most easiest to guess passwords despite new standards. Now with cars, we are going to have people who do not care to make their WiFi networks private, not worry about Bluetooth security or general device security. Now, of course this road-path is still so new and not many people have had the time to realize it nor have there been nearly enough case studies to show people and grab people’s attention on this matter. Lets take a second to acknowledge something.
Note: This next section might be primarily bias, because it is based on my experience and knowledge in this field as well as networking with thousands of people that are decades older than me and have more experience in these fields whilst being here practically before the field was even considered “real”. So please, approach this next section with absolute caution, note that it is bias and is only used to raise an eye and a hand that is open for debating.
Being Sort Of “Radical” With The World
For decades, the idea of the internet has both been designed and alive, there are multiple forms of the web, millions and millions of different technologies for web, different types of encryption, authorization, hundreds of programming languages if not thousands including private languages and the list just goes on. Web security is the most popular field because if we all are being honest; the web has always and will always be one of the most important things and will be everything in the tech world. Without the internet, 99.5% (possibly) of computational systems just could not operate properly. It took people years to realize what not making a correct password could do to their bank accounts, store accounts, personal lives and more; it took thousands and thousands of ransomware attacks to get people to realize how deadly it is and detrimental it can be to systems that run on networks for hospitals or other various buildings. Now we are hitting a stage where everything or nearly everything in a car is going to be web based, there are a ton of case studies out there and a good example of one is the jeep hack. But that only showed what the affect could have been if someone had gotten into it. I feel that many people will not care about security of cars or automotive systems in general until something horrible happens such as a major terrorist attack. I do not need to reference it to tell anyone what I mean but I am guessing you are assuming the airports and how physical security was not taken heavily enough. I can see the same exact thing happening in the automotive world once someone developes a malware or exploit sophisticated enough to remotely kill cars or even damage systems in the car killing 10 maybe 20 and possibly hundreds at a time.
Now that we can call that done and over with, I would like to list off general systems that are in almost every car today that are going to be vulnerable.
Bluetooth Systems: Bluetooth systems are one system that is seriously overlooked and often not taken seriously because it can take a ton to exploit a Bluetooth device, but with the right vulnerability, it can be extremely easy.
WiFi Networks: WiFi networks are about the easiest system or type of networks to attack because of how either open, non secure they are, and what can be found on them. For example, IoT devices such as the GoogleChromeCast use SSDP for service discovery and will send paths in plain-text over the network to API’s that can be used to gather system information. If the networks on cars also do the same thing, mix it with free networks that are left open on cars or standard passwords that are never changed and now you can easily spot most endpoints or even flaws in the network that may lead to more discoveries on the network of the car. Not to mention, hackers could also get into the network and still be connected from longer distances.
Monitoring Systems: Monitoring systems are all attached to electrical control units in a car which are used to send the results of the diagnostics through the systems to be displayed, in basic terms anyway. A simple way a hacker could take advantage of these systems is by forcing the monitoring system to send a fake or forged signal to the receiver or ECU which may cause the engine to stop or force the driver of the car to pull over and make sure nothing is wrong; when nothing truly is wrong with the car.
Infotainment Systems: As mentioned before, infotainment systems are a massive system that is attacked a ton simply because most of them run third party software, which we will talk about in just a second.
Radio Systems: Radio systems are a pretty undermined and overlooked system as well because they are just not expected to be vulnerable when in reality, most modern radio systems interact with internal API’s.
Key Fobs: This is one thing that is popular right now, but the most susceptible attack to these devices on a car is where an attacker could remotely record the signals sent to the cars reciver and play them back which in turn makes a mock or copy of that key fob.
There are many other systems as well such as cellular systems that can be taken advantage of. Now, lets route back to something I talked about in the point of monitoring systems and radio systems, this brings us to the wonderful and horrible world of third parties.
Modern Attack Surfaces | A Note On Third Party Systems
I have mentioned this before, but third party applications are my worst nightmare and in 90% of cases, I do not believe they should be used. Let me give a bit of a personal background. A while back in the early days of 2023 I started a project known as the SkyLine programming language. A modern day interpreted programming language dedicated towards cyber security related tasks. The reason I did build this language originally was not because of cyber security related tasks, I just was tired of running Python scripts that required a million third party libraries when you could have easily made them yourself. So, I built a language that would be used for web hacking, binary exploitation, reverse engineering and more without having to use Python scripts or Perl or even C scripts that were overly bloated with third party libraries. Not to mention I built the language to allow interfacing with Go/C/C++/Rust/Crystal/Fortran and various other programming language’s easily. I did this because I primarily could not trust and again got tired of using third party libraries. People who use third party libraries for the simple scripts or programs are a good example of the negative use cases of a third party system. In cars, sadly enough, no manufacturer makes their own systems much anymore asides from their API’s that interact with the networks in the car. Infotainment consoles, radio systems, management and record systems might all be third party. Below I have listed some points that might tackle this a bit more.
No Control Over The Software: If a automotive system is using a third party system to manage some of its internals and said system is now vulnerable to some exploit that allows total takeover remotely, the developer of that system is the only one that has control over the software. Sure, the user could update the software, but they have 0 control over what is managed and what is patched or what is hidden and so on from there. This is a huge downfall because in the further future, some of the systems that automobile manufacturers implement today, 2 years down the line even a year down the line might be abandoned by the developers and thus just not patch-able without direct access to the product.
Chaining: Chaining is quite the affect, for example, some people may recall that a specific python library for hacking / security research relied on many other third party libraries (hint: the library was pwntools) and then from there used libraries that chained other libraries and then the chain goes on and on. Because of this chain, at the very end, a singular third party library had become vulnerable, then the library that pwntools imports and uses had also become vulnerable because that library relied on the vulnerable library finally ending in pwntools, a third party library, becoming vulnerable to specific attacks. The idea that third parties rely on more third party systems is a huge downfall and a good example of how bad third party libraries can be. Some of the libraries used in some applications are just over popular and a nest for vulnerabilities.
Monitoring And Logging / Trust Issues: Another huge reason why third party systems are quite easy to pass by but are also a huge security risk is because of the trust issues with third party vendors. If a car company such as Chrysler was to put in a system that can auto answer calls, auto save call sessions, auto save voice mails and more; there is a privacy issue there that might have been buried deep from the owner of the system that states we have access to all calls that come in and out of our system and so on legal details that may state why they are allowed to do that. This is an issue because its just the break-point in privacy and will raise a hundred other ethics issues especially in the political world!
This is just some of the good examples of where third party systems fall short and the dangers they can pose when it comes to automotive security. But, that is as far as we will go for now. Since this article is supposed to go down into threat modeling and rating, lets get more into the rating aspect of things.
Modeling & Rating| Threat Modeling — Level 0–1
We have already talked a good bit on threat modeling, but there is one important key topic I forgot about — the levels. Wait a second, there are levels? Yeah! Thread modeling also has its own form of levels and steps during the viewing process! These types of levels are defined below.
Level 0: Level 0 is the first step in threat modeling you will come across and is typically referred to as the “birds-eye” view. This type of approach is used to identify major components and interactions within the system while also having the end goal of understanding the systems architecture, key functionalities, and potential entry points for threats or attackers! This system is basically like a layout and a general blueprint before the construction.
Level 1: This is known as the receivers level which is the process of narrowing down the focus from the systems architecture to specific receivers of input within the system that was analyzed. This step usually involves examining how the system processes inputs and responds to them such as authentication, network data, uploads and so on from there. This levels prime point and aim is to understand potential security flaws and vulnerabilities that might exist inside of the system when handling input.
Each level also has its own key steps and each one can be broken down into their own systems. However, it is important to note that while some of them have their own set of key steps, pros, and cons they also make the whole threat modeling process up! Below I have sectioned their key points.
Birds-eye View — Steps And Process
Image Of Birds Eye View — Taken From: Car Hackers Handbook
Step 1 → Recon / Identification: The first step within the birds eye view is to identify the major components of the target system. This can fall under researching into hardware, network elements, and other systems that are external or internal to the system. This will help us ensure what the system may be possibly filled of vulnerabilities or which one may be more likely to attack.
Step 2 → Data Flow Definitions: The next step is to trace the flow of data within the system. In the case of a car, we may be executing or carrying out this step on the network to see how the data actually flows or how specific systems are working. This is more recon and information gathering but the point of this is to highlight potential areas where sensitive information could be at risk. Think of it like using wireshark to see if there are passwords being used on unencrypted and insecure FTP servers but in a much more complex network and setting.
Step 3 → Entry Point Spotting: Entry Point Spotting is something that is heavily shown in the graphic above. As the name implies, the point of this step is to help security researchers identify key entry points of the system which is where an attacker may want to go to gain access to the system. In today’s cars this may be anything from the API’s and interfaces used to external network connections.
Step 4 → High Level Threat Identification: As the name also implies here, this step involves focusing on identifying and categorizing the amount or type of threats and risks that said system might be facing. An example of this is unauthorized access.
Step 5 → Documenting / Information Gathering: The last step is documenting the information and the findings then drawing out the map. In this case, this will be where we gather relevant documentation, diagrams for the architecture and even other available resources to help gain a comprehensive understanding of the system we are targeting; yes, even if it is proprietary.
As you can imagine, these steps are all extremely important and help in so many different worlds! You can possibly even see this being applies outside of automotive security as well!
Receivers — Steps
Receiver Model Example — Car Hackers Handbook
Step 1 → Identifying Receivers: In this step, which is a pretty important step, we determine the various components, mechanisms, or modules within the system that receive external inputs such as user inputs or data from external API’s. Understanding and identifying these systems are quite important because it can teach us what a system does and what the system may be using to take input in or what parameters the system may need.
Step 2 → Input Validation: Input validation is another good step as this one will tell us how each receiver will validate and process the received or captured inputs, whether it is from a user, API, or network data set. This step helps us identify potential areas where input validation is inadequate leading to security vulnerabilities like injection attacks.
Step 3 → Security Controls: Analyzing the security steps is right there with step 2. In this case, we are looking for security controls and mechanisms set in place to disallow or prevent malicious input given from API’s or users. This may include input sanitation, if its connecting to a database then it may validate or sanitize queries and more. This is an important step because it determines how we will move forward or if we need to at all.
Step 4 → Attack Surface: Defining the attack surface is another great step, in this step, we define the attack, surface of each receiver we can find and identify steps or exposed endpoints where an attacker could interact with the system. This can help us better identify and understand the types of inputs that are allowed and the potential attack vectors of that system.
Step 5 → Threat Identification & Mitigation: In this last step here, the focus shifts towards identifying specific threats and risks associated with the input handling process which includes threats like SQL injection, NoSQL injection, XSS, CSRF and other various attacks ( depending on the system. We may also come across buffer overflows but it mainly depends on the type of application we are targeting and looking at ). When we do actually identify and understand the threats we are up against, we can go ahead and purpose and discuss potential mitigation strategies to address the identified risks or vulnerability on the receiver level of things.
As you can see, both levels (0–1) are extremely important. But why do we use them in the automotive world? Well, like every other point of security research, its important to gain a full understanding of how a system works before we target it. In the case of cars, the risks drastically increase! For example, if we go into hacking or reverse engineering the network of the car blind and just start sending data over the wire and random streams of bytes without directing them somewhere, there is a possibility we may hit the wrong ID on the channel or the wire and say accidentally accelerate the vehicle instead of our target which may have been to unlock the doors. Systems like this give us a good direction of where we are supposed to go and how we are supposed to handle things. Of course, when it comes to cars; you will most likely be put in a black box scenario where you no nothing about the systems in a car. But, starting with the steps of these models are a good direction to getting more information on the car itself, the systems it uses, the network, which applications rely on what, what parts of the car actually require other forms of functionality, and so on from there. Now that we have a good understand of how threat modeling works, lets jump a bit more into threat rating and how to do it!
Modeling & Rating| Threat Rating, How It Works And Why
We already gave you a small rundown of what threat rating is, but we did not go too too deep into how it works and why it works as well as why we do it other than the smaller side of why it exists. So, in this section, we will be talking about why exactly it works for us, how it works on a deeper level and also how you should start it. Without anything else to say on the matter, lets dive into it.
As the cyber-threat landscape continues to evolve which is constantly driven by the advancements in technology, so does the cyber criminals along with it. It really does go to show that as tech advances, the criminals will with it. To effectively defend against the advancements criminals have made, there needs to be some type of proactive and adaptive approach that can help us. This is where threat rating seriously shines! Threat rating, as mentioned before but in deeper detail is a process that involves analyzing a risk and looking into all of the potential risks considering both internal and external threats. But where does this process aid us? This process not only aids in identifying specific vulnerabilities but also facilitates informed decision-making by prioritizing a specific set of risk mitigation efforts based on the severity of identified threats. But aren’t all threats important? You are very correct on that, no matter the scale, no matter the affect that threat has, no matter what it is or how it works; it is still a threat and needs to be taken care of. But lets throw this in a smaller example for you to better understand why risks are rated. Say we have a car and we have identified three threats. The threats are listed below.
A vulnerability that allows hackers to take full remote control over the car
A vulnerability in a single API that will expose all of the cars, owners and even possible passenger information if linked.
A vulnerability that will allow hackers to change radio stations actively.
These are all extremely powerful vulnerabilities that if taken advantage of in the wrong hands can be super deadly or can end in something else being exploited. But which one is more important? The first vulnerability when exploited should be rated to be the most deadly and most import vulnerability to solve. Now of course, as mentioned before, the other two vulnerabilities can also lead to some serious harm. However, when a hacker can remotely target a car and then gain access to its functionality such as breaks, acceleration, diagnostics and logging, recivers and more- things really start to get dangerous and at this point you are going to need to take care of this one first. This is where threat rating seriously comes in handy, it is not dismissing the other vulnerabilities but rather allowing us to take the findings and research then tell the company or research center which one is the one vulnerability that can cause the most damage and to who or how much.
Because threat rating is heavily used, there must be some key benefits of it right? Of course! I have listed some decent ones below that may help you better understand why it is used.
1 → Risk Priority: When it comes down to it, as we mentioned multiple times; the major benefit of threat rating is being able to show you what risk needs to be handled first and which one last. This kind of section is a major benefit of threat rating because it saves companies, security research groups and developers a ton of time since they do not always have to make proper and formal decisions on what should be handled right away because the priority of the risk has already been matched up and rated for them in the list. By understanding the potential impact of various threats as well by seeing their ratings, specific groups could invest much more money ( if they want to ) into technologies that can help mitigate these risks or threats in the future and even help with the patching!
2 → Resource Optimization: Another major pro to threat rating is the factor of resource optimization. What do I mean by this? Well, the idea of resource optimization is to save the amount of resources spent on specific risks. Because of the risk priority, teams and organizations could easily understand where to allocate or direct their resources and where to not direct them. This kind of optimization is seriously needed especially if an organization does not have many recruits to just spare! In other companies, you might find that this is rare, but regardless, no matter the size; it definitely helps the company on their resource development, funding and direction.
3 → Proactive Risk Mitigation and Decision Support: This is another super important one, but the last on the list because it is used throughout the process. When it comes down to threat rating, the one thing it helps with more and one of the more valuable parts of it is the factor that it can enable a proactive approach to risk mitigation and decision making. When companies do look at a threat rating, they are able to use the data that was collected or sent in for proper decision making and creating idea’s that can develop much more sophisticated preventive measures and even develop robust incident response plans to help neutralize threats before they escalate into full-blown security incidents.
These major pros are what make threat rating- work. Because it not only provides information about a specific threat or risk, but also rates them on a severity, it can help organizations and research teams put much more fluid idea’s to the table to help better prevent this. By now, you should at least understand how or why we rate threats the way we do. In summary, it just helps and gives people a bunch more to work with than just saying “here is a 10 page document on 20 vulnerabilities I found in your system”, instead its a much more deeper analysis of a threat.
Now, by the end of this section you should have a good understanding as to how threat rating works, but now we need to go deeper and use example models such as DREAD!
Modeling & Rating| Rating Systems — DREAD
This is something that I think you guys are going to find quite interesting! If you have not heard of it before, there is a commonly known rating system called DREAD. This is one of many risk assessment techniques and ways of measuring and rating a threat or risk but is one that I personally find much more easier to use. So in this section, we will be deep explaining and breaking down DREAD and also talking about how we can demonstrate a system. Below is a list of how we will be breaking down this section.
Rating Systems — DREAD | Where Ya From? → A section that talks about where DREAD came from and its basic upbringing / history. We will then talk about why it is a bit hated on now.
Rating Systems — DREAD | Damage Potential (D) → Dissecting the DREAD model starting with the damage potential mark and rating.
Rating Systems — DREAD | Reproducibility (R) → Dissecting the reproducibility part of DREAD (R).
Rating Systems — DREAD | Exploitability (E) → Dissecting the exploitability part of the model.
Rating Systems — DREAD | Affected Users (A) → Dissecting the affected users part of the model.
Rating Systems — DREAD | Discoverability (D) → Dissecting the discoverability part of the model.
Rating Systems — DREAD | Demonstration → A demonstration about using the DREAD model to model out a known vulnerability.
Rating Systems — DREAD | Alternatives Of The Alternative → A section that talks about possible alternative models
Note: At the time of writing this article (2023) DREAD has been discontinued and is known as one of the less-flavorful models in some security circles. We will talk about this more when we start this section but this is just good to note. We are using this model as a demonstration of threat modeling rather than saying “its the best rating system” when there are better alternatives out there.
Rating Systems — DREAD | Where Ya From?
The DREAD rating systems is one of the most basic rating systems out there and has quite the volatile popularity gain. Lets get a bit of an understanding as to how it works on a deeper level. A general background of DREAD is that it started and was introduced by Microsoft in the early 2000s as apart of their SDL (Software Development Lifecycle) process. There is no direct release date that has been documented, at least from what I have found, but I have also seen people talking that it has been first publicly documented and presented around 2004. Take that knowledge as you will, but in general, DREAD is well known but is also quite foreign. Like most other threat rating models today, the whole idea of DREAD was to prioritize potential risks associated with software vulnerabilities and major threats. This model really did help security professionals and even software developers ( in some cases ) assess and understand the level of severity of a given risk. Not to mention, it was also quite easy. This is also why it gained popularity quite fast — because it was just a simple and effective ( at the time ) way to assess and prioritize specific security risks. This also provided quite the approach to evaluating specific risks and again, recapping, helped developers and security researchers understand the potential impact of threats which can help them focus on the efforts of addressing the issues. It is important to note that while this model was good, it had a major downfall and today is not well practice actively especially given that the model was discontinued by Microsoft in 2008. There are reasons to this and the few primary reasons I have listed below.
Subjectivity — A Influential World: The first thing that we can take off the list was the subjectivity of the threat model. DREAD relies quite heavily on subjective judgments when rating different factors and each different individual within an organization might assign different cores based on their perceptions and interpretations of the risk- in other words, subject to bias. Of course this will exist anyway with or without DREAD, but in other models due to the complexity and the direct rating power; other models are quite hard to be subjective in.
Oversimplification — A primary downfall: Oversimplification is a complete killer in threat modeling, the same follows for over complication. In general software security you learn that when working with threats, there is a principal known as the Goldilocks principal. It has other names, but this one is a general principal. The idea of this principal when rating threats or even modeling threats is to make sure that when working with models, that a model is not too simplified and also not too technical. Threat models and rating frameworks should not go into the deep core depths of everything but also should not go into the most basic explanation that can be Googled. Rather, they should be much more dynamic and understandable while being technical.
Incomplete Coverage — A wider argument: Incomplete coverage is another example of the downfalls the DREAD model had especially during its earlier days of coming out. Researchers understood that this model was already too basic, and while DREAD focuses on the technical aspect of vulnerabilities and exploits; it completely fails to adequately address other aspects of the risk such as business continuity risks.
Situational Limitation && Ignoring Probability: While the DREAD framework was good for technical security teams that are assessing software vulnerabilities, it was not good for more broader risk management and enterprise-level security assessments due to its oversimplification of specific topics and vulnerabilities. This kind of ignorant side of the framework became quite the issue and actually bleeds into the factor that the model also ignored probability. The model itself does not explicitly account for the likelihood or probability of a threat occurring, which is extremely important. Now it does account for a higher scoring risk but there is an issue that lacks within its consistency of the ratings. In general, DREAD despite being a okayish model, had its issues with the consistency of ratings which affected the overall sight of probability. The point of that is to say that high-scoring risks will not mean that they are the most likely to appear or materialize in more technical terms.
Now, why practice or even talk about it if it is an outdated model? Well, some knowledge may be out dated, but it is good to be generally aware of how threat rating works, and DREAD is a perfect example of what a contradictive model can look like whilst also giving you experience in the threat model and rating world. Now, lets actually get into the model. Below are the following definitions and extensive explanations of each letter of the model (D-R-E-A-D).
Rating Systems — DREAD | Damage Potential (D)
The damage potential of the model is quite obvious. This part of the model explains the damage potential a threat can have if it is properly exploited. In the context of general software security, damage potential can vary quite widely and has so many different applications which all lie to be dependent on the nature of the software and its role within the system that is being targeted. Lets put this in a better example to easily understand it. Vulnerabilities in critical software such as financial applications or healthcare systems might have a higher damage potential due to the impact on human safety and financial losses and even going back to medical systems general privacy. Typically, the damage potential is determined using the consideration of possible outcomes such as data breaches and general unauthorized access.
Rating Systems — DREAD | Reproducibility (R)
The reproducibility is again as the name implies is how hard or easy the threat is to reproduce. This is basically a way of saying and explaining the process of evaluation for how easily an attacker can replicate the exploit and achieve the same results repeatedly which means they might even be able to automate the entire process. As you may know, a vulnerability that is easy to reproduce provides a consistent and reliable attack vector/space for attackers which can lead to MUCH more significant damage! This field is generally important because it can also determine the complexity of the vulnerability and the ease of obtaining proper resources. This is rated as follows.
For a vulnerability that is difficult to reproduce may have lower risk, but a vulnerability that is easy to reproduce is much more of a risk.
This is an important part of the model because it also considers other factors such as the level of expertise that is needed to test and exploit the flaw which will also show again as noted above, how easy or hard it may be for an attacker to properly attack it.
Rating Systems — DREAD | Exploitability (E)
This kind of falls under the similar idea of the section above. This is the direct attribute of the model that measures how readily an attacker can develop an exploit for the vulnerability. I will mention that attackers do not always develop exploits right away, you can literally Google specific exploits and just obtain a copy of it and change 2 things then have yourself a fully working exploit. The ease of exploitation, similar to the ease of reproducing the exploit significantly influences the risk that is associated with the vulnerability. This is because if an attacker can easily find an exploit or create one themselves the vulnerability immediately becomes more critical also due to the factor that it can be exploited by people that do not even know what they are doing. In summary, this part explores and considers weighing factors such as the ability and skill required to develop an exploit, complexity and skill to use the exploit.
Rating Systems — DREAD | Affected Users (A)
As the name implies, this is the assessment of how many users or systems will be impacted by the vulnerability if it is exploited. If the vulnerability affects a large user base then the risk level will be much more higher and vice versa. This is pretty easy to understand, but I threw a short instance below.
A vulnerability in widely used software or operating systems could affect millions of users such as a vulnerability inside of Windows10 which makes the vulnerability much more critical than a vulnerability in a smaller application with a smaller user-base.
Note that when it comes to software types as well, just because a single brand uses a type of software does not mean they do not have users. If you are a company distributing third party systems to other automotive companies for instance, then you also have millions of users. This means that if your system becomes vulnerable, it does not matter how many people are directly using your software, there are still millions of vehicles or thousands even the implement that software and are now affected.
Rating Systems — DREAD | Discoverability (D)
The discoverability factor is extremely important. For those who may not fully understand, the point of discoverability helps us determine how complex out threat may be due to the factor that if a hacker can easily discover it, then it may raise the exploitability of it and vice versa. If the discoverability is low, then it means that the vulnerability can probably be discovered through public disclosures, security research, or even by chance. For example, you may easily come across an IDOR (Indirect Object Reference) vulnerability in an application quite easily or it might be a bit more hidden and may take surfing through a few pages to actually find it or even a series of inputs and other systems. Note that when working for the discoverability, other important factors come into play with how visible the software is, how easy it is to access ( in the case of automotive security ), and the past history of issues of that same software.
Now that we have a good idea of how the DREAD model works, lets go over how to use the model or rather determine scores.
Rating Systems — DREAD | Demonstration
For this demonstration, we are going to go to a receiver point of the view on threat modeling and hit the receivers. For the DREAD example, we are going to say that we can work with the network of a car, more or less, the WiFi network on board. Lets make up some random scenario. Say we find a WiFi network on a brand new car and model. Note that this system may also be working with API’s and other various systems and web related technologies within the car ( and other systems ). We have a few things to address here. Note that our network is using a WPA supplicant, not specific, just general knowledge.
Issues with WPA Supplicants: If the version of the WPA supplicant is outdated, there are various issues that can become even bigger problems. Our first example is the fact that if the supplicant is older and outdated, it might not enable or implement WPA2 styled encryption. This is dangerous because older implementations used older style encryption methods such as TKIP which was susceptible to specific cryptographic attacks such as the “Michael” attack. Older versions may also leak information about the driver via network interface and may even allow attackers to easily setup malicious hotspots that can force it to connect to said hotspot. These are just some general idea’s to give a good reason of why they may be bad.
Lets go ahead and start rating our example, lets look at the DREAD rating chart below and follow the information on the chart, or at least better explain it.
This chart is pretty self explanatory, so lets get to rating! Remember we are looking at a level two of threats and on the receiver end of things. Our threat is also quite big! Look at the table that rates it below and following that the explanation. We will only be looking at a very specific set of vulnerabilities on these types of networks known as Man In The Middle attacks.
Let me explain this a bit more, you might also notice some weird points which going back to the pros of the threat model can actively show you.
First Rating (D=3): The damage of this vulnerability being exploited is severe as it can allow for complete control over the network if they can leverage it as well as control over specific parts of the data going on within the network.
Second Rating (R=3): MITM attacks especially on WiFi networks are quite reproducible but this can also depend on various factors as we mentioned before when discussing threats.
Third Rating (E=2): The exploitability of MITM attacks also depend on various factors ( are you starting to see the flaws? ) which all have their own various sections. Given the factors and parts of our flaws and the situation, the exploitability is set to a 2 because it may take extra knowledge on the hackers end and a little bit of experience.
Fourth Rating (A=3): While MITM is typically between one party, we can also say that a hacker can successfully position themselves between communicating parties and also intercept and manipulate the data passing from multiple parties if they can do so and have the resources. In general this can also be at a 2 or 1 depending on the case, but since ours is general case, we leave it at three.
Fifth Rating (D): The discoverability of MITM attacks is quite high even in very specific scenarios, for example, VPNoverview reported that 35% of attacks are MITM attacks, in our case, given out network is out and about; the discoverability of it may be pretty easy. Especially if the network is actively broadcasting data out about itself.
This was by far the most basic way you can place a sample, maybe it was not the best but you can say we tried hahaha! But how do we actually work with our findings, whats there to do next? How do we see if it is low, high or medium? Well, dread has its own ratings for that. Below is a table that shows the ratings.
Our adding and total number of points made on the chart was 14, which means that our risk level is high and is one of the higher priorities. Now, its also important to note that generally speaking, you take into account many other vulnerabilities but this was just a general example.
Now, lets get more into some possible alternatives, because you might have noticed quite the list of flaws not only during our own rating but even when using the model itself. For example, how simple it is- way too simple.
Rating Systems — DREAD | Alternatives Of The Alternative
There are many alternatives to the DREAD model system which we will go over here in just a second. But I will actually make a small statement on the alternatives and why they exist. Every model / framework has its own unique purpose and its own unique reason for existing within the realm of threat rating; however, as the world of threats grows, so do the models and you may notice in the future some models may change or may become out dated as time goes on due to the complexity of threats widely increasing and vice versa. Each threat rating model has its own system and its own unique abilities! So it is important that you do your research. We have some good alternatives that are listed below.
U.S DoD — Military Standard 882E: The first standard I would like to get away was a standard that was and still is used by the United States (U.S) Department of Defense (DoD) to manage safety and risk in defense programs. This unique model aims to outline a systematic process for identifying and assessing as well as mitigating specific threats or even hazards in military systems and equipment. You may not think it, but the military and government also have their own standards, systems, protocols and models and systems they need to follow and develop! Most of these systems are not talked about much same with protocols due to how kept away they need to be from the public especially in the case of warfare. You might be wondering, why even bother learning this standard or framework? Whats the point? Why is it better than DREAD. Well, as we have discovered, DREAD has quite the flaws and is not really used much, but there is a good set that can help us weigh the MIL-STD-882E model. The first one right off the bat is that this model in comparison to DREAD provides a much more comprehensive process for managing safety and risk that encompasses all the phases of a defense program from its bare concept to final disposal and use. This helps ensure that the model stays fluid throughout the lifecycle of the program. The secondary point would be how heavily this mode emphasizes mitigation. The standard deeply talks about the implementation of risk mitigation's measures which can help reduce the probability and severity of threats in the future and even current which is an extremely helpful part of this model especially for future development. The final point to make is that is has a wide consideration and takes into account multiple threats that include environmental, human, and even operational factors. Overall, the MIL-STD-882E model is one of the more in depth models and is used today, but might be a bit of a learning curve in comparison to DREAD.
ASIL (Automotive Saftey Integrity Level): Also known as ISO 26262, this model is an international standard for function safety in road vehicles. Within this standard, ASIL is also used to assess the safety-related performance of automotive systems and their internal components. This standard determines based on the potential severity of a threat ( as some common models do ) and also go into depth about the exposure to the threat, and the ability of safety mechanisms to help mitigate against the threat. There are multiple levels to this model, which are ASIL A, ASIL B, ASIL C, ASIL D which all go from lowest to absolute highest risk. This model is quite important because it allows the automotive industry to ensure that the design, development, operation, and etc of vehicles and their software as well as primary components prioritize safety and minimize the risk of accidents or injuries. The ASIL model plays a massive role in enhancing the safety of vehicles especially with the implementation of modern systems. But this model is used to rate physical hazards and threats right? No, that is not entirely true. ASIL was initially developed for accessing the functional safety in road vehicles but due to the world of automotive world growing with all new implementations has also been adapted to the cyber space! For instance, the model can also help identify cyber-security related hazards and access the risk severity within systems by being able to address their potential impact on the vehicles integrity! This model is more well tackled for various reasons, in comparison to DREAD anyway. This is because the model is not only safety-centric which means it is specifically designed to assess and mitigate risks in a specific domain such as automotive security but also has a hierarchical approach which means that it allows automotive developers to prioritize their efforts based on the levels of risk and potential harm!
CVSS (Common Vulnerability Scoring System): Also known as CVSS, this system is a widely and I mean WIDELY used and well-standardized framework for assessing and rating the severity of software vulnerabilities. This model provides a quantitative and quality scoring system that really helps security researchers properly and accurately document a software vulnerability and also allows security researchers to be specific without being too specific. What I mean by this is that the CVSS model takes into account the exploitability, impact on confidentiality, integrity, availability, and other various factors such as the complexity of the attack vector. But why is this so widely used? This scoring system has been widely used for quite some time because of how not only constantly it’s being improved and worked on but because of the new systems that it keeps implementing which makes it much more friendly! For example, let’s list a few common examples as to why CVSS is used in much more technical detail. The first reason I would like to clear up is the unique metric-based approach. CVSS uses specific metrics and formulas to calculate a vulnerabilities score which can provide a much more objective assessment. The approach also allows security analysts and stakeholders to compare and prioritize the vulnerabilities more accurately because of the formula CVSS may be using! With its popularity, the CVSS also has provided much more of a standardized and consistent method for evaluating and scoring vulnerabilities across different types of security teams. Because this language is so common or rather communication format is so common it allows for much easier and more easily understood communication when collaborations are in session for discussing the severity of vulnerabilities! Its mass standardization also threw in the third primary point for this system and that is its mass evolution over time. Every model improves in some shape or form, but CVSS is one of the most volatile in growth due to its community adoption, the scoring system is able to provide both base and temporal scores, and the constant room for improvement that the maintainers are always trying to do to ensure that the model is much more accurate, usable, and also stays relevant! This kind of community adoption, the power behind management and design, as well as complexity without being too complex is exactly what’s needed in a model!
As also mentioned, there is literally a land that is as vast and as wide spread as the world can see filled of threat rating models! But these are just some good pointers and examples that can show you the true power and versatility that other models have!
Lets go back to the world of threat modeling for a second and view another good example of threat modeling. I promise we wont go so horribly deep this time hahaha!
Modeling & Rating | Threat Modeling — STRIDE
The STRIDE threat modeling framework is quite easy to understand and is not used for complexity but is rather used for specific security threats in six different categories. You might be confused, why are we addressing levels of security and vulnerabilities rather than just standard threat models that try to map out the threats within a system? This is because STRIDE operates a bit differently than the standard threat model and instead wants ot focus on specific TYPES of security threats that can exist within a system. When STRIDE targets specific vulnerabilities specifically by categorizing them, it is able to target a particular type of security risk that may be common in specific systems.
STRIDE — Spoofing (S): Spoofing is the first category that the STRIDE model addresses. This type of attack is categorizing any type of attack where a bad actor might want to impersonate a legit user such as an administrator or even specific system component to bypass specific systems to gain unauthorized access. These type of attacks target authentication mechanisms which make it great to model out and rule out during testing of authentication systems.
STRIDE — Tampering (T): Tampering is another fun one, something many people especially during secure software design, completely forget to rule out. Tampering threats typically involve unauthorized modification or even altering of data during the transmission or even storage. Attackers may do this for various reasons whether or not its to erase logs or even lead to specific breaches such as data integrity breaches. This is quite essential to think about and even has its own set of models.
STRIDE — Repudiation (R): This type of threat is a bit of a weird one to explain, so bare with me hahah! Repudiation threats are a specific category of threats and are their own situation or category of security risk(s) that involve situations where entities within a system or even users may deny their actions. This type of threat typically occurs in systems or applications that involve digital transactions such as online banking, electronic document signing and other communication systems. For example, this type of threat occurs when a user involved in the system aims to claim they did not perform specific actions which can create a dispute over the authenticity of the actions. A better example is in the case of banking systems. Say that a customer during an online transaction with a digital banking system denies initiating a funds transfer. This can lead to quite the long argument and dispute over whether or not the transaction was fraudulent or if it was authorized. Sometimes this is not even on purpose, this is just considered a threat because it can ruin the accountability in specific transactions, can lead to legal issues if its not protected against and can also lead to fraud in a transaction system. This is why STRIDE aims to address this, not to mention; this general concept applies to almost all systems that require some form of communication. Think of it like someone trying to blame their own actions on a ghost.
STRIDE — Information Disclosure (I): Information disclosure is another big one. Typically, when information disclosure happens, it involves unauthorized access to sensitive data ( or in the case of a broken API, a single miss-use or even glitch in the program may be giving out excessive amounts of data, also known as a excessive information disclosure ). This is a major issue because if an application or data gets leaked or leaks data from itself such as too much information or can even be abused, then the company or group can also reflect a horrible reputation due to not securing user information or may even have programs and private source code leaked and so on. The list just goes on. Overall, this is important to address because even the smallest amount of private information leaked, can cause the biggest threats.
STRIDE — Denial Of Service (D): Denial of Service (DoS) is the most common vulnerability or threat to go over. This attack for those who are not familiar aims to disrupt the availability of a system or service by overwhelming it with excessive requests or sets of data. The STRIDE model addresses this by basically pointing out the amazing idea’s that load balancing might be something to consider as well as rate limiting to mitigate against this threat.
STRIDE — Elevation of Privileged (E): This is another huge one! Elevation of privilege is quite the threat that targets unauthorized access to much more higher levels of system privledges which can allow an attacker to take control over specific systems or even run specific programs with specific permissions that may be apart of a specific role. There are specific models that can also help that STRIDE aims to point out to such as role-based AC ( Access Controls ) and system of “least privilege”.
As you can see, the STRIDE model is much more different than any standard threat model and is used quite differently from the ones we have talked about. But, it is a good model to understand and also go over especially if our section is about threat modeling. I wanted to tackle this because I felt that it would also give you a broader amount of knowledge on threat modeling and how everything works.
Modeling & Rating — Summary && Conclusion
Sheesh, what another long article. Lets sum everything up and go ahead and end everything. The automotive series has been quite long, but there is a purpose; simply because as this world grows, the more people want to pump out all new technologies without barely understanding the risks to them. In order to properly assess and model the risks, its important to understand how vital threat modeling and threat rating is and how it ties this entire world together! The world of automotive is deep- it always has been and always will be, but, then again; be sure to at least understand some of it. In this article we talked about threat modeling and also talked about why they are important, how we use them in the automotive sector, why we need to use them and then finally talked about threat modeling and threat rating models to help us properly identify and categorize threats within a system from multiple view points. With knowledge like this, it should not be that hard to start drawing practice. I hope you learned something from this module, and if you did, then I appreciate you tunning in!
Anyway, below is an ending note thanking you for making it this far! So I do appreciate it and if you would love to support me, please throw this around!
Ending Note — Extra’s, Resources, Support, Thanks
Typically I never do like promoting stuff but I figured it was worth a shot. This section will provide you with basic information about me, some socials you can follow me on, how you can support me and some resources that were used to build this article / module. Apparently my articles are so long people are calling them “modules” so I will go with that for now hahaha! Below are some bullet points that showcase extra sections.
Ending Note | About Me → This section will talk obviously about me, who I am, why I am doing this, current projects etc.
Ending Note | Thank You → A section thanking you for reading this article and explaining why I value community.
Ending Note | Ways To Support → A section talking about ways you can support me with currency!
Ending Note | Where To Find Me → A section that talks about where you can find me and how you can follow me.
Ending Note | Resources To Advance Your Knowledge → A section that explains some basic resources used to help you.
Below, sections are listed and talked into!
Ending Note | About Me
Hello there nerd! My name is Ryan and I am commonly known as Totally_Not_A_Haxxer! I am a 16 year old security researcher and developer with quite the experience primarily in development (50+ language’s including working on my own) and take a huge interest in automotive security! I write the articles I write especially in length as well as books because I believe that knowledge is for everyone and should not really be charged so much. For example, I saw someone write a Golang tutorial that was like 10 hours of content and charged over 1K for it- I thought it was a complete waste of time so I started my blog page to not only do what they were doing but do it better and for free! I also have multiple projects going on around education such as $1 Courses which are courses on various topics in tech or even general that get sold off for a single buck! That is a small about me, you can find more which we will get into in quite a second hahaha!
Ending Note | Thank You
I want to also thank you for reading the article and coming this far, I know these articles are extremely large and take a ton of time but I hope they were worth it. I do try my best to actually go and put the time and effort into the articles by ensuring that I can actually help educate people and go deep into the topics I talk about for free! So, if you have made it this far, I appreciate giving the effort back as far as reading the article and hoped it helped :D!
Ending Note | Ways To Support (Financially)
Currently I am not in the best of situation with money and I do not have the proper funding to afford good equipment for security research even something as much as a laptop where I could do remote work. That being said, I have always been used to saying “I do what I do with passion, and I will stop at nothing to do so”. Even though I do not have the direct resources, I always do try my best to deal with what I have and do what I want to do with said resources that I do have. With this, I ask that if you can bother to donate or do have the extra to spare, this will make my development, skill and more go much MUCH more faster and also make me much more motivated to continue doing what I am doing! Below I have listed my cashapp and venmo as well as crypto wallets!
Venmo:
Venmo | Totally Not A Haxxer hacker Venmo is a digital wallet that lets you make and share payments with friends. You can easily split the bill, cab fare…account.venmo.com
CashApp:
BitCoin Address: bc1q45ctj3cwl8zr2qdw4xceukr58cdnayxuutymt8
Ethereum Address: 0x466BA936E2bdbEab74c8cd048CC43279fE712E54
USDC Address: 0x466BA936E2bdbEab74c8cd048CC43279fE712E54
Tether Address: 0x466BA936E2bdbEab74c8cd048CC43279fE712E54
XRP Address: r4s8FeyYCBHJQGJRGuDuPeM2YLMwRCZP4R
Ending Note | Where To Find Me
This sounds weird to say, but you can find me on a few places; social media is one of them. Below I have listed some links of where to find me but I will say this. Often in discord servers, communities and even other platforms: some people always ask me for links and I can get tired of constantly pasting social media links on days where I have a bunch of stuff to do and given social media is not on my phone ( at this time, working on a study / ghost month ). SOOOO, that being said, Google is a good place to go literally search “Totally_Not_A_Haxxer” and some of my socials should pop up + look at it this way, you get more OSINT experience.
Instagram
Medium:
Totally_Not_A_Haxxer — Medium Read writing from Totally_Not_A_Haxxer on Medium. Cyber Security Educator, Developer, Social media manager, Author…medium.com
Blogger:
Hakin9 Articles / Research point
GitHub
TotallyNotAHaxxer — Overview Single Developer of the red rabbit project, leader of the scare security team, and Single developer of the Grizzly…www.github.com
Google: https://www.google.com/search?q=totally_not_a_haxxer&sxsrf=AB5stBjHLrW6iWuxLvuh7jKHebe6L-BTGQ%3A1690923815850&source=hp&ei=J3PJZJqkL-nakPIP7dqCgAo&iflsig=AD69kcEAAAAAZMmBN09YHcUlW2STp8BofYjoKR1t0GgH&oq=tota&gs_lp=Egdnd3Mtd2l6IgR0b3RhKgIIADIHECMYigUYJzIEECMYJzIHEAAYigUYQzIHEAAYigUYQzIHEAAYigUYQzIHEAAYigUYQzIHEAAYigUYQzIHEAAYigUYQzIOEC4YgAQYsQMYxwEY0QMyCBAAGIAEGMkDSMYGUABY1QJwAHgAkAEAmAGtAaABhQWqAQMwLjS4AQPIAQD4AQHCAg0QABiKBRixAxiDARhDwgIIEAAYigUYkQLCAhMQLhiKBRixAxiDARjHARjRAxhDwgILEC4YigUYsQMYkQLCAg0QLhiDARixAxiKBRhDwgIKEC4YigUYsQMYQw&sclient=gws-wiz
Ending Note | Resources To Advance Your Knowledge
For the automotive world, I can not recommend much resources because there simply are none in this world. Let me take that back, there are, but there could always be more- and there are not many good explanations anyway and not that many good resources out there for automotive security. This is also why I started this series of articles. But below I have listed some decent resources on threat rating and modeling.
Threat Modeling & Rating Basic Resources
Threat Modeling Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html
What is threat modeling: https://www.spiceworks.com/it-security/network-security/articles/what-is-threat-modeling-definition-process-examples-and-best-practices/
CVSS scoring: https://www.balbix.com/insights/understanding-cvss-scores/#:~:text=What%20is%20CVSS%3F,of%20an%20information%20security%20vulnerability.
STRIDE: softwaresecured.com/stride-threat-modeling/
DREAD: https://www.fairinstitute.org/blog/how-to-use-dread-analysis-with-fair#:~:text=DREAD%20is%20a%20framework%20that,%2C%20Affected%20Users%2C%20and%20Discoverability.