|
It's cool Griff. We are spending the week dead, for tax reasons.
|
|
|
|
|
Just don't press that weird black button that is labelled in black on a black background. 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Well that's strange. A sign popped up and it said "please do not press that button again".
|
|
|
|
|
That is strange! Normally a small black light lights up black to let you know you've done it.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Except the virus stopped spreading when a random domain name was registered, as the virus assumes it is being run in a an analysis sandbox. They are keeping the domain up.
Assuming the hackers don't start a DOS attack against it (my fear).
|
|
|
|
|
A DDOS shouldn't do it in theory, since it's the IP it looks for (apparently) - which comes back from the DNS lookup rather than the domain itself.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Thanks for shedding some light on the scale of the problem in individual organizations. However even in large distributed systems there must be a daily reconciliation and backup of local servers. Thus I'm assuming that an organization with proper backup policies in place should only be risking a day or two of data at any time.
Peter Wasser
"The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts." - Bertrand Russell
|
|
|
|
|
Basildane wrote: Your backup of a desktop computer is comparing apples to oranges. I manage a VAST amount of data, and that's just in my tiny little world. Petabytes.
Thanks for the view from the other side.
Makes my backup scheme seem trivial. We have three servers that back up to each other nightly. One of the servers has an external hard drive that gets everything as well. We have a remote server that receives backups of our source control data bases. Weekly I back up the source control data bases to DVD's, plus to a thumb drive that goes home with me. And yes, I regularly check the backups to make sure they contain the data I think they should contain.
Software Zen: delete this;
|
|
|
|
|
Actually, it's worse than that. We are just talking about backing up raw data. To recover from a disaster would require a colossal effort, not just restoring data. Re-configuring servers / clusters, database schemas, firewall configurations, all the myriad of server customizations and service account settings to make a particular service operational. DNS and VLAN's, all the networking configurations.
If I had to restore my project from a complete loss, I can't even imagine that. Would probably take a month with my whole team working on it non-stop. That's with a full data backup.
|
|
|
|
|
It's hard to imagine.
If I lost our primary source control server, I could have us back up and working in less than an hour. If I lost all three servers it would take a day to build a box(*) and get everything installed. Anything more serious than that would suggest building damage (fire, tornado, etc.) that would mean far more significant problems.
(*) All three of my current servers are recycled server-class industrial PC's from our products. I have a pile of these machines in my lab called the Island of Misfit Toys , all of them functional. If I had the time, I'd love to create a distributed build system. Our current build process takes 30-90 minutes, depending upon the product and which server is running the build. With a distributed process, I could probably get that down to under 10.
Software Zen: delete this;
|
|
|
|
|
This one system runs on servers spread across 3 cities (for technical reasons). We just this month moved 5 racks of data processing from the 3rd floor of this building to a new datacenter on the 2nd floor. This took 2 YEARS of planning. We just finished the move this month (with no loss of service).
|
|
|
|
|
When I worked at DOW Chemical I was introduced, as an intern, to the Disaster Recovery Plan they had.
Their backups go offsite.
They rent a virtual offsite location year round.
Quarterly they test their restore process, and TIME IT. When you are dealing with this much data, and tens of thousands of shipments coming into various ports throughout the world, this gets serious.
They update their documentation on when people have to be on planes to fly to one of the few restore centers, and had fallback plans for emergency leasing of jets, and people driving!!!
My first question, after realizing that MANY companies pay this same company for these services, and access to their mainframes, etc.... "What happens if many companies get hit at the same time?"
The answer was "The risks of that are LOW, but they can handle up to 3 companies at once". Which is incredibly rare. (And the lesson of the last 25 years... UNTIL IT ISNT)
This outbreak brought back those two memories.
Having worked for companies that CANNOT REASONABLY complete a "backup" in 24 hrs, think of your exposure.
Just hope it never spreads through bitcoin 
|
|
|
|
|
DVDs and CDs have a shelf life unfortunately.
|
|
|
|
|
I think the news reports were not completely accurate. Big systems were attacked but backups could be restored which took a day or two. That is pretty much what I would expect especially on a weekend.
Peter Wasser
"The whole problem with the world is that fools and fanatics are always so certain of themselves, and wiser people so full of doubts." - Bertrand Russell
|
|
|
|
|
I suppose it makes sense that an IT professional would want the NHS to spend more of its budget on IT professionals.
Me, I want them to spend ALL their money on making people well.
When the people who distributed this malware are caught, let's hope that they are given life sentences for it.
An object lesson needs to be taught: Go ahead and be an @rsehole, but certain things are off-limits.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
I'd bet that the @rseholes are not that focused, just blast it out there and get anyone, don't care who they are just want their money.
I have sympathy for the NHS, totally overworked health professionals who have to rely on computer systems that they barely understand.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mark_Wallace wrote: When the people who distributed this malware are caught, let's hope that they are given life sentences for it.
Hell, NO!
Hacking a system that involves human safety (medical, air traffic control, first-responder communications, and so on) ought to be a felony. If a person dies as a consequence of the hack, it ought to be prosecuted as first-degree murder, with a mandatory maximum possible sentence allowed under the law. If that sentence dictates capital punishment, all the better.
I want their heads mounted on pikes outside the castle walls as a warning to others.
Software Zen: delete this;
|
|
|
|
|
All I can say is that you guys are going easy on them...
the sad part is that this goes back to the NSA!
|
|
|
|
|
The first rule of security is, you don't "talk about it" (your measures).
I use 3 levels:
1) Extra local drive (D)
2) External drive
3) Cloud storage.
Most acquaintenances I steer to cloud storage (PC and Mac) for their photos and the like.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
I remember when well-meaning and trusted IT professionals took rolls of backup-tape home with them for off-site storage because the company WOULDN'T PAY for off-site backup. I don't remember any adverse effects ... and that's not because my memory is shot. Of course, back then people didn't know how to "monetize" other folks' data!
|
|
|
|
|
It seems to me a big part of today's problem is that companies are too stingy to pay for proper backup facilities and procedures (and possibly personnel), to cover the kind of eventuality that we saw this past week. If so, they get what they deserve!
Get me coffee and no one gets hurt!
|
|
|
|
|
I still take my nightly backup on LTO-6 tape each evening. Two weeks of tape on a rotating basis gives me 10 days I can go back in case of infection Stupidity.
|
|
|
|
|
First thing: Minimum budget.
Second thing: Many people who work in medical institutions dont know or dont care about cybernetic security at all.
Last thing: Many people think that they had a paid version of a famous anti virus will help protect them from anything, even electrical leak.
|
|
|
|
|
Simple. Make a backup and place it into a fireproof safe. Then make a second backup in case there is a fire in the fireproof safe. (Source: Hogans Heros.)
|
|
|
|
|
This is so nice.
I've got some Jasmine JavaScript tests that include NaN for my arrgh.js library, works fine.
Example:
it("should add NaN to the list", function () {
var l = new arrgh.List();
l.add(NaN);
expect(l.toArray()).toEqual([NaN]);
});No problem at all, even though NaN does not equal NaN.
The alternative is that I manually test the entire array (I've got some other tests involving NaN).
Now I decided to add support for Node.js.
So I install jasmine-node, load my tests using require(), run them and get the following error...
Expected [ NaN ] to equal [ NaN ].
Yes, I know NaN does not equal NaN, I know it's a friggin bitch to work with, that's why I'm specifically testing with NaN!
The browser framework does it right, it treats NaN to be NaN in such cases, or this kind of tests become pretty difficult to test.
So with Node.js support my library becomes a bit more difficult to test I guess 
var arr = l.toArray();
expect(arr.length).toBe(1);
expect(arr[0]).toBeNaN(); On to the bigger tests...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
