Archives ||  About Us ||  Advertise ||  Feedback ||  Subscribe-
-
   Home
   Archives
 About Us
   Advertise
 Feedback
 Subscribe

Home > Focus > Full Story

Protecting Critical Systems

It is one thing to know that we have to protect your company's critical systems, but quite another to identify which are the critical systems. by Graeme K Le Roux

Organizations have to identify what are the risks involved, before they can figure out how to avoid them. But this process is more complex than one might think.

Consider this: is your company e-mail system a critical system? Can your business operate without e-mail? In spite of what a number of vendors would have you believe, the answer is probably yes, you could live without it and therefore it is not "critical".

But what if your e-mail is a function of, say, a Microsoft Exchange server which is tied into your voice mail or your voice-over IP (VoIP) phone system? There are a few of these VoIP systems around now and there are some systems which support other, non-Microsoft service application platforms. So now we have critical functions-namely, the voicemail and telephone system-running on the same server farm as non-critical functions like e-mail. Ascertaining if that is a critical system now becomes harder.

As these systems become more tightly integrated, it will be practically impossible to separate the individual functions of the system-that's what "convergence" is all about after all-so how do you "protect" the system?

The manager-proof database
Many companies run a database of some sort, often on a mini or mainframe host and increasingly on a server platform. And most database users work through well defined clients such as those with forms style interfaces. A good example is a bank teller front-end.

Such users are of no threat to the integrity of the system because what they do is controlled by the screen forms they can access, nor are such users a threat to system performance because the system is ordinarily provisioned to cope with their normal load. Managers on the other hand can inflict lethal blows on their systems, whether intentionally or not.

A typical manager has two sorts of interfaces to the database open to them: canned reports and freehand query interfaces. A canned report is basically a query that many managers run periodically to produce reports, such as current stock levels, transaction records by customer, etc.

One common, and unwitting problem is timing. Many managers tend to run such reports just before they go to lunch, probably because it takes so long to generate. But this is also the time when most customers choose to do their banking. The result: unnecessarily high data traffic that can be avoided.

But that is not the worst. Freehand query interfaces, because they pretty much let managers query as they please, are even more lethal. This is because even the slightest crack in the server-enforced integrity rules can allow a manager to completely scramble the database.

So what can be done?
It is important to realize that most managers do not need real time data. With mainframe systems, an organization can easily dispatch canned reports offline by running them as a batch job as part of the day end processing routine. The down side to this approach is that the reports may not be used every day so you end up doing a lot of processing for nothing. Nor does this approach address the freehand query interface problem.

What you can do every night is to export a data set representing the day's transactions. You probably do this already for backup. The process is usually to export the day's data to a file, back up the file, and then delete the file.

Now, instead of deleting the file, simply move the file to a NAS device and export it to say, a SQL server. This will be your repository that you may allow managers to do as they wish. And if they scramble the database, you can always rebuild it by reloading data from the NAS device.

But that is not all. Having a buffer system is useless if you continue to allow managers access to the "live" database. In order to hide the live database and NAS device from those using the SQL server, put two network interfaces in the SQL server and make sure there is no route between them.

This way, users can see the SQL server but not the devices attached to it, and none but the system administrators will be able to log on to the SQL server host as a general user.

Having a shadow database also increases the responsiveness of your actual database. Your live database, stripped of the reporting load, is likely to be much more responsive to those users who must deal with it, such as staff who are dealing directly with your clients. Managers also benefit since the SQL servers that they are using can be configured specifically to support their requirements and thus be more responsive than the live host.

Company Jewels
You must also not confuse critical systems with what is often your company's jewels: critical data.

Organizations will need to decide whether they are trying to "protect" the operation of the system or the data set it maintains. For example, in the VoIP phone/voice mail/e-mail example outlined above, having the system function is probably more important than preventing the loss of the data, such as voice mails. To devise an effective strategy to protect operational systems, first make a list of the things which can stop the system from functioning, like hacker intrusion or hardware failure.

If your critical system is "critical" because of the data set it hosts, then the risks to it are likely to range from hardware failure to someone scrambling your data. In most cases, the greatest risk to your data is internal users. This should be no surprise: an external attacker has to do a lot of work just to get access to your internal data set; your users only have to do something you don't expect.

Sanity Check
Most of your users will have restricted access to data sets via some sort of structured interface but some users, typically managers, will have wider access out of necessity, and so will be more dangerous. One effective safeguard would be to house your data in a storage area network (SANs).

SANs allow you to physically separate a data set from the processing platforms that are using it, as well as maintain one or more copies of it in real-time. But more importantly, they allow you to switch storage components into-or out off-the SAN on the fly.

Naturally, data integrity is also much better with SANs. This is because a SAN allows a number of processing platforms to use a single data set so that you can build a network with fail-over capability very easily.

For example, you can construct a front-end server farm with a series of load balancing switches and connect the processors to the same data set via the SAN. This also allows you to configure processor sets for the needs of specific user groups. An example would be using a SAN for one group of users specializing in transactions, and another specializing in generating reports. The transaction-heavy systems can then be outfitted for high speed I/O, while the report-generating system can be given heavy processing capabilities.

The benefits of maintaining a single, consolidated data set extends to backup and replication. Since the "single data set" is physically spread across several disks sets, all of which are maintained in real time, you can effectively protect data from being damaged by different groups of users by having them work on replicated disk sets.

If you use fibre channel-based SAN, you can easily create a "live" shadow data set in secure storage which effectively gives you instantaneous backups in the event of a catastrophic fault. You can never completely protect your critical systems, but you can do a lot to put them beyond most common types of harm. As always, the first step-identifying your critical systems and risks-is usually the most important one. And it is a step that most organizations can't afford not to take.

Making an idiot-proof firewall
Most companies have relatively basic Web and e-mail requirements. This requires no more than a publicly-accessible Web server and a simple SMTP server. You can do this for even the largest company with low cost Linux-based appliances. The challenge is to find a safe way to connect your public servers to your internal network without giving access to hackers or unauthorized users. This is where most companies would install a firewall.

Most organizations tend to think "firewall" in the likes of Raptor or Check Point. A simpler, and cheaper category that can be also considered is the Internet access device (IAD), that is typically aimed at the SOHO market.

IADs are usually intended to connect to a DSL modem on the public side and a small LAN on the other. Generally they provide a small 10Base-T hub, NAT, DHCP and an imbedded HTTP server so you can configure them with a Web browser.

IADs are usually feature-strapped, and quite "stupid". Even the smartest ones which run imbedded Linux are built so that they can't be configured from the public side, that is, the HTTP server just cannot see the public interface. By default, they are set up so that clients on their private side can make a connection to the Internet any way they wish, but connections from the public (Internet) side are blocked (you can change the default configuration so that, say, an external SMTP connection is allowed but you don't need to).

Simpler better?
The fact that IADs are so simple can make them a powerful security device. While IADs are intended for DSL connections, you can just as easily plug them into a standard router's Ethernet port. This works as the IAD makes a simple PPP connection over a direct Ethernet link to the router every time an internal device such as an internal mail server wants to connect to one of your public servers.

Even if the router is compromised, all the intruder sees is that the router is set to accept a PPPoE connection on a given Ethernet port, that is all. And if an intruder is watching when a link is established, what do they see? A PPPoE session from a single IP address (which is issued by the router anyway) and nothing on the end of it because the IAD will not respond to any attempt to connect to it.

In short, the IAD presents no path into your internal network. Figure 1 illustrates this arrangement.

Of course your public mail server can still be attacked and your Web server hijacked, but that can happen anyway. Any mail on your public mail server is compromised anyway as its going across the Internet. In any case, your public Web server should be backed up and therefore can be restored anytime.


Graeme K. Le Roux is the director of Morsedawn (Australia), a company which specialises in network design and consultancy and writes for Network Computing-Asian Edition. He can be reached at graemel@moresdawn.com.au. Send your feedback to editor@networkmagazineindia.com.

>>Next

- <Back to Top>-  

Copyright 2001: Indian Express Group (Mumbai, India). All rights reserved throughout the world. This entire site is compiled in Mumbai by The Business Publications Division of the Indian Express Group of Newspapers. Site managed by BPD