A while back I blogged
on the relative computational expense of various network techniques.
Another way of considering the amount of computational effort
it can take to protect your company from a potential attack is to look at the logical
distance between your security mechanism and the asset it is trying to protect.
To answer your next question (“what does he mean by
logical distance?”), consider the case where you’re trying to control requests originating
from outside the company that result in access to particularly sensitive tables
of data located in multiple databases in your data center. All these requests
will come through your perimeter firewall – it clearly is a “choke point” where
you could exert control before the flows fan out to multiple web servers, each
of which might fan out to multiple application servers, which ultimately
connect to one of several database servers.
But the “logical distance” between an HTTP request and
the database transaction in which it ultimately results is rather large. A
network security device which is to accomplish the goal stated above would need
to parse the incoming HTTP request into its constituent parts (relatively easy)
and would then need to know the transformations applied to these parts through a
couple of servers into the ultimate database request – an almost impossible
task (and, if possible, certainly computationally expensive) as the logic
contained within the web tier and app tier in the data center would need to be
encoded into the security policy. So network security devices that sit at the
perimeter of the data center tend to be used to look for anomalous patterns
rather than implementing layer 7 access controls.
A number of vendors provide database security products
which either sit in the network in front of your databases or are installed as
software agents on the database servers. The logical distance these security
products have from the resource to be protected in this scenario is certainly
far less. The challenge these products tend to run into is that it’s difficult
to divine the original task which resulted in the database request – once the
request that started out as on HTTP has woven its way through a the web tier
and the app tier, assurance of the identity of the user making the request has
usually been lost – while the user was authenticated by the web or app tier,
the app tier is logged into the database under a generic account that can
generally access far more than the user would have been allowed to. Thus,
moving the security control closer to the resource being protected results in
less computational complexity, but also the loss of sometimes crucial bits of
context which would prove very useful in making policy decisions.
The challenge of how to distribute out security
enforcements to points that have little “logical distance” from the stuff they
are meant to protect while threading the necessary context to make these
decisions through the intervening layers in the application stack is a
challenge which is typically imperfectly met.
aicasiano
on:
May 2012 Microsoft Patch Tuesday Summary
