لطفا منتظر باشید ...
A Modular Model
The preceding definition of a network security tool, although technically accurate, does not offer a tangible description. Using this definition as an overall theme, however, we can formulate a more functional model of network security tools. The modular model of network security tool design (see Figure 1.1) separates a network security tool into separate objects at three layers. Each layer has a different level of specificity, with each object responsible for a different area of functionality. The three layers, component, technique, and control, adequately break down a network security tool into an abstract entity, making it much easier to conceptualize and build. A fourth entity, class, depends on the technique(s) that the tool employs and is set at the technique layer. Due to the layering paradigm, dependencies with the modular model of network security tool design (referred to from here on as the modular model) are naturally hierarchical. Objects at one layer have dependencies on one or more objects below it. Techniques depend on one or more components, just as the control logic depends on one or more techniques.
Figure 1.1: The modular model of network security tool design.
Component Layer
At the most fundamental layer is the component. Components answer the question, "How does this tool do what it does?" They are task-oriented and specific at what they do. Components tend to outlay the development requirements and restraints of a tool, because certain components might have dependencies that require additional components to be installed or certain other files to be in place on the system. For example, libnids is a component for building network intrusion detection systems that requires the libnet component to be installed before you can employ it.Figure 1.2 shows the components profiled in this book and their relationships.
Figure 1.2: Components.
Technique Layer
Above the component layer is the technique layer. Techniques answer the question, "What does this tool do?" They are a bit more abstract than components and are more solution-focused. Techniques consist of one or more components and imply a degree of analysis or control logic. Much of the tool's major work occurs at this layer, and as such the tool's class (described as follows) is bound here.For example, packet sniffing is a technique built on top of the libpcap component. It employs libpcap to perform packet capture, but packet sniffing requires additional processing of the captured data and usually functions with a specific goal in mind (such as e-mail or passwords). The techniques profiled in this book appear in Figure 1.3.
Figure 1.3: Techniques.
Control Layer
Finally, above the technique layer is the control layer. The control layer is a general abstract layer that groups together the individual pieces below. The control layer is like a delivery mechanism for techniques. The control layer is less concerned with security-related topics than general program cohesion. Anything that does not logically fit at the component or technique layer stays here, including the user interface, overall program flow, end-user reporting, and internal data correlation. Because it is such a general layer and is not security-specific, there is not much singular focus on it in this book.
