Hurricane Florence and Disaster Recovery Planning

As Hurricane Florence is set to smash into the Carolinas today, it may have you thinking about how your business might fare an unexpected disaster. Even if it didn’t, it sure crossed our mind.

Some businesses have a strong record of surviving disasters, even using it as a competitive advantage. Below, is a link to a 2011 article about just such an advantage that Waffle House and Home Depot have over the competition. While the article is about supply chain management, it’s still a very interesting read as it applies to IT disaster recovery, and business continuity as a whole.

Visit our LinkedIn page to join the conversation if you’d like, or give us a call to talk about your DR plans and strategies. We have years of DR experience in various industries that can help you be as prepared as possible.

Waffle House, Home Depot cited as examples of emergency preparedness

 

PCI-DSS 3.2.1 is Here

Recently, the Payment Card Industry (PCI) released an update to their Data Security Standard (DSS) that is used by anyone that accepts credit cards within their organization.  This new release, version 3.2.1, is a minor update to version 3.2 which we've been using for the past two years.  The minor changes are as follows, and should generally come as no surprise:

  1. Some requirements had a "Best practice" that wasn't required until February, 2018.  Seeing as which February has come and gone, the "best practices" are now required.  
  2. The appendix has been updated to reflect that SSL/early-TLS is now required
  3. "Multi-factor authentication" has been removed as an example Compensating Control.  Since Multi-Factor is now required, it makes sense it can't be a compensating control.

What's this mean for you?  In general, if you've been following PCI 3.2 (which you should be), and you implemented TLS 1.2 or 1.3,  then nothing has changed.  You can confirm this by going to https://www.ssllabs.com/ssltest/ and testing your site for SSL, TLS 1.0 or TLS 1.1.  Even if you use a payment gateway such as PayPal to process the actual transaction, PCI still applies if you are passing information to the gateway and back.

If you need more information, or would like advice on how to handle PCI compliance in your environment, give us a call or send us an email.  We'd be glad to help!

Policies and your Information Security Program

Information Security Policies are like guard rails on the highway.  They keep you "on track"

Information Security Policies are like guard rails on the highway.  They keep you "on track"

Regulations and standards almost universally require an "information security policy," which would make us believe they must be rather important.  For example, New York's Department of Financial Services "Cybersecurity requirements" say "Each Covered Entity shall implement and maintain a written policy or policies... setting forth the Covered Entity’s policies and procedures for the protection of its Information Systems and Nonpublic Information stored on those Information Systems" (23 NYCRR 500.03).  Another example is the PCI Data Security Standard which has 12 requirements, one of which is "maintain an information security policy."  As for the other 11 requirements of PCI they all end with a question asking if policies are "documented, in use, and well known."  But what's a piece of paper going to do for you to improve security?

The short answer, and to borrow a phrase from the medical field, "if you didn't document it, it didn't happen."

The long answer is that well documented information security policies provide us, among other things:

  • Direction
  • Accountability
  • Protection

Direction

Think of information security policies as guard rails on a highway.  Without them, we might find ourselves flying off a bridge or cliff.  To use another analogy, policies form the foundation of our information security program and are often overlooked.  As staff turns over, or the business changes, our policies set forth the way we will manage our security program. 

For example, a common information security policy is a "data retention policy" which outlines how the organization will manage its data, and for how long it will make the data available.  As IT administrators change (keep in mind the average employee tenure is 3.68 years), or IT consultants change, a data retention policy provides them the direction on what is required to maintain your business data. 

Without it, staff have to either guess; or your data gets deleted early; or never.  Under all three of those scenarios, you lose.  Deleting business data early is usually considered a data breach because it impacts the "availability" of the data.  Having it too long costs you money.  And I'm sure you can guess what "guessing" does.

Accountability

The HIPAA Security Rule specifically requires a "sanctions policy," and this makes complete sense.  Policies provide the written, documented expectations of employees and vendors within your organization.  If someone isn't meeting these expectations, for example one of your employees CONSTANTLY clicks on phishing links, your information security policies, as well as your discipline policy, give you the ability to address the issue.  Without a policy outlining your expectations, an employee can claim ignorance.  At best, you might be able to get them on insubordination because you told them to stop.  However, I'd bet a lawyer could fight that argument.

Therefore, policies set up a system of accountability.  The "guard rails" that tell us what we can and can't do are established and are made clear to everyone.  Those that don't follow the policies can be addressed.  Even if it means the employee gets additional training, or a write-up, the policies give us the ability to work together.  By working together, we're able to reduce risk.

Protection

When I say protection, I pretty much mean "liability."  When it comes to policies and liability this can go a few different ways.

First, without a policy, you could be considered non-compliant for any regulations that require a policy.  However, even if you're not required to have a policy by law, you're required to have a policy by precedent.  In the 1939 Supreme Court case "T.J. Hooper v. Northern Barge Corp" it was established that companies owe a "duty of reasonable care" even if there is no standard or regulation requiring you to do something.  It's very well established in standards and regulations, even if they don't apply to you, that a policy is a basic thing to do to help protect data and systems.  Because of that if you experience a breach, and you don't have a policy, you're probably on the hook for negligence.   Even without negligence, a breach is an expensive proposition.

Second, a policy provides you (some) protection from negligent or careless staff.  If you have a well-established policy, and you follow it, your risk in case of a breach is reduced.  Beyond the risk reduction that people are doing the right things, should you have a breach that is caused by a staff member the organization will probably fair better (disclaimer: I'm not a lawyer and this is not legal advice).  In such a case, you have your policy and the evidence that the policy has been implemented to back up your claim that the event was far outside the normal standard practices of your business.  Without the policy, you've got nothing.

Lastly, I would be remiss to not point out that a policy can actually HURT your business.  I worked with a compliance officer at a hospital who frequently said "there is nothing worse than a policy you don't follow."  I would bet that hospital compliance officers would know from experience in malpractice cases the merits of that statement.  If you want to hand a cut and dry case of "negligence" to a legal opponent or regulator, document what you should do, and then don't do it.  By demonstrating that you know what you're supposed to do, and then to not do it, is probably the legal definition of negligence (I'm not a lawyer, so I'd have to guess here...).  So, when you create a policy, make sure you follow it!

Conclusion

Information security policies may seem like a burdensome exercise on your "check the box" path to compliance. That doesn't have to be the case though. Policies can communicate valuable information on how you protect your sensitive data, and provide you with the means to ensure that it actually happens.  Without policies, staff must assume what is intended and when they assume wrong, you're left holding the bag.

I use this statistic all the time, and it's not meant as a scare tactic, but 60% of small to medium size business close after a data breach.  For small business owners like ourselves and the employees and clients that depend on us, we have an obligation to protect them because it makes good business sense.  Having a well documented and thoughtful information security policy is a great step on that journey towards risk reduction.

If you need assistance with creating an information security policy, contact us today.  We take policy creation seriously, and have created policies for many businesses.  We can start with a baseline policy that meets your specific regulatory requirements, and tailor it to work for YOUR business.