According to a poll conducted by Astaro Internet Security, it seems as though security budgets are likely not to get hit as hard by the current economic downturn as I would have expected. Of the over 300 conference attendees surveyed, 67% said that they do not see their security spending behavior affected by the recession in 2008. This is somewhat good news, and it puts a tiny ray of hope into my usually dreary view of the general corporate commitment to security. I’ve lamented on several occasions the fact that security is seen as more of a “because we have to” expenditure rather than “because it’s a good idea”. My first thought would be that, when times get lean for[…]

In a recent case in Arkansas, a registered nurse has pleaded guilty to violating HIPAA rules by disclosing confidential patient information for personal gain. No one should be surprised that things like this happen. Every industry has laws, regulations and penalties set up for the purpose of consumer (and business) protection. In the health care industry, there is and has been an enormous amount of money spent to bring processes and systems into compliance with regulations like HIPAA to try to protect patient confidentiality. You can lock down electronic systems as much as you want, but nothing can ever be truly secured, because of one simple fact – these systems are owned and operated by people. A “weakest link” analogy[…]

I was at the Microsoft Health and Life Sciences Developer Conference last week in Atlantic City, where I got the chance to listen to a good presentation from Les Jordan of Microsoft about 21 CFR Part 11 compliance. The talk centered around how Microsoft is trying to make dealing with the V Model more manageable for validated application as it pertains to applying security patches. One interesting point that was made was that if there is a security patch available for a validated system, and that patch has not been applied to that system, then the system is not considered by the FDA to be compliant. However, full qualification tests must be run and documented while applying the patch, which[…]

Seriously, folks. This is just unacceptable. The amount of effort put into securing an application needs to be proportional to the importance and sensitivity of the data. A SQL injection vulnerability that allows addition of records to the sex and violent offender registry? Are you kidding me? This wasn’t a “bad credit” kind of a security hole, this was a “completely ruin somebody’s life” kind of security hole…and the steps required to exploit it aren’t exactly rocket science. Given the description of how much effort it took to get the hole patched, it doesn’t sound like these developers should have ever been let within 10 feet of a computer, let alone a Department of Corrections application. How does this happen?[…]

Pascal Meunier writes The entry for CVE-2006-4339 reached 16941 bytes, with 352 references. This is an OpenSSL issue, and highlights how much we are dependent on it. Vulnerabilities in any security suite aren’t something you ever want to hear about, particularly something as ubiquitous as OpenSSL. Whenever you use an application that has SSL capabilities, there’s a good chance you’re relying on OpenSSL for security, especially if the software doesn’t come from a company that has its own proprietary security suite (such as Microsoft or Mozilla). VMWare, Opera, various products from Sun, any Apache instance using mod_ssl…there’s a lot out there that needs to be patched right now. You may want to do a quick search of your systems for[…]

The MSDN documentation for CertGetCertificateChain is pretty unclear when describing how the CERT_CHAIN_TIMESTAMP_TIME flag relates to the pTime parameter. The documentation for the function can be found here. The pTime parameter is described like this: A pointer to a FILETIME variable that indicates the time for which the chain is to be validated. Note that the time does not affect trust list, revocation, or root store checking. The current system time is used if NULL is passed to this parameter. Trust in a particular certificate being a trusted root is based on the current state of the root store and not the state of the root store at a time passed in by this parameter. For revocation, a certificate revocation[…]