Here’s an interesting post on High Earth Orbit about the usage and promotion of open source software for defense contracts. As a developer of open source tools, Andrew Turner of course brings up some “pros” for the government to push open source, but it’s the “cons” that are really interesting. A big “con” – the US government having something called “sovereign immunity” which apparently means something like it can’t be sued unless it consents to be sued. Hunh – the Republic of ScienceLogic-Land? Closing the loop here, a federal appeals court just boosted open-source software licenses by saying that any infringements can now get more severe remedies under copyright law (instead of contract law); here’s the case, Jacobsen v Katzer. But apparently not if it’s the US government?? Who knows more?

Does Linus Torvalds hate everyone except for developers? You have to check out this article on an email exchange he had with Network World this week, talking about how fed up he is with the “security circus”. Over the course of the exchange and some other comments from last month, he manages to blast security folk, OpenBSD (on security) in particular, vendors and PR people (of course). In the midst of the barrage of colorful language, it’s difficult to really get his point – which if you can dig it out, ends up being surprisingly sensible.

Sharon Taylor, Chief Architect of ITIL V3, recently wrote that with the release of the latest version of ITIL, BSM is now an ‘ITIL best practice.’ You say potato… “The distinction between IT and the business has blurred, and the language of IT has been replaced with the language of the business.”

Blogger: Ramon Krikken

The web browser is one of those peculiar pieces of software, having to accept input from arbitrary sources and then parse and render the data that is sent to it. Part of this it does by itself, and other parts are taken care of by handlers and plug-ins. In doing so, it displays hypertext, images, videos, and even runs active content like Flash, JavaScript, and ActiveX.

But however much we love the browser, we’ve also come to hate the myriad of vulnerabilities that affect it. Everything from cross-site scripting to remote code execution via maliciously formed animated cursor files and Flash content can make browsing a hazardous activity. The browser is sick, and that’s not desirable for a platform we use for important business and personal transactions.

Worsening the browser’s diagnosis is the recent paper from Mark Dowd and Alexander Sotirov, sub-titled “Setting back browser security by 10 years,” which discusses how to bypass Microsoft Vista’s memory protection capabilities with some added effort for the exploit designers. It’s not that all of the techniques are necessarily new, but the browser appears to be particularly vulnerable to easy exploitation.

Surprising? Not exactly, when we take into account that the browser is suffering from the same disease as the general purpose operating system: bloat and compatibility. We expect the browser to do ever more, but everything we used it for before still needs to work as if it were yesterday. It feels a bit like people insisting on using a cardboard box as a safe, and wondering why their money keeps getting stolen.

It’s not like we haven’t been working on the browser’s cure, though. There have been some improvements in the browsers themselves, the operating systems have also implemented compensating controls, but most of all, there has been an enormous push for securing the web applications that deliver the data in the first place. Unfortunately, the latter two won’t help secure the browser in the long run.

The first issue is that not all content will come from ‘nice’ servers, the second that the server can only make an educated guess on how a browser will parse and render a given set of data, and the third that operating system controls have their own limitations, whether by design or implementation (for example needing to re-compile existing code to enable certain protections.) The browser, in the end, has to be mostly responsible for keeping itself safe; the operating system must assist it in doing so.

So we’re in a pickle. The browser is sick (and the operating system is too), but it’s hard to cure it without a redesign that will undoubtedly impact compatibility, the ever-so-desired multi-functionality, or its ease of use. We can layer defenses by using web filtering in the enterprise environment, but in the end – for the consumer market in particular – we need to fix the browser itself. I can think of a few things I think might help:

• Some kind of site security policy  to restrict where the browser loads auxiliary content from, and which data it can ‘trust’, when loading a web page (I’d prefer mandatory enforcement, and adding an HTML tag to be able to indicate blocks of untrustworthy data.)
• Restricted compartments for plug-ins to run in, ensuring that their bugs cannot easily affect the whole browser.
• Better software development practices for the plug-ins and content parsers themselves, so that they’re less vulnerable, and compiled with the latest protection measures to begin with.

All of this means more work, and some of it means a lot of unhappy reactions when things stop working. Even then we will of course still have to deal with additional vulnerabilities, such as those that may be present in hardware, but we will at least have taken prudent steps to ‘find a cure.’

Blogger: Ramon Krikken

The web browser is one of those peculiar pieces of software, having to accept input from arbitrary sources and then parse and render the data that is sent to it. Part of this it does by itself, and other parts are taken care of by handlers and plug-ins. In doing so, it displays hypertext, images, videos, and even runs active content like Flash, JavaScript, and ActiveX.

But however much we love the browser, we???ve also come to hate the myriad of vulnerabilities that affect it. Everything from cross-site scripting to remote code execution via maliciously formed animated cursor files and Flash content can make browsing a hazardous activity. The browser is sick, and that???s not desirable for a platform we use for important business and personal transactions.

Worsening the browser???s diagnosis is the recent paper from Mark Dowd and Alexander Sotirov, sub-titled ???Setting back browser security by 10 years,??? which discusses how to bypass Microsoft Vista???s memory protection capabilities with some added effort for the exploit designers. It???s not that all of the techniques are necessarily new, but the browser appears to be particularly vulnerable to easy exploitation.

Surprising? Not exactly, when we take into account that the browser is suffering from the same disease as the general purpose operating system: bloat and compatibility. We expect the browser to do ever more, but everything we used it for before still needs to work as if it were yesterday. It feels a bit like people insisting on using a cardboard box as a safe, and wondering why their money keeps getting stolen.

It???s not like we haven???t been working on the browser???s cure, though. There have been some improvements in the browsers themselves, the operating systems have also implemented compensating controls, but most of all, there has been an enormous push for securing the web applications that deliver the data in the first place. Unfortunately, the latter two won???t help secure the browser in the long run.

The first issue is that not all content will come from ???nice??? servers, the second that the server can only make an educated guess on how a browser will parse and render a given set of data, and the third that operating system controls have their own limitations, whether by design or implementation (for example needing to re-compile existing code to enable certain protections.) The browser, in the end, has to be mostly responsible for keeping itself safe; the operating system must assist it in doing so.

So we???re in a pickle. The browser is sick (and the operating system is too), but it???s hard to cure it without a redesign that will undoubtedly impact compatibility, the ever-so-desired multi-functionality, or its ease of use. We can layer defenses by using web filtering in the enterprise environment, but in the end ??? for the consumer market in particular ??? we need to fix the browser itself. I can think of a few things I think might help:

• Some kind of site security policy  to restrict where the browser loads auxiliary content from, and which data it can ???trust???, when loading a web page (I???d prefer mandatory enforcement, and adding an HTML tag to be able to indicate blocks of untrustworthy data.)
• Restricted compartments for plug-ins to run in, ensuring that their bugs cannot easily affect the whole browser.
• Better software development practices for the plug-ins and content parsers themselves, so that they???re less vulnerable, and compiled with the latest protection measures to begin with.

All of this means more work, and some of it means a lot of unhappy reactions when things stop working. Even then we will of course still have to deal with additional vulnerabilities, such as those that may be present in hardware, but we will at least have taken prudent steps to ???find a cure.???

My reply is that I don’t care must about reported dollar sales because these numbers are, for the most part, meaningless and mythical at this point in time. Large companies sell enterprise licenses and make up allocated numbers for the CEP/EP share of the pie based on a subjective formulation. They can sell an enterprise site license for $2,000,000 USD that includes CEP/EP software and claim 20% is CEP revenue, regardless of if the software is used or not.

Small companies nearly give software away with the hope of developing a strong public reference client, which are few and far between in 2008. Soon, I will start a Google spreadsheet, similar to what we did last year on this topic. Some folks don’t seem to like this initiative because, unfortunately, we will see that for this half of 2008, this year has been very lean for CEP/EP. Some would prefer I blog as a cheerleading evangelist versus an objective analyst. Go Fight Win! Rah Rah Rah!

Much of the current gloomy situation, of course, is because the entire market has fallen and IT spending is down. Financial companies announce record losses. Bankruptcies and restructuring are in the daily news.

In this depressed market, some companies have tried to tie the subprime crash to CEP, somehow implying that CEP would have helped, but that positioning is mostly fantasy. I work in the field of risk management at the corporate level and the current problems are not caused by a lack of technology, it is simply corporate greed - corporations taking high risks to stay competitive in a bull market and then they experience a frighteningly negative reversal during a market free fall.

Of course, the US Federal Reserve did not help matters when they decided to poke a gaping hole in the real estate bubble by dramatically raising interest rates without thinking about how they would manage the consequences, but that is another story! After all, the current top government executives in Washington DC are so politically, scientifically and economically incompetent that all we can do is hold our breath and count the days.

One risk management colleague often says,

“When then tide is high, you can’t see that the swimmers are naked.”

….and so it is in business. The current problems in the global market are based on human, social, and political errors and incompetence; nothing that technology can cure at this point in the game. So, the entire market is in decline, and folks are overhyping all software to keep the buzz going, as if CEP or SOA or BPM would have helped stopped the current global meltdown. Yes, CEP can stop global warming! Buy one today, save a cute polar bear!

Then again, maybe we only need a CEP engine in Washington; even a simple rules-based one would be good. Naturally, some would suggest that we need Neural Nets and Bayesian analytics; but I think just a simple rules-engine looking out the window that can process if-then-else conditions would be a great improvement over the mind-numbing leadership in Washington today.

Why? Well, the problem with layered security is that we tend to assume if Layer X isn’t providing a particular protection, Layer Y must be… and we all know what assuming does.

In the good ol’ days, we relied on firewalls- perhaps nested firewalls, or ones positioned strategically on the LAN as well as the WAN. Because of our network architecture at the time, that was the primary (and probably only required) protection. After years of de-perimeterization and the increase of threats from both remote-access and insiders, we have a much different landscape.

The addition of resources and availability in the network has lead to the addition of vulnerabilities and threats.

Now… our schools need to protect children from material online. Now… we need to stop Trojans from sneaking in with VoIP apps. We need to access our corporate network securely from Starbucks. Our corporations need to protect their network from users accessing or publishing illegal content on the Internet. We need to protect our email, make sure its virus-free and not allowing employees to send sensitive information to the outside world.

All these increased risks and threats lend to the need for more protection in the environment. There’s just no single silver bullet or cure-all for the problems we’re facing.

What does this mean? It means we’re adding security products to the network to address these issues. We need content filtering. We need layer-7 visibility on the WAN for inbound/outbound application control. We need data leakage prevention. We need email security. We SSL-VPNs for secure remote access… the list goes on.

So, what’s the problem? We’re living in a world of security buzzwords and ‘hot topic’ solutions. But the problem is 2-fold.

Problem 1- We forget to KISS IT. In the frenzy to understand and implement these hot new products, we’re losing sight of some basic security functions and overlooking some really important security fundamentals. Remember to KISS IT and keep your basic security solutions simple- then layer on top of that. Your hot new NAC or DLP solution won’t seem so impressive if your basic firewall rules haven’t been properly configured.

Problem 2- We forget thy layers. After you KISS IT, you need to start layering responsibly. That means having a CLEAR understanding of what each solution does- or does not- do. You wouldn’t believe how many customers call and want to hear about Widget A for a certain solution that Widget A is not designed to fix. I deal with it daily and I blame (for the most part) vendors for mis-advertising their product as a fix-all. Whether its hardware or software- know what each piece of your security solution is designed to do, what it’s actually doing, and keep that information documented. Documented- I’m going to say it again. Your firewall/UTM may offer content filtering and gateway AV, but are you using it? Are you using a WAN optimization product to stop prohibited applications, or is your web filter doing that? Do you even know?

Solving the Cube. Layered security is like solving a Rubik’s Cube. You may think you’re on the right track after you get one side solved… but the other 5 are just a huge mess. There are patterns and algorithms you must follow to solve all sides together. Your layered security solution is no different. Understand what each piece is doing, how it fits in, and when to twist one layer here to implement a solution as part of a different layer over there.

# # #