Limiting insider damage

How would you limit the damage that one person could cause, by making sure that they have access only to what they need?

There are two prime methods of limiting the damage a single person can cause, limiting access to data and limiting impact to data.

Limiting access to data is most strictly implemented through mandatory access control, in which every piece of data is given a classification of value. An individual is rated for access up to a specific classification and only may read data at or below it. The most common example cited for this is the United States Government’s use of the Unclassified, Confidential, Secret, and Top Secret national security classifications. (Anderson, 2008) This example is cited so often it is nearly a cliche, yet it is done so because it is effective. A person intent on causing damage has difficulty damaging data they never can read.

Limiting impact to data involves preventing data from being modified or otherwise manipulated by a malicious actor. Embezzlement is an effective example of damage that is caused through data impact. A person with the ability to modify the audit trail concerning monetary funds can make it appear that money went where it was intended when the actual destination was someplace that they profited from. A common solution to these type of threats is to utilize two-person integrity controls. (Humphreys, 2008) When data modification actions require two individuals to occur, it guarantees that single person cannot overtly damage the data. When data modification notifies a separate reviewer of an action that may be carried out by an individual then damaging changes will be detected in short order, which reduces the time available to cause damage, limiting the overall damage that can be accomplished.

---

Anderson, R. (2008). Security engineering: A guide to building dependable distributed systems. New York: Wiley.

Humphreys, E. (2008). Information security management standards: Compliance, governance and risk management. Information Security Technical Report, 13(4), 247-255. doi:10.1016/j.istr.2008.10.010