When looking for new blogs to follow (or design ideas), I tend to just stumble around the links on other people’s blogs. If you’re looking for new blogs to follow, the RSA Social Security Awards nomination list (pdf) is an excellent source.

In fact, I had no idea there were that many podcasts out there now!

Interested in command line codes? Check out the Command Line Kung Fu blog. I especially dig this ping beep post that will beep for any lost packets.

If you want to hear from the authors and why they made this, check out the first part of Pauldotcom episode 146.

Gnucitizen has a security buzzword generator available which generates often amusing and often non-sensical buzzword-sounding security phrases. It’s a little mean, but I suppose you could test some against anyone and see if they’ll admit to not knowing wtf you’re talking about.

“Yes, we need to be concerned about Indirect Server Reversing.”
“I think our government needs to worry about Extraterrestrial Memory Routing.”
“Our solution does provide protection against JavaScript Stalking.”
“So, what are you doing about Backend Shellcode Sidejacking?”

If you have a Cisco ASA or Pix around, you might want to think about patching it. Cisco has released information on several vulnerabilities. Particularly interesting are a couple remote DoS attacks and an ACL implicit deny bypass.

The latter is a bit vague and scores low on the Cisco metrics for impact. In some postings I read it as an ACL to get into the device, but in other wordings I get the impression it affects firewall rules for traversing the box. Either way, hopefully you use explicit DENY and don’t rely on the implicit one.

System security belongs to systems admins. The network to the network dudes. And the developers get to reign over the security of the apps they write. But where does something like the .NET framework fall? Sort of in between the cracks between system admins and developers. Developers don’t write it or manage the code, and systems admins most likely don’t know it very well either. (And I’m not even delving into consumer systems, just servers.)

Enter: .NET rootkits.

A .NET rootkit modifies the core framework DLLs from Microsoft (located in the GAC). A .NET rootkit may only be a symptom of a bigger problem: someone already owns your box hard enough to be able to replace framework files. But it might also be something that rogue developers can sneak into a production system. Even a sysadmin may taint something like an image base that other servers are built from.

It is probably a good idea to add some framework DLLs (or all of them) to any tripwire or digital integrity monitoring you have. If they change, an alert gets thrown. Caveat: I have not implemented such measures myself, so I don’t know if they change too often naturally. I assume they don’t.

Traffic egress should also be monitored. One purpose to rootkit an application is to siphon off its data. It can accumlate on the server (disk usage monitoring!), but ultimately it needs to get somewhere else to be useful to an attacker.

This doesn’t stop with .NET frameworks, but really any framework environment, such as Java.

Details on a 2008 Fedora intrusion. Nope, not necessarily a technical vulnerability but rather a people/key/procedural one, for the most part. And yes, keys without passwords make life breezier, but also riskier.

Also interesting is the timely, and lucky, discovery of the intrusion. It sounds like something like this could have persisted for a while, until whatever discovery/detection/tripwires they have laying around were triggered. Then again, maybe that failed cron job failed because of the actions of the intruder. That almost sounds reasonable considering the near-immediate detection. Maybe the cron does some sanity check…or it was just coincidence that an admin’s eye was pulled over to the logs at such a convenient time. 🙂

Nonetheless, kudos and beers for giving details not just for our own knowledge, but as a sort of lesson-learned-through-others deal.

RSnake (ha.ckers.org) has posted a nice list of purposely vulnerable sites, apps, and other ways to challenge one’s hacking skill. I have a small list on the right menu “things to do” section. Maybe someday I’ll go through his and transpose them to my menu, but for now a simple single link to his will suffice.

This really just reminds me that there ought to be 36 hours to every day…and I also see some of my links are now defunct. Ick.

Oh, I mentioned I took the CISSP exam in an earlier post. I neglected to say I passed!

So, what’s next? I’m not really sure, but I’m looking forward to something new. I know last year I started the OSCP course right at the same time a coworker left the organization which swamped me for about 8 months. Needless to say, I didn’t get time at all to dive into it. However, I don’t feel at all bad about any wasted money as it goes to the same people who deserve it for maintaining/creating BackTrack. I have absolutely no problem helping them out. But I’d like to tackle it again with some actual devoted time!

Longer-term, I may want to stick with the idea of alternating between hands-on, technical studies with courses that are more about book-study or less technical.

I just wanted to quote an article quick that talks about the US Interior Dept’s lack of security despite warnings in the past. This part spoke to network monitoring and being able to see what is leaving a network:

“According to the Department’s own analysis, nearly 70% of the network traffic leaving the Department through a single one of its Internet gateways during the month of January 2008 was bound for known hostile countries and the Department lacked the capability to even determine what the traffic was,” the report reads.

When I tested for my CISSP a few weeks ago, I was struck by how little information there is about the logistics of the exam itself. The admission information pretty much says, “Dress: Business Casual” and that’s about it! Many CISSP books go into some detail in the intro sections, but you never know if they’re up-to-date or not. So I wanted to post some info based on my recent experience.

The environment. Get there early and be prepared to put your coat, bags, food along a side or back wall. Turn your cell phones off or turn off all alarms/rings/vibrations! Bring a simple wristwatch if you have one, but there should always be a clock visible. The only things allowed at the desk were pencils, something to drink, your admission papers (which were collected after filling in the first part of the answer sheet), and for women their purse. We had pencils provided for us along with a pencil sharpener, but I would always recommend bringing at least a few of your own just in case. The test is a bubble-sheet test so you need a #2 pencil. You can write all you want on the question booklet.

The admissions doc says the dress is business casual, but at my location there were t-shirts, shorts, etc. I can’t imagine proctors would turn anyone away for their dress and indeed none were. So dress dress comfortably.

The exam. I can’t speak about specific topics/questions/answers, but I can talk about general stuff. Unlike almost every practice exam out there, there are no multiple-answer questions. There are very few (I don’t recall any!) negative questions (e.g. ‘which of the following is NOT…’). There are some scenarios that have more than 1 question regarding it. There are plenty of “best answer” questions.

Feel free to get up and walk around, or get a proctor’s attention if you want to go to the bathroom. Only one person was allowed out at any time, and you have to sign out and back in. You can get up and move to the back and have a bite to eat if you need to, or just stetch your legs. I took my test in downtown Minneapolis and we had a nice 8th floor corner office view of the NE part of downtown, so the ability to look up and out for a bit was really nice!

The test is 250 questions, which means you should plan at least 3 hours. This is a lot of sitting, so if you need to, get up to get your blood flowing. If you don’t work fast, I think you get a total of 6 hours. Think: 9am to 3pm.

Studying. My really quick suggestion for what to study with, I’d suggest the official CISSP book plus an additional supplement. The official book because, well, it absolutely has all the material! And a second book for something that is far better to read. (I used the Stewart, Tittel, Chapple book). I don’t suggest practice tests as they are often focusing on stupid minutiae or awkward question structures. And when at all possible, try to relate or bring home topics to something at your job now, or past jobs. Relevancy makes dry topics far more memorable.

Also, if you want to take the CISSP, there is little reason to not take the CompTia Security+ cert beforehand. The technical concepts overlap greatly and it is quite a bit cheaper and easier as a sort of warm-up.

My company is in an industry that has had to deal a bit of negative press in the last 8 months or so (the industry, not my company). One thing I learned today in a corporate meeting is that you can decrease media coverage by complicating a topic. That certainly makes sense, and I bet is a strategy they teach in PR school early on (living with a couple PR girls in college didn’t rub off I guess!).

But the principle goes beyond just PR and general media coverage. The point is complex topics make for bad news bites, bad readability, bad audience understanding, and bad digestability.

Kinda sounds like the fight we have to do to for budgets, management presentations, visualization of effectiveness (scorecards!) and…damnit…compliance. Hell, it even relates to security awareness!

If you work in IT and are not focused solely on the desktop side (systems, network, security, admin, management…) then you really have to be aware of what PCI DSS is and where it may or may not be going. Anton has posted a link to this week’s Congressional hearing on PCI along with various links and reactions to it. I suggest at least skimming it to get an idea of what happened, even if it does feel like watching C-SPAN during summer vacation.

Here’s a really brief itinary of what happened in case you want to skip around (heh, and what I sent my boss).

Gov’t: Chairwoman Clarke reads a prepared statement
Gov’t: Chairman Thompson reads a prepared statement
-recess for about 30-40 minutes-
Gov’t: Rita Glavin from DoJ reads statement and answers some questions

Witnesses/Panel statements in order:
PCI Council: Bob Russo
VISA: Joseph Majka
Merchant: Michael Jones (CIO Michael’s Stores)
Merchant: Dave Hogan (CIO National Retail Federation)

Followed by questions for the group. (starts with about 22 minutes left)

If nothing else, at least skip out to the final 20 minutes of questions.

I don’t use Digg.com. But I have watched the podcast Diggnation since about the 6th episode (currently 196 episodes). I didn’t watch TechTV at all (never once!). But I grew into being a fan of Kevin Rose’s from his too-short series The Broken (which dealt pretty much with hacking and I think was the entire inspiration behind things like, oh, Hak5!). I find his story and progress in business to be utterly fascinating. The dotcom bubble burst nearly a decade ago, but people like Kevin (it’s poignant that I reference him by first name as if I know him) are the embodiment of this extended surge of tech and web culture and business.

I only just read an Inc magazine article from last November about Kevin, along with a series of 10 questions for him. I find what he does and has done remarkable. Maybe partly because I’m on the fringe of his audience (I don’t click ads, I don’t read Slashdot, and only infrequently used to read Fark…), or maybe because of his age (born 1977), or maybe because he’s just a fellow geek pursuing his passions.

Or really, it might just be because he was the right guy at the right time and place and did the right things. He got into the geek culture with TechTV and did what I think most geeks find fascinating: talked about hacking stuff. This got him a following, and then he leveraged that following along with his technical ability (which we have to admit was not beyond any of us), passion for social media (not beyond any of us), and his ability to interact with people online in a positive way to attract users (not beyond any of us who’ve been around the nets for 10 years). Anyone who has tried to build a forum or community or site knows that it either takes a solid core following or a lot of extremely involved (and present!) work, let alone the relevant content.

And beyond that, he still maintains an image of the guy you can see at a bar, poke on the shoulder, offer a beer to, and he’ll happily accept and be immediately down with any geeky, friendly banter that may occur. As opposed to someone in a tie whom you can’t approach without an appointment and would look at you like one of the little people for even thinking he might want to drink a beer. Old media meet new media.

Oh man, was that a man-crush post? At any rate, I wanted to post the article link and just kinda gush for a moment about someone I respect, not because he has tens of thousands of followers, but simply because he’s ultra successful as a geek and appears to stay extremely grounded.

CSO has another article up with a story of a not-quite-data-breach. I apologize for no attribution since I don’t recall where I got linked to this from.

While this does drive home code reviews and data access control concepts, it also, to me, drives home another aspect.

I fully agree we need to build things securely and correctly the first time and we need code reviews and less willy-nilly development. And while that is all a great goal to keep in mind, I will always concede that it is neither perfectly, humanely, or economically possible to rely on that paradigm. Kinda like saying our endpoints really do need to be secure, but really, will they ever be satisfactorily secure with non-geek users at the helm?

This is why I will always put so much weight back onto the network as a place to detect and monitor everything else. The company in question should have easily been able to notice outgoing data to their vendor from their webservers (1 terabyte in 6 months!).

Now, they may not have been able to know what was going on since it was wrapped in SSL, but I doubt it would take much effort to get between that and decrypt it anyway, depending on how well it was coded to look for valid certs (chances are, not at all). Or at least start digging into the web servers deeper to see what is going on.

But the fact remains that proper network monitoring can detect bad things like this extruding from an enterprise.

(Likewise, proper network controls like firewalls should also be able to notice or log blocked outgoing 80/443 traffic from the webservers. While some apps do end up needing a hole open to a third-party, it should be a pinhole, not a total allowance. But again, we’re ultimately talking network still.)

I like stories of things that work and don’t work in security. The SANS Internet Storm Center reported this story of a router hack.

Three concepts stand up pretty loudly here, and are echoed in the lessons learned part of the story.

1. Monitor for changes! Having a script pull configs and compare them for changes, then raise an alarm is really small effort for huge gains. This can also work as an internal change management control as well.

2. Logs are vital.

3. We make mistakes as humans, and we need to assume they will be made and those mistakes will be found by an attacker eventually. Always review devices, configs, settings, logs, scripts, etc. Reviewing this stuff is boring and often reveals nothing, but that one time it does reveal something like an unremoved test account or access, will save bundles. If that attacker had more time and had simple done more, he may have already captured some data or dug in deeper into your network, past the config-protected routers. At least the Rancid script cut this off, but there was still a window of time where the attacker was in control and could have done more.