RE: RAID 5 drive replacement schedule

["Rivest, Philippe" <PRivest () transforce ca>]

Im not to sure about which part of my previous post you think is up to
interpretation, if you could clarify that would help.

But for your scenario:

If I understand correctly your scenario, I know it's a resume, but it is
flawed in the basic concept of availability.

If you have a safe box, with a door and a lock on it. No body can access the
box and it is only available to the key holder (hence confidentiality and
integrity could be assumed to be good). If this is the situation you stated
then here is the concern for availability. What if the key is lost? What if
the door lock is damage and can no longer open?

If you go about to keep a second (back up) key pair, you would consider this
availability safeguard. If you had another way to get in the room with the
box, that would also be considered a backup safeguard for availability.


Hope this helped.

Merci / Thanks
Philippe Rivest, CEH
Vérificateur interne en sécurité de l'information
Courriel: Privest () transforce ca
Téléphone: (514) 331-4417
www.transforce.ca


-----Message d'origine-----
De : listbounce () securityfocus com [mailto:listbounce () securityfocus com] De la
part de Nick Vaernhoej
Envoyé : 20 juin 2008 14:15
À : security-basics () securityfocus com
Objet : RE: RAID 5 drive replacement schedule

Philippe,

Any chance this is a bit up to interpretation?
If you build a box with no access the inside is for the sake of argument
"safe".
If you add a door it is available, but only as far as the architect is
concerned.
If you add a lock to the door and lock it, the inside is once again "safe".

Here is my interpretation of the availability topic, when you give the key to
the users of the box you have ensured availability as it applies to security.

Let me know if I am way off :-D

Nick Vaernhoej
"Quidquid latine dictum sit, altum sonatur."


> -  -----Original Message-----
> -  From: listbounce () securityfocus com
> -  [mailto:listbounce () securityfocus com] On Behalf Of Rivest, Philippe
> -  Sent: Friday, June 20, 2008 12:24 PM
> -  To: Adriel Desautels; Murda Mcloud
> -  Cc: security-basics () securityfocus com
> -  Subject: RE: RAID 5 drive replacement schedule
> -  
> -  Adriel & Murda
> -  
> -  It is a security issue the way you store your data. In regards to the
> -  raid
> -  technologies, raid 5 improves the availability of the data by making
> -  sure
> -  that a single drive failed will not impact the availability of the
> -  data.
> -  
> -  Remember that security is
> -  1- Confidentiality
> -  2- Availability
> -  3- Integrity
> -  
> -  The main goal of a Raid 5 is to help #2. You are referring to the
> -  disposal of
> -  the HD which is the issue of confidentiality and that is not what
> -  Murda was
> -  aiming at. If it is, go for encryption, degaussing, destruction and
> -  just
> -  plain format (if the data is not confidential).
> -  
> -  As I explained to him offline, the MTTF and MTBF is about the same
> -  for 2 HD
> -  bought/constructed at about the same time. How ever, those are not
> -  absolute
> -  numbers that state that, if one drive fails the other one is about to
> -  go too.
> -  It's more an estimated value against which you should have some
> -  confidence/hope, your drive should not fail before X hours (it could
> -  go
> -  before but the average is X).
> -  
> -  In a raid 5, Drive A, B and C are online and working (they are the
> -  same drive
> -  bought at the same time). Drive A fails, you should NOT change drive
> -  B & C
> -  unless they are failing also. If you do, the cost of your raid 5 will
> -  be
> -  greater then what it should be (the replacing of the parts are going
> -  to cost
> -  a lot). Change drive A and hope drives B & C will last longer.
> -  
> -  
> -  The only issue is that 2 drives fail at the same time, which is very
> -  improbable. And if it does, you should be going for your back ups.
> -  
> -  
> -  I do hope this clarified the questions and that I wasn't to unclear
> -  with my
> -  details!
> -  
> -  Merci / Thanks
> -  Philippe Rivest, CEH
> -  Vérificateur interne en sécurité de l'information
> -  Courriel: Privest () transforce ca
> -  Téléphone: (514) 331-4417
> -  www.transforce.ca

This electronic transmission is intended for the addressee (s) named above.
It contains information that is privileged, confidential, or otherwise
protected from use and disclosure. If you are not the intended recipient you
are hereby notified that any review, disclosure, copy, or dissemination of
this transmission or the taking of any action in reliance on its contents, or
other use is strictly prohibited. If you have received this transmission in
error, please notify the sender that this message was received in error and
then delete this message.
Thank you.