A few days ago, I was delighted to see the National
Institute of Standards and Technology (NIST) release its Preliminary Cybersecurity
Framework for reducing cyber risks to critical infrastructure. And my first
read-through was pretty positive: they cover a lot of material, and I think it
will help organizations understand the full picture of security readiness. Their
tiered approach, for instance, is sound, and I’ve seen it work successfully in
other industries–e-discovery, for instance, has the EDRM Maturity Model, and
software development has the CMMI. And I’m very pleased to see such attention
paid to PII and privacy.

That said, however, I saw a few structural problems on my
second review. The Framework has a lot of noise about security policies and procedures
and not as much of a call-to-action on collaboration and threat
intelligence-sharing as I would like. It lacks any mention of proactive
forensics or proactive investigation. It contains a wealth of detail on rules
and process for ensuring information security, but very little in the way of
the means of, or requirements for, organizations to work together to fight the
good fight. And it has a major hole in its attempt to categorize threat
detection and response.

As usual, one article triggered a series of thoughts to connect from various news pieces that have been building up in my head over the past week. Let's start with the most recent first. Reading this article on what security concerns the leadership in healthcare the most got me thinking. Particularly this quote from the article: “The goal in healthcare generally is treating those patients, not
privacy and security. You don’t see the same focus on security in
healthcare that you do in the financial sector.” Yeah, that sounds about right. Makes sense from what I've seen and experienced. I'm sure we've all seen that there are signs in hospitals and other health care places that say 'No Smoking, Oxygen In Use' or some such thing. These rules make sense to all of us. We all get it. Problem is, there is no such rule about no hacking hospitals. 'Our pricing model doesn't let us afford ample security staff, so please don't hack us' just doesn't carry the weight as 'don't smoke or you'll blow us all up.' Patients' health is their primary focus, thankfully, and the data is just a way to describe the current condition and progress so that you can achieve the good health outcome of your client. Essentially, it is a model that hasn't evolved in light of the data revolution of the computer age. This brings me to my next thought...government security clearances.

Of course, an equally well known security principle states that a valid response to risk is to accept it. I would sincerely hope that the businesses that have my data aren't doing this. Who am I kidding? I know they are. As if I only do business with the 20% crowd...I can only dream of the day.

Anthony Di BelloA security breach, or fraudster acting from
the inside, is expensive for any organization to endure - but such incidents
are especially expensive for the heavily regulated financial services
industry.

In addition to direct monetary losses from
an incident, breaches also create a significant hit to the trust an institution
enjoys. That lost trust causes customers to leave, and creates a loss in
confidence among partners and even regulators. The resulting customer churn is
expensive, as is the loss of confidence among regulators which can result in
more aggressive audits. It’s just human nature to look more closely following a
security incident. And then there’s the higher cost of business insurance that
follows a breach.

While
they’re naturally targets among cyber-thieves, financial services firms are
also very heavily regulated. Now, that’s no secret but it helps to highlight
why, in addition to mitigating the damage of attacks, financial services firms
should make sure they have solid incident response and e-discovery capabilities
in place. These capabilities - properly integrated with IT, IT security, risk
management, legal, HR, and business executives - should be on the ready to
respond to potential cases of system abuse, fraudulent transactions,
unauthorized, or repeated, access attempts to systems and applications, and
incidents involving customer financial data.

What
many people overlook is that there are quite a few regulations that require
these capabilities be in place. And if they don’t require it directly, their
mandates make them essential.

For
instance, the Payment Card Industry Data Security Standard (PCI DSS) is often
overlooked when it comes to e-discovery and incident response. However, as is
pointed out in this Information Law Group post, while PCI DSS
doesn't directly require an incident response capability, it certainly does
through the resulting requirements that are set, and now commonplace, among
merchants and their payment processors:

In
reality, however, a merchant's true obligations in a security breach situation
are dictated by the merchant agreement it has with a payment processor or
acquiring bank. Most modern merchant agreements will require the merchant
to comply with the operating regulations and security programs of the relevant
card brands. However, these contracts may also have additional duties
relating to incident response, including different reporting requirements,
audit rights and indemnification obligations.

If you are accepting a
certain volume of credit card payments chances are you are contractually required
to have adequate incident response capabilities in place.

Provide
reasonable assurance regarding prevention or timely detection of unauthorized
acquisition, use or disposition of the [company's] assets that could have a
material effect on the financial statements.[9]

Section 302 also specifically
identifies internal fraud as an event that would require disclosure by senior
management. Put simply, an adequate internal control structure must include
"controls related to the prevention, identification and detection of
fraud."

It’s not just those two,
albeit rather substantial, regulations that require financial services firms’
and others to have effective incident response and e-discovery capabilities in
place. There’s also the FTC’s Red Flag Rules designed to identify and
fight identity theft, as well as the Gramm-Leach-Bliley Act ‘s Notification Rule.

Each of these regulations, as
well as numerous others, make incident response and e-discovery capabilities essential.
In fact, there isn’t a financial services firm that doesn’t need to be able to
quickly find and provide documents necessary for GLBA or Red Flag rule
compliance for incidents involving privacy or potentially even fraud.

Of course, all of this is
easier written in a blog post than done. Like many things in life, success
requires the right combination of technology, people, and practice. We believe
Guidance Software provides the right technology for both e-discovery and incident response, so all you need to do is
make an incident response plan, put in in place, and test and practice - this
way when something unexpected occurs you’ll be ready.