Skip to content

MAL Syntax

mathiasekstedt edited this page Mar 16, 2026 · 23 revisions

Versioning

This page documents the latest changes related to the syntax of MAL.

Language Constituents

The following are commonly used keywords in writing MAL specification:

  • define Defines information for entire MAL projects. The syntax is '#key: "value"', for example '#version: "1.0.0". The keys #id and #version must be present in every project.

  • include "path/to/specification.mal" Imports another MAL specification. Enables references to assets and elements defined in separate specifications. Paths are relative to the specification with the include statement.

  • category Similar to a package in for instance Java. A category consists of one or more assets. The category does not bear semantics, it is only there to enable structure for the language developer.

  • asset Similar to a class in object oriented programming languages. An asset could represent physical objects (e.g., a network router) or logical objects (e.g., Credentials, or a Network Service).

  • extends Similar to inheritance in object oriented programming languages. A child asset inherits attack steps and defense mechanisms from its parent. Child steps and mechanisms override their parent counterparts by default if the same names are used. Let expressions and associations are also inherited by extended assets (e.g. we don't need to create the association for an extended asset Linux to another asset Application, if its parent asset Machine is already associated with Application.).

  • abstract asset Similar to object oriented programming languages; the asset cannot be instantiated, only extended. Everything defined on an abstract asset is inherited by its children.

  • user info This keyword is used in MAL to provide information for end users about the asset and/or the associated attack step and defense mechanism.

  • developer info This keyword is used by developers of MAL specifications, typically to document reasoning and rationale behind the specification design.

  • modeler info This keyword is used to provide information to modellers or parser developers. It can be used to communicate assumptions or parsing requirements, which might otherwise be ambiguous.

  • let This keyword is used to associate a given expression with a specific reusable name. The syntax is 'let <nameHere> = <MAL expression>'. Let expressions can be defined within the scope of entire assets, specific attack steps, and defense mechanisms. Let expressions can be referred to across separate assets like attack steps, assuming appropriate associations exist.

  • association Association is analogous to UML class diagram associations. It denotes a potential bidirectional structural relationship (physical or logical) between two assets. The syntax is Asset1 [role1] <multiplicity1> <-- AssociationName --> <multiplicity2> [role2] Asset2'. The <multiplicity> of a composite association can be <1>, <1..*> or <*> on the composite end. Role names determine the directional references to other assets used in code. For example, Asset1 references Asset2 as role2.A, where A is an attack step. Conversely, Asset2 references Asset1 as role1.A.

  • attack step On Assets, attack steps can be defined. In simulations attack steps have state of non-compromised or compromised by some attacker agent. Attack steps can form a graph as it can be specified how attack steps lead to other attack steps. Attack steps come in two types; OR or AND. For OR steps only one parent needs to be compromised to enable compromising of a child step. For AND steps all parents need to be compromised. Attack steps can be associated with a Time-To-Compromise (TTC) distribution, representing the difficulty of changing the state from non-compromised to compromised.

  • defense step On Assets, also defense steps can be defined. Defense steps have state True or False, representing if the defense is activated or not. Defense steps are connected to attack steps and when True they make the connected attack step not possible to compromise. For simulations the state of defense steps can be specified as a (Bernoulli) distribution.

MAL Symbols

Symbol Meaning Description
-> Leads to The successful compromise of this attack step allows the attacker to consequently compromise further attack steps. Also specifies steps affected by defenses and existence checks.
+> Append Child assets only. When parent and child assets have overlapping elements, e.g. | access, the expressions defined for the child access are appended to those of the parent access. The child expressions will otherwise override those of the parent.
| OR An OR attack step A can be compromised if any of the attack steps which refers to A is compromised.
& AND An AND attack step A can be compromised only if all of the attack steps which refer to A are compromised.
TTC Time-To-Compromise TTC is a probability distribution reflects an attacker's ability of compromising an attack step. Simulations calculate/aggregate TTC for models/scenarios.
# Defense A defense step represents the countermeasure of an attack step (e.g., the passwordBruteForce attack step can be defended by a twoFactorAuthentications defense step). In simulations defense steps are governed by defender agents.
E Existence Existence conceptually operates as a defense step. It is used when the existence of connected/associated assets, given by <-, must be checked. The associated attack steps are possible to compromise when at least one designated asset exists.
!E Non-existence Same as Existence, except the specified attack steps are possible to compromise when at least one designated asset does NOT exist.
<- Require Denotes which associated assets are required by the current expression. Used to specify preconditions for Existence and Non-existence.
[ ] TypeOf Reaching an attack step that traverses a set of assets can now be further specified by child asset if a parent asset has been extended. For example, if Dataflow has children assets Inbound and Outbound, we specify as dataflows[Outbound]
\/ Union Union operations of same-typed sets. (Backslash + forward slash)
/\ Intersection Intersection operations on same-typed sets. (Forward slash + backslash)
- Difference Difference operations on same-typed sets.
X.A Collect operator Attack step A of the asset X is referenced. Other asset X is referenced to reach the attack step A.
X*.A Transitive operator Recursively follow X until the end is reached, then, perform A. For example, folder.subFolder.subFolder.subFolder.access = folder.subFolder*.access. Hanging transition are allowed for let expression, e.g., let allFolders = folders.subFolder*.
X().A Let substitution The parentheses after X denote that it refers to the let expression labeled 'X'. A is performed on the assets given by X.

Probability Distributions

For detailed information regarding distributions, see Supported distribution functions (MAL compiler).

Attack steps may have probability distributions set to express their uncertainties. Current tooling supports parsing of the following distributions:

  • Bernoulli(p)
  • Binomial(n, p)
  • Exponential(λ)
  • Gamma(k, θ)
  • LogNormal(μ, σ)
  • Pareto(x, α)
  • TruncatedNormal(μ, σ^2)
  • Uniform(a, b)

MAL Coding Standard

MAL specification follows a coding standard similar to Java. Please consider the following coding standard when creating your MAL language.

  • Asset names are PascalCased.
  • Attack steps, defense mechanims, and role names are camelCased.
  • The attack step definition syntax is '<\type> nameHere @tag [ProbabilityDistribution(params)]'. Tags and probability distributions are optional.
  • Multiple expressions can be written under both -> and <- operators. They should be delimited by a comma and line break. Furthermore, the first expression should be on the same line as the operator itself.
  • The defense mechanism definition syntax is '# nameHere @tag [Bernoulli(p)]'. The tags and Bernoulli distribution are optional.
  • Comments in MAL files can be introduced by "//"
  • It is recommended that asset names are not repeated in the attack step
  • Associations are defined at the end of each MAL specification.
  • Inline documentation using the three info elements is preferred over other formats.

Clone this wiki locally