SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 

The Achilles Heel

By Phil Factor,

When a company experiences a data breach, or a catastrophic IT failure, there are often some pathetic and unedifying manoeuvres by the senior management to deflect blame onto a single subordinate or team. It is ridiculous to attempt to convince the public that this is a viable explanation. If IT management has done its job properly, there will be a strategy in place that dictates that resilience or security is layered, meaning that even if someone accidentally fails to maintain one line of defence, there are still several other lines. Besides, any successful intrusion, or node-failure, will surely be detected? I can't remember a single catastrophic failure or breach that hasn't been due to a whole plethora of slack and ignorant practices.

It is true that, in many cases, one can pinpoint the moment when all was lost. For example, that developer should never have used the placeholder 'Dear Rich Bastard' when testing the new banking software. The Ops guy shouldn't have switched the UPS for the production server off and on again. The developer should have created a new feature switch rather than reuse an old one. The web developers shouldn't have created SQL Queries by concatenating strings from an input form. However, in every case, that was just the tipping point, within the context of a security or resilience architecture that was rotten.

When things go wrong in engineering, architecture or software, we can learn a great deal from a frank and meticulous autopsy. Sadly, we find that, unlike other industries, we only get the details of IT failures when matters go to court or public inquiry. This makes it harder to win the battle against the cyber-criminal. This information is educational. In much the same way that airline pilots pore over the accounts of safety incidents, it pays dividends to understand exactly how IT security breaches happen. I wish that there was more of this information in the public domain, but there is enough to rid yourself of any complacency. Security and resilience have to be an intrinsic part of IT culture.

In my own work in auditing database systems, I never came across an incident where a system had failed due to a single 'Achilles Heel', or even a single team of people. A well-run IT department has procedures and policies that prevent the classic mistakes made by people under pressure from causing any more than a temporary inconvenience. They also prevent villainy and malignance. It is only when IT Departments fail in promoting a culture that recognises the importance of this, and doesn't allocate resources to plan and implement this properly, that the bad things that sometimes happen in IT result in catastrophe rather than mere embarrassment.

Phil Factor.

 
Total article views: 65 | Views in the last 30 days: 1
 
Related Articles
ARTICLE

Data Breaches

Security is hard, but are we doing a good job? Steve Jones shares a few thoughts on our security dev...

BLOG

Is There Interest in SQL Server Security Pre-Cons?

I’m very passionate about security, especially database security. As the numbers with regards to dat...

BLOG

More On The Target Breach

Over the past week there has been information finally coming out about how the Target breach occurre...

ARTICLE

Data Breach Danger

Is a data breach a danger to those identified in the data. A court says no, but Steve Jones wonders ...

ARTICLE

The Biggest Data Breach (For Now)

JP Morgan suffers the largest data breach for a financial institution, but Steve Jones doesn't think...

Tags
database weekly    
editorial    
 
Contribute