Research Paper on Operating System Security.

Reference Article 1st published in May 2015 doi: 10.1049/etr.2014.0035

ISSN 2056-4007 www.ietdl.org

Operating System Security

Paul Hopkins Cyber Security Practice, CGI, UK

Abstract This article focuses on the security of the operating system, a fundamental component of ICT that enables many different applications to be used in a variety of computing hardware. While, the original operating systems for large centralised computing focused their security efforts primarily on separating users, operating systems secur- ity has had to adapt to cater for a wider range of technology, such as desktop computers, smartphones and cloud platforms, and the different threats that have evolved as a consequence. This article examines some of the core security mechanisms that every operating system needs and the gradual evolution towards offering a more secure platform.

Introduction: What is the Operating System? All too frequently the words operating system conjure up thoughts of Microsoft Windows made popular as an operating system that enabled desktop computing. However, there have been, and still continue to be a large number of operating system types and versions in operation [1] for all sorts of devices. These devices range from those designed to work with mobile phones, tablets and games consoles of the consumer world, through to the servers/laptops, network routers and switches of the IT industry, as well as em- bedded devices and industrial controllers from indus- trial engineering. [Dependent upon the hardware architecture, the operating systems can be significantly different to the fuller versions that this paper uses to illustrate the key security mechanisms.]

In essence, the purpose of the operating system is to provide a layer above the hardware execution environ- ment, abstracting away low level details, such that it appropriately shares and enables access to the mul- tiple hardware components, such as processors, memory, USB devices, network cards, monitors and keyboards. It thus provides an environment in which multiple applications (ranging from advanced weather forecasting through to word processors, games and industrial control processes) can all be po- tentially executed and accessed by multiple users.

Operating systems have a history and timeline dating back to the development of the first computers in the early 50s, given that the users, then also needed a way to execute their applications or programs. Since that time operating systems have adapted to

Eng. Technol. Ref., pp. 1–8 doi: 10.1049/etr.2014.0035

take advantage of increases in speed and performance of hardware and communications. The changes either enable new functionality and applications or adapt to optimise the performance of certain hardware, such as in the case of telecommunications routers and switches that can have additional networking func- tions integrated into their operating system. So while the UNIX and Microsoft Windows family of operating systems have dominated the server and desktop envir- onment of the past 20 years, the security problems found, and subsequent solutions to these problems, have also found their way into a variety of operating systems for other hardware environments; ranging from mobile phones (e.g. Apple iOS, Android, Symbian), to embedded devices (e.g. WindowsCE, Integrity RTOS), to networking products (e.g. Cisco IOS, JunOS) [This article focuses on the most popular operating systems found in the IT industry. A collec- tion of known operating systems can be found at ref- erence [1]].

Changing Threats Having evolved from running on shared stand-alone computers to being highly optimised and networked computers it’s not surprising that operating systems have had to evolve their security to mitigate different threats.

30+ years ago, the shared stand-alone mainframes used by large organisations and universities faced threats from (predominately internal) users accessing data and computing ‘time’ that they were not entitled to.

20+ years ago, the range of applications and network connectivity that operating systems had to support

1 & The Institution of Engineering and Technology 2015

IET Engineering & Technology Reference Paul Hopkins

increased significantly. With increasing connectivity threats arose around the exchange of malicious files or network access to data by both internally connected users as well as an increasing community of curious ex- ternal individuals and groups of less altruistic ‘hackers’.

10+ years ago, the operating system was integrated into and became dependent upon the networks of often globally connected organisations. This integra- tion and dependence brought about attention and threats from serious criminals and activists who used the computing resources and network reach of the Internet to not only attack an increasing number of online applications for confidential data, but also to deny access to online services and applications.

Today, the potential threats that operating systems have to protect against have been extended still further.

† Miniaturisation has meant that the physical theft of small scale devices, such as smartphones/tablets (now containing potentially large quantities of sensitive data or as access tokens for online and physical services) needs to mitigated. † Increased availability of wireless networks has required devices to be ‘always connected’ to a variety of public networks and other devices, thus in- creasing the number of types and potential network attacks against the platform. † Operating systems (from different organisations) are increasingly deployed onto shared public computation and storage resources in cloud data centres, which brings with it concerns about protecting the data and availability of these services from attacks against the collocated operating systems and its hosting platform. † Increasingly, highly capable and advanced threats from governments and organised crime have become a concern of many organisations. With oper- ating systems having to develop mitigations (alongside other security controls) for advanced malware and the potential interception of communications between platforms and cloud data centres.

Why is it Hard to Secure? It’s not surprising given this evolving threat landscape that operating systems have had to change their se- curity models, and also not surprising that they have had significant challenges in responding.

One of the most significant changes was experienced 10+ years ago when Microsoft Windows [2], which

2 & The Institution of Engineering and Technology 2015

due to its ubiquity and market dominance, found itself opened up to a multitude of network based attacks as organisations moved many services and communications online using its operating system. The consequence of opening up this ‘network surface’ of the operating system to the internet was that the type and range of vulnerabilities (ranging from buffer overflows to denial of service) being dis- covered and exploited rapidly increased. That’s not to say other popular operating systems, such as UNIX did not find themselves similarly attacked and exploited [3]. However, Microsoft found itself having to significantly enhance the software development and assurance process by which it secured its operat- ing systems (and other software) [2].

Similarly, operating systems rely on and also provide for increasing connectivity to not just networks but also multiple peripherals either externally connected through interfaces, such as USB or with integral devices, such as graphics card. The software necessary to interface these devices (e.g. device drivers) network and peripheral devices may also operate in a privileged mode within the operating system, potentially acces- sing system resources, such as processor memory dir- ectly. For example, vulnerabilities within the USB device drivers within Linux [4] and Windows [5] have been found to enable an attacker to gain full control of the operating system, when armed with a ‘crafted’ USB device. While USB driver software tends to be an integral part of the operating system software, other software drivers for graphic and network devices are developed by the hardware manufacturer themselves, thus creating a challenge when integrating and ‘assuring’ that this software is free of similar vulnerabilities.

Over time, operating systems have also increased their functionality to take advantage of the high network connectivity and performance increases in hardware, which has in itself bought about some challenges. Firstly, this has meant that the operating systems have significantly increased in size and complexity. Hence examining the operating system software for vulnerabilities and security issues has become difficult and expensive (e.g. Windows XP has an estimated code base of 50 million lines of source code). Increases in complexity have also meant re-use of code and with it the propagation of vulnerabilities from one so believed trusted code base to another. A classic and a relatively recent example of this is the discovery of a previously known vulnerability in Linux, that allowed, a ‘local’ user to escalate privileges

Eng. Technol. Ref., pp. 1–8 doi: 10.1049/etr.2014.0035

IET Engineering & Technology Reference Operating System Security

(beyond their restricted user privileges to system privi- leges) also replicated within Android [6], with the re-use of that code base. Secondly, the operating system is expected to provide a rich environment for users where the user has control over the applications running within the operating system (e.g. just look at the multiple applications enabled for a desktop or smartphone to realise that users like personal choice and rich functionality). Hence the operating system has had to increasingly protect itself, its resources and all users from weaknesses (or malicious intent) in the applications that users want to use.

How are They Being Secured? So while there have been many security issues in oper- ating systems, there have also been a number of attempts to design, build and just generally strengthen an operating system’s security over the years. In add- ition to funding and developing operating systems, such as SELinux (which was made open source by NSA in 2000), governments have also attempted to provide standards and incentives for operating systems, with evaluation schemes, such as TCSEC [Trusted Computer System Evaluation Criteria (TCSEC).] and the Common Criteria [7] scheme.

In the 1980s the US government developed the TCSEC scheme with the aim of evaluating the trustworthiness of commercially available operating systems (applica- tions and networking products are also evaluated) and evaluated a number of operating systems against that scheme. Overtaking and extending this scheme in the 1990s a number of governments (UK, Canada, France, Germany and the Netherlands) devel- oped the Common Criteria scheme, with a wider variety and type of operating systems, such as Windows, HP-UX, AIX, Linux [8], evaluated against the more flexible ‘protection profiles’ that defined the threats and thus security goals of the operating system under evaluation.

The industry has also both developed dedicated high security operating systems (often aimed at the govern- ment market and thus had their products put through evaluation schemes) and also felt the need to improve its security, generally in response to increasing security threats and vulnerabilities discovery [2]. As previously highlighted, Microsoft, for example, needed to rapidly re-engineer its security and assurance approach for its Window operating systems to take account of the emerging security threats facing its products and the growing complexity and size of the code.

Eng. Technol. Ref., pp. 1–8 doi: 10.1049/etr.2014.0035

Similarly, the open source and academic communities have focused on developing either specific security features/extensions for an operating system or on developing a full secure operating system. While the more well-known initiatives, such as TrustedBSD [9] provide the full functionality needed of a desktop or server environment, others, such as seL4 [10] are highly assured minimal operating systems (microker- nels) that have been developed for mobile and em- bedded devices.

While the approach and focus of these different com- munities have been different, the central goals for a secure operating system have always been fairly consistent:

† Ensuring that the operating system can enforce the separation of users and access to resources, such as files, memory, I/O and processes through a defined policy. † Ensuring that execution is through a trusted execu- tion path, which is free from vulnerabilities and flaws that would reduce the effectiveness of that separation.

However, as operating systems have developed for mobile and embedded devices, it has become neces- sary to mitigate for other threats, such as securing the data on the device in the event of theft or loss, or validating that the software has not been tampered given physical access to the device. The following diagram (Fig. 1) and sections outline some of the key security features and how they mitigate the threats.

Key Security Features

Access control At the centre of all operating system security is the ability to enforce control over access to system resources and information, either to mitigate malicious actions or accidental damage by users. While control- ling access to confidential patient or financial files from multiple users on a shared system may seem like an obvious security feature, just as important is the need to prevent the inadvertent download of malware from within a browser from executing and installing unwanted spying software; as is the need to prevent a badly implemented application access- ing other users’ private data held within the memory as demonstrated recently by the Heartbleed vulnerability [11].

Access control lies at the heart of many operating systems, ensuring that legitimate users and processes

3 & The Institution of Engineering and Technology 2015

Fig. 1 Key threats and operating system security controls

IET Engineering & Technology Reference Paul Hopkins

are only allowed to access the resources that they are entitled to do so. Unfortunately, it’s not necessarily as simple as it may seem, as the examples above illus- trate. It is not just access by users to files we need to worry about, but also the need to control the access by processes or machines to resources that includes not just data files, but memory, peripherals, networks and so on.

Access is also a term that can be used to describe quite a number of operations; at the simplest it could be the ability to write to, read from or execute a file. This is the case within many commercial UNIX systems where ‘files’ represent all resources, such as memory, I/O and network connections. However, in other oper- ating systems (such as Microsoft Windows) the access operations are richer and include the capability to ‘delete’ or ‘take ownership’ of a data type (rather than just a file type), for example.

The fact that we need to store a range of permitted operations with a large number of users and with access to a large number resources, can cause prac- tical difficulties (having to store and check each time an individual user needs to access a particular resource that they have permission to). Hence a popular strat- egy is to either group users into groups (with defined group access permissions) or to store individ- ual lists of users and access permissions for each resource.

However, the principles that operating systems need to achieve in order to control access securely are well known (even if the practical implementation is more challenging). Firstly, they need to ensure that

4 & The Institution of Engineering and Technology 2015

they have a trusted mechanism for deciding and en- forcing the rights of the requesting process/user with the designated rights of the object (e.g. file), a capabil- ity often referred to as the reference monitor. Secondly, that enforcement capability needs to be free from tampering, modification and vulnerabilities, a concept often referred to within the operating system as the Trusted Computing Base. Finally, the path by which that enforcement happens also needs to also be trusted, such that there can be no oppor- tunity for malicious processes or users to interrupt that execution path, a concept known as the trusted path.

In reality, there are few operating systems that imple- ment these capabilities and concepts perfectly, al- though a number of the capabilities can be seen in many. For example, Microsoft Windows contains a se- curity reference monitor that mediates the requests for access to resources or files (including generating audit messages based on the operations attempted). In add- ition, it also provides a trusted and prioritised execu- tion path for the console logon (ctrl-alt-del) such that other installed applications (including malware) cannot intercept the password and user credentials. Similarly a number of UNIX versions, such as SELinux or TrustedBSD [9] have added support for a reference monitor as well as the capability for Mandatory Access Control (MAC). In the majority of our description so far, and probably in the experience of many readers, most ‘files’ are under the ownership of the user who can grant or deny access to others a scheme known as Discretionary Access Control. By contrast for many secure operating systems and those implementing a reference monitor it’s necessary to protect the files for a variety of other reasons, such as policy, using MAC. For example, the integrity of the files could be critical in which case modification of files needs to be avoided to stop them either being corrupted or misused by malware or a careless user. Similarly, on some systems despite a user being granted access to a file by another user (perhaps sharing the latest clas- sified intelligence) because that user does not have the necessary ‘security clearance’ and therefore privileges to view files of that sensitivity, an access policy needs to enforce that denial until such time as their clearance is enhanced or the file sensitivity is downgraded.

Building on the TrustedBSD [9] MAC framework the Apple iOS [12, 13] operating system has embedded the capability to limit the access to objects within its operating systems against a couple of policies for en- suring file integrity and also process (or application)

Eng. Technol. Ref., pp. 1–8 doi: 10.1049/etr.2014.0035

IET Engineering & Technology Reference Operating System Security

control. In the latter case, applications can only access other system resources for which they have been enabled. Thus, for example, if they are not allowed to access the Internet then this is enforced by the op- erating system, irrespective of the running application requests.

Network protection Today, many operating systems are deployed in highly networked environments, with communications es- sential for most users to access applications, data and communicate with each other. In the early devel- opment of operating systems just as the files were believed to be trustworthy from users, so too were the networks to which they were connected often connecting organisations on trusted or in-house net- works, rather than the highly mobile devices now con- necting over untrusted and public networks, such as the Internet. Hence operating systems have had to adapt to embed a number of security features into their systems to mitigate this including network en- cryption, firewalls and network access protection.

The connectivity of operating systems to the Internet also signalled the start of a rapid increase in reported vulnerabilities with many Internet facing ser- vices for UNIX and Windows Systems found to have either vulnerability in the services themselves or funda- mental flaws in the protocols used by the operating systems to move data around. In the former case, un- expected or malformed messages are used to overflow the memory and execute malicious instructions, as used by the Slammer worm [14] or simply access sen- sitive memory and return it to an attacker, as was the case in the recent high profile Heartbleed [11] vulner- ability. In the latter case, vulnerabilities were found in the implementation of network protocols themselves, such as in the classic TCP SYN flood attack [15] example, where constant requests to open a network connection on a system from an attacker without them subsequently closing that connection caused the operating systems to consume too many resources and stop communicating.

As a consequence of these threats many operating systems have built firewalls into their operating systems to reduce the ability of attackers to access net- works services and applications that they should not. As well as limit the number of external connections that can be made to only those that are trusted, espe- cially important with many operating systems outside of an organisational network and directly on the Internet. The Internet Storm Centre [16] has

Eng. Technol. Ref., pp. 1–8 doi: 10.1049/etr.2014.0035

attempted to track the time before which an un- patched operating system directly connected to the Internet, is compromised. Varying from ∼20 min in 2003, through to 4 min in 2008 and back to 40+ min in 2012, the statistics mirror the addition of pro- tection to the network and operating systems security rather than a change in threat levels.

Similarly, operating systems have also increased their support over time for more secure protocols (e.g. IPSEC, TLS/SSL and WPA2) to enable trusted connec- tions either to organisational networks remotely across the internet or direct to other individual systems and networks using encryption and mutual authentication based upon Public Key Cryptography (PKI). That mutual authentication often needs to be used to help identify the operating system itself and its general security health (e.g. that it has not been compromised and will not help propagate malware or a worm) before it is given access to a corporate network, a scheme known as Network Access Protection.

Malware protection Malware has become an increasing issue for operating systems to deal with as users need and want to access and exchange files and applications through a variety of means, such as web portals, messaging/chat systems and social media. Indeed, many of the recent cyber security attacks have been as a conse- quence of the receipt of a malicious file from a web site or email rather than direct attack via the network.

This leaves the platform designers with a conundrum. How to secure the platform against the potential ma- licious execution of applications, yet also provide an open environment for legitimate execution of applica- tions? As a consequence a number of strategies have been adopted.

Application Verification and Control: An important principle in ensuring security in most operating systems is that of maintaining the user’s privileges to run and access resources as being very distinct and separate from that of the administrator as this limits the potential damage a malware can do to the core operating system code and other users or application data.

Whereas most operating systems have historically identified the code that was acceptable to be executed based purely upon the user identity or the group that they belonged to, operating systems (such as Apple

5 & The Institution of Engineering and Technology 2015

IET Engineering & Technology Reference Paul Hopkins

iOS and Microsoft Windows) use methods that check that the code within the application has not been modified and is from a trusted source. This is done by checking that the ‘hash’ (or fingerprint) of the ap- plication (that is about to be executed) matches the cryptographically signed hash that is extracted from a certificate (from a trusted authority) accompanying the application. For example, Apple iOS implements this mechanism, by enforcing all applications through the app store. These are signed by Apple after being checked, although there is anecdotal evi- dence that the checking is not always that specific from a security perspective.

Similarly, operating systems have extended the mechan- ism by which they assess and control the execution of files so that other attributes, such as its location in the file system; its version number date or type and so on all can be combined with the user or group identity to decide on the access permission. An example of which can be found in Microsoft Windows with Applocker.

Even though an application may be permitted to execute, sometimes the application (and the process that executes it) may become compromised. For example, the browser or mail reader starts executing malware from the downloaded content. For this reason operating systems (such as Apple iOS/OSX) have used cryptographic mechanisms (PKI certificates) to protect the rest of the operating system using two methods. Firstly, by protecting the list of capabilities that an application may require (such as network, GPS) so that the operating system knows that no add- itional capabilities have been requested since it started running (e.g. some malware may attempt to turn on the microphone and camera). Secondly, by using the code signing mechanism, the signed application code is checked by the operating system as the process is loaded into memory for execution to ensure that it has not been compromised or hijacked during its general execution.

Application Separation: Sandboxing: Sandboxing is a popular method of ensuring that an application’s functionality is contained and thus limits the ability of the application either to access other applications running at the same time or their memory, I/O and network interfaces/resources, by providing a form of isolation. There are a number of different approaches to this, firstly the whole operating system can be virtualised and run on a hypervisor. (A hypervisor abstracts the hardware environment for a platform, and provides a method or container for separating out

6 & The Institution of Engineering and Technology 2015

and executing a number of operating systems on one platform.) Although this approach does not protect other applications in the same operating system, it does protect applications in other operating systems on the same hardware. Alternatively, some particular vulnerable applications, such as the browser may themselves have sandbox protection (e.g. Google Chrome) built into them and therefore tries to limit the ability of code to execute on the operating system. Or lastly, as is the case in operating systems, such as Apple iOS/OSX and Android [17], an application is constrained to a single process space and it is executed within its own context. Access to shared system resources (ranging from file systems to cameras and GPS receivers) are defined and need to be accepted by users prior to installation and execution and controlled and logged by the operating system.

Application Execution Attackers have exploited (and will probably continue to exploit) applications through the user supplied input. One of the most common and oldest form of attacks has been the ‘buffer overrun’ where the user supplied input goes unchecked and ends up writing directly to the operating systems and applications memory that is normally used to store the application execution code, temporary and global data. Instead an attacker supplies sufficient data to take control of the application execution (by manipulating the stack pointer) and execute within the application context the data and code they have written to the memory rather than continue to execute the application. In order to mitigate this attack, a number of platforms and operating systems, such as Windows XP onwards, Apple iOS, Android, SELinux, all mark the application data as non-executable so that even if the attacker manages to write data to the memory they will struggle to execute that data.

To mitigate the non-execution of the overwritten data or where the space available is too small to contain all of the malicious instructions attackers attempt to use another technique ‘return to-lib-c/return orientated programming’. In this case, they attempt to use already pre-loaded and existing libraries and code of the operating system, which they reference in a se- quence to try to execute their desired functions. To mitigate this attack, a number of operating systems have also adopted the technique of address space layout randomisation. By randomising the memory locations in which they load executable code and li- braries the ability of an attacker to readily guess and

Eng. Technol. Ref., pp. 1–8 doi: 10.1049/etr.2014.0035

IET Engineering & Technology Reference Operating System Security

access the predictable software codes they need is sig- nificantly reduced.

Physical Theft With widespread Internet connectivity and a prolifer- ation of mobile and smart devices, operating system security has had to turn its attention to the simplest and oldest of threats, that of theft and physical access to the device. Operating systems now have the capacity to access online services and store locally on the devices increasing volumes of informa- tion, such that access to the device could provide access to significant online resources and local data. This was a significant departure from the original plat- forms of 20 years ago that would have required a crane to take the systems from the building, yet now they are in the reach of a pickpocket.

Fortunately, many operating systems have developed protection in two ways. Firstly, they have developed the capability to encrypt individual data files and in some cases data within the memory. This is done in order to protect access to applications and data from other users and processes during a short period of physical access to the device (e.g. where a USB stick or drive is plugged into the system). Secondly, all of the data is encrypted on the device and thus protects against subsequent copying if physically stolen. Both approaches may take advantage of hardware encryp- tion facilities that are increasingly built into many pro- cessors/chips (as cryptographic operations can be expensive and power consuming). However, the oper- ating systems have also taken advantage of the hard- ware capabilities that are increasingly built into some computing platforms to also store the cryptographic material securely. For instance, Bitlocker within the Microsoft Windows operating system is designed to use the Trusted Platform Module, a tamper proof hard- ware chip to store the encryption key material. Similarly the application processor used by many Apple iOS devices will store a unique cryptographic key for each individual device. The key, embedded during manufac- ture into the application processor, is never accessed or disclosed, but used in other encryption routines to sign and encrypt other keys and data, and never accessed by the operating system directly. It provides a unique key that the operating system can rely on to check that its hardware and code have not been tampered with.

Operating System Security – Good Implementation Practice While for a number of different operating systems the overall trend appears to be one of enhancing security

Eng. Technol. Ref., pp. 1–8 doi: 10.1049/etr.2014.0035

within their core, very often organisations (and indivi- duals given the increase in products, such as smart- phones) need to configure them to adapt to their business and personal requirements. If the security is to be maintained and balanced with the usability of the devices, then an understanding of the options needs to be available to make those compromises.

Just as the threat landscape to operating systems has changed, so too has the environment for guidance for secure configuration and deployment of these platforms, with an increase in guidance and tools (albeit primarily for an organisation and its IT opera- tions rather than the end user).

Many operating system (and platform) vendors, such as Microsoft Windows, VMware and Cisco etc, have now produced both ‘hardening’ guides and tools to assist with their secure configuration. Prior to these vendors issuing guidance the information gap was filled by independent security associations, such as CIS [18] who provide ‘hardening’ guides for multiple platforms based on community feedback. Similarly, government agencies (such as the UK CESG and US NSA) have published guidance with ‘hardening’ and configuration information (and in some instances con- figuration tools). Although in the latter case, such guidance has only recently become more widely avail- able to communities other than government, probably as a result of recognising the interdependence of these platforms for much of society rather than a select few.

Overall, this guidance very often focuses ensuring that any configuration maintains the principles and con- cepts we have introduced within this article, namely:

† Least privilege: Restricting users and processes (acting on their behalf) to the minimal privileges ne- cessary to execute their operations. † Separation: Isolating processes, data and users ap- propriately, so that there is minimal interference pos- sible either maliciously or accidentally. † Minimal: Limiting access to only the essential users and services from a trusted and authenticated source. † Updates: Being able to update software on the dis- covery of vulnerabilities or configuration weaknesses to maintain security. † Assurance: Designing and managing subsequent development (on top of the operating system) using secure development methodologies and the security features that the operating systems have embedded into them.

7 & The Institution of Engineering and Technology 2015

IET Engineering & Technology Reference Paul Hopkins

† Audit: Enabling a trusted and secure path to gener- ate appropriate information log and audit information.

Future Directions for Operating System and Platform Security Within this article, we have examined the key security features of operating systems and how they have adapted to changes in technology and the threats that have emerged. So while it is apparent that many operating systems are increasingly having the core security concepts built into their operating systems to meet the changing threats, it is also clear that they will continue to have to evolve.

In particular, operating systems will continue to have to adapt, to the increasing distribution of functions to the cloud, the increasingly rich functionality required within embedded systems/devices, the avail- ability of hardware for assisting with secure functions or the changes in attitudes to privacy and different threats.

† From a user perspective, the cloud will undoubtedly be viewed as an operating platform of the future, with dedicated applications or access to sub-operating systems, all of the key security mechanisms from the federation of authorisation and access control to en- cryption of data remains challenging. † Just as was originally the case with mobile phones evolving from feature phones to smartphones, the in- creasing functionality and connectivity will result in embedded systems facing similar challenges to secur- ing their (increasingly functional) operating systems. Either as consequence of the limited space and power constraints, or as consequence of the difficul- ties with integrating real-time safety related opera- tions with security concepts, such as encryption. † The availability of dedicated hardware for encrypt- ing data or holding key encryption material has already had a significant benefit on the security of some platforms, as highlighted earlier. Increasing access to such dedicated hardware or the use of hard- ware virtualisation for process separation and protec- tion against threats, such as malware will help strengthen protection of single device operating systems, and create a more secure platform. † The increasing concerns of an individual’s privacy and the emergence of powerful security threats from governments appears also to be having an effect on the security features within operating systems. While some concerns have led to changes in encryption methods (such that the master keys always reside

8 & The Institution of Engineering and Technology 2015

with the user rather than the operator/provider) re- search work has also focused on developing access control mechanisms that allow users to be more ex- pressive about the situations when, where and how they want their information to be accessed, rather than giving complete rights all of the time to particular groups and users.

REFERENCES

[1] List of operating systems: http://www.en.wikipedia.org/wiki/ List_of_operating_systems, accessed October 2014

[2] At 10-Year Milestone, Microsoft’s Trustworthy Computing Initiative More Important than Ever, http://www.news. microsoft.com/2012/01/12/at-10-year-milestone-microsofts- trustworthy-computing-initiative-more-important-than-ever/, accessed October 2014

[3] Sourcefire Vulnerability Research Team (VRTTM): 25 Years of Vulnerabilities: 1988–2012, Research Report, Yves Younan

[4] Linux Kernel caiaq USB Drivers Buffer Overflow Vulnerability: https://www.labs.mwrinfosecurity.com/system/assets/153/ original/mwri_caiaq-usb-drivers-buffer-overflow_2011-03-07 .pdf, accessed April 2015

[5] MS13-027 Vulnerabilities in Kernel-Mode Drivers Could Allow Elevation of Privilege, https://www.technet.microsoft. com/library/security/ms13-027, accessed April 2015

[6] Linux vendors rush to patch privilege escalation flaw after root exploits emerge, http://www.computerworld.com/ article/2500325/malware-vulnerabilities/linux-vendors-rush- to-patch-privilege-escalation-flaw-after-root-exploits-em. html, accessed April 2015

[7] Common Criteria: https://www.commoncriteriaportal.org/, accessed October 2014

[8] Certified Products: http://www.commoncriteriaportal.org/ products/, accessed October 2014

[9] The Trusted BSD Project: http://www.trustedbsd.org/docs. html, accessed October 2014

[10] seL4 Operating System Kernel Home Page: http://www.sel4. systems/, accessed October 2014

[11] Heartbleed Vulnerability: http://www.heartbleed.com/, accessed October 2014

[12] iOS Security: https://www.apple.com/privacy/docs/ iOS_Security_Guide_Oct_2014.pdf, accessed November 2014

[13] Miller, C., Blazakis, D., Zovi, D.D., Esser, S., Iozzo, V., Weinmann, R.-P.: ‘iOS Hackers Handbook’ (John Wiley & Sons Inc.) ISBN 978-1-118-20412-2

[14] The Spread of the Sapphire/Slammer Worm: http://www. caida.org/publications/papers/2003/sapphire/, accessed October 2014

[15] TCP SYN Flooding and IP Spoofing Attacks: http://www.cert. org/historical/advisories/CA-1996-21.cfm, accessed October 2014

[16] Survival Time: https://www.isc.sans.edu/survivaltime.html, accessed October 2014

[17] Android Security Overview: https://www.source.android. com/devices/tech/security/, accessed October 2014

[18] CIS Security Benchmarks: http://www.benchmarks.cisecurity. org/, accessed October 2014

Eng. Technol. Ref., pp. 1–8 doi: 10.1049/etr.2014.0035