Enterprise applications, and integrated application systems
in general, offer unique IT security challenges. You can button down your
servers, your databases, your interfaces, and match your protocols ideally to
your environment and still not be secure in an integrated application
environment.

Why is this so? Because enterprise application integration
almost invariably includes the economic and labor-saving innovation of blending
legacy apps and new apps in a system, and this leads to an entirely new class of
security risk.

When a legacy app is shoehorned into an ERP application
workflow, economy is served as the investment in that software is preserved.
But it’s also true that we use such legacy apps in new ways in order to achieve
this economy. We often put those programs to work in ways their original
creators did not anticipate, feeding them data they may not have originally
been designed to cope with, and opening the door for users (both human and
digital) that were not originally intended.

What can you do about it?

Wrapping your security in more security

What may not have occurred to you is that your distributed
application architecture itself offers you a new way to lock your applications.

Integrated/distributed applications have a general
architecture that includes tracking of all data access, organization of all
application processes into finely-defined, managed workflows and communication
between workflow components (and potentially between workflows themselves) via
a dedicated messaging system. What needs to be clear is that, in addition to
the implementation of accountability measures like digital certificates and
signatures, entire application systems can be watched by means of these
integrated workflow components. Depending on the make and model of your
application integration middleware, these are the options available to you:

  • Secure
    entire workflows.
    Set up access, with user
    authentication (whether for in-house or Internet users) not at the
    application level but at the workflow level. What does this buy you? You
    will be able to restrict access to transitory data and applications in a
    distributed process based on the status of the process; that is, an
    application is only accessible to anyone, legitimate or otherwise,
    if other conditions in the workflow cycle have been met. This will greatly
    reduce the opportunity for hacking the apps or data.
  • Have
    users request data, rather than access it
    . With secured
    workflow and messaging, it is a simple matter to set up a talk-back
    mechanism activated by the authentication of the requesting user. That is,
    keep data objects in a workflow inaccessible to all, then set up the
    messaging service to initiate its transfer to the querying user upon
    authentication. Don’t let them grab it; instead, hand it off when identity
    is confirmed.
  • Play
    the links.
    When appropriate to the situation, set up data
    queries, procedure calls, server access, and application execution with an
    interim server-side initiation. This is a variation on the trick mentioned
    above. Instead of directly initiating any of these activities, the user
    request is a function-specific server request—a click on a link that sets
    a dynamic workflow in motion. This step, rather than the initial call, can
    set in motion the authentication procedure between client and server—a
    curveball to a malevolent visitor and an unexpected reversal for invading
    software. Instead of simply slipping a key in a lock and entering, the
    unauthorized user faces a sentry demanding credentials on the other side
    of the door.
  • Implement
    a client-to-server link.
    Finally, in a variation on the
    previous item, when there’s occasion for human intervention in an
    integrated/distributed application system, the client-to-server link is
    the perfect interim step. It logs everything you need to know about the
    requesting user and leaves it to an accountable party (who likewise must
    self-authenticate) to authorize the release of data. In many scenarios,
    this isn’t practical, but in situations when the routine allows for it,
    or when review and accountability are essential in any case (i.e., the
    approved release of a monthly report), you have a built-in mechanism for
    implementing it.