Trike

By Anonymous -

Credit: https://www.octotrike.org/images/octotrike_logo.png
Sparked from a question on our public discord channel https://discord.gg/HeHuehh


What does GRIMM's threat modeling process look like?  Is it only used in the design phase of the Software/System Development Life Cycle (SDLC), or can it be applied to systems already in production?

We use the Trike methodology on account of it's friendliness to people who are not security experts.  Like most threat modeling methodologies, it is most efficient when it's used even earlier than design: at requirements phase of the SDLC. When there are requirements like "no need to set up an account" and "make sure user-entered data is kept confidential" it is really difficult for anyone to implement that in a way that isn't going to surprise some of the business people down the road.

What information are we talking about here? Does this include things like usernames, or is it just things like email addresses and phone numbers?  From whom should it be kept confidential? Should my name be kept confidential from friends on the system?  Should the system prevent administrators of the server, database, or cloud that it's hosted in from seeing this info? Getting these things clearly established is pretty important, and Trike helps get everyone on the same page. This can be done after the product is already deployed at well. In fact, some of the analysis is easier, because there's already a concrete system in place which is not constantly changing.  However when people find out their systems aren't providing the level of protection that they want, it's a lot more effort to make changes on systems that have already been deployed.

During threat modeling engagements, we want to make it clear to everyone (product owners, managers, developers, operations, etc.) that threat modeling is an ongoing process. It's not something you do at the beginning and never look at again. Every time a feature is added that changes who can access what, it should go through the threat modeling process to make sure everyone is on board.  It's more planning and coordination up front, but less time spent re-doing things or having to patch weird edge cases that weren't considered.

The Trike project describes it best, but the oversimplified explanation is we figure out who are the actors, what are assets within the system, what are the intended actions of the system, what are the rules that governed the intended actions.  From the Trike original whitepaper:

An actor is a human being who interacts with the system in some way. Actors must interact with some part of the system which is in scope for the threat model. 
Assets are normally discrete data entities, but sometimes physical objects, which feature in the business rules of the system. Assets are things which are inherently meaningful in the problem domain of the system, not merely in the way the system is implemented.
Actions are things which actors do to assets. The intended actions demonstrate what the system was designed to accomplish, where are the functional requirements to denote how the system should accomplish those actions.

Some of the questions we explore include: 
  • What privilege levels exist? (i.e. who uses the system, including roles who you don't really want to use the system like "anonymous internet user" but they can)
  • Determine what the system needs to defend against? (e.g. should an admin be able to see or manipulate everything?)
  • Defining what things need protecting and from whom, and then going through the architecture to determine if this is happening in theory (e.g. in the design).  

Once the threat model is done, we have a map of all of the places where there could be security issues. Implementation review checks two things: does the implementation match the design, and were there any programming errors that are going to cause a security incident. For example, analyzing functions to see if authentication flows match what was depicted during the threat model. We do this for all use cases, of which authentication is merely one. For any notable findings along with mitigation recommendations are provided to the product owners for evaluation.

The output of the Trike threat modeling process is a complete understanding of the system, its actions, actors that interact with it and understand the risks associated with it. This is an ongoing process and should be revisited with configuration changes or upgrades of the system. If you need assistance with threat modeling systems you built, or rely on, feel free to reach out to us!

Popular posts from this blog

New Old Bugs in the Linux Kernel

By Anonymous -
Image
  Introduction Dusting off a few new (old) vulns Have you ever been casually perusing the source code of the Linux kernel and thought to yourself "Wait a minute, that can’t be right"? That’s the position we found ourselves in when we found three bugs in a forgotten corner of the mainline Linux kernel that turned out to be about 15 years old. Unlike most things that we find gathering dust, these bugs turned out to still be good, and one turned out to be useable as a Local Privilege Escalation (LPE) in multiple Linux environments. Who you calling SCSI? The particular subsystem in question is the SCSI (Small Computer System Interface) data transport, which is a standard for transferring data made for connecting computers with peripheral devices, originally via a physical cable, like hard drives. SCSI is a venerable standard originally published in 1986 and was the go-to for server setups, and iSCSI is basically SCSI over TCP. SCSI is still in use today, especially...
Read more

Automated Struct Identification with Ghidra

By Anonymous -
Image
At GRIMM, we do a lot of vulnerability and binary analysis research. As such, we often seek to automate some of the analysis steps and ease the burden on the individual researcher. One task which can be very mundane and time consuming for certain types of programs (C++, firmware, etc), is identifying structures' fields and applying the structure types to the corresponding functions within the decompiler. Thus, this summer we gave one of our interns,  Alex Lin , the task of developing a Ghidra plugin to automatically identify a binary's structs and mark up the decompilation accordingly. Alex's writeup below describes the results of the project, GEARSHIFT, which automates struct identification of function parameters by symbolically interpreting Ghidra's P-Code to determine how each parameter is accessed. The Ghidra plugin described in this blog can be found in our GEARSHIFT repository . Background Ghidra is a binary reverse engineering tool developed by the National Sec...
Read more

SOHO Device Exploitation

By Anonymous -
Image
Netgear R7000 SOHO Device Exploitation After a long day of hard research, it’s fun to relax, kick back, and do something easy. While modern software development processes have vastly improved the quality of commercial software as compared to 10-15 years ago, consumer network devices have largely been left behind. Thus, when it’s time for some quick fun and a nice confidence boost, I like to analyze Small Office/Home Office (SOHO) devices. This blog describes one such session of auditing the Netgear R7000 router , analyzing the resulting vulnerability, and the exploit development process that followed. The write-up and code for the vulnerability described in this blog post can be found in our NotQuite0DayFriday repository. Initial Analysis The first step when analyzing a SOHO device is to obtain the firmware. Thankfully, Netgear’s support website hosts all of the firmwares for the R7000. The Netgear R7000 version 1.0.9.88 firmware used in this blog post can be downloaded from this web...
Read more