Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fire destroys S. Korean government's cloud storage system, no backups available

koreajoongangdaily.joins.com

Post reply on HN
Print view View original

251–260 of 987 posts

Re: Fire destroys S. Korean government's cloud storage system, no backups available

#251

Post by 9dev »

Avamander wrote: post #236
t-3 wrote: post #205

Earlier quoted context omitted.

From the perspective of securing your data, what's the practical difference between a second country and an enemy country? None. Even if it's encrypted data, all encryption can be broken, and so we must assume it will be broken. Sensitive data shouldn't touch outside systems, period, no matter what encryption.

Any even remotely proper symmetric encryption scheme "can be broken" but only if you have a theoretical adversary with nearly infinite power and time, which is in practice absolutely utterly impossible. I'm sure cryptographers would love to know what makes it possible for you to assume that say AES-256 or AES-512 can be broken in practice for you to include it in your risk assessment.

You’re assuming we don’t get better at building faster computers and decryption techniques. If an adversary gets hold of your encrypted data now, they can just shelf it until cracking becomes eventually possible in a few decades. And as we’re talking about literal state secrets here, they may very well still be valuable by then.

Re: Fire destroys S. Korean government's cloud storage system, no backups available

#252

Post by crazygringo »

vkou wrote: post #221
crazygringo wrote: post #166

Earlier quoted context omitted.

Exactly. Like, don't store it in the cloud of an enemy country of course. But if it's encrypted and you're keeping a live backup in a second country with a second company, ideally with a different geopolitical alignment, I don't see the problem.

A country can become an adversary faster than a government can migrate away from it.

Hence a backup country. I already covered that.

But while countries go from unfriendly to attacking you overnight, they don't generally go from friendly to attacking you overnight.

Re: Fire destroys S. Korean government's cloud storage system, no backups available

#253

Post by jiggawatts »

I was the principal consultant at a subcontractor to a contractor for a large state government IT consolidation project, working on (among other things) the data centre design. This included the storage system.

I noticed that someone had daisy-chained petabytes of disk through relatively slow ports and hadn’t enabled the site-to-site replication that they had the hardware for! They had the dark fibre, the long-range SFPs, they even licensed the HA replication feature from the storage array vendor.

I figured that in a disaster just like this, the time to recover from the tape backups — assuming they were rotated off site, which might not have been the case — would have been six to eight weeks minimum, during which a huge chunk of the government would be down. A war might be less disruptive.

I raised a stink and insisted that the drives be rearranged with higher bandwidth and that the site-to-site replication be turned on.

I was a screamed at. I was called unprofessional. “Not a team player.” Several people tried to get me fired.

At one point this all culminated in a meeting where the lead architect stood up in front of dozens of people and calmly told everyone to understand one critical aspect of his beautiful design: No hardware replication!!!

(Remember: they had paid for hardware replication! The kit had arrived! The licenses were installed!)

I was younger and brave enough to put my hand up and ask “why?”

The screeched reply was: The on-prem architecture must be “cloud compatible”. To clarify: He thought that hardware-replicated data couldn’t be replicated to the cloud in the future.

This was some of the dumbest shit I had ever heard in my life, but there you go: decision made.

This. This is how disasters like the one in South Korea happen.

In private organisations you get competent shouty people at the top insisting on a job done right. In government you get incompetent shouty people insisting that the job gets done wrong.

Re: Fire destroys S. Korean government's cloud storage system, no backups available

#254

Post by 9dev »

deaddodo wrote: post #213
OvbiousError wrote: post #198

Earlier quoted context omitted.

Enemy country in the current geopolitical climate is an interesting take. Doesn't sound like a great idea to me tbh.

There are a lot of gray relations out there, but there’s almost no way you could morph the current US/SK relations to one of hostility; beyond a negligible minority of citizens in either being super vocal for some perceived slights.

Trump will find a way, just as he did with Canada for example (i mean, Canada of all places). Things are way more in flux than they used to be. There’s no stability anymore.

Re: Fire destroys S. Korean government's cloud storage system, no backups available

#256

Post by MBCook »

pico303 wrote: post #150
kristianc wrote: post #95

The government official who insisted that commercial AWS/GCP/Azure couldn't possibly be trusted with keeping the information will be keeping their head low for a few days then... "The Interior Ministry explained that while most systems at the Daejeon data center are backed up daily to separate equipment within the same center and to a physically remote backup facility, the G-Drive’s structure did not allow for extern…

What a lame excuse. “The G-Drive’s structure did not allow for backups” is a blatant lie. It’s code for, “I don’t value other employees’ time and efforts enough to figure out a reliable backup system; I have better things to do.” Whoever made this excuse should be demoted to a journeyman ops engineer. Firing would be too good for them.

It could be accurate. Let’s say, for whatever reason, it is.

Ok.

Then it wasn’t a workable design.

The idea of “backup sites” has existed forever. The fact you use the word “cloud” to describe your personal collection of servers doesn’t suddenly mean you don’t need backups in a separate physical site.

If the government mandates its use, it should have a hot site at a minimum. Even without that a physical backup in a separate physical location in case of fire/attack/tsunami/large band of hungry squirrels is a total must-have.

However it was decided that not having that was OK, that decision was negligence.

Re: Fire destroys S. Korean government's cloud storage system, no backups available

#257

Post by fiatpandas »

63stack wrote: post #255
jn78 wrote: post #80

https://phrack.org/issues/72/7_md#article

This is the first time I see this site, who/what is phrack? A hacker group?

It’s a zine. Been around since the 80’s. Hackers / security industry types read and publish to it.

Re: Fire destroys S. Korean government's cloud storage system, no backups available

#258

Post by immibis »

edoceo wrote: post #245
bink wrote: post #209

Earlier quoted context omitted.

Not only does the NSA break encryption but they actually sabotage algorithms to make them easier to break when used.

Can the NSA break the Ed25519 stuff? Like the crypto_box from libsodium?

ed25519 (and ec25519) are generally understood not to be backdoored by the NSA, or weak in any known sense.

The lack of a backdoor can be proven by choosing parameters according to straightforward reasons that do not allow the possibility for the chooser to insert a backdoor. The curve25519 parameters have good reasons why they are chosen. By contrast, Dual_EC_DRBG contains two random-looking numbers, which the NSA pinky-swears were completely random, but actually they generated them using a private key that only the NSA knows. Since the NSA got to choose any numbers to fit there, they could do that. When something is, like, "the greatest prime number less than 2^255" you can't just insert the public key of your private key into that slot because the chance the NSA can generate a private key whose public key just happens to match the greatest prime number less than 2^255 is zero. These are called "nothing up my sleeve numbers".

This doesn't prove the algorithm isn't just plain old weak, but nobody's been able to break it, either. Or find any reason why it would be breakable. Elliptic curves being unbreakable rests on the discrete logarithm of a random-looking permutation being impossible to efficiently solve, in a similar way to how RSA being unbreakable relies on nobody being able to efficiently factorize very big numbers. The best known algorithms for solving discrete logarithm require O(sqrt(n)) time, so you get half the bits of security as the length of the numbers involved; a 256-bit curve offers 128 bits of security, which is generally considered sufficient.

(Unlike RSA, you can't just arbitrarily increase the bit length but have to choose a completely new curve for each bit length, unfortunately. ed25519 will always be 255 bits, and if a different length is needed, it'll be similar but called something else. On the other hand, that makes it very easy to standardize.)

Post reply on HN