So here’s another track that was being played in the CTF room at DEFCON.

I frickin’ love techno. Add technology and it magnifies its coolness 1000 fold.

This vérité action series follows Tiger Team – a group of elite professionals hired to infiltrate major business and corporate interests with the objective of exposing weaknesses in the world’s most sophisticated security systems, defeating criminals at their own game.

Tiger Team is comprised of Security Audit Specialists Chris Nickerson, Luke McOmie and Ryan Jones who employ a variety of covert techniques – electronic, psychological and tactical – as they take on a new assignment in each episode.

The show will air on CourtTV Tuesday, December 25 at 11 and 11:30pm E/P. Here’s a sample:

Penetration testing falls into three basic categories based on the posture of the organization you’re up against. Reality obviously has shades, but here are the main groupings I always seem to run across during internal assessments.

1. Trivial Joke
2. Standard Mess
3. Seriously Stout

And here are some of the primary metrics:

• Asset Management:
  • Do they know what all their systems are?
  • Is that information kept up to date?
  • Would they know if a new system came onto the network?
• Patching:
  • Do they have an automated patching system?
  • Are patches verified, or are they just assuming they were applied?
  • Do they patch everything, or just the stuff that’s not too “scary” to touch?
• Visibility
  • Do they run their own regular vulnerability scans?
  • Do they have their own IDS and/or IPS systems?
  • Do they have logging and auditing enabled?
  • Are they actually REVIEWING this information?
  • Any solution for real-time alerting/monitoring?
• Hardening
  • Are there standards that are followed for hardened system deployments?
  • Is the environment scanned for superfluous services?
  • Do they follow a least-privilege philosophy, or are they in “just make it work” mode?

The more of these questions that result in blank stares the easier it is to get domain admin and harvest critical data. If the answer is no to more than a few of these questions the group is going to fall into either category 2 or 1. Only people doing all of that stuff (and lots more) end up with decently tight networks/systems (3).

Reality

It’s easy to get excited when exploiting systems, pulling hashes, cracking them, getting domain access, etc., but it’s a false high. What are we doing really? In the cases of 1 and 2 the enemy is either in a coma or not even there. How is that a battle? It’s nothing but knowing how to find the droppings of apathy and underfunding, and then knowing what to do with them.

I totally hacked them…

No, you didn’t. The vast majority of penetration testers out there are successful not because they’re exceptional, but because their targets are open wounds. Attacking these networks is like pushing over little kids. Congratulations on that.

Real penetration testing doesn’t start until two things are true:

1. The network/system you are attacking is administered by a serious, properly-resourced security team.
2. There are no known, serious vulnerabilities.

If you start with a brick wall and have to invent new ways of getting in — that’s impressive. Until then you’re simply a monkey with a bag of tricks. Maybe you are a smarter monkey who can do more with less, or maybe you’ve created a few of your own tricks, but you’re still just a monkey.

I know because I am one.:

Ah, hacking the Gibson and listening to pre-reign-in-blood Slayer. Life is good. As a friend put it: “the simple pleasures.” I’d forgotten how fun this is — even though it’s not very hard.:

The Bar Code deciphered, by Scott Blake.

So I’ve been at DEFCON in Vegas for the last few days. It’s been a rich experience and I’ve made a couple of observations.

DEFCON is a Social Networking Event DEFCON makes all of the audio and video content available (for a price) afterwards, meaning you can watch all of the presentations as if you were there anyway. What you can’t do is mill about and catching up with your with your friends and colleagues from all over the country (or make new friends and colleagues). That’s invaluable, and it should be the main reason for attending these types of events.

You Can Tell a Lot About a Person by the Shirt They Wear Most people wear regular shirts — polos, t-shirts, etc. — that have no writing on them. Those don’t count. What I’m speaking of is those who are trying to make a statement by calling attention to themselves with text or images on their shirts. Among those you can tell who is most skilled by the shirt they choose. Simple rule: if the shirt they choose represents an old meme that died a long time ago, they’re most likely followers with very little creative power. If the shirt they’re wearing is something really obscure, they’re likely leaders.

Examples: There were many guys walking around with the binary shirt — the one that starts with “There are only 10 kinds of people in this world, those who understand binary and those who don’t.” This was a cool shirt. In fact it still is a cool shirt. But the only reason to wear writing on a shirt at a con is to have others read it. In other words you’re calling attention to yourself on purpose. And in the case of a hacker convention, the goal is to impress.

If your method of impressing a convention full of hackers is to support a joke that was old a few years ago, you’re not a thought leader. These people are likely to be followers who simply mimic others and do very little on their own. Not because they wear a shirt with an old joke on it, which is fine in other settings, but because they thought it would impress the DEFCON crowd three years later.

Now, contrast that to people like Dan Kaminsky and H.D. Moore. They both wore shirts that had cryptic icons or text on them. Unknown icons or text. In fact, there are likely to be very few people at the whole con who knew what those shirts meant — and that’s the way they like it. They’re trying to make a statement just like the guys with the binary shirt, but the difference is that they are actually succeeding by wearing something obscure and interesting. You would never catch any of these thought-leaders promoting a tired meme at a con.

<

p align=”center”>In other words, the elite group create and promote new memes, while the followers are attracted to the well-established and therefore stale ones.

It’s like in the writing world. Good writers find new ways to say things while poor writers use cliches. The thing is, cliches are still good writing. The only reason they are bad choices is because they’ve been overused — just like the binary shirt meme.:

I’ve alluded to a major project a few times in recent months. Well, I’m now ready to talk about what it is. I apologize for the disjoined presentation; I’m a bit excited and will clean up as needed later.

Background

One of the most annoying problems that faces computer users is contact management. Most don’t have a truly organized digital address book, and even those that do suffer from contact-rot. This is where each passing day means one more mailing address has changed, someone got a new mobile number, and another person got married and has a new last name. In other words, time deteriorates the quality of your information about other people.

Many services have come and gone that tried (or are trying) to solve this problem. Most notable of these is Plaxo. Plaxo, as well as most of the other services like it, have essentially been services where you kept your updated information. The idea being that when you changed your info, Plaxo could notify the people in your address book that you had done so. At that point they could take some steps to update their information. The problem is that it’s required too much involvement with the third party service. Plaxo is, after all, a for-profit company, so it makes sense that they would want you to interact with them.

Identity Management + Semantic Web

My idea is simple: provide a free and open infrastructure upon which people can build identity-based services ranging from contact management to social interaction functionality. Focus on transparency and open standards, meaning that the exchange of informaton should be as simple as possible and should allow for infinite potential for securely sharing and manipulating the data.

Here are the two primary components:

1. Central, Server-Side Representation of People using XML I’m currently working on RDF for the main definition.
2. Open, RSS-based Client The client piece, while completely open to various implementations, will have two components. 1) Subscriptions to contacts via RSS, and 2) translation of the server’s XML to their own address book format.

Functionality

• Maintain constantly updated contact information by subscribing to your friends’ information on a central server. You stay updated because your information is not static. The information you see when you open your address book is what was last pulled from your contact’s RSS feed.
• Your contact list is constantly maintained in a neatly defined, XML-based format on the server (OPML?). To get your contacts onto any new system (including mobile devices), install any client (there will be many) that speaks both the server-side XML protocol and the local address book format.
• Link the elements within a given definition to other namespaces that carry weight within the semantic world. In other words, allow favorite bands, favorite foods, and a multitude of other attributes to be defined in such a way that associated information can be referenced (and mashed) semantically.

The Architecture

The server resides at kitmee.com (currently living in a VMware machine in San Fransisco that’s powered off) and hosts the various identity files (RDF, etc.). As an example, we’ll say we have two accounts — myself (Daniel Miessler), and my friend (Seth Kline).

We respectively live at kitmee.com/dmiessler and kitmee.com/skline. Within whatever client we’re using for the system (again, this will be any one of many available) I’ll subscribe to Seth’s address within my client that’s installed on my local system. The client works by maintaining two types of information: who you are, and who your subscriptions are (your contacts).

More On Client Functionality

The most basic client monitors the local address book for changes to my own contact information, and upon sensing changes translates the changed result into the server’s XML format and uploads it. This updates my information on the server and updates the associated RSS feed that represents me as a person.

Since people who have me in their “contact list” are actually just subscribed to my RSS feed, their respective clients (web clients, desktop clients, mobile clients) will be notified the next time they check in that I have updated my information. Their client will then update my information in their contact list (server-side) and make the associated change to the local address book on the system they are using (mobile phone, work computer, etc.).

So what we end up with is an infrastructure in which I can update my information using my own local address book, and that information will transparently be propogated (via RSS pull) to anyone who is subscribed to me using the system.

Once I have a client installed it disappears into the background. From that point on I interact only with my regular contact management application, and changes I make are propogated to my subscribers, and their changes are propogated to me.

The end result is that when I open my address book entry for Seth two years from now and dial his mobile number, I could very well be dialing a number that I never entered. He’ll still answer the phone on the other end, however, because at some point he updated HIS local address book, which updated the server, which updated MY local address book.

No extra steps. No extra hassle.

Considerations

Security is handled on the server by managing who can and cannot access your information. Obviously we don’t want just anyone to be able to pull your entire personal definition (essentially what’s now a vcard) by simply visiting a given URI. I also intend for the various elements/fields in the definition to be granularly controllable, e.g. work associates can see only your home number, while friends can see everything, etc.

Clients are the key; without them we don’t have the transparency that’s required to make the infrastructure useful. Specifically, we need the client to be able to translate between the server’s XML format and the local address book format. In later client iterations, however, I anticipate moving towards address book integration, i.e. being able to add kitmee subscriptions right into the native address book.

Final Thoughts

So that’s the project. I’m currently working with one other developer on the server side, and have not even started considering the client piece. Our development environment currently consists of a fairly stout Gentoo Linux server running in VMware. The application platform is RoR, and we’re using Subversion for version control.

I am very much interested in any feedback you may have. And if you’re interested in contributing — either via conceptual input or actual development effort — I’d love to hear from you. I will be following the comments in this thread and am also available via email.

We of the tech-culture elite tend to obsess about efficiency. Those with the worst form of the disease can experience genuine anxiety when a task isn’t performed in the most efficient way possible. Unfortunately, this obsession can lead to a deep feeling of dissatisfaction. Sharpening tools can only only grant so much happiness; eventually you’ll have to build something.

The problem is one of perspective. We’ve lost sight of the actual purpose of efficiency. That purpose is to make things — to improve things — to create.

That output can be most anything — writing, programming, teaching — whatever it is that benefits from your internal improvements. The key is that you have to do something with that knowledge.

Seeking Balance

A single balance should be kept in mind here: optimization vs. creation. We should spend x amount of time improving ourselves, and then spend y amount of time actually making something. What that ratio is for each of us will obviously vary, but we can never forget how important that second step actually is.

Those who do forget this are stuck in perpetual optimization mode, and they feel lost. They read hundreds of books on how to write, but never get started on their own stuff. They watch a million cooking shows and never make any food. Remember that the point of efficiency and self-improvement is to raise the quality of your output — which requires that you actually create output.

They key to breaking the obsession and becoming more happy is to stop practicing for some big project in the future. Just find a project and dive in.:

Last Friday I went to my first 2600 meeting. It was, of course, here in New York City — home of the original meetings. The group started small and grew to around 40, which the regulars said was a weak showing.

We pushed through the awkwardness (which wasn’t helped by our being dressed in business attire) and were able to mingle pretty easily. I got to speak with one guy who was something of a regular/leader on a range of topics, most noteworthy of which was a brief discussion of assassins-mace weapons.

The main conversation I had was with a very cool guy who does graphic design and has a background in programming. We discussed all kinds of stuff, including how we both hated those who write HTML but don’t take the time to learn how to do so correctly.

Meetings end in the final group going downtown for dinner, which we did. There it was a bit more difficult to blend in because the group was just a bunch of friends. It was pretty clear to me that they were going to raz us when we left because of how we dressed, but I think they might have a few good things to say as well.

Overall it was a really good experience. I intend to go back for the December meeting.