Two problems for detective and corrective security controls are education and false positives. Education refers to providing the appropriate knowledge required by users of the system or data being secured. Simply stated the people using the system or data need to know how to manage the security control to both enable the secure use and minimize the inconvenience of the control. False positives are the act of identifying risk(s) when there is no risk present. For example, identifying a legitimate Windows system file as a virus and quarantining it. Or incorrectly identifying a phone number as a social security number. They both start with three digits (XXX) and end in four digits (XXXX) and are separated by dashes.

One method of managing both of these security problems which is enabled by the IT savvy mind is what I call a Figure Eight Feedback Loop. The figure eight is created by two feedback loops next to each other which feed information to each other.

• Loop 1
• Action is triggered by automated identification of a risk. Event recorded
• System/data user is prompted, including specifics about what/what automated trigger occurred (Education)
• User is allowed to make a decision
• Decision is recorded
• Loop 2
• Automated identification and decision records from loop 1 are utilized.
• Review of identification and decision information by security resources
• Automated identification triggers are revised to reduce false positives
• New automation triggers included in loop 1

Let’s look at more concrete example to get a better grasp. As many of you know, it’s a Payment Card Industry (PCI) violation to send credit card information via unencrypted e-mail. This creates a problem if a customer sends their credit card number (CC#) in an e-mail to their financial institution. The customer service representative needs to be knowledgeable of the regulation and ensure they remove the CC# in the event they reply to the customer. To assist in resolving this problem the financial company can institute e-mail data loss prevention tools.

• Loop 1 – Host Data Loss Prevention (DLP) software on company computer scans e-mail for violations of information security policies
• E-mail DLP tool scans e-mail for credit card numbers when the user hits the Send button.
• If CC# is found prompt the user. “It looks like there is a credit card number(CC#) contained within this e-mail. It is against Payment Card Industry (PCI) – data security standards (DSS) to send CC# data via unencrypted communication. Please review the e-mail and make sure CC# is not present (No CC# present button) or hit (Cancel Sending) if you find CC# data. Thank you.”
• Decision by user after review of e-mail
• Record of possible event is recorded in system for review by security resources
• Loop 2 – Insider threat team reviews Host DLP log files to improve patterns used to identify credit card numbers
• Security team selects either samples or reviews all transactions as appropriate, to identify when associates continued to send CC#s (policy violation) and when the system falsely identified a number as a credit card number
• If policy violation then associate and associates manager are involved to understand risk to company and possibly warning or termination if severity violation warrants it
• If false positive, patterns used in identifying credit card numbers are refined to manage the situation
• New automation is loaded into loop 1

Hopefully, that example provides enough meat for us to discuss the benefits I laid out in the beginning.

1. Education – The users of the system are informed what they did, why it was wrong, and how to correct it, before a violation of policy occurred. This proactive involvement in security decision making builds a positive image of security, educates the users of the system, and provides a foundation for other risk decisions.
2. False positives – By educating and then utilizing the intimate knowledge of the user to determine if there is risk or not, the security resource has a much better understanding of the false positive. This enables a collection of false positives to be created and analyzed to come up with new automation methods. The control itself evolves and gets better over time.

This technique can be used for any detective or corrective control. You’ve probably already seen it and or used it, but didn’t have a name for it. Another simple example is password requirements. Most password change processes now refuse to accept characters which are forbidden by the federated systems being managed. The user is told to try again and presented a list of the possible characters they must use and are forbidden to use. This is the end state evolution of many years of figure eight feedback loops. As new creative controls are engineered these concepts need to be applied to best serve both the needs of the business partner and the Information Risk Management requirements of the security/risk organization.