CXO

Add a layer of security to your distributed applications

Companies using enterprise architectures for distributed applications may not realize the extra vulnerability of their apps, but they might also fail to realize that they already have the means of increasing security without increasing expense.

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.

About Scott Robinson

Scott Robinson is a 20-year IT veteran with extensive experience in business intelligence and systems integration. An enterprise architect with a background in social psychology, he frequently consults and lectures on analytics, business intelligence...

Editor's Picks

Free Newsletters, In your Inbox