I’ve had two clients in two weeks present to us as part of an assessment an incident response plan template provided to them as part of the documents their cyber liability insurer provided them along with their policy. Neither client had done anything with the template yet presented them as proof that they did indeed have an incident response plan.
Incidents that are handled on the fly without any prepared plan can be a magnitude more costly thatn those that are managed through a prepared plan. For that reason I think it is a good thing that the insurance companies have provided a template that provides structures for a plan. It is good for the client, the insurer and everyone else involved.
My concern is neither client felt compelled to do anything with the templates that were provided. In the heat of the moment following an incident they are going to manage things on the fly. Will that impact their coverage?
Both clients thought that the template was the plan and didn’t realize that it needed additional attention to be completed.
So beyond saying incident response plans are good and templates that are not completed are bad, I’ve got more curiosity than conclusion.
Some questions for discusion:
Have you invested in cyberliability insurance as part of your risk management strategy?
Are you doing what is necessary to meet the requirements of your insurer to have coverage in the event of an incident?
Did you get an incident response plan template or any other security operations templates along with your coverage? Is coverage incumbent on those templates being complete and used? Did you complete them?
I would welcome a conversation with you about the role cyberliability insurance plays in your risk management program including a discussion of your answers to my questions above.
I am putting the finishing touches on an executive presention for a client. Our finding, after a series of technical tests, a review of their policies and their security administrative compents was that they are generally proactive on securty from a technical perspective but any additional maturation or improvement of their program requires management involvement.
I am going to present this to senior management team that has already informed me they don't want to hear that message.
This isn't the first time Jacadis has encountered such a situation.
Why should senior management be involved in security decisions?
At some level security decisions are really risk management decisions and not just technical, information security decisions. Even the strongest technical team can't know the risks, obligations, contracts and mission priorities that senior management brings to the table.
Sorry, managers but this isn't just geeky stuff.
Here is a quick list of five questions that my client's technical team needs senior management input, involvement and or leadership on:
Are we obligated by law or contract to HIPAA?
Are we obligated to PCI? Are we exposed in the way we handle crtedit card data?
How long can your business operate with reduced computer facilities? Which facilities are most important to the mission?
How will we respond to illegal activity on our network? Attacks from outside? In the event of a breach?
What are our employees permitted to do with social media outside of work hours on their own computers?
Are you putting your technical team in a spot where you expect them to protect your business but don't share with them critical information or involve yourself in their decision making process? If you are in a business that is data driven (and which business today isn't) your lack of involvement will likely ensure a high technical team turnover, raise the possibility that you will have security issues interfere with your business, decrease the resiliency of your business and potentially put at risk vendor and client relationship while also opening your business (and perhaps yourself personally) to legal and regulatory liability.
After operating my own business for 10-plus years I often get asked by new entreprenuers starting out what things I think are most important to someone starting up a new business.
1. Focus on your craft, but become an expert at sales. When I started I thought that I needed to be the best I could be at what we do (information security, privacy, risk management) and how we do it (project management, professional services management). I have found over the years though that if you don't understand the sales process and excel as a participant in it you can lose sales to firms that don't know the craft as well as you and you can miss customer expectations. Truly every project begins with sales.
2. Find a good lawyer. Find a good accountant. I have had a good accountant almost from day one, John Davidson (no relation, really) from Kyles Hill. John's taught me a lot about the financial side of business, sat beside me in negotiations as our CFO and given me a different perpsective that has helped me and Jacadis grow. We have had good legal work done but no attorney has given us th depth of the effort that John brought us on the accounting side. That, I believe, was a weakness in our formative years.
3. Take the time to write a simple business plan. Spend your time searching for a good simple business plan outline. Take the time to work through it. Focus on the directional issues. Why does your business exist? What does it do? Why do people need it? Who are your customers? Where do you find them? What do you need to do your work successfully? Can your idea scale? What do you need to scale? A solid business plan can be written in a weekend. Don't put it on the shelf. I pull ours out every quarter to check our direction. Sometimes I adjust the plan with input from senior staff. Sometimes I adjust the work effort or activities. Regardless we make course corrections every quarter because the plan is a living guide for who we are, what we do and who we serve.
4. Design the business with security and privacy in mind. Really. We run our businesses off the fuel of information. Too often we have seen small businesses fail or struggle because they have lost the confidentiality of key information, lost access to key information or found that it became contaiminated and unusable. Larger businesses can absorb more damage. Many of them by virture of their size have these covered. Small businesses can't absorb much damage. In the rush to focus on sales and craft many entrepreneurs forget the basics and leave their networks open to the outside, key customer data exposed or simply opt to save a few bucks and not back up their information. There are stories in the news regularly about business failures that were planning failures because business starters didn't think about security and privacy at startup.
With so much focus these days on data privacy and individual identities much of the conversation within the security community and from the security community to the business community skips over other critical information types that need to be protected.
This is a list of information that you should also work to protect:
1. Information about your systems and networks. When I backpack I don't do very well if I have to go off trail and I don't have a map. The same is true for someone trying to break into your information systems. If you fail to protect the information describing your systems and networks (network maps, configuration files, etc.) then you may just be providing a map to someone who wants to explore your network and find more valuable information. Are you making your network an outside explorers paradise?
2. Your company's secret sauce. You may not have a secret sauce made of "11 herbs and spices". Or your business may not depend on the mysteries of an ancient chinese secret (Remember the Calgon commercials?) but all of us in small business have our secret sauces. For Jacadis, it is the unique way we deliver many of our services. For a printing client of mine, it is the unique steps that they have created to protect confidential data transmitted to them from larger customers. That process has helped them win business because other printers aren't doing it. Years ago we did work for a company that made a unique material used in the florist business. They were the only company in the world that could produce the material at quantity and had factories world wide that did it. Their key asset was the chemical formula and process to produce that material. Are you protecting your secret sauces?
3. Work. Think of the endless hours that you spent putting together that killer sales presentation. Should it be corrupted or removed from your computer you’ll have to redo the work. The same is true for data entry, etc. The work itself might not be “secret” but should you lose it you’ll really be losing time and value. As I sit here typing most of my work is electronic collections of media (words, video, slide presentations, papers, articles, Secure-Value, jacadis.com). For your business your work may be many other things. My sales team would tell me that their biggest collection of work is the information they have on clients. A friend of mine has a laser cutting business. Unique programs are written to consistently and repeatedly cut 3D designs into different materials. These programs are his work. Another friend has a much lower tech manufacturing business, an old sand mold foundary. His forms and molds breaking means he has to redo them just as my more high tech laser cutting friend would have to do should those laser programs get lost or corrupted. In the end the loss of work means the loss of time or information. You'll have to invest time to recreate the information. In some cases you may not be able to recreate it. Are you protecting your work?
4. Personal information about your executives, leaders and key employees. Again, to explore something you need a map. To attack a target you need a map. Freely and without thought sharing personal information on your executives, leaders and key employees may just be providing a map. This is a tricky subject though. I won't do business with a company if I can't see some information about its ownership. Most people do business with people so a company that completely hides the details of their key players doesn't earn my trust. Likewise, though, a firm that freely shares contact information, addresses, personal information, etc. about its members opens itself up. On a simple level, executive emails sprinkled all over a web site invite spam. On a more complicated level, in some businesses, travel plans and other locational information improperly shared invites more nefarious attacks. Are you protecting your key people? Are you protecting all of your people?
5. Personal, though non-protected, information about your customers and prospects. Again, protect the map. Customer lists, detailed information about your customer's pains and challenges, and the other sort of information that fuels a personal realationship between your business and your clients should be protected regardless of whether or not the informaiton is consdiered private, confidential or in some way protected by law or regulation. Protecting your customers information promotes trust. Are you promoting trust with your customers?
What types of information that must be protected did I miss?
We had a unique call come in yesterday, one I wish we had more of, but we don't.
A small business owner with a brokerage of sorts wanted to develop a website that would allow the producers and the buyers to post information, in some cases highly personal information, review non-confidential subsets of the data about the other and keep the whole thing secured from the outside.
She asked if we could help and provide "small business pricing quotes."
In fact, I don't think many security firms get those calls.
Most of our calls are after the fact either after the app or system has been developed or just after it has been breached.
She called us asking questions because she didn't have any answers. I think that approach serves us well in many endeavors.
We can help her. We offered to help her develop a list of functions and safeguards she needed in her application, help her manage the procurement process and then to test the application for security before she accepted it from her developer.
In 10 years of business that was a first.
Most web applications, particularly web applications are built with out much thought to information security, customer privacy or regulations covering the information.
Truthfully no application is 100% secure. But an application that has been designed and developed with careful consideration for its information security, user privacy and regulatory requirements stands a great defensive chance once it has been launched. Testing that application before launch further raises the defensive posture. Regular testing and a proper operational routine after it has been released to production even further raises that posture.
Again, our experience has been that most businesses, particularly small business, design and develop applications, release them to production and then through some event realize that security is a concern. There is a breach or a break-in. The site is knocked off line by a denial of service attack and revenue streams are interrupted. The invoice from the payment card processor is higher than they want to pay and they find it is because of non-compliance with PCI. And so on.
This occurs because two things don’t happen up front:
Security just isn’t talked about as part of the deisgn process. It must be!
An assumption is made that developer and hosting providers on the project will handle security. In most cases they won’t unless you demand it of them and back the demand up with contracts and tests.
Here is a list of non-technical questions you need to consider as part of your design conversation. Getting technical on some of these issues may require a member of your IT staff or an outside consultant. But any small business owner should be able to answer these questions if they are trying to build a business using technology:
What is the sensitivity of the data on our planned site? Is it regulated data?
Who regulates the information or audience that uses our site? What are your obligations to protect it? What are your obligations to maintain user privacy? Does your privacy policy match that obligation? Will the site be developed with the guidance of a privacy policy?
How long can the site be offline before it negatively impacts our business? When will customers usually visit the site to transact business? If we are off line an hour of peak traffic time how much revenue will we lose? Profit?
What do our customer’s expect from us in regard to protecting their privacy?
Will you have user forums or accounts on the site? How will you verify those signed up are really customers? Or really people?! Does that matter? Will you allow any and all comments in your forums? Do you need to edit them or block them?
How does the developer ensure the web application is secure? The database?
How does the hosting provider help secure your application? How will you know they are doing their job?
You then need to make sure that your development partner builds the site to meet the requirements these questions should raise to the surface.
That site must be deployed in a technical environment that is at minimum protected by:
Proper and verified operating system and application hardening procedures
Separation of the development (where you’ll continue to create and innovate as well as test) and production
We then recommend you test the site against your requirements to make sure they were met (best to do that before that last check goes to the developer!). We also suggest you conduct a vulnerability scan against the site to make sure that it wasn’t developed with technical weaknesses a hacker could use to create havoc for you.
And then finally we recommend that you, as a matter of routine, continue running those tests to make sure the sight maintains the secure posture you paid for in the first place.
The team spent the day yesterday working through the creation of version 2.0 of Jacadis' HIPAA - HITECH workshop. As we worked through the deck I had a couple of "Ah ha!" moments come back from my original research.
The biggest of these was the fact that with HITECH's breach notification provision a Covered Entity must manage the breach notification process even if the breach was the result of an event at a Business Associate. )
According to the Ponemon institute, the average cost of a breach in the US in 2009 was $204 per record (Source Report: Global 2009 Annual Study on Cost of a Data Breach ). In the case of a breach the BA informs the CE. The CE then handles the response, including the implementation of the necessary notification steps which are determined by the size of the breach. That $204 is largely driven by clearn up and notification driven expenses. That means that the potential impact, particularly the impact of a breach for a BA that handles a large amount of a CE's PHI, is potentially enormous, and for smaller practices, potentially enterprise threatening.
Given the AH HA! I would recommend that CEs assemble the security or compliance committee and review the risk represented by their population of BAs covering the following questions:
Do we have the proper BA contracting in place?
Are our BAs aware of their changed obligations to HIPAA under HITECH?
Do we trust them?
Can we trust them but verify their compliance?
Do we verify with on site audits?
Do we verify with them self assessing and then attesting to the results?
How do we handle failed audits?
Do we have an incident response and breach notification plan in place?
Does our plan include the potential for our need to react to a breach at a BA?
Have we table top exercise tested the plan?
Typically, our HIPAA and HITECH conversations are finding that CE's don't have their own incident response and breach notification house in order. My fear is that many are operating "knowing" the HITECH change but not operationalizing it. They know the BAs are responsible but they haven't considered the risk or impact of a breach at a BA. The cost of considering those impacts after their first breach is going to be much higher than starting to deal with them now.
We are now offering a HIPAA - HITECH workshop to our customers and prospects that have HIPAA compliance concerns. We've learned some valuable lessons through the workshop creation and delivery process.
We created the workshop because -- even though we offer a set of services and safeguards that would solve almost any HIPPA regulated organization's compliance challenge -- most of our sales conversations around the HIPAA topic were starting with an "I don't know enough ... " in the client's introductory paragraph.
Our sales team kept reporting the difficulty these Privacy Officers and Security Officers had in having a conversation about our offered solutions because they didn't have the knowledge they needed to do their job. This is especially true in mid-sized CE's, small practices and many BA's. The assigned PO or SO (many times only 1 person) position was an add-on to a full time job that was already a challenging 40 hour week before the HIPAA add-on.
Not counting extra blog related reading, direct client work and vendor partner related HIPAA reading I have about 120 hours into the HIPAA - HITECH learning experience this year. And my learning has come on a foundation of 10-plus years focused on security and privacy.
The biggest risk to most organization's HIPAA compliance is the knowledge that the PO and/or SO can gather given constrained time and training budgets.
Our workshop covers the learning areas that we see lacking in those we are trying to help:
Module 1: HIPAA - HITECH overview, because frankly there are a number of misunderstandings about HIPAA itself all these years in, not to mention the additions and adjustments from HITECH
Module 2: Information Security 101, because while HIPAA largely uses the established information and privacy jargon, most PO/SOs don't have a working knowledge for the basics like confidentiality, integrity, availability, risk, threat, vulnerability, authentication, authorization, etc.
Module 3: Privacy Rule because again the rule isn't universally understood by those charged to implement it in CE's and BAs or their management
Module 4: Security Rule because again the rule isn't universally understood by those charged to implement it in CE's and BAs or their management
Along with the learning in the second two modules we go through through a privacy rule and security rule gap assessment to detail where the client is non-compliant. We do it in a group setting with PO, SO, management, IT (if it is someone different) and others involved in managing PHI or PHI processes.
In the workshops we've done to date there have been moments where the process of doing the facilitated self-assessment brings a moment of clarity to the table. Management thought something was being done. The PO or SO says, sure we have the policy, but you didn't fund the safeguard, so we aren't compliant with HIPAA or our own policy.
As you know, I'm a huge advocate for a management level information security steering committee. These gaps in knowledge and gaps in understanding that ultimately feed a gap in compliance only get cleared up when those that are responsible for security and privacy from funders to doers can learn and coordinate in a regular fashion.
We are finding that our workshop is a clear step in helping create the foundation for that ongoing focused committee structure.
Do you have a working security steering committee? How is it helping you building understanding for security and privacy? is that understanding translating into a more secure organization?
Information security compliance continues to motivate conversations with new and prospective customers. Customers more and more realize they can be secure without being compliant. Many times that lesson comes on the tail end of a failed audit, new regulation or new customer request. They then call us for help because showing compliance reduces a cost, maintains a client relationship or opens a new opportunity.
Typically, regardless of the alphabet soup (HIPAA & HITECH, SARBOX, COPPA, PCI DSS, FERPA, etc.) that the client is struggling with the reasons for the compliance failure boils down to a consistent list of Administrative and Technical failures.
The administrative failures impact compliance in manner more pronounced than the technical failures. Administrative failures generally mean a lack of prioritization within the security program. A technical security staff can only do so much without management and leadership providing direction.
The typical administrative failures include:
Information Security Program Management and Governance:
Security programs (read operations) are not formally managed as are other business processes within an organization so there is a lack of centralized, coordinated effort.
Security programs are paper only with a documented organization, steering committee charter, policy and procedure. But that program fails under the inspection of an auditor who wants to see committee minutes and proof that policies and procedures are in place.
Data Protection:
Information is not classified or controlled based on its value or the risks to its confidentiality, integrity and availability. Without that priority security investments are spread evenly over the entire organization rather than being focused on the most critical assets. And then the company softball team schedule is protected at the same level as the secret sauce, the general ledge, the customer list and the historical credit card transaction database (do you even need that last one?!). Which means you are either spending too much or not enough.
The company operates by handling critical, often times protected, information without any or at least without adequate handling procedures. Information is exposed through the normal course of the day because your employees "just doing their jobs" are doing them in a way that exposes you and your customers.
Security Awareness:
People are a critical link in the security chain and in the compliance chain. If we don't tell our teams what is important to protect, why and how, they will work in a non-compliant fashion and expose themselves, you and your customers.
Technical issues are generally tied to the administrative, programmatic issues above. If the company understood the risk of operating in a non-compliant fashion they would make the technical investments necessary. But because the administrative / management side of the equation is not in the know the technical team can't make the case for required controls. Typically we see the following controls shortcomings in a failed compliance conversation:
Technical Architecture or How Your Computers and Network are Set up to Work Together:
Architecture does not account for critical data. Architecture does not account for specific compliance requirements. Architecture is old and outdated. Baseline protections, or those considered absolutely necessary to protect a company such as strong passwords, anti virus, firewalls, and the like are missing or out of date or poorly managed.
Visibility:
Neither event logging and aggregation or intrusion detection is in place meaning the organization doesn't know what is normal or when something abnormal is happening. Most compliance constructs include some level of expectation for basic visibility for network activity.
Similarly, vulnerability management tools are not in place so technical staff doesn't have a tool-set to help them keep track of weaknesses that may creep into the network or the systems on it.
Data Protection:
Going hand in hand with architectural weaknesses many times we'll find companies made investments in technologies that include security features but didn't turn them on. With little to no investment both security and compliance can be improved IF these features are turned on. This includes basic logging through syslogs on systems, more complex logging in applications, firewalls built into operating systems that aren't turned on and use of strong passwords.
Is security and compliance on your management radar? On your customers'?
This post is a quick note for those of you who serve children online as
audience members of your websites, either intentionally or unintentionally.
The FTC announced an
extension of the public comment period for COPPA Rule Review until July 12,
2010. If you are familiar with COPPA you may want to take this
short window to comment; if you aren’t, and include minors under 13 in your
online communities you may want to take the time to familiarize yourself with
COPPA.
For those that don't know COPPA, it is the Children's Online Privacy
Protection Act of 1998, a US federal law.
According to the FTC web site:
Congress enacted the Children’s Online Privacy Protection Act (COPPA), 15
U.S.C. §§ 6501-6508, in 1998. COPPA contains a requirement that the Federal
Trade Commission (FTC or Commission) issue and enforce a rule concerning
children’s online privacy, which the Commission did in 1999. The Children’s
Online Privacy Protection Rule, 16 C.F.R. Part 312, became effective on April
21, 2000.
Under the act “operators covered by the Rule must:
Post a clear and comprehensive privacy policy on their
website describing their information practices for children’s personal
information;
Provide direct notice to parents and obtain verifiable
parental consent, with limited exceptions, before collecting personal
information from children;
Give parents the choice of consenting to the operator’s
collection and internal use of a child’s information, but prohibiting the
operator from disclosing that information to third parties;
Provide parents access to their child’s personal
information to review and/or have the information deleted;
Give parents the opportunity to prevent further use or
online collection of a child’s personal information;
Maintain the confidentiality, security, and integrity
of information they collect from children.
In addition, the Rule prohibits
operators from conditioning a child’s participation in an online activity on
the child’s providing more information than is reasonably necessary to participate
in that activity.
Though we've touched on COPPA in the field when we've worked on assessments and governance formation within the higher education sector, I've not had much direct field experience with COPPA. Here are some articles online that helped me understand it, its implementation and limitations:
COPA vs. COPPA and the U.S. Supreme Court (January 29th, 2009) by Steven Leung. Leung quotes n FTC press release that says that “there is potential for
age falsification on general audience websites, as well as liability
under COPPA, should these sites obtain actual knowledge that they are
collecting, using, or disclosing personal information from children
online.”
As a parent with 3 boys 13 or under this was an interesting topic.
As a risk management perspective I recommend that you consider whether you have any exposure to children that age group using your online properties. If you do, you'll want to plan on how you can reduce your risk in regard to COPPA.
It isn't about the systems but the information .. ask yourself "What information can my business not afford to lose" ... and then protect it!
So much of my day is filled talking to executives or senior level managers who are trying to translate technical security concerns into their business frame of reference. For them stepping from a world of comfort in business lingo into a jungle of technology jargon speak is painful.
If that is painful for you I have a suggestion.
Turn it around.
Take out a legal pad.
Write out your key information or processes.
Rank order them from most critical to least critical.
Start with the most critical.
Test its place on the list. Could the business survive without it for a day? a week? Would the business survive but be worth less? How would it impact your organization? customers? bank accounts and available cash? regulatory obligations?
What are you doing to prevent that bad event from happening?
Could you detect it if it did happen?
How would you respond when it does happen?
You may need to call on your IT manager, your CPA, your lawyer, HR and other managers internal to your company to get the answers to these questions. These conversations may raise other questions you can't answer internally.
You may need to find an outside firm to assist with those tougher to answer questions.
Once you are confident the questions about that first piece of critical data has been answered go to the next item on the list and repeat until you have a sense you know what needs to happen to secure your critical data.
Insurance (Photo credit: Christopher S. Penn)
