Offensive Security has opened their exploit database. This is a response to the halt of milw0rm due to whatever circumstances. In fact, they improve on it a bit by sometimes adding a link to the vulnerable application, which is pretty slick. If there’s anything missing, it’s that I haven’t seen an equivalent section for the milw0rm videos. (Bonus: this site isn’t blocked by Cisco like milw0rm is!)
Social-engineer.org has a new podcast out about, wait for it….social engineering! Hopefully this becomes the de facto place for SE information and education.
Mike Smith’s (rybolov) DojoSec talk on compliance is a good listen. The panel is good as well, although be forewarned that it gets deeper into government-types of compliance and standards. One theme: collaboration in creating and defining regulatory controls.I had to pull out one quote from Mike from the panel in regards to a question about graularity in compliance controls: “If you make [regulatory controls] very, very broad, you’re relying more on [in-the-trenches practitioners] with varying levels of skillsets to interpret it, but if you make it more and more specific, then you rule out a lot of other solutions. So you lose a lot of that flexibility. And in the places where you have really smart people who know what they’re doing that actually limits what they can do.” Other DojoSec videos can be found in their archives.
Andrew Hay decides to torture himself by reading (and then sharing!!) horrible press releases. Yes, I agree a little bit dies inside whenever I read this drivel where it reads more like marketing (or a company) trying to impress themselves with long sentences filled with vague buzzphrases and 5-cent words. This is why I prefer to talk to the SE and get my hands on products directly to form my own conclusions.
Chuvakin has been busy! First, he throws down about SIEM complexity (for me, SIEM is a nice-to-have only because it ends up being too complex…but that’s what you get in pursuing the futile effort of replacing analysts with a box, rather than marketing SIEM as a tool to *assist* analysts…). Second, he grabs FUD by the throat both for a shake and a hug. (Me, I don’t rail on FUD too often because I agree, it’s necessary and will never go away, but that doesn’t mean we need to wallow deep in it; besides, “FUD” itself is too subjective…). And third he addresses the devil of PCI DSS. (Again, my take is that PCI DSS is just fine, but organization’s suck at security in general and they’d suck even worse without PCI DSS. I don’t get how that’s hard to swallow.)
To swerve off on a brief tangent, security is not solvable. To this end, that means media can forever be able to point out flaws. Likewise, analysts can forever be able to point out how measure XYZ doesn’t address MNO. And further, FUD can always be brought up (whether “FUD” is a negative or a positive to you depends on that subjective definition [connotation/context] you place on it). Therefore, when I read tales about how XYZ isn’t addressing MNO, my first question has to be whether I need to care about MNO, not to rail against XYZ. My second question has to be how I would addres MNO, regardless whether XYZ exists or not, especially if XYZ is just a product/standard and not a concept. My third question would be whether XYZ *should* address MNO. And so on. If you read the links Anton lists in the devil entry, this paragraph will make more sense. Don’t create XYZ to be a devil when that’s missing the crux of several problems.