|
|
08-11-2009
Registered User
26,240,
27
Add "human factors"? No.
OK, Gary has asked if the CISSP CBK should be expanded to cover "human factors" in security?
And I answer "No."
With that kind of beginning, you could be forgiven for thinking that I disagree with Gary about the importance of human factors in security. Nothing could be further from the truth. I agree with everything he has said about the fundamental significance of human factors in information security, as well as the difficulty of dealing with them, and will defend to the death his right to say it.
What I disagree with is the question.
The CBK already addresses human factors.
When I teach CBK review seminars, I start with the security management domain. Yes, Gary is right that this field started out with a bunch of technical people who had difficulty understanding that people don't always do what you tell them. So candidates coming in, who are not prepared for dealing with human factors, get a good scare right off the top. They have to deal with management, which means dealing with people (and probably politics). And organizational roles (which have to do with people). And security awareness training. (Oh, and ethics.)
Moving on to access control, we talk about social engineering there. (As well as the password choice problem Gary mentioned.) Good scope for human factors.
Crypto's a technical field, so no human factors, right? Wrong. We talk about implementation problems, and the inability of people to be truly random.
Physical security talks about human factors.
BCP talks about human factors. As long as you are truly recovering the business, as you should be, and not just systems. (Common mistake.)
Security architecture is pretty technical. But it deals with the security frameworks, with all those guideline documents.
Applications security has a lot to do with human factors. (If you actually do it properly.)
Telecom? Sure, that's technical. But it also has to do with spam, social networking, phone phreaking, and all kinds of social engineering/human factors implications.
Operations? You're dealing with people. In fact, most of the stuff in operations could equally be dealt with in other domains, except for the extra provisions you have to make for your employees who need escalated privileges. Your classic insider situation.
Law and investigation? If you don't think that is mostly dealing with human factors, you are in the wrong field.
So, no, the CBK doesn't need to have human factors added.
If you want to talk about whether we need to pull all the human factors stuff out, and put it in a separate domain, that's a different question.
(And, to that one too, I'd say no. We'd have a human factors domain that takes up three days of a five day seminar, and have to squish the existing domains into the remaining two days.)
More...
And I answer "No."
With that kind of beginning, you could be forgiven for thinking that I disagree with Gary about the importance of human factors in security. Nothing could be further from the truth. I agree with everything he has said about the fundamental significance of human factors in information security, as well as the difficulty of dealing with them, and will defend to the death his right to say it.
What I disagree with is the question.
The CBK already addresses human factors.
When I teach CBK review seminars, I start with the security management domain. Yes, Gary is right that this field started out with a bunch of technical people who had difficulty understanding that people don't always do what you tell them. So candidates coming in, who are not prepared for dealing with human factors, get a good scare right off the top. They have to deal with management, which means dealing with people (and probably politics). And organizational roles (which have to do with people). And security awareness training. (Oh, and ethics.)
Moving on to access control, we talk about social engineering there. (As well as the password choice problem Gary mentioned.) Good scope for human factors.
Crypto's a technical field, so no human factors, right? Wrong. We talk about implementation problems, and the inability of people to be truly random.
Physical security talks about human factors.
BCP talks about human factors. As long as you are truly recovering the business, as you should be, and not just systems. (Common mistake.)
Security architecture is pretty technical. But it deals with the security frameworks, with all those guideline documents.
Applications security has a lot to do with human factors. (If you actually do it properly.)
Telecom? Sure, that's technical. But it also has to do with spam, social networking, phone phreaking, and all kinds of social engineering/human factors implications.
Operations? You're dealing with people. In fact, most of the stuff in operations could equally be dealt with in other domains, except for the extra provisions you have to make for your employees who need escalated privileges. Your classic insider situation.
Law and investigation? If you don't think that is mostly dealing with human factors, you are in the wrong field.
So, no, the CBK doesn't need to have human factors added.
If you want to talk about whether we need to pull all the human factors stuff out, and put it in a separate domain, that's a different question.
(And, to that one too, I'd say no. We'd have a human factors domain that takes up three days of a five day seminar, and have to squish the existing domains into the remaining two days.)
More...