Linksys addressed many of my concerns with that previous device. The 610N can mount a drive and share it via SMB and FTP, have two full-speed connections running over both bands without skipping a beat, and supports several methods of getting the one-click WPS (Wi-Fi Protected Setup) to work. Read the review for all the details, but I can't recommend this router to Mac users with any needs beyond basic networking; I'm perfectly happy to give it a full thumbs-up for Windows XP and Vista users, however.

WPS is a particular mess, by the way. Linksys has four somewhat distinct methods of using WPS to enable a password-free encrypted connection between a client and a base station: a button on the front that, when pressed, turns on WPS; and three modes (one of them similar to that button) accessible via their Web configuration software. One option is to get the base station to create a short PIN that's then entered on the client system as an out-of-band confirmation that there's no man in the middle.

Apple, by contrast, has a single way of joining a WPS-offering base station: it displays the network's name in bold. Select the network, and Mac OS X displays a key code that needs to be entered on the base station. But the WRT610N can't handle that option. If you put the WRT610N into a mode in which Apple can spot the device as offering a WPS handshake, you can't enter the code into the Linksys router!

This shows that there's still rough edges in the WPS protocol that two of the highest-selling makers of Wi-Fi gear can manage to not mesh up their respective options. (Apple declined to comment for my Macworld story; Linksys confirmed the lack of compatibility, but put the burden on Apple's doorstep.)

As we get closer to the conference dates, I wish that I had made plans to fly back to the US to meet everyone.    However, I have been cutting back on public speaking, taking a break since May.  In addition, Gartner did not ask me to speak at their Event Processing Summit this year, I assume because they did not want to pay airfare for my flight from Thailand to the US.    Also, Gartner always likes to fill their conference speaking slots with as many Gartner speakers as they can, unless you are a paid sponsor; and I noticed a number of Gartner employees speaking in multiple slots.

(Editorial Note) Then again, maybe I complained to much about the lack of organization and conference problems when I was invited at be a Gartner keynote speaker last time - reservations not made propertly,  problems with the guest speaker registration list at sign-in, rooms shifted without notifying the speakers and panelists.   Admittedly, I was not happy with the conference organizers at the last get together.  This was my fault, as I am accustomed to better conference execution and am probally too “picky” about details these days - my bad.  Anyway, the Gartner organizers apologized numerous times, saying they had too many conferences going on at the same time and not enough people to cover them all.

One of the problems with spending so much time in Asia, especially in Thailand, is that guest speakers are really treated as VIPs.  There are usually special comfy couches set up for the speakers and the conference staff really treat you very nice, taking care of you every step of the way.   In fact, there is an entire very nice culture around how guest speakers are treated in Thailand.   Often, they pin flowers on the VIP speakers and take your photos like you are a star.    Very nice culture.

I absolutely look forward to speaking on event processing or CEP at a future venue and meeting everyone face-to-face instead of over the net.  My sincere and deepest apologies for not attending either the Gartner or the EPTS event this year.   

PS:  If you take up a collection and send me a RT business class air ticket, I might change my mind

"consumers hate tokens."

"Everyone wants to be the single federation platform for everyone else."

"Federation will never work. It won’t work because the single most important consumer Web applications in the world are scared of it. Banks hate the concept because it becomes a weakest link in the chain problem."

"Tokens don’t actually solve most security problems, like man-in-the-middle, phishing, and keystroke-logging malware."

"Oh yes, and finally, consumers are going to have to carry around 13 of them just to make sure they can log into whatever they need to log into since no one will federate."

"Global federation is nowhere near a solid concept in the consumer space, despite what the vendors will try to sell you."

"This is a long term problem. If you work on it and make any progress against it, you'll find yourself much smarter at the far end, than you were at the near end.

When I was in Norway about 5 years ago, I was there very close to the summer solstice. I was wandering around town at 2 o'clock in the morning and there was plenty of light out. You come to a sign that says New Minsk about 60 km and it points south.

And I ask the lady "what country is this?"

She scratched her head for a bit, and said "well I think its Norway"

I said "well who plows the roads?"

"well Norway does, but he have to pay them."

There is a triple boundary in this town that I was in between Norway, Finland and Russia.

But what I did there, was, I had a card about wallet size, I stuck it into a machine, I punched in four digits, and it gave me about 2,000 krone, whatever the hell that is.

Now there are a lot of participants in that transaction. When I put a card into that machine, punch in a pin, and it gurgles for awhile, and finally gives me, a fairly large amount of money. There are a lot of participants in that transaction. The bank that owned the machine that gave me the money, it gave some money away -- that bank wants it back. The pin is necessary to convince my own bank that I'm me. But I don't want my pin to be broadcast all over the world. My bank in the us, it hasn't really given out or taken in any money, really. But there is a lot of credits involved here. Somebody needs to charge somebody else for having more money available. Even though there was actually no cash transfer.

And the problem that I have in mind is
- who are all the participants in an ATM transaction?
- what do those participants need to satisfy their problems?
- how is that in fact done?

In a general way, does the atm system actually work in some reasonable sense? To which the answer is by the way: yes. The atm system damn well works. With extremely high reliability and accuracy. It surprises me. Its quite a bit different than voting machines.

1. DNS + Karma = Boom! Enuf said. Also, hear Pete Linstrom squeal.
2. Fun essay on "blocking" and risk. Is it our job to stop'em from using Facebook?
3. MS Exploitability Index. Smart ... or misguidedly focused on "vulnerability release" (and not creation)
4. Chip-n-PIN, a PCI killer? I don't think so!
5. Mike R revisits "good enough security" - read it, then review your IR plans (...for you will be 0wned)
6. Very fun RSA survey here; data leakage beats malware again, people still not report incidents (to whom???)
7. More and more and more people point at idiocies of academic security research... Read the whole w00t 08 thread here. Weep. Laugh.
8. Neosploit has a bad quarter... breaks support "contracts" ... shuts down? Ah, the economy :-)
9. Awesome stuff from  Richard Bejtlich: CAER.
10. "The Network Firewall is a Consensual Hallucination" :-)
11. More GRC-ball-kicking: here, here ("IT-GRC "vendors" are not IT-GRC vendors") - both are pretty insightful for GRC-lovers and GRC-haters)
12. More SIEM-ball-kicking: here ("underwhelming","ridiculous", "missing the point"), here ("dead ...unless","cripple")
13. Fun DLP portal launches.
14. Final word (?) on TerryChilds-gate here. "When management starts controlling the actions of admins, things start to fall apart." Huh? When management loses control of the business, it dies. Folks, IT vs IT security gap IS real. I never quite believed it, but this taught me a lesson. Some common security sense for a change (also here).

Enjoy.

We've probably all heard that you can't secure what you can't see and that statement is even more profound when it comes to virtual environments.  This is because it is extremely challenging to see what is going on at a micro vs. macro level within a virtual environments network.  The virtualization vendors such as VMWare and Citrix have provided embedded tools into their management consoles that show a macro level of visibility but its not enough to identify security events in the environment.  Take a look at the attached picture.  It simply shows VMWare's ability to monitor virtual network performance statistics from a bits per second perspective.

<-Click To Enlarge

With only this level of detail how can one determine which network applications are causing spikes.  Is it FTP traffic that is occuring at a high volume at an unuseal time of day?  If that were occuring, could that be indicative of either a breach or some sort of problem? What if FTP isn't even an authorized service in the virtual environment but there is a high volume of it?  Did someone install a rouge FTP service so they could steal information from the server at will?

These types of questions can't really be answered without a micro level of detail into the packets flowing in, out and within the virtual environment.  Now, what I am highlighting is not security in the traditional sense of prevention but using visibility as a means to first identify, then pin point the source of an issue so that it can properly be mitigated.  Having constant visibility can also ensure that other security products in the environment are performing as expected.  What if a Montego HyperSwitch with firewalling enabled is configured with many policies but someone forgot to create an FTP block policy.  One could think they are protected from rouge FTP services transmiting data out of the network, but without constant visibility monitoring, can you be certain?

Some vendors, namely Reflex Security will get you to believe that their IPS / IDS solution that is inline and running in the virtual environment is the right and only approach.  Or they will tell you to hang a virtual IDS off a span port in the virtual environment and you will at least have visibility into the attacks that are taking place.  Well, sure... You now have attack visibility but at the performance cost of your virtual environment.  Signature matching technologies are great, I'm a huge believer; however they don't scale very well in shared computing environments such as virtual ones.  IDS systems also don't typically track protocol and network service (FTP, HTTP, etc.) utilizations; which is another important part of visibility.

So, what do we do to gain visibility without the performance headache?  Well, for starters its probably best to put your IDS/IPS solutions in the physical environment where performance will be less of a concern.  In fact, you can span a virtual switch's traffic out to a physical NIC as easy as you can to a virtual one.  So why do it virtual and have to pay a 60% CPU utilization tax?  Another solution is to IDS inspect only the things you care about.  Why IDS inspect SSL traffic if you know your solution can't unencrypt SSL.  Its just a waste of compute cycles isnt it?  Policy based switching helps you with directing only the things you care about to an IDS (attack visualization product).  Montego's HyperSwitch also can help you with the traffic redirection of only the things you care about.

Another method of visibility which I tend to be a fan of is one of packet analysis (aka NetFlow).  NetFlow was invented by Cisco some time ago and has gained popularity in the physical world and definately has a use in the virtual world.  NetFlow is lightweight.  Let me say that again, its light weight!  It only sends a summation of packet detail to an analytical engine which can do some number crunching, packet comparison, etc. etc. to make some sense out of whats going on.  Lancope, an Atlanta based visibility company that provides Network Visibility, Security Visibility and User Visibility has this tool on their website that is a Netflow Bandwidth calculator.  You'll see from playing with this ( http://www.lancope.com/netflowcalculator.aspx ) calculator that it doesn't consume a lot of network bandwidth to transmit these network accounting records.  It also doesn't cause a lot of CPU overhead to send these records to an analytical engine sitting somewhere in the network.

Lancope's analytical engines have the ability to do the following for you within your virtual environment:

...and probably a slew of other things I'm not aware of.  A screen shot of their product is bellow:

<- Click to enlarge

You'll notice from the screenshot that you are able to visualize who is talking to who, how much traffic they have sent and received and something called a concern index (not seen on this screenshot).

Now, a concern index is a number that increases as Lancopes analytical engines monitor suspicious activity on a session.  A high counter can be indicative of a security problem.  Its another way of identifying (visualizing) compromised hosts (virtual machines) without having to do signature matching like a heavy weight IPS engine.  Example:  Lets say you have a VM that has a BOT on it and is "owned".  The Lancope product is monitoring this long life session.  Let's say that session is established for several hours or maybe even days or months.  Lets also say that the conversation appears to be mostly unidirectional from a public ip address not belonging to your enterprise.  Lancope would increase a the concern index on this since this server hasn't typically had this type of behavior.  Once the concern index reached a certain level it could then fire off an email, send you a text message or something saying:  Warning, Warning, Danger, Danger Will Robinson!!! You're virtual server may be infected with a BOT, please investigate immediately!!!

This example is VISIBILITY which helps you with SECURITY.  There are a number of other things you can do with NetFlow and Lancope products that have less to do with security and more to do with operational efficiencies.  Things like, helping you answer questions of:  How do I know what network applications are taking up the most bandwidth?  When should I move those applications over to a server with more horsepower?  When did these VM's vmotion over here and was there a traffic condition / CPU condition that caused that to occur?  I could go on and on but thats a topic for another blog entry.

So, my suggestion is to take a look at what NetFlow has to offer.  Montego Networks supports NetFlow transmission and Lancope supports NetFlow analytics and with both you can regain what was lost visibility.

I hope this was helpful to you all!

-John Peterson

We've probably all heard that you can't secure what you can't see and that statement is even more profound when it comes to virtual environments.  This is because it is extremely challenging to see what is going on at a micro vs. macro level within a virtual environments network.  The virtualization vendors such as VMWare and Citrix have provided embedded tools into their management consoles that show a macro level of visibility but its not enough to identify security events in the environment.  Take a look at the attached picture.  It simply shows VMWare's ability to monitor virtual network performance statistics from a bits per second perspective.

<-Click To Enlarge

With only this level of detail how can one determine which network applications are causing spikes.  Is it FTP traffic that is occuring at a high volume at an unuseal time of day?  If that were occuring, could that be indicative of either a breach or some sort of problem? What if FTP isn't even an authorized service in the virtual environment but there is a high volume of it?  Did someone install a rouge FTP service so they could steal information from the server at will?

These types of questions can't really be answered without a micro level of detail into the packets flowing in, out and within the virtual environment.  Now, what I am highlighting is not security in the traditional sense of prevention but using visibility as a means to first identify, then pin point the source of an issue so that it can properly be mitigated.  Having constant visibility can also ensure that other security products in the environment are performing as expected.  What if a Montego HyperSwitch with firewalling enabled is configured with many policies but someone forgot to create an FTP block policy.  One could think they are protected from rouge FTP services transmiting data out of the network, but without constant visibility monitoring, can you be certain?

Some vendors, namely Reflex Security will get you to believe that their IPS / IDS solution that is inline and running in the virtual environment is the right and only approach.  Or they will tell you to hang a virtual IDS off a span port in the virtual environment and you will at least have visibility into the attacks that are taking place.  Well, sure... You now have attack visibility but at the performance cost of your virtual environment.  Signature matching technologies are great, I'm a huge believer; however they don't scale very well in shared computing environments such as virtual ones.  IDS systems also don't typically track protocol and network service (FTP, HTTP, etc.) utilizations; which is another important part of visibility.

So, what do we do to gain visibility without the performance headache?  Well, for starters its probably best to put your IDS/IPS solutions in the physical environment where performance will be less of a concern.  In fact, you can span a virtual switch's traffic out to a physical NIC as easy as you can to a virtual one.  So why do it virtual and have to pay a 60% CPU utilization tax?  Another solution is to IDS inspect only the things you care about.  Why IDS inspect SSL traffic if you know your solution can't unencrypt SSL.  Its just a waste of compute cycles isnt it?  Policy based switching helps you with directing only the things you care about to an IDS (attack visualization product).  Montego's HyperSwitch also can help you with the traffic redirection of only the things you care about.

Another method of visibility which I tend to be a fan of is one of packet analysis (aka NetFlow).  NetFlow was invented by Cisco some time ago and has gained popularity in the physical world and definately has a use in the virtual world.  NetFlow is lightweight.  Let me say that again, its light weight!  It only sends a summation of packet detail to an analytical engine which can do some number crunching, packet comparison, etc. etc. to make some sense out of whats going on.  Lancope, an Atlanta based visibility company that provides Network Visibility, Security Visibility and User Visibility has this tool on their website that is a Netflow Bandwidth calculator.  You'll see from playing with this ( http://www.lancope.com/netflowcalculator.aspx ) calculator that it doesn't consume a lot of network bandwidth to transmit these network accounting records.  It also doesn't cause a lot of CPU overhead to send these records to an analytical engine sitting somewhere in the network.

Lancope's analytical engines have the ability to do the following for you within your virtual environment:

...and probably a slew of other things I'm not aware of.  A screen shot of their product is bellow:

<- Click to enlarge

You'll notice from the screenshot that you are able to visualize who is talking to who, how much traffic they have sent and received and something called a concern index (not seen on this screenshot).

Now, a concern index is a number that increases as Lancopes analytical engines monitor suspicious activity on a session.  A high counter can be indicative of a security problem.  Its another way of identifying (visualizing) compromised hosts (virtual machines) without having to do signature matching like a heavy weight IPS engine.  Example:  Lets say you have a VM that has a BOT on it and is "owned".  The Lancope product is monitoring this long life session.  Let's say that session is established for several hours or maybe even days or months.  Lets also say that the conversation appears to be mostly unidirectional from a public ip address not belonging to your enterprise.  Lancope would increase a the concern index on this since this server hasn't typically had this type of behavior.  Once the concern index reached a certain level it could then fire off an email, send you a text message or something saying:  Warning, Warning, Danger, Danger Will Robinson!!! You're virtual server may be infected with a BOT, please investigate immediately!!!

This example is VISIBILITY which helps you with SECURITY.  There are a number of other things you can do with NetFlow and Lancope products that have less to do with security and more to do with operational efficiencies.  Things like, helping you answer questions of:  How do I know what network applications are taking up the most bandwidth?  When should I move those applications over to a server with more horsepower?  When did these VM's vmotion over here and was there a traffic condition / CPU condition that caused that to occur?  I could go on and on but thats a topic for another blog entry.

So, my suggestion is to take a look at what NetFlow has to offer.  Montego Networks supports NetFlow transmission and Lancope supports NetFlow analytics and with both you can regain what was lost visibility.

I hope this was helpful to you all!

-John Peterson