Security comparison of Windows, Linux, and Apple operating systems

Information Technology

Refuting the Claims That Windows-based systems are not as Secure

As Linux or Apple Mac systems

The evaluation of one operating systems' level of security relative to another is often evaluated from the number of patches completed in response to severity from the United States Computer Emergency Readiness Team (CERT) database, or from customers making it widely known there are security holes and shortcoming in new products (Buckler, 3). There are also the architectural analyses of the Microsoft Windows, Linux and Apple operating systems, each being evaluated in terms of their relative level of security and stability (Parnas, 112). In fact the truest answer to which operating system is the most secure is found in the combing of these factors and evaluating these operating systems across both empirical and theoretical analyses. While Microsoft Windows has a dominating market share of Worldwide PC Operating Systems Market Share as can be seen from Figure 1, analysis of security threats using the CERT database actually show Linux is gaining through rootkit attacks (Baliga, Iftode, Chen, 323)

Figure 1: Worldwide PC Operating Systems Market Share

Calendar Q4, 2007 to Q4, 2009

Source: http://marketshare.hitslink.com/operating-system-market-share.aspx?qprid=8&qptimeframe=Q&qpsp=35&qpnp=9&qpct=3&qpmr=5

The number and severity of attacks then is not dependent purely on the number of operating systems in use by a given software company or open source distribution. Instead the level and severity of security breaches to operating systems is more dependent on the design goals and architectural structure, both within the kernel and in each subsystem including those that enable integration to networks and the Internet via Transmission Control Protocol/Internet Protocol (TCP/IP) to be secure. Merely analyzing the number of entries for any given operating system or its version by severity on the United States Computer Emergency Readiness Team (CERT) database entries is an incomplete analysis. Using just severity metric in fact can lead to drastically inaccurate conclusions as the widely held belief that Linus is more scalable and secure than Windows when in fact it is being attacked this year with Rootkit-based approaches that have been around in variant forms for decades (Baliga, Iftode, Chen, 323). Analyzing CERT data is like looking in the rear-view mirror instead of looking through the windshield to drive. Looking instead at the inherent differences in Directory Support, Public Key Infrastructure (PKI), cryptography functions including integration with hardware, and Kerberos support being integrated or added on through ancillary code all need to be considered. In addition the role of IPSec and SSL tunneling over Virtual Private Network (VPN) lines also needs to be considered. As each of these approaches to security vary drastically in their configuration and use in organizations, there are implications at the operating system level for these functions as well. Given the rapid growth of remote and telecommuting workers in organizations, VPNs and the corresponding roles of IPSec and SSL in security is also included in this analysis. As more organizations seek to gain the cost advantages of Software-as-a-Service (SaaS) applications and the use of virtualization increases as a result, the role of server-based operating systems from Microsoft, Linux server distributions are analyzed as well. SaaS-based platforms are also commonly hosted on Amazon Web Services (AWS) or Google Web Services platforms, alleviating the need for virtualization of servers in organizations. The security issues surrounding virtualization however are so significant that any company that produces a server-based operating system needs to be cognizant of it and define a strategy of compliance and continual security improvement (Mattsson, 15). When all of the factors are taken into account, it is clear that the use of a single metric from CERT and its trending is not sufficient to claim one operating system more or less secure than another. A multifaceted approach is necessary starting with an assessment of operating systems design and structure including the definition of Operating Systems Security Design Variations

The integration of disparate, often completely incompatible systems at the byte-order level is happening with increasing frequency as organization seek to gain efficiency and performance advantages from their data. As a result of the onslaught of system integration brought on by Business process Management (BPM) and Business process Reengineering (BPR) efforts in organizations, significant security gaps at the operating system level have been found, especially in industrial and plant-based systems (Harmon, 44). This has led to organizations auditing the security of operating systems to the kernel and platform level (Parnas, 112). The results of this analysis indicate that kernels or the central coordination logic of an operating system has much more to do with security, and in fact can either significantly reduce or increase the level of security breaches one operating system has relative to another.

The Apple Macintosh, Linux and Microsoft Windows kernels and corresponding operating system structures are now analyzed from the standpoint of Directory Support, Public Key Infrastructure (PKI), cryptography functions including integration with hardware, Kerberos support, IPSec and SSL tunneling over Virtual Private Network (VPN) are all considered.

Apple OS X Kernel Analysis

Cognizant that security of the Apple OS X operating system would be more reliant on the level of cross-platform integration it could achieve relative to Apple's traditional focus on graphics and image processing (Stern, et.al.) this latest edition of an Apple kernel structure is shown in Figure 2.

Figure 2: The Apple Mac OS X Kernel Structure

Source: (Stern, et.al.)

Ironically the initial reports of lack of security within this kernel structure are not emanating from the BSD distribution used for integration or the Application Services layer responsible for coordination of Classic, Carbon, Cocoa and Java (JDK) and support for Java Virtual Machine (JVM). They are from one of the most tested areas of this operating systems' structure, and that is the JVM component and its coordination role across the myriad of web browsers available on the market today (Paul, Evans, 338). JVM code can be hacked through the use of scripting and annotation through impersonation (Fong, 138). This is a major security breach in the architecture itself. Despite the myth that Apple gets hacked the least because hackers are running on this platform and are brand-loyal to it (another misconception) the fact of the matter is that its architecture is easily penetrated through JVM impersonation and also through QuickTime hacks, a point made clear in the CERT database (Buckler, 3). Clearly one of Apple's design objectives with this operating system is the eventual introduction of Web Services that are transparent across all devices. Lack of transportability and ubiquity of single sign-on continues to be a major criticism of the Apple operating systems and parallel business models of systems, servers, operating systems, and their iTunes economic ecosystem. The issue is that these systems are not integrated with one another past the GUI level, a point made when the proprietary Digital Rights Management System (DRMS) of Apple's iTunes ecosystem is taken into account (Erber, et.al.). This philosophy pervades Apple's design mindset in this kernel as well, and opens up significant security liabilities as a result. As can be seen from Figure 2, the Mac OS X operating system does not take into account cryptography at the hard level, a management framework or support for virtualization and partitioning. This is consistent with the company's philosophy of hardware abstraction not being necessary due to the lack of parallel systems and process integration. This is also indicative of how Apple envisions Web Services progressing on this platform, namely, in all-Apple environments. As a result of these design decisions the QuickTime and Java components become the most at-risk areas of their platform. Unlike other kernels which are evaluated in this analysis, there is shared memory usage and directory support integrated across the entire memory allocation for the operating system. This by definition then is a cooperative multitasking environment, and JVMs can be created that impersonate threads through the operating system, causing a complete breach to the rootkit level (Baliga, Iftode, Chen, 323).

In conclusion it is apparent from analyzing the Apple OS X operating system kernel that at a systemic level, it is flawed from a security standpoint. The myths of hackers and those with the skills to penetrate these systems not choosing to due to their brand loyalty is not founded and in fact can be seen contrary through the availability of rootkit-based guidance online on how to hack into Apple systems and servers (Baliga, Iftode, Chen, 323). Second, the claims of Mac OS X not being hackable are false (Mansfield-Devine, 7) (Voss, Siegel, 10). What is established from this analysis is the fact that there is greater correlation of shortcomings in the operating system structure itself and reported security breaches in CERT and other databases when design criteria are not fully met or are based on assumptions regarding use that don't turn out to be accurate. JVM hacks into cooperative memory areas of an operating system can completely define authorization and user privileges, leading to impersonation of user accounts. Clearly the Mac OS X kernel is not designed with a heterogeneous, more integrated environment in mind and as a result of not hardening JVM, QuickTime and Application Services it is in fact one of the most vulnerable operating systems in this comparison.

Linux Kernel Analysis

Much has been written in praise of the Linux (Crandall, Wu, Chong, 359),

(Parnas, 112), (Baliga, Iftode, Chen, 323), and its use of preemptive multitasking memory architectures to manage process control, file management, device management, information maintenance and communications subsystems securely and effectively. The Linux modular design, lack of reliance on Remote Procedure Calls (RPC), and use of UNIX-based system administration all are often cited as factors in how it is significantly more secure than Microsoft Windows for example. Linux relies on a dedicated memory partition architecture more comparable to Microsoft Windows than UNIX and also has a specific API calls for each of the subsystems as well. The combination of modularity and preemptive multitasking through dedicated memory structures is also an architectural argument that Linux supporters site when defending the inherent security of this operating system. In fact the KDE and GNOME components of the operating system are monolithic, not modular in design and therefore pose a security risk from the standpoint of being accessible through the kernel. Figure 3, Linux Kernel Structure, provides a graphical representation.

Figure 3: Linux Kernel Structure

Source: (Jaeger, Edwards, Zhang, 7)

What is immediately apparent from analyzing the Linux kernel is that when you take into account its wide variation in interpretation between Linux distributions from Debian, Red Hat, MandrakeSoft and SUSE it is clear that coordination and collaboration to resolve severe security risks can be challenging. In fact the highly fragmented nature of the Linux kernel and the distributed ownership of it across all those companies who are offering unique distributions make response time to severe alerts (as defined by CERT's methodology) challenging. Further exacerbating this shared ownership of security on the Linux platform is the integration of only Crypto functions, IPSec, SSL Tunnel and firewall functions. All other functions critical for operating system security are in fact supported through 3rd party partners including Directory Support, PKI integration, Cryptography at the hardware level, Kerberos support and a security management framework. As a result of the Linux kernel structure and operating system infrastructure being so balkanized the days of risk associated with any attack and the response time to resolve them is significantly longer than any Microsoft operating system included in the analysis (Massel, et.al.). This is a function of the lack of concerted, focused collaboration on the part of companies who are creating and marketing Linux distributions. Unlike the Apple operating system and its QuickTime and Java Virtual Machine (JVM) security liabilities, Linux has more complex security threats. At the operating system, kernel and the threat of days of risk growing rapidly due to a lack of shared knowledge (despite the myth of the open source community being egalitarian) Linux has significant security vulnerabilities (Massel, et.al.).

Analysis and Recommendation/Conclusion

Based on the analysis of each operating system's structure, inherent design strengths and weaknesses with regard to security it is apparent that the design criteria for security vary significantly. For the Apple OS X operating system the entry points of QuickTime and JVMs has been well documented in the CERT database. Apple has been relatively fast to respond to these concerns and has yet to define a management framework which makes the operating system secure in heterogeneous integration use. The second operating system evaluated, Linux, has far more security vulnerabilities due to its lack of preemptive memory management and use of actual calls through a virtualization layer from the applications to the kernel. Compounding this is the variation in approach each distribution takes when completing an interpretation of the operating system. All of these factors add up to significant increases in days of risk when a security threat is found.

When all of these factors are taken into account from an operating system design perspective and then the CERT data is analyzed from the standpoint of days of risk exposure, it is clear Microsoft, while has the highest percentage of flaws with high severity also have the highest percentage of flaws fixed. Table 1: CERT Analysis provides an analysis High Severity Flaws based on Forrester Research methodology. The factors contributing to the lower scores for Linux include the lack of efficient collaboration across the open source community, exacerbated by the fact that each of the companies listed in the analysis have slight variations in how they have interpreted the Linux operating system.

TABLE 1: CERT Analysis

Platform

Number of Total Flaws

Number of High-Severity Flaws

(%) of flaws with High Severity

Number of Flaws Fixed

(%) of Flaws Fixed

Microsoft

86

67%

Red Hat (Linux)

56%

99.6%

Apple

65

47

72%

46

97.8%

Debian (Linux)

57%

96.2%

MandrakeSoft (Linux)

60%

99.0%

SUSE (Linux)

63%

97.7%

It is also evident from evaluating this data in the context of the operating system architectures that days of risk, over time, tends to correlate to the level of consistency and modularity of an operating system. Days of risk also are indicative of how effective the cross functional teams can quickly ascertain the root cause of the problem and respond with a patch or an update. Given the fact that Microsoft has the most complex of the operating system architectures, the level of internal coordination and collaboration to fixed fatal flaws shows that xecurity has become a strategic priority inside the company.