Leadership Learning 2: When a Security Measure Fails, Put it Away!

Just a lesson of common sense: when some security tool or practice is useless because it was ill-designed or because it's broken, or because the rationale behind it has disappeared, it's better to just get rid of it.

Just two examples:

• British Airways Chief Slams US Security Requests (Slashdot)
• New Orleans Scrapping Surveillance Cameras (Bruce Schneier)

Fun fact: Facebook Bug in Handling Who Accesses Photos

I just experienced a funny bug: Facebook lets me view photos of someone who is not a "Friend" anymore :-)
OK, it's not in every case, it's just when I had written comments on a photo and someone writes additional comments.

Say I have written a comment in March, on a photo by a friend named Alice (pseudo) :

And then Alice and I stop being "Friends" in Facebook. She doesn't allow anyone but her friends to access photos, so I shouldn't have access anymore. But today someone else writes a comment on that same photo and I receive a notification.

Let's click on the link to Alice's photo. Nice, I can view that old photo again! That I should be let in to see that photo and any additional comments is subject to discussion.

However, the big bug is that I can click on "Back to Album" and I get the complete album, which I certainly should not:

I don't know whether that's a common case or just a kind of local bug or exception...

A little thought about computing clouds and physical security

Clouds are not so cloudy that they don't sit on God's green earth.
I was thinking that with so much data concentration, and data of so much value, what would prevent people to break physically into data centers to rob data?

After all, who says data banks says data hold-ups...

I can think of four reasons why they wouldn't make a hold-up to steal data from a data center:

1. It's probably easier to steal it online.
2. It's certainly safer to steal it online.
3. If you're breaking into a place you've never been, finding what you're looking for may be messier for a data center than for a bank.
4. The adoption rate of this kind of crime would probably be very slow: burglars are not accustomed to data centers and black hats are not accustomed to hold-up parties. They probably don't share a lot of "good practices".

Yet, these barriers do not seem to apply to States and polices. They can easily break into a data center, they do not fear any defence from the "victim", they have all the time they need, and they probably can gather people accustomed to both heated situations and computer hacking.

So I was thinking that data of interest to a State should probably not be stored within its reach.

However, I don't have a clue how the visibility of a criterion such as the geographical situation of data may evolve in the next years for the cloud customer :-|

Back on the technology SPOF: practical case

A reader commented in private that the article about the technology SPOF was too abstract and lacked a few simple illustrations. The opposite would have been surprising ^^ The subject seems universal, which is no reason not to give a good example.

So, there I have it, example with an "all-in-one" security appliance, as is too often so often used in SMBs. It's mainly sold as a corporate firewall and serves many other uses.

The first SPOF is the hardware one. When the hardware fails, you've got a problem:

You can resolve that SPOF by adding another piece of hardware:



The second kind of SPOF is the network one. You have the backup hardware, but it's not available:

In this case, it's completely useless... You can solve this problem by making sure that the access to the redundant appliance is also redundant:


The third kind is the configuration SPOF. The backup is ready, working and available, but it's not used because clients are not configured to use it. For instance:

For this, you just have to configure the backup to be used in case of problem on the master or, if it's not possible, to setup an emergency procedure that switches from a configuration with the master to a configuration with the backup. That should look like:


Finally, and that the point in my previous post, you've got the technology SPOF, which means that both the master and the backup suffer from the same problem. This could be anything from "disk full" to "corrupted configuration file" ranging through "expired license". In this case, it's no help that you have a backup:

You just have to be sure about the list of the services you provide with that specific technology, and which of those are critical enough to require a reduced/degraded mode:

Monthly ITsec Leadership Quotes and Articles: September 2010

Back from vacations in Tunisia ^^

• "Managers spread powerlessness by limiting information", Rosabeth Moss Kanter in July-August HBR.
• "The powerless retaliate through subtle sabotage. They slow things down by failing to take action-a form of pocket veto, in which a bill is killed simply because time runs out", Rosabeth Moss Kanter, same source.
  
• "Drawing a line between strategy and execution almost guarantees failure", Roger Martin, same source. The whole article is a jewel. A must-read for many managers.
  
• "Antagonizing the performance engine [vs the innovation engine] is a really bad idea. The performance engine always wins in an all-out fight. It is, quite simply, bigger and stronger." by Vijay Govindarajan and Chris Trimble, same source. So true about security if you take performance=IT and innovation=ITsec...
  
• "I don't see the legal advisor as a fusspot, always waving his law-code book. On the contrary, he/she must escort the company through its development and minesweep the legal area.", Sabine Lochmann, in the French review "Management", issue number 179 (my own translation). I feel exactly the same about the company's security officer.
  
• A disturbing disconnect between CSOs and CIOs
• Put down the pink stickies to improve your career
• Too Perfect to Be an Effective Security Manager?, follow-up to the previous one.
  
• Do All Hospitals need a CISO?
• Zero Trust Security – The Technical Discussion, good note on the now-obsolete MZ/DMZ model and the fact that silos should never be considered "safe".