Security Model

A SecurityModel, in the general sense, is any well-defined approach to security that describes both agents in their roles (with their respective rights and responsibilities (or motives)) and the potential and legal interactions between them (possibly including which interactions are 'critical', which can be safely compromised for a period, and, for attackers, which must be forbidden (i.e. must have a prohibitively high cost to perform)). Roles can include attackers, traitors (inside job & subverted machines), and defenders, among others (zombies, ISPs, shared services (DNS), middlemen, et. al.). A SecurityModel doesn't need to actually provide security to be a SecurityModel - one can describe weak, flawed, or even backwards security model. 'SecurityModel' also doesn't need to be limited strictly to agents, roles, and interactions between computers, though one acknowledge that humans cannot ever be as persistent or consistent in their intentions to secure a resource than can be an automaton, and are far more readily subverted (threat, bribery, and even the seemingly innocent - a guy dressed as a tech needs into a particular server room with all the Ethernet cables, or needs a password to a machine).

When one goes about implementing a Computer SecurityModel, it is useful to note that there are limited mathematical tools currently available to go about performing the implementation. In general, we have: hide the content, hide the communication, sign the content, and encrypt the communication (any of which can be combined). Secrets - hidden content - can also be broken into multiple pieces so that it takes several systems being subverted or going traitor in order for it to be revealed to the wrong parties (or one of the parties who has access rights being subverted). Communications can be hidden via steganography (e.g. hiding data in an image) but also by anonymity (e.g. delivering steganographic content in a mass spam e-mail). Public/Private key signatures are the true building-blocks of trust, authority, and rights management: capabilities can be signed and delivered along with the entire chain of certificates saying one had the right to sign that capability, back to some 'known' entity the agent to whom you're presenting the capability believes to possess proper capability for access (see CapabilitySecurityModel). Finally, encryption keeps secrets between trusted parties (though always with the adage: Two can keep a secret if one of them is dead).

We also have social engineering: ensuring that interests are properly aligned with responsibilities via reward or punishment - ideally in a manner intrinsic to the data in the system; reducing the reward from successful attack; increasing ability to identify the attacker so perceived threat of punishment is higher, etc.. It isn't really a security tool, per-se (there is little need to secure something for which nobody has interest in attacking), but it is something that should be considered in the design of a security model.

In a glorious tip-of-the-hat to the WikiWay, SecurityModel is in stark contrast to TrustedSystems.

CategorySecurity, CategorySecurityModel