The meta-level structure of Cherubim architecture permits
reflection; that is, it permits the semantics of the operations
of the security model to be changed dynamically. Thus, the architecture
allows the system security personnel to easily
change the default behaviors of security agents using a well-defined
meta-level protocol.
Applications of reflection in a security architecture include but are not restricted
to improved control of the system; counter-attacking security
attacks by increasing surveillance, auditing, and security measures; isolating, monitoring,
and spoofing compromised remote nodes; providing fault-tolerance by
reconfiguring a security system as nodes fail; and replacing compromised
encryption or security algorithms.
For example, the meta-level protocol allows improved control of a security system.
It permits maintenance of meta-level information about security agents
including interface/class names and class-related
statistics, allows dynamic binding of different concrete customized
classes to standard interfaces, and facilitates visualizing and reconfiguring
the internal structure of the security
architecture. The proposed study for introducing reflective features into
security architecture will be based on our previous work on building
Choices, a distributed object-oriented operating system, through refining
frameworks with reflective structures in C++ ,
and developing a new visualization technology
for monitoring, verifying and refining architectural abstractions in fine
granularity.
The efforts we will make to develop reflective structures for our
proposed security architecture will focus on the following three areas:
Extension to the IDL language to support hidden security features
Although the OMG's IDL provides a language and machine independent
mechanism to specify application interfaces, application developers often
have to code security features into an application. This is detrimental
to both flexibility and reusability. Therefore we propose extensions to
IDL based on the hidden software capability model presented in
The extensions will include security information in a form that
can be used for dynamic modification of the security provisions.
Application developers will specify
security mechanisms and policies or just desired quality
of security to the security system as a precursor to
any programmed access to objects
within applications.
Through the IDL extensions, the security system will provide
the appropriate security using a combination of the security requested
by the application developers and any predetermined security policies.
Besides providing the extensions, the new IDL compiler will compile-time verify
security information obtained through
the reflective structures.
Moreover, we will also extend the IDL runtime so that
the security measures applied to the applications
as they use the interface
can be queried, consulted and modified.
Providing secure security interfaces that are hidden from an application
separates security provisions from the application.
Security features may be added unobtrusively later without changes
to an application.
However, the safe use of these reflective features is a question of
concern and will require analysis in the project.
On the other hand we are also interested in how IDL constructs like
type, module, and interface may be integrated with security attributes
like security domains, access rights and policies through some well-studied
object-oriented concepts like inheritance, polymorphism and subtyping.
Customizable binding mechanisms for method dispatching and
interface-class mapping
Because of the separation of interface and implementation, we can
choose appropriate security policies, encryption algorithms,
authentication protocols, and authorization/auditing mechanisms
based on user-specified security quality. Although many existing approaches
only allows static binding or at most configure-time binding, we believe
this inflexibility seriously inhibits the usefulness and adaptability
of a security system. For example, dynamic binding could be decisive
in attempts to defeat unexpected security attacks.
Since the binding mechanism is part of the reflective structure
we can customize the binding mechanism to meet different
security function requirements.
For example, the security system could
select appropriate security policies and mechanisms automatically
for a given interface given a user-desired security quality.
The same interface may supply different implementations for different
applications depending upon the choice of security quality.
Security quality might impact the choice of verification and auditing process
for a security agent.
Moreover, this customizable binding mechanism can
support performance optimizations and fault tolerance.
For example an automatic swizzling mechanism can be incorporated as part
of the binding mechanism so that, after the arrival of a security agent and
its verification, the agent is converted from a complex external
form into a simple internal one.
We can also using such binding techniques to support fault tolerance
by replication, voting, and runtime implementations
capable of handling the Byzantine General's problem.
We believe this feature is very useful in a military setting where
attacks occur unexpectedly and immediate response is critical.
Architecture-Aware visualization for monitoring and refinement
The reflective structure also supports technology for
architecture-aware visualization.
In a security setting, visualization can compare actual information flow
with the original security requirements and system design.
It is hard to build a good security system. One of the reasons
is that software developers cannot easily compare an implementation of
a security scheme with its design or design principles.
From past experience of developing large scale system software,
we argue that architecture-aware instrumentation and visualization
can help perform such comparisons.
One of the security properties of interest in a dynamic security system
is that of least privilege. Using architecture-aware instrumentation,
we can search for anomalies in a specific implementation configuration
that do not conform to the principle.
We can also use architecture-aware visualization to identify subtle changes
in behavior of the system, perhaps caused by attack or reconfiguration.
The architecture-aware visualization system also forms an important browsing tool
for the auditing framework and its implementation is included as part of the base-line
instrumentation facilities.
