One of the problems the Open Text ECM suite faces is the fact that the suite wasn't designed as a suite but put together from a large and diverse set of distinct applications that Open Text build and acquired by purchasing companies. This has put a lot of integration challenges over the years that, frankly, Open Text has done well to meet, however this diversity makes it very difficult to talk about characteristics of the suite as a whole. When it comes to the security charcteristics, it is vital to undestand the application built on the suite in order to be able to assess the security of the deployed implementation.

That is probably true for all multi-purpose tools, even non-technical ones; a pocket-knife is a necessary tool for survival in many real-world situations and yet in many other situations provides a very serious security hazzard. The knife hasn't changed, only the circumstances and environment in which the knife exists. The same can be said for any multi-purpose "platform" like the Open Text suite; in fact the same can be said for the workhorse of that suite, the previously labeled Livelink Enterprise Server. With it's ability to be extended to solve problems as diverse as tracking internal controls to a records management system tracking physical papers (and MANY points in between), LES cannot be thought of as a single entity. 

LES Main Architecture in Simple Terms

Livelink is an interpreter of a proprietary computing language called Oscript -- from a security aspect this means that we need to be concerned with not only the code that is the interpreter but also the interpreted code. The interpreter itself is written mostly in C++ and (again from a security perspective) has the most crucial task of not just interpreting and executing Oscript but also ensuring that the individual interpreted pieces of Oscript code are isolated from each other. The interpreter is completely blind to the semantics of Oscript, it provides a number of abstractions (APIs) and data types for Oscript programmers to use but has no more connection with the code being run than any operating system has about the programs it runs. In fact, the interpreter that is Livelink Enterprise Server is more like a full-blown operating system than it is an application itself.

On many levels, Open Text has been very smart about how Livelink has been developed. From it's humble beginnings it has avoided many of the historic pitfalls for application security (though it isn't clear that was a deliberate decision or a lucky consequence of other decisions).

1. It is a user-space (non-privileged) process that requires very little special access to run (in Unix, none at all, in Windows it requires rights to run as a service) and is isolated from the OS itself. The main consequence of this (from a security perspective) is that IF some Oscript writer figures out how to break out of the Oscript jail Livelink creates and gains unauthorized system-level access, while they are in a position to circumvent all security for Livelink itself, the rest of the processes and applications running on the server cannot be compromised because of this breach.
   
2. Due mostly to the desire to stay operating system agnostic, LES uses a single, dedicated file system-based hierarchy for it's code, configuration, and logging files; an installation in Windows or Unix is similar and does NOT generally include installation of files into system directories. Again, this design choice had more to do with platform independence than it did with security, but it does provide the ability to easily isolate each LES service meaning that a single server can securely run multiple and distinct LES-based applications.
3. While it isn't enforced, unfortunately, Open Text has a well-defined internal hierarchy that can allow for very fine-grained file system-based access control ensuring, for instance, that the 'bin' directory cannot be written to by the LES application itself, that the 'logs' and 'config' directories cannot execute programs, and otherwise isolate activities such that it makes it very difficult for unauthorized os-level activity to occur.
   
   1. Their have always been exceptions to this, the most notable is the 'filters' that can create os-level command scripts that are then executed as a part of normal execution path (though it isn't clear that the fault in this case is really Open Text's in that the problematic code is licensed from a 3rd party, that point is moot from a security perspective).
      
4. As a client-server application that uses a web server as a transportation conduit only that doesn't require access to the DB or admin servers, LES has the ability to be deployed in multiple network tiers with only a single communication port required betwen most of the network tiers (though not always the case, this has been true for years). The consequence of this decision is that the application can be isolated enough such that the only approach possible to escalate privileges is to break the application ... that is, even if a malicious user breaks the web server, if it is isolated on it's own network then the only access to Livelink is via the same network port and protocol that the web server would use.
   

Showing it's age

The architecture of LES has allowed for a somewhat old (some might say mature) application to meet the requirements of some very picky security professions; I've heard one high-profile defense customer of Open Text comment that they thought Livelink was "about 5 years ahead of other CMS applications" in terms of secure deployment. The 'platform independent' design choices provided the ability for enhanced security.

That being said, all is not perfect. While Livelink (the interpreter) does an excellent job in protecting itself and developers of Oscript from older, programming security issues like buffer overruns, heap exhasution and other historic problems (to it's credit!) it was built before the times of Cross Site Scripting (XSS) and Cross-Site Request Forgery (XSRF) attacks that are commonplace today. While Open Text can hardly be blamed for this, the fact is that the software is rife with opportunities for XSS and CSRF attacks to be placed because it was built with the notion of a trusted user base that needs to be protected from the external bad-guys and is having difficulty in changing that paradigm to one that sees the internal users as essentially untrustworthy.

XSS and XSRF are both difficult bugs to protect against after the fact ... to be successful one must be able to validate all submitted forms to be sure that they originated from a valid session and haven't been altered AND that all user input is sanitized (removing all 'dangerous' characters). The problem is that in an application as old as Livelink, there are a number of 'dangerous' characters that are also valid characters used within Livelink ... in our anology, some Livelink submitted forms contain "knives" but it is not possible to determine whether one needs the knife for survival or malicious purposes.

While Open Text could redesign Livelink (and I predict they will be forced to at some point) to be able to add enough context to understand what the knife is needed for (and remove it when it isn't needed), right now their solution lies in keeping with the Trusted User model. So, for instance, while folder and project overview pages and HTML/XML Appearances offer the relatively easy ability to insert XSS and XSRF attack-code, Livelink provides the ability to limit who can create such "trusted content" thus limiting the risk. Unfortunately, this approach doesn't scale well and it makes it difficult to use Liveink effectively within a large, mostly untrusted user base.

Livelink comes from a time before the world knew about the two most prevalent attacks today (XSS & XSRF) so one can hardly point a finger of blame, however that doesn't change the reality either. Although a true workhorse, LES does have it's limitations you should be aware of; if you can't trust your users then you probably want to spend some time locking down LES.