Information Security: The Case Study of Turn Key University (TKU)

Executive Summary

This report presents a case analysis of Turn Key University (TKU) with respect to information security. It covers the nature of information handled by the university, the threats and protections in place, conformance to the APP guidelines and a critique of the case-given recommendations. The report was written in line with the SDLC waterfall model highlighting system requirements, system design, implementation, testing and maintenance, augmenting each part with the assignment prompt. Under system requirements, it was established that the report aimed to draw lessons from the TKU case scenario and highlight the essence of information security in educational contexts. The types of information handled by the institution under system design were identified as personal information, financial information and system information. On the other hand, threats included abuse by system users, unauthorized access, systemic chaos and external threats of hackers. Protective systems entailed the use of authorized access and logging features, both of which were insufficient. With respect to APP, it was apparent that guidelines of information collection and security were flouted, with the institution falling short on multiple provisions. In the end, though the case proposes plausible recommendations on people, process and technology, narrower and accountable user access controls were needed. There was also need to use advanced access features like Biometrics and facial recognition to invalidate password sharing and general unauthorized access.

Introduction

            Information security and privacy concerns have gained traction in Information Systems (IS) curricular in the present day due to the aggravated and mutating nature of breaches and security threats. In any information management context, security issues are a prime concern and necessitate the presence of appropriate counter measures and policies that ensure privacy is upheld. While many organizations have been quick to embrace technology and make the best use of it, there has been little effort to take note of security threats and develop systematic methods of countering them (Ayyagari & Tyks, 2012). There has instead been a proliferation of passive protection behavior, with users assuming that information security threats are overrated or they are somehow immune to them. This has often resulted in major breaches, which come at both fiscal and socio-cultural costs in organizations. Loss of trust, litigation and paranoia has resulted from failure to institute and adhere to security guidelines and principles. This has been profound in educational contexts, given that academia thrives on the principle of information sharing rather than confidentiality and privacy. Nevertheless, educational contexts have various sensitive sets of information which calls for unprecedented and extraordinary security measures (Stair & Reynolds, 2013). These include Personal Identifiable Information (PII) among others that could interest malevolent persons in the cyberspace. Therefore, there are integral security issues that should be considered even in educational settings to guarantee integrity and safety of information.

            This report shall present a case study analysis of Turn Key University (TKU) where a number of information security issues were evident. The case previews a number of general information security issues as well as the curious case of educational settings that has been introduced thus far. Apart from showing that indeed educational settings have major information security issues to take care of, it analyzes solutions and proposes further mitigates. The report shall include the different types of information that was collected, stored and used by TKU, the threats to the information that are evident from the case, the protections that were in place and more importantly, conformance of the case scenario to the Australian Privacy Principles (APP). A critical analysis of the recommendations of the case is also presented. The report shall be written in line with the Software Development Life Cycle (SDLC) model, integrating all assignment requirements.

Outline of the SDLC model

            The SDLC model has many different variations designed to meet unique needs of software developers. In this case, the model shall be adapted for report writing and in particular, the Waterfall model shall be the choice for the report design. It has six important steps namely requirements analysis, system design, implementation, testing, deployment and maintenance (Gupta & Laxmi, 2015). Requirements analysis is the first step where the uses of the system to be in place, why it is needed and how it will be used is put in place. In this stage, the problem to be resolved by the system is often set out clear and the needs of the solution also delineated. For the report, this stage shall include the significance of the report and its scope. The second stage of the SDLC process in the waterfall model is the system design where the software design and system specifications are issued out (Gottipalla et al., 2013). In the report, this shall cover the information related issues that were at TKU. This is basically the assignment prompt the different kinds of information collected, stored and used by the University. The implementation stage in software systems often covers the coding of the software, but in the report shall represent the threats to the information and the protections in place as provided for in the assignment prompt. The next stage shall be testing, whereby the report shall analyze the TKU scenario with respect to APP guidelines. The latter shall act as a “test” for the information security practices at the university. The final process shall be maintenance, which normally covers resolving emergent problems from the deployed software. In the report, it shall address the assignment prompt on the critique of recommendations issued in the case. The deployment stage shall not be included in the model due to lack of an augmenting assignment prompt for the same. In software development scenario, it often entails the putting of the software into use, and such is made as a presumption in this report- that the recommendations in the case scenario were acted on by the TKU management (Sharma & Misra, 2017). A glimpse of the model is shown in fig 1 below:

Fig 1: The SDLC model (Source: Yadav & Yadav, 2014)

Requirements Analysis

            As explained earlier, this is the first stage of the SDLC model and shall encompass the significance, purpose and scope of the report. In other words, it identifies the problems that shall be resolved through the analysis, justifies the solutions and gives the ingredients for the same.

            The purpose of the report is to derive lessons from the TKU case study. The case presents typical problems of information security in educational institutions and shall therefore cover the nature of information in such institutions, its uses and categories. In addition, it dawns the primacy of information security in educational contexts despite the maxim of information sharing that governs academia. This report shall be useful to all educational stakeholders and other organizations that deal in lots of user information. It not only exposes the threats faced but also previews the protections that can be leveraged on and their potential weaknesses. The scope of the report covers five of the six stages of the Waterfall SDLC model in sync with assignment instructions. This includes the nature of information handled at TKU, the threats and protections evident from the scenario and a critique of the recommendations given in the case study.

System Design

The system design typically features the specifications and the designation of the software to be in place to address identified problems. In this report, it shall address the assignment prompt on the nature of information handled by TKU and how it is categorized.

            There were different types of information that were collected by the TKU through their Transaction Management System (TMS). The first type of information which is also the backbone of the case is personal information. This encompasses the Personal Identifiable Information (PII) that was exported from the University’s system by the external contractor. PII in information systems refers to any type of information that on its own or in combination with other sets of data can be used to identify an individual, their location, contacts and so forth (Ayyagari & Tyks, 2012). The loss of this information is a major issue given that it can lead to criminal activity, undesirable targeting by marketers and more importantly, acts as a breach to personal privacy. This explains the chaos and subsequent financial compensation that had to be extended to the students following the loss of such information from the University’s servers. Their lives, privacy and safety had been compromised in the process. Another category of information that TKU dealt in was financial information. This encompasses data on meal plans and virtual dollars that were offered by the school as well as other transactions involving money such as purchases from vendors. Such information was also critical as it could be used to compromise the institution’s financial system and result in losses. Finally, there was system information which is basically technical data on the TMS tool (Ayyagari & Tyks, 2012). It ranges from passwords, the users of the system, the user groups formed by the administrators and the logs that were used for audit among others. This information was critical in the sense that it could be used to compromise the system, opening it up to hackers and other vulnerabilities.

System Implementation

This stage often covers the coding of the software or acquiring it from a vendor to address the problems identified from the outset (Fichman, Dos Santos, & Zheng, 2014). For the purposes of the report, it shall however outline the threats to the system that are identified and the protections that were in place at TKU.

There are several security threats evident from the TKU case scenario. First, there was the internal threat of system abuse by users within user groups. Notably, the TMS was unable to identify the specific users behind any actions that were in the system. They could only point to user groups which means that any actions of misuse or abuse could not be pointed out to their sources. Secondly, there was an evident threat of intrusion by unauthorized persons given that passwords were given casually and there were no clear guidelines for the same (Ayyagari & Tyks, 2012). It was noted that users issued passwords to temporary workers, over the internet and via text messaging which opened the possibility of the passwords falling into the wrong hands and thus allowing unauthorized persons to gain entry into the system. Therefore, there were two threats with respect to unauthorized persons, encompassing the casual issuance of passwords as well as their transmission in unsafe manner. Thirdly, there existed a threat of chaos in the system. There was no order in access, with numerous departments gaining entry for their respective functions and transferring administrative responsibilities in a disorderly manner. Individuals like Don inherited the system with no formal training and were handed critical responsibilities that they barely matched up to (Ayyagari & Tyks, 2012). This was a potential for chaos with various factions warring for control or unable to handle the system in the right manner. Finally, there was the external threat of hackers who employed tricks and skill sets in information technology to gain access to the TMS for malevolent reasons. This was due to the weak passwords used in the system and the failure to update them regularly. Further, usernames were easy to guess and predictable in their password combinations to the extent that those who sought unauthorized entry found an easy time. In general, there were thus four potent threats to the system. A summary of the threat is given in table 1 below:

Threat	Description
System abuse by users	The system could not narrow down to individual users in the system and could only identify the group that made access.
Unauthorized persons	Passwords were shared casually, transmission of passwords via unsafe means like text messaging.
Systemic Chaos	There were no clear authority and accountability mechanisms. Too many people had access.
External hackers	Passwords and usernames were easily predictable.

Table 1: Summary of threats in the system.

On the other hand, there were a few protective methods in place that worked to some extent. One of them was only allowing authorized access by creating user account and passwords for those that were allowed in. However, this method proved ineffectual in the end, as there were several orphan user accounts that could be used by hackers (Ayyagari & Tyks, 2012). Additionally, there were no strong passwords to the user accounts which meant that they could be easily breached by unauthorized persons. The second method was a bit better and entailed the logging feature where the user groups, time of action and the event performed could be traced. However, this was not effective as it could not point to actual users and therefore the exact sources of breach could not be figured out (Ayyagari & Tyks, 2012). However, at least it could flag off suspicious activity and narrow down audit to a manageable radius.

Testing

            This section typically covers the deployment of the software on trial to examine whether it has the ability to perform as desired (Willcocks, 2013). In this report, it analyzes the conduct of information security at TKU in relation to APP guidelines.

It is apparent that the conduct of the TKU was not in line with the APP guidelines of sensitive information collection. The guidelines highlight that collecting sensitive information is justified only if the persons involved are informed and consent to it and additionally, the information collected directly relates to provision of certain services or functions of the agency. This is highlighted in APP 3.3 (a) which goes:

“An APP entity must not collect sensitive information about an individual unless: (i) the individual consents to the collection of the information and:

(ii) If the entity is an agency—the information is reasonably necessary for, or directly related to, one or more of the entity’s functions or activities”

In this respect, it is abundantly clear that TKU did not inform the students about the collection of their private information though it was necessary for the management of the meals and other administrative functions. There is indeed no record of whether they offered consent in the release of their PII. There was thus justification of purpose but clearly no consent which invalidated the collection. The institution also falls short in the APP guidelines of security of personal information. The guidelines demand that there are practical steps to keep such information safe from unauthorized access or misuse, which they failed through the various weaknesses of their system. These safety requirements are given in APP 11.1 which goes:

“If an APP entity holds personal information, the entity must take such steps as are reasonable in the circumstances to protect the information:

• from misuse, interference and loss; and
• from unauthorized access, modification or disclosure.

It was clear that their culture did not encourage safety of sensitive personal information as was required in the APP. Misuse, interference and loss were both possible in the TMS while unauthorized access actually materialized.

Maintenance

            This is often the final stage of the waterfall SDLC model which entails taking note of defects and addressing them and the improvement of the same (Kazim, 2017). In the report, this part offers a critique of the recommendations given and suggests further corrective actions.

            The case study ends in plausible recommendations on people, process and technology. These three themes directly speak to the problems encountered in the TMS. There was no accountability mechanisms to be used by people or a sense of order. Equally, there were no processes in place to ensure security of information while the technology used to secure the system was also erratic. Thus, the recommendation that clear leadership structure be introduced with respect to security was correct as such would ensure there was order and accountability. Elsewhere, access control would cure the technological lapses such as weak passwords and predicable usernames, as well as detail structured processes of access (Ayyagari & Tyks, 2012). On its part, trainings and awareness would also address the chaos in the system and institute processes. The institution should consider complimenting these measures with a more specific and accountable access control with respect to individuals to ensure that every user could be identified personally and held accountable for their actions. This would also require a reduction in the number of persons with system access (Velmourougan et al., 2014). In addition, access should be more comprehensive utilizing facial recognition and biometric features to nullify the potency of shared or stolen passwords.

References

Ayyagari, R., & Tyks, J. (2012). Disaster at a university: A case study in information security. Journal of Information Technology Education, 11, 85-96.

Fichman, R. G., Dos Santos, B. L., & Zheng, Z. E. (2014). Digital innovation as a fundamental and powerful concept in the information Systems curriculum. MIS quarterly, 38(2).

Gottipalla, A. K., Desai, N. M. S., & Reddy, M. S. (2013). Software Development Life Cycle Processes with Secure. The International Journal of Scientific and Research Publications, 3, 1-3.

Gupta, R. S., & Laxmi, V. (2015). Software Development Life Cycle (SDLC) Implementationin Information Technology & Management. International Journal of Recent Advances in Information Technology & Management, 1(1).

Kazim, A. (2017). A Study of Software Development Life Cycle Process Models. International Journal of Advanced Research in Computer Science, 8(1).

Sharma, A., &  Misra, P. K. (2017). Aspects of Enhancing Security in Software Development Life Cycle. Advances in Computational Sciences and Technology, 10(2), 203-210.

Stair, R., & Reynolds, G. (2013). Principles of information systems. Cengage Learning.

Velmourougan, S., Dhavachelvan, P., Baskaran, R., & Ravikumar, B. (2014, August). Software development life cycle model to improve maintainability of software applications. In Advances in Computing and Communications (ICACC), 2014 Fourth International Conference on (pp. 270-273). IEEE.

Willcocks, L. (2013). Information management: the evaluation of information systems investments. Springer.

Yadav, H. B., & Yadav, D. K. (2014). A multistage model for defect prediction of software development life cycle using fuzzy logic. In Proceedings of the Third International Conference on Soft Computing for Problem Solving (pp. 661-671). Springer, New Delhi.