Aetheric Research, Ltd.

The spokesman for an outfit that puts out retro games, Good Old Games, has been quoted saying that DRM drives gamers to piracy.  The argument being made here is that the massive hassle involved in installing and maintaining the ‘authorized’ conditions to play the game legitimately form too high a barrier and that, at least for single-player or other local system games, it’s easier to install a cracked version of the game than to try to maintain the ‘authorized’ version.

Mr. Kukawski also makes an interesting point in his statement–much of the DRM that game manufacturers (and the manufacurers of other media) insist on installing could well count as malicious software.  Anyone recalling the Sony rootkit debacle–where Sony attempted to enforce DRM by crippling the functionality of the users’ systems without their consent–will easily see what happens when a company goes ‘too far’ in their quest to maintain control over content.

However, piracy is more or less inevitable, and by spending so much time and money ‘securing’ your media against theft, you’re more or less guaranteeing that others will take an interest in breaking it.

Insisting on the installation of malicious software–software that spies on the system’s activities to see if “forbidden” programs are installed or running, that “phones home” to a remote server, that cripples the functionality of your system unless certain conditions are met–is a tactic that even the mafia would hesitate at enforcing.  

DRM only serves to hurt legitimate users.

Pirates will pirate the media no matter what–if it’s sufficiently interesting to them, then it will be cracked and released on the internet, regardless of the technical obstacles put in the way.  The only pirate inconvenienced by the DRM is the first one–and if these media companies paid any attention to the psychology of the typical warez-head, they’d realize that by putting technical obstructions in the way, they’re only serving to glorify the exploits of those pirates who make available the content in the first place.

One might be excused for thinking that the pirate ecosystem was being deliberately cultivated, in a sort of perverse mockery of the open-source software world–many eyes finding and correcting ‘bugs’.  Ubisoft has rather blatantly stolen (in a perversely ironic way) the work of various pirates on a number of occasions, including as a method of circumventing onerous DRM put in place by an online marketplace.

Time and time again, DRM has served only to inconvenience the legitimate paying customers, who are painted as thieves and bandits by the media companies who take their money with one hand while denying them the functionality that they have paid for with the other.  This is not being limited to software, either; Intel has announced that their new line of ‘Sandy Bridge’ chips will have DRM built into them, attempting to enforce these ‘digital rights’ at the hardware level for streaming media.  This will only serve to hurt legitimate users; pirates will, in all likelihood, take about a week to circumvent these protections and the whole game will start again.

Content providers should take notice that this DRM nonsense does not work, and look at the example of studios who have made this realization.  Cut out DRM licensing and R&D from the budget, and accept piracy as part of the cost of doing business–write off the ‘losses’ from the advertising budget, given that piracy can lead to more sales.  Fighting the flow does nothing but waste energy; using the flow to your advantage helps you grow and thrive.

The Register has an excellent (if somewhat snarky, though that is the milieu of the publication) article on some of the recent breaks to SSL’s effectiveness as a platform for secure communications.

The basic problem behind this round of vulnerabilities is the reliability of the certifying organizations.  After the recent breakin to Comodo that resulted in the issuance of several fraudulent certificates, more attention has been paid to this particular flaw in the way in which traffic is secured.

SSL works by means of PKI: public key infrastructure.  This means that a large string of data, known as a ‘key’, is sent out into the public for use by anyone wishing to communicate with the server.  The key has a certain mathematical relationship with another key stored on the server (known as the private key); when data is encrypted with one, it can be decrypted with the other if the proper mathematical steps are taken.

These keys are used to negotiate a secured connection to a server, which serves two purposes–first, it assures the person connecting to the server that they are connecting to the genuine article; the fact that the connection can be made successfully proves that the server has the requisite private information associated with the key.  Secondly, it allows the entire connection to be encrypted so that people between the computer and the server will be unable to determine the content of the transaction.

This only works, however, if the key is trusted–if anyone has access to the private key other than the server in question, then there is no assurance that the connection is being made to the correct server, and no assurance that someone in the middle is unable to eavesdrop.

Cerifying Authorities such as Comodo, VeriSign, and others are supposed to guarantee that they issue certificates only to the organizations that they identify.  However, this is not always the case; especially in the case of their licensees–companies that issue certificates under license from the CA houses, and whose certificates are intended to be just as trusted–the requisite identification of the certificate request is not always accomplished properly, resulting in certificates being issued to incorrect persons.

One particular certificate that has been mentioned is one for ‘localhost’–that is, one’s own computer.  While most articles on this subject have noted that this is an essentially frivolous certificate and have paid much more attention to the ‘exchange’ domain certificates that could be used for intercepting corporate email, it’s worth noting that a live ‘localhost’ certificate along with a maliciously-installed local proxy could intercept all internet traffic that a user attempts, thus providing no overt sign (unless the user was very security-conscious and checked carefully the certificates of all the sites that they connected to) to the user that they were being compromised and, for instance, their bank account details were being stolen.

Certain alternatives to the SSL system have been proposed, but as yet they all suffer from the difficulties of limited adoption.  Until a significant movement arises–or at least some of the ‘big players’ get involved–eCommerce and the like will likely continue to be only partly secured.

(On a side note, a service that actively tracks and validates certificates issued by all authorities–like the automated one run by Google on page 3 of the article linked–could be made very profitable)

Apologies for the mangled French title.  The BBC reports that several companies are challenging a French law insisting that they keep a record of users’ real names, telephone numbers, addresses, and–most damningly–passwords, to be turned over to police on demand.

In a proper, competent system, passwords themselves are never stored.  Instead, when an account (and associated password) is created, the password is passed through a complex mathematical function to produce what is called a ‘hash’–much like how reconstructing an order of ham hash into the original ham and potatoes is more difficult than anyone can reasonably be expected to accomplish, reconstructing a password from a hash is intended to be next to impossible.

When the user logs in, their password is passed through the mathematical function again, and the result compared with the entry in the password table.  Since the function is tuned to produce a complex but unique result from each input, if the hashes match then the password has been entered properly.

The recent high-profile crack at Gawker, where the password database was compromised, was only possible because their hashing algorithm was weak and most users’ passwords were also weak.  Indeed, the algorithm itself was not actually reversed–instead, a database known as a ‘rainbow table’ was used, which is the result of passing a dictionary of common passwords through a known hashing algorithm.

This French law completely ignores best-practices.  Besides the obvious privacy concerns, it requires that the companies make passwords available to the police–which means that, rather than a database of the hashes, the companies will be required to keep a database of the actual passwords.

This is an unnecessary and badly thought-out requirement, as it lays every single person in France who uses any of these services open to theft of their accounts should anyone be successful at exfiltrating the associated databases.  Worse, given that real names and addresses are associated with these accounts, it provides very nearly one-stop shopping for any French identity that an attacker could wish to have.  

In essence, no company that engages in anything resembling standard security practises can operate in France unless they irreperably damage standard procedures in order to engage in traffic with that country.

This law is badly thought-out and will irreperably damage France’s status in the EU and on the world stage.  Anyone who wishes for security in their dealings should avoid any companies that provide this data, as these databases will be inherently insecure.

RSA, a well-known manufacturer of two-factor authentication systems based around cryptographic tokens and developer of numerous other security-based products, announced last month that their security had been compromised, specifically that surrounding their flagship SecureID tokens.  Yesterday, they finally revealed some of the details behind how that particular compromise happened.

The description given by the WSJ above is one of an attack carried out with ‘sophistication’–but looking deeper in reveals that this is apparently face-saving propaganda, given that the description matches up with a textbook social engineering-mediated trojan installation.

In short, a spearphishing campaign–a phishing campaign focused at a specific person or group–was carried out to solicit a person with some level of privilege into opening a document in which was embedded malicious code–in this case, an Adobe Flash object.  This malicious code proceeded to install what’s known as a RAT–a remote-access trojan–which connected to a remote server to allow the infiltrator to observe his target’s activities and gain access to secured information.

At that point, the infiltrator was able to package and upload private information concerning the cryptography used in the SecureID token system to a server that he controlled elsewhere.

As per the usual texbook example–and the phrase is chosen deliberately, given that it is, in all respects, materially identical with the majority of examples given in this text on social engineering–the target was induced to deliberately open a suspicious attachment.  Said attachment had been put into the ‘spam’ bucket (though attachments had not been stripped, as best practices would dictate for such arrangements) and it was deliberately retrieved and opened by the target at the infiltrator’s inducing.  

This cannot be stressed enough: the initial infiltration was accomplished through mundane means, by convincing the target to act against standard security policies.

It was only through the user’s deliberate violation of standard secure practices that the infiltrator was able to gain access to the network and carry out his work.  

There were a few other failures in security that this appears to put into play–RSA has several products that they market specifically to prevent these sorts of infiltrations, to detect and counter intrusions; these were apparently not in use inside the company, which rather places doubts on their effectiveness.  Attachments, as mentioned above, were not automatically stripped from external emails; this is fairly standard practise with any reasonably well-administered mailserver, as it cuts down the possible attack surface significantly.  The corporate firewalls did not, apparently, block outgoing FTP traffic to sites not known-good; this allowed for easy exfiltration of private company data.  

Any one of these failures has the potential for a breach; all of them together combined to make that breach much easier and much less detectable than it might have been otherwise.

To RSA’s credit, they at least determined that a breach had happened before they were notified by some outside agency; oftentimes, insufficiently secure networks are infiltrated and no notice is taken of any odd function or other telltales of intrusion until, for instance, the company domain is blacklisted for being a spam origination point.

The countermeasures to prevent this sort of breach are obvious: secure the corporate network according to standard best practices.  Ensure that all users are fully aware of security policy, and ensure that all users follow said policies–even if that means disabling the accounts of executives until they have time to receive training.  Configure the mailserver to strip out unknown attachments–frankly, in an enterprise of that scale, email attachments are entirely unnecessary; a CMS should be used for departmental file storage and sharing.

The SecureID product is probably, given RSA’s extreme reluctance to disclose what information was leaked, irreperably compromised–at least until such time as RSA develops a new algorithm and a new implementation for it.  

RSA can learn some lessons from this breach, but it remains to be seen if they will put those lessons into practice.

If you’re unfortunate enough not to have someone in your family or circle of friends who builds computer systems, you may have had the unfortunate experience of buying a new computer at a retail store and, on unboxing and setting it up, being confronted with a significant amount of preinstalled nonsense that you neither want nor need.  Usually, this includes such things as “trial versions” of games, “trial” versions of antivirus programs, “helpful” extensions to the web browser, assorted other “previews” of software, generally some sort of “maintenance” console from the system manufacturer, links to one or more ISPs setup procedures, etc., that require several hours’ cleaning in order to be rid of them.

If you have the misfortune of buying a system from Samsung, however, you may have found a little something more.  NetworkWorld broke a story yesterday where a security professional found a clear instance of spyware being preinstalled by the manufacturer.

Spyware, as the name implies, is the term for software intended to covertly gather information from a system and report it back to some other party without the user’s knowledge or consent.  In this case, it was a kind of program known as a keylogger: it intercepted keyboard input and logged it for transmission back to, apparently, Samsung–meaning that any documents, usernames, passwords, credit card numbers, social security numbers, names, addresses, or what have you that are entered on the keyboard, regardless of the context or location of the entering, would be logged by the system for inspection by Samsung.

Systems have been compromised by malicious software before being shipped in the past–Seagate had an incident in 2007 where some of its home-user Maxtor drives shipped with an outdated virus due to contamination at the drive manufacturing plant–but in this case the action appears to have been purposeful, as Samsung has admitted to purposely installing the software on the systems.

This recalls the Sony rootkit debacle from ’06–Sony had purposely built onto CDs a data track designed to be run by user’s computers that would install software specifically for the purpose of restricting music copying.  In this case, not only was the rootkit largely ineffective, but Sony was brought up before the FTC and restricted to such an extent that business refactoring was necessary in order to continue to operate in the United States.

The FTC stated at that time that installing software that creates a security risk to the consumer without the user’s consent is forbidden.  This apparently did not stop Samsung from violating, clearly, the letter and the spirit of that decision in installing malicious (to the user) software on the system.

Fortunately, there is a–relatively–easy fix for all of the problems above.  Installing an operating system onto the computer other than the one the manufacturer provided is a sure way to prevent both the installation of bloated advertising programs and vendor-provided malicious software.  

It’s an unfortunate extra step, but so long as vendors continue to prove they cannot be trusted with consumers’ information, it’s a necessary step.

A word of caution: the Windows license key printed on the case will likely not work with a regular Windows installation disk; that key is keyed to what’s known as the OEM version of the operating system–that is, the one that is distributed on the computer.  You will either have to purchase (or obtain by some other means) a license for Windows from another source, or choose a Linux distribution (such as Ubuntu or Fedora) that can be obtained without cost.

A post on the best ways to bribe the local computer geek into setting this up for you will be written shortly.

EDIT:

Several sources (engadget and Ars Technica, specifically) are now reporting that the keylogger detected was likely a false positive.  The statement by the customer support supervisor was, in this case, likely due to a misunderstanding of the question being asked. 

That being said, it is still a good idea to either build your own system or wipe and install your own OS on a vendor-supplied system, if only to keep off unnecessary bloat.

McAfee, a noted provider of various antivirus and internet security products, has been revealed to be vulnerable to one of the security holes that they offer a product specifically to prevent.

As reported yesterday by Network World, McAfee’s website has a cross-site scripting (XSS) vulnerabilities that could lead to compromise in the same manner as the SQL.com compromise.

McAfee markets a product, “McAfee Secure”, which they claim will ‘scan a website daily’ to reveal a significant number of vulnerabilities.  Apparently not a fan of dogfooding, McAfee was found to be vulnerable to many of these same security issues.  Amongst them were, as mentioned, XSS holes; also found were references to internal hostnames and disclosures of source code.

The XSS vulnerabilities are quite bad enough on their own–this means that a malicious attacker could serve various kinds of javascript to, for instance, steal login credentials or otherwise gain access to resources that they were not supposed to, without having to compromise the security of the server in any other way.  

Revealing internal network structure is quite another kettle of beans–if an attacker knows the hostname to look for, then they have a specific target to attack; if the hostname was revealed in such a manner as to show its purpose (from the context of the reference, for instance) then the type of attack to use to compromise it would be far easier to select.  

Source code disclosure is not that bad in and of itself, except that McAfee is a closed-source shop, and their code has been vetted by only a limited community of programmers; more eyes will find more vulnerabilities in the code, and unlike an open-source model (where that is the intent, and the same eyes that find the bugs are likely to either fix it themselves or know who to tell to fix it) the persons who would find this code are likely to use it for attack purposes.

It may be possible that some of these vulnerabilities are the result of deliberately-crafted honeytraps–that is, “vulnerabilities” set up specifically to be as appealing to attackers as possible in order to convince them to attempt to exploit them, leading them into a controlled environment for study.  Many security companies are known to operate whole networks of honeytraps in order to study emergant threats and catalogue attack types.  However, given that McAfee has been found to be vulnerable to XSS before, and that these vulnerabilities have remained unrepaired for more than a month, it is apparent that McAfee does not take its public-facing security seriously.

This is a very serious problem.  Millions of systems are deployed in this country and elsewhere with McAfee’s security products enabled–from basic home systems up through large enterprise and government workstations.  If McAfee is this lax in addressing a threat to their own presence on the web, how much can they be trusted to address threats to customers?  If McAfee does not eat their own dogfood–that is, if they do not use their own products–then why should anybody else?

There is no reason for a home user to bother paying McAfee for antivirus protection; there are several free solutions available–both Avast and AVG offer free versions for home use that are, often, more capable of picking up infections than McAfee.   It is in everyone’s best interest to keep the internet ecosystem as free of malware as possible; the actions of companies like McAfee (and Symantec, as well, though they’re not in the news today for complete failures of security policy) in charging home users every year are borderline unethical.

This also throws into stark relief the necessity for security culture as a way of life rather than as an item to be addressed at meetings: without a secure culture, there is no assurance that security will be addressed with any regularity.  

People, in general, are lazy.  If you want to make an individual follow a course of action, one of the best ways to ensure that they follow the action that you want them to take is to make it the easiest option.  

This is a principle that systems administrators can use to secure their systems as well:  if they configure the system such that insecure behavior is more difficult than secure behavior, then the users will either avoid using the system (if done badly) or default to the secure behavior (if done correctly).

There are several things that a careful administrator can do to ensure that the secure way is the easy way–many of those things involve configuring client systems to, for instance, accept automatic updates to the operating system and to antivirus software from a centrally managed server.  Other useful configurations would include requiring credentials before performing potentially insecure actions–presumably the intent behind the much-reviled Vista and Windows 7 nag screens, though at least for home users who typically run everything under a privileged account such protection becomes more susceptable to the automatic-yes-click.

Password authentication is, perhaps, one of the stickiest points involved in the whole mess.  For typical username/password setups, the ‘easy way’ is generally to use a known and memorable password over all the systems that they have access to–a vastly insecure practise, given that these kinds of passwords are generally easily compromised and, if repeated, are often repeated with the same or similar usernames.

Training and warnings will do little to mitigate this, as well, because as simple as most schemes for generating and remembering individual secure passwords are, they still require marginally more thought than reusing a simple one everywhere.

Offering other means of authentication may help.  OpenID, for instance, offers an API for websites to allow for authentication on a single system to be carried across multiple systems; the OpenID servers maintain the authentication standards and provide those servers that support their system with tokens to prove identity for logins.  For businesses, a token and PIN combination may help–that is, a card or dongle on which a cryptographic token is maintained (together with the requisite public-key infrastructure, or PKI, to validate it being available on the network) which can be unlocked by a short password or PIN.  Combined with single sign-on procedures, this means that the user has only to remember to bring their login token and remember a short password in order to use any of the systems that the networks supports.  Combining the token with some means of entry authentication–e.g. an identity badge–helps to ensure that it will be easier to sign onto the computer within the approved system than without it.

Network file share permissions are another area where special attention needs to be directed.  Without clear and consistent direction, such fileshares will end up a chaotic mass of all-access folders, as those with the ability to grant permissions will be continually harassed to allow for various special cases of cross-departmental sharing and the like.  Consider installing a well known and well supported CMS–and there are several open-source options, such as Alfresco, to allow for proper management of files in a secure fashion that can be made easier to use than alternatives.

A system is only as secure as its weakest link; that link is often the willingness of users to cut corners in order to expedite their needs.  A careful administrator can, with proper setup and proper diligence towards securing the network, ensure that these weak links are strengthened enough to make the resources behind them more trouble to access than they are worth.

The Examiner reports yet more fallout from the HBGary Federal leak: agencies of the US Government contracted with them to deliver “persona management” software that would enable the creation of, and use of, ten profiles per user with all the associated details required to make them appear to be independent, legitimate users.

Using “sockpuppet” accounts to build the illusion of a greater level of support on a given topic than actually exists is nothing new.  ”Alt” accounts are a fine old tradition, refined to an art by generations of trolls, and the techniques discussed by HBGary for ‘legitimizing’ their existence are largely unnecessary and overly complex.  Ultimately, any use of this program, absent some genuine talent for trolling on the part of the operator, is going to be doomed to failure.

First, when attempting to sockpuppet or astroturf a position as several different people, one’s writing style has to be disguised.  Spotting someone’s characteristic ‘fist’ is not easy, and is not an exact science, but there are many cues that will tip off the careful and attentive reader–characteristic typos, for instance, or idiosyncracies of punctuation.  Few people make their posts in exact accordance with the AP Stylebook–and those posts would themselves be highly characteristic.  Word choice, too, makes a significant difference–the English language vocabulary is large enough and contains enough synonyms for different shadings of words that word choice can often reflect the mental state of the person writing.

Secondly, using multiple personas will lead to mistakes.  It is inevitable that, when managing multiple personae, slipups will happen–this happens even to the best trolls, and is a significant factor in catching them.  All it takes is for one persona to display knowledge that the would not reasonably have as that persona, and suspicions will arise; pulling the thread will unravel the whole thing as previously unnoticed inconsistencies come to light.

Thirdly, most people are not going to bother researching the “full background” of every person they argue with on the internet.  While the facebook/myspace/etc profiles may be consistent and hang together under casual scrutiny, almost by definition the only time someone will be likely to investigate ‘em is if they’re suspicious already–at which point, various indicators (apparent monomania over a subject, lack of internet presence before a certain date, etc.) will clue in the careful investigator to the sockpuppet nature of the poster.

Fourth, approaching people with personas generated from old classmates is one of the oldest scams in the book, and the method for defeating it is so well-known as to form a trope–the “false memory gambit.”  Asking the so-called classmate, “Hey, do you remember back when such-and-such happened?” where the event described did not, in fact, happen (or, for more subtlety, did happen but they weren’t involved) is a trivially easy means of establishing identity–the “shared secret” forms the basis of many systems of cryptography.  Getting around that requires a true master of social engineering–and given HBGary’s demonstrated failures in that realm, it’s unlikely that they would be able to communicate to the software users any sort of expertise in this field.

Fifth, the IP roulette described is bound to cause difficulties.  Maintaining a static IP per persona is a reasonably good idea, albeit wasteful of IPs and unlikely to make much difference–most users of most fora are unaware of the IPs that any individual users may have; those are usually only available to administrators.  The “bank of proxy IPs” is more or less equivalent to using a TOR proxy; those will likely all be quickly flagged by administrators as being proxy IPs and, accordingly, banned.

Finally, if your propaganda message requires astroturfing and sockpuppeting to get out, there are far more effective ways of doing it (not the least of which is “writing a better propaganda message”) than sitting a bunch of airmen down to try to troll internet fora.  Single strong personalities will get far better results than a lot of shallow sockpuppets–especially given that each user is, according to that plan, responsible for ten alts apiece, the personalities and posting history of each will be, of necessity, very thin.  While this approach may fool the “Sarah Lou” school of users, it’s unlikely to work for any length of time on any messageboards with enough population to sustain such an interruption.

(And then, of course, there are always professional astroturfing agencies that already have the expertise to pull ths off properly–once again, HBGary was trying to reinvent the wheel.)

Ars reports that further examination of the leaked HBGary correspondence reveals that one of the focuses of their work was in developing rootkits that would bypass detection from existing antivirus products and would be capable of forwarding keystroke logs past existing firewalls.

Rootkits are a special kind of malware.  Most malware is written to take advantage of various holes in the operating system; some trojans convince users to open such a hole ‘voluntarily’.  Rootkits attempt to bypass a large portion of the operating system, generally by providing administrative access to low level portions of the system’s running code–in the case of the HBGary ‘products’ this would be the Windows kernel, the ‘supervisor’ program that orchestrates all the other programs.  Rootkits act to subvert and redirect portions of the operating system; by modifying certain system functions, they both cloak their presence from the user and act to allow elevated or hidden access to the interloper.

HBGary is not the only ‘legitimate’ firm to make use of rootkits; a little over five years ago, there was significant outcry due to Sony installing a rootkit via an autorun vulnerability on users’ computers as part of a copy protection scheme.  This was rather a PR disaster for Sony; as part of the rootkit’s function, certain files–those starting with “$sys$”–were hidden from users; this provided significant opportunity to other malware vendors to install various kinds of viruses and the like to the systems that Sony compromised.

Detecting rootkits is inherently a very difficult task.  Usually, rootkits can hide themselves from conventional antivirus products (HBGary’s boasts about lack of detection from the standard AV products reveal only very base malware writing competency, as this is a required feature for any new malware) by subverting the runtime environment of the system; hence, no program running on the system can be trusted to reveal a new infection–detection is most reliably accomplished by booting from a ‘trusted’ operating system, one that runs on a read-only medium.  

Cleaning up after a rootkit is an onerous task; generally, the safest method to use will be to wipe the system and restore from a known-safe source.  In the case of known rootkits, AV vendors tend to be very quick to update their signatures–once a rootkit is known to be in the wild and has been detected, then the method by which it can be detected and removed will be quickly determined and distributed.  

Needless to say, any use of rootkits is ethically suspicious–the use of malware as a weapon for espionage is a logical one, but given HBGary’s demonstrated lack of competence in other fields, no confidence as to the proper targeting or usage of said malware can be assumed.  Additionally, holding onto a collection of OS security flaws rather than providing them to the vendor for a fix is ethically unsound; Microsoft, especially, is already very lackluster about fixing known security flaws; reporting these holes would likely do little to impact their business, especially as al-Qaeda is hardly likely to be running the latest patches on their systems.

Defending against HBGary’s rootkits would be relatively simple for a competent corporate network security administrator with access to a proper IDS or IPS; the network traffic “disguised as ad clicks” would be readily apparent moving across the network and could be blocked and mitigated at that level.  Home users would find detection and removal to be more difficult, having fewer resources, but little damage would likely be done–especially as any destination server for extracted traffic would be very quickly closed down by interested parties.

All in all, rootkits are just another unsavory part of HBGary’s product line; presumably, at least some of these have been leaked along with the emails, so it would be in HBGary’s best interest as a company to either dissolve quickly or report the full contents of their “inventory” to antivirus and OS vendors–otherwise, when, inevitably, their “products” are used for the usual criminal reasons, HBGary will end up being sued–and it is doubtful that they will be able to handle the inevitable suits as well as Sony was able to.