When I first read the article Authy Makes Using Two-Factor Authentication Easier I thought to myself, “why have I never heard of this Authy thing?” After all, we have been covering two-factor for a while. I went ahead and installed it, and started digging into the application and the company. I even fired off some questions about how they treat the information in the application and I’m impressed. This application is advancing the state of the art for two-factor authentication by making it not just simpler to use, but more secure as well. This article is covering how Authy is simplifying the use of two-factor authentication. Next week I’ll publish another article about how they are also advancing the state of[…]

There are quite a few tools readily known to the Android reversing community. The primary one is most likely smali/baksmali. It’s an open source tool which will decompile/compile an android dex format which is used by dalvik the native Android VM, into a format known as smali, which is very similar to an assembly language. A lot of people even like dex2jar, which further enhances the experience and takes a broken down apk, and pulls out the compiled dex classes. With dex2jar you can further that and attempt to get some readable jar files. If you wanted to make it even simpler you continue with that jar and use something like JD-GUI to read those jars back into native java code and be off running. For the lazy, there’s also the apktool which does most of the above for you in a simple one-stop-shop.

These are all great tools, but what else is out there? That’s what I’ll be covering in the next few articles. Today I’d like to point your attention to JEB (http://java-decompiler.com). I discovered this back in February when it made its first public release. At the time, I was knee deep in doing Android Application Security Assessments as part of our IPA process. I was still primarily using the tools mentioned above, so it was nice not only to find something different (it doesn’t use the open source smali as the decompiler), and it’s a nice all-in-one solution for exploring the code, as well as analyzing it.

Should Reasonably Have Known The HIPAA Breach Notification Rule has an interesting turn of phrase: “should reasonably have known”.  A company is liable if they reasonably should have known about a breach.  So what is reasonable?  The latest 2013 rulemaking gives some guidance on that:  §164.404(a)(2) expands that to reasonably should have known by exercising reasonable diligence.  And then goes on to define it as “business care and prudence expected from a person seeking to satisfy a legal requirement under similar circumstances”.  Further adding that as soon as a workforce member or other agent has knowledge or should have had knowledge of the breach, the clock on notification starts. So, you’ve got some relatively vague definitions of what’s reasonable, and as soon as someone[…]

This article describes the HIPAA contingency planning and security incident response requirements. The relevant subsections of the HIPAA law are §164.308(a)(6) and §164.308(a)(7).  HIPAA contingency planning is a term used broadly to cover security incident response procedures and contingency planning for emergency situations that may compromise protected health information. HIPAA contingency planning is one of the administrative safeguards that a covered entity must employ. The audit requirements for HIPAA contingency planning is covered in a separate post. HIPAA Security Incident Procedures “Implement policies and procedures to address security incidents.” [§164.308(a)(6)] A covered entity is required to be able to identify, mitigate and respond to security incidents in a timely and reasonable fashion. The procedure for responding to security incidents should be[…]

This article describes the HIPAA information access management requirements for accessing electronic protected health information. The relevant subsection of the HIPAA law is §164.308(a)(4).  Section §164.308 of the Health Insurance Portability and Accountability Act describes the administrative safeguards that a covered entity must employ. This article will explore section §164.308(a)(4), which deals with ensuring that appropriate authorization mechanisms are in place when electronic protected health information (ePHI) is accessed. HIPAA Information Access Management “Implement policies and procedures for authorizing access to electronic protected health information that are consistent with the applicable requirements of subpart E of this part.” [§164.308(a)(4)] A covered entity is responsible for isolating and guarding ePHI from unauthorized access. This section outlines the implementation requirements of a covered[…]