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.

November 2018 - Posts

  • HIPAA Notifications Are Now Within 30 Days Since Breach If You're In Colorado

    According to, any HIPAA-covered entities that do business in Colorado will now have 30 days to notify Coloradans (or Coloradoans, if you prefer) of a data breach involving personal information, and not the customary 60 calendar days under HIPAA. The reason? A bill on data security that went into effect in September.
    As usual, the use of encryption provides safe harbor. Indeed, the bill – HB18-1128 – goes out of its way to define data breaches as unauthorized access to "unencrypted" personal information. Furthermore, it notes that cryptographically protected information is still subject to the reporting requirements if the encryption key is compromised; that "encryption" is whatever the security community generally holds to be as such; and that a breached entity does not need to provide notification if it determines that "misuse of information… has not occurred and is not reasonably likely to occur."
    In the past, variations of that last part were heavily criticized. Naturally, it's in the breached entity's interest to declare that there won't be misuse of the hacked information, ergo no need to inform anyone about it. In 2018, however, it'd be a laughable position to take.  

    Surprising Development? Not Really

    Colorado's "encroachment" on HIPAA can take one aback but this would be merely a knee-jerk reaction to unfamiliar news: to date, if one was covered under HIPAA, state privacy and information security laws left HIPAA-covered entities alone. But there's absolutely no reason for it. After all, it wouldn't be the first time that a state decided to pass laws that are more severe than federal ones.
    Furthermore, think about the purpose of notifications. Supposedly, it's so (potentially) affected individuals can get a start on protecting themselves. If the past ten years have shown us anything, it's that receiving a notification 30 days after the discovery of a data breach can already be too late. In that light, waiting 60 days could be disastrous.
    It's a wonder that HIPAA hasn't updated its rules to reflect reality. HIPAA was, arguably, a trailblazer when it came to protecting personal information, with its no-nonsense approach and enforcement of the rules. That last one was a biggie: When Massachusetts General Hospital (MGH) was fined $1 million in 2011 – the largest amount at that time for a data breach – the medical sector not only took notice, they went into action. At minimum, entities started to encrypt their laptops; those paying attention did far, far more.
    At the time, HIPAA's 60-day deadline was seen as revolutionary by some (if memory serves, existing data breach laws didn't codify a deadline for alerting people). Of course, companies being what they are, covered-entities ended up doing as most people feared would do: they put off sending notifications for as long as possible, like mailing letters on the 59th day.
    Not everyone did this and HIPAA specifically prohibited the practice. A handful were fined as a result of purposefully delaying the inevitable. But waiting until the last possible moment to send notifications appears to be the ongoing behavior, regardless. The same thing happens for non-HIPAA data breaches, except that most states have set a 30-day limit, so companies send it on the 29th day.  

    Update Those BA Docs!

    Unsurprisingly, Colorado's law also affects business associates to HIPAA-covered entities. All hospitals, clinics, private practitioners, and others in the medical sector should immediately update legal documents that establish obligations between themselves and BAs.
    Remember, a covered entity's data breach is the covered entity's responsibility, and a BA's data breach is also the covered entity's responsibility.  


    Related Articles and Sites:

  • Leading Self-Encrypting Drives Compromised, Patched

    Earlier this week, security researchers revealed that certain SEDs (self-encrypting drives) sold by some of the leading brands in the consumer data storage industry had flaws in its full disk encryption.

    Bad Implementation

    One of the easiest ways to protect one's data is to use full disk encryption (FDE). As the name implies, FDE encrypts the entire content of a disk. This approach to protecting files ensures that nothing is overlooked: temp files, cached files, files erroneously saved to a folder that was not designated to be encrypted, etc.
    There is a downside to full disk encryption: it can slow down the read and write speeds of a disk drive, be it the traditional hard-disk drive or the faster solid-state drive (SSD). In order for a computer user to work with the encrypted data it must be decrypted first. This extra step can represent a slowdown of 10% to 20%. Not the best news if you invested in SSDs for the bump up in read/write speeds.
    The downside mentioned above, however, is mostly true when software-based FDE is used; that is, you used a software program to encrypt the disk, like Microsoft's BitLocker. For SEDs, the "self-encrypting" portion of their name comes from the fact that an independent chip for encrypting and decrypting data is built into the storage device. That means there is no impact in reading and writing data. It does mean, however, that you've got a new point of failure when it comes to data security. If the chip is not secure enough, it could lead to a data breach.
    The researchers were able to extract the encrypted information by modifying how these chips behave. It was hard, time-consuming work but they figured out how to bypass the encryption entirely. In certain instances, they found that the data wasn't encrypted at all due to a misconfiguration. You can read the details here.
    If you read the paper, you'll notice that the data hack is not for the faint of heart. While certain security professionals have decried the incompetence in how the SEDs' encryption was implemented – and truth be told, they are right. Some of these workarounds are very Wile E. Coyote – finding these flaws would have been nearly impossible for mere mortals, non-professionals, and amateur hackers.
    Indeed, it's quite telling that it took academic researchers to shine the light on the issue.

    BitLocker "Affected" As Well

    Oddly enough, BitLocker, arguably the most deployed full disk encryption program in the world today, was affected by the SED snafu. How, you may ask, seeing that BitLocker is software-based while the security issue affects hardware-based encryption?
    By default, BitLocker hands the reins over to SEDs if disk encryption is turned on, assuming an SED is being encrypted. On the surface, deferring to the SED encryption makes sense. People don't care how their data is encrypted as long as it is encrypted, and foregoing software-based encryption means there is no performance hit. It appears to be win-win.
    (There is a group policy setting to override this behavior. Security professionals recommend that this setting be used going forward. Being security professionals, it makes sense they'd place more weight on security than performance.)

    Trade-Off: Speed vs. Transparency

    Relying on hardware-based encryption, however, means that you're relying on Samsung, Crucial, and other hardware manufacturers to implement encryption correctly. Have they? There isn't an easy way to know because they're not transparent about the design and implementation. The revealed vulnerabilities could be all there is to it… or could represent the tip of the iceberg.
    Hence the recommendation by the pros that software-based encryption be used: any solution that is worth its salt will ask NIST to validate it. Sure, the process is long and expensive; however, the ensuing uptick in business more than makes up for it. While NIST's stamp of approval does not guarantee perfect security (possibly not even adequate security), it does remove the possibility of terrible security implementation like the ones witnessed this week. And even if it's not validated, the ones that are transparent allow for examination. If something's is glaringly wrong, it will be found and noted by researchers.
    All of this being said, confirms that companies have either come out with firmware patches for the vulnerabilities in question or are working on it. Apply those as soon as possible, and rest easy (or easier) that your data will be safer by doing so.
    Related Articles and Sites: