Yehuda,
*
I'd like to make a couple of observations about the conversation and
issue at hand.
*
1. Security is very difficult to achieve if you consider the whole as
independent parts. You have the input, they have the processing, you
have the output. Your design model must include the processing to an
extent that allows you to tie the input to the output in an irrefutable
way. If that means they have to add a couple of thousand lines of COBOL
code to their mainframe to carry a ticket around with the data their
processing to give it back to you when its done, then that should be
what you demand. If you rely entirely on your own methods to tie input
to output, I fear you may be putting yourself at too much risk.
*
2. This system is going to be attacked from both the inside and the
outside. While its important to assess the risks outside, you have to
consider the internal risks also. Protocol separation is an effective
deterrent for external intrusion attempts, but does little to thwart
internal attempts. Don't let the obscurity lull you into a false sense
of security. (in other words, surround your IP components with IP
packet filtering devices, and then surround your SNA components with
whatever forms of gateways you can employ there). Make sure you are
handing off data streams in a securable fashion using the strongest
authentication you can get to validate communications between your own
trusted boxes. The NT encrypted RPC channel is susceptible to TCP
packet sequence number detection, and apart from the initial connection
between the two boxes, does not alter the identifier between sessions,
making spoofing possible. My recommendation would be to employ
additional encryption of your own design and whatever stronger
authentication you can use that would be time-sensitive (hence my
reference to tickets earlier).
*
3. Make sure you have independent services running which validate your
auditing selections on an on-going basis.
*
4. I would also look at writing your own code for changing the
passwords on the accounts you are worried about. NT can support a
password up to 128 bytes in Unicode. The user interfaces that are
available will only allow 14 bytes of ASCII (which are then converted
to Unicode). If you write your own automated logon processes (and an
automated change password process) you can use the full 128 bytes
thereby thwarting a non-programmatic attack on the passwords/user
accounts. Set the change process to do so frequently.
*
5. While you're only exposing TCP443, you are, of course, relying on
the underlying stack to present these packets to you. I would recommend
introducing at least a monitor driver at the TDI layer so that you can
calculate a hash of the data and then compare that hash in your ISAPI
filter. This would allow you to verify that the inbound data hasn't
been modified through the stack, and also verify that anything you
create for output isn't modified prior to delivery to the wire. If I
now understand the buffer overrun attack possibilities correctly,
comparing a hash within the HTTPS environment of an outgoing packet to
the same hash at the TDI layer should allow you to determine if what
you think you should be doing is actually what's being delivered. If
the TDI driver can't validate the hash against one that was created by
your processes, it shouldn't allow delivery. Creating the hash in your
processes should be done as far away as possible from the input stream
so that as many attempted exploits as possible can be detected. Your
driver would have to have alerting code and maybe some logging code.
*
Obviously doing the above may add significant overhead to your
throughput. I suspect, however, that speed is going to be less of a
concern than security (and so it should be). I would also consider
enforcing the use of personal digital signatures at the browsers, if
you can, as an additional level of authentication.
*
There are lots of other things that you might do, of course, but that
would depend entirely on what/how your processes do their thing. I
personally think you've given far more information than you should have
in this public forum, so I certainly wouldn't ask you to expand on your
description of your system any more. Besides, I have to keep some
things in my pocket for sale, don't I...;-]
*
Cheers,
Russ
R.C. Consulting, Inc. - NT/Internet Security Consulting
mailto:Russ .
Cooper @
RC .
on .
ca <-- *note the new address*
|
|
