Jay Heiser
Research VP
6 years at Gartner
24 years IT industry
Jay Heiser is a research vice president specializing in the areas of IT risk management and compliance, security policy and organization, forensics, and investigation. Current research areas include cloud and SaaS computing risk and control, technologies and processes for the secure sharing of data… Read Full Bio
by Jay Heiser | December 23, 2011 | 2 Comments
I’ve reviewed three different policies so far this month, all of which contained the a similar requirement that users not write down their password. How counterproductive is that?
It is impossible to impose any level of password complexity and regular expiration, without expecting that the password holders write the things down for reference at least until they’ve memorized the new password. Demanding that users not write down their passwords is a quarterly opportunity to send the message that security policy is a useless bureaucratic exercise.
One thing that I have not seen popping up in security policy is a requirement that users not use the same password for the multiple unsynchronized systems that are inevitable within an organization of any size. Including work-related eZines and a memory stick that disappeared years ago, I’ve got 30 different Gartner ’accounts’ and passwords stored in my personal password database. That database has over 200 secret authentication strings stored in it, which leads to the point of today’s blog, that corporate password policies should forbid the use of ‘home’ passwords on corporate systems.
The reuse of passwords across multiple accounts is a well-recognized phenomenon within the security community (even security specialists have stumbled into self-imposed cascading password exploit incidents). Multiple published studies indicate an unfortunately high level of password duplication. While most people intellectually recognize this as the case, I’m not sure how many have fully understood the implications. The use of the same password for multiple accounts represents a single point of failure, in which the (dare I say lazy?) actions of an individual can result in multiple simultaneous failures.
I recognize the impracticality of preventing the shared use of passwords on both personal and employer systems (I won’t suggest that corporate surveillance tools could easily identify the majority of personal passwords, given the number of people who access FaceBook and gmail from work). Even though it cannot be reliably enforced, I see nothing but advantage in encouraging employees to avoid reusing passwords.
PIN and password proliferation is one of the unfortunate and virtually insoluble challenges for the digitally active individual. I try to maintain unque passwords for several hundred systems, and my dependence upon several synchronized copies of an encrypted password store is only one of the several inconveniences, and I am not recommending it. I do recommend that until we have widespread availability of a stronger mechanism that scales to dozens of corporate sites, and hundreds of personal sites, individuals should try to perform a degree of password proliferation.
Enterprise policy writers must recognize that only a small number of humans have photographic memory, and the proliferation of accounts and passwords, and the frequency of changes, dramatically increases the number of random strings that need to be protected. Memorization is impossible. Instead of telling users not to write down their passwords, ask them to treat passwords as carefully as they treat their own money.
Category: Cloud IT Governance risk management security Tags: passwords, policy
by Jay Heiser | December 14, 2011 | Comments Off
I review a lot of corporate security policy material, and it is the rare organization that doesn’t have an ITsec policy statement amounting to “all employees must obey the law.” Well, yes. I reviewed one today that managed to get this point across 4 times during the first page and a half, a remarkable achievment for a 2 page document.
Its easy to imagine where this nearly universal policy compunction comes from. In a legalistic society, the Simon Says Rule, and its inverse, trumps all other considerations. When it comes time to fire someone, its just so much easier if they can’t use the Simon Didn’t Say Rule to claim “you didn’t tell me I wasn’t supposed to break the law.” It is ironic that the legal field puts such emphasis on the reasonable man standard, given that so much of what happens in law defies common sense. To loosely apply the reasonableness standard in this situation, would there not always be an expectation that a reasonable person would consciously obey the law?
Even worse is a policy statement such as “all employees must obey all applicable laws.” What reasonable person could disagree with that? I would. That is tantamount to telling your employees “we will not tell you what specific laws you must follow as part of your job, let alone how to follow them, but if you do not, then we will punish you.” If your own organizational lawyers can’t specifically state what individual legal responsibilities are, why should there be any expectation that non-lawyers will be able to do so?
Vague and unactionable policy, full of ambiguous legal language is a corporate cop out. If you want your people to do the right thing, you must give them sufficient guidance such that they know what that thing is. If you want people to avoid doing certain classes of act, then you must provide sufficient details such that they can reasonably know what they must not do. A policy requiring employees to “do everything we should have thought of but didn’t” is a weak policy that will have virtually no impact on reducing risk.
Category: IT Governance risk management security Tags: law, policy, security
by Jay Heiser | December 1, 2011 | 1 Comment
I heard a story on the radio today about an old man who had donated an overcoat to charity, forgetting that one of the pockets contained his life savings. It seems that he was one of those people who are uncomfortable with the idea of trusting their money to a bank. Its been suggested more than once that avoiding public cloud computing is tantamount to keeping your money in a mattress. Given what’s happened over the last 4 years, why would anyone automatically assume that the use of banks represents a low level of risk?
The history of banking has been checkered with countless failures. Many people and many institutions have been ruined when their financial institution failed. Today, in many parts of the world, your money is safer in a bank than it is in your mattress, but this is a recent and unique situation in the several millenia evolution of the banking sector. Banks were not really ‘safe’ until risk transference mechanisms were developed in the 20th century, and only national governments had the ability to underwrite the risks, insuring individual deposits and in some cases, intervening to ensure the economic viability of a major bank. Given the European debt crisis, this seems a particularly apt time to question the relative advantages of mattresses and banks.
Banks are highly-regulated institutions and their customers can rely on multiple forms of government intervention, and consumers can rely on government insurance to prevent the complete loss of deposits. Bank customers benefit from huge levels of transparency. In contrast, clouds are a brand new form of depository institution with minimal transparency, no risk transference mechanisms, and no expectation that national governments consider them too big to fail.
In practice, moderately-skilled private individuals, let alone small to medium business, are able to provide an in-house IT service that far exceeds the reliability of a mattress as a piggy bank. Individuals have no ability to create duplicate copies of cash, but data can be easily backed up and stored off site. Cash must be physically protected from theft, but data can be encrypted. The suggestion that the avoidance of public cloud computing is tantamount to keeping your life savings in a mattress is a deeply flawed one, if not an outright lie.
Category: Cloud risk management security Tags: backups, disaster recovery
by Jay Heiser | November 28, 2011 | 2 Comments
With the understanding that I am not a lawyer, and Gartner is not a law firm, here’s my brief summary of the contractual language dealing with SaaS security as provided by a prominent vendor:
- We believe that we obey the law. If there are any questions pertaining to how your data is handled within our system, it is YOUR problem.
- We won’t give your data to the police. Unless we do give it to the police.
- When this contract is over, you may have the ability to get your data back, but that is your problem, not ours.
- If one of your customers contacts us, we won’t give them anything. Unless we are forced to give them something.
- We will store the data in whatever country we want.
- We might have third parties help us with this, and they of course would be held to the same weak levels of standard as we contractually obligate ourselves to follow.
- You the customer are obligated to obey the law at all times, even if you have no idea what that may entail. (Guess what happens if there is a dispute with us and our lawyers can find some way to demonstrate that you didn’t completely follow the law.)
- We will follow appropriate security measures—as understood by us.
- We will back up your data at least once a week, we will review our procedures periodically, although this seems unnecessary, given that none of these procedures were knowingly designed to fail. If we have the slightest plan for testing our ability to recover, we are not sharing it with you and we hope that you won’t ask that question.
- If any of our support personal ever accesses your data, by definition, it is necessary access.
I make light of the sort of legalistic word games typical of SaaS contracts, but given the constant stream of complaints from Gartner clients about this form of service, who can blame me for being more than skeptical? If a potential buyer is looking for a contract that clearly protects their interests, and is presented with an inflexible document that, in highly obtuse language, spends far more time describing what the vendor will NOT do than what they intend to do, why shouldn’t buyers be frustrated? As long as enough buyers are willing to give money to a service provider on the basis of what amounts to that provider saying that they will try to do a good job, and without actually accepting any significant level of risk if they don’t, then who can blame them?
Category: Cloud Vendor Contracts risk management security Tags: disaster recovery
by Jay Heiser | November 17, 2011 | 2 Comments
In the Disney cartoon Dumbo, a misfit elephant discovers that his ears are so large that he has the ability to fly. Lacking confidence in this unusual capability, he is understandably reluctant to fully exploit it. His shrewed friends, a pack of crows, come up with an ingenious psychological ploy. They give him a single feather, explain that it has magical properties, and as long as he clutches it in his trunk, he will be able to fly. This ruse is wildly successful, enabling the young pachyderm to soar with the crows.
This story is compelling because it illustrates a common form of human behavior. Desiring to do something, and unfamiliar with the associated risks, we often latch onto talismans, superstitiously hoping that they will protect us from unforeseen disasters. We do the same thing in the IT world, vainly clutching contractual SLAs in order to gain the false confidence that it will enable us to safely fly in the public cloud.
A typical example is a security document I recently reviewed which explained how this particular enterprise could safely rely on a specific SaaS vendor to reliably protect, and if necessary recover, their data, because it was ‘protected by a high level of SLA’. AN SLA IS NO MORE THAN AN EXPRESSION OF INTENT; IT IS NOT EVIDENCE OF DELIVERABILITY.
I’m not saying that you should not seek very specific service level agreements in your contracts–by no means. What I am saying is that the mere fact that a vendor promises to do something does not mean that you as the buyer can rely on it to happen.
If your business depends upon having access to data or services that are hosted externally, then you need to either have a tested contingency plan that functions entirely independently of that provider, or you need specific evidence that the provider is not only reliably making offline backups that are consistent with your recovery point objectives, but also that they have a proven ability to restore your data within your time objectives.
I have to admit that I’m completely at a loss to come up with some sort of test which would reliably demonstrate that in the event that even a small part of their client data was lost, say a petabyte worth belonging to a couple hundred thousand digital tenants, that a service provider would be able to restore it within a few days. As a recent case in point for what was a minuscule disaster, earlier this year it took Google 4 days to restore what they described as .02% of their gmail users.
What form of evidence could demonstrate that a provider with hundreds of thousands of tenants, if not millions, could, after some sort of data-eating disaster, reliably restore that data from offline backups and link it back into the accounts and applications such that it could be used again by their customers? How long would it take for the highly-leveraged administrative staff of a cloud services provider to complete such an operation? Where in the recovery queue would you be?
An SLA from a public cloud service promising some sort of recoverability can be a crow feather, clutched in the trunk of the enterprise elephant, providing them the false courage to be willing to fly in the public cloud. I hope that this is not a lesson that your organization will have to learn the hard way.
Recent Gartner research on this topic includes ‘Black Swans’ Are Sure to Fly in the Public Cloud, and The Realities of Cloud Services Downtime: What You Must Know and Do.
Category: Cloud Vendor Contracts risk management Tags: continuity, contract, Dumbo, feather, recovery, SLA
by Jay Heiser | November 9, 2011 | 1 Comment
I have to wonder how many consumers truly understand that when they are paying money for rights-managed content that they have locked themselves into the future of a specific vendor. At best, this represents a lifetime relationship, and at worst, it represents the potential to lose years worth of music or books.
A perfect example would be this year’s business failure of the Borders book store chain. Borders offered an ebook service, and those who spent money to license this digital content now find that their supplier is missing. In the olden days, the business viability of your local book store had absolutely no impact on your ability to read whatever you might have bought from them. In the digital world, your continued ability to use rights-managed content, be it music, video, or books, is completely dependent upon the willingness and ability of a service to support it on your current device. You cannot access your purchase without the key to unlock it, and an application to consume it.
While most services download the key to whatever your initial consumption device is, be it a computer, a phone, a book reader, a tablet, or some other sort of player, there can be no reasonable expectation that this device will last for more than several years. Devices break, they are stolen, they become obsolete, and Windows requires periodic restoration. I’ve got 80 year old records that I can play, and 15 year old files that I cannot.
While many people are happy to only watch a movie or read a book once, I certainly am not the only consumer who has a large collection of books and movies that I expect to use for the remainder of my life (however long that may be). Books, LPs, and CDs are all relatively open, and in the unlikely eventuality that I can no longer purchase readers for either form of music disk, the migration path is simple, and entirely within my own control. In contrast, licensed digital media introduces two significant requirements for ongoing accessibility:
1) a license server willing and able to serve replacement keys to legacy customers
2) reading client software for new devices
Clearly, a bankrupt Borders is going to be unable to fulfill either of these requirements. In this case, the licensing agency had a minority stake in Kobo, which has apparently agreed to take on support for existing Borders customers (although they are actually being somewhat non-committal). In practice, this probably doesn’t represent a huge impact for Borders customers–at least for those who figure out how to transition to Kobo while the offer is still outstanding. What it does mean is that Kobo will be providing licensing and software support to some group of people who have never paid them for it, and in the future, may well never pay for any Kobo content.
I’ve experimented with both Microsoft’s media player and Apple’s iTunes, and found both to be quirky. Effective use of either means entering metadata, like ratings, that is probably not portable, so even without paying for content, the more you use one of these products, the greater the level of vendor lock-in you are creating for yourself. For those who’ve given up on CDs and LPs (yes, they still press these things), the lock-in stakes are much, much higher.
From my POV, managed content is a bit more convenient than going to the library, but its not something that can be counted on for indefinite availability. If I’m going to listen to a tune multiple times, or if I’m going to mark up a book with annotations and highlighting, I’m going to pay for an unlicensed copy that I can control.
Category: Applications Cloud risk management security Tags: DRM, rights management, vendor lockin
by Jay Heiser | November 2, 2011 | 1 Comment
Gartner has heard from several sources that SaaS-based contract management application provider Mumboe told their customers last week that they have 2 weeks to pick up their data before their cloud is permanently grounded. Law Technology News confirmed this on Oct 31, and evidence of a small feeding frenzy, at least 4 competing vendors have announced Mumboe migration services.
I suppose some customers will be grateful that they have been given an entire 14 days to pickup their PDFs and download a CSV text file of their contracting activities. Its easy to imagine a smallish procurement shop in which the only person to have been sent a warning was on a 2-week vacation, and won’t get around to reading about it until it is several days too late to download their only copy of several years worth of past and current purchasing data, so its nice to hope that Mumboe actually will burn and mail DVDs to their customers.
Some customers will feel pressure to take immediate advantage of offers from solvent competitors to migrate, and some will hope that they still have enough technically-savvy employees of their own to parse their data and stuff it into a new in-house database. Others will just stare at an unstructured pile of formerly structured data and will wonder just how they allowed themselves to become dependent upon a service that could disappear on such short notice. Perhaps some customers won’t get the word in time, or they’ll do something clumsy, and lose their only copy of important contract and procurement records.
In the boom and bust environment enabled by the low overhead of cloud-based SaaS, Cloud Rushes and Cloud Runs are inevitable. Fearing a sudden outward stampede of worried customers, SaaS providers are likely to maintain a smiling web presence right up to the bitter end. Although their web site contains no obvious signs of startup rundown, clues include a Twitter feed that hasn’t been updated since Sept 11, a content-free FB presence, a corporate blog that hasn’t had an entry for 2 months, and a sure sign of corporate apathy, 4 months without a press release. When a vendor goes under, don’t expect any significant amount of advance notice, and do not expect that any contractual commitments can be honored by a firm that has run out of money and staff.
If the bankrupt vendor’s app is running on one of your computers, you have plenty of time to figure out how to conduct a graceful transition. If you use a cloud-based service for important tasks or data, you MUST have a contingency plan in place. NEVER use a SaaS application without first considering whether you can afford its sudden disappearance. If your data is valuable to you, then figure out how you will get sufficient access to your data if the vendor is no longer able to provide it to you.
At Gartner, we’ve been suggesting for quite some time that procurement organizations need to develop new skills not only for the procurement of SaaS applications, but also for the ongoing monitoring of provider viability. This should be an example that resonates with the procurement community.
Nov 3: update
The Mumboe home page was finally changed last night:
Most of the links were removed from the home page, and a number of Mumboe pages, such as the press releases, are no longer available. In an ideal world, the status page would provide existing customers with information about where their data was, the plans for returning it and any data destruction plans. As of this morning, the following stale status is still online:
Nov 28 update:
At this point, www.mumboe.com is a dead link, and their twitter feed has gone away.
Category: Applications Cloud risk management Tags: cloud failure, continuity, data loss, disaster recovery, outsourcing, recovery, SaaS, vendor lockin, vendor viability
by Jay Heiser | October 10, 2011 | 1 Comment
What sort of security information should a buyer expect from a service provider?
In April, Google uploaded a marketing video to YouTube, Security and Data Protection in a Google Data Center. This 7 minute piece explains that interior doors are protected with biometric sensors, and that scooters are provided for the guards. Take a silent moment to try to visualize the sort of infosec security failure that would be solved with scooters. Is there some sort of Google security training camp where security staff are taught advanced scooter incident response techniques? Instead of Mall Cop Two, can we anticipate Google Cop?
Just before (and continuing after) Irene struck, Amazon’s AWS service health dashboard included the reassuring news “We are monitoring Hurricane Irene and making all possible preparations, e.g. generator fuel, food/water, flashlights, radios, extra staff.” Laying in some extra staff to temporarily beef up the inherently lean personnel of a cloud service sounds like a great idea, but shouldn’t a provider always have enough generator fuel to outlive unforseen power failures, let alone scheduled hurricanes? Why wouldn’t they always have some MREs on hand to tide their admin crew through a snow storm or civil emergency? How about a deck of cards, or a board game, too? Once they get to the point where they need flashlights and radios, the extra staff will need something else to do while waiting for the power and the Internet to come back up.
Taking a more minimalist approach, Dropbox is sticking with the marvelously ambiguous position “We use the same secure methods as banks.” Does that mean the same methods that banks use to prevent robbers from getting into your safety deposit boxes, or the same methods that UBS uses to monitor for fraud?
Best practice for determining if a service provider is fit for purpose remains an open topic. I do have some ideas on what a buyer should be told, and I’m confident that this sort of information is not it.
Category: Cloud risk management security Tags: BCP, Cloud, security, symposium, transparency
by Jay Heiser | October 5, 2011 | 1 Comment
I’m driving a four-year old car with over 50K miles on the odometer. It runs like a top, requiring only routine annual maintenance and a quart or two of oil. When I was a kid, a 3-year old car represented an ongoing maintenance hassle. Other than the quirky guy down the street with the 190D, anybody who wanted to avoid constant breakdowns got rid of their car long before mileage reached 6 figures. Autos are a lot more reliable these days, which is why my 4-year old wagon still has a more comprehensive power train warranty than was typical for new cars in 1965.
Makers of the first generation of cars were understandably reluctant to accept any risk associated with the use of their products. Ford offered Model T buyers a 90 day warranty on materials, and only a 30 day warranty on labor. A significant number of mission-critical parts, including belts, glass, plugs and gaskets, were explicitly excluded from the warranty. I’ve got my grandfather’s expense records from the late 20s: he went through tires like candy and visited the garage once a month for a tune up. The reduction in the reliability risk of vehicle usage is one of the profound achievements of the 20th century, explaining why auto sellers today are competing on their willingness to reduce buyer risk.
Vendor competition to explicitly accept product risk is not characteristic of the cloud computing realm, Like Detroit in 1925, today’s sellers are putting their lawyers on overtime to create lists of things that are explicitly not covered by warranty.
Unsurprisingly, I’m hearing lots of complaints from potential and current cloud service buyers that are disappointed about their unwillingness of their suppliers to share some of the risk that their product might malfunction and impact their customers. They naturally ask “If you truly believe that your product is reliable, then why wouldn’t you offer to share the risk of using it? If use of your service entails minimal risk, then you should have no reluctance to allow some of it to be contractually transferred to you.”
The truth of the matter is that the provider actually has no idea of the likelihood of a loss event within their own offering. Cloud service providers are painfully aware that leverage and efficiency cut both ways: if a failure occurred, it could impact all of their customers simultaneously. They don’t have enough cash on hand to cover that portfolio risk, and they can’t find any insurer willing to underwrite it. Don’t expect any 100,000 mile warranties any time soon.
Category: Cloud risk management security Tags: Cloud, contracts, risk management, symposium
by Jay Heiser | September 29, 2011 | 1 Comment
This week, I was forced to change my Gartner corporate password, and the password I use to access my online pay stubs. The latter was particularly aggressive in demanding a complex string that is impossible for me to remember. According to my password storage software, in the past 6 weeks, I’ve been forced to change 17 different passwords. Its nice to know that so many different institutions are working so diligently to please their auditors, but I have to wonder just how deep this security commitment goes. After all, what good is a fresh password if it is sitting on top of stale security technology?
We spend a lot of time evaluating the performance of security operational processes, but I often wonder if this isn’t a deliberate distraction, a sort of best practice figleaf meant to hide the fact that we often don’t know how secure the underlying code actually is.
Many of the seminal works on computer security were collected and scanned by a team at UC Davis and can be found online at NIST. If you spend some time reading through these documents, which date back as far as 1970, you’ll see relatively little concern about password complexity and aging. What you may well experience is a sort of déjà vu all over again, as you watch over the shoulders of the world’s top computer scientists and their struggle to identify and compensate for the innate security weaknesses of a set of networked shared-resource systems. A prime example of what goes around–goes around a lot–is James Anderson’s 1972 paper for the Airforce, in which he discusses the inherent shortcomings of the typical penetrate and patch process. The only thing that has changed in 40 years is the amount of penetration testing and patching. But it still remains a hit and mostly miss operation.
We keep applying vulnerability patches because we haven’t figured out how to make the code safe in the first place. This is not to say that we haven’t learned a great deal about security architecture, secure coding, and security testing. What we have not learned is how to reach any useful conclusion as to just how secure any particular piece of code is. In contrast to the 1970s, today’s architects and coders have a useful understanding of basic security principles. However, the threat and risk considerations for public cloud-based services are exponentially more significant than what confronted a typical 1974 mainframe.
Vendors are constantly asking us to use systems based on highly complex and unproven software. When asked how secure this code is, providers tell us that they have the best people, and that an auditing firm has evaluated their operational processes. Google brags that their security staff has scooters, a mall cop capability totally irrelevant to the attack resistance of their proprietary infrastructure. I’m afraid that history is going to get this one right. The integrity of your data and processes is dependent upon the robust design and careful coding of somebody else’s shared-resource network-based software. It might be great code, but the vendors struggle to provide useful evidence, and the buyers lack any agreed upon practice for code evaluation.
For the lack of any useful process for the evaluation of code risk, we are choosing instead to address questions that are relatively easy to answer, and pretending that the answers matter. Let the farce be with you!
Category: Applications Cloud IT Governance risk management security Tags: history, history of security, security history, security testing
