Ariane 5 Crash and Risks of Modern Cloud Applications Report (Assessment)

Introduction

Software plays a critical role in numerous areas nowadays, and its reliability and security are of pivotal importance due to the possible highly adverse consequences of its failure. This paper explains the causes of the Ariane 5 crash in 1996 (which was caused by outdated, poorly tested software) as an example of such consequences, and then investigates the safety concerns related to the cloud storage industry.

Ariane 5 Crash

Ariane 5, a rocket that was launched by the European Space Agency (ESA) on June 4, 1996, was self-destroyed nearly 40 seconds after the flight was initiated (“Ariane 5,” 1996). This happened at an altitude of approximately 3.7 km; the rocket changed its direction, veering from its intended path, broke up, and then exploded (“Ariane 5,” 1996). This happened due to the failure of the backup software Inertial Reference System (IRS), which by.05 seconds preceded the failure of the active IRS; after that, the rocket swerved severely; soon, the self-destruction sequence was correctly initiated so as to minimize the damage that the falling ship could have caused (“Ariane 5,” 1996).

This failure was caused by a bug in the software guiding the rocket (Gleick, 1996). An internal variable that was tied to the horizontal velocity of the ship exceeded the limit that could be processed by the software of the computer in the rocket’s backup IRS: an attempt to recode that variable from a 64-bit format into the format of 16 bits was made by the computer, and the resulting number was too large for the computer to handle (“Ariane 5,” 1996; Gleick, 1996). The active IRS failed nearly 50 milliseconds later because of the same error (“Ariane 5,” 1996).

Due to the failure of the IRSs, the ship could no longer gain appropriate guidance information, which made the failure of the mission inevitable (“Ariane 5,” 1996). More specifically, the work of the active IRS was shut down, and the IRS started transferring diagnostic information to the main computer of the launcher, instead of the flight data; this caused the main computer to make a considerable correction to the deviations from the intended attitude, although the deviations did not occur in reality (“Ariane 5,” 1996). The real change of attitude resulting from the erroneous correction led to the disintegration of the launcher because of the impact of aerodynamic forces; after that, an automatic initiation of self-destruction sequence occurred correctly because of the disintegration (“Ariane 5,” 1996).

On the basis of the analysis of the accident, several recommendations were made to avoid similar accidents in future flights (“Ariane 5,” 1996). For instance, it was advised that immediately after lift-off of a rocket, the IRS’s function of alignment should be turned off, and that, generally speaking, no software function should be running in the process of flight if it is not necessary; that any sensors such as the IRS should not be permitted to cease sending best effort data (i.e., sensors should not simply be shut down); or that additional backup capabilities should be designed whenever technically feasible (“Ariane 5,” 1996).

In addition, it was recommended that any equipment utilizing software should be tested more thoroughly, not in isolation, and should cover and be able to handle much more data (“Ariane 5,” 1996). When it comes to software security, it was learned that the main and the backup systems should be running different types of software, so that they would not fail for the same reason; that redundant safety systems should be implemented; that more extensive testing of the software should be carried out; and that formal mathematical models should be built by professional software developers for any software systems that may potentially have a critical impact on the outcome of an operation (Richardson & Thies, 2013). Also, it became evident that codes and programs from previous models should not simply be re-used without adaptation (Merkow & Raghavan, 2010).

Key Security Risks for Cloud Applications

According to Merkow and Raghavan (2010), research conducted by the Gartner Group identified seven main security risks associated with the use of cloud applications, and provided corresponding advice (pp. 157-158):

1. Privileged user access: providers of cloud applications have access to the information stored in the cloud, so their reliability should be checked thoroughly;
2. Regulatory compliance: providers of cloud applications sometimes refuse to be subjected to external security certifications and audits, which may be a warning sign of poor reliability of a provider;
3. Data location: it is often unknown where the data contained in the cloud is actually stored, even in which country; this may entail numerous risks (for instance, due to weak local legislation, etc.);
4. Data segregation: cloud providers should supply evidence that the schemes utilized for data encryption were created and tested by professionals (it should be noted that professional testing of software was apparently absent in the case of Ariane 5), so that data encryption accidents would not render the data unusable;
5. Recovery: it is pivotal to obtain information about what would happen to the data in case of disaster, whether it is replicated in several sites, and if it is possible to restore it completely if problems occur;
6. Investigative support: it is often nearly impossible to investigate illegal or improper activities in cloud services, so the only possible safe assumption is that in case of problems, requests about investigation will not be satisfied;
7. Long-term viability: it should be ensured that the data stored in cloud will remain available if the service provider becomes acquired, merged with another company, or goes bankrupt.

Simultaneously, Cisco focuses on five security risks related to cloud computing (Beckham, 2011):

1. Secure data transfer: all the data traveling between the client and the cloud should be transferred via a secure channel (URL should start with “https”), and ought to be encrypted utilizing industry standard protocols (e.g., IPsec);
2. Secure software interfaces: it is pivotal to ensure that the cloud provider employs highly secure software interfaces, and integrates security into its services;
3. Secure stored data: it is paramount that the data is well-encrypted when it is stored in the cloud or used from it;
4. User access control: because employees of the provider may access the data easily, the data’s sensitivity should be considered, and inquiries should be made about the level of access of the firm’s employees;
5. Data separation: virtual containers on the provider’s hardware are supplied for each of the customers of a cloud service. Therefore, it should be checked whether the compartmentalization is reliable so that other users would not gain access to one’s data.

On the whole, recommendations #1, 2, 3, and 5 by Cisco are, apparently, not covered in the Gartner Group’s report, whereas recommendation #4 by Cisco corresponds to the item #1 in the Gartner Group’s report (Beckham, 2011; Merkow & Raghavan, 2010).

Simultaneously, Network World describes five problems related to cloud use security (Brodkin, 2010):

1. Identity management problems in clouds: various clouds use different security tools, some of which may be not reliable;
2. Weak cloud standards: the legislation and security standards for clouds are at the stage of development; companies may have their own standards, but do not always comply even with them;
3. Secrecy: cloud providers often behave clandestinely when it comes to their security procedures, which should be a reason to mistrust them;
4. Access to data from anywhere is convenient, but also risky: malefactors may launch an attack on a cloud from anywhere;
5. It is often unknown where exactly the data is stored: while in some countries, the law requires that sensitive data is stored in the same country, this may be untrue in other countries.

Apparently, issues #2 and 5 identified by Network World correspond (at least partially) to the items #2 and 3 on the Gartner Group’s report, respectively, whereas problems #1, 3, and 4 explained by Network World are not covered in the previous two lists (Beckham, 2011; Brodkin, 2010; Merkow & Raghavan, 2010).

It is possible to hypothesize that the three lists partially vary because there are multiple perspectives on various security risks, and different parties (e.g., individual and corporate clients) might have varying beliefs about the most important threats. Also, it is difficult to create a comprehensive list, especially because new aspects might emerge every day, so different lists are likely to vary in at least several elements.

Conclusion

All in all, the Ariane 5 crash provides an example of the potentially disastrous consequences that the use of faulty, inappropriate or insecure software nowadays may have. This is true of many industries, e.g., aviation industry, where software failure may have disastrous, life-threatening results. Simultaneously, security risks for cloud applications could endanger the sensitive data of many clients, which could also lead to severe losses of resources, or to leaks of sensitive personal information. These examples make it evident that when dealing with software the failure of which may have adverse impacts, all parties should make their best effort to ensure that its use remains as safe as possible.

References

Ariane 5: Flight 501 failure: Report by the Inquiry Board. (1996). Web.

Beckham, J. (2011). The top 5 security risks of cloud computing [Blog post]. Web.

Brodkin, J. (2010). 5 problems with SaaS security: Security tops customer concerns on software-as-a-service.Network World. Web.

Gleick, J. (1996). Little bug, big bang.New York Times. Web.

Merkow, M. S., & Raghavan, L. (2010). Secure and resilient software development. Boca Raton, FL: CRC Press.

Richardson, T., & Thies, C. N. (2013). Secure software design. Burlington, MA: Jones & Bartlett Learning.