Logic is going to get messy fast, rules engine?

[nozmore]

I've been thinking about this and relates to a few issues I've added recently.

I think the logic is going to get messy as we add more Threats, Mitigations, and add logic to alter severity while applying mitigations.

Does it make sense to continue creating a tightly coupled rules engine here vs using something existing?

Idk what exists for Python. For Java I've worked with Drools that would be perfect for this. So much so I had the fleeting thought to port this to Java to use it.

[izar]

Let's see if we can find something in python first. I am not familiar with Drools, what are its main characteristics that you find appropriate? It seems to be a business engine? If at all moving from Python, let's go PROLOG.

[colesmj]

I agree a Rules Engine will be necessary and important, if nothing else to manage the complexity as the threat list expands. We might consider a package like this: https://pypi.org/project/Intellect/

[izar]

I agree, it will be necessary as we move forward and complexity increases. I was looking at a Python-Prolog bridge, but this Intellect seems interesting in the fact that it appears to take input via classes and properties, just as we are structuring the input for pytm.

On Thu, Aug 9, 2018 at 6:28 PM colesmj notifications@github.com wrote:

I agree a Rules Engine will be necessary and important, if nothing else to manage the complexity as the threat list expands. We might consider a package like this: https://pypi.org/project/Intellect/

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/izar/pytm/issues/19#issuecomment-411947580, or mute the thread https://github.com/notifications/unsubscribe-auth/AAWggW3FcUgSpcxAZ-wwAnScRoCTY-qzks5uPOG7gaJpZM4VYaSe .

[lfservin]

I'm looking into https://pypi.org/project/durable-rules/ and https://pypi.org/project/rule-engine/ . I just tried looking into Intellect, but I didn't really get the grip of it. Have you had any discussions on this topic since 2018? is there a preferred way to go? I'd try to re-create the same threats and come up with the same results. Does anyone have any other examples that could be run to try this approach?

[izar]

We are currently testing a number of approaches - a "best" one has not been decided yet. So far we will progress with the simple boolean rules until we get to an approach that is worth moving to.

[Thorsten-Sick]

I had good experience with plugin based models (Cuckoo sandbox signatures and most of the flexible components in PurpleDome https://github.com/avast/PurpleDome ). Based in a Rule class most of the rules would be just a few lines with the option to put heaps of real code in there for identification of security flaws.

[izar]

interesting, i had never seen PurpleDome, thanks! Would you have an example of a Rule class translation of any of the rules we currently have?

[Thorsten-Sick]

Purpledome was fun. But rule wise Cuckoo is more interesting. They use two system for rules. The newer one is "evented" because the logs they are processing are huge. Still they are quite simple to read. Examples are in https://github.com/cuckoosandbox/community/tree/master/modules/signatures/windows

One with medium complexity is this one: https://github.com/cuckoosandbox/community/blob/master/modules/signatures/windows/disables_security.py

The boilerplate

_name = "disables_security"
description = "Disables Windows Security features"
severity = 3
categories = ["anti-av"]
authors = ["Cuckoo Technologies", "Brad Spengler"]
minimum = "2.0"
ttp = ["T1089", "T1112"]_

Is similar to your rule entries. And the things in your "condition" line can be a logic like:

_regkeys_re = [
    ("HKEY_LOCAL_MACHINE\\\\SOFTWARE\\\\(Wow6432Node\\\\)?Microsoft\\\\Windows\\\\CurrentVersion\\\\Policies\\\\System\\\\EnableLUA", "attempts to disable user access control"),
    (".*\\\\SYSTEM\\\\(CurrentControlSet|ControlSet001)\\\\services\\\\WinDefend\\\\.*", "attempts to disable windows defender"),        
]

def on_complete(self):
    for indicator in self.regkeys_re:
        for regkey in self.check_key(pattern=indicator[0], regex=True, actions=["regkey_written"], all=True):
            self.mark(
                description=indicator[1],
                registry=regkey,                     
            )
            self.severity += 1

    self.severity = min(self.severity, 5)
    return self.has_marks()_

I will try to find some time and prototype a rule base class and 2-3 example rules

[Thorsten-Sick]

I created an example for rule plugins: https://github.com/primion/pytm/tree/rule_plugins_simple

It is not perfect yet. I would like to add more helper functions, examples and documentation (including types for the rules author's IDEs) before releasing it. But the code is working and can be discussed. What do you think ?

This is how a rule looks like:

https://github.com/primion/pytm/blob/rule_plugins_simple/pytm/plugins/rules/example.py

Some design principles:

• I try to abstract PYTM internals. Keep them away from rule authors
• I want to throw exceptions as soon as a rule plugin is faulty (not there yet)
• As much in code documentation as possible to make writing rules simple. Especially in the base classes

[izar]

Thanks, it looks really good. And it does away with the eval() silliness, which is a big + for me :) So, what's the next step? I wish I could commit to embracing this fully, but I am overwhelmed right now for the next couple of months.

[Thorsten-Sick]

I will refine the code and create a PR. Either to your main branch or to a dev branch (depends on you, on a dev branch you can do a shorter review as people will not necessarily expect it to work....). I can maintain a parallel dev branch in my fork, so we here at my company can use it. And after your time away we put some effort in to get everything upstream. (Background info: In my company I want to get our Threat Modeling more automated).

I have some more ideas and will just open up new issues to discuss them. Your feedback there would be very important. But I will find workarounds for PRs that get stuck for a few months ( like my dev branch in my fork). My goal is to get everything upstream sooner or later while at the same time benefit from new features as early as possible.

[colesmj]

@Thorsten-Sick I am also curious about the system you are looking to use, as it seems very flexible and can have some interesting uses. Some questions perhaps you can enlighten me / us on your thoughts?

• How might a more complex rule be constructed, such as one that looks at 2 elements (say a source and sink, or client and server)? My concern recently has been that our current threatlib rules are only evaluated on a per-element basis, and we have constructed some element subclasses to hold more information than they should (in a non-logical way for a developer doing a threat model).
• Would we want to associate rules and/or perform rule processing at the Element (or subclass) scope, or globally at the tm level, or maybe both?
• I'm looking at some changes for a future "incubation" branch for pytm which might change up the objects and attributes (such as controls); it seems rules are always going to be dependent on the underlying element class/sub-class definitions. What are your thoughts on versioning, or some semantic rule definition approach?

[izar]

hi, sorry for taking so long to get to this! new year (happy new year!), new job, closing some older projects.

i took a look at the code - and I am not quite sure where to go from here. Do we have to translate the existing rules into this plugin system? What are some other possible plugins that this enables ?

[Thorsten-Sick]

Hi

You can keep the old rules. But sooner or later it would be simpler to translate them to plugins an remove the redundant code. Maybe I could do that. But as I will start a new job soon I can not promise anything. The other plugin type I am thinking about is moving all the design elements (servers, communication protocols) to a plugin system as well. In my current company we do build embedded systems (embedded Linux, secure controllers to store key material) and cloud services. All the extremes. This architecture could benefit from more components written as plugins.

Is it ok to merge into the main branch ? Do you want to start a "next generation" branch for those giant leaps ?

[izar]

Yeah I'm thinking next gen. This sounds like a change that might break things way too easily going forward.

On Thu, Jan 4, 2024 at 1:14 AM Thorsten Sick @.***> wrote:

Hi

You can keep the old rules. But sooner or later it would be simpler to translate them to plugins an remove the redundant code. Maybe I could do that. But as I will start a new job soon I can not promise anything. The other plugin type I am thinking about is moving all the design elements (servers, communication protocols) to a plugin system as well. In my current company we do build embedded systems (embedded Linux, secure controllers to store key material) and cloud services. All the extremes. This architecture could benefit from more components written as plugins.

Is it ok to merge into the main branch ? Do you want to start a "next generation" branch for those giant leaps ?

— Reply to this email directly, view it on GitHub https://github.com/izar/pytm/issues/19#issuecomment-1876438532, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAC2BAMT7RT6VULWIZVGC3DYMZCEBAVCNFSM4FLBUSPKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBXGY2DGOBVGMZA . You are receiving this because you commented.Message ID: @.***>

[noloader]

Let's see if we can find something in python first...

If possible, please select something that's available out-of-the box, without the need to install additional software. Since this is a Python project, please try to limit to standard Python3. I don't want to run Pip, and I don't want to install stuff from third parties.

Xz has demonstrated how dangerous it is to depend on externalities. Xz contaminated SELinx and Systemd (among others).