Amenaza-Technologies

08/26/2024

These days a lot of parents are seeing their offspring leave the nest and head off to college or other adventures. Of course, parents have spent immense effort getting their kids to this stage. But also experience a degree of loneliness and a sense of trepidation as to whether they have done enough to prepare them for the rigors of life in the Real World!

I know it isn't exactly the same, but we software vendors have similar feelings as a new release of software makes its way out the door! Today, Amenaza releases SecurITree v5.6. The new version has a significant new analytic feature to make it easier for analysts to understand what their attack tree models are telling them. There are enhancements to the machine learning function and improvements to the API (thanks to suggestions from a major national laboratory). There are the usual bug fixes and v5.6 is built using the latest Java - Java 22.

And the software development team and I feel the same sense of relief to see v5.6 make its way in the real world - mixed with the trepidation we always feel. Has all the testing been enough?! Did we miss anything?!

Amenaza's customers with support will be getting upgrade letters over the next few days. People who would like to try out SecurITree v5.6 are welcome to visit the Amenaza website to request an evaluation kit.

It warms the Amenaza heart to see v5.6 making its way in the harsh real world!

05/07/2024

I'm here at the RSA Conference in San Francisco. Always impressive - over 40,000 attendees. I guess somebody realized that this would be a serious target - they now have X-ray scanners and metal detectors at the entrances! But I digress.

One of the speakers yesterday mentioned that being a security professional is, for many, a calling (and not just a job). I certainly agree with that statement.

A super session today talked about attacks (cyber and kinetic) against the Ukrainian power grid. One of the speakers in the session was American - from Cisco - and the other was from the Ukrainian power company.

What is remarkable to me is how the two became connected. I'll probably get the details wrong, but it involved a happenstance meeting between a group of Ukrainian energy people who had come to the U.S. looking for power grid components to replace those being destroyed by Russian missiles. By sheer coincidence (or, in my opinion, divine providence) the group happened to run into the senior person from Cisco. And so the relationship began.

To digress a bit, I have to talk about how power grids have a critical need to keep the phase and frequency of their grid absolutely stable. If various power sources get out of phase this amounts to a direct and colossal short circuit. Very Bad Things happen! There is a delicate dance between generation and demand and the system load can affect phase and frequency.

The way this is normally managed is through GPS time receivers. GPS satellites have atomic clocks that keep incredibly accurate time. Monitors at various points in the grid use the GPS time base to report phase and frequency back to operators who manage the grid. Once the Russian invasion began, it was no longer possible to rely on GPS because of Russian electronic countermeasures. Restoring this capability was critical to maintaining power in Ukraine.

In this case, the happenstance relationship between Ukraine and Cisco saved the day. In a matter of days Cisco managed to modify some of their Ethernet switches such that the quartz clock in the unit could take over seamlessly whenever the GPS signal was lost. Although not as accurate as GPS, given that it would synch with GPS whenever available, it was accurate enough to carry the grid through the periodic outages. And, thanks to the dedicated team at Cisco, power in Ukraine has been preserved.

I believe those dedicated individuals at Cisco viewed their work not as a job but rather as a calling. Kudos to the Cisco team!

Slava Ukraini
Слава Україні!

03/20/2024

As president of Amenaza Technologies, I was recently interviewed by Ed Amoroso, the founder of TAG Cyber, an elite cybersecurity advisory organization.

Dr. Amoroso is a legendary figure in the field of cyber-security. Check out his biography at https://en.wikipedia.org/wiki/Edward_G._Amoroso .

As the Wikipedia article on Dr. Amoroso points out, he was a pioneer in the area of threat trees. Ed still believes in the value of attack tree analysis and, in the closing comments of his interview with me, recommended that organizations engage in this type of analysis for situations involving high potential harm or loss. Check out the interview at https://youtu.be/9SMUtCouTv4

Let me know what you think!

Terry Ingoldsby, President of Amenaza, chats with Ed Amoroso, CEO of TAG, in a discussion about attack trees.Visit the Amenaza WEBSITE: https://www.amenaza.c...

10/24/2023

I recently asked ChatGPT to tell me what it knew about attack trees. I was surprised at the high quality of its response (and how quickly it responded).

Now, here is my question. Given a description of a system, could ChatGPT create an attack tree for it? Part of me says yes. Part of me says no and that the difficulty would be in providing the AI all the information it needed to create the tree. It would almost need to ask probing questions to clarify how things were bolted together.

What do you think?

10/20/2023

Today Amenaza Technologies is releasing SecurITree v5.5. What's new in v5.5? The machine learning functionality introduced in v5.4 has been expanded. Machine learning greatly simplifies the task of evaluating a large set of attack scenarios and grouping them into similar categories (based on input from the analyst). It also introduces a "scratchpad" - something I've been asking for for a long time (sheesh - you'd think I'd have some influence! 🙂 ) This provides a work area where the analyst can drop subtrees that they want to reuse. It is super handy when one needs to reorganize a tree but doesn't want to lose valuable work already done. It is true that there were other ways of doing this in the past, but the scratchpad makes it much easier. Anyway, drop by Amenaza's website and request a SecurITree v5.5 evaluation kit if you'd like to take it for a test drive.

09/21/2023

Following up on my last post (about assessing events that have both random and hostile components) I have written a short white paper and placed it on the Amenaza website. Check it out at

09/15/2023

Apologies for the gap in my posts! I was in Disneyland with grandkids. But, back to work!

Last time I described a situation wherein a window of opportunity (a hurricane) opened for an attacker. A system that was normally well secured became insecure due to a random event that was not under the control of the attacker. Now, you might not be concerned with hurricanes, but there are lots of random events occurring in IT/OT shops. They could as simple as a door being left ajar or a configuration error occurring on a router or firewall. Equipment failures are also present. If an Intrusion Detection System fails (perhaps due to an overrun on a busy network) a hostile packet may elude detection.

I promised to explain how we would calculate the probability (and ultimately, the risk) associated with such situations. How do we model this in an attack tree?

The key is in the clever use of an AND node. The children of the AND node describe the steps which must be performed in order to traverse the AND node. These steps, along with others that may be present due to the structure of the tree, lead us to consider sets of exploits that make up an attack scenario.

Recall that hostile events (exploits) are not well described by statistics. Instead, we infer the probability of hostile events by considering whether the set of exploits in a given attack scenario is feasible for the adversary and whether the scenario satisfies attacker goals. So, we create an AND node structure that reflects the situation if the random event were always present.

For example, we might have an OR node that depicts two ways past a router. One subtree would describe how to defeat a well constructed router rule. The other subtree would be an AND node detailing the steps of traversing an incorrectly defined router rule. Presumably, this branch would be much easier (more feasible) than its sibling and capabilities-based analysis would show it to be more probable. But, this branch is only traversable if and when a configuration error was present. So, an additional special "probability" node could be added beneath the AND node representing the random event.

If the random event were expected to occur (say) 1% of the time, then the probability calculation for the scenario involving the AND path that assumed the error was always present) could be multiplied by 0.01 to give the true probability over a period of time.

Whew!

08/18/2023

There are updates on Amenaza's website! On the home page there is a new, 8 minute video tour of SecurITree. I invite everyone to drop by to check it out. Just under the top, home page graphic you will see a large button labeled, "Take a Tour of SecurITree". The video demonstrates how a tree is built and some of the types of analysis that can be performed.

There is also a link to the TAG Cyber Security Annual on threat analysis and risk assessment (that features Amenaza). It can be found under the "What People are Saying About Us" (near the bottom of the home page) or directly via There are updates on Amenaza's website! On the home page there is a new, 8 minute video tour of SecurITree. I invite everyone to drop by to check it out. Just under the top, home page graphic you will see a large button labeled, "Take a Tour of SecurITree". The video demonstrates how a tree is built and some of the types of analysis that can be performed.

There is also a link to the TAG Cyber Security Annual on threat analysis and risk assessment (that features Amenaza). It can be found under the "What People are Saying About Us" (near the bottom of the home page) or directly via

08/10/2023

Last time I outlined the classic ways of depicting controls in an attack tree. Today I want to start moving toward new ways of representing controls in an attack tree. This topic requires a fair bit of background information, so be patient if I don't get there immediately.

To introduce this I first need to talk about something that may appear to be unrelated - but believe me, it ties in. And that is, how random events affect our attack frequency predictions.

Let's take a very simple case as an example. I'll use a physical situation for simplicity. Suppose we have a manufacturing plant located somewhere along the U.S. Gulf Coast. The plant manufactures a product that, when completed, is stored outdoors in an adjacent storage yard. To protect the goods from theft, the yard is surrounded by a tall fence equipped with motion sensor detectors and alarms. There are also guards that periodically walk the fence perimeter looking for intruders. You might even suppose that there are guard dogs in the compound on the prowl for a tasty burglar.

In principle, at attack on the facility is fairly simple. A burglar simply cuts a whole in the fence and enters the yard. However, due to the personal risk and likelihood of being apprehended, the attack is beyond the capability of burglars. So, attack tree analysis (comparing attacker capabilities with attack requirements) would not reveal any risk from an average burglar.
Now suppose that there is a hurricane raging (not an unusual event on the Gulf Coast). In fact, on average hurricanes occur about 1% of the time (3 days per year) in that region. During the hurricane the guards are huddle in their guard shack (hoping it doesn't blow away). The dogs are in their kennels and the motion sensors on the fence are triggered constantly. During this interval a bold burglar might cut a hole in the fence, enter and remove some of the manufactured goods.

So, how do we calculate this? More on that in the next post!

08/08/2023

Summer has ruined some of my good intentions - I'm behind on my posts about attack trees. So, back at it!

In my last post, I mentioned that attack trees see things from the point of view of the adversary, and that classic attack trees do not explicitly model controls and countermeasures. However, controls can and do appear in attack trees. There are three ways in which a control may appear in a classic attack tree. Amenaza has added ways to explicitly model controls in its SecurITree software - but let's first look at the classic techniques.

Since all interaction between adversary and target occurs at the leaf node level the obvious place to model controls is at the leaf nodes. The problem being that there are a lot of leaf nodes in a typical tree! But still, it is a way of modeling improvements that increase the difficulty of a leaf exploit. For instance, if someone is kicking down a cheap, hollow core door (with a $20 lockset) then one obvious control would be to improve the quality of the door (solid core, steel coated, expensive lockset and reinforced door jam). This doesn't change the basic nature of the defense, but does require much more effort from the adversary. Similarly, if a leaf node describes a brute force attack against an encryption system with a short (or low entropy) key, then moving to a better crypto system (e.g., move from DES to AES) doesn't change the essence of the attack but requires vastly greater resources from the attacker.

The most popular strategy for depicting a control in a classic attack tree is to harden branches under an existing AND node (or create an AND node where none originally existed). This is very effective if we cannot improve the security of certain parts of our system (perhaps they are already defined and there is no opportunity to alter them). Instead, add one or more additional activities that are carefully chosen to be difficult for the adversaries. Suppose we have an application that we believe is weak or poorly secured. We may have purchased the application and have no ability to improve it directly. But, we could put the application server on a separate network segment and require users to perform strong, multi-factor authentication to access the segment. This would be effective against outsiders. It wouldn't stop a hostile insider, but it would expose them to significant personal risk since their activity would be logged.

There is one more technique that can be used in a classic attack tree. That is to screen out the attacker's ability to perform certain leaf nodes by setting up Boolean filters. For instance, certain attacks may only be possible if the attacker is physically present (e.g., plugging in a cable). So, if we mark leaf nodes requiring physical presence we can quickly eliminate those nodes for attackers who are not present.

Next time I'll talk about extensions to classic attack trees that make countermeasures more obvious.

07/27/2023

Whoohoo! I was recently interviewed by TAG Cyber (the renowned advisory group) about risk analysis and threat modeling. Please check out the interview at https://www.tag-cyber.com/advisory/quarterly/download/10 My interview is on page 34. The article states that I am the "owner" of Amenaza - not quite true - I am one of a variety of shareholders in the company. Other than that, the article represents my views on the subject of attack tree-based threat modeling.

06/28/2023

As a brief digression from my ongoing discourse on attack trees, I wanted to reference a fascinating article posted by Mark Mateski about some historic wargames. https://reciprocalstrategies.com/blog/baubles-and-gems In Mark's post he notes how several major 20th century battles were lost because the defender failed to take notice of war game exercises. These war games had accurately predicted how certain attacks would occur -- but the defenders had ignored or been unaware of the findings. And thus, they lost.

This is very analogous to attack tree analysis. Attack tree models consider a broad range of ways in which a system can be attacked. Analysis reveals which attacks a given adversary is likely to pursue. Of course, if the defender fails to do attack tree modeling, or ignores the results, they too may experience a significant setback!

Now and then, an exercise reveals a potentially worrisome event or course of action, one that the game’s sponsors would do well to consider.

06/23/2023

Through the last posts I have basically outlined how attack tree models are constructed and how the behavioral (capability) and impact (benefit to attacker; detriment to victim(s)) allow us to understand and *predict* which attacks are likely. I can't overestimate the importance of this last statement - attack tree analysis is a tool for predicting the behavior of the adversaries.

But now what? Given that we know which attacks are most likely to occur (and which are most painful to the defender) what do we do about it? How can attack trees help us build effective defenses and prevent the attacks from happening?

Attack trees see things primarily from the point of view of the attacker (that is their value). To be pedantic, controls and countermeasures do not exist from the attacker's point of view except as additional obstacles to be overcome. Getting up in the morning is an obstacle for some attackers! Overcoming each obstacle is just a task for the attacker - and something that can be represented in the attack tree as a step or series of steps that need to be performed.

Steps are represented as leaf nodes in an attack tree. And leaf nodes are one of three ways of representing countermeasures in a classic attack tree. So, let's tackle them first.

Suppose you have a leaf node in an attack tree that represents breaking down a door (or, if you prefer, doing a brute force attack on a crypto key). If the door is of poor quality - hollow core, cheap lockset (or the crypto key is short) - it won't take a lot of resources from the attacker to compromise it.

The leaf node representing these activities would presumably require the attacker to expend little money and low technical ability to perform the exploit. But, if the door were enhanced (solid core, coated with metal, top notch lockset and door jam) or the crypto key were longer then the amount of resources needed to compromise would increase dramatically. The nature of the exploit doesn't change, but the difficulty would.

So, a simple approach to improving security is simply to visit all the leaf nodes in the tree and harden them. There are a couple of problems with this strategy. First of all, trees often have lots of leaf nodes - so this means a lot of work to do! Also, strengthening a leaf node isn't graphically obvious. The defender can't see that a control has been implemented. Of course, a simple solution is to change the color of the leaf node or otherwise make it obvious.

Sometimes we do focus on leaf nodes. If many attack scenarios share a particular leaf node then it is prudent to harden it. But other, more effective strategies may exist. We'll talk about some of those next time.

06/15/2023

In my previous post I mentioned how classic attack trees could, under some circumstances, require a separate tree for each adversary (if they had very dissimilar goals). I alluded to the fact that adding impacts to the model usually remedied this.

Recall that all of the interaction between the adversary and their target occurs at the leaf level of the tree. This is where the exploits are performed. And clearly, there are some impacts (benefits to the attacker, damages to the victim) at that level. However, they are usually minor. The impacts grow and scale as the mid-level and high-levels of the tree are achieved (as the leaf nodes trigger the Boolean logic). These impacts may vary by path.

So, one path toward root may cause immense physical damage and human injury - but provide little financial reward to the adversary. Another path may cause no physical damage, but provide significant financial rewards to the attacker. Clearly, the path that causes physical harm and injury would be attractive to a terrorist but offer no reward to a commercial criminal intent on stealing intellectual property. And vice-versa.

Of course, when we are evaluating risk we see things from the victim's point of view. Similarly different paths through the tree would present different levels of concern to a specific victim.

Indeed, there may be multiple victims (each with their own point of view). So, the employees of the organization might be very concerned about attacks that cause physical harm to themselves. A greedy CEO might worry more about the financial loss of their IP. These different perspectives can cause different estimations of risk, depending on the values held by the victims.

06/12/2023

Time to get back to the discussion about attack trees (and what the root node should represent).

In a previous post I used the example of commandeering an aircraft as an example root node in an attack tree. And explained how two different types of adversaries had very different overall goals. Although the mechanics of taking control of an aircraft were similar for both types of adversary, the impact on the victim(s) were vastly different. In fact, I kind of hinted that the root node was not "Seize control of aircraft", but rather either "Make a political statement about the virtues of Marxism" or "Create terror to influence geopolitical events", depending on the nature of the attacker.

One solution would be to have different attack trees for each type of adversary that the system might face. But, that seems to be a lot of work! And, up to a certain point, the two trees are apparently very similar (if not identical).

Paths through the two trees differ by impact, both in benefits to the adversary and impacts on victims. So, it stands to reason that if our attack trees captured the impacts that we could probably make a single tree deal with multiple adversaries.

This would be a significant enhancement to the classic attack tree model. Classic attack trees look at the resources required by the adversary to perform leaf level exploits and then tally up the costs. Since all of the adversary's interaction with the target occurs at the leaf level, a classic tree only requires analyst input at the leaf nodes. Impacts tend to occur throughout the tree, and often require business knowledge to assess. I.e., they cannot entirely be calculated using some simple formula.

06/07/2023

No - I haven't stopped my discussion of attack tree analysis - just been really busy! But - what I wanted to mention today is that there is a write-up about Amenaza's SecurITree software in the June issue of the CIO Review Canada magazine. I think you need to give them your e-mail address in order to see the magazine - I am working on getting a copy of the article for Amenaza's website. In the meantime, go to

05/24/2023

Today Amenaza Technologies unveiled a new look to its website. Websites are never finished, but I think the new site is a definite step ahead. Take a look and let us know what you think!

Amenaza Technologies has created SecurITree, the best attack tree (threat tree) risk assessment tool and methodology designed to identify security risks

05/18/2023

There is more to the question of what the root node of an attack tree means than is immediately obvious.

My previous example discussed how Bad Things (in the case of 9/11, Really Bad Things) can happen if the root of the attack tree doesn't match the adversary's goals. I kind of implied that there might need to be multiple attack trees (with different root nodes) to represent the interaction with each type of adversary. Is this true? If so, it means that the job of creating attack trees just got a whole lot harder!

Fortunately, in most cases, a single attack tree will do - IF we augment the classic attack tree to incorporate impacts.

Recall that we already discussed behavioral or capability indicators. These indicators reflected the resources the adversary would need to expend to perform leaf level exploit activities. And, aggregation functions could be used to tally up the total resources needed for a given attack scenario (that probably contained several leaf level exploits). Since all of the interaction between an adversary and their target occurs at the leaf level, this simple scheme worked perfectly.

Although the direct interaction between adversary and target occurs at the leaf level, the intermediate and higher nodes of the tree are also very interesting. These nodes are where impacts occur. There may be benefits and detriments to the attacker. There are almost certainly detriments or harms to the victim(s).

It is true that part of impacts can be calculated mechanically (e.g., several losses may simply sum to give a total). However, generally speaking, calculating the impacts requires an understanding of the system's processes.

As an example, consider an AND node with two children. One child is "Light match". The other is "Place match under dynamite fuse". The consequences of each of these activities (in isolation) is marginal. The combination of the two has explosive consequences! So, we would need to inject impact values at the AND node. Depending on the circumstances, the consequences to the victim might involve financial loss, physical harm or even loss of human life. Similarly, the attacker might garner some particular benefits (and/or harms).

The trick to making a single attack tree work for various adversaries involves determining which benefits each type of attacker seeks, and creating appropriate impact indicators to reflect their disparate goals. In that way, it is possible to show how certain paths through the tree will be selected by the different attackers.

Using my previous 9/11 airplane hijacking example, we might find that certain branches through the tree would appeal to a Cuba bound hijacker (i.e., publicity, safety of attacker) whereas other paths would reflect the goals of the terrorist (cause fear in populace, destroy infrastructure, no regard for well-being of attackers).