Last week I gave a Lunch and Learn Presentation to a group of business people and enterpreneurs at the Dublin Chamber of Commerce on Living Securly in a Digital World.
Researching the topic for fresh material I tripped across a Unisys study that shows a disturbing gap between what employees and what employers think about data use in the enterprise:
While 67% can access non-work-related websites only 44% of employers agree.
While 52% of workers say they can store personal data on the company network only 37% of employers agree.
Do you have that same perception gap in your company?
As an employer it may mean behaviors you don't want, non-productive sites visited during work time or worse, malware introduced into the company network. As an employer, it may also mean extra storage costs or extremely awkward moments during terminations (can I have my data back?!).
As an employee, it may mean a disciplinary action for what you think is approved or allowed behavior. And more importantly it might mean loss of personal data an information if you lose or leave your job (or the company closes).
It is in the best interests of both sides of this divide to close the gap.
Few small business owners and entrepreneurs WANT to talk about policy. Most of us want to focus on our customers or our craft. But the hard truth is writing down our values and our key processes is a way to secure value in our enterprise and provides a foundation for growth. As you grow, well written, well thought, well communicated policies and procedures provide the foundation of consistency. Inconsistency is a key drag on growth.
Considering the explosion of smart phones and tablets in our lives it is relatively few small businesses that don't have key employees managing key functions and crticial information on these compelling devices.
Policy is important because it answers two key questions:
What is permitted?
What is prohibited?
It also puts everyone in your company on the same page.
Depending on how you develop policy in your business the creation process provides some key benefits. If you take the command position and develop policies on your own for communcation to your team in a top down approach going through the process of documenting your thoughts will force you to consider issues that likely would get missed if you just verbalized your thinking. If you use a more collaborative style assigning the leg work to a committee of staff you have the ability to align everyone to the problem and gain support and agreement for the final policy. Neither way is correct. In my business I sometimes take the command approach and other times take the collaborative or consensus approach.
Policy also allows you to confirm that your use of mobile devices conforms with regulatory practices as well as leading standards and practices in your industry and others.
And finally it allows you to have consistency in your actions. It is too easy in a small environment to create imbalances by providing extra benefits to some in the company that sometimes creates no benefit immediately and strife in the future.
A well thought mobile policy will consider:
Expectation of privacy -- What is the employee's expecation of privacy?
Employee-owned devices -- Do employee owned devices fit into your business? If so, how do you manage them?
Approved (supported) devices -- What devices are permitted? What devices are prohibited? Are you going to support all devices or a limited subset of those avaialable on the market?
Installing apps -- Are apps permitted? Does the company pay for them?
Jailbreaking / rooting -- Jailbreaking or rooting is, in a nutshell, breaking the warranty and setting up the operating system to your own liking rather than to the liking of the device manufactor. In some cases it makes the device more useful. In other cases it makes the device more fun. Do you allow jailbroken or rooted devices on your network?
Incident response -- How does the company respond if a device is lost? the employee?
Training -- What training needs to be provided to the employee to promote safe and secure use?
Sign-off -- Make sure your policy has a sign off for users to acknowledge acceptance of your policy. That accepted document needs to go into each employee's personnel file.
Restriction to certain data for smartphone users -- can smartphone users access everything on your network? Or are they restricted from some systems?
Termination procedures / device recovery -- when an employee moves on how do you manage recovering the data on the phone?
Your mobile device policy may impact other policies. If you've done a good job of writing information security and privacy policies for your business you need to review those other policies for linkages or impacts. All your policies need to be consistent.
We see these policies most often impacted by mobile device policies:
Update Related Policies
Acceptable Use
Asset Management
Remote Access / Mobile Computing
Security Incident Response
If you are conducting business as a supplier to larger, regulated businesses these policies may be reqired to maintain your business relationship.
Jacadis helps businesses prepare and respond to security questionnaires and audit requests from their usually larger customers. We also are the audit and assessment team for some firms who choose to use external resources to review their key vendors' security.
Frankly, as breaches Epsilon isn't a big of deal. No protected information, just names and email addresses were taken. And more sophisticated attacks have come and gone in the press largely unnoticed.
Epsilon has received more attention than the more impactful breaches in part because it touched so many people. Non techies are talking about it. We believe that buzz is going to find its way into the executive suites and audit teams of big companies and boost the rigor and frequency with which larger firms test, prod, and assess their supply partners.
Experts suggest that companies that outsource technology services take some of the following steps:
Make sure the vendor has a recognized certification for information security, such as ISO 27001 or SAS 70 Type 2, granted by an accredited auditing organization such as the International Standards Organization;
Sign agreements that oblige vendors to undergo regular audits by third parties, at least annually. Auditors should test software (especially software that can be accessed via the Internet) and hardware as well as people, to ensure that vendors’ employees themselves don’t fall prey to scams;
Make sure vendors assume liability for breaches that affect customers and end users; and
Make contingency plans with the vendor so that neither is caught by surprise in the event of a security breach.
Management consultants and corporate governance experts are providing similar advice to their Fortune 2000 and similarly sized customers. These recommendations have been around for several years, however, the buzz from Epsilon has the potential to fuel the recommendations to reality.
This will impact you if you answer yes to any of the questions below:
Your business is part of the supply or services chain for larger regulated firms. We see most of the third party verification activity from firms that have regulatory obligations to HIPAA; PCI, GLBA or other financial privacy rules, or Sarbanes-Oxley. We have seen these type of firms apply the highest security and privacy standards to their vendors even if their vendors don’t process confidential or protected information. Do you provide services to these types of firms?
Your business provides a service that includes considerably volatile information. If, for instance, you process non-protected personal information but it is somehow seen as critical to your client’s business or it’s relationship with its customers this might apply. Or, if, for another instance, you process company confidential information such as trade secret related information. Do you provide services to these types of firms?
Firms in the supply chain stack. You may not be doing business with a regulated firm, but you may be providing services to firms that provide goods or services to firms that provide services to regulated businesses. You know what they say about it rolling downhill. Are you at the bottom of a supply chain?
Take action
If you answered yes to any of those questions we suggest the following:
1. Look at your customer agreements with firms in the categories above.
Do any of those agreements place obligations on your company to protect your client’s information in a certain way?
Do they have the right to audit?
Have you told your IT team about these obligations?
Are you prepared to meet these obligations?
2. Sit down with your technical leadership and discuss:
Are we secure? Vulnerable? Do we follow a best practices approach to information security? Which one?
Do we routinely check through tests, assessments, and/or audits our answers to the questions above?
If we got an auditing letter from an existing customer would we be ready for the audit in a week? a month? 3 months?
When the auditor arrives do we have documentation that defines our security programs values (policies), details the routines we follow to meet those values (processes), shows that those routines are being followed (logs, action reports, scorecards, etc.) and that our staff is aware of their obligations (awareness training)?
If we committed during the sales process with a new customer to do certain things to secure their data did IT and the others in the company responsible for delivering on that obligation have a hand in the answer? Are we overcommitting?
Are we managing security well enough that we can create a competitive advantage over other firms in our class? Can we use that advantage to build new business?
If your business provides business to regulated businesses upstream in your market we recommend you keep asking these questions until you feel comfortable with the answers.
If you have formed an information security steering committee (or call it a governance committee, security working group or other similar name either to meet compliance or contract issues or because it is a leading security management practice you may have the committee version of writer's block: "We are all here. What do we do next?"
Last week I helped a client kick off their steering committee. After a quick training session on Information Security 101 and Security Govrnance 101 we as a group discussed the following openly:
How do we organize for infromation security governance?
What is the committee work product?
Do we keep minutes? Detailed minutes or just a summary?
We publish policies? What else do we do?
How do we, as a committee, develop, adopt and publish policy?
As a cross fucntional committee where do we do our work?
How do we raise awareness within this group that information security is important? Within the company?
Does everyone here agree they have a role on this committee?
There's a lot of material on what the answers to these questions SHOULD be, but discussing them provides a great learning moment for a new committee. And while I use much of the available literature to help guide my work in assisting customers in forming committees I've found that each company's cultural uniqueness can be acommodated within those leading practices.
Simply talking about "what do we do now" is a great ice breaker to get the committee aligned and moving forward.
We are presenting a free lunch and learn on "Dangers of Social Media and How to Stay out of Trouble" at the DEC in Dublin on August 5th. I last gave this 5 months ago. In a realm where the velocity of change is unprecedented much has changed. Logically, as I work to refresh the presentation deck, I'm discovering some interesting new facts and updating my knowledge on older ones. Here's a sampling:
A January Manpower survey, Social Networks vs. Management? Harness the Power of Social Media showed that 75 of employers do not have social media policies. Having policy to guide and direct your employees is necessary. Having a personal policy is also in my mind a must, too. "Policy" strikes most as some thick document that gets written and put on a shelf to gather dust. We'll discuss how policy can be used to great effect and not just take up shelf space.
Complaints to the Internet Crime Complaint Center are on the rise according to an article by the Wall Street Journal, Hackers Aren't Only Threat to Privacy. The article goes on to highlight a rule of thumb in the security industry that doesn't have much awareness among general users: it isn't just hackers that put your, your company's or your customers' protected data at risk. We'll discuss those threats and what to do about them.
If you haven't registered yet, we still have room. If you can't make the 5th we have other ways to deliver the content. Let me know.
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.
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.
A formal, routine, active information security steering committee is the foundation of many compliance requirements.
We work with emerging businesses to help them secure their networks and to operate within the requirements of an alphabet soup of compliance requirements (PCI DSS, HIPAA, FERPA, ISO 27001, etc).
When we are first called in the client is usually reacting to a request from a prospective client (or sometimes an existing client in the midst of a security program upgrade of their own) to show that they are secure.
The typical scenario is a small business, generally growth oriented, usually in a B2B vertical, sometimes technical, sometimes not. The typical client in this space provides some level of service whether it is software, an outsourced business process or some client other client oriented service that requires critical business information to operate.
Their customer is generally a larger firm, regulated by multiple regulatory obligations. They have a requirement that my client respond to RFP questions, open themselves to an audit or otherwise show that they are secure.
We get called when they fail or when they are fearful of failing and as a reaction are willing to make an investment under fire to win – or retain – the customer.
More often than not the key missing component is that lack of a centralized, coordinate security program, what we call in the security and audit world, a governance program. We see one of three conditions:
The company does not have a formal information security program (management structure) so the company relies on its technical staff to make both business and technical decisions about protecting the information the company relies on.
The company has a paper tiger security program with an assigned committee, documented policies and no real operational framework. The company says it does something it does not do.
The company has a security program which meets on a regular basis but its meetings are largely without agenda or direction or, after interviewing its members, purpose.
In the end, with a new deal or the continued relationship with an existing client, is on the line because the company is not organized to manage security issues at a business level.
Is your business similar to our “typical” profile? Do you sell services to larger, regulated firms? If so, do you have a working functioning information security program? Will you program as documented and managed stand up to the rigors of an audit?
Some questions to ask:
Are we organized to operate in a compliant state with rules and regulations we are obligated to meet?
Does the information security steering committee include an executive C-level sponsor? Does that assigned executive attend the meetings and participate?
Does the committee meet on a regular, routine basis? Can you prove they meet?
Do you document its proceedings?
Is the action of the committee improving the operation of the company? Its security program?
Is the committee measuring our performance against the following questions?
Are we administering (business processes) routinely in a manner compliant with rules and regulations we are obligated to meet?
Are we operating (technical environment) routinely in a manner compliant with rules and regulations we are obligated to meet?
Are users behaving in a manner compliant with rules and regulations we are obligated to meet?
The Federal Trade Commission (FTC) announced yesterday Twitter's settlement against charges that Twitter "deceived consumers and put their privacy at risk by failing to safeguard their personal information."
In a non-technical pedestrian manner David Vladeck, Director of the FTC’s Bureau of Consumer Protection boils it down in this quote on the FTC site:
“When a company promises consumers that their personal information is secure, it must live up to that promise. Likewise, a company that allows consumers to designate their information as private must use reasonable security to uphold such designations."
Twitter was hacked twice, once in January, 2009 and again that same year in April. And during that time period Twitter's privacy policy stated that:
"Twitter is very concerned about safeguarding the confidentiality of your personally identifiable information. We employ administrative, physical, and electronic measures designed to protect your information from unauthorized access.”
Twitter had borrowed some of the language from another firm's privacy statement (how did your privacy statement get written?).
The FTC acted under Section 5 of the FTC Act which gives them the power to hold firms accountable for "unfair and deceptive" practices. The deception here is that Twitter publicly proclaimed it did something that in fact it did not do.
There were no monetary fines levied. According to legal friends of mine this is due to the fact that Section 5 of the FTC Act does not grant the FTC the power to levy fines or penalties.
Again, according to the FTC:
"...Twitter was vulnerable to these attacks because it failed to prevent unauthorized administrative control of its system, including reasonable steps to:
require employees to use hard-to-guess administrative passwords that they did not use for other programs, websites, or networks;
prohibit employees from storing administrative passwords in plain text within their personal e-mail accounts;
suspend or disable administrative passwords after a reasonable number of unsuccessful login attempts;
provide an administrative login webpage that is made known only to authorized persons and is separate from the login page for users;
enforce periodic changes of administrative passwords, for example, by setting them to expire every 90 days;
restrict access to administrative controls to employees whose jobs required it; and
impose other reasonable restrictions on administrative access, such as by restricting access to specified IP addresses.
Under the terms of the settlement, Twitter will be barred for 20 years from misleading consumers about the extent to which it protects the security, privacy, and confidentiality of nonpublic consumer information, including the measures it takes to prevent unauthorized access to nonpublic information and honor the privacy choices made by consumers. The company also must establish and maintain a comprehensive information security program, which will be assessed by an independent auditor every other year for 10 years."
Again, according to my legal friends that means that Twitter is now in a spot that should they fail to fulfill their part of the settlement the FTC may find them in contempt of the settlement which then would permit the FTC to levy fines and penalties.
There is plenty of debate in the security blogosphere discussing whether or not the FTC "went too far" or was legislating by regulation.
For me the important element of the case is the lesson for other growing and emerging businesses.
Twitter has grown more rapidly than they could have known when they started up. As the subscriber based sky rocketed, however, the start up culture that is more feature focused than formal process focused carried onward. One of the hacks was because a dictionary word, easily guessed, was used to protect an executives Google Applications account. A dictionary-based password can be guessed easily especially if you know the person who owns it. Strong passwords are the foundation of information security. If a company isn't using strong passwords we question their commitment to security. Ultimately that lack of commitment is what got them.
Here are some lessons to consider:
Start security and privacy planning with business and application planning and design from the beginning. That is particularly true if your key processes involve confidential, consumer or protected information. The cost of doing security later will be much higher because you'll have to re-engineer. Metaphorically it is similar to adding a basement after your house is built.
Likewise, include information security, privacy and trust considerations in your culture early on. Technology, difficult and expensive to re-engineer, is easy in comparison to restructuring a company's culture. You can operate securely and create a loose modern team oriented culture. Focus on the customer trust issue as a rallying point rather than the constraints you feel security places on you.
Plan for your future value from the get go. Twitter's apparent laissez faire attitude toward information security and privacy earned them a 20 year dance with the FTC. It also puts a mark of toxicity on their value. If I had the money laying around to purchase Twitter would the potential of an historical lapse in security or the potential for one in the future, either of which would spawn a contempt finding and financial penalties, give me pause or give me leverage to reduce my offering price? Understand now how a breach or poorly architecture might impact your future value and work with that in mind.
Don't cut and paste privacy statements or other statements of values or customer trust from other sites and call them your own. Get an attorney or a privacy professional or both engaged in your developing your privacy policy. That policy is a sign of trust for your customer now. But poorly executed it could be a weapon used against you in the future. And as you work on developing that policy remember it is a legal and technical document and not a marketing brochure.
Finally, don't say things you don't mean or that you can't back up. Be honest. That should be true in all your business dealings as a start up or emerging firm. Customers purchase trust.
Have you built security into your culture and technology from the start? Working on it now?
Social media security and risk management is a business and communication policy issue NOT a technical issue. Assign responsibility to a business leader and not IT or information security staff.
This week at the Gartner Group's Security and Risk Management Summit, Gartner research
director Andrew Walls dropped a contrary statement on the heads of the information security and risk management employees in his workshop. Summarized (from reports on his presentation available on the Internet) he asserted that:
Information security professionals worried about malware, phishing, and information leakage who try to take control or block social media use by employees are treading into water that is similar to monitoring employee's home use of the telephone.
The malware, phishing and other attacks against the social media front are the same attacks that we see against email. Logically, if we are going to block social media why are we not considering blocking email? (NOTE: Because we need it to run and grow our businesses).
At the root of concerns about social media are concerns about its drain on employee productivity. Employee productivity is not a charter concern for information security. It is a management issue.
While the information security and risk management blogosphere lights up with arguments about whether Andrew Walls is on target or off his rocker I wanted to bring the discussion into the realm of the entrepreneur and emerging business management professionals.
I think Walls is dead on.
Too many times I see a communications topic or business process topic turned into a technical topic because it involves technologies unfamiliar to the business manager.
Twitter, Facebook, twits, followers, friends, fans, Zemanta, wiki, widgets .... and so on sounds technical and something the CIO, IT manager or that smart young kid on the help desk should be working on.
But if I boiled it down to communications channels (Twitter, Facebook, LinkedIn, etc.), conversations (twits, posts, etc.) and customers (followers, friends, fans) you could have the conversation. And you'd want to have the conversation if not control it altogether.
Though Walls' message was to information security and risk management professionals managers and leaders in the small and emerging business space need to get it. The decision about social media is a business decision not a technical or a security decision.
Here are some questions for discussion to help guide you in making that decision:
What conversations are appropriate for employees to be having with customers, prospects and the market in general online?
What topics are out of bounds?
What information is considered secret, private and confidential?
What information is regulated by government entities? How does that play into your social media policy (e.g. a doctor's office that allows friend connections from patients may be violating HIPAA)?
Can employees identify themselves as an employee of the firm?
Does that identification obligate them to certain behaviors? If they don't identify themselves as an employee does that expand their freedom?
How do you handle breaches of these policies?
What else concerns you about social media?
Document your answers into a policy statement. Formally share that statement with your employees. Assign ownership of the policy based on which business unit makes the most sense (IT to monitor use on the company network, HR to manage discipline of violations, marketing or IT to monitor your brands exposure in online conversations, IT or information security to manage endpoint controls that help protect against malware, etc.)
And then use social media to run and grow your business.
