KealeyLab1Input.txt

Abstract
Although public awareness of the need for security in computing systems is growing rapidly, current efforts to provide security are unlikely to succeed. Current security efforts suffer from the flawed assumption that adequate security can be provided in applications with the existing security mechanisms of mainstream operating systems. In reality, the need for secure operating systems is growing in today’s computing environment due to substantial increases in connectivity and data sharing. The goal of this paper is to motivate a renewed interest in secure operating systems so that future security efforts may build on a solid foundation. This paper identifies several secure operating system features which are lacking in mainstream operating systems, argues that these features are necessary to adequately protect general application-space security mechanisms, and provides concrete examples of how current security solutions are critically dependent on these features.

Keywords: secure operating systems, mandatory security, trusted path, Java, Kerberos, IPSEC, SSL, firewalls.
1 Introduction
Public awareness of the need for security in computing systems is growing as critical services are becoming increasingly dependent on interconnected computing systems. National infrastructure components such as the electric power, telecommunication and transportation systems can no longer function without networks of computers [50]. The advent of the World Wide Web has especially increased public concern for security. Security is the primary concern of businesses which want to use the Internet for commerce and maintaining business relationships [24].

The increased awareness of the need for security has resulted in an increase of efforts to add security to computing environments. However, these efforts suffer from the flawed assumption that security can adequately be provided in application space without certain security features in the operating system. In reality, operating system security mechanisms play a critical role in supporting security at higher levels. This has been well understood for at least twenty five years [2][54][39], and continues to be reaffirmed in the literature [1][35]. Yet today, debate in the research community as to what role operating systems should play in secure systems persists [11]. The computer industry has not accepted the critical role of the operating system to security, as evidenced by the inadequacies of the basic protection mechanisms provided by current mainstream operating systems.

The necessity of operating system security to overall system security is undeniable; the underlying operating system is responsible for protecting application-space mechanisms against tampering, bypassing, and spoofing attacks. If it fails to meet this responsibility, system-wide vulnerabilities will result.

The need for secure operating systems is especially crucial in today’s computing environment. Substantial increases in connectivity and data sharing have increased the risk to systems such that even a careful and knowledgeable user running on a single-user system is no longer safe from the threat of malicious code. Because the distinction between data and code is vanishing, malicious code may be introduced, without a conscious decision on the part of a user to install executable code, whenever data is imported into the system. For example, malicious code could be introduced with a Java applet or by viewing apparently benign data that, in actuality, contains executable code [32][62]. More so than ever, secure operating systems are needed to protect against this threat.

The goal of this paper is to motivate a renewed interest in secure operating systems. By consolidating a number of well-documented examples from the literature, it argues that the threats posed by the modern computing environment cannot be addressed without support from secure operating systems and, as was stated in [8], that any security effort which ignores this fact can only result in a “fortress built upon sand.” Section 2 describes a set of secure operating system features which are typically lacking in mainstream operating systems but are crucial to information security. The need for these features is highlighted in section 3, which examines how application-space access control and cryptography cannot provide meaningful security without a secure operating system. Section 4 provides concrete examples of how security efforts rely on these operating system security features. Section 5 discusses the role of operating system security with respect to overall system security.
2 The Missing Link
This section identifies some features of secure operating systems which are necessary to protect application-space security mechanisms yet are lacking in mainstream operating systems. They form the “missing link” of security. Although this section only deals with features, it is important to note that features alone are inadequate. Assurance evidence must be provided to demonstrate that the features meet the desired system security properties and to demonstrate that the features are implemented correctly. Assurance is the ultimate missing link; although approaches to providing assurance may be controversial, the importance of assurance is undeniable.

The list of features in this section is not intended to be exhaustive; instead it is merely a small set of critical features that demonstrate the value of secure operating systems. A more complete discussion on secure operating systems, including discussions of assurance, can be found in [25], [59] or [20]. Subsequent sections argue the necessity of these features by describing how application-space security mechanisms and current security efforts employing them are vulnerable in their absence.

Mandatory security
The TCSEC [20] provides a narrow definition of mandatory security which is tightly coupled to the multi-level security policy of the Department of Defense. This has become the commonly understood definition for mandatory security. However, this definition is insufficient to meet the needs of either the Department of Defense or private industry as it ignores critical properties such as intransitivity and dynamic separation of duty [12][22]. This paper instead uses the more general notion of mandatory security defined in [59], in which a mandatory security policy is considered to be any security policy where the definition of the policy logic and the assignment of security attributes is tightly controlled by a system security policy administrator. Mandatory security can implement organization-wide security policies. Others have referred to this same concept as non-discretionary security in the context of role-based access control [22] and type enforcement [39][7][13].1


1. Actually, long ago, the term non-discretionary controls was used for multi-level security as well [39].
Likewise, as defined in [59], this paper uses a more general notion of discretionary security in which a discretionary security policy is considered to be any security policy where ordinary users may be involved in the definition of the policy functions and/or the assignment of security attributes. Here discretionary security is not synonymous with identity based access control; IBAC, like any other security policy, may be either mandatory or discretionary[58].

An operating system’s mandatory security policy may be divided into several kinds of policies, such as an access control policy, an authentication usage policy, and a cryptographic usage policy. A mandatory access control policy specifies how subjects may access objects under the control of the operating system. A mandatory authentication usage policy specifies what authentication mechanisms must be used to authenticate a principal to the system. A mandatory cryptographic usage policy specifies what cryptographic mechanisms must be used to protect data. Additionally, various sub-systems of the operating system may have their own mechanism usage policies. These subsystem-specific usage policies may be dependent on the cryptographic usage policy. For example, a network usage policy for a router might specify that sensitive network traffic should be protected using IPSEC ESP [4] in tunneling mode prior to being sent to an external network. The selection of a cryptographic algorithm for IPSEC ESP may be deferred to the cryptographic usage policy.

A secure system must provide a framework for defining the operating system’s mandatory security policy and translating it to a form interpretable by the underlying mandatory security mechanisms of the operating system. Without such a framework, there can be no real confidence that the mandatory security mechanisms will provide the desired security properties. An operating system which provides mandatory security may nonetheless suffer from the presence of high bandwidth covert channels. This is an issue whenever the mandatory security policy is concerned with confidentiality. This should not, however, be a reason to ignore mandatory security. Even with covert channels, an operating system with basic mandatory controls improves security by increasing the required sophistication of the adversary. Once systems with basic mandatory controls become mainstream, covert channel exploitation will become more common and public awareness of the need to address covert channels in computing systems will increase[57].

In any system which supports mandatory security, some applications require special privileges in the mandatory policy in order to perform some security-relevant function. Such applications are frequently called trusted applications because they are trusted to correctly perform some security-related function and because they are trusted to not misuse privileges required in order to perform that function. If the mandatory security mechanisms of a secure operating system only support coarse-grained privileges, then the security of the overall system may devolve to the security of the trusted applications on the system. To reduce the dependency on trusted applications, the mandatory security mechanisms of an operating system should be designed to support the principle of least privilege. Type enforcement is an example of a mandatory security mechanism which may be used both to limit trusted applications to the minimal set of privileges required for their function and to confine the damage caused by any misuse of these privileges [48][28].

The mandatory security mechanisms of an operating system may be used to support security-related functionality in applications by rigorously ensuring that subsystems are unbypassable and tamperproof. For example, type enforcement may be used to implement assured pipelines to provide these properties. An assured pipeline ensures that data flowing from a designated source to a designated destination must pass through a security-related subsystem and ensures the integrity of the subsystem. Many of the security requirements of these applications may be ensured by the underlying mandatory security mechanisms of the operating system. [48]

Operating system mandatory security mechanisms may also be used to rigorously confine an application to a unique security domain that is strongly separated from other domains in the system. Applications may still misbehave, but the resulting damage can now be restricted to within a single security domain. This confinement property is critical to controlling data flows in support of a system security policy [33]. In addition to supporting the safe execution of untrustworthy software, confinement may support functional requirements, such as an isolated testing environment or an insulated development environment [48]. For example both the Sidewinder firewall and the DTE firewall use type enforcement for confinement [6][12].

Although one could attempt to enforce a mandatory security policy through discretionary security mechanisms, such mechanisms can not defend against careless or malicious users. Since discretionary security mecha-nisms place the burden for security on the individual users, carelessness by any one user at any point in time may lead to a violation of the mandatory policy. In con-trast, mandatory security mechanisms limit the burden to the system security policy administrator. With only discretionary mechanisms, a malicious user with access to sensitive data and applications may directly release sensitive information in violation of the mandatory policy. Although that same user may also be able to leak sensitive information in ways that do not involve the computing system, the ability to leak the information through the computing system may increase the bandwidth of the leak and may decrease its traceability. In contrast, with mandatory security mechanisms, he may only leak sensitive information through covert channels, which limits the bandwidth and increases accountability, if covert channels are audited.

Furthermore, even with users who are benign and careful, the mandatory security policy may still be subverted by flawed or malicious applications when only discretionary mechanisms are used to enforce it.2 The distinction between flawed and malicious software is not particularly important in this paper. In either case, an application may fail to apply security mechanisms required by the mandatory policy or may use security mechanisms in a way that is inconsistent with the user’s intent. Mandatory security mechanisms may be used to ensure that security mechanisms are applied as required and can protect the user against inadvertent execution of untrustworthy applications. Although the user may have carefully defined the discretionary policy to properly implement the mandatory policy, an application may change the discretionary policy without the user’s approval or knowledge. In contrast, the mandatory policy may only be changed by the system security policy administrator.

2. A discussion of the formal limitations of discretionary security mechanisms appears in [29].
In the case of personal computing systems, where the user may be the system security policy administrator, mandatory security mechanisms are still helpful in 
protecting against flawed or malicious software. In the simplest case, where there is only a distinction between the user’s ordinary role and the user’s role as system security policy administrator, the mandatory security mechanisms can protect the user against unintentional execution of untrustworthy software. With a further sub-division of the user’s ordinary role into various roles based on function, mandatory security mechanisms can confine the damage that may be caused by flawed or malicious software.

Although there are a number of commercial operating systems with support for mandatory security, none of these systems have become mainstream. These systems have suffered from a fixed notion of mandatory security, thereby limiting their market appeal. Furthermore, these systems typically lack adequate support for constraining trusted applications. In order to reach a wider market, operating systems must support a more general notion of mandatory security and must support flexible configuration of mandatory policies.

Mainstream commercial operating systems rarely support the principle of least privilege even in their discretionary access control architecture. Many operating systems only provide a distinction between a completely privileged security domain and a completely unprivileged security domain. Even in Microsoft Windows NT, the privilege mechanism fails to adequately protect against malicious programs because it does not limit the privileges that a program inherits from the invoking process based on the trustworthiness of the program [65].

Current microkernel-based research operating systems have tended to focus on providing primitive protection mechanisms which may be used to flexibly construct a higher-level security architecture. Many of these systems, such as the Fluke microkernel [23] and the Exokernel [41], use kernel-managed capabilities as the underlying protection mechanism. However, as discussed in [59], typical capability architectures are inadequate for supporting mandatory access controls with a high degree of flexibility and assurance. L4 [38] provides some support for mandatory controls through its clans and chiefs mechanism and its IPC mechanism for identifying senders and receivers but still lacks a coherent framework for using these mechanisms to meet the requirements of a mandatory policy. Furthermore, L4 assumes that there will only be a small number of distinct security domains [38]. Flask [56], a variant of the Fluke microkernel, provides a mandatory security framework similar to that of DTOS [43], a variant of the Mach microkernel; both systems provide mechanisms for mandatory access control and a mandatory policy framework.

Trusted path
A trusted path is a mechanism by which a user may directly interact with trusted software, which can only be activated by either the user or the trusted software and may not be imitated by other software [20]. In the absence of a trusted path mechanism, malicious software may impersonate trusted software to the user or may impersonate the user to trusted software. Such malicious software could potentially obtain sensitive information, perform functions on behalf of the user in violation of the user’s intent, or trick the user into believing that a function has been invoked without actually invoking it. In addition to supporting trusted software in the base system, the trusted path mechanism should be extensible to support the subsequent addition of trusted applications by a system security policy administrator [28].

The concept of a trusted path can be generalized to include interactions beyond just those between trusted software and users. The TNI introduces the concept of a trusted channel for communication between trusted software on different network components [44]. More generally, a mechanism that guarantees a mutually authenticated channel, or protected path, is necessary to ensure that critical system functions are not being spoofed. Although a protected path mechanism for local communications could be constructed in application space without direct authentication support in the operating system, it is preferable for an operating system to provide its own protected path mechanism since such a mechanism will be simpler to assure [59] and is likely to be more efficient.

Most mainstream commercial operating systems are utterly lacking in their support for either a trusted path mechanism or a protected path mechanism. Microsoft Windows NT does provide a trusted path for a small set of functions such as login authentication and password changing but lacks support for extending the trusted path mechanism to other trusted applications [65]. For local communications, NT does provide servers with the identity of their clients; however, it does not provide the server identity to the client.
3 General Examples
This section argues that without operating system support for mandatory security and trusted path, application-space mechanisms for access control and cryp-tography cannot be implemented securely. These arguments will then be used to reinforce the discussion in section 4, which analyzes concrete examples.

3.1 Access Control
An application-space access control mechanism may be decomposed into an enforcer component and a decider component. When a subject attempts to access an object protected by the mechanism, the enforcer component must invoke the decider component, supplying it with the proper input parameters for the policy decision, and must enforce the returned decision. A common example of the required input parameters is the security attributes of the subject and the object. The decider component may also consult other external sources in order to make the policy decision. For example, it may use an external policy database and system information such as the current time.

If a malicious agent can tamper with any of the components in the access control mechanism or with any inputs to the decision, then the malicious agent can subvert the access control mechanism. Even if the components and all of the inputs are collocated within a single file, the operating system security mechanisms are still relied upon to protect the integrity of that file. As discussed in the prior section, only mandatory security mechanisms can rigorously provide such integrity guarantees.

Even with strong integrity guarantees for the policy decision inputs, if an authorized user invokes malicious software, the malicious software could change an object’s security attributes or the policy database’s rules without the user’s knowledge or consent. The access control mechanism requires a trusted path mechanism in the operating system in order to ensure that arbitrary propagation of access cannot occur without explicit authorization by a user.

If a malicious agent can impersonate the decider component to the enforcer component, or if a malicious agent can impersonate any source of inputs to the decision, then the malicious agent can subvert the mecha-nism. If any of the components or external decision input sources are not collocated within a single application, then the access control mechanism requires a protected path mechanism.

If a malicious agent can bypass the enforcer component, then it may trivially subvert the access control mechanism. Mandatory security mechanisms in the operating system may be used to ensure that all accesses to the protected objects are mediated by the enforcer component.

3.2 Cryptography
An analysis of application-space cryptography may be decomposed into an analysis of the invocation of the cryptographic mechanism and an analysis of the cryptographic mechanism itself. The analysis of this section draws from the discussions in [51][15] [60][61][55][52].

As an initial basis for discussion, suppose that the cryptographic mechanism is a hardware token that implements the necessary cryptographic functions correctly and that there is a secure means by which the cryptographic keys are established in the token. Even in this simplified case, where the confidentiality and integrity of algorithms and keys is achieved without operat-ing system support, this section will demonstrate that there are still vulnerabilities which may only be effectively addressed with the features of a secure operating system.

One vulnerability in this simplified case is that invocation of the token cannot be guaranteed. Any legitimate attempt to use the token might not result in a call to the token. The application that performs the cryptographic invocation might be bypassed or modified by malicious applications or malicious users. Malicious applications might impersonate the cryptographic token to the invoking application.

Mandatory security and protected path features in the operating system address this vulnerability. Mandatory security mechanisms may be used to ensure that the application that invokes the cryptographic token is unbypassable and tamperproof against both malicious software and malicious users. Unbypassability could also be achieved by using an inline cryptographic token, which is physically interposed between the sender of the data to be protected and the receiver of the protected data; however, this would be less flexible. A protected path mechanism may be used to ensure that malicious software cannot impersonate the cryptographic token to the invoking application.

Misuse of the cryptographic token is a second vulnerability in the simplified case. Misuse may involve the use of a service, algorithm, session or key by an unauthorized application. Without operating system support for identifying callers, a cryptographic token can do little more than require that a user activate it, after which, any service, algorithm, session or key authorized for that user may be used by any application on the system. In this case, the cryptographic token may be misused by applications operating on behalf of other users or may be misused by malicious software operating on behalf of the authorized user. Furthermore, unless the cryptographic token has a direct physical interface for user activation, malicious software can spoof the token to the user, obtain authentication information, and subsequently activate the cryptographic token without the user’s knowledge or consent. Even with a direct physical interface to the user, it is impractical for the cryptographic token to require user confirmation for every cryptographic operation.

This second vulnerability may be addressed through mandatory security, trusted path and protected path features in the operating system. A trusted path mechanism obviates the need for a separate physical interface for activation. A protected path mechanism permits the cryptographic token to identify its callers and enforce fine-grained controls over the use of services, algorithms, sessions and keys. As an alternative to having the token deal with fine-grained controls over its usage, mandatory security mechanisms may also be used to provide such controls. For example, mandatory security mechanisms may be used to isolate the token for use only by applications executed by the user who activated the token. Furthermore, the mandatory security mechanisms can reduce the risk of malicious software being able to use the cryptographic token and may consequently limit the use of the trusted path mechanism to highly sensitive actions.

Hence, even in the simplest case, the features of a secure operating system are crucial to addressing the vulnerabilities of application-space cryptography. In the remainder of this section, the assumptions of the simplified case are removed, and the additional vulnerabilities are examined.

If the assumption that initial keys are securely established within the token is removed, then there is the additional vulnerability that the initial keys may be observed or modified by an unauthorized entity. Unless the initial keys are provided via a dedicated physical interface to the cryptographic token, the operating system must protect the path between the initial key source and the cryptographic token and may need to protect the initial key source itself. Mandatory security mechanisms may be used to rigorously protect the path and the key source. A trusted path may be required for initial keying.

If the assumption that the cryptographic mechanism is confined to a single hardware token is removed and implemented in software instead, the confidentiality and integrity of the cryptographic mechanism’s code and data becomes dependent on the operating system, including both memory protection and file protection. Mandatory security is needed to rigorously ensure the mechanism’s integrity and confidentiality. If any external inputs, such as input parameters to a random number generator, are used by the cryptographic mechanism, the input sources and the path between the input sources and the cryptographic mechanism must be protected with mandatory security mechanisms.
4 Concrete Examples
This section further demonstrates that secure operating systems are necessary by showing that some widely accepted security solutions critically rely on the features of secure operating systems. In particular, this section examines mobile code security efforts, the Kerberos network authentication system, firewalls and network security protocols.

4.1 Mobile Code
A number of independently-developed security solutions for the World Wide Web, each with its own protection model, have been developed to protect against the threats from malicious mobile code. However, systems relying on these security solutions are vulnerable because of a lack of operating system support for security. Primarily, this section will emphasize this point by focusing on efforts to secure Java [27], but other efforts will also be used to highlight issues.

The primary threat that these solutions attempt to address is the threat of hostile mobile code gaining unauthorized access to a user’s files and resources in order to compromise confidentiality or integrity. The threat is not limited to interpreted applets loaded from the network by a web browser; both [26] and [30] extend this threat model to include helper applications which may have been actively installed by a user. There is little distinction between mobile code and what is traditionally considered data. For example, consider that Postscript documents are actually programs with potential access to the local filesystem. Consequently, helper applications which operate on untrustworthy data, such as Postscript viewers, must either be executed in a less flexible mode of operation, or must be carefully confined by the operating system.

The basic Java Security Model is based on the notion of “sandboxing.” The system relies on the type-safety of the language in conjunction with the Java Security Manager to prevent unauthorized actions [27]. Efforts are currently underway to add additional security features to Java, such as capabilities, an expanded access control model, or additional controls over access to certain class libraries [70].

The fundamental limitation of these approaches is that none can be guaranteed to be tamperproof or unbypassable. For example, although the Java language is claimed to be secure, the Java Virtual Machine (JVM) will accept byte code which violates the language semantics and which can lead to security violations [32]. JVM implementation errors have led to violations of the language’s semantics [19]. A significant portion of the Java system is currently in the form of native methods which are implemented as object code and are not subject to the JVM’s type-safety checks. The JVM is not able to protect itself from tampering by other applications. Finally, the Java security model can offer no protection from the many other forms of malicious mobile code. In [30], the authors call for trusted systems to support a system-wide solution to address the threats presented by non-Java code.

Even if such problems with the JVM did not exist, these security solutions would still suffer from the fundamental limitation that they rely on application-space access control for security. They all depend on the local file system to preserve the integrity of the system code, including class files. All of the systems which store policy locally depend on file system access control to preserve the integrity of the policy files. Section 3.1 demonstrated the importance of secure operating system features for supporting application-space access control.

Another popular approach to “securing” mobile code is to require digitally signed applets and limit execution to those originating from trusted sources [27]. In fact, native ActiveX security is based entirely on digital signatures, as it has no form of access control [24][27]. The basic flaw with this approach is that it is an all-or-nothing proposition; the user cannot constrain a native ActiveX control to a limited security domain. Mandatory security mechanisms in the operating system may be used for this purpose, by confining the browser to a distinct security domain.

Note that, although not sufficient by themselves, digital signatures will play an important part in mobile code security, even on secure operating systems. They can reduce the risk of malicious code entering the system, provide some measure of trust that an applet will behave properly, and provide another piece of information to use in making an access control decision. However, as with the general application-space cryptography described in section 3.2, the digital signature verification mechanism depends on secure operating system features to guarantee invocation, to protect the integrity of the mechanism, and to protect the integrity of the locally cached public keys.

The need for an operating system trusted path mechanism was highlighted by [67] which demonstrates the ease with which a trojan horse applet can capture credit card numbers, PIN numbers or passwords by perfectly emulating a window system dialog box. The proposed solution was an ad hoc user-level trusted path mechanism which required a user to customize his dialog box with a complicated graphical pattern. This solution is not adequate as it only increases the sophistication required in the trojan horse.

Other systems attempt to provide alternative security solutions to the mobile code threat. The Janus system [26] interposes on Solaris system calls to constrain untrusted native applications, and Safe-Tcl [49] provides a “safe interpreter” which attempts to limit the command set available to untrusted code. However, like the Java security solutions, these systems are subject to the same vulnerabilities as any other application-space access control mechanism; consequently, they require secure operating system support.

Beyond enabling all of the mobile code systems mentioned above to function securely, a secure system could also simplify them. Rather than implementing their security primitives in application space where they are vulnerable, they could utilize the system security services to provide a better overall system. A properly designed secure system would provide a flexible, economic foundation with one consistent security model for all of the different virtual machine efforts to use.

4.2 Kerberos
Kerberos [31][47] is a network authentication service originally developed for Project Athena at MIT. In addition to providing an authentication service, Kerberos supports the establishment of session keys to support network confidentiality and integrity services. Derivatives of Kerberos have been used to provide authentication and key establishment services for AFS [64], DCE [53], and ONC RPC [21]. Kerberos and systems that rely on Kerberos have been suggested as a means of providing security for the World Wide Web [18][36][37].

Kerberos is based on symmetric cryptography with a trusted key distribution center (KDC) for each realm. The Kerberos KDC has access to the secret key of every principal in its realm. Consequently, a compromise of the KDC can be catastrophic. This is generally addressed by requiring that the KDC be both physically secure and dedicated solely to running the Kerberos authentication server [46].3 A typical environment also uses physically-secure dedicated systems for the servers using Kerberos. Without these environmental assumptions, the Kerberos authentication service and the Kerberized server applications would require secure operating system features to rigorously ensure that they are tamperproof and unbypassable. For the sake of argument, the remainder of this section will consider these environmental assumptions to be true and focus only on the security of the client workstations.


3. Variants of Kerberos have been proposed that use asymmetric cryptography either to reduce the cost incurred by a penetration of the KDC or to completely eliminate the need for the KDC [63] [66][42][18].
Kerberos was designed for an environment where the client workstations and the network are assumed to be completely untrustworthy [10][45]. However, since the software on the client workstation mediates all interactions between its user and the Kerberized server applications, this assumption implies that the Kerberized server applications must view all client applications as potentially malicious software. Furthermore, a Kerberized server application has no means of establishing a trusted path to a user on a client workstation, since that would require trusted code on the client workstation. Thus, in a system that uses Kerberos, malicious software executed by a user is free to arbitrarily modify or leak a user’s information, with no means of confinement; no distinctions between a user’s legitimate requests and the requests of malicious software are possible. Given the increasing ease with which malicious software may be introduced into a system, the Kerberos environmental model seems untenable. As noted in [14], secure end-to-end transactions require trusted code at both end points.

As a basis of further discussion, suppose that there is a base set of trustworthy software on the client work-stations which is protected against tampering, but that the client workstation operating system still lacks mechanisms for mandatory security and trusted path. Furthermore, suppose that the client workstation is a single-user system which does not export any services to other systems. In spite of these assumptions, a user is still vulnerable to attacks by malicious software, such as mobile code downloaded by the user.

If the malicious software could spoof the client-side authentication program to the user, then it may be able to obtain a user’s password. Even with one-time passwords, this attack would permit the malicious software to act on behalf of the user during the login session. A trusted path mechanism in the client workstation’s operating system can be used to prevent such an attack. Additionally, such a trusted path mechanism in combination with support for a network protected path can be used to provide a trusted path between users and server applications.

If the malicious software can read the files used by the Kerberos client software to store tickets and session keys, then the malicious software may directly impersonate the user to the corresponding Kerberized server applications. Even if the session keys are encapsulated within a hardware cryptographic token, the malicious software can invoke the cryptographic token on behalf of the user, exploiting the misuse vulnerability discussed in section 3.2. Mandatory security mechanisms can be used to rigorously protect either the file or the cryptographic token against access by malicious software.

4.3 Network Security Protocols
The IPSEC network security protocols [5][3][4] are used to provide authentication, integrity, and confidentiality services at the IP layer. Typical implementations of the IPSEC protocols rely on application-space key management servers to perform key exchanges and supply keys for security associations. The IPSEC module in the network stack communicates with the local key management server via upcalls to retrieve the necessary information.

SSL [69] is another network security protocol that provides authentication, integrity, and confidentiality services and a negotiation service for keys and cryptographic algorithms. SSL, however, is implemented entirely in application space and requires no kernel modifications. SSL has been implemented as a library that interposes on socket calls to incorporate the SSL protocol between the underlying transport protocol of the socket (e.g., TCP) and the application protocol (e.g., HTTP).

Since it relies on application-space cryptography, the key management server used by IPSEC is subject to the vulnerabilities described in section 3.2 and requires mandatory security mechanisms in the operating system for adequate protection. In turn, since the protection provided by IPSEC depends on the protection of the keys, mandatory security mechanisms in the operating system are also crucial to meeting the security requirements of IPSEC. Since the complete SSL implementation operates in application space, it is directly subject to the vulnerabilities described in section 3.2 and requires mandatory security mechanisms in the operating system for adequate protection.

Both IPSEC and SSL are intended to provide secure channels. However, as noted in [14], an end-to-end secure transaction requires a secure channel and secure end points. If an attacker can penetrate one of the end points and directly access the unprotected data, then the protection provided by IPSEC and SSL is only illusory.

4.4 Firewalls
A network firewall is a mechanism for enforcing a trust boundary between two networks. The analysis of this section is based on the discussions in [17][9][11][6]. Commonly, firewalls are used to maintain a separation between insiders and outsiders for an organization’s computing resources. Internal firewalls may also be used to provide separation between different groups of insiders or to provide defense-in-depth against outsiders.

Modern firewall architectures typically involve the use of bastion hosts; in a screened subnet architecture, there may be an external bastion host on a perimeter network, which is highly exposed to outsiders, and an internal bastion host on the internal network, which is exposed to the external bastion host. The security of the bastion hosts is crucial to the security provided by the firewall. To reduce risk, bastion hosts are typically dedicated systems, only providing the minimal services required. Even with such minimal configuration, flaws in the proxy servers on the bastion host may permit penetration. However, mandatory security mechanisms in the operating systems of the bastion hosts may be used to confine proxy servers so that penetrations are narrowly limited. Similarly, the bastion host’s mandatory security mechanisms may be used to protect proxy servers against tampering.

Firewalls provide no protection against malicious insiders. Typically, insiders can easily leak information through the firewall. Malicious insiders can construct tunnels to permit outsiders to perform inbound calls through the firewall or may provide ways of bypassing a firewall entirely. Additionally, malicious insiders can exploit data leaked between users within the firewall. Although internal firewalls may be used to partition insiders into multiple trust classes, the granularity of protection is quite limited in comparison to what can be provided by a secure operating system.

The ability of malicious insiders to leak data through the firewall can be confined by mandatory security mechanisms in the operating systems of the internal hosts. Likewise, mandatory security mechanisms in the operating systems of the internal hosts can confine outsiders who perform inbound calls through tunnels constructed by a malicious insider to the security domains in which the malicious insider is allowed to operate.

In addition to the threat of malicious insiders, a firewall is at risk from the threat of malicious software executed by benign insiders. Typically, firewalls do not require that insiders strongly authenticate themselves to the firewall in order to access external services through the firewall [40]. Hence, if a benign insider executes malicious software on an internal host, the malicious software may seek to subvert the protection of the firewall in the same fashion as a malicious insider. An example of using a malicious Java applet to enable outsiders to penetrate a firewall is given in [40]. Even if insiders are required to strongly authenticate themselves to the firewall, a benign insider may still execute a trojan horse whose overt purpose requires external access; in this case, the malicious software may still subvert the protection of the firewall.

Mandatory security mechanisms in the operating systems of the internal hosts may be used to protect users against execution of malicious software or to confine such software when it is executed. If strong authentication is required prior to accessing external services, mandatory security mechanisms could be used to ensure that only trustworthy software on the internal hosts can communicate with the strong authentication mechanism on the firewall. In any case, the mandatory security mechanisms would limit the ability of malicious software to leak information or support inbound calls.

Firewalls are also susceptible to malicious data attacks [62]. Some example malicious data attacks relevant to firewalls are described in [68][40][16]. As with malicious insiders and malicious software, mandatory security mechanisms in the operating systems of the bastion hosts and the internal hosts may be used to confine malicious data attacks.

When inbound services are supported by a firewall, the firewall itself cannot protect the remote system against compromise. The remote system’s operating system must protect against misuse of the allowed inbound services and must protect any information acquired through the inbound service against leakage. Mandatory security mechanisms in the remote system’s operating system may be used to provide such protection. Additionally, mandatory security mechanisms in the internal host’s operating system are needed to confine any attack from a penetrated remote system.

When a benign insider wishes secure access to a remote service, the firewall itself cannot provide complete protection for the use of the remote service. The internal host’s operating system must protect against any attempts by the server to trick the client into misusing its privileges, as in the case where a browser executes a malicious applet provided by a server; mandatory security mechanisms in the internal host’s operating system may be used to confine these client applications. 
5 System Security
No single technical security solution can provide total system security; a proper balance of security mechanisms must be achieved. Each security mechanism provides specific security functions and should be designed to only provide those functions. It should rely on other mechanisms for support and for required security services. In a secure system, the entire set of mechanisms complement each other so that they collectively provide a complete security package. Systems that fail to achieve this balance will be vulnerable.

As has been shown throughout this paper, a secure operating system is an important and necessary piece to the total system security puzzle, but it is not the only piece. A highly secure operating system would be insufficient without application-specific security built upon it. Certain problems are actually better addressed by security implemented above the operating system. One such example is an electronic commerce system that requires a digital signature on each transaction. A application-space cryptographic mechanism in the transaction system protected by secure operating system features might offer the best system security solution.

No single security mechanism is likely to provide complete protection. Unsolved technical problems, implementation errors and flawed environmental assumptions will result in residual vulnerabilities. As an example, covert channels remain a serious technical challenge for secure operating system designers. These limitations must be understood, and suitable measures must be taken to deploy complementary mechanisms designed to compensate for such problems. In the covert channel example, auditing and detection mechanisms should be utilized to minimize the chances that known channels are exploited. In turn, these should depend on secure operating systems to protect their critical components, such as audit logs and intrusion sensors, because they are subject to the same types of vulnerabilities as those discussed throughout this paper. 
6 Summary
This paper has argued that the threats posed by the modern computing environment cannot be addressed without secure operating systems. The critical operating system security features of mandatory security and trusted path have been explained and contrasted with the inadequate protection mechanisms of mainstream operating systems. This paper has identified the vulnerabilities that arise in application-space mechanisms for access control and cryptography and has demonstrated how mandatory security and trusted path mechanisms address these vulnerabilities. To provide a clear sense of the need for these operating system features, this paper has analyzed concrete examples of current approaches to security and has shown that the security provided by these approaches is inadequate in the absence of such features. Finally, the reader was given a perspective of system security where both secure operating systems and application-space security mechanisms must complement each other in order to provide the correct level of protection.

By arguing that secure operating systems are indispensable to system security, the authors hope to spawn a renewed interest in operating system security. If security practitioners were to more openly acknowledge their security solution’s operating system dependencies and state these dependencies as requirements for future operating systems, then the increased demand for secure operating systems would lead to new research and development in the area and ultimately to commercially viable secure systems. In turn, the availability of secure operating systems would enable security practitioners to concentrate on security services that belong in their particular components rather than dooming them to try to address the total security problem with no hope of success.

uantum” is a word that stirs in its wake a litany of questions. No one can deny that the future of computing is to be found in the unique features of quantum mechanics, the branch of physics that studies nature at an infinitely small scale. However, it seems hard to grasp how it could be that the sector that has most to gain from quantum computing is, in fact, the security sector.

What is quantum computing?

Computers currently work in bits. Traditional computing is conditioned by the amount of information that can be contained in these binary chains of zeros and ones. This also implies a limit in computing that sets a series of technological hurdles and some limits on what we can do.

But what if we were to expand this binary limit? Qubits which are the computation unit of these systems, not only consist of two values, but they can use a set of quantum states that include the superposition of this binary.

In other words, qubits can adopt a value to represent 0, 1, and 0 and 1 at the same time, or any quantum superposition of those two qubit states. This is caused exclusively by the characteristics of quantum physics. With appropriate adaptations, it allows a multiplying of the computing capacity to solve certain tasks which would otherwise be impossible to deal with.

What is quantum computing for?

Or rather, can it be used for everything? No; quantum computing isn’t intended to “substitute” current computing. At least, not for now. This is what Mikhail Lukin — co-founder of the Russian Quantum Center and creator of the first 51 qubit quantum computer — explained during last year’s International Conference on Quantum Technologies, ICQT 2017.

Because of the characteristics that grant it its special properties, quantum machines aren’t useful for carrying out many of the everyday tasks that our computers perform. But what they do allow is to do things that until now we thought impossible. Thus, the first quantum computers, just as we saw in ICQT 2017, will be applied to research, in order to process massive amounts of data; and to artificial intelligence, especially in self-driving cars; and, above all, to digital security.

The highest possible security

Are we really looking at impregnable systems? If we take into account the fact that no systems are 100% safe forever, we can’t make such a claim. But if we understand how quantum cryptography works, we can understand why it is so important for the future of security.

Quantum cryptography is a cryptological system that harnesses several of the properties of quantum mechanics to send messages securely. In fact, it’s the safest form that is known of to date.

Firstly, if a third party were to intercept the information during the creation of the secret key, the process would alter itself, meaning that the system would reveal the intruder before any information could be sent.

Secondly, quantum cryptography makes use of another property called entanglement, which can be used to send information safely without a means of transmission. This means that there is no way that a failure in the channel can cause an information leak.

To all of this can be added coding under the most secure conditions ever known due to the incredible processing capacity offered by quantum computing. Because of all this, this is the most promising system to safeguard privacy in the future of communication. A future that is almost upon us.

Quantum cryptography is already here

While it may seem like we still have decades of development before it can be implemented, the fact is that we have already seen several examples of how quantum computing and cryptography can be implemented. For example, during ICQT2017 Lukin announced the first computer with 51 real (not simulated) qubits, the most powerful up to that point. During the same conference, John Martinis, head of the Artificial Intelligence section of Google, explained the company’s plans to develop their own quantum computers.

According to the experts at the conference, in a few years’ time, we will have practical machines that are capable of fulfilling the requisites that will enable these computers to be used commercially. Security in companies will have to be adapted to the new possibilities associated with these super powerful computers.

Because, all of a sudden, passwords won’t be so secure unless we have quantum security measures. This leads us to the second question: quantum cryptography is much more advanced that we thought. In January this year, a joint China-Austria team showed that communication between continents with quantum encryption was possible.

The latest breakthrough achieved by this group consists of combining quantum communication from the Micius satellite with the fiber optic network in Beijing. It is the first practical proof that technology that allows networks to use quantum encryption is already available. How long will it be before we see a commercial application? Probably not long.

While we’re waiting for quantum computing and security to come to the business world, however, we need to continue to make sure we have the strongest measures against cybercriminals: a good security plan and a good security team; efficient tools like Panda Adaptive Defense, which allows us to have absolute control over what happens on the company’s systems and networks. We can even consider including new approaches to security, such as applying chaos engineering to our security plan.

Data security in cloud computing
With all the high-profile data breaches in the headlines over the last couple years, many people wonder if they can trust their data if it lives in the cloud.  Of course, anytime you use an Internet or Phone based app, data is accessed from Cloud infrastructure.  The conversation of data security in the cloud explains how the actual web or mobile app provider is accountable for the data protection, regardless of the Cloud platform.

The burden of protection and accountability is assumed by the software architecture team within the company that builds and manages critical data.  To ensure a high level of accountability, there are many regulatory measures that must be implemented within the IT operation.  The main framework is known as the CIA Triad - where data must maintain a specific level of Confidentiality, Integrity and Availability.  This blog highlights some of the practices companies leverage to maintain these measures.

A common misconception in Cloud computing is that data is not secure when hosted on 3rd party hardware.  While there have been numerous stories in the headlines exposing data breaches, the truth is that Cloud computing can be even more secure as opposed to when you host it in your own environment.  Regardless of the hardware and Cloud infrastructure, the software that a company delivers must maintain validated checks and balances to prove that data is safe.

Keeping Cloud Computing Confidential
Encryption is the means for which data privacy is protected and insured, modern encryption technologies are very mature.  Vendors that provide cloud storage have security measures built into the platform that help protect the data. One example of this is having encryption on the data “at rest,” something a traditional file system would not have without additional software.  This means that data in encrypted, while sitting on a server, and no one in the outside world can make heads or tails from it.

When using Cloud apps, in theory, your data should be protected from unauthorized access.  This is because the online software provider uses encrypted data and enforces security controls over the infrastructure. There may also be situations where you want to make data available to certain personnel under certain circumstances – providers must be able to do this securely.  In the business world, all Cloud providers are subject to the compliance regulations that are dictated by their customers.  If they enter into an agreement, they must able to validate that secure measures are followed, and all breaches or losses must be disclosed. 

Data breaches inevitably result in diminished trust by customers. In one of the largest breaches of payment card data ever, cyber-criminals stole over 40 million customer credit and debit card numbers from Target. The breach led customers to stray away from Target stores and led to a loss of business for the company, which ultimately impacted the company’s revenue.  It is important to note that Target was collecting their customer's data and storing it within their own environments.  They were not able to uncover the vulnerabilities that led to the breach.

When companies scale their environment to the size of an enterprise like Target (or other high profile breaches), they must have a solid foundation with layers of management and software.  A critical cyber security operation should be managed 24x7x365 with human eyeballs and have data coming from as many points as possible.

Maintaining Data Integrity in the Cloud  
Data integrity can be defined as protecting data from unauthorized modification or deletion.  An example of this is easily understood if you think about online banking.  If specific administrators have access to bank accounts, how are they held accountable and protect the bank from illegal changes?  There must be a system of permissions and logs that can demonstrate that there is no inappropriate access to customer data.

With cloud computing, there are large amounts of data, coming from many sources.  A Cloud system will deliver the access in its base form, but it is up to the cloud app developer to define means of access.   Authorization is crucial in assuring that only specific entities can interact with data and that there are ways of producing the proof.  In a cloud environment, data integrity must be maintained at all times to avoid any inherent data loss.

Ensuring Data Availability and Cloud Access
Cloud and Infrastructure engineers always plan for inevitable network failures and downtime. There are several architectural concepts that must be takes to insure that data is highly available in a Cloud infrastructure.

Data availability is a term used by some computer storage manufacturers and storage service providers (SSPs) to describe products and services that ensure that data continues to be available, at a required level of performance, in situations ranging from normal to disastrous.  Within a Server or Storage Network, architects must build out the storage component with redundancy.  Often, they will build in twice the number of drives that would ever be used to make sure there is always 2X the level of availability in case there are failures.

Now with the advent of Public Cloud providers like AWS, subscribers can dictate what region(s) data is stored in. To increase availability data can replicated or backed up across various availability zones and geographic regions.   This is important because it not only helps with compliance but also increases response time/latency on a global scale.

A Cloud platform is a tool that software developers can use to make their product better.  Right out of the box, Public Cloud providers like Microsoft (99.9% availability) and AWS (99.99% availability) deliver availability SLAs (Service Level Agreements) for stored objects. If a web application provider must deliver a better SLA to their clients, it is up to them to engineer redundant/fault tolerant networks to back up, replicate and maintain copies of customer data.

When selecting a Cloud partner, it is important to know where your baseline SLA is so that you can build off it.  Businesses must pay close attention to these SLA definitions because they will share the burden of downtime if there is a loss of data from a cloud provider.  For the typical consumer, SLAs are as big of a concern because the app is usually free.  Consumers must trust that the technology provider is taking these measures and ensuring that your data is safe.

Air-Tight Security Controls for Cloud Computing Services
Access control is a security technique that regulates who or what can view or use resources in a computing environment.   Companies that run online applications must comply with regulatory requirements and define access controls in accordance with their verticals.  Practices must be validated with regularly security checks, measures and audits.

When running a complaint (secure) Cloud operation, specific measures and practices must be defined on how you manage your infrastructure - this is known as change management.  These reports must outline even the most minute of details such as: defining the specific steps to be taken when making changes on a firewall.

Most employee-related incidents are not malicious however, your greatest threat could be inside your walls.  According to the Ponemon Institute’s 2016 Cost of Insider Threats Study, 598 of the 874 insider related incidents in 2016 were caused by careless employees or contractors. It also found 85 incidents due to imposters stealing credentials and 191 were by malicious employees and criminals.

To fight off internal threats, compliant employers must manage their networks responsibly by enforcing company policies that mitigate threats.  For example, they should require intricate passwords and automatically ask for changes every 1-3 months.  2 Factor Authentication can also be implemented to validate every log-in and stop brute force bots.  On a larger scale, the network administrators must have strong visibility with analytical data to see complex, distributed networks (on Cloud Servers and Cloud Storage). They must install, configure and operate sophisticated software that continuously scans the network looking for vulnerabilities, abnormal activity and the movement of large quantities of data.

Industry Compliance for Cloud Infrastructure
Compliance is dictating much of the required security measures and it is becoming more and more sophisticated.  Anyone holding European data must follow the guidelines of the recently enforced GDPR (Global Data Protection Regulation) and California has also implemented their own version called CCPA (California Consumer Privacy Act).  HIPAA, HITRUST, SOX, PCI, NIST etc. are all defined regulatory compliance measures that specifically cater to verticals such as Medical Records, Financial Data etc.

The definition of compliance is either a state of being in accordance with established guidelines or specifications or the process of becoming so. The definition of compliance can also encompass efforts to ensure that organizations are abiding by both industry regulations and government legislation.  This allows companies the freedom to grow as long as they can demonstrate that they are defining policies and improving their security  practices along that path.  The market generally pushes this agenda as it becomes more challenging to sell a product against competition if your product is not verifiably complaint. 

A compliance audit is a comprehensive review of an organization's adherence to regulatory guidelines.  Audit reports evaluate the strength and thoroughness of compliance preparations, security policies, user access controls, and risk management procedures over the course of a compliance audit.  These reports need to be validated and run by a third party that specializes in cyber security and general IT practices.

Mindcentric is a technology company in San Diego California that helps companies secure and manage critical infrastructure while complying with regulatory requirements.   We work with in house data centers, provide our own computing infrastructure and leverage public Clouds.  When working with our Clients, we engineer fully secure and compliant operations.  Our team of industry experts have been helping customers with sophisticated needs for 20 years.

Learn More About the Cloud

Tags: Cloud Security

"Top 10" List of Secure Computing Tips
Tip #1 - You are a target to hackers
Don't ever say "It won't happen to me".  We are all at risk and the stakes are high - to your personal and financial well-being, and to the University's standing and reputation. 

Keeping campus computing resources secure is everyone's responsibility.
By following the tips below and remaining vigilant, you are doing your part to protect yourself and others.
Tip #2 - Keep software up to date
Installing software updates for your operating system and programs is critical. Always install the latest security updates for your devices:

Turn on Automatic Updates for your operating system.
Use web browsers such as Chrome or Firefox that receive frequent, automatic security updates.
Make sure to keep browser plug-ins (Flash, Java, etc.) up to date.
Utilize Secunia PSI (free) to find other software on your computer that needs to be updated.
Tip #3 - Avoid Phishing scams - beware of suspicious emails and phone calls
Phishing scams are a constant threat - using various social engineering (link is external) ploys, cyber-criminals will attempt to trick you into divulging personal information such as your login ID and password, banking or credit card information.

Phishing scams can be carried out by phone, text, or through social networking sites - but most commonly by email.
Be suspicious of any official-looking email message or phone call that asks for personal or financial information.
Check out our Phishing Resources section for details about identifying phishing scams and protecting yourself.

Tip #4 - Practice good password management
We all have too many passwords to manage - and it's easy to take short-cuts, like reusing the same password.  A password management program (link is external) can help you to maintain strong unique passwords for all of your accounts.  These programs can generate strong passwords for you, enter credentials automatically, and remind you to update your passwords periodically. 

There are several online password management services that offer free versions, and KeePass (link is external) is a free application for Mac and Windows.

Here are some general password tips to keep in mind:

Use long passwords - 20 characters or more is recommended.
Use a strong mix of characters, and never use the same password for multiple sites.
Don't share your passwords and don't write them down (especially not on a post-it note attached to your monitor).
Update your passwords periodically, at least once every 6 months (90 days is better).
The Protecting Your Credentials how-to article contains detailed recommendations for keeping your password safe.

Tip #5 -  Be careful what you click
Avoid visiting unknown websites or downloading software from untrusted sources.  These sites often host malware that will automatically, and often silently, compromise your computer.

If attachments or links in the email are unexpected or suspicious for any reason, don't click on it.

ISO recommends using Click-to-Play or NoScript (link is external), browser add-on features that prevent the automatic download of plug-in content (e.g., Java, Flash) and scripts that can harbor malicious code.

Tip #6 - Never leave devices unattended
The physical security of your devices is just as important as their technical security. 

If you need to leave your laptop, phone, or tablet for any length of time - lock it up so no one else can use it. 
If you keep sensitive information on a flash drive or external hard drive, make sure to keep these locked as well. 
For desktop computers, shut-down the system when not in use - or lock your screen.
Tip #7 - Protect sensitive data
Be aware of sensitive data that you come into contact with, and associated restrictions - review the UCB Data Classification Standard to understand data protection level requirements.  In general:

Keep sensitive data (e.g., SSN's, credit card information, student records, health information, etc.) off of your workstation, laptop, or mobile devices.
Securely remove sensitive data files from your system when they are no longer needed.
Always use encryption when storing or transmitting sensitive data.
Unsure of how to store or handle sensitive data?  Contact us and ask!

Tip #8 - Use mobile devices safely
Considering how much we rely on our mobile devices, and how susceptible they are to attack, you'll want to make sure you are protected:

Lock your device with a PIN or password - and never leave it unprotected in public.
Only install apps from trusted sources.
Keep your device's operating system updated.
Don't click on links or attachments from unsolicited emails or texts.
Avoid transmitting or storing personal information on the device.
Most handheld devices are capable of employing data encryption - consult your device's documentation for available options.
Use Apple's Find my iPhone (link is external) or the Android Device Manager (link is external) tools to help prevent loss or theft.
Backup your data.
Tip #9 - Install anti-virus protection
Only install an anti-virus program from a known and trusted source.  Keep virus definitions, engines and software up to date to ensure your anti-virus program remains effective.

For personally-owned systems and unmanaged UCB owned computers, the campus offers free anti-virus software, available for Windows and Mac, to current faculty, staff, and students.

Tip #10 - Back up your data
Back up regularly - if you are a victim of a security incident, the only guaranteed way to repair your computer is to erase and re-install the system.

Here are some additional tips to help keep you safe and secure online:
Use a firewall - Mac and Windows have basic desktop firewalls as part of their operating system that can help protect your computer from external attacks.

Use public wireless hot-spots wisely - follow these tips (link is external) for staying safe.

Be conscientious of what you plug into your computer (flash drives and even smartphones can contain malware).

Be careful of what you share on social networking sites.

Monitor your accounts for suspicious activity.

Bank or shop online only on trusted devices and networks - and logout of these sites when you've completed your transactions.

TOPICS
Cybersecurity Awareness