Now, I have to apologize for sneaking up to my esteemed colleague Michael Farnum and sticking him with a scalpel :-) I had to board a plane to London to present at CESG/GCHQ tomorrow and so I dropped out of the mayhem .... eehhh .... discussion that ensued.
As I am sitting in hotel in Cheltenham with sheep wondering around the place, I am noticing that this discussion has grown - and became even more interesting.
So please read:
As I am sitting in hotel in Cheltenham with sheep wondering around the place, I am noticing that this discussion has grown - and became even more interesting.
So please read:
- Initial discussion with a link to a paper here
- Longer follow-up from Mike Farnum is here (scalpel bit is explained too :-))
- "Mr Hoff Strikes Back" discussion is here
- Security team usually does not own the 'A' - IT does. If you think "IT availability" equals "DoS defense", your view is painfully narrow
- It sucks that some folks chose 'A' over 'C-I-A', but they do!
- It often takes some effort to explain why people need to care about 'C' and 'I' (no matter how painfully obvious it is for security folks!), but you never have to explain the 'A' part
- Yes, if your data is corrupted ('I' violation), then obviously the right data is not available (leads to an 'A' violation), but this is actually far less common today compared to the following: a crappy solution is deployed to guard 'C' and 'I'; it flakes out and takes 'A' with it ... oops!
- I also disagree with taking it too far to "security against availability" (even those it happens sometimes, especially in the form of "security vs performance" or "security vs usability"); security is definitely not the opposite to availability.
- Information / IT risk management definitely covers all of C-I-A risks; thus, a security team might not be responsible if a lighting strikes a server, but such scenario must be considered in IT risk assessments.
