The case of Code Spaces still echoes in cyberspace. Code Spaces offered cloud facilities to developers and had a successful business model, until it became the target of a cyberattack.
The attack started as a DDoS (distributed denial of service) attack. Strangely enough, Code Spaces was alerted by the attacker to the possibility of stopping the attack by messages that the attacker left on the Code Spaces internal console, showing that the attacker had already penetrated Code Spaces systems.
When Code Spaces attempted to oust the attacker, the attacker retaliated by deleting large portions of Code Space data, and causing irreparable and fatal damage to the company, whose backup strategy failed to save it. So, what went wrong?
When a cloud enterprise with the size and reputation of Code Spaces collapses and ceases trading, it sends out a strong warning to other organisations using the cloud. In this tale of smoke screens and sabotage, there are several points that other companies would do well to heed, if they want to avoid the Code Spaces fate.
- A basic rule for backups is that organisations should conserve 3 copies of data on 2 separate media, with 1 offsite, also known as the “3-2-1 rule”. Code Spaces used Amazon Web Services to run their service and store their data, but without observing the 3-2-1 rule.
- A DDoS attack may be carried out for different reasons. One is to force the target into complying with a given demand (like paying money for the DDoS attack to stop). Another is to create a diversion, leaving other parts of the IT infrastructure less well guarded, so that the attacker can work on penetrating other systems.
Add into the mix a lack of multi-factor authentication to securely identify people asking for access, and it looks even more as if Code Spaces had essentially set itself up to be attacked. All that was back in 2014, but the lessons learned (too late for Code Spaces) are still just as valid today.