Beyond web logs

A vast number of problems surround these ad hoc solutions—in particular, when these services need to
interwork in a complex environment:
• There are too many no interoperable encryption/authentication systems and products, with more
to come. It is almost impossible for an organization with a deployed, heterogeneous operating
system and network infrastructure to provide one standard over all platforms or to obtain sufficient
interworking between a range of (unharmonized) products.
• A generally available public key infrastructure (PKI) is still missing. While corresponding
standards have been available for some time, a common PKI is not yet been provided on the
Internet, and many of the regulations concerning digital certificates are still pending. In addition,
interoperability problems have plagued the deployment of PKIs and corresponding directories, as
well as "PKI-ready" products provided by different vendors.
• There is an open debate as to which security services should be provided by which functional
layer (network, operating system, middleware, application, or presentation). While some have
championed IPv6 and its security elements as the end of all security problems on the Internet, it is
still unknown (and consequently not reflected in the deployed IT base) which security service
elements will be provided and accepted by the market as part of the networking base, the
operating system, or application services.
• The interworking of a large number of components and the corresponding dependencies create an
additional level of complexity, which has so far substantially hampered deployment of common
security platforms. A subtle change in one operating system covered by a security framework, for
instance, may imply the upgrade of the security framework (or parts of it), may in turn imply
upgrades in other deployed platforms, upgrades of middleware components, and/or upgrades of
applications on these platforms.

Externally supplied frameworks (such as SAP) utilize their own "embedded" security modules and
methods, which may not be compatible with the security model and systems already installed. In
some cases, it is almost impossible to obtain enough information about the inner workings of these
systems to assess whether the embedded security is up to the standards required from all other
systems and applications in the organization.
• The complexity and openness of interfaces between the organization and entities in the outside
(i.e., untrusted) world poses another problem for a coherent security environment. One financial
information vendor, for instance, may give customers the choice to separate a financial data
stream from an email channel (i.e., allow them to block unwanted email gatewaying between the
organization and the Internet through the financial service provider). At the same time, another
provider may opt to code all these functions into one proprietary data stream, thus making it
virtually impossible to selectively block email gatewaying.
• Many organizations suffer from severe integration problems when it comes to deploying "just
one" security framework. Although it has become popular in the IT community (especially in the
sales force) to term all systems sold and paid for as "legacy" in order to boost next year's sales, a
large number of business-critical systems in the mainframe and midrange area have their own,
well-built but incompatible security environments, while they are still perfectly suited to run the
organization's business applications. No head of IT would be able to justify the replacement of
these investments "just because of IT security."
• As in every software area, bugs and deficiencies also exist in IT security software, as well as in
particular configurations. While the IT industry as a whole has learned a lesson with respect to
covering up security holes (also thanks to the self-organization of the Internet community into
Computer Emergency Response Teams [CERTs] and other security communities), such security
holes still exist and will continue to exist as the corresponding software becomes even more
complex.
In addition to technical and organizational shortcomings, legal and regulatory issues add another layer of
complexity to the provision of a coherent IT security environment.
Therefore, a redesign of security within the scope of IPv6 had to "go back to the roots" and determine the
few important key elements of security that need to be provided by IPv6. These elements are to be used
within IPv6 itself or by applications on top of IP without imposing organizational or legal settings that may
render these basic services unusable for the world-wide Internet.