@chris:
“The situation you frame above about corruption (impacting integrity) *could* impact the “reliability” of the data, but not necessarily the “availability” of it…but it depends on what the data is and represents. Now you’re introducing the notion of “good” versus “bad” data which further complicates the issue.”
it’s not good vs. bad data, it’s clean vs. corrupt data… corruption can take the form of more data, less data, or modified data – some of which directly affect availability, but all of which affect the usability/reliability of the data and if you can’t use it then it’s as good as unavailable…
“Look, you don’t have to like, agree or accept my statements, but this is just the way I’ve observed life in general. There are no absolutes. Trying to make “security” and absolute forcing function will result in…well, what we have now.”
i can’t speak for others but i’m certainly not dealing in absolutes and i’ve definitely allowed for various situations being more about one aspect of security than another – but they’re all still aspects of security…
@lonervamp:
“When something is down, managers and the business can pretty quickly measure it and the impact,”
when something is corrupt it is also generally down (at least until such time as it can be restored to an uncorrupted state from backups)…
furthermore, if a service is leaking data you’re probably going to want to take that service down until something can be done about it (unless you can do something about it immediately, of course, and good for you if you can) because although a compromise of availability can be reversed, a compromise of confidentiality can’t…
I guess I just take a much more universal view of information security than most people (maybe trying to justify my existence?) I think it all is an aspect of security in today’s modern world. General IT takes care of “A” to a point, but as I stated here, I think everyone has to look at security first now days.
And you can’t confine availability to making sure your hard drive doesn’t crash. You MUST take it a step further by looking at the security side of things. IT may do the work, but backing up the data is a security function by definition. That is DR / BC. it all comes back to security in some way.
When “C” or “I” break down, does the business really truly rally around that security analyst? Maybe… Hopefully!
When “A” breaks down and a critical system is not available for a day, you can bet heads will roll. This is part of what Hoff is saying. When something is down, managers and the business can pretty quickly measure it and the impact, but when something is done that affects “C” and “I,” the business may not be impacted in any way other than someone (either customer or the business) pushing the “OMG Stop” button when they notice the issue. It is far harder to quantify, and also to justify stopping the presses due to it.
And when push comes to shove in a business, keeping something down is far bigger a pain than keeping something insecure.
I see this every week in my jobs over the last 6 years as an in the trenches admin. “A” will always trump “C” and “I”.
This is also why I will argue “A” is the weakest of the three pieces of the triad when it comes to a perspective on security. It is IT’s general role to provide for “A”, while security is far more concerned with “C” and “I”, simply because “A” is already taken care of, in most cases.
I’ll happily take A out of the troika, if only because the stool will then fall over, and we can break it up for firewood.
Our operational security isn’t served at all by plans that try to cast confidentiality, integrity and availability as equal partners at the macro level. Those might be useful as detailed tactical design tags, but even there I’m not convinced.
In my real world, I’m more concerned about bringing systems back into control as quickly and safely as possible after we’ve had an incident of some kind. That’s the operational bottom line, and why our security planning is focused on PDR (prevention, detection, and response).
Thanks for the back and forth. Looking forward to the new post.
BTW, I do name one of “them”, which is in my new post. I specifically talk about the OpenBSD people doing it. I also distinctly remember Microsoft doing it with some IE vulnerabilities. I ranted here about it (I couldn’t find it when I was doing my last post). There was some decent bank-and-forth on that post as well.
What is funny is that both of “them” are trying to remove the “A” because it negatively impacts their own security rating, just as I pointed out in my new post. Conspiracy???
Ok, so let me make this simpler since we’re talking past each other…based on your new post.
The Business separates out availability because the other two are difficult to quantify from the perspective of
measuring the impact of controls you put in place to preserve them.
So, they talk about availability (which equals service availability) because that’s easy to measure.
It totally explains why we have breaches.
BTW, I’m not suggesting it’s a good thing to disregard any of them, I’m just answering your question as to
why you see “them” separating A from C and I.
/Hoff
(I’ll cross-post this on your new entry so it makes sense…)
Practice clearly shows that your assertion is inaccurate. You can proselytize all you want,
but C, I and A *are* “ingredients” that are adjusted and substituted based upon the prevailing
appetite for risk.
You won’t pass your CISSP exam that way, but this is where dogma versus reality kicks in.
You’re generalizing and then asking for specifics. The situation you frame above about
corruption (impacting integrity) *could* impact the “reliability” of the data, but not
necessarily the “availability” of it…but it depends on what the data is and represents.
Now you’re introducing the notion of “good” versus “bad” data which further complicates
the issue.
This is why businesses simply expect you to fix this.
Further, there are gradients involved here; one isn’t only 0% or 100% “secure.”
Based upon a risk assessment (formal or seat of the pants) many businesses simply choose
to manage risk by accepting it and managing to it.
In the real world, businesses make trade offs like this every day.
You may not be able to “separate the heads from the tails” of a quarter, but you can stand
it on its side…this sanctimonious adhesion to the maxima/minima of textbook versus pragmatic
“security” often means that you *do* decide focus on one versus the other two.
Look, you don’t have to like, agree or accept my statements, but this is just the
way I’ve observed life in general. There are no absolutes. Trying to make “security”
and absolute forcing function will result in…well, what we have now.
if i corrupt data (compromise it’s integrity) then have i not made the good data (the data i used to use) less available from the business’ perspective? if i leak data (compromise it’s confidentiality) then have i not made it *too* available and/or available to the wrong people?
no corner of the triad is an island, separate unto itself… confidentiality, integrity, and availability are not ingredients in a recipe, they are aspects of the same thing… you can choose to focus more on one face of security than the others but you cannot truly separate them anymore than you can separate the heads side of a coin from the tails side…
I don’t know who the “they” are that are allegedly taking the ‘A’ out of the triad…
If I had to guess, the security folk quoteth from their holy Tipton books from upon
high regarding all three. The BUSINESS doesn’t know how to describe or measure the
impact C and I have on their business as it relates to “security,” so they talk about
what most businesses talk about:
Serving the customer.
…which to the business means making sure whatever you’re providing is available.
Why should they even fret about C and I? From their perspective that’s YOUR job.
That’s what they pay for every time IT and IT/Security gets a budget off the sweaty
backs of their toils.
C and I are table stakes that they expect as part of the package and service you provide
them with. Why do you think software development has had such a crappy track-record for
security. They expect the firewalls and WAFs would “fix” the problems…all they cared
about was that it “worked.”
BTW, I may be picking nits, but information security does not encompass risk management,
it’s the other way around. If what you wrote were true, you wouldn’t have written your
post in the first place…
…this response ain’t brilliant and I’ve only been at this for 14 years, so I haven’t
gotten to the point of boldly declaring anything I know or say as “old school.” YMMV, but
s Inigo Montoya was once fondly noted as saying
“…I do not think that means what you think that means…”
My $0.02
You’re still my favorite redneck security dude tho…you’re like the security version of
Larry the Cable Guy… (is redneck a bad thing?)
First off, I think you are missing the point. I don’t place the CI before the A except that it just happens to be that way in all the books. All are equally important.
Which leads to my second point, which is this question: when did it become so vogue to take the “A” out of the Triad? People have been separating these for the last year or two (maybe more), and it is driving me up a wall. Information security encompasses risk management. It is not just about the C and the I.
Speaking of I… I am sleepy and don’t feel like an arguement right now.
OK, now I will sleep and wait for a lengthy and assuredly brilliant explanation of why I am still kickin’ it old school (which I am proud of, BTW).
It’s funny how allergic you and Wismer are toward the notion that managing risk may mean that “security”
(namely C and I) isn’t always the priority. Basic risk assessment process shows us that in many cases
“availability” trumps security.
This can’t be a surprise to either of you.
Depending upon your BCP/DR/Incident Response capabilities, the notion of a breakdown in C or I can be overcome
by resilience that also has the derivative effect of preserving A.
Risk Management != Security.
However, good Security helps to reinforce and enforce those things which lend themselves toward making better
decisions on how to manage risk.
Well, in the minds of some biz folks this is not dumb at all. Yes, we all know ab the ‘A’ in ‘CIA’, but there is indeed a chasm, of sorts, between ‘keep it running / but maybe owned’ vs ‘keep it secure’…
@chris:
“The situation you frame above about corruption (impacting integrity) *could* impact the “reliability” of the data, but not necessarily the “availability” of it…but it depends on what the data is and represents. Now you’re introducing the notion of “good” versus “bad” data which further complicates the issue.”
it’s not good vs. bad data, it’s clean vs. corrupt data… corruption can take the form of more data, less data, or modified data – some of which directly affect availability, but all of which affect the usability/reliability of the data and if you can’t use it then it’s as good as unavailable…
“Look, you don’t have to like, agree or accept my statements, but this is just the way I’ve observed life in general. There are no absolutes. Trying to make “security” and absolute forcing function will result in…well, what we have now.”
i can’t speak for others but i’m certainly not dealing in absolutes and i’ve definitely allowed for various situations being more about one aspect of security than another – but they’re all still aspects of security…
@lonervamp:
“When something is down, managers and the business can pretty quickly measure it and the impact,”
when something is corrupt it is also generally down (at least until such time as it can be restored to an uncorrupted state from backups)…
furthermore, if a service is leaking data you’re probably going to want to take that service down until something can be done about it (unless you can do something about it immediately, of course, and good for you if you can) because although a compromise of availability can be reversed, a compromise of confidentiality can’t…
LV,
I guess I just take a much more universal view of information security than most people (maybe trying to justify my existence?) I think it all is an aspect of security in today’s modern world. General IT takes care of “A” to a point, but as I stated here, I think everyone has to look at security first now days.
And you can’t confine availability to making sure your hard drive doesn’t crash. You MUST take it a step further by looking at the security side of things. IT may do the work, but backing up the data is a security function by definition. That is DR / BC. it all comes back to security in some way.
Michael
When “C” or “I” break down, does the business really truly rally around that security analyst? Maybe… Hopefully!
When “A” breaks down and a critical system is not available for a day, you can bet heads will roll. This is part of what Hoff is saying. When something is down, managers and the business can pretty quickly measure it and the impact, but when something is done that affects “C” and “I,” the business may not be impacted in any way other than someone (either customer or the business) pushing the “OMG Stop” button when they notice the issue. It is far harder to quantify, and also to justify stopping the presses due to it.
And when push comes to shove in a business, keeping something down is far bigger a pain than keeping something insecure.
I see this every week in my jobs over the last 6 years as an in the trenches admin. “A” will always trump “C” and “I”.
This is also why I will argue “A” is the weakest of the three pieces of the triad when it comes to a perspective on security. It is IT’s general role to provide for “A”, while security is far more concerned with “C” and “I”, simply because “A” is already taken care of, in most cases.
I’ll happily take A out of the troika, if only because the stool will then fall over, and we can break it up for firewood.
Our operational security isn’t served at all by plans that try to cast confidentiality, integrity and availability as equal partners at the macro level. Those might be useful as detailed tactical design tags, but even there I’m not convinced.
In my real world, I’m more concerned about bringing systems back into control as quickly and safely as possible after we’ve had an incident of some kind. That’s the operational bottom line, and why our security planning is focused on PDR (prevention, detection, and response).
Thanks for the back and forth. Looking forward to the new post.
BTW, I do name one of “them”, which is in my new post. I specifically talk about the OpenBSD people doing it. I also distinctly remember Microsoft doing it with some IE vulnerabilities. I ranted here about it (I couldn’t find it when I was doing my last post). There was some decent bank-and-forth on that post as well.
What is funny is that both of “them” are trying to remove the “A” because it negatively impacts their own security rating, just as I pointed out in my new post. Conspiracy???
Michael
Ok, so let me make this simpler since we’re talking past each other…based on your new post.
The Business separates out availability because the other two are difficult to quantify from the perspective of
measuring the impact of controls you put in place to preserve them.
So, they talk about availability (which equals service availability) because that’s easy to measure.
It totally explains why we have breaches.
BTW, I’m not suggesting it’s a good thing to disregard any of them, I’m just answering your question as to
why you see “them” separating A from C and I.
/Hoff
(I’ll cross-post this on your new entry so it makes sense…)
Practice clearly shows that your assertion is inaccurate. You can proselytize all you want,
but C, I and A *are* “ingredients” that are adjusted and substituted based upon the prevailing
appetite for risk.
You won’t pass your CISSP exam that way, but this is where dogma versus reality kicks in.
You’re generalizing and then asking for specifics. The situation you frame above about
corruption (impacting integrity) *could* impact the “reliability” of the data, but not
necessarily the “availability” of it…but it depends on what the data is and represents.
Now you’re introducing the notion of “good” versus “bad” data which further complicates
the issue.
This is why businesses simply expect you to fix this.
Further, there are gradients involved here; one isn’t only 0% or 100% “secure.”
Based upon a risk assessment (formal or seat of the pants) many businesses simply choose
to manage risk by accepting it and managing to it.
In the real world, businesses make trade offs like this every day.
You may not be able to “separate the heads from the tails” of a quarter, but you can stand
it on its side…this sanctimonious adhesion to the maxima/minima of textbook versus pragmatic
“security” often means that you *do* decide focus on one versus the other two.
Look, you don’t have to like, agree or accept my statements, but this is just the
way I’ve observed life in general. There are no absolutes. Trying to make “security”
and absolute forcing function will result in…well, what we have now.
/Hoff
if i corrupt data (compromise it’s integrity) then have i not made the good data (the data i used to use) less available from the business’ perspective? if i leak data (compromise it’s confidentiality) then have i not made it *too* available and/or available to the wrong people?
no corner of the triad is an island, separate unto itself… confidentiality, integrity, and availability are not ingredients in a recipe, they are aspects of the same thing… you can choose to focus more on one face of security than the others but you cannot truly separate them anymore than you can separate the heads side of a coin from the tails side…
I don’t know who the “they” are that are allegedly taking the ‘A’ out of the triad…
If I had to guess, the security folk quoteth from their holy Tipton books from upon
high regarding all three. The BUSINESS doesn’t know how to describe or measure the
impact C and I have on their business as it relates to “security,” so they talk about
what most businesses talk about:
Serving the customer.
…which to the business means making sure whatever you’re providing is available.
Why should they even fret about C and I? From their perspective that’s YOUR job.
That’s what they pay for every time IT and IT/Security gets a budget off the sweaty
backs of their toils.
C and I are table stakes that they expect as part of the package and service you provide
them with. Why do you think software development has had such a crappy track-record for
security. They expect the firewalls and WAFs would “fix” the problems…all they cared
about was that it “worked.”
BTW, I may be picking nits, but information security does not encompass risk management,
it’s the other way around. If what you wrote were true, you wouldn’t have written your
post in the first place…
…this response ain’t brilliant and I’ve only been at this for 14 years, so I haven’t
gotten to the point of boldly declaring anything I know or say as “old school.” YMMV, but
s Inigo Montoya was once fondly noted as saying
“…I do not think that means what you think that means…”
My $0.02
You’re still my favorite redneck security dude tho…you’re like the security version of
Larry the Cable Guy… (is redneck a bad thing?)
@ The Hoff and the Honorable Anton,
First off, I think you are missing the point. I don’t place the CI before the A except that it just happens to be that way in all the books. All are equally important.
Which leads to my second point, which is this question: when did it become so vogue to take the “A” out of the Triad? People have been separating these for the last year or two (maybe more), and it is driving me up a wall. Information security encompasses risk management. It is not just about the C and the I.
Speaking of I… I am sleepy and don’t feel like an arguement right now.
OK, now I will sleep and wait for a lengthy and assuredly brilliant explanation of why I am still kickin’ it old school (which I am proud of, BTW).
Michael
I’m with Anton.
It’s funny how allergic you and Wismer are toward the notion that managing risk may mean that “security”
(namely C and I) isn’t always the priority. Basic risk assessment process shows us that in many cases
“availability” trumps security.
This can’t be a surprise to either of you.
Depending upon your BCP/DR/Incident Response capabilities, the notion of a breakdown in C or I can be overcome
by resilience that also has the derivative effect of preserving A.
Risk Management != Security.
However, good Security helps to reinforce and enforce those things which lend themselves toward making better
decisions on how to manage risk.
What’s so hard to understand about that?
/Hoff
Well, in the minds of some biz folks this is not dumb at all. Yes, we all know ab the ‘A’ in ‘CIA’, but there is indeed a chasm, of sorts, between ‘keep it running / but maybe owned’ vs ‘keep it secure’…
Kurt,
Exactly. Sheesh…
Michael
presumably written by someone so out of touch with security that they don’t realize availability is part of it…