Web Security Breaches and Accountability

By Zack Sanders – Security Expert – APconnections

If this recent story about a breach of medical information in Utah is any indication of how organizations will now handle security breaches, technology managers everywhere should be shaking in their boots. After a breach that exposed personal information of 780,000 people, the Utah state technology director was relieved of his position by the governor, and several others are under investigation.

Details of the actual attack are scarce, but it appears as though a medicaid server (possibly hosted in the cloud) was vulnerable to a security misconfiguration at the password authentication level. This could mean a few different things – including SQL injection issues, exposed configuration files, or that content was accessible without actually logging in. Regardless of how it really occurred, it certainly could have been prevented with proper proactive assessments.

The larger issue at hand that the article touches on is accountability in data security. Personally, I think you are going to have a hard time finding organizations that will guarantee their solutions are totally secure. It’s just not realistic. You can never be 100% protected against an attack, and because software solutions often rely on other technologies and people, the amount of ways in are many and proving exactly how someone got in and who is to blame will be difficult considering that vulnerabilities are often leveraged against each other. For example, say you have a server that has a third party web application, a back-end database, and blog software installed. The web application itself is secure, but the blog software is not. It is breached by an attacker, and the database for the web application is stolen. User data in the database was not encrypted, and wide-spread fraud occurs. Who is to blame? The blog maker? The web application developer? The system administrator?

In truth, the answer is everyone – to varying degrees. The system administrator should not have these two software packages running on the same system. The blog developers should have built a better solution. The web application programmer should have encrypted data at rest. Blame can even shift further up the chain. The IT director should have budgeted more money for security. The board members should have demanded proactive actions be taken.

So, it is likely the firings in the Utah Medicaid breach were mostly political in that someone has to fall on the sword, but in truth, the blame should fall on many individuals and companies.

One thing is clear, if you are a technology director or manager, you don’t want this to happen to you – but there are actions you can take. The most important thing is to BE PROACTIVE about security. How many breaches do you have to read about every day before you take charge in your own environment. If you’ve never been hacked, ask someone who has. It is a very painful process and costs reputation, money, and time. Start taking steps today to better your chances against attack. Some options to consider:

– Have quarterly security assessments conducted.

– If major changes to the application or server are made, have those changes reviewed for security.

– Discuss your security controls with an expert.

– Audit your existing infrastructure and start making changes now. Even though this will take time and resources, it does not compare to the time and resources required if a breach occurs.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: