Detailed Written Procedures | Paperwork
Regulators should not to overemphasize documentation as a form of data security. Paperwork per se does not protect sensitive data.
In practice, overly detailed documentation can hinder enterprise security, because threats, technology and enterprises themselves change very rapidly. Keeping very detailed documentation up-to-date can be a distraction and a source of confusion. Security should focus on substance.
Regulatory authorities can be tempted to emphasize documentation because it is easy to audit.
Fine for D.A. Davidson
The Financial Industry Regulatory Authority (FINRA) fined stock broker D.A. Davidson & Co. $375,000 after a hacker stole personal data on 192,000 Davidson customers.
This incident caused no identity theft among customers.
Does Imperfect Documentation Justify Fine?
A key reason for the fine, according to FINRA, is that Davidson’s security documentation was incomplete: “D.A. Davidson failed to . . . establish and maintain a system, including written supervisory procedures, reasonably designed to achieve compliance with Rule 30 of Regulation S-P.” FINRA Letter of Acceptance, Waiver and Consent No. 20080152998.
According to Rule 30, “[e]very broker, dealer . . . must adopt written policies and procedures that address administrative, technical, and physical safeguards for the protection of customer records and information. These written policies and procedures must be reasonably designed to: (1) insure the security and confidentiality of customer records and information . . .”
Let’s look more carefully at what FINRA said about Davidson’s lack of documentation. It said: “The Firm also did not have finalized and implemented written procedures in place for its information security program that, among other things, should have been designed to protect confidential customer information.”
Was There a Substantive Shortcoming?
So what were the particular shortcomings in the documentation? FINRA said:
1. “The Firm did not have any written procedures in place for the review of system web server logs, nor an intrusion detection system.”
2. “Even if it had detected the intrusion, the Firm did not have written procedures setting forth an information security program designed to respond to intrusions.”
This lack of documentation needs to be seen in context.
Davidson did have a security program (including a firewall and a practice of regularly reviewing perimeter security logs) under the care of IT professionals. It had recently engaged with security auditors and consultants and had implemented the “majority” of their recommendations.
FINRA did not say that Davidson had no security documentation, or that Davidson’s IT professionals were incompetent. From what FINRA said, it appears Davidson did have documentation, maybe quite a bit. Some of it was not finalized; in IT security today, nothing is ever final because technology and threats change constantly.
Further, FINRA did not find that Davidson responded poorly to the incident once it was discovered. In fact, FINRA cited a series of intelligent steps that Davidson took when it learned of the break-in (such as taking down the firm’s web site, contacting law enforcement and hiring an outside consultant for remediation).
Should Regulators Expect InfoSec Perfection?
Security is very difficult. FINRA does not talk about that in this Davidson ruling. Regulators are imprudent to expect perfection. Security perfection does not exist.
FINRA did not analyze how difficult it would have been for Davidson to become invulnerable to attack.
It is easy for a regulator to look back with the benefit of hindsight and say, “Oh, you forgot to review web logs.” What is much harder is for an enterprise like Davidson – on a prospective basis – to find, evaluate and close off all possible vulnerabilities, while at the same time providing good service to customers at a good price.
Why a Fine for Failing to State Common Sense?
One of the two documentation shortcomings FINRA cited was intrusion response procedure. What magic did FINRA think was missing in the documentation to inform IT professionals how to respond to an intrusion? Intrusions come in a multitude of flavors, and the flavors change over time. The most competent intrusion response procedure to document would be general: “In the event of a suspected intrusion, strive to investigate it, keep records of the investigation and take appropriate steps to mitigate it, based on the circumstances.” So what is the problem about not explicitly writing this sentence in documentation? The sentence is just common sense to IT professionals.
FINRA’s report does not tell whether Davidson had other evidence that its professionals knew how to respond to an intrusion, such as training, experience or discussions recorded, for example, in email.
FINRA’s emphasis on formal documentation worries me because it gives the impression that documentation in and of itself is really important to regulators. Such an impression can cause enterprises to overdo the paperwork, creating long, rigid, expensive documents to show to auditors and regulators.
What's More Important, Paperwork or Substance?
Leaders at the SANS Institute have long criticized FISMA (law requiring information security in Federal government agencies) as a misguided and wasteful call for paperwork rather than substantive security. See comments by Alan Paller and Ed Skoudis, SANS NewsBites, April 23, 2010, Vol. 12, Num. 32 .
–Benjamin Wright, Legal Issues Instructor, SANS Institute
