Written at 2002/03/11.
For a real world policy and topology with about 900 networks, 400 routers, 100 groups, 400 rules and many wildcard or any objects, CSPM needed about 3 hours to generate configurations for about 30 managed devices. NetSPoC needs less than 30 seconds for the same task.
There are no documented import or export functions for CSPM. NetSPoC uses a simple, well defined language stored in plain text files.
When using CSPM, only a single user is allowed to change the database. For NetSPoC, the topology and policy description may be split into different files, which may be changed by different users simultaneously.
Changes of the CSPM database can't be version controlled. The text files of NetSPoC's language may be easily be integrated into a version control software like CVS. This is in particular important for the task of security management.
CSPM runs only on windows NT (next version W2k). NetSPoC is written in perl and should be portable to many platforms.
CSPM provides a graphical user interface which is nice to use for a small to medium size topology. It becomes nearly unusable for a large topology. NetSPoC provides no GUI at all.
CSPM supports the definition of IPSec tunnels and network address translation. This isn't supported by NetSPoC currently, but planned for the near future.
CSPM has build-in support for transferring generated code to the managed devices. NetSPoC uses separate scripts for this task which are currently not made available.
The policy description language of NetSPoC is similar to CSPM's graphical policy and topology description, but there are differences:
CSPM preserves the order in which rules are stated.
For NetSPoC, deny rules override any permit rules. Otherwise the order of rules doesn't matter.
NetSPoC handles clouds, routers and PIX firewalls all as routers.
CSPM treats an interface as a physical interface with a name like router.Serial0.
NetSPoC treats an interface as a logical interface with a name like router.network. The name of the underlying hardware is given as an attribute. There may be multiple logical interfaces for one hardware interface.
In CSPM, perimeters are used as an implicitly defined group of all network objects of a security domain. When used in a rule, a perimeter object is compiled to an ACL with one entry for each network in that security domain.
For getting smaller ACLs, CSPM provides the notion of wildcard networks. They are used as a representation for the whole security domain as well. But when used in a rule, the corresponding ACL entry uses 'any' (i.e. network 0.0.0.0/0.0.0.0) for a wildcard network. CSPM automatically inserts 'deny' rules to prevent intervening networks getting undesired access.
In NetSPoC's description language, perimeters are called 'every' objects and wildcard networks are called 'any' objects, but have similar meaning.
CSPM doesn't allow to define groups of groups or groups of interfaces.
There is no such limitation for NetSPoC.