Thesis:
The added value of an operating system audit to an IT
General Controls audit
S.A.H. Cobelens MSc. 2174332 cobelens@gmail.com
September 6, 2013 Vrije Universiteit Amsterdam
Abstract
The threat of information leakage, financial misstatements or fraud from financial IT solutions is imminent. Accountancy firms have to trust on information coming from these systems and deal with a world where new cyber-attacks are daily news. Accountancy firms continuously develop their audit approach to mitigate (new) risks in a more effective and efficient way. Auditors are often unsure of whether to include a thorough operating system parameter check in their IT General Controls audit approach. This thesis explores the added value of an operating system parameter check to an ITGC audit. This is done by inspecting a best practice, testing it at three companies and creating a risk analyses per parameter category.
Acknowledgements
I would like to thank my thesis supervisor Rene Matthijsse for helping and guiding me through the whole thesis process. Besides that I would like to thank my colleagues for their import and thought on the subject. Last but not least I thank my family and friends for their support.
Table of contents Acknowledgements ...3 1. Introduction ...7 1.1 Introduction ...7 1.2 Research question ...8 1.3 Contribution ...8 1.3.1 Academic Relevance: ...8 1.3.2 Managerial Relevance:...8 1.4 Research design: ...9 1.5 Thesis structure ...9 2. Theoretical Background ... 10
2.1 A brief history of IT audits ... 10
2.2 IT General Controls ... 11
2.3 ITGC in the financial statement audit ... 12
2.4 The structure of IT General Controls ... 14
2.5 Auditing of the ITGCs ... 16
2.6 Information security ... 17
3. Hypotheses ... 24
3.1 Conceptual Framework ... 24
3.2 Hypotheses ... 25
3.3 Control Variables ... 26
4. Case study methodology ... 27
4.1 Research Methods ... 27
4.1.1 Observation ... 27
4.1.2 Preliminary information gathering ... 27
4.1.3 Theory formulation ... 28
4.1.4 Hypothesizing ... 28
4.1.5 Further scientific data collection ... 28
4.1.6 Data analysis and conclusion ... 29
4.2 Sample selection ... 29
5. Case study findings ... 30
5.1.1 Company A ... 30 5.1.2 Company B ... 30 5.1.3 Company C ... 30 5.2 Outcome ... 30 5.3 Analysis of results ... 32 5.3.1 Accounts ... 32 5.3.2 Audit policy ... 32
5.3.3 Detailed Security Auditing ... 33
5.3.4 Event log ... 33
5.3.5 Windows Firewall ... 34
5.3.6 Windows Update ... 34
5.3.7 User Account Control ... 35
5.3.8 User Rights ... 35
5.3.9 Security options ... 36
5.3.10 Terminal services ... 36
5.3.11 Internet Communication ... 37
5.3.12 Additional security settings ... 37
5.4 Other factors ... 38
5.4.1 Costs of the operating system parameter check ... 38
5.4.2 Type of operating system(s) in use ... 38
5.4.3 No extra comfort ... 38
5.4.4 Politics and time ... 39
6. Validation of hypotheses ... 40
6.4.1 WH1: An operating system parameter audit will only give comfort over the operating system layer ... 40
6.4.2 WH2: Operating system comfort is essential for reliance on application controls ... 40
7. Conclusions ... 41
8. Limitations and further research ... 43
References ... 44
List of tables and figures
Figure 1... 13 Figure 2... 15 Figure 3... 21
1. Introduction
1.1 IntroductionCompanies use a variety of software solutions for their financial administration. These financial software solutions (e.g. SAP, Oracle, PeopleSoft and Navision) have been implemented in thousands of companies worldwide. Software solutions often have a client-server architecture which means they can be reached within a network and are therefore likely to be a target for people with the wrong intentions (Albornoz Mulligan, 2007). The machines that run these financial software solutions need to be hardened in order to respond to the increasing amount of risks from the connected world. There are best practices available for the setup of the system environments and there are tools to check them.
The threat of information leakage, financial misstatements or fraud from financial IT solutions is imminent and it is a complex matter where there is no single control that mitigates all the risks. For example, users with broad privileges in a financial system can bypass controls like the 4-eyes principle to make unauthorized adjustments, database administrators can edit tables and change user information, and system administrators can get access to the database and the software. This shows that multiple levels of computer system security need to be taken into account for a company in order to be able to trust its businesses processes to such financial software. Its accountants need to obtain comfort about the completeness, accuracy and validity of the data coming from the system in order to do their work.
Accountancy firms, who sign off the financial statements, rely heavily on data coming from these systems and therefore need to be sure of the completeness, accuracy and validity of the data it generates. In order to gain this comfort an IT General Control (ITGC) audit is performed as part of the financial statement audit. This is an audit on all controls that apply to relevant system components, processes, and data of the IT environment (ISACA, 2013).
Accountancy firms continuously develop their audit approach to mitigate (new) risks in a more effective and efficient way. Auditors are often unsure of whether to include a thorough operating system parameter check in their ITGC audit approach. This thesis explores the added value of an operating system parameter check to an IT General Controls audit.
1.2 Research question
A company uses an operating system baseline security scan as part of their ITGC audit. This security scan checks the system settings of the operating systems against a best practice published by the Center for Internet Security (CIS). The outcome of the scan is an overview of the many system settings and their compliance against the best practice. Audit teams are often not aware what the added value of such a baseline scan is for their ITGC audit and when they can or should use it. What comfort does this security baseline scan give the IT auditor regarding the ITGCs and when should an auditor consider performing such a scan?
How does a baseline security scan on operating systems parameters add value to an ITGC audit?
In order to answer the research question, several sub questions have to be answered:
What is the place of operating system parameters in the IT General Control environment?
What kind of comfort and assurance can result from an operating system parameter baseline scan to the ITGC audit?
Under which conditions should an ITGC auditor consider using an operating system parameter baseline scan?
1.3 Contribution
1.3.1 Academic Relevance:
This research tries to add academic value to both topics making the choice for auditors more sound as whether to use an operating system baseline security scan for their IT General Control work. There exist a lot of best practices but not much academic literature is found regarding ITGCs and operating system security baselines.
1.3.2 Managerial Relevance:
A business unit tries to sell baseline scans as part of an IT audit (ITGC). Audit teams are sometimes unsure and are wondering what comfort they will get with a baseline scan and how it can make impact at the client. Several baseline scans have been done. It is important for IT audit
processes to understand what the most common and notable findings are and what is their impact is on the IT General Controls.
1.4 Research design:
This research intends to study the use of an operating system parameter baseline scan as part of an IT General Control audit, how the operating system parameters can be linked the IT General Control environment, what kind of comfort an auditor would get doing an operating system parameter audit and when it would be a viable audit approach. The link between the ITGC environment and the operating system parameters will first be determined by a literature study. Based on the outcome an operating system parameter check will designed and performed in a case study environment. Based on the theoretical background and results from the case study the impact to the ITGC audit will be determined and recommendation will be formulated and documented.
1.5 Thesis structure
The structure of this thesis can be broken down into three main parts. The first part consists of a general introduction concerning what will be researched as well as the theoretical foundations of the thesis. Furthermore all relevant literature concerning operating system parameters and ITGCs will be discussed.
The second part is about the methodological aspect of the thesis. In this section, a conceptual framework is constructed based on the research questions and literature review. Moreover, the methodology of this research is explained. This section will also elaborate on the design and execution of the case study.
Finally, the last part of this thesis will consist of the presentation of results, discussion of the results, limitations and future research and conclusion.
2. Theoretical Background
2.1 A brief history of IT audits
Over the course of the years businesses have become more and more dependent on information coming from IT systems. In the 60’s one of the first frauds using IT systems was detected at the Equity funding Corporation of America. Also in The Netherlands auditors became aware that information systems more and more became part of the business and therefore needed to be taken into account for the audit. This shift in thinking had a great impact on accountants and the financial statement audit. Accountants formed ideas about information systems, their place in the administrative organization and how to audit them. Some accountants started to specialize in the audit of information systems which meant the birth of the IT auditor.
When the 3270-terminal was released on the markets in the 70’s it allowed mutations to be entered real-time on the computer. This replaced the physical processes and controls that were used with the so called ponskaarten. Because now anyone could make mutations, the accountants had no comfort over the reliability of the information generated by the system. In order to
mitigate the risks associated to such information systems the segregation of duties principle and authorization matrixes were introduced.
In the 80’s the field of IT audits was further developed. Data centers and IT projects became a focus point for IT auditors. In 1988 the Dutch National Bank released a memorandum that stated that IT is an essential part of a business that supports its solvability and liquidity. This confirmed that the IT environment is essential for the financial statement audit.
The 90’s introduced the client/server architecture which replaced a lot of main frames and was adopted in many projects. Next to that new IT developments methodologies were developed based on the client/server architecture which promised more efficient projects with shorter durations. Because of an increase in computer systems and applications best practices like ITIL were developed to manage the new IT infrastructure.
The 00’s marked the introduction of further integration of IT with the business, development of best practices and continuously new challenges for the control of the IT
environment. New upcoming technologies and initiatives like Cloud-computing and Bring Your Own Device challenge management and auditors to find a way to implement these advances in a controlled manner (Comte, 2009).
2.2 IT General Controls
From the founding thoughts about administrative organizations it is said that proper internal controls need to be in place to ensure the reliability of information processed by
information systems (Starreveld, 2002). These controls can be divided into organization, logical and physical controls.
In accounting and auditing, internal control is defined as a process affected by an
organization's structure, work and authority flows, people and management information systems, designed to help the organization accomplish specific goals or objectives. It is a means by which an organization's resources are directed, monitored, and measured. It plays an important role in preventing and detecting fraud and protecting the organization's resources, both physical (e.g., machinery and property) and intangible (e.g., reputation or intellectual property such as trademarks) (COSO, 2013).
Because of the increasing reliability on IT systems, controls were developed and best practices formed to control the IT environment. Two control “frameworks” have been devised to assist both management and auditors in designing and assessing controls in computerized
environments. One is the Information Technology Control Guidelines (IT Guidelines), first published by the Canadian Institute of Chartered Accountants (CICA) in 1970 (in its 3rd edition in 2011). The other is the Control Objectives for Information and related Technology (COBiT) developed by the Information Systems Audit and Control Association (ISACA) (GFS, 2013).
IT controls are a subset of the internal controls of an organization. In literature (Jenkins, 1992) internal controls are often divided into
User controls; manual controls
Application controls; programmed controls
ITGC; general IT management controls
User controls are defined as manual internal controls. The goal of user controls is to generate
reliable information for the input into information systems, to take action based on information or signals from an information system and to control an information system in a proper manner. Manual elements in internal control may be less reliable than automated elements because they can be more easily bypassed, ignored, or overridden and they are also more prone to simple
errors and mistakes. Consistency of application of a manual control element cannot therefore be assumed.
Application controls can be defined as programmed controls in applications. The goal of
application controls is to create segregation of duties in applications and to ensure the reliability of the data.
IT general controls (ITGC) are controls that apply to all system components, processes, and
data for a given organization or information technology (IT) environment. The objectives of ITGCs are to ensure the proper development and implementation of applications, as well as the integrity of programs, data files, and computer operations (ITGC, 2013).
2.3 ITGC in the financial statement audit
Accountants need to be sure that the published financial statements are being prepared reliably. Also called Financial Statement Line Items (FSLI), they give an overview of the
financial figures and position of the organisation (Berger, 2003). The controls in the ITGC are an aid to mitigate IT risks that the company faces in the preparation of the financial statements. The IT risks need to be identified and appropriate controls need to be in place to mitigate these risk. IT risks can be divided into two types: IT-dependent and IT-specific risks (PwC Audit Guide, 2012). The ITGC mitigate the IT-dependent and IT-specific risks
IT-dependent risks are risks that directly stem from comfort that the ITGC should provide the organization. There are three types of IT dependent risk areas: Automated Control Integrity (ACI), Report Integrity (RI) and Access Integrity (AI). Access Integrity is the risk area about controls that can be bypassed to gain unauthorized access to systems and applications. Risks in the Automated Control Integrity area are risks coming from automated application and system functions that haven´t been properly tested and implemented. Report Integrity risks are the risks associated with the reliability of the system generated reports.
IT-specific risks are risks that are inherent to IT-systems such as hardware/software changes outside of the normal business processes. The primary risk areas Direct Data Access (DDA), Data Integrity (DI) and Applications Controls in Computer Operations (ACCO). Direct Data Access risks involve all the risks that can lead to unauthorised access to data, to the change of data and to the destruction of data. Data Integrity risks involve all the risks that can lead to
damaged or lost data. Applications Controls in Computer Operations risks involve errors in batch jobs or interfaces leading to incomplete or unreliable (financial) data.
Effective ITGCs ensure the continued effective operation of application and automated accounting procedures that depend on computer processes. ITGCs are also important when manual controls depend on application-generated information.
Figure 1
The figure above depicts how ITGCs link indirectly to the achievement of the financial statement assertions. Transaction level controls are control activities over the initiation,
recording, processing and reporting of transactions designed to operate at a level of precision that would prevent, or detect and correct on a timely basis, misstatements related to one or more relevant assertions for a FSLI/business process. Transaction level controls can be either detective or preventive in nature and they often include manual application, automated application or IT-dependent manual controls (PwC, 2013).
2.4 The structure of IT General Controls
Although there is no detailed control set for ITGCs the general areas are described. They are generally divided into the following domains:
Access to programs and data
Program Changes
Computer Operations
Program Development
IT Control Environment
Each domain has certain IT -dependent or IT-specific risks associated to it. We can map these risks to the IT-dependent or IT-specific risks.
Table 1
Domain Associated risks Type of risk
Access to Programs and Data
Application Access
Database/Data File Access
Operating System/Network Access
IT-dependent - Access
integrity
IT-specific - Direct data access
Program Changes Changes to Application Programs
Changes to Application Configurations
Changes to Operating System/Network
IT-dependent – Auto
control/ report integrity
IT-specific - Data integrity
Computer Operations Computer Operations IT-specific - Data integrity
IT-specific - Application
controls in computer operations
Program Development Program development IT-dependent – Auto
control/ report integrity
IT-specific - Data integrity
IT Control Environment Organizational IT-dependent – Auto
control/ report integrity The most common ITGC controls are:
Logical access controls over infrastructure, applications, and data.
System development life cycle controls.
Program change management controls.
System and data backup and recovery controls.
Computer operation controls. (ITGC, 2013)
Figure 2 shows the domains and associated controls.
IT General Controls
Systems Development
Computer
Operations Program Changes Access to programs and data IT Control Environment Application security administration Operating system security administration Network / connection security administration Application logical security Operating system logical security Network logical security Application powerful accounts Operating system powerful accounts Network powerful accounts Database administration
Direct data access via App/Network/ OS/Util. Specification and authorisation Constructing Testing Implementation Documenting and training Segregation of duties Report integrity Batch processing Interface processing Monitoring of computer processing Backups Computer centre operations Initiation, analysis and design Contructing Testing Data conversion Implementation Documentation and training Segregation of duties IT strategy IT organisation Risk management Figure 2 (PwC, 2013)
For an organization to be in control of their IT they need to identify the IT risks and implement a tailored ITGC control framework. A control framework exists of at least of risk, a control objective and a control activity. Control objectives are the "aim or purpose of specified
controls at the service organization which address the very risks that these controls are intended to effectively mitigate" (SSAE16, 2013). Control activities are the activities that occur within a
control (University of Washington, 2013).
Risk CONTROL Risk Risk Properties Key control ref. no. Control Activity Control Properties Control Objectives Operator / Owner Preventive/
Detective Evidence Freq.
Unauthorized access to the IT systems because of weak password policies
All passwords are based on a password policy based on best practices AM-1 An up-to-date password policy is available and applied to key applications
ICT manager Preventive Password
policies
Annual
In the example framework above the risk, control and control activity can be seen. In order to make the control more SMART an owner, type of control, evidence and frequency is added. A control framework can be used by internal and external auditors.
2.5 Auditing of the ITGCs
Accountancy firms have defined their own ITGC framework and audit these controls in an organisation. The IT auditor need to form an opinion about the ITGCs by testing these
controls. The auditor needs to design his audit activities based on the type of organization that is being audited so to be efficient and effective. Sufficient appropriate audit evidence needs to be obtained to be able to draw reasonable conclusions on which to base the auditor’s opinion.
Most of the auditor’s work in forming the auditor’s opinion consists of obtaining and evaluating audit evidence. Audit procedures to obtain audit evidence can include inspection, observation, confirmation, recalculation, reperformance, and analytical procedures, often in some
combination, in addition to inquiry. Reasonable assurance is obtained when the auditor has obtained sufficient appropriate audit evidence to reduce audit risk to an acceptably low level.
The sufficiency and appropriateness of audit evidence are interrelated. Sufficiency is the measure of the quantity of audit evidence. The quantity of audit evidence needed is affected by the auditor’s assessment of the risks of misstatement (the higher the assessed risks, the more audit evidence is likely to be required) and also by the quality of such audit evidence (the higher the quality, the less may be required).
Appropriateness is the measure of the quality of audit evidence; that is, its relevance and its reliability in providing support for the conclusions on which the auditor’s opinion is based. The reliability of evidence is influenced by its source and by its nature, and is dependent on the individual circumstances under which it is obtained (International Standards of Auditing, 2009).
2.6 Information security
The term ‘information security’ means protecting information and information systems from unauthorized access, use, disclosure, disruption, modification, or destruction in order to provide
Integrity, which means guarding against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity;
Confidentiality, which means preserving authorized restrictions on access and disclosure, including means for protecting personal privacy and proprietary information; and
Availability, which means ensuring timely and reliable access to and use of information.
Which is often depicted in the CIA triad as seen below (Cornell, 2013) .
Figure 3
In order to ensure the confidentiality, integrity and availability of information and information systems companies often implement an access management, change management, business continuity and risk management process.
Access to protected information must be restricted to people who are authorized to access the information. The foundation on which access control mechanisms are built start with
identification and authentication. Identification is an assertion of who someone is or what something is. Authentication is the act of verifying a claim of identity. Information security uses cryptography to transform usable information into a form that renders it unusable by anyone other than an authorized user; this process is called encryption.
Change management is a formal process for directing and controlling alterations to the information processing environment. This includes alterations to desktop computers, the network, servers and software. The objectives of change management are to reduce the risks posed by changes to the information processing environment and improve the stability and reliability of the processing environment as changes are made.
Business continuity is the mechanism by which an organization continues to operate its critical business units, during planned or unplanned disruptions that affect normal business operations, by invoking planned and managed procedures.
Risk management is the process of identifying vulnerabilities and threats to the information resources used by an organization in achieving business objectives, and deciding what countermeasures, if any, to take in reducing risk to an acceptable level, based on the value
of the information resource to the organization (CISA, 2006). These four processes are also part of the ITGC audit as described in paragraph 2.4 (Information security, 2013).
2.7 Operating System security
Businesses store their financial information on computer systems. These computer systems enable employees to access, modify and delete information. The operating system is the heart of the computer system that allows hardware and software applications to communicate with each other and share resources as can be seen in the multiple definitions of an operating system.
Software designed to control the hardware of a specific data-processing system in order to allow users and application programs to make use of it. (Answers, 2013)
The collection of software that directs a computer's operations, controlling and scheduling the execution of other programs, and managing storage, input/output, and communication
resources. (Dictionary, 2013)
An operating system (OS) is software, consisting of programs and data, which runs on computers and manages the computer hardware and provides common services for efficient execution of various application software. (Wikipedia, 2013)
For example consider a program that allows a user to enter her password. The operating system provides access to the disk device on which the program is stored, access to device memory to load the program so that it may be executed, the display device to show the user how to enter her password, and keyboard and mouse devices for the user to enter her password. Of course, there are now a multitude of such devices that can be used seamlessly, for the most part, thanks to the function of operating systems. The most used operating systems by businesses are Microsoft Windows and the different UNIX variants.
Ensuring the secure execution of all processes depends on the correct implementation of resource and scheduling mechanisms. First, any correct resource mechanism must provide
boundaries between its objects and ensure that its operations do not interfere with one another. For example, a file system must not allow a process request to access one file to overwrite the disk space allocated to another file. Also, file systems must ensure that one write operation is not impacted by the data being read or written in another operation. Second, scheduling mechanisms must ensure availability of resources to processes to prevent denial of service attacks. For
example, the algorithms applied by scheduling mechanisms must ensure that all processes are eventually scheduled for execution. These requirements are fundamental to operating system mechanisms.
A lot of people, or at least lots of email addresses, web sites, and network requests, want to share stuff that aim to circumvent operating system security mechanisms and cause computers to share additional, unexpected resources. The ease with which malware can be conveyed and the variety of ways that users and their processes may be tricked into running malware present modern operating system developers with significant challenges in ensuring the security of their system’s execution.
There’s an ongoing battle between operating system developers and hackers to secure and breach operating systems. The term “secure operating system” is both considered an ideal and an oxymoron. Systems that provide a high degree of assurance in enforcement have been called secure systems, or even more frequently “trusted” systems. However, it is also true that no system of modern complexity is completely secure. The difficulty of preventing errors in programming and the challenges of trying to remove such errors means that no system as complex as an operating system can be completely secure. (Jaeger, 2008)
Because an operating system plays such a vital role in an information system its security has a direct impact on applications and their data as can be seen in figure 3. All data that comes from outside the system needs to pass the operating system layer.
Figure 3
Operating system settings are highly customizable in order to be tailored to the needs of the user. This means that the user is also responsible for a secure implementation of configurable settings.
2.8 Operating System configuration for Windows Server 2008
Apart from the inherent design of the operating system the configuration of parameters also plays a role in the secureness of the operating system. There are many types of operating systems that can be configured in a variety of different ways. Researching all these operating systems would be too exhausting for this thesis. This research will therefore look at the settings for one of the most used operating systems for servers, Windows Server 2008 (Wikipedia, 2013). Windows Server 2008 was released by Microsoft on February 27, 2008. It is the successor to Windows Server 2003.
The Center for Internet Security (CIS) helps organizations improve their security
this is by publishing security configuration benchmarks for operating systems. The security configuration benchmark for Windows Server 2008 was released on September 30th, 2011 and
includes many parameter settings recommendations (CIS, 2011). Each recommendation contains a description, rationale, remediation, audit, default value and reference. For example for the
enforce password history control we see the following recommendation.
1.1.1 Enforce password history
Description This control defines the number of unique passwords a user must leverage before a previously used password can be reused. For all profiles, the recommended state for this setting is 24 or more passwords remembered.
Rationale Enforcing a sufficiently long password history will increase the efficacy of password-based authentication systems by reducing the opportunity for an attacker to leverage a known credential. For example, if an attacker compromises a given credential that is then expired, this control prevents the user from reusing that same compromised credential.
Remediation To establish the recommended configuration via GPO, set the following to the value prescribed above:
Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy\Enforce password history
Audit Navigate to the GPO articulated in the Remediation section and confirm it is set as prescribed.
Default Value 24 passwords remembered
References CCE-2237-6
There are more than a hundred recommendations like this for Windows Server 2008. This shows one of the complexities of securing the operating system. It is always a balance of security versus usability. All these settings can be broken down and ordered into the following categories or controls.
Category Settings
Accounts Password and account settings. These settings all
contribute to the logical access security.
Audit Policy Settings regarding the logging of events and changes to
the operating system. For example the logging of access attempts and changes to user rights and policies.
Detailed Security Auditing These are more specified auditing settings like the
logging of changes to the security state of the system, when a register object is accessed or whether the results of a validation test are logged
Event Log These settings are about the retention of the system
logging and some technical settings.
Windows Firewall Settings in this area are about the setup of the Windows
Firewall that is part of operating system.
Windows Update Settings regarding the installation and download of
User Account Control Settings regarding the behaviour of the operating system when operations are being performed that require elevated privileges
User Rights Defines which type of users can do certain types of
actions like logon, shutdown or change the system time.
Security Options Specific security settings fall in this category like
interactive logon, Microsoft network client, network access and system settings.
Terminal Services Remote desktop settings
Internet Communication Settings regarding the use of local resources over a
network connection like printing or publishing files.
Additional Security Settings Additional settings like disable remote desktop sharing,
turn of autoplay and registery policy processing.
Most of the categories would fall under the ITGC domain ‘Access to programs and data’ except for the Windows Update category which would fall under ‘Computer operations’.
2.9 Influence of operating system settings on the IT General Controls
As can be seen in previous paragraphs the operating system is only one of the parts that together can form a secure information system environment. Logically it protects the
applications, data and system resources but once a program or user is allowed access it cannot control the implications of that access. For example the operating system cannot control the behaviour of a user within an application or the content of data that is being send and received. Nevertheless it is an essential part of the security because it does protect data from external and internal threats in a way that applications cannot do.
There is not one setting that determines how secure an operating system is and therefor an auditor always has to look at combination of settings. Some settings can have a higher impact than others. Not being able to rely on the operating system for access to programs and data controls undermines the application controls. In practice most operating systems including Windows Server 2008 have a basic level of security configured which means that reliance on the operating system is not binary and can be partial.
Financial statement audits always have a time period in scope. In order for an auditor to get some comfort over the operating system settings for a certain period the changes to the settings need to be logged. Which means an auditor either has to rely on the change management process or has to inspect the event logs that the server generates (if this logging is enabled).
3. Hypotheses
3.1 Conceptual Framework
There are different operating systems and types of audits that need to be identified and researched. This research will only look at Microsoft Windows Server 2008 for the financial statement ITGC audit in order to keep focus. To visualize the research question and give a clear overview of which variables are involved and how they are interlinked, the research idea of this thesis can be visualized in a Conceptual Framework seen below.
Inherent Operating system security design Operating system parameters Operating system
comfort ITGC comfort
Operating system paramater configuration T0 T1 T3 T4
There are five main variables that can be distinguished in this framework. The Independent Variables Inherent operating system security design and Operating system
parameters, the Moderating Variables Operating system configurations, the Dependent
Variable Operating system comfort and the Dependent Variable ITGC comfort. The meaning of these variables will be explained next.
First, the independent variables Inherent operating system security design and Operating
system parameters stands for all the possible operating systems and there inherent security
different security design. A company has to think about this when they choose the operating system for their applications. Next to the inherent design they also have to make sure that the operating system is setup and configured according to their security needs
Secondly, Operating system configuration is the moderating variable in this framework. It entails the actual configuration of the operating system. This variable influences the dependent variables based on parameter configuration.
The forth variable Operating system comfort is one of the dependable variables in this framework. It entails the combination of security design and configuration leading to a level of comfort that can be placed on the operating system.
Finally, the dependent variable ITGC comfort is about the contribution of the Operating
system comfort to the IT General Controls audit. If an audit looks at application controls, Operating system comfort must be obtained.
3.2 Hypotheses
With the conceptual framework set up, specific working hypothesis can be set up to test the framework. Working hypotheses (WH) are a “provisional, working means of advancing investigation”; they lead to the discovery of other critical facts (Dewey, 1938). Working hypotheses are linked to exploratory studies (Shields, 2006). They are never proven but are supported by empirical evidence.
Building on the research questions the working hypothesis will explore the subject in more detail. Based on the literature background the following working hypothesis were created.
WH1: An operating system parameter audit will only give comfort over the operating system layer
As depicted in Figure 3 the operating system is the layer between applications, data and the network. Auditing the operating system parameters will therefor only give comfort over the implementation of information security on the OS layer.
WH2: Operating system comfort is essential for reliance on application controls Because the operating system manages system resources and data the systems needs to be secured in a way that minimizes the risk of unauthorized use of the system resources. Using an application, even in a client/server architecture, requires some form of operating system access and thus exposes the application and data to certain threats.
3.3 Control Variables
In order to answer the research question and the sub-questions the relationships between the main variables have to be tested. The formulated working hypotheses can then be, based on the results either be supported or not. However, it is possible that the results of this study are influenced by other variables that were not included in the framework. For this study it will be hard to exclude all the other variables that might influence the Dependent Variable ITGC comfort and thus influence the outcome of this study.
The Inherent Operating system security design is a variable that greatly influences the
Operating system comfort but is tricky to measure. As (Jaeger, 2008) argues that no operating
system of great complexity can be completely secure a feeling of its security can be obtained by looking at its history of secureness and design philosophy.
Although the methodology for performing an IT General Control audit tries to be as objective as possible there is still a lot of room for an auditor’s opinion and so called professional judgment. Companies are almost never 100% alike, technology develops fast and there are many variables that influence IT security, yet auditors often work on a tight time schedule with limited budget. Therefore an auditor has to form an opinion as best as possible and can only give
4. Case study methodology
4.1 Research Methods
The purpose of this research is to find out what the added value of an operating system audit is for the IT General Controls. In order to do this, this study tries to find out the theoretical place of an operating system in the IT General Control framework and audit methodology. Secondly, an operating system parameter audit is performed and the added value to the ITGC audit is discussed. The methodology used for exploring the hypothesizes is a case study.
This study uses the hypothetico-deductive method that according to (Sekaran, 1992) involves seven research steps: observation, preliminary information gathering, theory formulation, hypothesizing, further scientific data collection, data analysis and logically deducing conclusions from the results obtained.
4.1.1 Observation
By being a professional auditor for a big firm and studying IT-audit the researcher is aware of discussions and hot-topics in the field of IT-audit. The company the researcher works for has been using a tool the last couple of years to audit operating system parameters and the results of these settings are being sent back to audit teams. It was observed that auditors often do not know how to interpret the results and what the added value to the audit is. They noticed that it makes an impact at the client if they present the results but the exact meaning and impact for the ITGC audit as part of the financial statement audit is unclear. The researcher felt like this was an interesting area that lacked enough academic or pragmatic literature and needs to be clarified.
4.1.2 Preliminary information gathering
Preliminary information gathering is the search for information in order to build up the researchers understanding towards the area (Sekaran, 1992). In order to do so a research proposal was written. Google, work experience and the PwC audit guide were the basis for further
preliminary information gathering. The topics of financial statement audits, IT General Controls, auditing and operating systems were explored. Most concrete information was not found in academic literature but in white-papers and best-practices.
4.1.3 Theory formulation
The theory formulation is done by literature research and is necessary in order to get a good understanding of what is already known about the topic to save valuable time and make sure the wheel doesn’t get invented for the second time. Not only operating system and IT
General Control literature is relevant for the theory formulation but also related literature in order to develop a theoretical framework. The goal of this theoretical framework is to put the topic in perspective.
Most of the literature research was done via Google and Google Scholar which can search through many (academic) databases. Beside online literature research the researcher has access to internal audit methodology material from PwC, one of the four big accountancy and consulting firms, in the form of the PwC audit guide. This guide describes the companies audit methodology in order to deliver high quality audits.
4.1.4 Hypothesizing
From the theoretical framework educated guesses were made regarding the outcome of the research question. These working hypotheses are presented in chapter 3.2. They represent a tentative statement of a relationship between two variables that have yet to be empirically tested. This study will try to test these hypotheses and the empirical results will either hold and support the hypotheses or discard it.
4.1.5 Further scientific data collection
In order to test the hypotheses further scientific data has to be collected. In order to find out about the added value of an operating system audit this study will perform an operating system audit at three companies that uses Microsoft Windows Server 2008 as platform for their IT environment.
4.1.5.1 The operating system design
In order to get an understating of the inherent operating system security design, literature research is performed by looking at the builders design philosophy, responsiveness to security issues and global opinion.
4.1.5.2 The operating system parameters
Based on the CIS best practice a parameter scan will be performed at a company. The researcher will use his professional network to find three companies willing to do an operating system parameter scan.
The researcher will provide a script that companies need to run on their Windows Server 2008 Domain Controller. This script will check the parameters and output the results into a text (.txt) file. The results of this file be analyzed using a tool called Easy2Audit. Easy2Audit is a benchmarking website where you can upload the results of the script and it will generate a graphical representation of the results.
4.1.6 Data analysis and conclusion
After all the scans are performed the case information per company will be stated and the results will be evaluated. The research will make use of Easy2Audit’s benchmark tool to make a graphical representation of the results from whereon the researcher will further investigate. Next to that the parameters, baselines values and results will be put into a table.
For the baseline, the recommended settings for an enterprise domain controller are used because we are testing the enterprise domain controllers. The other recommended settings in the CIS baseline are for Special Security – Limited Function (SSLF) systems. The companies in our sample do not have a higher than average risk profile so it was chosen not to use the
recommended SSLF settings.
4.2 Sample selection
The samples used in the research are companies that run a Microsoft Windows office environment that is managed by Active Directory and the domain controllers run on Microsoft Windows Server 2008. Domain controllers distribute the companies IT policies and
configuration settings to all computers that are in the office network. This means that a domain controller is a key system in a network and needs to be secure. The configuration of the domain controller does not necessarily apply to the computers in the domain but it can indicate the level of thought that was given to security. If a domain controller is compromised a hacker has the potential to access all systems that are part of the Active Directory network.
5. Case study findings
Three Dutch companies participated in this study which are anonymized for privacy and security reasons. This study took place between January 2013 and June 2013. The system administrators first tested the scripts on their test environment before running them on the production. It took each administrator about an hour to test the scripts, run the scripts on the production environment and send the results.
5.1 Company profile 5.1.1 Company A
The first company is a medium sized company with about 500 employees active in the food industry. Their ERP system, SAP, is used primarily for sales, purchasing and finance. They run a Windows environment which is administrated by two domain controllers. There is no single sign-on so in order to login to SAP a separate username and password have to be used.
5.1.2 Company B
The second company is a small company operating in the gambling machine market. They use Exact for their enterprise resource planning and run a Windows environment.
5.1.3 Company C
Company C is a medium sized software company operating in the supply chain logistics industry. Their ERP system, SAP, is used primarily for sales and purchasing. They run a
Windows environment which is administrated by two domain controllers. There is no single sign-on so in order to login to SAP a separate username and password have to be used.
5.2 Outcome
Company A:
Company B:
Company C:
5.3 Analysis of results
In this paragraph, the results will be discussed that were obtained from the scans and the theoretical framework. First the parameter categories and their audit impact are discussed. Once the audit impact of the parameters is determined non-technical factors are discussed. A complete overview of the results can be found in chapter 5. Thereafter results aside from the Working Hypothesizes are presented.
5.3.1 Accounts
In the ITGC framework the account settings can be placed in the Access to programs and data domain and they directly influence the logical operating system security. They can also influence application and data access if there are no further mitigation controls defined.
Finding Impact Likelihood Risk
Decreased efficacy of the password based
authentication control
Unauthorized users get administrator access to the critical systems, their applications and data.
Unauthorized access to financial data and applications can lead to misstatement, fraud and can threaten the business continuity
Medium Medium. This control can
directly influence access to financial data and thus cause financial
misstatements
Our results show that none of the companies have implemented a secure password policy. In company C the password based authentication control is operating at a bare minimum without a minimum password length making it simple to guess or brute force attack the password.
5.3.2 Audit policy
In the ITGC framework the audit policy can be placed in the Computer operations domain under monitoring of computer processing. The event log is filled based on the audit policy. This can be classified as a detective control for inspection of (potential) problems
afterwards. As can be seen in the baseline CIS did not define any audit settings. This is because Windows Server 2008 comes with more detailed audit facilities that are preferred to the legacy audit facility.
Finding Impact Likelihood Risk
No audit trail available Not possible to determine
system and user changes to the system over a certain period. In case of a calamity this can make it more difficult to inspect the cause.
Medium Low. This is a detective
control that does not directly influence financial misstatement. It is merely a monitoring instrument.
The obtained results show that all three companies use the windows server 2008 audit facility in a different manner. This means that the companies have event logs available that can be used in case of a calamity.
5.3.3 Detailed Security Auditing
The detailed security auditing parameters are the detailed audit policies introduced in Windows Server 2008. In the ITGC framework the detailed security auditing policy can be placed in the Computer operations domain under monitoring of computer processing. Its use and impact on the ITGC audit is similar as the audit policy described in paragraph 6.2.2.
5.3.4 Event log
With the event log parameters the size of the logs and thus the retention of events is determined. This would, just as category 6.2.2 and 6.2.3 fall under the monitoring control category as part of the computer operations domain. Its use and impact on the ITGC audit is similar as the audit policy described in paragraph 6.2.2. The event log settings in combination with the audit policy and/or the detailed security auditing together determine the impact for the monitoring control called the audit trail.
5.3.5 Windows Firewall
The windows firewall controls the incoming and outgoing connections and is thus part of the access to programs and data domain. Companies often have a dedicated firewall controlling all the network traffic. This often results in a de-activated Windows Firewall which can be seen in the results where none of the companies have any firewall rules determined. An auditor should establish that the client uses a dedicated firewall. If this is not the case then the whole network is open for the outside world and that alone would pose a serious security hazard. The risk analyses done for this category assumes a dedicated firewall.
Finding Impact Likelihood Risk
No firewall settings configured.
Administrators can overwrite Group policy settings that exposes the system to remote attacks. However, in case of a dedicated firewall this might have no impact
Low. Low. All network activity
is controlled by a dedicated firewall.
5.3.6 Windows Update
The windows update parameters define how Windows handles available updates. This would fall under the Access to programs and data domain since ensuring that the latest updates and patches are installed minimizes the potential of a successful hack through a known
vulnerability. However, the settings alone do not tell anything about the patch level of the server and thus not much can be said about the patch level of the machine.
Finding Impact Likelihood Risk
Windows update settings do not enforce the positive behavior of installing updates
No impact. Low. Low. These settings do no
tell anything about the patch level of a machine but can indicate a non-adequate patch management process.
5.3.7 User Account Control
User Account Control aims to improve the security of Microsoft Windows by limiting application software to standard user privileges until an administrator authorizes an increase of elevation. This would ensure that malicious software would not be able to perform administrative tasks on the operating system. This control would fit under operating system security in the Access to programs and data domain.
Finding Impact Likelihood Risk
UAC is not enabled Software uses
administrator operating system functions to perform malicious actions.
Medium Medium. Once a system
is infected with malware it might perform malicious actions that impact the integrity of the system
In the results we can see that all companies have UAC enabled in some manner. Company C has implemented in the most secure way so that even admin approval is required for admin accounts.
5.3.8 User Rights
The user rights parameters would also fall under the Access to programs and data domain. They manage which users and/or user groups can perform certain high risk or administrative functions. It also impacts some of the system security design functions.
Finding Impact Likelihood Risk
User rights are not setup based on the least authorizations principle
Unexpected users can perform high risk or administrative functions which can compromise the systems availability and integrity
Medium Medium. The attack
surface is increased unnecessarily.
In the results we can see that all three companies have defined and limited most user rights to appropriate users or groups.
5.3.9 Security options
The security options parameters are a set of security options influencing various functionalities like accounts, devices, domain membership, logon, Microsoft network client, network and system. Operating system security administration is the ITGC topic that this would be placed in.
Finding Impact Likelihood Risk
Security options do not adhere to the best practice
Attackers could potentially benefit from the security mis-configuration
compromising the system.
Low Medium. The security
options are not configured tightly which increases the chance of a successful attack.
The companies have set about 60% percent of the security options according to best practice.
5.3.10 Terminal services
With terminal service, users can login to a server from a remote location. The parameters deal with encryption, the password mechanism and drive redirection. In the ITGC framework we can find these settings under operating system logical security.
Finding Impact Likelihood Risk
The terminal service connection is more vulnerable to eaves dropping because of the lower level of encryption.
Attackers can potentially access remote servers via a locally saved terminal service shortcut.
Unauthorized access to the server through terminal services.
Medium High. Unauthorized
access through terminal services makes it easy for an attacker to compromise the system.
The results default values apply for all except company B, who disabled drive allocations.
5.3.11 Internet Communication
The best practice recommends to disable all unnecessary internet options that come with Windows Server 2008 for hardening purposes. Operating system security administration in Access to programs and data would be the ITGC domain this relates to.
Finding Impact Likelihood Risk
Unnecessary internet options enabled
Increased exposure to malicious content, unstable drivers and potential loss of information.
Medium Medium. The system has
unnecessary functions enabled that can disrupt the system and lead to information leakage when an administrators is not careful.
None of the companies have changed any of the default values leaving these options enabled, thus unnecessarily increasing their risk.
5.3.12 Additional security settings
The additional security settings are settings that can further harden the system. The difference with the security options is that the security options can have multiple possible values and the additional security settings are more binary. Only three out of the 11 settings have to be set according to the best practice which relate to operating system security and logical access in the Access to programs and data domain.
Finding Impact Likelihood Risk
Additional security settings not configured
Increased number of options that an attacker can benefit from to compromise the system
Low Medium. The options that
are not set according to the best practice can be key for an attacker to compromise the system.
None of the companies have changed any of the default values leaving these options enabled, thus unnecessarily increasing their risk.
5.4 Other factors
Aside from the value of the parameter audit there many other factors that can influence whether an auditor should use an operating system parameter scan. These factors are drawn from the researchers audit experience.
5.4.1 Costs of the operating system parameter check
Most audits are performed for an agreed upon fee and thus have a limited budget.
Although an operating system parameter check is no rocket science it will take an auditor at least a couple hours to perform. There are many cases, especially when small companies are audit which often have a very tight budget, where a couple hours is already quite an expense on the budget. This means that an auditor will have to decide how to spend his hours most effectively in order to gain the most comfort.
5.4.2 Type of operating system(s) in use
Although there are baselines for the most common operating systems it is possible that a company uses a legacy or customized operating system. In these cases it will be a time
consuming task to get any comfort about that operating system and comfort needs to be obtained in a different manner.
5.4.3 No extra comfort
There could be situations where testing the operating system parameters would lead to no extra comfort. For example when a server or computers are not connected to an external
network. When it is known that the ITGC audit will lead to limited or no-comfort the additional comfort obtained by performing an operating system audit will be minimal.
5.4.4 Politics and time
Companies can be reluctant to perform scripts from third-parties, such as the auditor, because they fear it can disrupt the system. In these cases the scripts will need to go through a test procedure before they can be ran on a production environment. This can take quite some time depending on the company’s organization as it has to go through (multiple) steps of approval. This might influence the usability of an operating system parameter audit because of the time factor. Some companies might outright refuse to run a script on their server which means the auditor will have to inspect the settings himself or find some other way to obtain them, probably increasing the time-spend and thus the costs.
6. Validation of hypotheses In this chapter the working hypotheses are discussed.
6.4.1 WH1: An operating system parameter audit will only give comfort over the operating system layer
As noted in paragraph 6.2 the parameters influence the access to programs and data and
computer operations ITGC domains. Within these domains operating system security, operating system logical security, operating system powerful accounts, network powerful accounts, direct data access and network logical security are influenced. Because the operating system is the
heart of a system it is logical that all these categories are influenced. The results obtained from the operating system audit give all the information needed to formulate an opinion regarding the operating system layer. However the information can also tell the auditor something regarding the security policy of the company, the manner of hardening they applied and their user account policy. The results support the working hypotheses in the sense that it will only give comfort about the operating system layer. It does however give an auditor additional information that might influence his audit approach and opinion.
6.4.2 WH2: Operating system comfort is essential for reliance on application controls
There are many settings that an attacker can use to eventually compromise a system. Once access, or worse, administrator access is obtained an attacker can further penetrate the system directly accessing or modifying unprotected data. Secured data can also be stolen or attempts can be made to breach the security. User account data can be tried to log into
applications and if a company has single sign-on enabled access is immediately obtained. All this can lead to a bypass of application controls. Because of the layers in computer systems, comfort can only be obtained of a layer if the layers below are reliable. The literature and results support the working hypothesis that operating system comfort is essential for reliance on application controls.
7. Conclusions
The intention of this research was to determine the added value of an operating system audit to the IT General Controls audit by answering the research question ‘How does a baseline
security scan on operating system parameters add value to an ITGC audit?’. A literature study
provided the context and role of operating systems within the ITGCs. A best practice for Windows Server 2008 configuration settings was used to test three companies against this baseline. This led to (1) a risk analysis of the security categories and (2) insight into the company’s compliance and the link between the parameters. To answer the research question three sub questions have to be answered.
First of all, what is the place of operating system parameters in the IT General Control
environment? As can be seen in the analysis of results, chapter 5.3, all the parameters were
analysed and the results show that they can be linked with the access to programs and data and
computer operations ITGC domains. This demonstrates that they have a place in the IT General
Control framework and thus should be taken into account when performing an ITGC audit. Secondly, what kind of comfort and assurance can result from an operating system
parameter baseline scan to the ITGC audit? It was found that there are many parameters that an
attacker can leverage to compromise an operating system. Once access, or worse, administrator access is obtained an attacker can further penetrate the system directly accessing or modifying unprotected data. Secured data can also be stolen or attempts can be made to breach its security. User account data can be used to log into applications and if a company has single sign-on enabled access is immediately obtained. All of this can lead to a bypass of application controls. As discussed in the working hypotheses, an audit on operating system parameters only gives comfort over the operating system layer but this comfort is essential. When there is no comfort regarding the operating system layer the integrity, confidentiality and availability of the
information generated by the system cannot be fully relied upon. The results from an operating system parameter audit can also influence an audit approach and opinion because of the indirect information it can give about the company’s security policy.
Thirdly, under which conditions should an ITGC auditor consider using an operating
system parameter baseline scan? As shown, operating system security has a place within the
ITGC framework and is essential for relying on information generated by applications. An auditor should consider using and operating system parameter baseline scan when he judges that
there is a risk of unauthorised access to the systems. This can be done by looking a company’s IT environment, infrastructure, external connections, and other mitigating factors.
The answer to the research question ‘How does a baseline security scan on operating
system parameters add value to an ITGC audit?’ is found in the theory, case study results and
the above answers to the sub questions. This research shows that a baseline security scan on operating system parameters adds comfort to the IT General Controls when the auditor judges that there is a risk of unauthorized access to the system. It also argues that operating system comfort is necessary in order to rely on information generated by applications.
8. Limitations and further research
As mentioned before this study has several limitations. First of all no thorough study was performed regarding the operating system’s inherent security design. An unresolved security flaw could undermine the whole value of the parameter check. Also the researcher did not inspect all the operating system parameters individually and/or tested its workings. This research relies on the recommendations of the Center for Internet Security.
Secondly, this research only focusses on Windows Server 2008 and inspected its best practice. Therefor this research can say little about the other operating systems. Its usefulness, costs and time can vary depending on the OS’s security options and design.
Thirdly, as mentioned in paragraph 5.4, there a many factors that influence the
appropriateness and added value to an ITGC audit. These factors are not taken into account in this research and leave room for further research. If all these factors are researched this might lead to a more concrete framework on when to use an operating system audit.
Furthermore the role of the accountant and auditor is an ongoing discussion. Especially with the increasing risk of cyber-attacks their might be a shift in thinking and interpretation or adaptation of the financial statement assertions. This can influence the way the auditor has to take cyber security and business continuity into account.
Because systems are not stand-alone and are operating within an IT environment, an audit on operating systems as well as the other components in the infrastructure, e.g. the firewall, could potentially increase the value to the ITGCs. Further research could look at the added value of an infrastructure audit to the ITGCs.
References
Albornoz Mulligan, J. (2007). Best Practices: Server Operating System Security.
Answers. (2013). Retrieved from Answers: http://www.answers.com/topic/operating-system CIS. (2011). Security Configuration Benchmark For Microsoft Windows Server 2008. CIS. CIS. (2013). Center for Internet Security. Retrieved from http://CISsecurity.org
CISA. (2006). Review Manual.
Comte, L. (2009). IT audit en SOx. Retrieved from
http://www.vurore.nl/images/vurore/downloads/718_IT_audit_en_SOx_Le_Comte.pdf Cornell. (2013). Retrieved from http://www.law.cornell.edu/uscode/text/44/3542
COSO. (2013). Retrieved from
http://coso.org/documents/Internal%20Control-Integrated%20Framework.pdf
Dewey. (1938). Experience and Education, The Educational Forum, 1938-8098, Volume 50,
Issue 3, 1986, pp. 241 – 252.
Dictionary. (2013). Dictionary. Retrieved from Reference: http://dictionary.reference.com/browse/operating+system
GFS. (2013). Retrieved from
http://www.gfsconsulting.ca/sox/it-general-controls-and-it-application-controls-what-businesses-really-needs-to-know
Information security. (2013). Retrieved from Wikipedia:
http://en.wikipedia.org/wiki/Information_security#cite_note-1 International Standards of Auditing. (2009).
ISACA. (2013). Information System Audit and Control Association. Retrieved from https://www.isaca.org/
ITGC. (2013). Retrieved from Wikipedia: http://en.wikipedia.org/wiki/ITGC
Jaeger, T. (2008). Operating System Security. Morgan & Claypool. Jenkins, B. (1992). An Audit Approach to Computers.
PwC. (2013). PwC Audit Guide.
Sekaran, U. (1992). Research Methods for Business: A Skill Building Approach. New York, John
Wiley & Sons.
Shields, P. M. (2006). Intermidiate theory: The missing link to successful student scholarship.
Journal of Public Affairs Education, Vol, 12, No. 3 , pp. 313-334.
SSAE16. (2013). Retrieved from
http://www.ssae16.org/glossary/83-control-objectives--example-control-objectives-for-soc-1-ssae-16-reporting--ssae16org.html Starreveld. (2002). Bestuurlijke Informatieverzorging, Deel I, Algemene Grondslagen.
University of Washington. (2013). Retrieved from
http://f2.washington.edu/fm/fa/internal-controls
Wikipedia. (2013). Operating system. Retrieved from Wikipedia: http://en.wikipedia.org/wiki/Operating_system
Wikipedia. (2013). Usage share of operating systems. Retrieved from Wikipedia: http://en.wikipedia.org/wiki/Usage_share_of_operating_systems
