Add a security layer to distributed apps

TechRepublic
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?

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, organisation 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 unauthorised 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 authorise 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.

    TechRepublic is the online community and information resource for all IT professionals, from support staff to executives. We offer in-depth technical articles written for IT professionals by IT professionals. In addition to articles on everything from Windows to e-mail to firewalls, we offer IT industry analysis, downloads, management tips, discussion forums, and e-newsletters.

    ©2004 TechRepublic, Inc.

  • Advertisement

    Talkback 0 comments

    Sponsored content

    Power Centre - Content from our premier sponsors

    Blogs

    • Suzanne Tindal Sick of broken tender sites
      Some of the state governments desperately need to invest in more user-friendly tender sites so that looking for information on government tenders doesn't have to be a game of blind man's bluff.
    • Array Cyberwar: What is it good for?
      In this week's episode, Cyberwar. What is Australia's place in the world of digital warfare? What are the implications for the NBN?
    • Array Is wholesale-only backhaul just a pipedream?
      The potential acquisition of Pipe Networks by SP Telemedia has raised the question about whether vertically integrated backhaul providers will mean higher wholesale prices for ISP customers.
    • More blogs »

    Tags

    Back to top

    Featured