The most effective approach to evaluating the security of complex systems is to deliberately construct the systems using security patterns specifically designed to make them evaluable. Just such an integrated set of security patterns was created decades ago based on the Reference Monitor abstraction. An associated systematic security engineering and evaluation methodology was codified as an engineering standard in the Trusted Computer System Evaluation Criteria (TCSEC). This paper explains how the TCSEC and its Trusted Network Interpretation (TNI) constitute a set of security patterns for large, complex and distributed systems and how those patterns have been repeatedly and successfully used to create and evaluate some of the most secure government and commercial systems ever developed.
Dramatically more trustworthy cyber security is a choice.
Industrial Control Systems (ICS) which control our critical infrastructures, including capabilities like bulk power generation, are unusually vulnerable to cyber attacks. The National Research Council (NRC) has reported that such an attack on the bulk power system “could deny large regions of the country access to bulk system power for weeks or even months. An event of this magnitude and duration could lead to turmoil, widespread public fear, and an image of helplessness”. While this is the subject of many ongoing current and proposed future efforts, very few are addressing the core underlying challenge of ICS security: namely, that the ICS is fundamentally insecure and in its present form cannot be made secure. A primary cause of this is that they are built on top of operating systems that cannot be made secure.
Contemporary cloud environments are built on low-assurance components, so they cannot provide a high level of assurance about the isolation and protection of information. A "multi-level" secure cloud environment thus typically consists of multiple, isolated clouds, each of which handles data of only one security level. Not only are such environments duplicative and costly, data "sharing" must be implemented by massive, wasteful copying of data from low-level domains to high-level domains. The requirements for certifiable, scalable, multi-level cloud security are threefold: 1) To have trusted, high-assurance components available for use in creating a multi-level secure cloud environment; 2) To design a cloud architecture that efficiently uses the high-assurance components in a scalable way, and 3) To compose the secure components within the scalable architecture while still verifiably maintaining the system security properties. This paper introduces a trusted, high-assurance file server and architecture that satisfies all three requirements. The file server is built on mature technology that was previously certified and deployed across domains from TS/SCI to Unclassified and that supports high-performance, low-to-high and high-to-low file sharing with verifiable security.
: The KGB officer addressed the select group of Soviet officials with his usual tone of secrecy but an unusual air of excitement: Comrades, today I will brief you on the most significant breakthrough in intelligence collection since the breaking of the unbreakable Japanese and German cyphers in World War II the penetration of the security of American computers. There is virtually (if not literally) no major American national defense secret which is not stored on a computer somewhere. At the same time, there are few (if any) computers in their national defense system which are not accessible, in theory if not yet in fact, to our prying. Better still, we don t even have to wait for them to send the particular information we want so we can intercept it; we can request and get specific material of interest to us, with virtually no risk to our agents. The Americans have developed a security kernel technology for solving their problem, but we need not be concerned they recently discontinued work on this technology. They are aware of the potential for a computer security problem, but with their usual carelessness they have decided not to correct the problem until they have verified examples of our active exploitation. We, of course, must not let them find these examples. Your first reaction to this scenario may be, Preposterous! But before you reject it out of hand, recognize that we know it could happen. The question is: Will we apply sound technology and policy before it does happen? To be sure, there are things we do not know about the probability of success of such an effort, but we can rationally assess the most salient controlling factors.
Although one senior security professional has emphasized that “it is unconscionable to use overly weak components” in a multilevel security (MLS) context, the majority of current transfer guards do exactly that. Basic guard technology is well-developed and has a long history, but most guards are built on low-assurance systems vulnerable to software subversion, and the lack of assurance limits the range of transfers. This paper describes a virtual guard architecture that leverages mature MLS technology previously certified and deployed across domains from TS/SCI to Unclassified. The architecture permits a single guard system to simultaneously and securely support many different transfer functions between many different domain pairs. Not only does this architecture substantially address software subversion, support adaptable information transfer policies, and have the potential to dramatically reduce (re)certification effort, the virtualized guard execution environment also promises to significantly enhance efficient and scalable use of resources.
research-article Using a high assurance TCB for infrastructure security Share on Authors: Mark Heckman View Profile , Roger Schell View Profile , Edwards Reed View Profile Authors Info & Claims CSIIRW '11: Proceedings of the Seventh Annual Workshop on Cyber Security and Information Intelligence ResearchOctober 2011 Article No.: 55Pages 1https://doi.org/10.1145/2179298.2179359Online:12 October 2011Publication History 2citation190DownloadsMetricsTotal Citations2Total Downloads190Last 12 Months2Last 6 weeks0 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteGet Access
U.S. Government agencies and major vendors are acti vely attempting to secure critical infrastructure networ ks, but those efforts depend on patching unsecure, commodit y systems, installing add-on security appliances, and applying other industry “best practices” that are ineffective against new attacks and software subver sion. This has unfortunately led to the conclusion that i t is impossible to secure critical infrastructure networ ks and even that a completely new, “alternative” Internet is needed. These conclusions disregard known and prove n techniques for building secure, high-assurance, tru sted systems – techniques developed as a result of years of research and engineering experience and systematica lly codified in the Trusted Computer System Evaluation Criteria (TCSEC) and related documents. Those techniques have not since been improved upon or adequately replaced, not even by the more recent Common Criteria for Information Technology Security Evaluation. In this paper, we sketch how the truste d systems technology codified in the TCSEC can be app lied today to create a secure infrastructure network.
Abstract The pervasive dependence on computers today gives us no choice but to use them in the face of professional attackers. That threat, for which software subversion is often the tool of choice, is serious and growing, so computers are increasingly a major source of risk. Responsible risk assessment and risk management requires that we not only create computers that are secure but also verify that we have succeeded. A productive history of more than 30 years of research and practical experience has produced a theory of computer security rich with solutions and tools. The greatest achievement is the demonstrated ability to build and operationally deploy truly bulletproof systems having verifiable protection. This remains the most powerful solution available for many of today's hard computer and network security problems.
14 the multilevel security constraints that precisely characterize the validity of mul-tilevel relational databases. Our model-theoretic semantics is consistent with, and extends, the Bell-LaPadula model. Compared with existing approaches, our model-theoretic semantics maximizes believability without compromising integrity or introducing ambiguity. Contrary to the claim that integrity and secrecy are in fundamental connict 1, 8, 15], our results demonstrate that integrity and secrecy could live harmoniously with each other: a multilevel relational database does not have to sacriice one for the other. Moreover, validity checking in multilevel relational databases is comparable to that in single-level relational databases in terms of complexity. Instead of developing special-purpose integrity techniques for multilevel databases, we could readily adopt those from single-level databases. Several logical extensions of this work are possible. First of all, we could consider classes of integrity constraints that are more general than key-based functional and referential dependencies. Such extensions must be made with great care however, since it might become impossible to maximize believability without choosing arbitrarily what low tuples to believe at high, as we can see from the examples in Section 1. Secondly, information in a multilevel state of the world might include the metaknowledge that relates the knowledge at multiple classiication levels, such as the polyinstantiation and referential security properties of Section 3. The notion of validity needs to be extended. A view at a classiication level should not only be valid in terms of the knowledge at that level, but also be consistent with views at other levels in terms of the metaknowledge. The complexity of validity checking is likely to increase signii-cantly, because cross-level metaknowledge interacts with single-level knowledge in complicated ways, as Theorem 4 shows. Finally, we could extend our approach to the multilevel relational model with element-level classiication, based on the connection between the two classiication schemes established in 11]. Given a multilevel database, straightforward validity checking based on the recursive deenition of validity is likely to be expensive, because it involves computing views for all classiication levels and checking their validity. Luckily, multilevel validity could be equivalently characterized by multilevel security properties, whose computation is comparable in complexity to integrity checking in single-level databases. Lemma 3 Suppose that & l (b;) = fr l i g 1in. For every t 2 r l i , there is t 0 2 r i and l 0 2 i (t 0) such that tK i ] …
The Trusted Computer System Evaluation Criteria (TCSEC) provide the basis for evaluating the effectiveness of security controls built into computer systems. This essay summarizes the definition and requirements of the TCSEC used to classify systems into seven hierarchical levels of enhanced security protection. This essay also reviews the history, technical foundations, and basic security requirements of the TCSEC. For a number of years, these criteria have been used in specifying security requirements during acquisition of products and systems, guiding the design and development of trusted systems, and evaluating systems used to process sensitive information.
This essay provides an overview of the vulnerabilities and threats to information security in computer systems. It begins with a historical presentation of past experiences with vulnerabilities in communication security along with present and future computer security experiences. The historical perspective demonstrates that misplaced confidence in the security of a system is worse than having no confidence at all in its security. Next, the essay describes four broad areas of computer misuse: (1) theft of computational resources, (2) disruption of computational services, (3) unauthorized disclosure of information in a computer, and (4) unauthorized modification of information in a computer. Classes of techniques whereby computer misuse results in the unauthorized disclosure and modification of information are then described and examples are provided. These classes are (1) human error, (2) user abuse of authority, (3) direct probing, (4) probing with malicious software, (5) direct penetration, and (6) subversion of security mechanism. The roles of Trojan horses, viruses, worms, bombs, and other kinds of malicious software are described and examples provided.
: As adversaries develop Information Warfare capabilities, the threat of information system subversion presents a significant risk. System subversion will be defined and characterized as a warfare tool. Through recent security incidents, it is shown that means, motive, and opportunity exist for subversion, that this threat is real, and that it represents a significant vulnerability. Mitigation of the subversion threat touches the most fundamental aspect of the security problem: proving the absence of a malicious artifice. A constructive system engineering technique to mitigate the subversion threat is identified.
AbstractThe termsecurity modelhas been used to describe any formal statement of a system's confidentiality, availability, or integrity requirements. In this article we focus on the primary use of security models, which has been to describe general confidentiality requirements. We then give pointers to security model work in other areas.Even if we limit ourselves to models of confidentiality, there are two related, but distinct, senses of the termsecurity modelin the computer security literature. In the more limited use of the term, a security model specifies a particular mechanism for enforcing confidentiality, calledaccess control, which was brought over into computer security from the world of documents and safes. In the more general usage of the term, security models are specifications of a system's confidentiality requirements and are not “models” at all in that they specify security requirements without describing any particular mechanism for implementing these requirements. These models specify restrictions on a system's interface (usually its input/output relation) that are sufficient to ensure that any implementation that satisfies these restrictions will enforce confidentiality. We consider access control models and interface models in turn after types are also descussed.
A security evaluation of Multics for potential use as a two-level (Secret/Top Secret) system in the Air Force Data Services Center (AFDSC) is presented. An overview is provided of the present implementation of the Multics Security controls. The report then details the results of a penetration exercise of Multics on the HIS 645 computer. In addition, preliminary results of a penetration exercise of Multics on the new HIS 6180 computer are presented. The report concludes that Multics as implemented today is not certifiably secure and cannot be used in an open use multi-level system. However, the Multics security design principles are significantly better than other contemporary systems. Thus, Multics as implemented today, can be used in a benign Secret/Top Secret environment. In addition, Multics forms a base from which a certifiably secure open use multi-level system can be developed.
Almost thirty years ago a vulnerability assessment of Multics identified significant vulnerabilities, despite the fact that Multics was more secure than other contemporary (and current) computer systems. Considerably more important than any of the individual design and implementation flaws was the demonstration of subversion of the protection mechanism using malicious software (e.g., trap doors and Trojan horses). A series of enhancements were suggested that enabled Multics to serve in a relatively benign environment. These included addition of "mandatory access controls" and these enhancements were greatly enabled by the fact the Multics was designed from the start for security. However, the bottom-line conclusion was that "restructuring is essential" around a verifiable "security kernel" before using Multics (or any other system) in an open environment (as in today's Internet) with the existence of well-motivated professional attackers employing subversion. The lessons learned from the vulnerability assessment are highly applicable today as governments and industry strive (unsuccessfully) to "secure" today's weaker operating systems through add-ons, "hardening", and intrusion detection schemes.
Gerald J. Popek合作论文数United Online Inc.1
Theodore A. Linden合作论文数available - click to provide one
No description available of Theodore A. Linden1