The System object is representing the hardware an Application is running on.
An Application (including IDPS and RoutingFirewall type of objects) should be connected to a System object only if it is running directly on the hardware which is the case with operating systems.
Strictly speaking, an operating system can of course be divided into smaller parts as well; the kernel which is running on the hardware and other applications that belong to the operating system but communicate with the hardware via the kernel. If this is desired, connect an Application object representing the kernel to the System object and all other non-kernel applications of the operating system as child applications to the kernel application. This is however only necessary when analyzing the security aspects of different parts of an operating system.
By connecting a Data object (for instance representing local storage) to a System objects defines which hardware is hosting the data physically.
If a piece of hardware is protected by an authentication mechanism, this is represented by connecting a Group or Identity object to the System object.
This authentication shall not be mixed up with the authentication needed to log in to or unlock a running operating system locally. That authentication mechanism doesn't give direct access to the hardware, but instead to the operating system running on it.
A System object can be connected to a PhysicalZone object representing the System's actual location. This is sometimes an interesting attack vector to analyze; if an Attacker would gain access to a System in a remote location, what options to proceed further in the network does the Attacker get?
The System object has been redesigned in the next version of coreLang, version 0.5.0.
The current version is therefore deprecated.
Updated 4 months ago