Design Process

In designing STAT, vital considerations are made regarding the most important aspects of the audit activity and forming the tool’s features around these considerations. Several architectural designs were considered including a distributed system that utilises client-server web service technology, and distributed systems using PHP. For each architectural design, the pros and cons were considered, including feasibility and capability to cope with the features of the tool. For example, the architectural pattern in web services technologies is lightweight. Distributed systems, create more cohesion and increase the degree of interdependence between modules. PHP is a server-side scripting language that is independent, multi-platform, and would allow the tool to be more coupled, which implies that the client will be more dependent upon the server-side. Thus, after thorough consideration and proof of concepts, it is decided for the tool to be implemented as a client-server web system that will be designed using PHP.

7.5 Architecture of STAT

In this section, the architecture of the tool is explained. STAT is a simple three-tier, web-based system that uses a client-server architecture. A three-tier architecture is an architecture pattern for developing web applications which work around three important layers, comprising a presentation layer, application layer and data layer (Conallen, 2002). Three-tier architecture is used to improve the modularity of the tool, and particularly allow for easy extension of features. Using client- server architecture, users can use any web browser to connect to the many services supported by the tool such as initiating audit assessments. On the server-side, the web server receives requests from the client, handles the request and generates an appropriate response to the client. The three- tier architecture role of three-tier architecture is explained as:

7.5.1 Presentation Layer

The presentation layer provides visualisation and dashboards that enable an organisation, security auditors and CSPs to interact with the tool, and enables the visualisation of audit information of various kinds such as assessment results, conformance level etc. It specifically provides the necessary user interface to enable auditors and CSPs’ access and use the tool using a standard browser. This layer is built using HTML, PHP and JavaScript, and it consists of web-browsers for HTTP clients that efficiently interact with the application and data layers using standardised protocols.

157

7.5.2 Application Layer

The application layer is built using PHP, and it essentially plays the role of linking together all the three layers by technically processing the various inputs and selections received at the presentation layer, and interacting with the vast database in the third layer. It houses the audit assessment module/platform, which specifically applies an algorithm to auditor’s assessment of CSPs to determine appropriate conformance level. It is also responsible for determining access rights of auditors, generating and managing access codes sent to CSPs. Also, the layer houses the web server, scripting language and the scripting language engine of the tool. The Web server enables the processing of HTTP requests for initiating the audit process, obtaining CSP responses and evidence. The application layer provides the technical deal with dynamic content and streamlines faster access of the database to extract results.

7.5.3 Database Layer

The database provides a centralised place where data captured in the tool are stored, manipulated, and accessed. The layer comprises database management systems (DBMS) and the database, which is built using MySQL. The rationale for the database layer is to centralise all data storage and retrieval duties concerning security audit, user profiles, authentication, audit history, etc. In other words, it contains the methods for accessing the underlying database data. Fundamentally, the database layer is responsible for storing numerous types of data the tool will take as an input, generate as output and other external services that the tool may use. The database is accessible to the system administrators and auditors. The high-level architecture for the tool is shown in Fig. 7.1.

Figure 7.1 Architecture of STAT

Presentation Layer

Administrative Dashboard Security Auditor Dashboard

CSP Dashboard

Application Layer

Database Layer

158

7.6 Features of STAT

A detailed overview of STAT features is provided in this section. The primary purpose is to provide a general understanding of how the tool is decomposed and how the individual components work together to provide the desired functionalities. Generally, the tool focuses on the evidence-based way of probing, assessing and reporting of findings relating to CSP conformity to requirements. The main features provided by the tool include three main dashboards consisting of essential functions that can be performed. Each functionality contains important components of a security audit. The three main features include administrative client; security auditor; CSP dashboards as shown in Fig. 8.2

Figure 8.2: Features and components of STAT 7.6.1 Administrative Dashboard

The purpose of this feature is to provide administrative and user management functions in terms of authentication and providing auditors and CSPs access to the STAT platform. The authentication module is designed using PHP with MySQL database, which serves as an integral part of security procedures. The primary user of this dashboard is the STAT administrator who creates user accounts for all authorised auditors and the CSP whose services are subject to assessment. The administrative dashboard also enables the auditor to manage logs and user activities in terms of reviewing auditor activities and CSP profile. Also, it allows the management of enquiry from the CSP who may have some questions, complaint, suggestion, and submission of requirements or checklist regarding the assessment. The system administrator can add, remove or edit the list of auditors that can use the tool, in addition to password recovery capabilities.

STAT Features 2. Auditor Dashboard 3. CSP Dashboard 1. Administrative Dashboard

User & access rights management .Logs Management Enquiry Management System Settings Audit Initialisation Perform Assessment Creation of audit Findings Recommendation of Remedial Actions Management of audit activities Answering Checklist Provision of Evidences Submission of Checklist/Evidences Acknowledgement of Remedial Actions Enquiry Prepare Audit checklist Define audit criteria Conformance level Corrective Detective Preventive Notification Management

159

Among other functions the administrative dashboard allows the auditor to maintain the overall system security, functionalities and definition of user access rights; create of user account; management of auditors assessment invitation to CSPs; control of audit platform; verification of CSP details and assessment invitation before being sent out by security auditors; notification services on completion of assessment, CSP response management, and acknowledgement of remedial plans by CSP.

7.6.2 Security Auditor Dashboard

Security Auditor Dashboard provides an auditor with the functionalities to perform a systematic assessment of CSPs conformity to requirements. It consists of many features that enable the auditor to establish requirements that will be audited, prepare security audit checklist, initiate the assessment process, gather and evaluate evidence from a CSP, establish and communicate the findings, and recommend remedial actions upon the completion of the assessment. Another important functionality provided by this feature is to enable an auditor to initiate the security audit by establishing contact with an inviting the CSP to commence the audit. This is achieved using an assessment invitation form that is embedded in the tool and managed by STAT administrator. The form consists of important details including the CSP’s name, the email address provided and the requirements that are being audited. This is followed by a request being sent to the CSP through a secure hyperlink and access credentials. The access credentials enable the CSP to log into STAT platform and access the checklist. In other words, the assessment invitation is automatically sent out to the CSP in a secure hyperlink that directly connects to the universal resource locator (URL) of the security audit checklist which comprises numerous questions prepared by the auditor

Essentially, the auditor dashboard provides an interactive page for access to the default checklist that is composed of a predefined set of questions derived from industry standards, which is stored in the STAT platform. The focus of the checklist is the requirements that will be audited, with each requirement consisting of standard properties such as control domain, control type, question, CSP/user response and the type of evidence supplied by the CSP. Moreover, an auditor can modify the default checklist by adding, deleting or changing the questions. This is particularly important in situations where the auditor has identified the need to improve the dynamicity of the checklist or adaptive to the business context of the organisation. In case of modification, changes to the checklist are saved, encoded and sent to the MySQL server for storing.

7.6.3 CSP Dashboard

This is the feature that enables CSPs to participate in the assessment routine. The goal is to provide the capabilities for a CSP to access STAT platform and take part in the audit process by responding to questions in the checklist. In other words, it allows the CSP to answer the checklist with a view of providing evidence and enabling the cloud auditor to assess responses and evidence

160

provided. Once the CSP acknowledged the audit invitation sent by STAT administrator, access permission is granted using credentials issued by the administrator. The checklist then appears as a form, covering the requirements that have been earlier defined by the auditor. The CSP then answers the set of questions relevant to each requirement using a dual-type checkbox that allows them to toggle between two choices – ‘Yes’ or ‘No’. Also, the evidence must be supplied by the CSP for every question that is answered with a “Yes” response. This is done by uploading and submitting documentary evidence that supports the CSPs’ assertion. Also, the dashboard allows the CSP to enquire the assessment or any other form of question they may have for the auditor. Lastly, audit findings and remedial actions recommended by the auditor are received by the CSP through this dashboard, who in return acknowledges and report back on the measures being taken to address the recommended actions.