The Importance of Information Security: Lessons Learned from the Code Spaces Breach
In today’s economy, companies are reliant on accurate data more than ever. This need for good data has resulted in an increased necessity for resilient and reliable means of storing data. In fact, according to Laudon and Laudon (2016), organizational effectiveness is largely governed by how companies manage and store their data. Numerous cloud solutions have hit the market in an attempt to help companies manage, store, and access their data. These solutions offer companies the opportunity to store their data off-site, leveraging the hosting infrastructure of a third party. The third party, also known as a hosting company, handles the maintenance, monitoring, backup, and repair of the data and infrastructure, while charging companies for their data storage. While there are many advantages to utilizing a cloud based storage service, many companies remain hesitant to embrace cloud storage. A large reason for this apprehension is that end users are uncomfortable with keeping their data on another company’s infrastructure (Jamsa, 2013). One such example of a situation feeding this hesitancy is the data breach experienced by Code Spaces in 2014. Code Spaces, a company that offered cloud based code repositories, was hacked in 2014. The hack was so severe, and data loss so great, that Code Spaces never recovered. According to Venezia (2014), hackers commandeered the Amazon Web Services (AWS) administrative console controlling all of Code Spaces Infrastructure as a Service (IaaS) resources. The hackers asked for a ransom, which Code Spaces neglected to pay. The hackers then destroyed all Code Spaces data, most of which belonged to their customers.
This breach had an extreme impact on not just Code Spaces customers, but on the future of Code Spaces itself. Not only did a data breach occur, but data (and all associated backups) were deleted and not able to be restored. This is an example of a worst-case scenario, and while it may not happen often, when it does it has dire consequences.
What Went Wrong and How Did It Occur
In early 2014, Code Spaces was an up and coming business providing code repository and project management to software development companies. The business marketed itself as utilizing fully redundant backup hardware, with multiple off-site locations. They were proud of their business data recovery plan, and even shared that they tested their recovery process by completing test restores regularly. Unfortunately, their data recovery plan failed the ultimate test over a twelve hour period during the summer of 2014.
Code Spaces’ problem began when a hacker initiated a Distributed Denial of Service (DDoS) attack. The DDoS attach came with a message: Code Spaces must pay a large ransom or all of their data would be deleted. The hacker claimed to have gained access to the Amazon Web Services (AWS) administrative console controlling all Code Spaces’ hosted Infrastructure as a Service (IaaS) resources, including their backup systems. At this point, Code Spaces began to execute their standard security incident response plan, which including actions such as disabling unnecessary user accounts, changing passwords, and moving data to secondary systems. Unfortunately, the hacker was observing this response and did not take it kindly. The hacker immediately made good on their threat and systematically began deleting all Code Spaces related resources (Constantin, 2014). This meant that all customer data was deleted. Even worse, the backups were deleted. Code Spaces had not diversified their systems and were working solely with AWS. This meant that the hacker had deleted everything that had ever existed. There were no available backups. Recovery was not an option. Code Spaces was gone, as was all of their customer data. In the end, it was not necessarily true that Code Spaces had a fully redundant data storage system; they were simply relying on a single AWS account. This account hosted both their primary and backup data. Once the account was compromised, there was literally no way to continue business operations. Code Spaces had learned the importance of security and storage best practices the hard way.
Who Was Responsible
The hacker responsible for the Code Spaces hack was never found or prosecuted. Unfortunately, this is a reality in many of these types of cases. As cyber-crime continues to operate all over the world, the attacks (and attackers) are frequently becoming more difficult to trace. Hackers cover their tracks with cleverly designed proxies and Virtual Private Networks (VPNs). Making matters worse, hackers have started to organize joining together in loosely banded groups, like those common in non-digital forms of organized crime, such as street gangs or the mafia. Similarly, cyber-crime is increasingly becoming more innovative and sophisticated:
Today the cyber crime market is full of highly organized groups, often connected with traditional crime groups, and is rapidly growing and continuously innovating. This market is full of increasingly sophisticated organizations, people, products, and methods for communicating and conducting business transactions (Gordon, 2016).
As the hackers become more organized, they also become hard to detect and catch. This means that in many instances, the perpetrators of cyber-crime are never prosecuted or convicted for their crimes. It is incumbent on companies to do their best to avoid being hacked altogether; hoping to “catch the bad guys” so to speak has become a somewhat fruitless affair, and is not a reliable form of recourse.
How Could It Have Been Prevented?
While it is always easy to see after the fact, there are several actions Code Spaces could have taken to prevent or lessen the impact of such a data breach.
First of all, they should have developed a clear security strategy for using cloud services, including policies for diversifying service providers and auditing security practices. This strategy should have been clearly aligned with the overarching goals and objectives of the business and its customers. With that in mind, cooperating with key business and customer leadership should have been the first step when considering the cloud strategy (Rittle and Sullivan, 2016).
Similarly, Code Spaces should have practiced information security best practices in line with industry standards. Information security researchers have spent a considerable amount of time, effort, and resources to improve the security of cloud based services (Ardagna, Asal, Damiani, & Quang Hieu, 2015). Code Spaces should have used these features and recommendations, such as multi-factor authentication, proxy servers to audit logins, traffic analysis appliances such as GigaMon, next generation firewalls such as Palo Alto that analyze layer 7 (application) packets, and other recent improvements.
Finally, Code Spaces should have taken ownership of their backup and restore policies and procedures. Simply assuming that a single cloud provider’s policies will keep a business protected is not enough. Companies are solely responsible for ensuring the security and integrity of their data. They cannot pass the burden of responsibility to their cloud hosting provider. Code Spaces should have had physical or replicated copies of critical data (e.g., tape, on-premises replication, copies with multiple providers, etc.). Similarly, Code Spaces should have taken better care of their administrative credentials. It is not the hosting provider’s fault that Code Spaces did not take ownership of their security and backup practices. Neither can it be considered a technical failure. The fault lies with Code Spaces and Code Spaces alone. They did not hold themselves accountable for the integrity, security, and reliability of their customer’s data.
Advice and Recommendations
In light of the Code Spaces breach and other similar cloud related security incidents, there are several recommendations that industry experts encourage companies to implement. Specifically, there are three main ways companies can prevent a similar breach from happening to them: Multi-factor authentication, role-based access control, and segregating primary data from backup data (Marks, 2014).
With multi-factor authentication, logging in with a user account requires more than just a username and password combination. A second, or in some cases third, factor will be required before the login process can be completed. For example, the second factor can be a code emailed to the user, a code texted to the user, or even a code generated by a hard or soft token. The idea is that while a username/password combination may become compromised, it is less likely that a personal phone or email address will also become compromised. Utilizing multi-factor authentication will ensure that company data is protected, even if a username or password becomes compromised.
Role-based Access Control
Role-based access control is the assigning of permissions and access based on roles, rather than on a per person basis. The idea is to create individual roles for completing specific actions and assigned permissions based on the role. With a role-based approach, single administrator accounts with access to all permissions do not exist. Instead, the permissions are split across several accounts, each with their own specific role. Had Code Spaces not had a single administrator account with full access to all areas of their AWS infrastructure, the damage would have been limited. To this end, companies should have several accounts which each have a specific purpose, or role. For example, companies should create an account for provisioning new data storage and assign it to that specific set of permissions. They should then have a second account that they use for backups and recovery. They should not have a singular account that is given access to all roles.
Segregating Primary and Backup Data
Companies should take care to store their primary and backup data in different locations, on different media, and with different providers. Marks (2014) refers to this as the rule of 3-2-1, which requires three copies of any piece of data, on two different media with one offsite. In the case of Code Spaces, they had their entire production environment, primary data, and backup data all with the same service provider and all using the same administrative account. This meant that when the administrator account was compromised, the attacker had the ability to bring down the entire company. Had Code Spaces simply had a backup environment hosted by a secondary provider, they could have shut down their compromised AWS account, and rolled over to their backup environment and provider. All companies should learn from this mistake and take care not to repeat it.
It is critical that companies interested in leveraging cloud technologies should heed the lessons learned from the Code Spaces breach. Businesses should implement security measures such as multifactor authentication, role based access control, and segregation of data storage. It’s important to note that with cloud technology comes both benefits and risks. Preparing for and managing these risks will allow for the benefits to be realized (Goldsborough, 2013). In the case of Code Spaces, they did not conduct due diligence in preparing for the security risks posed by the cloud. They did not practice accountability, implement security best practices, or institute a strategic plan governing cloud usage. Unfortunately, the worst-case scenario occurred. Their cloud-hosted data was compromised and the entire company paid the price.
As the proliferation of cloud services continues, businesses should strive to utilize them in a manner that improves organizational effectiveness; yet they must also remain vigilant and consider the risks posed by emerging technologies. Just as data drives business in today’s economy, it can also bring about its demise.
Ardagna, C.A., Asal, R., Damiani, E. and Quang Hieu, V. (2015). From Security to Assurance in the Cloud: A Survey. ACM Computing Surveys, 48(1), 2-2-50. doi:10.1145/2767005
Constantin, L. (2014, June 19). Hacker puts 'full redundancy' code-hosting firm out of business. Retrieved May 07, 2017, from http://www.pcworld.com/article/2365602/hacker-puts full-redundancy-codehosting-firm-out-of-business.html
Goldsborough, R. (2013). How Sound is the Cloud?. Teacher Librarian, 40(3), 68.
Gordon, J. (2016). Like a Bad Neighbor, Hackers Are There: The Need for Data Security Legislation And Cyber Insurance In Light Of Increasing FTC Enforcement Actions. Brooklyn Journal Of Corporate, Financial & Commercial Law, 11(1), 183-208..
Jamsa, K. (2013). Cloud Computing Saas, PaaS, Virtualization, Business Models, Mobile, Security, and More. New York: Jones & Bartlett learning.
Laudon, K. C., and Laudon, J. P. (2016). Management information systems: Managing the digitalfirm. Upper Saddle River, NJ: Prentice Hall.
Marks, Howard. (2014). Code Spaces: A Lesson In Cloud Backup. Retrieved May 07, 2017, from http://www.networkcomputing.com/cloud-infrastructure/code-spaces-lesson-cloud-backup/314805651
Rittle, J., Czerwinski, J., and Sullivan, M. (2016). Auditing The Cloud. Internal Auditor, 73(4),43-48.