An oped on the issues of CISSP

Danielm7 · July 2016

Without knowing what the job description was it's not really easy to say that the questions weren't fair or not. But, with that said, just saying if someone has 5 or more years with 2 of the domains so they should know powershell, sql injection, etc, isn't really accurate either. Their focus in the domains might be account creation, folder level security and doing some phishing training or something else similar. The CISSP is what it is, it's not very technical, the fact that very technical people might have it doesn't really mean anything either. That some HR departments demand it for positions where it doesn't make sense just shows that they don't know what the CISSP means, not that it's worthless.

ITHokie · July 2016

gespenstern wrote: »

And it is more or less so in a real world, security folks rarely DO something compared to an infrastructure or development or network team, who do stuff all the day long. Security folks watch, analyze and advise.

This is in incredible statement and very revealing. I suppose if I believed security people don't actually do anything I wouldn't have any issues with perception of CISSP. In the world I live in, security requires DOers.

goatama wrote: »

I'm not sure if you read my original responses before you went about telling me I was "doing it wrong", but maybe you should before responding?

At no time did I say we were hiring "CISSPs". I said we were hiring for a security engineer. Someone with hands on experience. I didn't list here all of the requirements in the job posting, more a general idea. My point was also that someone with five years of *actual* security experience in two or more of the domains should be able to do all of those things. Or at least provide an educated response. Again, they didn't have to get all of the questions right, but more often than not they couldn't get ANY of them right. None. I also didn't list all of the questions (since, you know, Idk if any of you guys are ever going to apply for the next one that opens up).

So no, I'm not "doing it wrong", my point is that the CISSP is not the end-all-be-all cert that a lot of people seem to think it is.

They were very good questions - thanks for sharing. I wish more employers would do this kind of technical screening.

billDFW wrote: »

Isn't the CISSP geared more towards managers anyway, and less in-the-weeds ? The Secretary of the DOD is a manager, he does not need to know how to drive a tank or land on an aircraft carrier. He does however have people under him, who are Subject Matter Experts (SMEs) and have specific knowledge and talent on their specific tools.

Again, what CISSP is intended for is irrelevant. It is perceived to be highly technical cert which is why it appears all over job boards for technical positions. Again, the problem is not with the cert itself but with how HR and management types perceive it.

TheFORCE wrote: »

I'd agree with gespenstern. You say you are not hiring CISSP's but you used the cert as probably something nice to have, preferred or required, in addition you compared the person with CISSP vs the one without and at the end you hired the one without because of the technical knowledge. Then again you compare the many CISSP and none of them seemed to know the answers, based on that you are assuming that the CISSP is not deemed worthy or it does not provide any real technical knowledge, the fact is CISSP does not provide technical knowledge and you should write your job descriptions aimed towards more technical people.

Seriously? You both completely misread what was being communicated. Take a deep breath.

gespenstern · July 2016

goatama wrote: »

I'm not sure if you read my original responses before you went about telling me I was "doing it wrong", but maybe you should before responding?

At no time did I say we were hiring "CISSPs". I said we were hiring for a security engineer.

Yet you sounded like the CISSP didn't live up to your expectations and the "really basic stuff" you asked your interviewees to do was supposed to be known by the CISSP interviewees. Also the whole description of your hiring process sounded ad hoc as, apparently, the first approach wasn't fruitful at all.

goatama wrote: »

My point was also that someone with five years of *actual* security experience in two or more of the domains should be able to do all of those things.

Not really. You sound like you didn't work much with people for example on the GRC side of our field or CISOs. Do you really expect them to write the PowerShell or SQL injection code on the interview? Or maybe do you think they don't deserve to be named security folks if they can't code PoSh? I have a lady working with me who does for the most part HIPAA compliance stuff, I'm not sure if she even knows what PowerShell is.

goatama wrote: »

So no, I'm not "doing it wrong", my point is that the CISSP is not the end-all-be-all cert that a lot of people seem to think it is.

Very well and my point is the CISSP is exactly the best overall security cert that covers all security-related things. Is it perfect? No. Is there a good substitute for it? No. HR in some cases may exaggerate its value, but I wouldn't blame them as they, not being professionals in the field themselves, need some way to assure at least with some degree of certainty that the candidate is proficient and there's no better cert out there for this purpose then the CISSP. For specific tasks, like writing a PowerShell code or SQL-injection-resistant code, are there better certs out there -- sure there are. But if I was asked to rely on one single thing I would rely on the CISSP (and not OSCP or MCSA, etc).

gespenstern · July 2016

ITHokie wrote: »

This is in incredible statement and very revealing. I suppose if I believed security people don't actually do anything I wouldn't have any issues with perception of CISSP. In the world I live in, security requires DOers.

And what are these DOers do exactly in your world? Let's say, compared to folks working in development or infrastructure.

Sheiko37 · July 2016

The CISSP seems borderline irrelevant for that engineering position, and I'm not surprised candidates holding the CISSP couldn't answer those technical questions. It could be open book and you couldn't answer those questions, that's not what the CISSP teaches, and 5 years of "actual" security experience doesn't necessarily teach it either.

ITHokie · July 2016

gespenstern wrote: »

And what are these DOers do exactly in your world? Let's say, compared to folks working in development or infrastructure.

It's debatable whether the ratio of DOers to non-DOers is the right one in any given organization; that infosec requires DOers and that they exist is not debatable. I think you know that, which is why you have already shifted the goal posts by insinuating that they don't do as much as development and infrastructure types.

On the other hand, if you actually believe security operations does not include DOers, your career (world) just hasn't intersected with them yet. It will eventually.

Ertaz · July 2016

laughing_man · July 2016

ITHokie wrote: »

It's debatable whether the ratio of DOers to non-DOers is the right one in any given organization; that infosec requires DOers and that they exist is not debatable. I think you know that, which is why you have already shifted the goal posts by insinuating that they don't do as much as development and infrastructure types.

On the other hand, if you actually believe security operations does not include DOers, your career (world) just hasn't intersected with them yet. It will eventually.

Just from my experience, I did not find those questions to be out of place. I am not a consummate coder, but I know Powershell and some Python. I know enough about SQL injection to at least describe how to do it. And I don't consider myself a "doer". Frankly I do a lot of risk assessments and reports. But those hands on skills are still a part of my work. So I think for an engineer type position it is very appropriate to ask such things.

As far as SIEM, yeah thats different and frankly most security folks should be able to have some view on that, especially for auditors and the like.

And whether some team is "doing it right" all really depends on where their organization is at. Not so long ago, our security team did mostly user provisioning. Now things have changed dramatically and SIEM, IPS, threat intelligence, vuln scanning, firewalls, and all that other basic security stuff is part of our daily lives.

Its a great field. Always changing

gespenstern · July 2016

ITHokie wrote: »

...which is why you have already shifted the goal posts by insinuating that they don't do as much as development and infrastructure types.

It's actually quite opposite to what you are saying. Every word is recorded, fortunately. I stated from the beginning of this conversation that security folks RARELY do things COMPARED to other teams, such as infrastructure, development or network. And it was you who shifted this for the sake of strawman arguing from rarely to never and omitted the comparison with other folks in IT.

ITHokie wrote: »

On the other hand, if you actually believe security operations does not include DOers, your career (world) just hasn't intersected with them yet. It will eventually.

I'm in my forties and I saw many things in this industry, if not everything, all career in IT and majority of it in security. And what I've found is almost always security folks spend much more time staring at logs, events, memory ****, compliance reports, network captures or CCTV camera displays compared to any other IT folks. And IF they do system administration tasks, like constructing GPOs to harden Windows servers or segmenting a network or developing software securely instead of just noticing a problem and making other teams fix it through change management -- this is usually an indication of incorrect and broken approach to security. Other teams do stuff. Security does stuff rarely, usually it is a small tool if it is a development (not a whole project), or a PoC of some kind or incident response, etc.

And it is so because because the ultimate goal of security is asset protection and it is achieved for the most part by relatively small touches of existing business processes. Like developing securely by introduction of security considerations to each step of SDLC, or configuring already developed systems securely (and all of this is done ultimately by other teams after they are advised to do that by security), playing red/blue games as a testing measure and the first and foremost closely watching things happening to make sure that they are aware of all the risks, design flaws and threats to the assets they are called to protect.

They are like spiders sitting in the center of the web, seemingly doing nothing, but having their many limbs connected to many silk lines of the web listening to things happening and making sure that they are happening right, not by changing the processes themselves, but influencing other people in the organization to change their practices to more secure ones.

They can do stuff occasionally, but if it is a habit and common practice then it is most likely a more or less immature organization of security.

TheFORCE · July 2016

I dont know if that is right or not, depends on the world i guess. In my organization our team does a lot of stuff too only because the other teams lack the knowledge or the capacity to do things right so instead we do many of the taks that should technically fall under the Helpdesk or the sys admin roles. But when the Helpdesk guy creates a folder with sensitive info and doesnt protect it and then the permissions propagate from the root where every employee has access and the folder comes up on my scans then I have to let them know to fix it. At this point it has happen so many times that we decided you know what, might as well those requests come to us. So i think there's no black and white roles or environments, it just depends on the maturity like you said but also on the knowledge of the people doing the changes.

topandreuser · July 2016

The CISSP should not be the end all be all when it comes to hacking and Information assurance. However, since its a must, then here are good resources to study off of it. https://www.isc2.org/isc2-study-resources/default.aspx

goatama · July 2016

gespenstern wrote: »

They are like spiders sitting in the center of the web, seemingly doing nothing, but having their many limbs connected to many silk lines of the web listening to things happening and making sure that they are happening right, not by changing the processes themselves, but influencing other people in the organization to change their practices to more secure ones.

They can do stuff occasionally, but if it is a habit and common practice then it is most likely a more or less immature organization of security.

I see what's wrong. You've seen some stuff so you think everyone else that doesn't do it specifically the way you think it should be done is doing it wrong. I guess that explains these responses.

So let me add a little bit more clarity: I need the engineers I work with to *know* these things. I need them to know Wireshark, what security events to look at and derive meaning from. I need them to know how to write SQL injection and how to detect a possible buffer overflow issue in code so they can ensure that the developers are coding things properly. I need them to be able to understand security architecture from the ground up, this includes networking and infrastructure. I also need them to know policy and compliance. They don't have to *do* all of these things. They need to be able to understand that information and then leverage it appropriately to advise and secure the organization.

Ertaz · July 2016

ITHokie · July 2016

gespenstern wrote: »

It's actually quite opposite to what you are saying. Every word is recorded, fortunately. I stated from the beginning of this conversation that security folks RARELY do things COMPARED to other teams, such as infrastructure, development or network. And it was you who shifted this for the sake of strawman arguing from rarely to never and omitted the comparison with other folks in IT.

Saying that security folks "RARELY" do things "COMPARED" to other teams (DOers) clearly implies that they aren't DOers. Which is why you followed this statement with

gespenstern wrote:

Security folks watch, analyze and advise. Your questions are more for doers...

The obvious implication is that security folks are not DOers and hence this is not a strawman. Feel free to retreat into semantics, though.

gespenstern wrote:

They can do stuff occasionally, but if it is a habit and common practice then it is most likely a more or less immature organization of security.

Yeah, it's completely the opposite in my experience. Taking goatama's example, a mature organization is going to (1) actually have a SIEM and (2) will hire a capable security engineer(s) to run it. A less mature organization, if they have a SIEM, will have a Windows or Linux administrator run it. This is important because the latter don't often have a strong security background and will struggle to collaborate with analysts that depend on them. This of course assumes that the organization has analysts.

gespenstern · July 2016

ITHokie wrote: »

Saying that security folks "RARELY" do things "COMPARED" to other teams (DOers) clearly implies that they aren't DOers. Which is why you followed this statement with

Implies? Retreats? You clearly posing yourself outside of the boundaries of intellectually honest discussion.

Cheers!

gespenstern · July 2016

goatama wrote: »

I see what's wrong. You've seen some stuff so you think everyone else that doesn't do it specifically the way you think it should be done is doing it wrong. I guess that explains these responses.

That is correct. Every person actually bases their views on their experience, among other things. But on top of that I supply arguments why it is how it is and claim that it is applicable to this industry as a whole.

goatama wrote: »

So let me add a little bit more clarity: I need the engineers I work with to *know* these things. I need them to know Wireshark, what security events to look at and derive meaning from. I need them to know how to write SQL injection and how to detect a possible buffer overflow issue in code so they can ensure that the developers are coding things properly. I need them to be able to understand security architecture from the ground up, this includes networking and infrastructure. I also need them to know policy and compliance. They don't have to *do* all of these things. They need to be able to understand that information and then leverage it appropriately to advise and secure the organization.

And this is kind of disturbing, again. CISSP CBK is vendor-neutral and therefore it is okay not to teach Wireshark on any deep level but just mentioning it. What if a candidate uses Microsoft Network Monitor? Or Message Analyzer? Or Softperfect Network Protocol Analyzer? Why not just ask about how general network capture works? I believe that any CISSP holder who didn't pass their exam more by luck than because of knowledge will be able to answer this question. As for Wireshark, there is a specific cert for Wireshark if you are really heavy on it and don't allow your engineers to use alternatives.

And the rationale is pretty simple here, as TheFORCE mentioned above, general knowledge that people are taught by the CISSP CBK lets them figure out a particular network capture software in just a matter of a few hours, like in his PowerShell example. It is actually more of knowing TCP/IP stack and CISSP holders surely should have a basic idea of how it works.

I understand that if you are the one who interviews, it is your views on what's important that matter for passing this interview successfully, but the thing is, it's pointless to argue that the CISSP isn't that good because the CISSP holder wasn't able to answer your questions on that interview, because besides security events/SIEM question the rest are just out of scope and vendor-specific. The CISSP CBK doesn't teach PowerShell or Python. It teaches though general computer language techniques and which of these could result in a vulnerable code.

And, honestly, I'd say that being able to write a SQL injection against a vulnerable code could be learned in a matter of about two hours for a person with proper knowledge of the CISSP CBK. There's absolutely nothing fancy in supplying a SQL statement code where the author expected data to be and didn't validate the input in any way.

ITHokie · July 2016

gespenstern wrote: »

Implies? Retreats? You clearly posing yourself outside of the boundaries of intellectually honest discussion.

Cheers!

Heh, I suppose I should be offended, but I can't help but find it amusing that you think the use of logic is somehow dishonest.

What is logical implication? - Definition from WhatIs.com

Retreating into semantics diverts focus from the subject of discussion to the meaning of words to the point that arguments die the death of a thousand qualifications.

techfiend · July 2016

Depends on what is considered doing. If it's accomplishing something that directly affects the business then yes IT security has a very small amount of DOers while system and network professional are regularly impactful.

If it's considered doing things instead of watching things then IT security has their fair share. Ethical hackers, red and blue teams are a few examples. Which seems like some pretty interesting stuff too bad it takes years of log diving and watching for most before you have a chance to do it regularly. Entry-level IT security still seems like the most boring, mundane IT jobs out there. Luckily there's other alternative paths to get into IT security.

An oped on the issues of CISSP

Comments