The convergence of voice and video traffic are quickly transforming the growing complexity of networks at a torrid pace. IDC estimates that the skills gap in VOIP should grow to 19% by 2011.

This changing profile in the role of the network plays a key role in the skills shortage. Network enabled collaboration tools such as social networking apps and the Webex conferencing/collaboration solutions we use in our business each and every day are demanding a new set of IT skills to deliver business value.

My perspective is two-fold on this issue; the first is what I have seen in the resources we have attempted to hire! We give a very straightforward quick written/oral test to all new technical hires. This requires basic networking knowledge and some Unix commands. On average, (after filters from reputable recruiting firms, some with 5-10 years experience) less than 10% pass muster for the first filter we use in our hiring process. This is a troubling fact, which has cost us considerable time and effort to secure the right resources with competent skills. So I can say from our market assessment in a very strong technological job skills market, core Unix and networking foundation skills are slipping.

The second is that we as an IT Operations Management (ITOM) industry need to keep pushing hard to build better proactive and intuitive solutions to aggregate instrumentation from all Data Center tools, including more work around VOIP, video streaming, and collaboration so that we can ease this transition. If ITOM solutions become more proactive across the typical Cisco infrastructure that is commonly installed in the Data Center, we can free up some additional time for advanced “emerging technologies” training where existing IT workers can enhance their core skills and re-invigorate their careers. We have to do a much better job of getting our existing IT professionals trained on emerging technologies!

While there’s less that ScienceLogic can do around training, we certainly strive to do our part to enhance a day in the life of the networking engineers who use our solutions to simplify monitoring of increasingly complex networking, Wireless, VOIP, and collaboration needs.

Here's the story. Every Oyster card has a radio-frequency identification chip that communicates with readers mounted on the ticket barrier. That chip, the "Mifare Classic" chip, is used in hundreds of other transport systems as well — Boston, Los Angeles, Brisbane, Oslo, Amsterdam, Taipei, Shanghai, Rio de Janeiro — and as an access pass in thousands of companies, schools, hospitals, and government buildings around Britain and the rest of the world.

The security of Mifare Classic is terrible. This is not an exaggeration; it's kindergarten cryptography. Anyone with any security experience would be embarrassed to put his name to the design. NXP attempted to deal with this embarrassment by keeping the design secret.

The group that broke Mifare Classic is from Radboud University Nijmegen in the Netherlands. They demonstrated the attack by riding the Underground for free, and by breaking into a building. Their two papers (one is already online) will be published at two conferences this autumn.

The second paper is the one that NXP sued over. They called disclosure of the attack "irresponsible," warned that it will cause "immense damages," and claimed that it "will jeopardize the security of assets protected with systems incorporating the Mifare IC." The Dutch court would have none of it: "Damage to NXP is not the result of the publication of the article but of the production and sale of a chip that appears to have shortcomings."

Exactly right. More generally, the notion that secrecy supports security is inherently flawed. Whenever you see an organization claiming that design secrecy is necessary for security — in ID cards, in voting machines, in airport security — it invariably means that its security is lousy and it has no choice but to hide it. Any competent cryptographer would have designed Mifare's security with an open and public design.

Secrecy is fragile. Mifare's security was based on the belief that no one would discover how it worked; that's why NXP had to muzzle the Dutch researchers. But that's just wrong. Reverse-engineering isn't hard. Other researchers had already exposed Mifare's lousy security. A Chinese company even sells a compatible chip. Is there any doubt that the bad guys already know about this, or will soon enough?

Publication of this attack might be expensive for NXP and its customers, but it's good for security overall. Companies will only design security as good as their customers know to ask for. NXP's security was so bad because customers didn't know how to evaluate security: either they don't know what questions to ask, or didn't know enough to distrust the marketing answers they were given. This court ruling encourages companies to build security properly rather than relying on shoddy design and secrecy, and discourages them from promising security based on their ability to threaten researchers.

It's unclear how this break will affect Transport for London. Cloning takes only a few seconds, and the thief only has to brush up against someone carrying a legitimate Oyster card. But it requires an RFID reader and a small piece of software which, while feasible for a techie, are too complicated for the average fare dodger. The police are likely to quickly arrest anyone who tries to sell cloned cards on any scale. TfL promises to turn off any cloned cards within 24 hours, but that will hurt the innocent victim who had his card cloned more than the thief.

The vulnerability is far more serious to the companies that use Mifare Classic as an access pass. It would be very interesting to know how NXP presented the system's security to them.

And while these attacks only pertain to the Mifare Classic chip, it makes me suspicious of the entire product line. NXP sells a more secure chip and has another on the way, but given the number of basic cryptography mistakes NXP made with Mifare Classic, one has to wonder whether the "more secure" versions will be sufficiently so.

This essay originally appeared in the Guardian.

I have this semi-random digital scribbling thingie called a blog.  You might have heard of them.  Hey, you might have even at one point heard of mine.  =)

On my blog I let it be known that I am what the rest of the world would call a “NIST Cheerleader”.  I watch your every move.  I comment on your new publications.  I teach your framework every quarter.  From time to time, I criticize, but only because I have a foot in the theory of information security that you live and a foot in the implementation with agencies who know where the theory and models break.

The best thing that you have given us is not the risk management framework, it was SP 800-30, “Risk Management Guide for Information Systems”.  It’s small, to-the-point, and scalable from a single server to an entire IT enterprise.  Sure, the quants hate it, but for the quals and Government, it’s good enough.  I know private-sector organizations that use it.  One of my friends and blog readers/commenters was the guy who taught a group of people how to do risk assessment, then these same people went on to help you write the book.

I heard that you were in the process of revising SP 800-30.  While this is much needed to catch up/modernize, I want to make sure that 800-30 does not follow the “live by the catalog, die by the catalog” path that we seem to be following lately.  In other words, please don’t change risk assessment process to the following:

1. Determine boundary
2. Determine criticality
3. Conduct a gap assessment against a catalog of controls (SP 800-53/800-53A)
4. Attach a priority to mitigation
5. Perform risk avoidance because compliance models are yes/no frameworks
6. Document
7. ???
8. Profit!

At Your Own Risk Photo by  Mykl Roventine.

The reason that I am writing this is to let you know that I have noticed a disturbing trend in how now that we have a catalog of controls, the risk management framework is focusing more and more heavily on the catalog as the vehicle for determine an adequate level of security.  Some of this is good, some of this is not.

Why am I so concerned about this?  Well, inside the Government we have 2 conflicting ideas on information security:  compliance v/s risk management.  While we are fairly decent Government-wide at compliance management, the problem that we have is in risk management because risk management is only as good as the people who perform the risk assessment.  Not that we don’t have competent people, but the unknowns are what will make or break your security program, and the only way that you can known the unknowns is to get multiple assessments aimed at risks outside of the control catalog.

However, if you change the risk assessment process to a “catalog of controls gap analysis” process, then we’ve completely lost risk management in favor of compliance management.  To me, this is a disturbing trend that needs to be stopped.

Thank you for your time

–Rybolov

Bookmark to:

Vulnerabilities are software mistakes--mistakes in specification and design, but mostly mistakes in programming. Any large software package will have thousands of mistakes. These vulnerabilities lie dormant in our software systems, waiting to be discovered. Once discovered, they can be used to attack systems. This is the point of security patching: eliminating known vulnerabilities. But many systems don't get patched, so the Internet is filled with known, exploitable vulnerabilities.

New vulnerabilities are hot commodities. A hacker who discovers one can sell it on the black market, blackmail the vendor with disclosure, or simply publish it without regard to the consequences. Even if he does none of these, the mere fact the vulnerability is known by someone increases the risk to every user of that software. Given that, is it ethical to research new vulnerabilities?

Unequivocally, yes. Despite the risks, vulnerability research is enormously valuable. Security is a mindset, and looking for vulnerabilities nurtures that mindset. Deny practitioners this vital learning tool, and security suffers accordingly.

Security engineers see the world differently than other engineers. Instead of focusing on how systems work, they focus on how systems fail, how they can be made to fail, and how to prevent--or protect against--those failures. Most software vulnerabilities don't ever appear in normal operations, only when an attacker deliberately exploits them. So security engineers need to think like attackers.

People without the mindset sometimes think they can design security products, but they can't. And you see the results all over society--in snake-oil cryptography, software, Internet protocols, voting machines, and fare card and other payment systems. Many of these systems had someone in charge of "security" on their teams, but it wasn't someone who thought like an attacker.

This mindset is difficult to teach, and may be something you're born with or not. But in order to train people possessing the mindset, they need to search for and find security vulnerabilities--again and again and again. And this is true regardless of the domain. Good cryptographers discover vulnerabilities in others' algorithms and protocols. Good software security experts find vulnerabilities in others' code. Good airport security designers figure out new ways to subvert airport security. And so on.

This is so important that when someone shows me a security design by someone I don't know, my first question is, "What has the designer broken?" Anyone can design a security system that he cannot break. So when someone announces, "Here's my security system, and I can't break it," your first reaction should be, "Who are you?" If he's someone who has broken dozens of similar systems, his system is worth looking at. If he's never broken anything, the chance is zero that it will be any good.

Vulnerability research is vital because it trains our next generation of computer security experts. Yes, newly discovered vulnerabilities in software and airports put us at risk, but they also give us more realistic information about how good the security actually is. And yes, there are more and less responsible--and more and less legal--ways to handle a new vulnerability. But the bad guys are constantly searching for new vulnerabilities, and if we have any hope of securing our systems, we need the good guys to be at least as competent. To me, the question isn't whether it's ethical to do vulnerability research. If someone has the skill to analyze and provide better insights into the problem, the question is whether it is ethical for him not to do vulnerability research.

This was originally published in InfoSecurity Magazine, as part of a point-counterpoint with Marcus Ranum. You can read Marcus's half here.

Simon Crosby, CTO of Citrix/XenSource made a pretty bold statement yesterday that has some people agreeing with his position and others disagreeing.  In an interview with searchsecurity.com he publicy stated that virtualization vendors are not competent to try and secure virtual environments and therefore looks to 3rd party security companies to solve these concerns. 

Listen to the podcast here

Who are these 3rd party security companies?  Well, there are a number of startup companies such as Montego Networks, Blue Lane, Catbird, Altor Networks as well as some of the big guys that are working on helping the virtualization vendors with these security concerns.

I tend to agree with Simon that the virtualization vendors don't currently have the expertise to deliver appropriate security controls for virtual environments BUT should they?

Well, Chris Hoff who blogs on the topic of virtualization security a lot seems to think that they should deliver security tools and and by not delivering solutions to secure the environment they are doing their customers a disservice.

"Further, I don't expect that the hypervisor should be the place in which all security functionality is delivered, but simply transferring the lack of design and architecture forethought from the hypervisor provider to the consumer by expecting someone else to clean up the mess is just, well, typical."  Said Chris Hoff in his blog on this topic

I've spoken with a number of research analysts, venture capitalists and customers on this topic over the last several months and whenever I tell them what Montego Networks is off building they ALL seem to ask the same questions.  One of those questions is:  Why isn't VMWare or Citrix/Xensource doing this?  My response has always been that "they have publicly stated they do not want to and plan on leveraging an eco-system of security vendors to provide this". 

Well, Simon's public statement is right in line with what I've been saying all along.  The other question I get when I describe how Montego has security built into a virtual switch we've created is; shouldn't this technology be in the VMWare Virtual Switch?  And my response is "absolutely!  But it isn't!  so, someones got to do it."

So, I agree with Chris Hoff and I also agree with Simon Crosby.  The virtualization vendors don't have the expertise BUT I feel they should provide SOME security tools to ensure the environment is safe. 

There are some virtualization vendors that I have spoken with that are planning on using security as a differentiator and its my prediction that one of them will acquire security technology to do this.   Its often easier to acquire vs. try and built it yourself given you don't currently have the expertise.

So who's problem is it to solve??  Virtualization Vendors or Security Vendors??

I see the finger pointing game starting!

-John Peterson

CTO / Montego Networks

Simon Crosby, CTO of Citrix/XenSource made a pretty bold statement yesterday that has some people agreeing with his position and others disagreeing.  In an interview with searchsecurity.com he publicy stated that virtualization vendors are not competent to try and secure virtual environments and therefore looks to 3rd party security companies to solve these concerns. 

Listen to the podcast here

Who are these 3rd party security companies?  Well, there are a number of startup companies such as Montego Networks, Blue Lane, Catbird, Altor Networks as well as some of the big guys that are working on helping the virtualization vendors with these security concerns.

I tend to agree with Simon that the virtualization vendors don't currently have the expertise to deliver appropriate security controls for virtual environments BUT should they?

Well, Chris Hoff who blogs on the topic of virtualization security a lot seems to think that they should deliver security tools and and by not delivering solutions to secure the environment they are doing their customers a disservice.

"Further, I don't expect that the hypervisor should be the place in which all security functionality is delivered, but simply transferring the lack of design and architecture forethought from the hypervisor provider to the consumer by expecting someone else to clean up the mess is just, well, typical."  Said Chris Hoff in his blog on this topic

I've spoken with a number of research analysts, venture capitalists and customers on this topic over the last several months and whenever I tell them what Montego Networks is off building they ALL seem to ask the same questions.  One of those questions is:  Why isn't VMWare or Citrix/Xensource doing this?  My response has always been that "they have publicly stated they do not want to and plan on leveraging an eco-system of security vendors to provide this". 

Well, Simon's public statement is right in line with what I've been saying all along.  The other question I get when I describe how Montego has security built into a virtual switch we've created is; shouldn't this technology be in the VMWare Virtual Switch?  And my response is "absolutely!  But it isn't!  so, someones got to do it."

So, I agree with Chris Hoff and I also agree with Simon Crosby.  The virtualization vendors don't have the expertise BUT I feel they should provide SOME security tools to ensure the environment is safe. 

There are some virtualization vendors that I have spoken with that are planning on using security as a differentiator and its my prediction that one of them will acquire security technology to do this.   Its often easier to acquire vs. try and built it yourself given you don't currently have the expertise.

So who's problem is it to solve??  Virtualization Vendors or Security Vendors??

I see the finger pointing game starting!

-John Peterson

CTO / Montego Networks

A huge chunk of why I started this site was for my own testing. I wanted to learn on a site that I controlled completely. That works great if you’re a guy like me, who’s already been in the web space for well over a decade. But for people who are either new, or are shifting their interests from some other area of security, the web space is highly complex and deep. So herein lies the second reason I started this site. I wanted a place where I could teach people what I know. Call it altruism, call it wanting a sanity check on my own thoughts, but here we are, 2 years and 20,000 visitors a day later and things have changed.

I’m ultimately troubled by the fact that there are so many people out there who are in every way smart but are only in web application security because they have fallen into it, for whatever reason, and now are trying to play catch up with guys like us. I feel like there is a huge gap of knowledge out there, and I feel like there is a lot that I could share with people given enough time. A one hour speech isn’t enough time. It’s barely enough time to gloss over a topic, let alone go down to any level of detail that would allow someone to think they are proficient in a topic. I really feel like I could share a lot more of what I know to a willing participant if we made it a week long course. So that’s what I did.

I’m going to be offering a week long course that I am dubbing The Austin Project. The goal of the project is to get a group of likeminded people who are interested in talking about and learning more about web application security from yours truly. Honestly, I just feel like there’s a lot more I can talk about in a week’s time than I could ever cover in a series of blog posts, especially because in an intimate class it is far easier to communicate.

So I will be inviting five people to fly in and stay for five days. No cell phones, no computers, no distractions - just talking webappsec. I attended an invite only conference of this format before and it worked great, where the only open computer was the one operating the projector. Being off the grid really helps people focus. Everyone will sign non disclosure agreements so people can talk freely about problems they are concerned with without having to worry about it getting out. There will be eventual outputs from the classes, but they will be discussed only with people who attend. Days will be spent talking about webappsec, nights will be spent with me in downtown Austin, visiting the local nightlife and probably talking about webappsec some more. My goal is not to make myself the grand leader of a group of five people who are webappsec gods, but rather, build a collaborative group of people who change their way of thinking and come out of it with the knowledge on how to fix their little slice of the Internet.

I’m just not scalable, and while the blog has been a great conduit for sharing some of my ideas, it’s clear to me that people just aren’t getting the value out of it that they could in another format (I guess you get what you pay for, as this site is free!). It turns out I just have a lot more to say than I put on this site. That became apparent today when I started chatting with someone about a specific web application flow. It took me ten minutes to explain some of the esoteric nuances to watch out for and I suddenly realized I had never talked about it before on the site, and I probably never would have because I ultimately consider a lot of that stuff to be “the basics” (even though apparently not a lot of people know about it). I usually try to skirt around the basics as to avoid alienating the experts who frequent this site. How would anyone know about the esoteric gotchas if I didn’t talk about it? Well, now is your chance to come ask me. Not that I will just be covering basics - oh no, why come to me for the basics? But this will be your chance to get me to slow down and explain things to you in a virtually one on one environment.

My goal isn’t to get the best of the best and put them in a room together (although if I wind up with a bunch of people who are experts I will build a class specifically for them). The main goal of The Austin Project is to get people who want to learn but are otherwise starved for information. I want to help those people and bring them to the next level, so that they go off and eventually help others and so on. I firmly believe education at this level will help our industry, help us start developing better applications, better strategies, and ultimately will make all our lives better.

This isn’t like most training. There will be no CPE credits (although I’m sure you could convince someone it should count), no class of 40 people, no canned demonstrations. This is just a chance for you to sit with me for a week and talk about whatever it is you want to talk about in an collaborative environment. I don’t want five people from the same company showing up. That’s not the goal here. The goal is for you to meet other people with other problems and work through them together as much as it is to hear from me. Why? Because other people have interesting problems that relate to our industry that you should think about too! I want to facilitate the correct thought process, which is so much more important than me just solving your problems for you. I want to make people into the big thinkers (not just technologists) that this industry needs. I want the participants to build relationships that they can use to better themselves and their careers. Big goals for such a little class!

Anyway, if we wind up with way more than five people who are interested, we can separate the classes into groups, but I have no idea how many people will be interested. I don’t want to go over five people and I don’t want it smaller than that or it would defeat the goal of building a team, so I may actually turn people away if we don’t hit a critical mass. This is just as much an experiment for me as it is for anyone who would attend. I also may turn people away if I think they couldn’t benefit from this - which is why I’ll be asking for a resume from each of the people who are interested. If you have no experience, this isn’t the class for you. If you have been doing this longer than I have, this isn’t the class for you. If you just want to come to the class to heckle me, well, it’s an expensive prank, but it’s your money. So if you are at all interested, check out The Austin Project web-page for the specifics and send your contact information through the form.

1. "...make both sense and money from the vast amounts of information Yahoo collects on the doings of 500 million people who visit its site every month."
2. "Fayyad... [is] engaged in a major battle over how freely that information can be used to tailor ads to individuals."

These goals are almost diametrically opposed. I searched for a chief privacy officer for Yahoo! as well, but did not find any references to one. While I am sure that Mr. Fayyad very competent and wants to strike the right balance, Yahoo! has opened themselves up to additional business risks by placing the duty to protect information, and make money from it in the same person. Much like our legal system, data protection and data usage need two different people on opposing sides in order to effectively bring the issues to light and find the right balance. That is why these two duties should be separated, and why it is important to have a chief privacy officer. There are already many other people on the opposite side of the issue, like the heads of business or marketing officers. Even still, it may not be a fair competition, but at least someone will be standing up for the consumer trying prevent privacy violations.