Whitepaper

What is Open Security Architecture

The purpose of the project is to build a modular, scalable, standards compliant, Open Source framework for integrated security facilities management. As there is a strong need of components interchangeability, heavy accent will be put on developing abstract representation of objects, policies and inheritance between them. Important strength of the project (as compared to other existing solutions) is a possibility to take advantage of some new software technologies, intensively improved and developed recently. Good examples are XML and Web Services. It is also important, that the components should be modular and conform to well known standards, because of the possibility to exchange them freely, according to special needs. I also personally believe, that making it Open Source could eventually speed up development greatly at some point in the future. Finally it speeds up development right now thanks to the possibility of using lots of already present, excellent, well tested and trusted software.

What Open Security Architecture is not

In any case this project will not concentrate on developing software directly related to security. At first the development environment (mostly Java) is in my opinion not well suited to low level, close to OS and hardware progamming. Then, such a software has usually much longer development cycle (before achieving production/stable state). Finally there is a lot of very high quality software available right now.

I do believe, that the only thing Open Source security software still lacks a bit is an integrated management.

Closer look at the Architecture

The diagram below shows main components:

OSA::HQ

This is the information centre of the whole system. Always appears as a single instance (at least unless some High Availability comes into play). Consists of:

• relational database, where information about objects and policies is stored
• some object persistency infrastructure, planned to be build using some software like Castor
• enforcement point interface consisting of:
  • servlet capable of providing XML security policies to the interested parties.
  • simple SOAP client capable of notifying interested parties, that their policy has changed
• client interface being a SOAP servlet used by various clients to manage policies.

It is worth mentioning here, that all network communiactions are secured by SSL authenticated both sides by use of appropriate certificates. The primary reason of using XML based communication in this project (instead of CORBA/RMI-IIOP) is the ease of securing XML channel (it is the feature of servlet engine, not the code itself).

Generally speaking OSA::HQ has no knowledge of particular implementation of security device it keeps the policy for. It is fundamental feature of the model used. The only thing OSA::HQ knows is so called device class (and possibly subclasses). This information is stored in the object representing device, created automatically during trust relationship initialization (more on trust relationships later).

Classes of security services could be the following:

• firewall
• tunnel riser (digger)
• traffic shaper
• router

while further subclassing may be as follows:

• firewall
  • stateful
  • stateless
• tunnel riser
  • IPsec tunnel riser
  • GRE tunnel riser
• traffic shaper
• router
  • advanced router (capable of link multiplexing)
• ... and so on

Classes and subclasses will be implemented as a boolean capabilities of devices.

Enforcement point interface serves policy encoded in XML specific for and only for the class of the device.

OSA::Control

Multiple clients are possible in various environments, under various circumstances (a GUI client, commandline client and web client come to mind). There is a need to develop one universal set of beans communicating with a server side and reusing them in every client application.

Client interface of OSA::HQ should be constructed in such way, that clients can be relatively thin, therefore making implementation of many kinds of clients easier.

OSA::Tower

This is a translator. Indeed it consists of three parts:

• an universal XSLT processor. It can be run on a separate machine, but it is recommended to implement it locally if it is only possible (quite hard trick on an ASIC based hardware). This is the most complicated part of OSA::Tower
• an XSL stylesheet, depending on:
  • class of the device (schema of the input XML depends on this)
  • output language (device specific)
Porting a new device to our framework is easy, one have to determine it's class and write XSL stylesheet for it (!)
• a shell for executing XSLT output (usually built in)

OSA::CA

This is the most isolated part of a system. During analysis phase there was a model taken into account, in which all the communications was secured by native XML Security mechanisms. Unfortunately the implementations of the above are still very immature. Therefore (at least for now), communication is always made point to point and secured by SSL. On the other hend, from the CA's point of view it does not matter if it deals with SSL or XML Sec connections.

The idea is simple: every other part of the system must have own certificate signed by OSA::CA. Initialization is done semiautomatically during components installation. Namely:

• component applies for certificate
• the request is registered by OSA::CA, fingerprint of a new key shows up in an administration console of CA. It is also shown on a component's machine
• if they match, OSA::CA administrator gives his permission for the certificate to be signed and sent back

These certificates may have nothing in common with the certificates used for VPN authentication.