This section describes the tool’s attributes that serve as essential considerations in the design of the tool for supporting critical functionalities. These include performance, security, reliability maintainability, portability and usability.
7.6.1 Performance
Performance is a crucial property of the tool. For the tool to run effectively, the HTML pages have to be able to update data on the database. The database, at a reasonable speed, must be able to supply requested pages to users. This is predicted to be highly processor-intensive and the database server must be deployed to keep up with all user requests.
7.6.2 Security
Security is one of the prime focuses of STAT, and as such, various aspects of security will be measures that will be implemented. From a basic security perspective, a combination of username and password are required to log into administrative and security auditor interface, while CSP interface is accessed using secure login details. Besides, STAT can hold data that represent generic information about the CSP’s security practices and services, excluding sensitive or private data. As mentioned earlier, each feature is tied directly or indirectly to a user dashboard. Therefore, STAT uses the definitive users’ access-rights to limit the scope of information or data accessible to each user. Each user is given a different feature-view to access data. To ensure adequate security, the implementation of STAT is designed to meet the following requirements: Each request to access CSP response and evidence must be authenticated to establish
that an auditor is authorised to access the material that is requested.
All communication between client interface that is accessed using a standard web browser and the server-side of STAT must be secured by a transport mechanism that offers confidentiality and integrity of data being exchanged.
7.7.3 Reliability
To ensure the reliability of the tool, a secondary backup database server will be implemented such that in case of a failure occurring to the primary server or incidents resulting to nonresponse, the secondary server will automatically start supporting the services. Also, a synchronisation mechanism will be used to ensure the synching of these two database servers. The possible solutions for synchronising these two databases include: establishing a full periodic backup for the entire database, or a trigger being created where all data on the main database are automatically copied to the secondary database.
7.6.4 Maintainability
The maintenance requirements of the tool should be very minimal because an initial configuration and implementation will be the only required system interaction. One area of user maintenance would be changed to administrative changes after the system is set up. Physical maintenance on
171
the tool’s database server may be required, and this would result in a temporary loss of data and connectivity. Upgrades to hardware and software are predicted to have little or no effect on the tool but could result in downtime.
7.6.5 Portability
The tool is highly portable because once configured in a server, and it can be entirely moved to another server. The coding and program portability are possible between kernel-recompiled Linux distribution and Microsoft servers. However, for all the tool to work efficiently, all components must be compiled from source.
7.6.6 Reusability
The tool is designed such that the code is written in open-source programming languages and the components can be reused without having reusability issues.
7.7 Summary
In this chapter, the design and overview of STAT are presented. STAT is a specially designed tool that serves the role of supporting organisations to seek, collect and assess evidence from CSPs to establish how requirements are being fulfilled. The chapter provided the general description of the tool and the programming languages used in its development, such as PHP, HTML5, CSS and MySQL databases. It also presented design considerations, including the tool’s architecture which is made up of three layers namely presentation, application and database layers. All these layers serve different roles. Also, the features of the tool are designed according to three crucial dashboards namely: administrative, security auditor and CSP dashboards. These dashboards provide numerous functionalities that are formed based on the audit activity in the proposed CSTF. Also, the workflow of the tool is presented, which illustrates how the tool is used from start to end, supported by screenshots of the dashboards for better illustration. Lastly, non- functional features that define the tool’s attributes such as performance, security, usability, etc. are also discussed.
172
CHAPTER EIGHT
Implementation and Validity of CSTF 8.1 Introduction
The CSTF presented in this research is a proposed solution that aims to address the many issues associated with security transparency and trust-related issues. Implementation is a principal activity and one of the most critical steps in the development process, especially for a framework of significant importance like CSTF. The implementation aims at rigorously providing clear-cut assessment for demonstrating the ability of the research to produce the desired effect (Straub et al., 2004). It also comprises a set of associated methodologies and techniques to provide the means to establish the value, quality and relevance of research, and in some cases, offers essential feedback as a basis for improvement (Boudreau et al., 2001). Some methods and techniques could be adopted such as action research, descriptive, and experimental methods.
8.1.1 Empirical Research Method
An empirical research method is chosen for the research. Empirical studies are increasingly becoming popular in information systems research (Runeson and Höst, 2009). It has proven to be an effective research method to collect relevant data for investigating a specific problem in information systems. Therefore, the case-study approach was employed to serve as the implementation approach for this research, whereby two companies were selected based on accessibility through the researcher’s contacts. A case-study approach is widely used in information systems research domain because it is useful for explanatory research projects, and serves as a basis for the development of well-structured research findings (Straub et al., 2004). The rationale behind employing a case-study is to obtain meaningful feedback regarding the validity and usefulness of CSTF as well as stakeholders view on the usefulness of STAT. Also, the author used questionnaires to collect feedback from stakeholders in the case-study contexts. Two sets of questionnaires were prepared to form the guiding principles for collecting data. In particular, the first questionnaire aims at collecting stakeholders’ perception and view about CSTF as a whole, while the second questionnaire is more specific to collecting stakeholder view about STAT in terms of its acceptability and validity to support security transparency. The questionnaires contain pre-formulated questions with defined response options. This consideration made the questionnaire highly relevant in obtaining feedback as the questions are clearly designed to help stakeholders express their view. Consequently, to efficiently collect feedback, it is imperative to develop the questionnaires using essential criteria that are formed according to established models for information systems adoption (Thong, 1999, Premkumar and Bhattacherjee, 2008). Specifically, these criteria are developed by considering Technology Acceptance Model (TAM) (Venkatesh et al., 2003) and Unified Theory of user Acceptance of Information Technology (UTAUT) proposed by Davis (Davis, 1989). The rationale behind these two models is that they are both widely used for assessing the organisation-level adoption of
173
various information systems products and services. Essentially, the criteria included ease of use/clarity, relevance, usefulness, flexibility and dynamics, compliance to security standards and best practices, trustworthiness (as shown in Appendix B and C).
8.1.2 Data Collection
At the initial stages of implementation, kick-off workshops were organised at each of the respective studied contexts. In each case, workshops were attended by senior management representatives and IT personnel with at least four years of working experience. The primary aim was to introduce the role of stakeholders in terms of the implementation exercises and feedback collection through the questionnaire. An overview of the process for CSTF and the essential features of STAT was introduced to help stakeholders develop an understanding of how the process/tool works, expected deliverables, procedures, and the methodology involved for data collection. Specifically, during the workshops, the process and implementation activities for CSTF were the focal point of presentation in case-study 1, whereas case-study 2 received more briefing on how to use STAT and its features.
Thus, a total of 35 printed versions of the questionnaires were distributed across the two organisations. The respondents were introduced to the aim of the project and how their feedbacks can contribute towards validating CSTF/STAT and the overall research findings. They were briefed about the criteria followed in formulating the questionnaire. Besides, the possible responses are designed to fit the purpose and can be indicated as either “I strongly agree”, “I agree”, “Not sure”, or “Disagree”.
Overall, a total of 31 questionnaires were returned by stakeholders from the two case-study contexts, implying a response rate of 88.5%. Table 8.1 provides a summary of the stakeholders that were involved and responses to the questionnaire within the studied case studies.
Table 8.1: Summary of Responses from researched case-studies.
Case-study Stakeholders that Participated Stakeholders that Responded
Senior Mgt. IT Personnel Senior Mgt. IT Personnel
Case-study 1 5 13 4 12 Case-study 2 2 15 2 13 Total 7 28 6 31 35 31 8.1.3 Chapter Outline
The chapter is divided into four parts. The first part presents the overall implementation of the proposed CSTF, including the presentation of how data was collected and analysed. The case study is used to evaluate the implementation of CSTF from the first activity of the process through the last. This means that all the activities and steps involved have been applied to the case-study context, and stakeholders’ feedback is collected for analysis using six important criteria. The second part covers the implementation of STAT in the context of case-study 2. It includes the
174
application of the tool, as well as the collection of data for evaluating its usability and acceptability from stakeholder’s perspective. The third part provides a comparison between this research and other related others found in the literature. The final part deals with the discussions on overall findings in respect to the implementation and validation of the proposed framework. Figure 8.1 shows an outline of the implementation approach for the proposed framework.
Figure 8.1: Evaluation Approach for the Proposed Framework Part 1: Study 1 - Implementation of CSTF Process
This section presents the implementation of CSTF process using case-study 1. By following the cloud transition process from the start to completion over some time, we were able to comprehensively apply most of the activities and steps within the CSTF’s process, as well as the opportunity to collect feedback towards evaluating its validity. Thus, a detailed description of the case-study is provided by firstly presenting background information and the existing system implementation, followed by the architecture for the migrated enterprise application. This is concluded by a practical demonstration of how the CSTF was achieved.