Some tests and some ideas/suggestions.

[jesajx]

As discussed previously, here are some test cases (roughly 46). You should be able drop it in to use as regression tests right away. Some of the tests may also be useful to use as documentation (notably test_T048_* on various kinds of privilege escalation).

The tests are based on a list of IoT weaknesses from an upcoming IoT pentesting methodology ("PATRIOT") paper by Emre Süren et al. Some of the weaknesses can also be seen here. For each weakness I've tried to model at least one example scenario of that weakness in CoreLang (at least for the weaknesses that made sense to model). I have added Emre's explanations for each weakness as comments, and have also added some clarifications and examples of my own.

The tests gives some ideas on what CoreLang might lack (in the context of pentesting IoT). I've made some TODO-comments on the things I think might be worth implementing in CoreLang (rather than in IoTLang - which I'm working on). To summarize:

It would be nice to model TLS in more detail to cover more attacks on it. For example, there are attacks based on overwriting or adding CA-certificates on the victim to enable TLS MITM attacks (see e.g. "Trust Stores" in mitre). CoreLang does not really model credentials being overwritten. I chose to not go into too much detail on TLS in IoTLang, but given how fundamental TLS is it might make sense to go into more detail in coreLang (or perhaps in a TLSLang?).

Replay attacks can be used to circumvent authentication and encryption. This can easily be implemented by introducing a replay attack step to Data that would behave similarly to Data.write. Secure protocols like TLS (and notably DTLS) would have a replayProtection-defense enabled, while insecure protocols would not.

It might be good to model cryptographic signatures, verification and authentication in more detail. IoT firmware updates sometimes are sent without transport encryption but are instead verified using hashing and signatures (e.g. using a PGP-signature and a preshared public key). While this would prevent the attacker from installing firmware, the firmware may still contain sensitive information that they can read (like hardcoded passwords). You could use Data.authenticated to express this, but we are also interested in attacks on the firmware verification mechanism. For example, if the attacker obtains the private key they should be able to replace the firmware in transit (i.e. breaking the defense). I think it would make sense to adjust Data.authenticated to mirror how Data.encryptCreds works (i.e. authenticated should depend on a certificate that the attacker could potentially attack).

CoreLang (and MAL in general) does not really model changing states that well. It would be good to have mechanisms to model for example rollback attacks. For example, an attacker may not be able to install arbitrary firmware, but they could perhaps downgrade to older firmware. The older firmware may have vulnerabilities that are absent in newer versions. Currently this can be worked around by creating multiple models -- one model of the scenario leading up to the rollback attack and another model showing the situation after a successful rollback attack.

I experimented with the following association:

• Data [copySrc] * <-- Copy --> * [copyDst] Data and it was quite useful. For example, it can be used to model a situation where multiple IoT device each run a copy of the same firmware. If the attacker overwrites the firmware on one of the devices it should not overwrite the firmware on the other devices. If the attacker reads the firmware on any device they are in effect reading the upstream version (in the cloud). Similarly, the copy association can model more complex data flows when interacting with APIs (e.g. to show how the data flows around the systems behind the API -- which can be used to illustrate injection attacks).

[andrewbwm]

I've only had a brief look at the first commit.

My first request would be to split up the file into multiple files that each encompass their broad categories.

I am not a big fan of the commented out tests that just say See "T0XX". I would rather just have as part of the description in T0XX an explanation that the scenario modelled also covers T0YY, T0ZZ, etc.

I understand that the helper functions were useful to write so many tests quickly, but because this batch of tests looks different than what our regular unit tests this makes them less legible at first glance.

I will address the specific missing coreLang functionality after I get a chance to dig deeper into those issues.

[jesajx]

Ok, I will clean it up when I have time.

[andrewbwm]

It would be nice to model TLS in more detail to cover more attacks on it. For example, there are attacks based on overwriting or adding CA-certificates on the victim to enable TLS MITM attacks (see e.g. "Trust Stores" in mitre). CoreLang does not really model credentials being overwritten. I chose to not go into too much detail on TLS in IoTLang, but given how fundamental TLS is it might make sense to go into more detail in coreLang (or perhaps in a TLSLang?).

What do you mean by '"Trust Stores" in mitre', are you referring to https://attack.mitre.org/techniques/T1553/004/ ?

[andrewbwm]

Replay attacks can be used to circumvent authentication and encryption. This can easily be implemented by introducing a replay attack step to Data that would behave similarly to Data.write. Secure protocols like TLS (and notably DTLS) would have a replayProtection-defense enabled, while insecure protocols would not.

This feels to me like it is already covered by the man-in-the-middle attack steps and defences in coreLang.

[jesajx]

What do you mean by '"Trust Stores" in mitre', are you referring to https://attack.mitre.org/techniques/T1553/004/ ?

Exactly. CoreLang does not distinguish between the credentials used to authenticate and the credentials used by the authentication mechanism to verify that authentication attempt.

For example, a client may use a password (Credentials) to authenticate to a server. The server verifies the password against a stored password hash (Credentials/Identity). CoreLang treats the password and the password hash as the same thing (or only models the hash, depending on how you see it).

• [X] If the attacker knows the password, then they can authenticate.
• [ ] If the attacker can overwrite the file containing the password hash on the server side, then they do not need to know the original password to authenticate.

This can matter in models where the credentials are reused since overwriting the password hash is not the same as learning the password -- although there are of course (slow) offline attacks for that too.

Certificates in TLS work in a similar way, where the server certificate is verified against a root-certificate on the client. So if the attacker can replace the root-certificate file on the client, then they do not need the server private key.

A possibly related issue: #17.

Perhaps there is some way to model this using e.g. parent and child identities or by using credentials to encrypting other credentials? If so it might still be good to write some documenting examples since it is not obvious.

Replay attacks...

This feels to me like it is already covered by the man-in-the-middle attack steps and defences in coreLang.

Not really, because the man-in-the-middle attack steps do not work on encrypted and/or authenticated data. The idea is that even if the attacker can't read or write the data, they may still be able to replay it in some cases. For example, if the attacker can eavesdrop on authenticated firmware updates, then they can "replay" an old firmware update to install old firmware -- i.e. perform a version rollback attack. The old firmware may contain additional vulnerabilities.

[andrewbwm]

As a summary of the excellent conversation with @jesajx yesterday.

1. Overwriting certificates can either be represented by writing a Data asset that contains the Credentials associated with an Identity that represents the Certification Authority or by simply adding a Vulnerability that represents the poor certificate enforcement or verification.
2. Replay attacks are covered on the Data asset by the manInTheMiddle attack step which does lead to a write. Impacts of replay attacks that focus on the behaviour of an Application are modelled via the Vulnerability asset since the Data asset is generic and does not permit us to express the concept of commands. This is in line with the CVSS Specification which explicitly defines man-in-the-middle/replay attacks as one of the circumstances that warrant a 'High' Attack Complexity score.
3. As of right now there is no way to "break" authentication. The need to model this has not arisen so far, but if it does @jesajx's suggestion is apropos. Due to how the Authenticated defence is implemented on Data it is not possible to create a workaround that represent breaking the authentication dynamically.
4. Rollbacks can be modelled either via two explicit Vulnerabilities where one, the rollback, fulfills some of the requirements of the other, the more serious vulnerability that exists in the older version, or through only one merged Vulnerability that represents both the rollback and the more disruptive impact present in the older version. This merged Vulnerability, as per the vulnerability chaining advice in the CVSS documentation, should have the prerequisites of the rollback and the more dire impacts exposed in the older version of the firmware.
5. In the future we may want to introduce a backup/replica relationship between Data and Information to represent that one logical concept is present in multiple instances. This would work similarly to @jesajx's suggestion, but would use the Information asset as the aggregator.

If I have missed or misinterpreted some points feel free to comment so that we amend that. If you have any other suggestions now or in the future please add them to this pull request.

[jesajx]

As a summary of the excellent conversation with @jesajx yesterday.

In short: the issues I pointed out would require a finer level of granularity than what is intended for Corelang. So these ideas will go into IoTLang instead.

[jesajx]

(Some cleaning work still remains on my side.)

[jesajx]

I hope that does it for the clean up.

[andrewbwm]

I hope that does it for the clean up.

Thank you very much! I will go through them as soon as I get the chance.

I also remembered another suggestion you made that should be documented somewhere, we should create an association between the PhysicalZone and Network assets.

[jesajx]

Speaking of PhysicalZone -- it would also be nice if System could be part of multiple PhysicalZones at the same time. Intuitively this would mean that PhysicalZones can overlap. I currently have to use ugly workaround to get around this in IoTLang since it is not possible to override associations in MAL.

That is:

- PhysicalZone     [physicalZone]      0..1 <-- ZoneInclusion         --> *   [systems]                System
+ PhysicalZone     [physicalZone]      *    <-- ZoneInclusion         --> *   [systems]                System
                                       ^