NIST Cybersecurity Framework Needs More Focus on Collaboration and Finding Anomalies

Jason Fredrickson

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.

When old processes meet new technology

Josh Beckett

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.

Trust but verify, people.

Josh Beckett

I thought it was a well understood security principle; trust but verify.  Maybe it is and the PHBs are simply out-voting the security crowd and the voice of reason.  At the end of the day when you don't know what is out in the cloud and have limited to no controls to act if you did know, your data is seriously at risk.

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.

Incident Response, E-Discovery: Crucial for Finance Industry Security and Compliance Planning

Anthony Di Bello A 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.

Same is true if you are a public company, the Sarbanes-Oxley Act of 2002 requires companies have the ability to prevent, and detect fraud, as outlined in this this FindLaw article:

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.