Comments on: A list of the fundamentals for security http://www.securitycatalyst.com/blog/2007/07/a-list-of-the-fundamentals-for-security/ changing the way people protect information Thu, 04 Dec 2008 01:28:53 +0000 http://wordpress.org/?v=2.6.3 By: The Compliance and Security Connection http://www.securitycatalyst.com/blog/2007/07/a-list-of-the-fundamentals-for-security/#comment-1876 The Compliance and Security Connection Wed, 08 Aug 2007 19:48:44 +0000 http://www.securitycatalyst.com/2007/07/30/a-list-of-the-fundamentals-for-security/#comment-1876 <strong>What do you think the fundamentals of security are?...</strong> Fundamentals. The basics. Building blocks. However, you put it, there are elementary aspects to almost any activity in life. I was listening to a Red Sox game against the Orioles the other night. They were commenting on the Orioles improved... What do you think the fundamentals of security are?…

Fundamentals. The basics. Building blocks. However, you put it, there are elementary aspects to almost any activity in life. I was listening to a Red Sox game against the Orioles the other night. They were commenting on the Orioles improved…

]]> By: john.smith http://www.securitycatalyst.com/blog/2007/07/a-list-of-the-fundamentals-for-security/#comment-1871 john.smith Tue, 31 Jul 2007 09:08:31 +0000 http://www.securitycatalyst.com/2007/07/30/a-list-of-the-fundamentals-for-security/#comment-1871 CIA is the oft peddled mantra, and I have two issues with it. Not saying it's wrong, just saying I've two issues. ;) #1) the unit currency of security is not C, nor I, nor A, but rather it is TRUST. I think CIA is just one way breaking the concept of TRUST down into manageable components: C is do you TRUST your data is accessible to the right people, and denied the wrong? I is do you TRUST your data is free from unauthorised or unexpected modification? A is to you TRUST your data is going to be available when you need it? Q. And why do you want to break it down in to bite sized chunks like this? A. Easiest way for us pygmies to eat that elephant! ;) 2) AVAILABILITY. In the real world (or at least in my version of it) this is a pie carved between many: Q.Do you trust your data is going to be there when your data centre is flooded? Operationally this is the domain of Disaster Recovery/ Business Continuity; and that is a different role in most organisations that the Information Security Officer. Developmentally this might fall under the Safety Officer, or System Architect, or someone else who are usually different from the Security Consultant* *well done for actually having a security consultant during the development phase!!! Q. So which part of A pie is left for Security? A. Do you trust your data to be available when your data is UNDER ATTACK? Attacks are no accident, they might be impersonal, your information assets might not even be the target, but they are no accident in the "act of god" or "negligence" senses. Q. So what is my point? A. CIA is all very well, but never loose sight of the context, and for this purpose believe the context is TRUST. Similarly if someone asks you Q. Hey security dude, is my widget secure? A. Secure against what? A mantra is no substitute for thinking things through, but it is convenient, and will probably be a good place to start. :) CIA is the oft peddled mantra, and I have two issues with it.

Not saying it’s wrong, just saying I’ve two issues. ;)

#1) the unit currency of security is not C, nor I, nor A, but rather it is TRUST. I think CIA is just one way breaking the concept of TRUST down into manageable components:

C is do you TRUST your data is accessible to the right people, and denied the wrong?
I is do you TRUST your data is free from unauthorised or unexpected modification?
A is to you TRUST your data is going to be available when you need it?

Q. And why do you want to break it down in to bite sized chunks like this?
A. Easiest way for us pygmies to eat that elephant! ;)

2) AVAILABILITY. In the real world (or at least in my version of it) this is a pie carved between many:
Q.Do you trust your data is going to be there when your data centre is flooded?
Operationally this is the domain of Disaster Recovery/ Business Continuity; and that is a different role in most organisations that the Information Security Officer.
Developmentally this might fall under the Safety Officer, or System Architect, or someone else who are usually different from the Security Consultant*
*well done for actually having a security consultant during the development phase!!!

Q. So which part of A pie is left for Security?
A. Do you trust your data to be available when your data is UNDER ATTACK?

Attacks are no accident, they might be impersonal, your information assets might not even be the target, but they are no accident in the “act of god” or “negligence” senses.

Q. So what is my point?
A. CIA is all very well, but never loose sight of the context, and for this purpose believe the context is TRUST.

Similarly if someone asks you
Q. Hey security dude, is my widget secure?
A. Secure against what?

A mantra is no substitute for thinking things through, but it is convenient, and will probably be a good place to start.

:)

]]>