Feeds

back to article New table-munching worm ravages Iranian biz databases

A new strain of malware is thrashing corporate databases in the Middle East, claiming the vast majority of its victims in Iran. Narilam is "causing chaos" by targeting and modifying corporate databases, according to Symantec. The worm spreads through removable drives and network shares. Network worms are relatively commonplace …

COMMENTS

This topic is closed for new posts.

Re: headline...

I didn't know David Cameron moved to Iran...

2
1
Bronze badge

Well-managed backups - what a good idea.

I will urge that my organisation implements well-managed backups immediately. Not because of this malware but because it just generally makes sense to back up the data that your business relies on. I advise other readers to do this, too.

2
0
Anonymous Coward

Re: Well-managed backups - what a good idea.

You'd be surprised how many backups are never tested to ensure they can actually be used. I once suggested this be done, as per our policy, and the response was "ah we'll just hope it works if it goes tits up".

Public sector, crazy eh?

1
0
Silver badge

Re: Well-managed backups - what a good idea.

The problem is getting a 2nd production system to test the backups on, or getting permission to remove all of the drives from the 'only' production system. Because if it doesn't work, proving it on the production system is NOT the way to do it.

1
0
Bronze badge

Re: Well-managed backups - what a good idea.

> Public sector, crazy eh?

Yup. Because we in the private sector are so much smarter than you.

Free irony tags at the bar.

0
0
Boffin

Re: Well-managed backups - what a good idea.

A second "production" system would be the one that you have provisioned for disaster recovery (DR). That's the one in a separate building, with its own electricty, etc supply. Connected only by optic fibre or a directional, wireless link.

How else does one cope with e.g. a physical catastrophe that might take days to weeks to resolve?

The DR system doesn't have to have 100% of the capabilities of the live system. It "only" needs to provide core business functions. You must be sure that it can, so you have to test it irregularly but at least several times a year; perhaps running a full "DR drill" once every year to 18 months if the plan isn't exercised out of necessity.

As for rogue RDBMS transactions, most engines support transaction logging. Those seeking to milk the last bits of performace out of the system may not have turned it off or never enabled it. The performance hit from transaction logging, when properly configured is a few percent. That is well worth it for protecting the integrity of enterprise data.

The vanilla procedure for recovery from a committed rogue transaction is to restore from the previous backup and then roll forward on the transactions up to the one which was rogue. It *may* be safe to roll forward on subsequent transactions but that is not the general case.

If you don't have a transaction log, then restoring from teh previous backup required "re-keying" all the data. Which is more likely not "possible" nowadays with EDI and web-presence. It may be possible to replay electronic transactions but their ORDER is significant in most EDI systems to preserve e.g. order numbers. Otherwise shipments, etc using such sequence numbers will become lost.

0
0
Anonymous Coward

Re: Well-managed backups - what a good idea.@ Robert Carnegie

Thanks for the tip. Nobody anywhere had ever thought about it before you mentioned it.

0
0

"Nobody anywhere had ever thought about it before you mentioned it."

It's not so much that nobody has thought about it, it's just that for a lot of people thinking about it is as far as it gets. Instead of actually /doing/ it.

0
0
This topic is closed for new posts.