Admit or not, all systems will have failures, those happened or those still are hidden. There is no exception for security system. Being a complex system, there are too many links involved in, from algorithms to implementation. Failures are just buried here and there in these links, and any such failure can be the weakest link of the whole system.
Ok, failure is something we have to live with. But how to minimize the catastrophic effects created by these failures?
I would think that the emerging design philosophy, Designing for Failure, might be one solution.
The way we are used to in software development is designing to Work, which is focusing on how to get things done and trying to minimize the errors along the way. This traditional way is deeply implanted in our mind. We always tend to think in one track, the track that the softwares suppose to work. How about the side tracks? Just pop up a error message box? Or throw an exception? Anything better than a Blue Screen can be considered as appropriate. Anyway in this philosophy failures are not expected, and if they do happen, too bad.
But in the security world, things are very different. Security systems are dealing with serious problems, so serious that anything must be handled. If you don't handle the failures, the adversaries will gain and you will have loss.
So in the paradigm of Designing for Failure, we must first pessimisticly evaluate all the possible failures. We have to admit the chances that such failures might be there, even when we are very confident on our design and implementation. Then we need to answer the question, "if this failure happened, what should the system to react?" We should design the capability of identifying failures and responding to failures into the security system. With such capabilities designed in, at least we should know that something bad happened. It will be even better if we can respond to the bad things to minimize the damage.
To use an analogy, you should put cushion barriers here and there when you design a F1 racing track. The more you put, the more possible you will save a life.
Ok, failure is something we have to live with. But how to minimize the catastrophic effects created by these failures?
I would think that the emerging design philosophy, Designing for Failure, might be one solution.
The way we are used to in software development is designing to Work, which is focusing on how to get things done and trying to minimize the errors along the way. This traditional way is deeply implanted in our mind. We always tend to think in one track, the track that the softwares suppose to work. How about the side tracks? Just pop up a error message box? Or throw an exception? Anything better than a Blue Screen can be considered as appropriate. Anyway in this philosophy failures are not expected, and if they do happen, too bad.
But in the security world, things are very different. Security systems are dealing with serious problems, so serious that anything must be handled. If you don't handle the failures, the adversaries will gain and you will have loss.
So in the paradigm of Designing for Failure, we must first pessimisticly evaluate all the possible failures. We have to admit the chances that such failures might be there, even when we are very confident on our design and implementation. Then we need to answer the question, "if this failure happened, what should the system to react?" We should design the capability of identifying failures and responding to failures into the security system. With such capabilities designed in, at least we should know that something bad happened. It will be even better if we can respond to the bad things to minimize the damage.
To use an analogy, you should put cushion barriers here and there when you design a F1 racing track. The more you put, the more possible you will save a life.
posted by Joe at 9:49 AM
0 Comments:
Post a Comment
<< Home