Page 103 - DCAP309_INFORMATION_SECURITY_AND_PRIVACY

Unit 7: Network Security

of known attacks. These methods would like to be automated (as human responses are too slow Notes
to avert damage), executable, broadly deployable, and must need no application modifies. Here
we will study three technologies that provide imperative levels of protection against unknown
attacks: software fault isolation, intrusion detection through program analysis, and fine-grained
mandated access controls.
These technologies distribute an imperative property: they do not depend on the accurate operation
of the programs; instead, they offer a secondary layer of protection should a program be breached
and corrupted. It is possible that these systems may also enclose flaws; but in order for a victorious
exploit to take place, both the application and the secondary protection need to be undermined at
the same time. As bugs will carry on to be patched, it is much less expected that two overlap bugs
will be present and be known concurrently than that a single error will be known.

7.5.1 Software Fault Isolation

The first expertise, Software Fault Isolation (SFI), produced by Wahbe et al. is a method to
generate Java-like sandboxes for dynamically-loading random code in a language-neutral
manner. Unlike JVM-based systems, it can be functional in spite of source language and compiler.
The only semantic restraint is that dynamic code generation is not permitted inside a fault-
isolated module.
SFI functions at the assembly level on a code module via a amalgamation of static analysis and
dynamic checks to generate the sandbox. The system provides each module its own concealed
memory space in which it is isolated as part of the bigger program. The static checks make
certain that all statically determinable jumps only appear within the module and to permissible
external functions, forming the basic structure of the sandbox.
The dynamic checks are inserted onto every load, store, and dynamic jump (apart from for those
that can be deleted through static analysis) to make sure that the program can’t flee the sandbox
produced by the static analysis and assigned private memory. These checks do not guarantee
fine-grained accuracy (like bounds checking) but only a coarse-grained correctness: the module
is not permitted to read or write outside its permissible memory ranges or carry out code not
enclosed within the module’s code base or permitted external functions. Because the module is
now limited both statically and dynamically, it is efficiently sandboxed from other modules
inside a larger application.

7.5.2 Intrusion Detection by Program Analysis

The second most important technique, host-based intrusion detection by program analysis, was
first projected and experienced by Wagner and Dean. This IDS executes a static analysis of the
program to generate an abstract, non-deterministic automata model of the function and system
calls. While the program is implementing, it matches the system call pattern with a running
copy of the automata. If the program ever tries a system call which disobeys the model, the
system assumes that a burglar has tainted the program.
Dissimilar to other intrusion detection methods which depend on either sample inputs or rule
sets, this technique has a demonstrable zero false positive rate, removing all false alarms. This
means the intrusion detection system can begin automatic responses: blocking the system call,
shutting down the corrupted program, and alerting the administrator. The zero false positive
rate is because of the programmatic nature of the IDS, which encloses a model that displays all
possible legal paths via the program, making sure that any detected deviation from the model
is not caused by the program’s code but by code inserted by a virus or an attacker.
The biggest issue is the very elevated run time needed for the IDS to function. This is because of
imprecision in the model of implementation since the IDS only have access to system call

LOVELY PROFESSIONAL UNIVERSITY 97