Home page logo
/

basics logo Security Basics mailing list archives

Re: RAID 5 drive replacement schedule
From: Adriel Desautels <adriel () netragard com>
Date: Fri, 20 Jun 2008 16:43:11 -0400

Nick,
I agree with your interpretation and this is why I have issues with things like "CYA". The definitions that the "security industry" uses as a whole are not always clear and do not always define. PCI-DSS is just one example of many that do not clearly "define" what, how, who, when, etc.

I think that we, the "security industry" need to define things clearly so that the boundaries are fully understood. Availability with respect to security is a fuzzy boundary at best.

Isn't it the case that information being stored on a computer that has been shut down and is no longer available is secure? I think so, but that also depends on a lot of different things. Guess it also depends on how one defines secure doesn't it?

Regards,
        Adriel T. Desautels
        Chief Technology Officer
        Netragard, LLC.
        Office : 617-934-0269
        Mobile : 617-633-3821
        http://www.linkedin.com/pub/1/118/a45

        Join the Netragard, LLC. Linked In Group:
        http://www.linkedin.com/e/gis/48683/0B98E1705142

---------------------------------------------------------------
Netragard, LLC - http://www.netragard.com  -  "We make IT Safe"
Penetration Testing, Vulnerability Assessments, Website Security

Netragard Whitepaper Downloads:
-------------------------------
Choosing the right provider : http://tinyurl.com/2ahk3j
Three Things you must know  : http://tinyurl.com/26pjsn


Nick Vaernhoej wrote:
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.

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault