Monthly Archives: October 2012

Kaspersky Lab Developing Its Own Operating System? We Confirm the Rumors, and End the Speculation!

Hi all!

Today I’d like to talk about the future. About a not-so-glamorous future of mass cyber-attacks on things like nuclear power stations, energy supply and transportation control facilities, financial and telecommunications systems, and all the other installations deemed “critically important”. Or you could think back to Die Hard 4 – where an attack on infrastructure plunged pretty much the whole country into chaos.

Alas, John McClane isn’t around to solve the problem of vulnerable industrial systems, and even if he were – his usual methods of choice wouldn’t work. So it comes down to KL to save the world, naturally! We’re developing a secure operating system for protecting key information systems (industrial control systems (ICS)) used in industry/infrastructure. Quite a few rumors about this project have appeared already on the Internet, so I guess it’s time to lift the curtain (a little) on our secret project and let you know (a bit) about what’s really going on.

Operating System Code

But first – a little bit of background about vulnerable industrial systems, and why the world really needs this new and completely different approach of ours.

More: The defenselessness of industrial systems …

Flickr photostream

  • KLHQ
  • KLHQ
  • KLHQ
  • KLHQ

Instagram photostream

From Columbia to Colombo.

Hi all!

Now, if you’re not too hot on geography, I’m writing this from Washington, D.C., with the D.C. standing for District of Columbia, don’t you know. There’s another Washington – Washington state – on the other side of the American continent, but without the D.C. There’s a Colombia – the South American country; then there’s Columbia University in New York; there’s Columbo – the TV detective fond of beige sack-like raincoats; and to add to the confusion, round the other side of the globe there’s Colombo – the largest city of Sri Lanka (formerly Ceylon), which is where we’re headed today.

Our three days in Washington whizzed past like a film on fast-forward: As per, we were whizzing about all over the place getting to event after event. And I really mean whizzing – just like a (non-D.C.) squirrel in a wheel – unlike the local squirrels here, which royally, haughtily and languidly stroll about parks as if they own them – not the easily-startled beasts I’m used to.

I won’t tell you all about all the events we took part in here – there’s not much point and it’d probably be pretty dull reading! (Note to event organizers/participants – your events were not dull to me :) I’ll just share with you one comment about the Billington Cybersecurity Summit where I got to speak about cyber threats, more info on which you can read here.

I really enjoyed personally meeting a whole lotta highly placed officials at the event and discussing with them in some detail the topic of cybersecurity and fighting computer maliciousness around the world. I was pleasantly surprised by how much these ladies and gentlemen – on whom a lot of US policy and thus security depends – know about the subject, and especially pleased to discover that their positions are very much like mine. Phew.

Work done, come Saturday we were able to get a bit of sightseeing in. We even managed to visit a couple of museums. The National Museum of Natural History we didn’t think too much of – all those dug-up mastodons and dinosaur bones look kind of unconvincing. While the Air and Space Museum… oh yes – that was more like it. All sorts of interesting stuff to see there, from the Wright brothers’ first airplane to the very latest drone. There are Messerschmitts, an SS-20, a Pershing, copies of Skylab and Apollo-Soyuz, and so on and so on. I decided against taking photos – there are plenty on the Internet. But it’s best to see it all in the flesh, of course.

The White House

More: Columbia-Doha-Colombo …

Enter your email address to subscribe to this blog

In Denial about Deny All?

In just a dozen or so years the computer underground has transformed itself from hooliganistic adolescent fun and games (fun for them, not much fun for the victims) to international organized cyber-gangs and sophisticated state-sponsored advanced persistent threat attacks on critical infrastructure. That’s quite a metamorphosis.

Back in the hooliganistic era, for various reasons the cyber-wretches tried to infect as many computers as possible, and it was specifically for defending systems from such massive attacks that traditional antivirus software was designed (and did a pretty good job at). These days, new threats are just the opposite. The cyber-scum know anti-malware technologies inside out, try to be as inconspicuous as possible, and increasingly opt for targeted – pinpointed – attacks. And that’s all quite logical from their business perspective.

So sure, the underground has changed; however, the security paradigm, alas, remains the same: the majority of companies continue to apply technologies designed for mass epidemics – i.e., outdated protection – to tackle modern-day threats. As a result, in the fight against malware companies maintain mostly reactive, defensive positions, and thus are always one step behind the attackers. Since today we’re increasingly up against unknown threats for which no file or behavioral signatures have been developed, antivirus software often simply fails to detect them. At the same time contemporary cyber-slime (not to mention cyber military brass) meticulously check how good their malicious programs are at staying completely hidden from AV. Not good. Very bad.

Such a state of affairs becomes even more paradoxical when you discover that in today’s arsenals of the security industry there do exist sufficient alternative concepts of protection built into products – concepts able to tackle new unknown threats head-on.

I’ll tell you about one such concept today…

Now, in computer security engineering there are two possible default stances a company can take with regard to security: “Default Allow” – where everything (every bit of software) not explicitly forbidden is permitted for installation on computers; and “Default Deny” – where everything not explicitly permitted is forbidden (which I briefly touched upon here).

As you’ll probably be able to guess, these two security stances represent two opposing positions in the balance between usability and security. With Default Allow, all launched applications have a carte-blanche to do whatever they damn-well please on a computer and/or network, and AV here takes on the role of the proverbial Dutch boy – keeping watch over the dyke and, should it spring a leak, frenetically putting his fingers in the holes (with holes of varying sizes (seriousness) appearing regularly).

With Default Deny, it’s just the opposite – applications are by default prevented from being installed unless they’re included on the given company’s list of trusted software. No holes in the dyke – but then probably no excessive volumes of water running through it in the first place.

Besides unknown malware cropping up, companies (their IT departments in particular) have many other headaches connected with Default Allow. One: installation of unproductive software and services (games, communicators, P2P clients… – the number of which depends on the policy of a given organization); two: installation of unverified and therefore potentially dangerous (vulnerable) software via which the cyber-scoundrels can wriggle their way into a corporate network; and three: installation of remote administration software, which allows access to a computer without the permission of the user.

Re the first two headaches things should be fairly clear. Re the third, let me bring some clarity with one of my EK Tech-Explanations!

Not long ago we conducted a survey of companies in which we posed the question, “How do employees violate adopted IT-security rules by installing unauthorized applications?” The results we got are given in the pie-chart below. As you can see, half the violations come from remote administration. By this is meant employees or systems administrators installing remote control programs for remote access to internal resources or for accessing computers for diagnostics and/or “repairs”.

Employee IT-security violations

More: The figures speak for themselves: it’s a big problem …