Toward a Safer and More Secure Cyberspace (2007) / Chapter Skim
Currently Skimming:
4 Category 1 - Blocking and Limiting the Impact of Compromise
4 Category 1 - Blocking and Limiting the Impact of Compromise
Pages 83-112
The Chapter Skim interface presents what we've algorithmically identified as the most significant single chunk of text within every page in the chapter.
Select key terms on the right to highlight them within pages of the chapter.
From page 83... ...
A great deal of experience in dealing with cybersecurity issues suggests that no individual defensive measure is impossible to circumvent. Thus, it makes sense to consider defense in depth, which places in the way of a cyberattacker a set of varied hurdles, all of which must be penetrated or circumvented if the cyberattacker is to achieve its goal.
|
From page 84... ...
security community to articulate principles of sound design and to meet the goal of systems that are "secure by design." On the basis of examinations of a variety of systems, researchers have found that the use of these principles by systems designers and architects correlates highly to the security and reliability of a system. Box 4.1 summarizes the classic Saltzer-Schroeder principles, first published in 1975, that have been widely embraced by cybersecurity researchers.
|
From page 85... ...
The software development model most relevant to this state of affairs is often called the waterfall model, explicated in considerable detail by Boehm.2 This model presumes a linear development process that proceeds from requirements specification, to design, to implementation/coding, to integration, to testing/debugging, to installation, to maintenance, although modified versions of the model acknowledge some role for feedback between each of these stages and preceding ones. But despite its common use in many software development projects (especially large ones)
|
From page 86... ...
In addition, any skeptical users may be allowed faces, inputs, state transitions, internal state information, outputs, and exception conditions. Put differently, the paradox is that successful principled development requires a nontrivial understanding of the entire system in its ultimate form before the system can be successfully developed.
|
From page 87... ...
Saltzer and M.D. Schroeder, "The Protection of Information in For these reasons, software development methodologies such as incremental development, spiral development, and rapid prototyping have been created that presume an iterative approach to building systems based on extensive prototyping and strong user feedback.
|
From page 88... ...
With different parties involved, especially in different organizations, communications difficulties are inevitable, and they often include incompatibilities among interface assumptions, the existence of proprietary internal and external interfaces, and performance degradations resulting from the inability to optimize across components. This point suggests the need for well-defined and carefully analyzed specifications for the constituent components, but it is obviously easier and less expensive to simply assume that specifications are unambiguous.
|
From page 89... ...
should be undertaken aimed at adapting the design principles of Box 4.1 for use in realistic and common software development environments that also do not make excessive sacrifices for performance or cost. Today, there are wellestablished methodologies for design-to-cost and design-for-performance but no comparable methodologies for designing systems in such a way that security functionality can be implemented systematically or even that the security properties of a system can be easily understood.
|
From page 90... ...
Threat-based design is one possible approach that requires the identification and characterization of the threats and potential attacks, finding mechanisms that hostile parties may employ to attack or gain entry to a computing system, and redesigning these mechanisms to eliminate or mitigate these potential security vulnerabilities. A further challenge is that of undertaking such design in a way that does not com
|
From page 91... ...
may well be usable for improving security. Compared with software-based security functionality, hardwarebased support for security has two primary advantages.
|
From page 92... ...
Dwoskin, and Z Wang, "Architecture for Protecting Critical Secrets in Microprocessors," Proceedings of the nd International Symposium on Computer Architecture, IEEE Computer Society, Washington, D.C., pp.
|
From page 93... ...
A second element is a trusted software module running in concealed execution mode that performs the necessary protected computations on users' secret keys, thus protecting all key information (the keys themselves, the computations, and intermediate states) from observation and tampering by adversaries.
|
From page 94... ...
TPM is a step forward in hardware-based security, but there are some limitations, such as the fact that the TPM definition of "remote attestation" enables checking the integrity of the bits on the entire software stack on program launch, but it does not do any checks after that for dynamic hostile code insertion and modification. TPM also has a threat model limited to software attacks and does not provide any coverage for even simple physical attacks like bus or memory probing; these probably should be considered because of the easy theft or loss of mobile or personal computing devices.
|
From page 95... ...
is also an important property. Improving the tamper resistance of hardware can increase the robustness of a system, because security functionality implemented at a high level of abstraction (in software)
|
From page 96... ...
indicates that it is possible to create a normal multitasking machine in which nearly all applications can be run in an execute-only mode. A second dimension of tamper resistance is that of increasing the difficulty of reverse-engineering a given object code.
|
From page 97... ...
In more recent times, early microprocessors such as the Intel 8086 lacked an instruction set architecture that could support virtualization, and this deficiency persisted through the instruction set architecture of the Pentium.13 As the instruction set evolved to be more capable and processor speeds rose, virtualization of these microprocessors became feasible -- and was useful as well, because of the increasing needs for isolation in a changing threat environment. The basic requirements for virtualization were described in 1974 by Popek and Goldberg.14 The basic work on virtualization to run multiple operating systems was done at IBM for the 7044,15 the 360/40,16 and the first product CP/67 for the 360/67.17 Virtualization makes it possible to run multiple operating systems (and their applications)
|
From page 98... ...
But other services can exploit the services provided by secure kernels as well. For example, security services can benefit from isolation because they are less easily subverted in that configuration and have greater tamper resistance.
|
From page 99... ...
so that different instances of a program are not subject to common attacks. 4.1.2.5 Component Interfaces Sound interface design must be integrated into system architecture.
|
From page 100... ...
This effort has user- and system-oriented aspects, particularly in trying to reduce the semantic gap between what can be derived from specific interfaces and what can be obtained by detailed examination of source code, libraries, compilers, interpreters, operating system environments, networking, and system administration tools. Particular emphasis is also needed on the use of analysis techniques for defining and analyzing system interfaces so that the desired behavior that they represent and the dependencies among different interfaces can be more easily understood and controlled.
|
From page 101... ...
They must also be incorporated into any evaluation processes, such as those built into the Common Criteria process.21 • he supplementing of the design and development process with assurance T techniques specifically relevant to the interfaces, including the ability to identify additional hidden and detrimental functionality that can be accessed through the interface in undocumented or unspecified ways. For example, an interface might include a test function inserted dur ing debugging that exposes cryptographic keys.
|
From page 102... ...
and increasingly sophisticated cryptanalytic tools mean that the study of even these very basic cryptographic primitives (encryption and hash algorithms) has continuing value.
|
From page 103... ...
Threshold digital signatures are a simple example of a multiparty computation. This functionality is useful (though it has not yet enjoyed widespread practical use)
|
From page 104... ...
Such cases will often reveal security vulnerabilities if they do exist. Testing can focus on particular attributes beyond just functional behavior.
|
From page 105... ...
Analysis and semantics-based 24 Hao Chen, David Wagner, and Drew Dean, "Setuid Demystified," Proceedings of the th uSenIX Security Symposium, pp. 171-190, 2002; available at http://www.cs.berkeley.
|
From page 106... ...
However, as noted in Section 4.1.1, a great deal of real-world software development makes use of methodologies based on spiral and incremental development in which the software "evolves" to meet the new needs that users have expressed as they learn and use the software. This means that it is an essentially impossible task to specify complex software on an a priori basis.
|
From page 107... ...
Although security efforts should focus on reducing vulnerabilities proactively where possible, it is important that a system provide containment to limit the damage that a security breach can cause and recovery to maximize the ease with which a system or network can recover from an exploitation. Progress in this area most directly supports Provision II and Provision III of the Cybersecurity Bill of Rights, and indirectly supports Provision VII.
|
From page 108... ...
More over, such methods can interfere with efforts to debug software undertaken at the object code level, as well as with legitimate third party software add-ons and enhancements, suggesting that there are trade-offs to be analyzed concerning whether or not automatic rewriting is appropriate or not in any given situation.) • isposable computing.
|
From page 109... ...
Illustrative research topics within this domain include the following: • ebooting. Rebooting a system is a step taken that resets the system R state to a known initial configuration; it is a necessary step in many computer operations.
|
From page 110... ...
0 TowARd A SAFeR And moRe SeCuRe CyBeRSPACe • nline production testing. An essential element of recovery is fault o identification.
|
From page 111... ...
Software engineering advances also leverage basic research in areas that seem distant from system building per se. Success in developing tools for program analysis, in developing languages for specifications, and in developing new programming languages and computational models typically leverages more foundational work -- in applied logic, in algorithms, in computational complexity, in programming-language design, and in compilers.
|
From page 112... ...
TowARd A SAFeR And moRe SeCuRe CyBeRSPACe edly not random. A test and evaluation regime oriented toward reliability will not necessarily be informative about security.
|
Key Terms
This material may be derived from roughly machine-read images, and so is provided only to facilitate research.
More
information on Chapter Skim is available.