The John LaCarre http://en.wikipedia.org/wiki/John_le_Carr%C3%A9 books. Do you remember the point where someone says to Smiley "There is no reason to think that they tapped the phone" to which Smiley replies "There is Every reason".
A must read, I tell my students in my Security Awareness training classes is The Cuckoo's Egg http://www.amazon.com/The-Cuckoos-Egg-Tracking-Espionage/dp/.... Examples like default service accounts on Dec Vax with username Field and password Service. Note when this is written and are our habits really any better with junk hung on the internet? Concepts pioneered in his book, as effective as they are, are not practiced. Note the alarms going off, ignored, at a large retailer last thanksgiving. Or another retailer recently, "Wait, what, we are being attacked? I didn't feel anything".
Most vulnerable is the thinking "Well, they can't get our X because <thing we did>". I have a matrix of attacker motives and what they are after. There motives and targetsyou haven't thought of.
The first book on that list "Grey Hat Python" isn't very good. It contains some good parts but it skips things like Scapy which a consider a superb tool if you are in the pentesting business. I recommend reading "Violent Python" instead. It's everything that Grey Hat should have been...
> I generally have a hard time with any book list for security people that includes, for instance, _Design Patterns_.
Would you please elaborate on this point? I am not familar with that book and so do not know why its inclusion reflects poorly on the list (or the list author's assessments).
_Design Patterns_ is one of those books that nerds of a certain vintage all have on their bookshelves. The lucky ones --- most of them! --- haven't read it carefully. It's a book about software architecture, and, more specifically, about turning C++ into Smalltalk.
It has absolutely no relevance to software security, even in terms of background material about computer science. (It's actually of dubious relevance to programmers in general). It's one of a couple books on this list that give it the flavor of "I just typed up my bookshelf".
It doesn't help that the summary is "Required reading for any serious programmer".
I agree that _Design Patterns_ has little to do with security, but I think you are being a bit hard on it from a programming perspective.
Certainly the book is tremendously useful for ObjC programmers because Apple incorporated most of these patterns into Cocoa and Cocoa Touch. And as someone who has done code review with junior Android developers, I wish that more devs read it. When a security researcher refers to a MITM attack or SQL injection, this higher level concepts mean something and it enables clearer conversation. That's what design patterns provide to software developers.
Apple incorporated most of these patterns into Cocoa and Cocoa Touch.
Great! That means I could just learn to work with Cocoa and Cocoa Touch and skip the tedious exposition.
I would try to explain why I've never been able to pick up a patterns book without eventually throwing it against a wall, and why I prefer to encounter my patterns in the wild as I work on actual code, where I can poke and prod them and watch how they behave in practice, but it's already been throughly explained and even given a name, The Monad Tutorial Fallacy:
Sounds to me like your junior Android developers might be learning patterns just fine: They trip over one in practice, and then they learn about it with the help of their teacher. This is how learning works. There is no royal road to geometry, and beginners don't become experts overnight just by reading the right book.
(To save you some explaining time:) I'm excruciatingly familiar with the GoF patterns and much of the broader pattern movement (I'm a recovering C++ programmer). So:
Of the original GoF patterns, which specific ones make it easier to discuss SQL injection?
"Of the original GoF patterns, which specific ones make it easier to discuss SQL injection?"
That doesn't seem to be the claim made in the parent comment. I read it as a far weaker, "In much the same way that security researchers label antipatterns that enable attacks and that makes it easier to talk about security, the GOF label patterns that make it easier to talk about design."
I don't know that the parent comment makes a good case for relevance of this claim, though, since - as you've been more focused on - this list is supposed to be more specifically for (FTA) "topics within computer security, digital forensics, incident response, malware analysis, and reverse engineering." I suppose if the system you're reverse engineering made substantial use of GoF design patterns, familiarity with them would probably help, but that seems a little bit of a stretch.
> I don't know that the parent comment makes a good case for relevance of this claim, though, since
The parent comment is responding to @tptacek's original comment:
> (It's actually of dubious relevance to programmers in general).
Where 'it' is the Design Patterns book. That's a more broad statement than just whether or not security researchers needs to read the book. The parent to your post replied to that:
> I agree that _Design Patterns_ has little to do with security, but I think you are being a bit hard on it from a programming perspective.
So, in summary:
tptacek: Design Patterns has no relevance to security. It also
has dubious relevance to all other programming.
skue: It doesn't have relevance to security, but I feel that it
does have relevance to programming in general.
From an security professional's point of view, the idea is to find flaws in software, developers thinking, or corporate culture that make vulnerabilities for attack.
GoF doesn't really help with any of the above. What GoF helps with is shoring up weak languages that don't have the proper stuff to begin with. It talks about abstractions and how to build them.
What is useful from a security professional's point of view is to learn how to puncture abstractions. Finding flaws such as information leakage between abstractions. This is a hard mind-set to come to.
Did you just want to voice your opinion and find my comment relevant enough to serve as a place to hang it, or did you mean that as a response to what I wrote? I don't think I substantively disagree, although I think Norvig's claim is often read (not sure if intended) slightly stronger than is merited. I would also note that the list does not seem to be restricted to "security professionals", but to all those interested in learning about the topics in the list I quoted above. I broadly agree with the thesis that Design Patterns doesn't fit that mold particularly well.
(In general, I find it a recurring problem on HN - and to some degree similar fora - that I am not sure what conversational role a poster intended their comment to serve; I wonder if there is a good way to address that...)
I was chiming in on support of I suppose if the system you're reverse engineering made substantial use of GoF design patterns, familiarity with them would probably help, but that seems a little bit of a stretch and to clarify my opinion about the 'tptacek comment pointing out a common vulnerability (sql injection) and how GoF doesn't really addresss it.
And we could discuss I think Norvig's claim is often read (not sure if intended) slightly stronger than is merited quite a bit. I might go the other way, as I think Norvig is really quite gentle in making his points.
So not disagreeing with your comment, and perhaps I did hang my comment on the wrong post.
Regarding GoF, I think having more well-known constructs to reference can provide some value even when those constructs are motivated by overcoming limitations that may not be present in a given context. Picking more broadly useful constructs will provide more value, but you may or may not be able to get there from here, and certainly (perhaps unfortunately) enough people still find themselves coding in contexts where GoF patterns can be directly useful.
I have now heard from several people about applied crypto being outdated and replaced with crypto engineering. I have since ordered the engineering book and based on initial reading will likely replace applied with crypto engineering once I am done (I only post books I have fully read).
I am not sure about the criticism of intro to modern crypto and design patterns though. I learned alot from both of them in my computer science classses that used them and the information is still vaulable and useful to me.
Although I haven't found GoF book useful when looking to solve a problem at work, it has come super handy when preparing for technical interviews. I must admit that over the last 10 years I haven't managed to answer any of the Design Patterns questions satisfactorily. Never mind that the roles required Perl/Python scripting skills in the job post.
The Tangled Web is written by Michal Zalewski. The book is the updated version of the famous Browser Handbook. [1] I still recommend looking at it if you can't get The Tangled Web. IMO, this is the bible of web security today.
I really hope people can put together a web security book (and free) that is up-to-date. To me, the Tangled Web does a pretty good job, but there are still nuts and bolts missing or wordy.
OWASP wiki is okay-ish but I really hate digging the wiki just to find the information is either incorrect or outdated.
The Hacker Crackdown by Bruce Sterling (cyberpunk author) is awesome. It's the story of Captain Crunch and the rest of the phone phreaks in the late 80s and early 90s, and some of the earliest prosecutions of hacking by the U.S. federal government. Apparently they still throw a 2600 magazine party at defcon....
I only posted books to the list in order to keep it managable. If I tried posting blogs, journal articles, etc. then the list would go on forever and be impossible to ever finish.
Whatever the list lacks, it is a very long list, let's admire its amazingly broad and deeply substantial veins for us to mine and keep on learning about for a long time. For those of us who have not yet reached the glory heights climbing the learning curve appreciate the vast richness of the resources while stumbling among them to find the best way to gain traction.
Here's a strategy, I'll organize a visit to our local technical bookstore, see what new and used gems await me like a treasure hunt to secure such dead tree scrolls.
Let's say I'm interested in building an app that uses encryption: an end-to-end email client and/ or server, a tarsnap competitor, or I just want to build a privacy conscious app (end-to-end encryption of user data, basically). How should I get started, would there be a reading list on cryptography besides the security reading list?
(And yes, I know the best way is to get a PhD building the thing, but I'm interested in learning nonetheless )
For people really interested in crypto there's obiously HAC [1].
For people interested in something that is updated each year: LNCS from DIMVA and RAID are quite good for understanding the problems or future problems and their solutions.
A real hacker would tell you that all these books are really not needed. All you need to know is in-and-out of any one os( say windows), and good understanding of any one hardware architechture (say x86). Practical reverse engineering\hacking is then about getting your hands dirty by doing things using tools like IDA. What you really need is a very strong intuition and understanding of software upside-down (from hardware instructions to source code and vice versa). There is a reason why practical hacking\reverse engineering is an ART.
A real hacker would tell you that all these books are really not needed.
Who's saying that these "need" to be read? Maybe the HN title has been changed in the meantime, but this is entirely presented as a list of resources. You're not going to argue against reading books as a component of education, are you? And I don't even want to know where that "real hacker" stuff is coming from. That word hasn't meant anything concrete for over a decade.
My recommendations would add:
http://www.amazon.com/The-Codebreakers-Comprehensive-Communi... by David Kahn. Many stories of the whole history of secret communications, with lessons in op-sec, not changing the codes frequently enough, they can't possibly break this.
The John LaCarre http://en.wikipedia.org/wiki/John_le_Carr%C3%A9 books. Do you remember the point where someone says to Smiley "There is no reason to think that they tapped the phone" to which Smiley replies "There is Every reason".
A must read, I tell my students in my Security Awareness training classes is The Cuckoo's Egg http://www.amazon.com/The-Cuckoos-Egg-Tracking-Espionage/dp/.... Examples like default service accounts on Dec Vax with username Field and password Service. Note when this is written and are our habits really any better with junk hung on the internet? Concepts pioneered in his book, as effective as they are, are not practiced. Note the alarms going off, ignored, at a large retailer last thanksgiving. Or another retailer recently, "Wait, what, we are being attacked? I didn't feel anything".
Most vulnerable is the thinking "Well, they can't get our X because <thing we did>". I have a matrix of attacker motives and what they are after. There motives and targetsyou haven't thought of.