Thursday, October 14, 2010

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 :-|

Saturday, October 9, 2010

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:

Tuesday, October 5, 2010

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".

Thursday, September 16, 2010

An interesting use of Google Trends

Google Trends is a nice tool that gives you statistics about the terms used in Google web searches, in the form of curves. For instance, you can compare the curves of iPod, iPhone and iPad:


But there's also another interesting part, on the right: it gives you links to articles that were published at the moment when a peak occurred. The moments are correctly chosen for buzzwords like in this example, not always as well chosen for less marketing-oriented products. Anyway, that's often a way to apprehend the history of a technology, idea or movement.

Have a look at these curves:

Tuesday, September 14, 2010

Security ROFL

Let's have some fun about security.

Monday, September 13, 2010

Zero Risk vs. Decision Making

The ability to produce risk assessment, partly-innate, partly-acquired, is one of the most basic skills of successful managers.

While there is much value in the organized and systematic research for accurate information, the ability to assess risks in a situation where information is incomplete is a most valuable asset.

The first reason is that we often lose precious time in the gathering and precise analysis of data when approximate data would be good enough. To make it abruptly: you don't need to know where the arrow will hit to know that an arrow sent grossly in your direction is a bad thing. That's when you need someone with some instincts about risks.

The second reason is that some data can be impossible to gather, or hard enough to slow down the process of gathering it to the point of discouragement. For instance, if you want to pinpoint the ability to turn on a specific option of a specific security feature in a specific version of a specific software, which software you have not already bought and cannot test, you might get bored before you get the information. That's when you need someone with some culture and work connections, so as to get a better access to -or approximate substitute for- such information.

The third and most important reason is that management people delegate. In this case, the management would probably want to delegate data collection and make its own assessment from it and make a decision from it. That is, delegate the boring part and make the obvious decision (taking all the credit, Dilbert-like).

To be more precise, it is commonplace to see IT managers answer a question by another question, asking for more technical details when the staff come for more decision making. In this case, the staff ask the manager for his/her ability to fill in the gap between available information and complete information. (And the staff is probably aware of this gap.) So when the manager overlooks this request for decision and asks for never-ending technical or economical details, data or evidence, the staff feels like the manager is worthless. That is: once they have collected all the data, they can make the decision themselves, they're not stupid, thank you!

As a conclusion, I would say that Zero Risk is, of course, not reachable, but that managers should be aware that their staff regularly look for risk assessments from them, not for an indication that they should go and look deeper to reach Zero Risk. If they could, they would.

Saturday, September 4, 2010

IT and ITsec books I've read these last years

These last years, I've read a few interesting books about IT and IT security, so I list them down here, if you ever got a spare week-end ^^
The list starts with the language, name and author(s) of the book then, when possible, links to related blogs and newsfeeds. It's in no particular order.
  • [EN] The failure of Risk Management, Why It's Broken and How to Fix It, by D.W. Hubbard [BLOG] [RSS]
  • [EN] Applied Security Visualization, by Raffael Marty [BLOG] [RSS]
  • [EN] The Official (ISC)² Guide to the CISSP CBK, aka the CISSP CBK, by... the (ISC)²
  • [EN] Beautiful Security, by Andy Oram and John Viega
  • [FR] La fonction RSSI (The CISO position), by Bernard Foray [old BLOG] [old RSS]
  • [EN] The New School of Information Security, by Adam Shostack and Andrew Stewart [BLOG] [RSS]
  • [EN] Security Warrior, by Cyrus Peikari and Anton Chuvakin [BLOG] [RSS] [Cyrus Peikari's page, see "Articles"]
  • [EN] Security Metrics, Replacing Fear, Uncertainty and Doubt, by Andrew Jaquith [BLOG] [RSS]
  • [FR] Sécuriser ses échanges électroniques avec une PKI, Solutions techniques et aspects juridiques (Securing Electronic Flows with a PKI, Technical Solutions and Legal Matters), by Thierry Autret, Laurent Bellefin and Marie-Laure Oble-Laffaire
  • [EN] The whole ITIL v3 series
  • [EN] Geekonomics: The Real Cost of Insecure Software, by David Rice [BLOG] [RSS]
EDIT 09/06: Oh and I forgot the mythical The Mythical Man-Month, by Fred Brooks [Wikipedia]