This Blog




AlertBoot offers a cloud-based full disk encryption and mobile device security service for companies of any size who want a scalable and easy-to-deploy solution. Centrally managed through a web based console, AlertBoot offers mobile device management, mobile antivirus, remote wipe & lock, device auditing, USB drive and hard disk encryption managed services.


AlertBoot Endpoint Security

AlertBoot offers a cloud-based full disk encryption and mobile device security service for companies of any size who want a scalable and easy-to-deploy solution. Centrally managed through a web based console, AlertBoot offers mobile device management, mobile antivirus, remote wipe & lock, device auditing, USB drive and hard disk encryption managed services.

July 2011 - Posts

  • Data Encryption Software: Australia's Medvet Announces Data Breach, 800 Affected

    Adelaide-based Medvet, one of the largest Australian providers of DNA and drug tests, has announced an on-line data breach that has affected approximately 800 people.  The breach was, as far as I can tell, their own fault.  It occurred not because they failed to put in place the proper data security, such as the use of data encryption or firewalls, but because they failed to "tell" Google not to index their site.  On the other hand, that could be a sign that proper thought wasn't given to security.

    The Details

    According to several sources --,,, and -- information on 800 people who ordered tests from Medvet was accessible on-line, possibly since August of last year, although the company became aware of the issue over the July 16 - 17 weekend and claims the leak started last Friday, July 15. (The issue was fixed on Monday.  Some think that the information leak started last year because of Google cache's date and time stamps.)

    Medvet is one of the largest providers of drug and paternity tests in Australia, charging up to $770 per test.  In this latest breach, it looks like the company's on-line shopping/order page was made public (based on screenshots), allowing anyone to find customer names, addresses, and order details.  The results of these tests were not available, thankfully enough.  Furthermore, Medvet claims that customers' names were not present either, contrary to some reports.  The screenshots seem to indicate otherwise.

    I've discussed the issue with colleagues, and some think that an order account page shouldn't be on the internet for this company: It makes sense for a page to take orders to be available, but why have an account page?

    Criticism - Why Have an Account?

    Based on the screenshots and commentary that were published by the media, it appears that there is some kind of order account page that people can log in to place and keep track of their orders, not unlike logging into your account.  (I have to admit that, based on the looks of it, it may just be an internal order tracking system.  Regardless, the fact is that it's been breached.)

    I've discussed the issue with colleagues, and some think that an order account shouldn't exist on the internet for this particular company.  It makes sense to have a page to take orders, but why have an account page where you can look up the order and change details?  Chances are people won't change or cancel their orders: DNA and drug tests are not something you decide to order on a whim.  And as the unfolding events show, there can be serious complications for setting it up that way.

    On the other hand, why not have it?  While most might stick by their purchases, there will be a number of people who won't.  It's all about leveraging the internet to make things more efficient.

    Plus, the above argument is in hindsight.  I doubt that most professionals setting up an internet order page would have considered the pros and cons of taking orders vs. actually setting up an account.

    Criticism - Australia Needs Data Breach Notification Laws

    Many have taken to using this incident as evidence that Australia needs laws that force companies to go public with a data breach, something akin to what can be found in the US, Canada, and Europe: the incident was not made public by the company, but by The Weekend Australian when it went public with an expose.
    Better laws might not necessarily be the solution, though: according to some sources, Medvet only learned of the data leak when The Weekend Australian contacted them with what I suppose was a courtesy heads-up. (Others insinuate that the company knew of the problems since April of this year, although the company has denied such claims.)
    Perhaps their ignorance absolves them from not notifying customers of the breach as of today (not really), since they hadn't the foggiest clue, but then how do they account for their slow-as-molasses way of dealing with the situation?  It took them nearly two days to figure out what was wrong, fix the problem (i.e., use the Google removal request tool), and to go public with the situation, apparently something that didn't happen out of their own volition.  Based on what happened and their response, it feels like they didn't have a data breach contingency plan in place.  Would better laws have made a difference?
    Perhaps the existence of a data breach notification law with commensurate penalties would ensure a speedier reaction by breached companies.  But that doesn't nip the problem at the bud, which is to have a proactive security mindset, something that is apparently missing in Medvet's operations.

    Doing Security the Right Way

    Google has been around for a little over ten years now.  While I doubt everyone on the planet knows how the search engine works, I'd bet that anyone who makes a living setting up commercial websites has a pretty good idea of how Google works.   Why any professional would set up a site so that online search engines crawl through the order area is beyond me.  The incident was entirely preventable.

    Of course, that's not to say that you should rely on a search engine not to index your site as a security measure: proper data security and access controls means that, even if you gave permission for search engines to crawl your site, restricted areas should be blocked by the proper controls.

    For example, take a look at a customer who is currently using AlertBoot as part of their data security: DNA TOTAL PROFILE, INC.  DNA TOTAL PROFILE offers bio identity preservation by combining biometrics with DNA for the purpose of identification in the event of a fatality or abduction.  Obviously, their business requires top-notch data security.

    Because bio data is collected in theater where the client is located and then transported to a secure depository for processing, multiple layers of security are utilized to protect client information.  This includes using AlertBoot to encrypt computers used on project sites and at the DNA TOTAL PROFILE, INC. processing center.

    External devices, also encrypted with AES-256, are utilized to ensure data security and integrity during transportation from project sites.  The end product containing the bio identity profile also utilizes AES 256 encryption providing for secure delivery to the client and maintains continuous security.

    As I understand it, the information on computers and external transport devices are ultimately destroyed, using Department of Defense criteria after the bio identity profile is delivered to the client.  (Why don't they use an encrypted internet connection?  Maybe the chances of getting hacked on-line are too big a risk, considering what they store.)

    DNA TOTAL PROFILE, INC. offers an add-on virtual safe through VitalESafe. VitalESafe utilizes SSL during transmission or upload of the record while the virtual safe is encrypted with AES256. 

    Looking at your operations and considering where your weaknesses and troublesome points lie, and then shoring them up: This is data security done right.

  • Learn Easy Ways to Help Your Clients Meet the New HIPAA/HITECH Compliance Rules!

    AlertBoot and eGestalt have partnered up and are offering a couple of free webinars exploring HITECH and HIPAA issues in the digital era.

    "HIPAA/HITECH Compliance Demystified - How to navigate the various requirements with implementation guidelines and best practices" focuses on data privacy and security best practices for medical providers and small businesses.

    The webinar is perfect for managed service providers, managed security service providers and security VARs, IT consultants, and resellers involved in providing service to the healthcare industry aimed at security and compliance.

    Among the topics covered are "how to mitigate potential data losses and leakage" and "how to comply with regulations," among others.

    The webinar is being offered on July 29th July 28th and August 9th.  Click here for more information and to register.

  • HIPAA/HITECH Compliance: Data Privacy and Security Best Practices for Medical Practitioners and Small Businesses

    AlertBoot and eGestalt have partnered up and are offering a couple of free webinars exploring HITECH and HIPAA issues in the digital era.

    Among the topics covered are the Data Privacy and Security related best practices and what can medical providers and small businesses do to deal with HIPAA/HITECH regulation requirements, how to develop the necessary documentation, and what types of fines and liabilities you face under the law, among other things.

    The webinar is perfect for healthcare compliance audiences, compliance managers, and auditors. IT compliance professionals involved in the Healthcare HIPAA and HITECH compliance.

    The webinar is being offered on July 28th July 29th and August 9th.  Click here for more information and to register.

  • Credit Card Encryption Decoded In Hack

    According to, -- a student travel company that specializes in spring break vacation for US college students, according to their site -- notified the NH Attorney General's Office over a data breach.  What attracted my attention is that they're claiming that credit card information that was protected with encryption was broken in some cases.

    266 in NH Affected

    StudentCity knew something was up on June 9, 2011 when I assume people started to call in to complain:

    StudentCity recognized...that it was beginning to receive a pattern of reports from a very small number of students that credit card accounts that were used for purchases.....were subsequently being used to conduct fraudulent transactions."

    According to the letter sent to the NH AG, a database was affected and contained the following: names, credit card numbers, and passport numbers; however, they emphasized that the credit card and passport information was not in the same record for the majority of the cases.

    StudentCity also detailed future plans regarding data security.  They will not collect credit card information going forward (it will be done by a specialized processor) and password numbers will be stored after applying strong encryption on the data. (I guess the implication is that the passport information was not encrypted until now.)

    A total of 266 New Hampshire residents were affected, although the bigger question remains: how many were affected in total?

    Credit Card Information was Stored in Encrypted Form

    One of the more eyebrow-raising aspects of this story is that the hackers were somehow able to crack the encryption used to protect the credit card numbers in certain cases.

    Under PCI-DSS, any credit card numbers that are stored by a merchant (something that a company has to do if their business is based on recurring billing, such as your wireless phone provider) must be encrypted.  AlertBoot, for example, keeps any such information protected with AES-256 encryption.

    Now, what's stupefying is not the fact that encryption was broken.  As detailed elsewhere in this blog, encryption can be broken given enough time; that's why you want to be using strong encryption, where "enough time" is counted in decades if not centuries.

    Based on what I'm reading, I've got to assume that a weak form of encryption was used.  I guess this is a good time to remind everyone that not all encryption is created equal.

    Due to advances in technology was well as data security theory (and research in general), what was once secure will indubitably become anything but.  This is why, for example, DES (Data Encryption Standard), a once widely-used encryption algorithm is not used to secure anything worth securing.

    In fact, it was replaced by AES (Advanced Encryption Standard), which is offered in AlertBoot disk encryption (in 256-bit form).

    Related Articles and Sites:

  • Cost Of A Data Breach: Sony's Insurer Says They Don't Need To Pay

    Did another reason for being proactive when it comes to data security just pop up?  (As opposed to the usual practice of taking a look at data vulnerabilities after it happens?  Because that happens a lot.  You have no idea how many companies decide to deploy laptop encryption software after a computer goes missing).

    According to a lawsuit filed in New York, Zurich American Insurance is suing Sony, stating that they are not under any obligations to indemnify the Japanese electronics company for its massive data breach earlier this year.

    Just to reiterate: this is an insurance company suing its client because it doesn't want to pay for a claim.  That's certainly not something one kind of expects to happen after a data breach.

    Some Definite Numbers and Facts

    The problem with the internet that any rumor is reported far and wide.  I've been waiting to see some official numbers, and what is better and more definitive than a court document?  According to Zurich's lawsuit:

    • 58 class action lawsuits have been filed against Sony (4 of them in Canada)
    • 77 million PSN customers/users were affected by the data breach earlier this year
    • Sony has been investigated "by one or more state attorney general’s offices, the Federal Trade Commission, and the House Subcommittee on Commerce, Manufacturing, and Trade"

    Yep, this is the kind of data breach that is going to cost beaucoup de moolah.  It only makes sense that Sony would have turned to its insurer and said, "hey, time to pay up."

    And, it also makes sense that the insurer turned around and said, "nothing doing, brother."  After all, the potential liabilities are humongous.

    I've noticed that many companies are coming out with coverage for liabilities stemming from data breaches.  An organization may be lulled into believing that, with such insurance, they're covered in the event of a data breach (and subsequent lawsuit).  The above case that things may not be as clear cut.

    The best approach to minimizing exposure from data breaches still involves preventing one from happening.  Call me biased, but I'd take the use of good, strong encryption software over insurance any day.

    Related Articles and Sites:

  • Data Encryption: Beth Israel Medical Says Virus Stole Information

    Beth Israel Deaconess Medical Center in Boston has announced a data breach that affects more than 2,000 patients.  I bring up this news not because the use of data encryption like AlertBoot would have prevented the breach, but because encryption was used by the malware.

    Computer Service Vendor Causes Breach...Kinda

    This breach is an example of one those situations where it's kind of hard to pin the blame.  According to

    The hospital said yesterday that an unnamed computer service vendor had failed to restore proper security settings on a computer after performing maintenance on it. The machine was later found to be infected with a virus, which transmitted data files to an unknown location.

    Should the computer service vendor be blamed?  Perhaps.  But, how are they supposed to know what the "proper security settings" are?  In the course of servicing a computer, settings may have to be changed.  In an ideal world, the contractors would keep track of all the changes they made.

    We don't live in an ideal world.

    Hence, most organizations, if they send equipment to a third party, will perform checks to ensure settings, and other things, are in place before slipping it back into the workforce.  It sounds like Beth Israel didn't perform this check, which means that they're to blame, at least to a certain degree.

    On the other hand, did they have a valid reason to perform this checkup?  For example, the fan on my laptop right now is noisy and fails from time to time.  If I have a vendor fix it, and he changes some settings on my computer, I wouldn't have the slightest clue that he did that because I'm not expecting it.  I mean, why would you change the settings in the software for a hardware problem?

    On the other other hand, these unexpected circumstances are what drive IT departments crazy to the point of laying down the law that all equipment will be checked, no matter why they were sent to a third party.

    Ultimately, I'd say that Beth Israel is responsible despite the involvement of the vendor.  Unless, of course, the virus was transplanted on the computer while the computer was under the vendor's supervision, even if this is the type of "unexpected circumstance" that I referred to above.

    Virus Makes Use of Encryption

    One of the surprising notables about this story is this:

    Halamka [the hospital's chief information officer] said the virus transmitted information in an encrypted form, so the hospital does not know exactly what might have leaked, but wanted to inform patients anyway. []

    Generally, hackers don't use encryption in this way.  I've heard of instances where data is encrypted in order to blackmail the data owners (send me $10,000 or you'll never see the contents of your server again), or of them encrypting their ill-gotten databases when storing them (in case other hackers hack them).  But sending them in encrypted fashion?  Unheard of, at least to these ears.

    On the other hand, if there is any need to keep information secret, the use of encryption software would be the way to do it.

    Related Articles and Sites:

More Posts « Previous page - Next page »