Ask Your Provider 2017-05-22T21:04:02+00:00

Questions You MUST Ask Your Security Provider (and Yourself)

(or “the questions Watson can’t, or won’t, answer”)

Print a copy of these questions for when you talk with your provider

Download
Is it protecting the author/developer/owner of the intellectual property embedded in a digital asset?

Or the interests of a third party browser, operating system, file system, server farm, or cloud infrastructure that knows and cares nothing about the specific security needs of a digital asset or its author/developer/owner?


Why it matters:

The priorities of an author/developer/owner of a specific digital asset and the priorities of a third party browser, operating system, file system, server farm, or cloud infrastructure are very, very different. The author/developer/owner invariably wants their digital asset as mobile as possible, distributed as widely as possible to all authorized users, and for those authorized users to have as unrestricted and seamless a user experience as possible consistent across all operating systems, file systems, and browsers. On the other hand, third-party browser, operating system, file system, server farm, or cloud infrastructure (Container-Related Asset Protection, or CRAP) security technologies restrict mobility, distribution, user access, and the user experience to make their task of protecting their interests easier (interests which have no regard for those of an individual digital asset). CRAP technologies tend to be narcissistic (implemented uniquely by each brand’s vendor with no standards in play across different brands) and therefore inconsistent from one environment to the next.

The implications:

Container-related asset protection (CRAP) technologies severely impact the user experience desired by an author, interfering with distribution, confounding use across multiple environments and devices as well as use between home and work, and almost invariably restricting the user from installing the very upgrades and updates that would improve the user’s security and user experience. Wide variations across organization security policies, CRAP vendors and products, quality of IT staff and their training levels, and even regard for employees all serve to make the user experience for a digital asset inconsistent and inconvenient against the author/developer/owner’s wishes.

The Certitude AMULET answer:

Certitude AMULETs serve the needs of the intellectual property embedded in a digital asset as determined by the author/developer/owner of that digital asset, and continue to serve those needs throughout the lifespan of the digital asset while remaining responsive to dynamic changes in the author/developer/owner’s wishes. The user experience is assured to be as consistent as possible across all environments (given some consideration for hardware and feature difference between devices). Although Certitude AMULETs are sufficient by themselves to secure all digital assets, they are also intuitively compatible with all forms of Container-Related Asset Protection (CRAP) technologies.

Why it matters:

Quite possibly the greatest deceit of the many perpetrated by security technology companies on American consumers has to do with encryption. With its potent combination of the mystical, magical, and mathematical, the subject of encryption is enough to inspire shock and awe anyone with a liberal arts degree, and some of the worst security technology ever written leverages that respect and fear to the hilt. And yes, encryption in and of itself is an impressive, if nerdy, accomplishment, assuming you are heavily invested in the difference between theoretically taking ten billion years to crack an encrypted item over theoretically taking 100 billion years to crack that item, or looking to put quantum physics to practical use creating obscenely large prime numbers quickly.

Do you remember the story of the Gordian knot, wherein Alexander the Great defeated the most sophisticated knot of rope that the technology of the time could produce by slicing it in half with a sword (or according to another version, simply remove the pin from a yoke holding the knot in place)? Or the scene in Raiders of the Lost Ark in which Harrison Ford’s character simply just shoots the Arab swordsman flamboyantly swinging an oversized scimitar?

Encryption on a computer is exactly like that. It is irrelevant beyond a certain point how much stronger one encryption is over another, because encryption strength is simply not the issue. A hacker’s goal isn’t to prove he can hack encryption; it is to copy, deny the use of, or take something and/or create havoc. So the issue is no longer the encryption, but instead, where is the data being decrypted to? The hacker simply goes there to retrieve the decrypted version of the data he/she wants. Here’s the deal – not only is encrypted data by itself generally useless to the hacker, it is also useless to the application that needs the unencrypted form of the data to do its work. So, the data must be decrypted to be useful. And the data must be decrypted to a location, in memory or (God forbid) as a file, where the consuming application (and not coincidentally, anyone else, including the hacker) can get to it. And therein lie the demise of that Arab swordsman.

There are dozens of ways that unencrypted data can be attained by a hacker, but let me lay out a typical path. Any operating system communicates with its file and memory systems via events, signals, and/or messages. A hacker places a hibernating bot or worm on the target host via any one of several means. Whenever an encrypted file is read for the purpose of decryption, the bot wakes in response to the file read signal and begins looking for a corresponding signal indicating the writing of another file, or creation of a memory handle, or system library creation of a file stream. It is that file, memory location, or file stream that will contain the decrypted data the hacker wants. The hacker injects a copy function or alternate destination into the process, and he has what he came for, no encryption key required.

Alternatively, the hacker can camp on the read of a certificates file for the incendiary signal (or to grab the key itself if the application is foolish enough to transfer the key across the network – don’t laugh, one of the worst “security” companies ever, Vera, transfers keys to AES256 encryption back and forth a half dozen times during a session! Reminds me of the old joke that IBM uses a three-letter acronym in large part because that’s the most number of letters its security technologists can be counted on to repeat in the right order), or capture the unencrypted output stream directly from the USB port driver. Of course, social engineering hackers have learned the fastest way to gain access to any encrypted data is to simply talk a human out of either the key or the decrypted data. If that’s not enough, most security technology software is so poorly written that they either leave the decrypted data in a memory block for the life of the application, or leave the decrypted data in a “temporary file” (sometimes they just leave the data unencrypted sitting forever in the decrypted format), or let it hang around in as-yet-to-be-garbage-collected memory. Finally, the applications consuming the decrypted data have security that is several orders of magnitude weaker than the weakest of encryption methods, and decrypted data can simply be hacked from those applications.

Security companies have a tacit agreement between themselves not to reveal these fatal encryption flaws to the public because they all suffer from the same affliction, and none of them has solved this Achille’s heel… except, of course, for Certitude Digital. For the consumer, this manufactured ignorance strips their encrypted data of any security whatsoever in the face of the motivated and knowledgeable hacker. But it gets worse. In 1998, Bill Gates sold out Windows consumers in order to get the U.S. Department of Justice to agree to a settlement in his criminal monopoly case, a settlement the majority of the state attorney generals who were prosecuting the case thought was far too lenient. Gates used encryption as the bait, promising to build back doors into all Windows encryption processes as well as Windows certificates for other vendors’ encryption methods so that the Justice Department could more easily monitor citizens’ computers in criminal and national security matters without obtaining warrants. Though it was widely suspected among computer professional at the time (internal encryption operations would occasionally produce large “prime” numbers that were even, a mathematical impossibility), Edward Snowden confirmed the facts of the arrangement in his various leaks, including that the backdoors had been extended and expanded in all Microsoft products in the years since: (see article). In 2013, the NSA tools for exploiting those back doors were found and released to the hacker community by Russian hackers (see article). Finally, Linux and other Unix variants are open source (open to the public), and NSA operatives have had no barriers to placing backdoors in that source code as needed.

The implications:

The implementations of encryption used in many, if not most, security technologies are outright frauds. Those which are not blatantly fraudulent have extraordinary implementation defects that render the encryption purposeless in the face of a sophisticated hacker. No security technology (other than Certitude Digital) has solved the critical issue of where a decrypted file is decrypted to. Commercial encryption programs, especially any embedded into Microsoft or open-source Unix-based operating systems, have back doors known to hackers. However, dishonest security technologies continue to tout the “strength” of their encryption as a way to mislead consumers.

Trusting encryption as the answer to your security issues (which dishonest security technology vendors encourage you to do) will result in exposing your digital assets to exploitation.

The Certitude AMULET answer:

Certitude Digital has pending patent applications, prior provisional applications, and current provisional patent applications on a suite of isolation technologies which can be deployed to resolve both the insecure decryption persistent destination issues as well as the insecure consuming applications (including legacy applications unaware of encryption) problem. We also have patent-pending keyless enciphering technology which uses a number of encryption techniques simultaneously to encrypt overlapping portions of raw data in layers – the base source code is our own and derives from code untainted by the NSA.

The isolation technology suite is collectively referred to in Certitude Digital AMULET documentation as Code Cocoons , and two forms of the technology are offered, both memory-based.

In essence, the first form of the technology emulates in memory a hardware device, hidden from the rest of the host operating file system, that has a nearly infinite set of virtual parameters to configure its capacity and geometry. Because it is a purely virtual device and an extraordinary variety of different parameters can produce the same apparent capacity, each invocation produces a radically different memory image from any other, even for the same file. A hacker stumbling upon a block of memory holding a decrypted file in one of these configurations would find it unrecognizable, yet to the intended recipient of the decrypted file it reads exactly as would a physical device of that type.

The second form of the isolation technology is built upon the first form, that is, resides on a virtual form of a hardware device in memory. This second form of a Code Cocoon can be used to host a consuming application that is itself too insecure to protect decryption content. The second form is mounted as a minimal instance of a virtual machine, also hidden from the host operating file system. Only the outputs of the running insecure applications are exported to the host operating system.

All of these technologies are the exclusive intellectual property of the Certitude Digital AMULET framework and system, and are not available to other security technologies except through authorized licensing agreements with Certitude Digital and subject to explicit provisions for their use. Such technologies are required to prominently display the Certitude Digital and AMULET logos and trademarks.

Why it matters:

Anyone ever involved in digital security knows the four levels of risk increase exponentially as you go down the list (with 1. being safest):

  1. Never allow the device online;
  2. If online, pull the device offline and never again allow it online;
  3. Allow a device online only when absolutely necessary and the risk results in tangible rewards; and
  4. Allow the device to be used online at will.

Given the associated risks, no decent person would ever consider a security technology that forced you to be online every moment the device is on, with “decency” being the operative concept. Of course, unmitigated greed, laziness, and gall do not qualify as decency but failing to meet that test has not stopped security vendors from forcing their customers online as a means to decrease their effort and increase their profits by leveraging client ignorance. And yet, dozens of questionable “security” companies have popped up almost overnight who rely on the Internet to deliver and administer their particular boutique security product. There’s even a cloud protocol known as Security-As-A-Service which requires clients to out-source, over the Internet, the management of the security technology that the security technology vendor made too complicated for the client to understand… on an added-fee, subscription basis, of course. Does forcing their security and administration servers online so someone else can manage them, while at the same time making their most sensitive servers naked to all the Internet by exposing the I/P addresses for them (and their Ethernet backbone connections) make the client more secure? Of course not. Does it make the security vendor more profits? Take a wild guess.

Worse, though, are all the boutique “security” vendors and apps which have sprung up overnight to take advantage of the attention being focused on digital security. These apps each carve out a little niche for themselves (Vera, for example, specializes in Office 365 files), throw some buzzwords around (Vera says “we have military-grade encryption” but in addition to the unsolved where-do-they-decrypt-the-file-to problems and the unsolved persistent unencrypted file and memory problems described above in their products, they pass the keys on which AES256 encryption depends to remain private across the network half a dozen times per session), and hope you’ll take the bait. But these get-rich-quick schemes all have the same huge hidden cost – you must be online while using them, and being online exposes the user to risks that are an order of magnitude worse than the problems these niche products claim to solve. Those products offer nothing, of course, to address those much greater dangers. So ultimately, for the unproven promise of protection for a tiny, tiny subset of your aggregate security needs, you are forced to expose all of your assets to significantly increased risk.

And just so you know, this is not the nineties any more. Hackers are no longer fundamentally spoiled children wanting to make trouble and brag about it. Modern hackers are professionals, paid for their efforts in one way or another (often by a foreign nation/state or our own government), and when they see a device come online with an I/P address in the block of I/P addresses openly published as assigned to an organization they are interested in, they (or their automated tools) simply slip a bot or a worm onto the device though one of a dozen or more mechanisms (including social engineering), and the bot or worm quietly waits for instructions or events that may not come for years, the host completely unaware of their presence.

The implications:

Hackers are completely dependent upon a device being online in order to do their work, and much of the actual work of hacking is spent inducing people to take their devices online. How convenient, then, that so many security vendors, through greed, blatant disregard, or sheer stupidity are doing that part of the hacker’s job for them. In many ways, security technology vendors are offering to protect you during your trout-fishing expedition, but at the price of requiring you to take your little vacation in the middle of the alligator-infested Atchafalaya River swamp (and to bring your small children and family jewels with you).

The bottom line is that with any of these security technologies, the entirety of the risk landscape must be assessed, especially with any technology that exposes you, your digital assets, and your intellectual property to significantly greater risks in exchange for a very small potential gain. You must make that risk assessment yourself, in accordance with your organization’s valuations of its digital assets and its willingness to take on additional risks. You must not allow any security vendor (including us) to make that assessment for you, because I assure you the value they place on any harm to you is far less than the value they place on making a profit. In a world dominated by the failures of the current large security technology vendors, and one in which they can hide any negative information (numbers of attacks they actually attract, rather than repel, because the attack surfaces of their products are well known and extensive, the success of those attacks, and the true costs of those attacks), dishonesty reigns supreme. When 86% of all CEOs report being dissatisfied with their current security provider, when $200 billion a year is being spent with these security providers yet cyber-security losses are expected to approach $1 trillion dollars annually by 2020, what security technology vendors do you think they are dissatisfied with? Here’s a hint – the biggest offender is IBM, at the time of this writing blanketing the airwaves with hacking-denier ads featuring Watson suggesting that their clients do not get hacked, probably one of the biggest in-your-face lies ever told using national media. What has escaped you about the fact IBM has been the dominant player in IT security during all of the four decades the present national cyber-security disaster was evolving? Did IBM make a ton of money? You bet. Were the needs of any of their clients or society at large met? Hardly. What are you expecting to change over the course of their fifth decade? And do you really think forcing more of your devices, digital assets, and intellectual property online is going to help your situation any?

Finally, there’s a very cynical suspicion floating around that the major security vendors actually encourage certain types of hacking as a way to advertise the need for their services and thereby churn business. We’re not ready to make that argument (yet), but there’s certainly nothing in the record or in their products’ performance that disputes the theory. No one can argue that artificially creating a $200 billion/year market while simultaneously allowing what is approaching $1 trillion in annual losses despite their customers’ expenditure of those monies is a masterful demonstration of how to milk a cow without having it go dry.

Trusting encryption as the answer to your security issues (which dishonest security technology vendors encourage you to do) will result in exposing your digital assets to exploitation.

The Certitude AMULET answer:

Certitude Digital AMULET technologies not only impose no requirement that a device ever be online, they are designed such that no harm whatsoever can come to a digital asset (or its protective AMULET ) from being online. You could spread a billion copies of the AMULET-protected originally-plain-text list of the Coca Cola secret ingredients across the Internet, and not a single entity in possession of one of those copies could make any use of it (or even recognize it for what it was).

Since the Certitude Digital AMULET technologies cover a wider spectrum of the entire cyber-security arena than any other security technology (by far), there is no need for the one-off minor applications that introduce more risk than they do solutions to a problem.

Certitude Digital AMULET technologies can certainly take advantage of the Internet when appropriate and available, not simply to make security technology vendors’ lives easier and richer, but to make the environment safer and more accountable for the digital asset, the intellectual property embedded in that digital asset, and the author\developer\owner of the digital asset. When online, Certitude AMULETs are dynamically modifiable by the author\developer\owner, meaning the digital asset’s security can be edited in real time. Remote criteria can be accessed so that as a part of its environmental evaluation the Certitude framework can consider website contents, the results of running a remote script or app, or the contents of a cell in an online database table, for example. And of course, real-time auditing and notifications are enabled when online.

Why it matters:

Container-Related Asset Protection (CRAP) security technologies (the mainstay of all the current major security vendors) are very limited in what they can do, and have thrived only because of the industry’s truly remarkable manipulation and muscling of its customers to bend the clients’ workflow, alter the clients’ business needs, and lower the clients’ expectations to meet the vendor’s requirements. These CRAP vendors have been so successful at conditioning us that we all take it as a matter of course that the only way to protect our digital assets is to place them on a locked-down centralized server (or cloud) controlled not by us, but by the security vendors’ self-serving rules of engagement, and in the meantime surrender the state of the art functions (mobility, real-time updates, online configuration) in the apps we’ve already purchased or digital assets we own or create. In so doing, we must re-learn otherwise acceptable habits to accommodate the changes imposed by the security vendors, and constantly go begging to IT to allow us the access we need to do our jobs. Hidden costs for all of this include loss of production, frustrations in the work environment, re-training of staff (especially IT), purchasing products to cover gaps caused by reduced functionality of existing applications, or to replace apps that are not compatible with the security vendors limitations (notably, free open-source and cell-phone apps), and costly additional security management applications meant only to serve the security technology providers’ needs (some of which, such as Security-as-a-Service, dramatically increase, rather than reduce, security risks for the client).

But far and away the greatest cost to CRAP technologies is the mortgaging of the organization’s future freedom and adaptability. These security vendors want you locked into their technologies, their methodologies, their services, often their hardware, and especially their subscriptions and maintenance agreements, such that you have no freedom whatsoever to change providers when a more effective, cheaper, or more reasonable security provider offers their services. Should you try to escape, the tactics they will use are so vicious an entire discipline in the practice of law has evolved to deal with it (see article).

IBM is the best example ever of why you would never want to outsource a police officer’s duties to a modern American corporation. The problem is that digital security has taken on the same importance and elements for which we assign police officers (because a police officer’s motivations hinge on efficacy and halting crime, rather than on deriving profit indirectly from the continued criminal behavior – what do you think would happen to IBM’s profits and general business if hacking stopped tomorrow, and do you really think IBM doesn’t fully understand their need for hacking to thrive at some level?).

The implications:

I do not think there is any situation in IT more frustrating, even downright maddening, than to be in a position of accountability when a major breach happens, knowing that the CRAP security provider who has been bleeding you dry and upon whom you relied, has just failed you egregiously, that you are trapped by the expenses and difficulty of transitioning to another security provider, and that your current provider’s only meaningful reaction is going to be to point fingers at your IT staff blaming them for implementation issues, and to try to sell you yet another Band-Aided-on “solution” to carry you over until the next breach. Sadly, this very scenario plays on a hundred times a day each and every day among larger U.S. organizations.

The Certitude Digital AMULETs project began life focused just on protecting intellectual property (patents, copyrights, trade secrets, etc.) from unauthorized use. During testing of the proof of concept, it became very obvious that what we had could do a lot more, so we were talking to people in the music business about creating an app using our technology that would ensure a seamless experience for the downloader of a song yet make sure the artist got paid. We just happened to be on the sidelines when the 2014 Sony hack occurred, and watching that play out led to the configuration of our framework so that we could in fact eliminate CRAP providers from the industry altogether (and make no mistake – while our technology can coexist with CRAP technologies, eliminating the need for them is our ultimate goal).

The Certitude AMULET™ answer:

Certitude Digital AMULET™ technologies cover the vast majority of your security needs, and require no lockdown of even the tiniest percentage of your digital assets. In other words, you do not need to have CRAP technologies on the one hand with their onerous burdens to protect one small subset of your digital assets while also paying for other security technologies to defend mobile digital assets, digital assets that may be incompatible with your CRAP technology for some reason, standalone operating systems on devices, and on-device applications like browsers. Certitude Digital AMULET-protected digital assets can travel at will between devices, operating systems, servers on any transport available, including the Internet and your Ethernet backbone, with no fear of breach. Certitude Digital AMULET-protected digital assets can be freely copied at will, and the unauthorized possessor of a copy (or authorized possessor in an invalid environment) can do absolutely nothing with it. This means a hacker gains nothing by breaching a container filled with Certitude AMULET-protected digital assets, and therefore any motivation to hack the container vaporizes, reducing the threat to your other containers, even if some of the assets in those containers are not Certitude AMULET-protected.

Certitude Digital AMULET™ technologies have no draconian overarching control structure, learning curve, or restrictions on the use of protected digital assets associated with them. The only infrastructure associated with Certitude AMULETs is a lightweight framework component that installs itself automatically in the background with first use on a device without any user intervention (see our little plain-text demo on our website). Various simple utilities provided at no cost make the association of an AMULET™ with a digital asset painless (and even easier if the author\developer\owner wants to make file-based assignments to a common AMULET en masse).

For organizations already trapped in the web of an existing CRAP security technology providers’ services from which they cannot easily escape, no worries – Certitude Digital AMULETs can provide security that actually works and still remains compatible with the CRAP technology’s constraints. Certitude AMULETs criteria can be set up on a per-instance-of-use basis so that you pay only for the actual services that are rendered, and only when effective – those costs will be a miniscule fraction of what you are obligated to pay your CRAP technology vendor. Having Certitude Digital’s comprehensive security technology covering all of your security needs will permit you to wean your organization from the CRAP technology. If necessary, Certitude AMULET protection can assure you a completely risk-free transition from one vendor to another if for some reason you desire continued overlapping protection, but with a less expensive or more effective vendor on the CRAP technology side of the overlap.

Certitude Digital AMULET™ technology is completely freeing in so many ways.

Why it matters:

 A fundamental quality of any good security technology is the expectation of, and ability to recognize, change (otherwise, your security guard would only have to walk that warehouse perimeter once a year).

That laptop and its VPN dongle locked into your Ethernet backbone may not be in the possession of the same person it was yesterday. There may be a flash drive now in a USB port that wasn’t there two hours ago, waiting to copy data it shouldn’t. The person sitting in front of that keyboard may not be the one that was sitting there ten minutes ago – did the previous user log out? The employee you could trust with that application six months ago may now be disgruntled, might have received a poor performance review in the meantime, could be going through a divorce, or may have been stealing from you all of this time without you knowing it. A hacker may have installed a worm or bot on the machine in the middle of the night, or the user might have clicked on a malicious link in an e-mail they just received.

The point is, things change, and not all changes are good. Since change rarely times itself to be convenient to your needs (quite the opposite if the change has been induced by a hacker), your security technology needs to scan the environment for the things your digital asset is concerned about each and every time before that digital asset is accessed, and periodically every few minutes during its use, if the intent is to secure the digital asset and the intellectual property represented by, or embedded in, that digital asset.

The implications:

 It takes a lot of engineering, consideration of resources, clever organization, and knowledge of how things (and hackers) actually work to design an efficient and effective system for pre-empting or preventing the abuse of a digital asset or intellectual property before that intellectual property is stolen or its author/developer/owner abused. We know, because we are the only entity to have ever pulled it off successfully. Most security vendors ascertain the owner of a laptop once a year, and then assign software and data access rights to that laptop periodically on demand, and that’s it – they never re-visit the issue again until someone is struck by lightning (a condition they become aware of not through their own technology, but via the smoke detector and automated sprinkler system), changes position or is terminated (the latter two they must be told about manually). The very most they can ever do is to provide a rudimentary post-mortem guess as to what happened after the damage is already done. At that point you’ve experienced four kinds of losses – the original loss itself in monetary terms, the non-monetary harm of that original loss to your intellectual property and inability to make use of the digital asset, the ongoing losses and harm to your intellectual property during the period between the loss and its discovery or correction, and of course, the licensing fees, training costs, maintenance and support fees and costs, and additional required products and infrastructure for a security technology that failed to do its job. There is nothing about such a process which in any way provides any actual security for anything in the modern era. Most digital security technology products are nothing more than elaborate ruses to charge you for the artificially-induced warm fuzzy feeling you have before the thief has discovered you have something he wants and decides to break in.

The Certitude AMULET answer:

 Rather than taking the stance of a change denier and pretending change doesn’t exist as most security technologies do, the Certitude AMULET system was designed from the ground up specifically to embrace change, welcome it, recognize it when it comes, and react to it in timely fashion when it does. In fact, the Certitude AMULET system treats change as a welcome tool and ally, because the reality is that hackers cannot do their harm without themselves causing change, which then gives them away.

Prior to each and every access attempt, and every ten seconds to ten minutes during each honored access attempt (depending on the type of security criteria the digital asset author\developer\owner has specified in the AMULET), the Certitude AMULET framework re-evaluates the environment against the AMULET criteria looking for changes that indicate a problem of some kind, immediately reporting, recording to audit trail, and reacting to anomalies as they occur. The Certitude Digital framework, AMULETs , and integration with digital assets are all mobility-aware, and so can accommodate changes in both the host device’s location and the movements of the digital asset itself from device to device across different device types, operating systems, and network infrastructures.

Beyond seeking out and adapting to change proactively on behalf of digital assets, the Certitude framework induces its own changes to frustrate hackers. Each and every active digital asset within reach of a host device is re-enciphered periodically, completely changing the enciphered files’ and the AMULET’s content and size with each pass even though the unenciphered AMULET and file contents do not change at all. And of course, the AMULET criteria are dynamic and subject to change at any time at the author\developer\owner’s discretion when online, or by specific periodic download when offline.

Or do they require a salesman to spin promises in an unrecorded presentation in which they control the conversations?

Content for this question coming soon…

Or is pricing based on what the vendor thinks the market (you) will bear in private “quotes”?

Content for this question coming soon…

 

Or are they intended to protect the property of third parties at your expense?

Content for this question coming soon…

If they dominate the market and their products are effective, why are organizations spending $200 billion per year on security, yet still suffering losses approaching $1 trillion per year, and why in a national survey did 86% of all CEOs report being dissatisfied with their security technology vendor?

Content for this question coming soon…

Who in your organization receives that report, and what do they do with it? Do you have to hide that report from your customers because its contents clearly show you’ve made a poor choice in security technology providers?

Content for this question coming soon…

The author, developer, or owner, who knows the digital asset intimately as well as the intended usage and audience?

Or a security vendor interested not in how secure your digital asset may be, but in how he or she can profit from products they can sell you (where profit is defined in part as being costs for labor which he/she doesn’t devote to the effort going straight into their pockets)?

Content for this question coming soon…

Would you prefer a system which allows a seamless efficient user experience unbound to a publisher which ensures the artist is compensated for their work?

Content for this question coming soon…

Do you think this should be enforced at a national level?

Do you fell clients have the right to understandable information necessary to make informed choices between security technology providers?

Content for this question coming soon…