Archive for June, 2005
Thomas Ptacek | June 29th, 2005 | Filed Under: Uncategorized
Interesting Cell/Xenon scoop on Slashdot today:
Not to mention that the requirements for hitting peak theoretical
performance are always ridiculous; caches are only so big and thus
there will come a time where a request to main memory is needed, and
you can expect that request to be fulfilled in a few hundred clock
cycles, where no floating point operations will be happening at all.
Ahhh, memory performance. Great equalizer, righter of wrongs. How
will you work your wiles on the Octeon? The 1450? The Raza
XLR?
Of course, it’s also necessary to reconcile this new “multicore will not take over the world as planned”
meme with what Cringely said
a few months back. You mean I can’t go get a 10MM round by launching the industry’s “first Cell-based
network IPS”? Or did Symbiot
already try that?
No Comments
Thomas Ptacek | June 29th, 2005 | Filed Under: Uncategorized
Like many of my generation, I am plagued by The Marcus Ranum
Conundrum, which causes me to define myself in opposition to someone
who usually comes off as so smart and levelheaded that my conflicting
feelings actually inspire self-doubt. Thankfully, MJR can be counted
on to occasionally say something crazy enough to throw our differing
perspectives into relief:
Truly, the only people who deserve a complete helping of blame are
the hackers. Let’s not forget that they’re the ones doing this to
us. They’re the ones who are annoying an entire planet. They’re the
ones who are costing us billions of dollars a year to secure our
systems against them. They’re the ones who place their desire for
fun ahead of everyone on earth’s desire for peace and [the] right to
privacy.
Mind you, the true nastiness of this statement can only be appreciated
in context, where MJR makes it clear that teenage joyriders occupy a
moral strata lower than that of spyware purveyors and negligent
vendors, who endanger the public for personal commercial
gain. Because, I mean, it’s not as if the side benefit of the hacker
rennaissance of the 1990s was the most drastic improvement in network
and software security in world history or anything, or that the
sweeping improvements they motivated came at a near negligable cost,
especially compared to the potential cost had we found out about
these problems the hard way.
If you don’t know what the hard way means, you weren’t paying enough
attention to Winn Schwartau. Not that I blame you.
1 Comment
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:
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.
3 Comments
Thomas Ptacek | June 24th, 2005 | Filed Under: Uncategorized
This is a really cool video, doing
structured assembly code analysis. It’s just an illustration of using assembly/bblock diff to reverse engineer an MSFT
patch, which is “old news”, but the meme it infects me with is: if we can visualize basic blocks and call graphs,
restoring structure to assembly code, what good is keeping the source code secure anymore? I know Halvar’s response
would be, “no shit”, and many people (myself included) have found vulnerabilities by reading assembly code. But this is
something subtly different: it’s 80% of the value of a decompilation —- it’s effectively a new form of source code, an inescapable translation into a new, equivalent higher-level language.
hAH-hAH!
Note to the CISSP guys who think this is “case in point” for why we should obscure or encrypt security patches: you can diff a running image just as easily as you can diff a file. Getting access to the assembly instructions isn’t hard for anyone; it’s making sense of them, versus reading the source code, that presents the challenge. Or, presented a challenge.
No Comments
Thomas Ptacek | June 23rd, 2005 | Filed Under: Uncategorized
I really wanted my next Bejtlich cite
to include a draft proposed code of ethics, to respond to the CISSP thing,
but I have to comment on a more recent
post:
His thesis, Using NetFlows for Slow Port Scan Detection, argues that
NetFlow records can be used to detect stealthy reconnaissance
Virtually all the anomaly companies do this now.
Arbor has done it since 2003. The basic technique comes from
Solar Designer.
(BTW, doesn’t it rule that most of the “fresh” ideas in network security,
like service/OS fingerprinting, come from Phrack?).
Here’s an excellent paper on scan
detection (as usual, affiliated with Vern Paxson). A followup Weaver paper
argues that if you embedded the original idea into a switch, to suppress
scanning outright, you could contain worms. I think that’s sorta clever.
No Comments
Thomas Ptacek | June 21st, 2005 | Filed Under: Uncategorized
Please note that “a really good set of guest speakers”, from last post, is in no way meant to be construed as an endorsement of me as a good guest speaker. =)
No Comments
Thomas Ptacek | June 21st, 2005 | Filed Under: Uncategorized
Stuck in Baltimore today, after giving a talk at the Pentagon Security
Forum. A bit wiped out to post. But I obviously want to respond to
Bejtlich’s response to
my post about
the CISSP code of ethics, if only because a mention on Taosecurity seems
to be worth about 487893473498 hits to my blog. And I’m all about the hits.
I’ll post slides & notes from the PSF talk; those who’ve had the misfortune
of seeing me talk at ISSA will find them suspiciously familiar.
The PSF is a surprisingly with-it operation; they’ve gotten a really good
set of guest speakers over the last year or so. And my son got a toy tank
out of it, to pay up the royalties he gets every time I mention his name in
this silly blog, from the gift shop at the world’s best-defended shopping
mall.
No Comments
Thomas Ptacek | June 17th, 2005 | Filed Under: Uncategorized
Richard Bejtlich inspects
a survey from the ISC2, corporate owner of the CISSP
certification, and finds it asking him whether “something you know” is
more important to the exam than “something you have” or “something you
have”, whether “value-added networks (VAN)” are more important than
“global information grids (GIG)”, and whether “hubs” are more
important than “routers”, or “gateways”.
Heh.
Richard (who holds a CISSP) says: The only value CISSP retains is its
Code of Ethics.
Is that so, Richard?
It’s not much of a secret that I sincerely dislike the CISSP —- to
the point of feeling slightly distrustful of people who openly admit
to holding the certificate. Call me crazy, but a certificate that is
held by less than 10% of the most respected practitioners in the
industry, but that is held by more than 90% of third-string consultants and
entry level IT secops, lacks some credibility.
There are a variety of good, specific reasons to disdain CISSP, but
you can sum the whole thing up this way: there’s a 90% likelihood that
the next major security advisory isn’t going to come from someone
who holds a CISSP, and a 90% likelihood that the next weirdo
suggesting a scheme whereby security patches remain encrypted until a
critical mass of users have installed it so that “hackers” can’t get
the details of the exploit is going to come from someone with a
CISSP.
But this isn’t a post about the (lacking) merits of the CISSP
certificate itself. It’s a post about the (lacking) merits of the
CISSP Code of Ethics.
Three proposed “rules of thumb” about a security “code of ethics”:
Rules that are self-evident are not useful. If you can take
a rule, stick “don’t” at the front of it, and come up with an
ethical statement that my five year old son Galen can reject, you
are demagoguing, not helping.
Rules that defend the salary of CISSP-holders instead of
the integrity of the practice or the common good are not
useful.
Rules that defend the salary of CISSP-holders at the expense
of the common good are less than not-useful.
“Compliance with the preamble and the canons” (of the code) is
“mandatory”. Well, the preamble says “you must comply with the
canons”. What do the canons say?
Protect society, the commonwealth, and the infrastructure.
Hey Galen: Should you protect society? The commonwealth?
The infrastructure? Cute little puppies? Criminals?
Whoah. He got all of them right. Strike one “canon”.
Act honorably, honestly, justly, responsibly, and legally.
Galen: Should you tell the truth? How about when telling
a lie will get you a candy bar?
Is it possible that my kindergarten-age son was born with
an innate sense of the ethics of computer security? It is
in the genes, you know.
Provide diligent and competant service to principals.
Well, Galen doesn’t know most of these words. But let’s try
this:
Don’t provide diligent and competant service to principals.
Hey wait a minute, I know consultancies that use this second
statement as an operating charter. But that’s ok! The CISSP
code clearly states:
Conflicts between the canons should be resolved in the order
of the canons. The canons are not equal and conflicts between
them are not intended to create ethical binds.
I’m not making this up: the CISSP seems to want to leave you
wiggle room to resolve “conflicts” between “competancy” and
“honesty”.
Advance and protect the profession.
Now we’re getting away from the Galen test and into rules
number 2 and 3 of “codes of ethics”. Let’s look at some of the
sub-bullets for this “canon”:
Sponsor for professional advancement those best
qualified. All other things equal, prefer those
who are certified and who adhere to these canons.
My break here Avoid professional association with
those whose practices or reputation might diminish
the profession.
Is it prima facie unethical to offer to render life-or-death
security services based on experience you can claim only by having
read a Que “… in 21 days” book? Yes.
Is it prima facie unethical to equate yourself professionally with
people who can render those same services based on a decade of
battlefield experience? Yes.
Is this “ethical bind” covered by the CISSP code? No.
Information security is rife with ethical conundrums. Vulnerability
disclosure. Exposure versus liability versus availability. The SPAM
blacklist
debacle. Product
marketing and selection. A real
code of conducts —- one that actually enumerated the tradeoffs
involved in real professional conflicts and gave real guidance, would
be useful.
If this code is
the best thing Richard can say about the CISSP, he’s damning it with
faint praise.
2 Comments
Thomas Ptacek | June 16th, 2005 | Filed Under: Uncategorized
I keep whining about how slammed I am lately. Here’s part of the
reason (but only part of it, and
more news is coming).
This is a class about beating the hell out of security products.
You can check out the syllabus for
more details. But for now, I rant:
Security vendors are just like any other technology vendor. It might
not be obvious, but it should make intuitive sense. Your firewall
vendor is under the same pressure that any consumer software vendor is to:
Market their products aggressively
Manipulate published tests to show their products in the best
possible light
Complete revisions of their software on insane schedules
Add at least enough features with each version to keep parity
with their competitors
Invent features, reasonable or otherwise, to achieve an edge
over their competitors
Do the bare minimum amount of work to ship those features and
grab the “merit badge”
The network security space alone represents over two billion dollars
per year in revenue. In large enterprises, a single major deal can
score a vendor over a million dollars. If you think vendors aren’t
employing absolutely every weapon in their arsenal to get their gear
deployed, you’re being naive.
A younger,
dumber
Thomas Ptacek would have railed against the vendors for this. (Maybe
even gotten a bit
vindictive).
But an older, wiser Thomas Ptacek (shut up, anybody from Arbor) has
begun to accept that maybe there’s nothing wrong with vendors being
aggressive. Gag.
Maybe the problem is how hopelessly outgunned buyers and evaluators
are. There’s no Consumer Reports (or
better yet, Cooks Illustrated ) for
security products. Those publications don’t take advertising, and
spend their money on test labs (or kitchens). Instead, we have:
Evaluations that begin and end at running “nmap” against the
IP address of an IPS.
Bogus “certification” programs with unpublished criteria that
every vendor mysteriously seems to pass.
Magazine reviews that center on performance (until you turn
all the defensive features on) and quality-of-UI.
Aggressively-enforced nondisclosure agreements and account
qualification to keep flaws from being circulated.
Product selection influenced more by the logo on the front
of the box than on the capabilities of the actual product.
Hundreds of different one-off test tools scattered across
the Internet, many of which don’t build on an OS distributed
within the last 5 years. (Whistles innocently).
Routine disclosure of serious flaws in major shipping
products. (For some reason, I’m feeling tactful enough not
to link each of those words to an advisory or white paper).
So, long story short, we saw a need for a class like this. We’re
running it for the first time (in its complete form) at Black Hat this
year. This time around, the class focuses on network security
tools. If I was going to boil our syllabus down to three main
objectives, it’d be:
How to go from a standing start to a professional-grade
product testing lab in the shortest time period possible.
How to decode, debunk, and defend yourself from vendor
marketing ploys and snake oil.
How to employ the same techniques attackers do to evade
detection and deflection.
You can find more information about the
class here, or at the Black Hat
course
page.
[more security]
No Comments
Thomas Ptacek | June 15th, 2005 | Filed Under: Uncategorized
If one thing assuages my irritation over this ridiculous Symbiot press hit, it’s
the fact that the company was reduced to issuing a press release saying it “targeted” a $10MM round.
Further dubious Symbiot claims:
- That they won an Apple Design Award (they were runner-up in a category that seems to equate to “first product to ship on an Xserve”).
- That they work with the Apache Software Foundation on OSS SIM (they proposed their project as an Apache Incubator project, to no apparent avail.)
- That Cisco has validated their claims by launching a Self-Defending Networks strategy; Cisco SDNI is the marketing successor to SAFE, and has nothing whatsoever to do with strike-back; also, Symbiot seems to have changed their branding to mimic Cisco’s.
- That their ideas appeared on a major TV show (a product placement on Fox’s 24, which had nothing to do with Symbiot or strike-back).
- That major corporations have deployed public deployed strike-back technology (presumably Symbiot’s, though I can’t find one press release naming a customer on their site).
- That their white paper launched an industry-wide debate on strike back (any debate seems to have begun and ended with Schneier calling Symbiot immoral, potentially illegal, and uncivilized).
Really though, the problem isn’t that “strike-back is immoral”. It’s that it’s stupid. The defining attributes of an Internet attacker are anonymity and mobility. Pinpointing a single compromised box and wailing on it with some vendor’s lame flooding script accomplishes precisely zero to improve your security. Whomever is attacking you will laugh at you. And so will I, for wasting money on such a useless tool.
No Comments
