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.

Need to comply with PCI? Whether you have wireless devices or not, you do need to scan and make sure you don’t have any popping up. This SPSP report goes into detail on this subject.

My biggest concern was the mention that using Netstumbler or Kismet to discover rogue access points is sufficient. I agree, but only if you’re constantly analyzing the results, i.e. not just doing a walk-through every quarter, month, or week, but rather have a dedicated system always looking. Not some point-in-time crap.

Why? Because an idle SSID-hiding AP will still be invisible to Netstumbler and Kismet (even a chatty SSID-hiding AP will hide from Netstumbler!). You need to capture even the small window where a wireless AP is talking.

By the way, I’m hoping some answers to EthicalHacker.net’s latest challenge will not only answer the second question (How were the kids able to access Greg’s rogue access point even though it was not detected during Mr. Phillips PCI compliance assessment?), but also explain how to detect a rogue wireless device that isn’t talking at the moment. I wasn’t sure if that is possible short of brute-forcing an SSID response or trying to get the AP to talk from wired to wireless somehow…

As if the state of PCI wasn’t confusing enough, here is a piece from ComputerWorld that basically makes my head explode:

A Gartner Inc. analyst is urging companies that do business with Heartland Payment Systems Inc. and RBS WorldPay Inc. not to switch to other payment processors just because of Visa Inc.’s decision this month to remove Heartland and RBS WorldPay from its list of service providers that are compliant with the PCI data security rules.

and later this:

Visa requires all entities that accept credit and debit cards issued under its name to work only with service providers that comply with the PCI rules, which are formally known as the Payment Card Industry Data Security Standard (PCI DSS).

But in a research bulletin issued yesterday (download PDF), Gartner analyst Avivah Litan said that customers can continue to utilize Heartland and RBS WorldPay without facing any fines from Visa.

My first reaction is, “So why the hell does PCI (or the PCI certified listing) matter?” Yes, I understand companies and people make mistakes and honestly this may not be reason to jump ship from an entity, but this certainly questions the relevance of PCI listings.

Well, we’ll make an exception to our own rules saying you need to work only with service providers that are certified?

They’re going to be recertified so stick with it for a bit? Are you sure? And what if they lapse at “a point in time” again?

PCI was not at fault because while HPS was certified at a point in time, it did not maintain that certification at every point in time? (Wow, that could be the infinitely defensible weasel-out card!)

By the way, their delisting is just a point in time thing, just wait?

So, we have this PCI certified listing that PCI itself wants you to adhere to, but if someone drops off, don’t worry about it because they’ll recover. Is there *any* reason left to worry about someone not appearing on that list or being delisted? Which is worse?

And I like the irony (?) of another recommendation in the same Gartner report:

All parties that handle cardholder data: Focus on maintaining continuous cardholder data security, rather than on achieving PCI-compliant status.

No shit? But isn’t that the “do it yourself all the time” attitude what keeps/kept us in a mediocre state in the first place?! It obviously does not work broadly, so we need a kick in the junk by something with steel toes. But do we really need limp steel toes too?

BlackHat USA 2008 videos have been posted!

Note: Hrm, seems I forgot to hit the Publish button 3 hours ago…

FOR IMMEDIATE RELEASE

Terminal23.net is proud to announce their offering of cloud computing services to the general public. Terminal23.net will immediately begin offering blog, news, and commenting services to all customers through its stable and scalable cloud computing architecture. As a visitor to our service, the more you click around, the more our system recognizes this and provisions computing resources to serve your news needs. In addition, customers do not have to worry about the complexity of the underlying technology!
Terminal23.net is also proud to align itself with the Open Cloud Manifesto principles!

• We are dedicated to working with other cloud computing providers to offer address the challenges of adoption our service may have, and to support ongoing standards. We have started by using common blog software, and a common layout of post title, body, date, and even comment services!
• At no time will we lock our customers into using only our service. Feel free to read other blogs, too!
• We will work diligently to align ourselves with existing standards wherever possible.
• We will also be aware that needs for new standards will be met through collaboration rather than individual standard provisioning.
• We will be committed to working with the community, not to further our own technical needs, but rather in response to customer needs.
• We will…hell..these all sound the same anyway, so we just meet the last principle too!

Terminal23.net is excited for the future and our offering this new service to the public. This is a new chapter in our organization!

Dan Kaminsky released some information this morning that it is possible to remotely (and anonymously) detect if Conficker has owned a system. He does link to a POC scanner (python). This is the result of some work by Tillmann Werner and Felix Leder of the Honeynet Project. Looking forward to the paper!

Update: Here is more information about Conficker compiled by the handler’s at the SANS diary. I haven’t personally paid much attention to Conficker recently, mostly because we appear to be fully patched on known, managed systems where I work, so it has been a non-issue since Microsoft released them (MS08-067). That and it was pretty obvious the issue at hand was wormable and would be important.

I’m obviously catching up on some blogs on a rather nicely lazy Friday. Over at Teneble, they have a repost of Marcus Ranum’s recent keynote at SOURCE Boston, Anatomy of The Security Disaster. This is a long read, but exceedingly well worth it. I apologize for not looking too hard for a posted video.

So, what’s going on? We’ve finally managed to get security on the road-map for many major organizations, thanks to initiatives like PCI and some of the government IT audit standards. But is that true? Was it PCI that got security its current place at the table, or was it Heartland Data, ChoicePoint, TJX, and the Social Security Administration? This is a serious, and important, question because the answer tells us a lot about whether or not the effort is ultimately going to be successful. If we are fixing things only in response to failure, we can look forward to an unending litany of failures, whereas if we are improving things in advance of problems, we are building an infrastructure that is designed to last beyond our immediate needs.

A quick pointer to an excellent article by Gunnar Peterson talking about his “He Got Game” rule. In short, you gotta have game with coding if you want to tackle securing code. This runs parallel to my thinking that you have to know how to code before you can know how to secure your code. Adrian Lane adds an excellent comment as well, at least from what I pulled from it (something about it’s wording made me need to read it 5 times…)

I’ll state there are always exceptions, but I’d say those exceptions are not the norm at all. At least you can say if someone is technical in one area, they *could* have a small headstart in tackling another technical area. In the end, just like having a security mindset is a huge help for a security professional, having an aptitude and experience in coding is a huge help for a dev security pro.

I could simply be failing by generalizing way too much. 🙂

The difference in all of this to me is: TRAINING/PRACTICE. Whether it is self-prescribed or work-prescribed, training makes a difference.

As far as his book recommendation, I have no idea about it, but I’d be willing to give it a flip-thru to see if I could grasp it and benefit from it.

* The older I get and the farther away I get from the analog world, the more I wonder how the hell we used to write and add emphasis without markup tages or non-standard type (**, bold, italics, all-caps…) Then again, without computers, thinking about what job I would be working now leaves me blank too…