Proposed Security Ethics Code: Steal Someone Else’s!

Thomas Ptacek | June 26th, 2005 | Filed Under: Uncategorized

One thing I am worried about, since I’m getting cited hither and yon for criticizing ISC2, is that people will be mislead into believing that my CISSP ethics jab stands as my rebuttal to the whole CISSP program.

Just in case you’re wondering: far from it. Though, Bejtlich is doing a pretty good job of it himself, and I paraphrase (and extend):

• It’s a certification without a open, accepted “body of knowledge”.

• It encourages ongoing education, but awards that credit to people taking my class (fools!).

• There’s an examination, but it’s so arbitrary that without shelling out for an ISC2-sponsored book, the top-tier of the profession might not pass it.

• 17-year-olds have been issued the CISSP.

• It’s not recognized by the field, unless you define the field away from expertise and towards people who pay for certs to improve their HotJobs profile.

• The certification is not provided by an organization operating in concert with the community as a whole. (Remember: non-profit status doesn’t connote charity status —- the people who operate an NPO can still take large salaries!)

But, once again, I’m letting several hundred words of lead-in obscure the central point, which is:

Why the fuck does the CISSP need it’s own code of ethics?

I ask because of Bejtlich’s excellent cite of the NSPE code of ethics, which, upon close examination, seems like a very reasonable code to apply to any technical profession that wanted to move itself towards engineering-levels of professionalism.

One way to disabuse yourself of the notion that the CISSP code is any good is to go point-for-point through the NSPE code and take note of the things that the CISSP leaves out, such as:

• Issuing only objective statements about professional matters (NSPE I.3: Canon)

• Obligation to notify employers, clients, and authorities when their best judgement is overruled (NSPE II.1.a)

• Adherence to standards (NSPE II.1.b)

• Avoid association with dishonest enterprises (NSPE II.1.d, and this is not the same thing as “avoid people who’s reputation tarnishes the profession”, which is a stupid point and one I’ll return to in my next post)

• Obligation to report NSPE code violations (NSPE II.1.f).

• Specific restriction from taking assignments outside competence gained by specific technical education or experience (NSPE II.2.a, and note the lack of weasel words!)

• Specific restriction from signing off on plans or designs that touch on concepts outside their expertise (NSPE II.2.b)

• Requirement to disclose conflict of interest (!) (NSPE II.3.c)

It goes on and on.

Another comparison to make is the sternness of the NSPE code, which does NOT offer its canons and professional obligations (not “Objectives for Guidance”) as “informational” or “unequally important”. Read the NSPE code and marval at the lack of weasel words. Engineers cannot offer services outside their competence, cannot hide conflicts of interest, cannot even sign off on documents that they can’t be expected to fully understand.

This makes perfect sense. If they could do those things, bridges would collapse, buildings would fall down, and my air conditioner would stop working.

So why can information security professionals do these things?

There are some foreseeable problems with the NSPE code. For one things, it overreaches a bit in favor of the employers of engineers, to no apparent benefit for society. And it refers to a level of standardization that doesn’t yet exist in information technology. But even without addressing these flaws, the NSPE code is still a pin-compatible upgrade for the CISSP code.

The difference between structural engineering and computer security is that ours isn’t an engineering field; it’s still, in most respects, a research objective. So our code of ethics has different requirements than the NSPE code:

• The NSPE code seeks to promote an orderly and harmonious marketplace for engineers.

• An ideal infosec code needs to prioritize the furtherence of research over commercial aims.

So, in my first-ever attempt to start a meme, which nobody will pick up but which I’ll still feel better for blathering about: using the NSPE code as a base, the top 5 issues an infosec code would need to address would be:

• Professional and research credit and attribution, ensuring that commercial and personal issues don’t obscure the advancement of the art. I’m thinking about “ostracizing black-hats” and falsely claiming credit for advancements.

• Secrecy and disclosure, reconciling the good of the public with the desire to withhold information for personal or commercial aims. Full disclosure, patents, NDAs.

• Human rights, because unlike the contractors on the Death Star, the people building the “great walls” around tyranny are actively promoting evil.

• Balance between laypeople and security, which is disrupted when nonsensical security requirements are enacted, when laypeople are blamed for the failings of our art, and when technology is used to create new rights and advantages for the few at the expense of the many.

• Respect for science, and in particular the the limitations thereof, so that we might avoid coercing the market into investing in unproven “ideas”. (Oh man I want to create a snarky link on “unproven”.)

No particular order, and I’ll probably repudiate this list when I reread it tomorrow morning. And here’s another thought: information security is a profession that is required only by the limitations of modern technology and the failings of human nature —- so maybe we don’t want to work to the “advancement and protection” of this profession. Maybe we want to do what we can within our lifetimes to end it.