» OWASP

Healthcare Web Applications – The Security Achilles Heel (Part 2)

Posted on by Dan Berger in Main | Leave a comment

Last June, one of my colleagues at Redspin blogged about his concern that security flaws in software applications that house ePHI (electronic protected health information) represent a big threat. We had just completed a security assessment for a client and had found it relatively easy to access their customer portal using a common SQL injection technique. ePHI  records represent tempting targets for cyber crime as they typically include a wealth of personal info (name and address, SSN’s, credit card numbers, DOB and more).

The healthcare industry is currently very motivated to deploy EHR systems, increase interconnectivity via HIE’s, and launch new web applications. As data is made more accessible to more audiences, the risk of a breach increases too. The scope of a HIPAA Risk Analysis should include software applications but be sure to hire a company with specific application penetration testing expertise. Make sure your provider is competent, has relevant experience and applies best practices, starting with the Top 10 Web Application Vulnerabilities list as outlined by the Open Web Application Security Project (OWASP).

Another area of focus should be your internal patch management process. Effective maintenance of your current day-to-day IT operating systems and applications is essential but be sure to conduct an inventory of older applications as well. They may have been developed by people who are no longer with your organization.  Some may perform tasks that are very mundane, highly specialized and/or are rarely used. At Redspin we often uncover these “out-of-sight, out-of-mind” applications in our HIPAA Risk Analysis process. Fortunately we have an application penetration testing methodology that is applicable to both web applications and non-web applications

Force Multipliers for Web Application Security

Posted on by John Reno in Main | Leave a comment

Over the last several years many analysts, including Gartner, have identified application security as the area presenting the most significant risk to companies with internet facing applications. As a result a number of best practices have emerged, ranging from secure coding practices and developer training from organizations such as Microsoft to change management driven black-box testing. However, one area where I see developers and security teams consistently struggle (and often introduce significant vulnerabilities) in terms of application security is with development of their own security controls.

Even with extensive security training, security controls are very difficult to get right. It requires extensive understanding of potential attacks, as well as implementation skill. Furthermore, a lot of things can go wrong – failure to perform output encoding, weak hashes and lack of access control, just to name a few areas.

A leveraged way to solve this problem is to take advantage of the open source work that OWASP has done with the Enterprise Security API.

As shown in the diagram above these libraries cover a wide range of security issues.  They are a standard, high quality and well tested set of security controls that developers should take advantage of. ESAPI is available for a wide range of development environments including Microsoft .NET, J2EE and PHP. This can be an important foundation for an application security program.