The hunt for hidden opportunities — III

Tech Forum - Dr. Nitin Paranjpe

Last week I had listed many things that you can achieve by simply trapping the menu selections made by the user—either in pull-down menus or toolbars or clicks on a URL. This article continues to explain some of the more complex activities that were listed earlier. For your reference, the previous article is available at: www.expresscomputeronline.com/techforum.shtml

6. Analyse existing user activity log and provide specific information / help / tips.
This is an interesting proposition. To achieve this you need to have logged the earlier usage pattern of the user. When the user has chosen to invoke some functionality, you can build a query to analyse past usage and provide information that will help the user achieve this task more effectively. Some of the things that could be useful in this context are:

1. Provide a summary of similar things done in the past—items purchased, funds transferred, feedback provided, whatever.
2. Provide a reminder about some mistake that was done repeatedly in past sessions—forgetting to choose the right options; entering wrong shipping address; reminder about updating phone numbers (in case you know it has changed).
3. More sophisticated prompting and help is possible depending on your business scenario and usable details available in the past log.

7. Control spam or denial of service attacks.
Sounds out of place? Do you think it is not the responsibility of your application? Shouldn’t a third-party tool take care of this? NO. You are wrong. Third-party tools are required to handle this because most applications don’t handle it themselves.

You and your application would be in the best possible position to monitor, identify, detect and control spam. Third party tools can only guess based upon some rules—which always have valid exceptions that are not spam.

Here is an example. Suppose your application allows a user to log orders through the Web. Someone finds out the exact way (URL, parameters, encryption if any, valid session ID and so on) in which your order logging ASP is called. Now, a typical attack would be launched by programmatically calling this order-logging page with a little tweak of the parameters. How does your application detect it? Simple:

• Log the typical type of transactions done by typical users (either based upon username or role).
• Analyse this log from the point of generalisation and ensure that the usage statistics are fairly predictable for routine usage.
• Assign a safe limit for each type of transaction volume for each user/role within a specified time interval. For example, even the biggest dealer would not log more than 40 transactions within a day. So keep the limit to say 45. You can configure global or specific limits. Of course, you will need to have additional tables designed to keep this information.
• Now, we look at these limits and compare this with the current request for the new transaction—by adding 1 to the current transaction count for defined period (daily). If the limit is exceeded, don’t allow the transaction. Give out a polite error page to the end-user, send an alert to administrators and send an alert to the actual user/role whose ID was being used. Furthermore, block that user ID till it is reset by the administrators.
• Put all transactions that have originated from this user in the current period, if possible. If not, generate a report of such transactions and send it to the business head and/or administrator for crosschecking and manual rollback.

How much extra work is this? A few hundred lines of generic code, a few simple tables and a few views. That’s all. But now you have a method for making your application (for that matter, any application) spam-proof!

8. Analyse and manage misuse or intrusion.
This is a tricky one. When you have Web-based extranet applications, your staff is able to utilise and view the data outside of your office, from anywhere—a cybercafe, home, hotel, or even from a competitor’s office!

Have you thought about the risk of this level of exposure of corporate data? When you know that most security and confidentiality breaches occur because of internal staff, this assumes substantial significance. But, you will say, being available everywhere is the key benefit of the Internet, so why stifle it?

I am not against the Internet. Extranet applications offer great benefits. But anything that has benefits also has shortfalls. How do you overcome this one? How can you prevent data being viewed by an unauthorised user?

I agree that you can’t. But let us not give up the issue so easily. Just a little additional thinking and you will realise things are not as depressing as they initially seem. Consider a sales head who has access to all sales data. All subordinates in the sales team have access to a subset of the data, which is for their direct customers.

Now, can your system log the usage of the reports or the ASP page requests at least? Definitely it can. You just have to put a little logging code in the menu selection event—as we have already discussed. Now, this log is going to be much simpler and smaller than the Internet Information Services (IIS) log. Some fields which could be present in such a log table are listed below. (Don’t bother about data types. The names are given in English. They are not valid field names).

Now, all that you have to do is to keep a tab (programmatic or manual) on how people are using what functionality and from where. Some common-sense-based thinking will easily highlight possible misuse instances. Moreover, you need a top management or security management directive that informs all employees that all their activities are being logged and they are answerable for the usage patterns! Simple, effective, practical and feasible, isn’t it?

9. Re-authentication of current user.
This is simple enough. But worth doing outside a form or a page. On the Web, page expiry can effectively tackle this problem. However, explicit re-authentication may be required in special circumstances like changing passwords or taking actions that have drastic impact. In most cases, re-authentication code is hardcoded into the module itself. It would be a nice idea to keep a table containing module names requiring re-authentication and then check it in our great menu handler event. The advantage of this feature would enable us to log the success, and more importantly, failure of this re-authentication. Failures would provide interesting intrusion attempt pointers.

10. Check for functional blocking.
This is not a common idea. It requires some detailed explanation. ‘Functional Blocking’ is a term coined by me. Maybe there is some other jargon to describe it, but I am not aware of it.

Anyway, let us learn the concept first. Consider any transactional system. A hospital, for example. When a patient undergoes some billable activity—X-ray, surgery or physiotherapy—the concerned staff member enters the activity into the hospital management system (HMS). The system keeps track of all activities and related charges. When the bill is generated, it would sum up all activities. Once the bill is generated further activities cannot be entered. Just a typical transactional system. Nothing great.

Another example: Consider system backup of a multi-user system. Backup cannot be invoked when one or more users are using the system. The reverse is also true—once backup has commenced, users cannot use the system till backup has been completed. This type of conditional execution need is very common in all types of serious applications. And this is what I call ‘Functional Blocking’.

Now the more hands-on guys (or gals, of course) would argue that serialisable transactions already handle this. No, sir. This is a different scenario. Serialisable transaction management will not allow a new item to be added to the bill while the bill is being printed, because there is a lock on the bill line-item table. That is fine.

But what happens after the bill is printed? There is a request pending for adding an activity, which was waiting for the locks to be released on the bill table. When bill generation is over, this lock is released and the pending write is added—effectively adding an activity that will never be billed! Yes, you can have a flag called active, which is made inactive when billing is done and this prevents further activities from being added. But this still does not prevent an activity that was added and was waiting in lock queue while the bill was being printed—the user had invoked the BILL UI but had not clicked on the OK button!

This is what functional blocking is all about. You want to ensure that while someone in the network has an OPEN BILLING dialog (for a given patient), nobody else can even invoke the form for adding a new activity for a patient. It is possible that both these guys choose to CANCEL the activities. But invoking a form is like declaring intention to do the activity at the user level.The same is the case with backup. The Backup dialog should not come up at all till all users are off the system. Does this not sound like a useful thing? In fact I have covered this funda almost six years back in Express Computer. But the context was different then. Moreover, I have implemented this functionality years back in a medical packaged product I wrote (in FoxPro, of course. It is still selling well).

So how does one implement functional blocking? Use the tried-and-tested method of clever database design and a little bit of simple thinking. Have a table that has the base module name and the blocking module name. This is your functional blocking master. You decide what functionality should block which other functionality. Now, you need another table that will keep runtime information about who is using which module. Our menu handler will make this entry, run the module and then remove this entry when the user quits the form. Of course you need a timeout mechanism to clear entries which may remain hanging due to machine or network failure. Once implemented, this concept provides a good mechanism to prevent functionally clashing things from ever clashing with each other!

11. Check for server/Web load and bottlenecks
This is an interesting usage. Very often, some long-running task like upload or batch processing or processing of a long and complex report starts when the end-user load is at a peak. This slows down everything painfully. A simple way to avoid such situations would be to have a menu handler that simply looks at the current load on server and decides whether to continue.

Sounds futuristic? Not really. You will need to look at one or more parameters to arrive at this conclusion programmatically (see table above).

We still have some way to go, with the remaining 17 items. But due to constraints of space and time, that will have to wait for the concluding piece in this series, next week.

Your feedback, suggestions, requests for covering specific topics or issues are welcome. Please send feedback to techforum@mediline.co.in

About the Author Dr Nitin Paranjape is the Chairman and MD of Maestros (Mediline). He is a consultant with many organisations, covering appropriate technology utilisation, business application of relevant technology, application architecture and audit as well as knowledge transfer. He has authored more than 650 articles on various technology-related subjects. He can be contacted at nitin@mediline.co.in