Saw this fly past on Twitter, and I can’t remember who posted it. Anyway, an interesting article on “Why The New Guy Can’t Code.”

Getting straight to the point (of this article and others linked to from it): technical interviews tend to suck and hire only people who have accomplished something.

The NSA has published a nifty Best Practices for Keeping Your Home Network Safe fact sheet. This is a pretty good document which mixes easy-to-understand concepts with some more challenging ones. I really feel that people can get overwhelmed with the technical stuff, but usually do react favorably when given managable challenges.

I’d like to have seen more emphasis made on unique, complex passwords and the importance of passwords, but these are still excellent bullet points to cover with people. Entire books can’t cover the breadth of tips for good security these days, even for the layman….

This is a useful exercise to do with oneself every now* and then: If I had xx million dollars right now, jobwise, what would I do? A few things spring to my mind…

1. Let’s get this out of the way first: Nothing. Retire and travel around the world to beautiful places and experiences. Play video games. Do whatever. Nothing too crazy.

Goal: Relaxation.

Why not do it now? Duh, $$$

2. Open a store: combination arcade, video/PC gaming, tabletop gaming, culture.

Goal: Enjoyment!

Why not do it now? A store like this won’t yield crazy margins and probably won’t ever be profitable. But if I had the money to eat the losses, I can think of many, many, many other less interesting and fun ways to spend my life.

Ok, now let’s get back to the real world for a bit.

3. Security consulting business. Now, I’m not talking some generic consulting where you just regurgitate the latest NetworkWorld news blurb or Gartner reports on what products in the AV space to buy. I simply want to answer security questions and help someone improve their security. I’d want to have the ability to dive in deeper as well, such as evaluating weaknesses in an IDS/IPS deployment and configuration, making recommendations on staffing for technologies, code development processes, testing detection and response, what works and what doesn’t in identity management. Not just top-level non-actionable things, but actually fingers-in-the-shit sort of work. Basically one step away from being on staff/contractor, so that the things I can talk about are also things that can be lived with, and any questions I can’t answer (like how do I protect against XSS in this specific function?) I can spend the time to figure out the answer. I wouldn’t want to be the consultant who says, “Classify all your data,” and then walks away with a paycheck for dropping that load of shit on some CIO’s desk when there are many other actionable items that can be tackled first. Even small things like the PCI item to discover all CC info on the network, would be fun, without just saying, “Buy DLP.” Any down time would be spent as I do now: tinkering with whatever I want to dig my fingers into, and staying abreast of the community.

That’s a huge paragraph, and I’m probably being more detailed than I need to be. Essentially like 1 part security analyst, 1 part architect,, 1 part coder, 1 part auditor, 1 part pen-tester, 1 part manager, 1 part managed security service provider….

Goal: I love doing it (defense and offense), including the allowances for profits/convenience.
Why not do it now? Simply financial risk.

Why not do it now, part 2? I’m not much of a salesperson; I often understate my abilities rather than thinking I’m a qualified expert.

Why not do it now, part 3? Ok, fine, as Rothman excellently points out, I could almost do this now by taking on the consultant attitude. Other than not having a dedicated security role right now (general ops), I could be there.

4. Pentesting. I get that it’s not all fun and games and there’s tons of report-writing and analysis and screen-staring and delivering the same old report to hostile managers and fruitless scanning and frustration at squeezing 2 months of work into 72 hours on site. I get that. But I’d still love to be doing it.

Why not do it now? RE:An earlier point, I feel like I could use some “junior” time under a mentor/guidance.

Why not do it now, part dos? Honestly, I feel like I would suck for several years until I gained more experience and instinct, and I hate underdelivering. That would be a rough few years where financial security would be nice. But for someone who self-describes as having the logical/analystical/paranoid mindset that is nice for security, it’s really just a matter of getting experience under the belt.

Any number of roles also come to mind or even my own managed security services firm, though I still am not sure of their value, ultimately. Even doing some auditing, but I also feel like that will never be profitable because of the corners so many other firms cut in order to do more and quicker audits while keeping customers happy (i.e. as much good news as possible).

As far as company size, I don’t mind large companies all that much, or even just being a cog in a much bigger wheel, but I would love the family-and-friends feel of a smaller shop, where you can relax and be yourself in the office and not just have it be a stuffy 9-to-5 sort of environment. I’ve actually been in a start-up for a summer, and while it was ultimately a waste of time, I think, I did really enjoy the informality and get-it-done feeling. (The Penny-Arcade office atmosphere comes to mind…)

The ultimate goal that makes me happy, though, is helping someone better understand the security of their data, business, network, systems, and ultimately people.

* I actually just hit my 5-year anniversary at my current job. A bit of a milestone that causes me to sit back and think about where I am now and my next 5 years…

Preaching to the choir, but here is my illustration of how difficult PCI can be. Let’s look at requirement 10.5.1: Limit viewing of audit trails to those with a job-related need. Let’s also keep in mind the wording of 10.5.2: Protect audit trail files from unauthorized modifications. Essentially we’re talking about log management.

(If you’ve worked in logs before, you can probably guess where I’m going to go…)

Let’s say Bob uses LogRhythm as his choice of log management software, and he points his devices over to it. For simplicity, let’s just say he has a Windows Server OS box that is under scope for PCI. Since the LogRhythm agent sucks up these logs and throws them at the master server, Bob submits only a screenshot of the user account list inside LogRhythm. Bob reasons that only these peope can see the logs in the SEIM.

Done! Right?

Well, wait a minute. The point of these PCI items is twofold. First, make sure unauthorized people can’t view the logs, only those who need to see them can view the logs (an important distinction, sadly), either because they may give details away or aid an attacker in seeing what errors she generates. Second, make sure the attacker doesn’t have a chance to modify those logs, or flat out destroy them.

As some vendors in this space will tell you, there are gaps here! The gap between when Windows gets the event and when it saves it to the event log. The gap between when the event is written to a local log and when LogRhythm’s agent grabs it up (including when an attacker has been able to turn off the collector agent). Moving forward, what about the backup location of log files? The agent-to-master communication? (Better yet, let’s talk syslog in terms of confidentiality and integrity!)

Another way to look at it is just to evalute our audit logs in a way that unauthorized people can’t just stumble upon them and/or edit them. If an attacker subverted a system and can intercept logs before they’re gathered, that just might be an advanced case. If an attacker popped Local System on his Windows/IIS box, should he still be able to protect those logs completely? I think that’s arguable. Likewise, someone may argue that more open logs like the Windows System and Application logs aren’t in scope of this, and only the Security log is, which is more locked down by default in Windows. Perhaps… In cases like this, you at least have logs up to when the attacker gained enough rights to start hiding her tracks.

I’m not going to diss on “just enough security” since I think that’s what we often preach anyway when we talk risk. I just wanted to illustrate that even slam dunk PCI items, when really analyzed deeply, are not always so easy to rush through.

Update: Also check out 11.5: Deploy file-integrity monitoring tools to alert personnel to unauthorized modification of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly. This begs the obvious question, “What files should I monitor?” It’s not an easy question and more orgs/people will opt not to tell you unless you’re paying them money to do so. So, do you purchase and deploy a FIM tool with defaults? What executables and dlls and files do you monitor? Unless you do the bare minimum of following vendor defaults, this won’t ever be something you just do and forget forever…and that’s not even having to deal with patch-related false positives or a misguided desire to log *everything* just because you want to, and then suffer through many false positives…

Picked up via @MikkoHypponen that some liveblogging was happening during a Sony press conference. I still won’t complain about their response to all of this, but…

No CSO level position? Weak. You’re how big with how much IP and data and how big if your digital footprint?

Known vulnerability but wasn’t known to you? What does that even mean? You think management is going to understand such vulnerabilities? Anyway, this means to me that either patching was broken or this was a reported hole in their systems that wasn’t addressed properly.

Rebuild/move data center with better security? Sounds almost like they just outsource their operations…that or moving your physical location isn’t going to help against a digital attack.

In case you missed it, the recent Playstation Network outage has been finally acknowledged in a Sony release. If you were thinking it was a DoS, you’re wrong. It was complete pwnage [emphasis mine]:

…we believe that an unauthorized person has obtained the following information that you provided: name, address (city, state, zip), country, email address, birthdate, PlayStation Network/Qriocity password and login, and handle/PSN online ID. It is also possible that your profile data, including purchase history and billing address (city, state, zip), and your PlayStation Network/Qriocity password security answers may have been obtained. If you have authorized a sub-account for your dependent, the same data with respect to your dependent may have been obtained. While there is no evidence at this time that credit card data was taken, we cannot rule out the possibility.

In short, this is a big deal. Maybe not ultimately to Sony/PSN, but it is a big deal for the industry. And these are the hard questions:

1. How did this one breach disclose so much? Was it one issue or several that were leveraged? (As a learning opportunity, which is better, a single issue that caused your (gigs of) data to be exfiltrated or a series of leveraged weaknesses?)

2. No password hashing? Encrypting? Credit card information segregated/tokenized/hashed/encrypted? If it was, was the key management that poor? I hate to be the one to say it, but let’s hear that PCI compliance status… (without the PCI marketing spin)

3. What was Sony’s security budget? Or any budget around technology and the protection thereof.

4. If Sony’s deep pockets and ability to have a deep budget didn’t help, is this further illustration of security futility? If nothing else, it’s illustration of the view of digital security in profitable enterprises…

5. What if Sony *has* done risk analysis and determined to accept whatever risk was present? (Even the act of not doing anything is an unspoken acceptance of risk, in my book.) This is my biggest problem with risk and probability: You’re still susceptible to that one-in-a-100-years-hurricane scenario; and heads will roll. It’s also my biggest problem with security and the media: We, in security, believe that you *will* fail, and the media will always sensationalize everything it can. This will always shake out against us; even when we do things absolutely correct (and what organization lets us even come close to doing things absolutely correct?).

6. Do you blame the attacker or do you blame Sony?

7. What was the time-to-breach after they leveled their attacks against you? I’m hoping it wasn’t hours, days, or even weeks… I’m also hoping their breach-to-detection time is small.

One thing I won’t harp on is how long or quick it took Sony to announce something to its customers. A 6-day period during which it took the network down to analyze the extent is not entirely something I can get upset about. And you certainly don’t want to tell 70 million customers something until you know it for sure; not just because of a loss of customers, but simply because if you’re wrong, you’ve just done fucked up even worse. This is an announcement you take the time to get right; and 6ish days is not unreasonable. Does this mean an attacker may have had free reign on credit card information (etc) for 6+(time of breach-to-detection) days? Yes, but when is that *not* the case?

Not a big deal, but thought I’d mark the occasion where I now own the terminal23.com version of this site to go with the .net and .org. Ever since I wanted to name my site this, some group has held the .com version (along with many other terminal##.com sites), but it has since been relinquished.

Not that I’m going to actually *use* that domain, but it’s a nice full circle sort of thing to have it under my control.

CAs have a nice scam going on with constant cert renewals, but registrars have it even better with all the damn top-level domains, let me tell ya…