Compliance - a matter of managing risks

Today I've been browsing the good stuff going on over at Unified Compliance Project whose aim, as I understand it, is essentially to help organizations find and exploit alignments between various compliance requirements, eliminating duplication and hence reducing the total amount of compliance effort required. For example, implementing an ISO/IEC 27001-compliant Information Security Management System (ISMS) should simultaneously satisfy most if not all legal requirements for information privacy controls (with no additional effort), and should at least partially satisfy governance requirements arising from SOX, in addition to miscellaneous business benefits as a result of having a best practice ISMS.

One of the issues I've been pondering relates to "mandatory" requirements and obligations such as those enshrined in laws, regulations and contractual terms. It seems to me that, despite initial impressions, compliance with "mandatory" requirements may not be a simple binary condition. For a start, in most cases, the requirements are more complex than that. It is conceivable for the organization to be fully compliant with certain parts of the requirements but not so for others. Furthermore, the extent of compliance with any one requirement is often subject to interpretation, either because the requirement is ambiguous (hopefully not!) or because the organization and whomever is assessing compliance (law enforcement, lawyers, auditors, regulators, management) have their own viewpoints and prejudices. Finally, there is a chance that noncompliance might not be detected, or even if it is, it might not lead to the worst case consquences often paraded by the compliance lobby.

It's the same with speeding laws. If I break the speed limit, even by 1 mph, I am strictly failing to comply with a mandatory legal obligation. In practice, however, it is extremely unlikely I would ever be stopped for 1 mph over because (a) there are insufficient policemen with radar guns to track my every journey; (b) their radar guns have tolerance limits; (c) my speedo has tolerance limits, and the police and/or prosecutors allow me some flexibility; (d) if I am caught, there's a chance I might talk my way out of it; (e) even if I am fined, I might escape justice by fleeing the country, or I might get off "on a technicality". The situation changes for every mph over the limit - as indeed do my chances of being involved in a fatal accident. I weigh all this up every time I drive. [And yes I make mistakes: I have been fined for speeding. I didn't flee the country, I paid up and "learnt my lesson".]

So, all of this is, in fact, a risk management exercise. I assess the threat (of being caught speeding), the vulnerability (how far over the limit I am going) and the impact (the fines, the grief).

Something like SOX can be treated in the same way. Management may consciously choose NOT to be totally compliant, assessing the risks like any other business decision. Maybe they will get away with it. Maybe they can present good enough excuses to the auditors etc. to escape the full force of the law. Maybe the commercial benefits of noncompliance justify it in purely economic, if not ethical, terms.

I haven't seen this kind of perspective discussed anywhere but I am not a compliance expert. Perhaps it's old hat and I've just stumbled across somethig that is already well known. Or perhaps this stuff actually happens but nobody is willing to acknowledge it openly? I'd be interested in your thoughts.

New IT security standards for US electricity industry

FERC, the Federal Energy Regulatory Commission, has approved eight new mandatory critical infrastructure protection (CIP) reliability standards developed by NERC, the North American Electric Reliability Corporation, covering:
- Critical cyber asset identification (NERC standard CIP-002) - essentially inventory and risk assessment of critical information assets;
- Security management controls (CIP-003) - security policy and management structure, exceptions process etc.;
- Personnel and training (CIP-004) - personnel risk assessment, training and, of course, security awareness;
- Electronic security perimeters (CIP-005) - a 'crunchy outer shell' for networks;
- Physical security of critical cyber assets (CIP-006) - physical perimeter controls, card locks, processes, visitor logs etc.;
- Systems security management (CIP-007) - security testing and patching, controlled network services, antivirus, security monitoring and various other IT security controls including, I note, minimum 6 alphanumeric+punctuation character passwords with a lifetime of up to one year (!);
- Incident reporting and response planning (CIP-008) - an annually-reviewed incident response plan; and
- Recovery plans for critical cyber assets (CIP-009) - DR plans with at least annual exercises.

For completeness, CIP-001 covers sabotage reporting, the critical infrastructure equivalent of SB-1386 and similar requirements to report unauthorized credit card or personal data disclosures.

FERC's IT security standards are stronger that mere recommendations and will probably become fully mandatory when get-out clauses relating to business judgement are removed. In-scope companies should all have started work on this by now and have to be fully compliant by mid-2008 or mid-2009 depending on the type of company and the specific standards.

FERC did not go as far as to mandate NIST's SP800-series security standards, however, excellent though they are, nor indeed international standards such as ISO/IEC 27002. The stated reason was not to delay implementation. While I applaud their haste to beef up infrastructure security, it's a shame to ignore the large existing body of work on information security from the likes of NIST, ANSI, BSI, ISO, IEC and others. Arguably there is a need for specific security standards covering SCADA (Supervisory Controls And Data Acquisition) systems, but the electricity industry is not pure SCADA by a long shot: there are conventional systems, many running Microsoft Windows and various UNIX/Linux variants, and TCP/IP networks all over the place, and security architecture, operations and management issues are basically the same as for any other industry. [I guess adopting existing standards would put a posse of electricity industry security consultants out of jobs but IMHO they are better deployed implementing security standards than creating new ones.]

Looking over the lit of bullets above, it is not hard to align FERC's advice with ISO/IEC 27002 ... whereupon gaps such as compliance stand out. FERC evidently intends to assess or audit the utilities' security against the standards but there's more to compliance than formal assessments/audits. Electricity companies should have suitable governance structures and processes in place to ensure compliance with their internal security requirements (policies, standards, guidelines and procedures) and with legal obligations unrelated to FERC (e.g. software license compliance plus other intellectual property issues, SOX and protection of Personally Identifiable Information) along with compliance by their suppliers and business partners. There are solid commercial drivers for information security in the electricity industry, quite separate from the critical infrastructure protection angle. Surely FERC could leverage this to their advantage?

The standard on DR is also notable for the absence of any advice on contingency planning and business continuity. I would have thought that 'keeping the light on' is absolutely number 1 top priority for the electricity industry, therefore resilience is more important than recovery. Perhaps this is so ingrained that it is taken as read but I'm surprised by the omission.

By the way, I also couldn't help but notice that "Facilities regulated by the U.S. Nuclear Regulatory Commission or the Canadian Nuclear Safety Commission" are explicitly excluded from the scope of the standards. I trust the nukes have their own, strong, rigorous, comprehensive cyber security standards ... they do, don't they?

Blogs trump piracy

An intriguing article in the Washington Post recounts a handful of copyright abuse cases in which corporations have used photographs taken by amateurs and published online, for example in their blogs or on social networking websites. There's a curiously ambiguous thread to the piece: on the one hand it says perhaps people shouldn't publish material online if they don't want it to be copied and used elsewhere, while on the other it notes that people are increasingly calling their lawyers to defend their rights. It is strongly implied that corporations should know better, in other words there's a David and Goliath element to it, especially if the self-same corporations are quick to defend their own copyright material against abuse by others.

Blogs and other online social interactions are credited with informing people that their images are being abused, and helping them defend their rights. Online communication between people is definitely changing the nature of human culture. How else could loose-knit communities spread across various countries collaborate with such ease?

Copyright law makes no distinction between original materials created/published/used by amateurs versus professionals. Anyone who uses images and other original materials in their own work either needs explicit permission from the copyright owner (for example through a license agreement or contract) or has to conform to the narrow "fair use" provisions (at least in countries that allow "fair use" - I gather Canada is a notable exception to the norm).

Several of the cases noted involved abuse of images by 'low level employees', corporate-speak for office juniors who are either unaware of, or choose to ignore, their copyright obligations. Clearly, corporate security awareness programs should cover copyright and other compliance obligations [as indeed NoticeBored recently did!].

Having a bad day at the office?

An IT systems administrator, fearing that he was about to be laid off, planted a logic bomb in his employer's systems. He survived the round of redundancies but detonated the logic bomb anyway. Fortunately for all concerned, bugs in the code prevented it working properly. In court, he was found guilty, sentenced to 30 months' jail time and found liable for $81,200 in restitution.

This story touches on quite a number of security topics:
- He was a trusted insider who went bad
- Logic bombs are a form of malware
- His office/day-job gave him privileged access to the company's IT assets
- Weak change management process controls did not prevent the bomb being installed
- The logic bomb had one or more bugs in the program/script
- Nevertheless it sparked a security incident
- He was called to account for the damage
- There was legal and presumably corporate policy noncompliance
- The risk of recurrence presumably remains

All in all, a nice multi-purpose security awareness case study.

PS The official US DOJ press release about the conviction is dated "Dec 8 2008", an integrity failure to boot.

UK insurance firm fined for pretexting incidents

The UK's Financial Services Authority has fined insurer Norwich Union £1.26m as a result of inadequate protection of customers' personal data:

"The City watchdog says Norwich Union's life assurance unit did not have effective systems and controls in place to protect customers' confidential information and manage financial crime risks. These failings resulted in a number of actual and attempted frauds against policyholders. Slack call centre security allowed fraudsters to use publicly available information - including names and dates of birth - to impersonate customers and obtain sensitive customer data, says the FSA. In some cases criminals were able to ask for confidential customer records, such as addresses and bank account details, to be altered. The fraudsters then used the information gleaned to request the surrender of 74 customers' policies totalling £3.3 million in 2006. The FSA says its investigation found that Norwich Union Life failed to properly assess the risks posed by financial crime and as a result, its customers were more likely to fall victim to identity theft."

The official FSA report makes interesting reading, disclosing for instance that fraudsters were using information obtained legitimately from public records held at Companies House to respond to authentication questions.

The company has since smartened up its act with better policies, procedures and (hopefully) compliance activities but I doubt that even it would claim to be immune to social engineering risks. Pretexting is a relatively cheap and easy form of attack and the juicy personal data in such databases is clearly luring fraudsters.

Breach disclosure net widens

California State Bill 1386 was the first US bill to insist that organizations disclose to Californian citizens details of privacy breaches affecting their financial data, an idea since extended to around 40 US states.

SB1386 opened the flood gates when privacy breaches affecting millions of data subjects were disclosed. Prior to SB1386, even huge privacy incidents were successfully hushed up or downplayed by embarrassed (borderline unethical) organizations' spin doctors. SB1386 woke up an ignorant or complacent public.

The Californian law is now being extended to include privacy breaches involving medical and health insurance information under AB1298:

" AB 1298 adds two new breach-triggering data categories to the law of “health insurance information” defined as a health insurance policy or subscriber number(s), any information in an individual’s application and claims history, including any appeals records; and “medical information” including any information regarding an individual’s medical history, mental or physical condition, or medical treatment or diagnosis by a health care professional."

ISSA eSymposium on PCI compliance

ISSA has a “PCI Compliance” webcast on December 6th 2007. Speakers will present "live and online" giving you the opportunity to interact in real-time from the convenience of your desk. Register for this free event.

New PCI security standard

The Payment Cards Industry (PCI) Security Standards Council (SSC) is adopting Visa's Payment Application Best Practices (PABP) standard as the Payment Application Data Security Standard (PA-DSS). It is due to be finalized and released early in 2008. Anyone wishing to access and contribute to the draft standard must join the PCI SSC (i.e. this is not an open standard).

PA-DSS will presumably be implemented by mandating it on those developing commercial credit card applications (not those developed and used internally) and checking their compliance through a network of Qualified Security Assessors (QSAs), accredited by PCI SSC.

It will complement the existing PCI Data Security Standard (PCI DSS).

IT audit checklist on privacy/data protection

A new checklist from the IT Compliance Institute on privacy and data protection suggests some 270 items to check, and offers advice and tips on the associated controls. It also gives hints on what the auditors do/don't expect to see, good for getting your house in order before they call.

New US infosec laws

SecurityCatalyst blogs on two new US information security laws. Minnesota's Plastic Card Security Act adds a legal mandate to PCI DSS. The Identity Theft Enforcement and Restitution Act gives victims of identity theft compensation rights. I'm hunting for more information on both of these and will provide an update if I have add anything to add to SecurityCatalyst's post.

Which is the real First Niagra?

A trademark spat between two financial services companies reveals a deeper issue.

First Niagara Insurance Brokers use the domain FirstNiagra dotcom. First Niagara Financial Group, previously known as Lockport Savings Bank, changed its name in 2000 and tried to purchase FirstNiagra dotcom from the present owners, who refused. They then registered First-Niagra dotcom as their address for emails.

Customers of First Niagra Financial Group sometimes forget to include the crucial hyphen when emailing them, so their emails end up at First Niagra Insurance Brokers. Some emails contain sensitive information because (shock! horror!) customers sometimes send Social Security Numbers etc. in plaintext emails.

With clear evidence that customers are being confused by the similar domain names, the trademark infringement issue should't be too taxing on the judge, but this case may perhaps open Pandora's box on similar cases.

ITCi Journal

The IT Compliance Institute's journal should be on your reading list if compliance is on your radar screen. The Fall 2007 issue has good articles on ISO/IEC 27001 & 27002 vs. NISTs SP800 series, symmetric encryption key management and eDiscovery.

The piece 'Holding auditors accountable for data security' is not about making internal auditors accountable for the organization's information security, but rather about the obligations on external auditors to secure privileged information they obtain during the course of audits. For a while it seemed de rigeur for big name auditors to lose laptops containing confidential client information but I can't recall any similar breaches since about 18 months ago. Did the audit firms clean up their act, or are these stories no longer newsworthy? Being of a cynical nature, I suspect the latter. Anyway, the article advises great caution when handing highly sensitive business records to the auditors, for example requiring that they are reviewed on-site and not taken away. I can almost feel the wave of horror passing across any auditors in the audience! If the organization has a strong information security policy, perhaps in response to its compliance obligations under SOX and PCI DSS, management should indeed be extremely cautious about handing information to any third party. On the flip side, though, the auditors need to be able to do their jobs and won't appreciate (further) constraints, although I guess they may just 'add it to the bill'. It is not unreasonable to insist that security compliance, confidentiality and liability aspects are incorporated in suitable clauses in the audit contract, for example by insisting that the auditors should be ISO/IEC 27001 certified. In fact, why not have your CEO formally express the importance of information security to the audit team before they start work? That's one way to make an impression ...

Standards are for everyone else, not BSI

When I tried to notify BSI-Global (formerly the British Standards Institute) about a possible phishing email using them as a lure this morning, their automated mailing system sent me the following curt response:

"This is an automatically generated Delivery Status Notification.

Delivery to the following recipients failed.

abuse@bsi-global.com"

So much for standards. RFC 2142 has only been out there for ten years. Perhaps BSI is above the standards that apply to us lesser mortals?

Resistance is useless

You know you want to. Visit the NoticeBored website to find out about the new security compliance module. We have stripped down and completely rebuilt the 'laws, regulations and standards' awareness module last delivered 3 years ago and soon realized what business people mean when they complain about the compliance load. When you look into it, there's a huge pressure to comply with externally-mandated laws, regulations and standards, plus the rules organziations make up for themselves, the strategies, policies and contractual terms.

Being a security awareness service, we focus on the information security rules of course but I believe there are possibly one or two non-information-security laws, regs and standards out there too ...