![]() |
Hello and Welcome from United States to the UNIX and Linux Forums! Thank You for Visiting and Joining Our Global Community.
|
|
google unix.com
|
|||||||
| Forums | Register | Forum Rules | Links | Albums | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
More UNIX and Linux Forum Topics You Might Find Helpful
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Should the CISSP CBK be expanded to cover "human factors" in security? | iBot | IT Security RSS | 0 | 08-10-2009 07:15 AM |
| A question/problem about oracle "tns listener" and "enterprise manager" | talipk | UNIX for Advanced & Expert Users | 1 | 12-03-2008 07:55 AM |
| Development Releases: Linux Mint 4.0 Beta "Fluxbox", 4.0 Alpha "Debian" | iBot | UNIX and Linux RSS News | 0 | 01-04-2008 03:00 PM |
| Explain the line "mn_code=`env|grep "..mn"|awk -F"=" '{print $2}'`" | Lokesha | UNIX for Dummies Questions & Answers | 4 | 12-20-2007 01:52 AM |
| No utpmx entry: you must exec "login" from lowest level "shell" | peterpan | UNIX for Dummies Questions & Answers | 0 | 01-18-2006 04:15 AM |
|
|
LinkBack | Thread Tools | Search this Thread | Rate Thread | Display Modes |
|
|||||
|
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... |
| Bookmarks |
| Thread Tools | Search this Thread |
| Display Modes | Rate This Thread |
|
|