Enabling
Enterprise Security Management

For every codified thought there is a purpose, a requirement that meets a need. The structuring and aggregation of logic and data is the essence of small programs that as building blocks can become large applications.  Regardless of the size there still remains a purpose with a requirement that fills a need sustaining its life expectancy.

For example, in years past the long distance telecommunications companies bread and butter application was their billing applications that serviced the call data record (CDR)s based on Bellcore Labs standards.  With the advent of more sophisticated switches, embedded applications for processing CDRs was fulfilling a newer advanced  requirement.  While not reaching it's absolute end of life, it evolved or was reinvented so that in the reincarnation it could support more advanced hardware capabilities or even replace hardware as something known as a soft switch.

People speak about killer applications. As far as the telecom firm is concerned the billing application is it. To the rest of the world an application like Lotus 1-2-3 was the killer application of our times with the coming of the IBM Personal Computer because millions of licenses were sold. It's utility verses that of absolute automation of the process is what makes it a publicly accepted killer application.  And, the world waits for the birth of the next killer application.  The question is, will it ever come to pass?

It seems disingenious to believe that disseparate software work products could be put together in such a way as to build a killer application.  After all each, and I am referring to open source software, was constructed from totally different requirements without a shred of thought documented with respect to cross purposes, dependencies or supportive requirements.  However, that is exactly what has happened with the open source movement.  For example, a unparalleled development of the web server and the application server.  What does seem common that often a derivative work is born from a work product such as the need for the servlet container whose purpose was not originally inspired as a requirement in Apache Server or any of the early web servers for that matter.

The open source inventory of work products has reached a critical mass in terms of variety, quality, distribution, support and all attributes of purpose, usefulness of utility driven by requirements within the framework of open standards.  And yet it seems as though the IT industry is still grasping for meaning and understanding as to where open source fits in the scheme of things. Even firms that publish proprietary applications cannot figure it out.

The next killer application1 is going to the defining moment for the open source movement.  The next killer application will be a magnitude greater than the standalone office application and surpass modern day enterprise applications.  In all of the IT industry we hear about the standard mega-applications such as Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), Supply Chain Management (SCM) and Sales Force Automation (SFA) solutions that address functional business areas build on proprietary platforms.  Every computer software company web site one visits whether it is IBM, Microsoft, Hewlett-Packard, Computer Associates or Oracle etc., there is one major functional area missing.  Rather, we believe it is missing because the past nature of it's existence. The function was not a crucial management function within corporate America or within the Business Schools and Universities curriculum's. Safety and Security is no where found on anyone's management radar screen.  However, this situation is about to change.  With a convergence of IT security and traditional corporate security, with a pressing need of traditional corporate security since 9/11, the need for corporate governance and compliance, business entities have literally invented a new corporate management function.  This has been witness by creation of new job titles and roles such as Chief Security Officer or Chief Information Officer.  Unfortunately, there has not been any dedicated applications equivalent to those such as CRM or ERP to support this new convergence.  The traditional corporate security department was run by security directors/officers/managers that have been typically concerned with access control, guard services or monitoring and surveillance.  The security department has been viewed as a cost center primarily because there have never been any long term studies that show return on investment on these expenditures.  Quantification is difficult at best because safety and security has never been commoditized into its various aspects that could earn it a reputation front and center in the boardroom.  From mitigation of risk and liability, workplace violence prevention, zero tolerance for shrinkage, to intellectual property protection, hard data is simply not available that is a result of direct management over all aspects of safety and security.

The next killer application is the Securitydirector, LLC Enterprise Security Portal (ESP).  It may become recognized at some point in the future as a killer because it is differentiated by several key attributes:

  1. It is not constructed using proprietary platforms and resources.
  2. It is built entirely with open source software.
  3. It addresses and supports this new crucial management function in the enterprise called Safety and Security Management (SSM) or better titled Enterprise Security Management (ESM).

Securitydirector, LLC has been carefully crafting the Securitydirector Enterprise Security Portal (ESP) on a business model premise of offering Fortune 500 professional level security management services to small and medium size firms that would not be able to afford the same quality and level of services from a dedicated department as found in the larger corporations.  The ESP is a management tool that facilitates messaging and reporting for a precise level of knowledge diffusion throughout the organization.



In this paper, I am proposing to write a text that is both technical in documenting the construction of a major portal application using open source software and its practical application driven by a new framework of requirements that encompasses a convergent industry evolving into an entirely new business segment that will have in the future corporate board level visibility in managing better profitability through managed safety and security.

I believe this proposal is supported by a number of factors.  Given the fact that the ESP's evolution was a slow process between the concept owner and the IT architect, the text will make direct correlations between each of the open source packages used and the requirements it fulfills.  It's magnitude is greater than a standalone office application yet the number of users will surpass even site licensing of previous killer application. And, the ESP has the potential of bridging the gap in safety and security between the public and private sectors.  

But, what makes the ESP a defining moment for the open source software movement?  To answer this question I think there are 2 key economic factors that will set open source apart from the old traditional ERPs and CRMs of the world.  The defining moment has everything to do with economics.  Building the ESP required only the services of a highly skilled IT architect.  Almost no outsourcing to offshore development companies and only 10% programming labor was required to build a product in record time.  Using all open source code and the skilled integration techniques of an architect, the chief difference between branded portal server products and the ESP is the later had a lower cost of labor and shortened time to delivery.  Development costs are considerably lower because a company does not need to train programmers to support and write code to a specific brand of portal server products and development environments.  Utilization of more generic skills is more cost effective. Base line systems administration and support may be the only unchanged factor.

This defining mega-application will relieve the fear of open source utilization because the most fearful constraint is the unknown question of package integration.  What will be the results?  For example, when posing the question to news groups or forums as to whether ZOPE would work on top of Jetspeed, and oh yes, it has to be operational within a totally secure session, no one really could give an answer because the 2 packages were never integrated before in such a way. The killer application will show the ingenious ability of putting together entirely disseparate open source software products in spite of their different requirements and unparalleled development.  The major labor of the architect involves the research and planning that must be considered when proposing the integration of open source packages.  The object of course is to not reinvent the wheel and yet still meet the requirements developed from concept owners. Demonstrating the effectiveness of building products from the open source inventory takes the risk out of a possible failure of integration. In the final analysis, the results will support the premise of the defining moment.

Another aspect and demonstration of flexibility in support of the defining moment has to do with scalability both at the application server level and the portals ability to service requirements from distinct vertical markets or industries.  The requirements once again drives the technical side because the ESP must support many companies simultaneously in their own Intranet like vacuum. In other words, portal utilization and customization appears to be each client's own unique instance even though 100 other firms are using it. Profiling and roles along with a finer granularity of security within system management of such things as content management for knowledge aggregation and delivery is what elevates the ESP as a Super Star Application.  Once again the ability to easily integrate diverse open source work products is far superior to similar efforts using the inventory of proprietary software to do the same.  Usually you are captive to the branded portal server solutions and tools.  This runs its own risk of obsolescence, branded market consolidation or product sun setting.

Unlike current day enterprise applications the ESP architecture is not mired down with legacy deficiencies or self serving perpetual IT solutions do to the so called monolithic bound applications.  Many layers of unproven attempts of web services and so-called enterprise services architectures, data mining or any other acronyms one cares to use to describe yet another way IT can restructure the world to improve business performance and competitiveness, is probably costing more than it is saving.  Or, in the final analysis, the increase in productivity is marginal.  The proponents of web services seems to be a sales pitch for more IT services that can produce more metrics, more data and better information.  The evolutionary path of the ESP through the use of an open standards based approach is to take the next logical step, taking information and transforming it into knowledge.  This end product is what management finds useful in all types of decision support situations.  In the security and intelligence community the term "actionable intelligence" is derived from data and information that has been transformed into knowledge.  

Web services in a component based facilitated layer is all about optimizing and automating the transaction process.  To support new relationships a very clean level of abstraction is needed in order to make it work and it would seem very clear that as more component integration is required the complexity increases as well.  Thus process modeling is used to configure and control the behavior of an application.  Components are used to integrate the enterprise applications.  This should not be confused with the idea of building the ESP with open source packages or software work products running on top of a supporting Java or object oriented implementation.  As an example, Silva is a Zope Product with its dependencies on Zope.  The ESP has its own processes defined where appropriate for example an incident report that goes to the security director when filed.  But the development of new initiatives belies no dependencies on mounting a portal technology or web services onto existing enterprise applications and is not under the same handicaps as the aging enterprise applications as we know them today. While we cannot deny that the CRM and ERP enterprise applications have tried to raise the bar on productivity, their failings often times were not necessarily from bad design or logic, rather from weaknesses in human nature itself in the use and appropriate applicability. There is very little literature available on those colossal IT enterprise projects that failed whether it happened during development, deployment or actual use with analytics on operational results. It is sufficient to say that large firms like Motorola have not been saved by their impressively expensive development and deployment of enterprise applications to smooth out their business fluctuations or even predicting that a major product line is entering early into it's end of life due to competitive pressures. They have the massive data but not the human means or organizational behavior to figure out what the semantics implies. The knowledge leading to sound actionable intelligence diffused to the right people at the right time is simply not part of the equation. Because the construction of the ESP is so unlike that of the enterprise applications we know today, the portal will give firms strategic advantages over fuzzy areas of decision support because the customization to achieve such high level goals as knowledge, actionable intelligence, and early warnings or alerts facilitates management with preemptive powers and procedures in support of plans and policies.

Having said all that based upon what we think the life span of the ESP will be, which is of course an inexact prediction into the future, we think the ESP is going to have a very unusual life cycle. Like most software products, it will be deployed throughout the world, mature and go through the usual revisions, but in a parallel dimension the ESP will start to become a Knowledge Operating System.  Initially, it will appear to be like any other targeted enterprise application for use by management in the daily mundane tasks of protecting operations and assets. But like the child development process, the system will become smarter and smarter as the database matures from the ability to aggregate data from hundreds of client companies using the portal. Knowledge management tools from text analysis, topic maps to summarization including early warning alerts will accelerate the ESP into a second generation life cycle. The chances of completing a second life cycle are very good given the fact that it is built using the open source model. However, the likelihood of advances in knowledge engineering will also propel a 2nd life cycle.

So, the question has to be asked why is it important that this text be written? The ESP will precipitate 4 general revenue streams during it's lifetime. First, there is the revenue generated by it's subscription based Application Service Provider model, second by the simple nature of firms engaging the portal it will generate consulting revenue on the safety and security incidents for directors, third it will generate IT consulting development, support and administration and fourth as a knowledge engine, Securitydirector will have the ability to sell it's knowledge gold mine. Consequently, it is important to document both the underlying technical infrastructure and the usability of the application itself.  The fourth revenue stream will come on-line in the second life-cycle. It is also conceivable that licensing from government or business entities that wish to have Total Content Ownership or in-house deployments will be an additional source of revenue. Revenue alone does not make this achievement important. Unless the application delivers value to society in terms of a safer place to live or work, it is irrelevant for purpose of fulfillment of requirements. And neither can it be said that because it was built through unique means of integration and package configuration, does it make it important to write. What we do hope to show is that the portal as host to the concepts of security thoughtfulness, planning, policy formulation and procedures will become a referential work which underlies the importance of its publishing.

The revenue streams outlined above are internal to this final reorganization called Enterprise Security Management (ESM). As a business object, ESM becomes legitimate because now we can apply and execute on such principles as Six Sigma. The pathways for statistical analysis and support empowers owners, managers and executives to run this crucial sector of their businesses at the strategic level.

ESM is a conceptual way of viewing "the whole" while filtering out details about its parts. This is sometimes referred to as "seeing the forest for the trees." It recognizes the identity of a "higher level" aggregate objects whose characteristics transcend the characteristics of its component parts. Aggregate objects such as IT Security, Logistics Security, Intellectual Property Protection, Workplace Safety, Executive Protection, Incident Management, IT Information or Systems Security to name a few all have underlying component parts. The component parts become integral in computing the Process Capability Calculations. In Six Sigma lingo this means measuring a sample of items or transactions from a business process to make a projection of the number of defects expected from the process in the long term. The defect rate, expressed as DPMO (Defects Per Million Opportunities) is part of the essence of Six Sigma. Expressing a business problem as a defect rate typically provides a more direct way to communicate with stakeholders, members of the project team or the strategic drivers who utilize ESM.


NOTE: The rest of this document is a work-in-process with elementary ideas that will be subject to change.


While I did not research point blank whether or not a book about portal construction would meet a market need, it is obvious that no portal built from CVS or out of a proprietary box is useful out of the gate. Deployment is trivial, tutorials are nice but taking it to the goal line is not. Architects find the information they need to integrate applications and portlets to be scattered all over the Internet. In fact, in most cases even with proprietary products the vender's will not tell you were that fine line is between their Wizards and where you have to get closer to the metal and do some coding.

The following outline is a proposed table of contents:

Securitydirector's Enterprise Security Portal
Open Source Portal Construction
From Humble Beginnings to Advanced Knowledge Diffusion
Usage and case management concepts.

Preface

Introduction
In general, we introduce the Enterprise Security Portal (ESP) and remind the reader that as an application, the product went through a formal design and development process including the architecture of a database in support of the business model and processes that came out of the requirements definition phase of the project.


Chapter 1
Concept Owners and a Business Model

This will be the short story about the meeting of the Concept Owner and the Architect describing the business model that predicates the technical infrastructure contained in the following chapters. Brief historical nature of traditional security consulting verses the Concept Owners view of it being or becoming a function of management.

A discussion of the realization that with the coming of portal technology, the vision could be fulfilled. The business model description with the key players or users of the system that begins to speak to portal customization and profiling.

Key characteristics as projected by the Concept Owner such as operational security restrictions, incident reporting, messaging, content management and publishing.

Chapter 2
Technical Requirements Gathering and Open Source Harvesting

Working with Concept Owners on a regular basis throughout the project, this chapter begins with the research phase of the architect and ends with the mapping of high level requirements to the low level packages of open source software that will be integrated into the portal during the construction process.

Harvesting from the inventory of the open source community is a prelude to the methodology and skills used to help developers understand the relationships and the levels of integration necessary to bring the ESP into production.

Even though recognition for the need to add open source products came later in the development and during construction, this chapter will fully disclose everything in use to date. The reason for doing so is it is critical to identify as quickly as possible to developers the points of integration. This is were the real details that appeal to those looking for the “how did they do that” and “what was the result” come into play. The “why” will be obvious.

The following is a general list of open source modules that will be the building blocks for the coming of the enterprise portal for safety and security:

Linux
Development Platform Tools & Resources
MySQL
Apache
Tomcat
Jetspeed
Velocity
Zope
Silva

The next 2 chapters will focus on the 2 primary areas that will illustrate the construction process of coupling the various open source packages through integration; system level security and profile management.

Chapter 3
Security Integration Between OS Packages

Coverage of the sequence of integration events that occurred to build the base without SSL implementation. Second phase to address the development efforts and system administration to configure, test and deploy SSL for an end-to-end secure portal. Because so much of the content, reporting and messaging must happen across the Internet, specific ssl encryption to and from the client's agent browser must be secure.

We will look at each point of integration to see what task had to be done in order to facilitate ssl between the various packages. Reduce the complexity of the throughput between Apache, Tomcat and Zope.


Chapter 4
Profile Management Within The Context of the Jetspeed Servlet

Chapter 4 speaks to the efforts of portal configuration and portlet deployment through the ability to extend Jetspeed to support combining a user's base profile with a custom profile. With marketing programs in mind for different subscriber offerings, client company as well as unique user profiles needed to be administered. Center of discussion does not focus so much on allowing for users to customize their space as found in many popular deployments, rather control of a subset and delivery of portlets is emphasized.

This serves as an introduction to portlet development efforts with respect to how this becomes a tool in the hands of management.

Chapter 5
Portal User Interface

The basic interface for directors, client's Owner Manager and Employee populations will be highlighted following technical discussion illustrating what we have bought ourselves thus far. Portlet descriptions with concerns of usability, weaknesses and strengths. A portal without a content management system is no management tool. Introduce the Zope Product and show how much it enhances the existing Jetspeed framework.

Give some background information on Zope, it's ZServer and object oriented database. Document the content delivery methods of the Zope Management Interface and the resulting server side code for targeted portlet deployment.

While content management is the foundation for controlling the paperless office and diffusion of knowledge, publishing is the icing on the cake. Publishing models through the use of Silva is the user friendly means to put the power of content management in the hands of the authors, librarians and consumers.