The doom and gloom in the security market spreads. This time it is from Richard Bejtlich who probably knows his stuff as well as any (spotted at Gunnar's 1raindrop). After a day at Black Hat, the expensive high-end "shades of illegal" conference in security, he concludes:
Note how he includes the security professional in there. Yup. The problem is that the knowledge space has ballooned and nobody can keep up; Internet security is now a game that is way to broad for anyone to really cover it all.
Even before the current "war on everyone" you still had several problems with the security industry: lack of understanding of the business, which fed into poor choices being generally too expensive, and a tendency to "best practices:" purchased products because brands deliver CYA as well as high prices, etc etc. Over time, industry discovered they made more money if they didn't hand it over to security ... until 2003 that is, when phishing found its lure.
If then, you can't find someone to do it for you, you have to do it yourself. This is what I called Hypothesis #6 "It's your job. Do it." But exactly what does that mean?
#6.5 You need to be an adept in many more aspectsIn all probability you will need to be adept -- well versed if not expert -- in all aspects, right up to user activity. This will stretch you away from the deep cryptographic and protocol tricks that you are used to as you simply won't have time for all that. But an ability to bridge from user needs all the way across to business needs, and then down to crypto bits is probably much more valuable than knowing yet another crypto algorithm in depth.
The FC7 thesis is that you need to know Rights, Accounting, Governance, Value and Finance as well as Software Engineering and Cryptography. You need to know these things in some depth not to use them but to avoid using them! And, more particularly, avoid their hidden costs, by asking the difficult questions about the costs that nobody else dare recognise.
Perhaps the best example was the decision by Microsoft to stop coding and start training all their coders in security practices. Not just some of them, all of them!
Where this leaves the conventional security professional is perhaps an open question. I would prefer to say that instead of prescribing solutions and sometimes supplying them, he would shift to training and guiding. This would involve a different emphasis: if you assess that an IDS might help, in the past you sold an IDS. Now, however, you would assess whether the team leader could cope with an IDS, pointed her in that direction, and mentored the assessment of the tool by the entire team. If they aren't up to that, then you have another problem.
Posted by iang at August 5, 2007 06:51 PM | TrackBackway back when ... it was about designing & implementing systems/infrastructure to prevent bad things happening.
some slight (nearly 40yr old) drift:
http://www.nsa.gov/selinux/list-archive/0409/8362.cfm
now we have a lot of systems/infrastructures where it is all about attempting to recognize when bad things have happened ... and the basic systems/infrastructures are effectively recognized as extremely vulnerable ... and solutions are effectively done in terms of bailing wire and chewing gum.
(one might be tempted to say that things have severely regressed and there is little lore left anymore about prevention)
recent reference:
http://www.garlic.com/~lynn/aadsm27.htm#48 If your CSO lacks an MBA, fire one of you
old buffer overrun post
http://www.garlic.com/~lynn/2005d.html#55 Buffer overruns
with these references
Microsoft Researchers Target Worms, Buffer Overruns
http://www.neowin.net/comments.php?id=27321&category=main
Microsoft researchers target worms, buffer overruns
http://www.infoworld.com/article/05/03/03HNmicrosoftworms_1.html
Microsoft Researchers Target Worms, Buffer Overruns
http://www.pcworld.com/news/article/0,aid,119891,00.asp
or this old post:
http://www.garlic.com/~lynn/2000.html#25 Computer of the century
with reference to discussion of how to deal with some number of C-language related coding problems .... 90% of which wouldn't happen in various other programming languages.
passing reference at a assurance panel in 2001 to comment about m'soft holding up windows 2000
http://www.garlic.com/~lynn/aadsm5.htm#asrn4
I remember in the early 80s ... where state-of-the-art had progressed to the point where work was going on ... not with regard to outsider attacks or straight-forward insider attacks (supposedly still responsible for up to 70percent of the fraud) ... but the state-of-the-art was "collusion" countermeasures .... i.e. organized groups of insiders attempting to bypass provisions preventing insiders from subverting the systems.
misc. past posts mentioning that early 80s security state-of-the-art focusing on insider collusion (i.e. having procedures in place for outsider attacks and the simple, straight-forward insider attacks)
http://www.garlic.com/~lynn/aadsm3.htm#kiss10 KISS for PKIX. (authentication/authorization seperation)
http://www.garlic.com/~lynn/aadsm7.htm#auth Who or what to authenticate?
http://www.garlic.com/~lynn/aadsm9.htm#pkcs12d A PKI Question: PKCS11-> PKCS12
http://www.garlic.com/~lynn/aadsm11.htm#10 Federated Identity Management: Sorting out the possibilities
http://www.garlic.com/~lynn/aadsm12.htm#33 two questions about spki
http://www.garlic.com/~lynn/aadsm18.htm#17 should you trust CAs? (Re: dual-use digital signature vulnerability)
http://www.garlic.com/~lynn/aadsm23.htm#10 PGP "master keys"
http://www.garlic.com/~lynn/aadsm24.htm#36 Interesting bit of a quote
http://www.garlic.com/~lynn/aadsm24.htm#40 Interesting bit of a quote
http://www.garlic.com/~lynn/2004j.html#15 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2005g.html#37 MVS secure configuration standard
http://www.garlic.com/~lynn/2005g.html#38 MVS secure configuration standard
http://www.garlic.com/~lynn/2005k.html#1 More on garbage
http://www.garlic.com/~lynn/2005v.html#2 ABN Tape - Found
http://www.garlic.com/~lynn/2006d.html#30 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006k.html#16 Value of an old IBM PS/2 CL57 SX Laptop
http://www.garlic.com/~lynn/2006k.html#33 Password Complexity
http://www.garlic.com/~lynn/2006n.html#32 The System/360 Model 20 Wasn't As Bad As All That
http://www.garlic.com/~lynn/2007f.html#39 Silly beginner questions