> Focus > Full Story
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
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?
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,
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
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
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.
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
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.
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
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).
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
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.
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 firstname.lastname@example.org. Send your feedback to email@example.com.