posted on Friday, March 05, 2010 3:48 AM
The current threat level is … the same as it was yesterday, and the day before, and will be tomorrow.
We’ve all been in the airport before and heard the announcement. “The current threat level is orange. Blah blah blah blah yada yada whatever.” At least that’s what I hear today because I’ve become immune to the fact that “orange” means there’s a threat. There’s always a threat, it seems, and the announcement simply conveys what appears to many of us to be the “status quo.” We have effectively been desensitized to a “higher” threat level as it is now treated as nothing out of the ordinary. It is the norm, rather than something that grabs our attention.
The same is true in the enterprise, where the threat level is always high. Although most organizations likely don’t have a “threat level announcement” the effect is the same: personnel and infrastructure alike treat this allegedly “heightened awareness” as the status quo. It’s no longer actually heightened, or more aware, it’s the way it always is. Many times this is because there’s always a credible threat to the infrastructure and applications of any organization. At any time there may be an incursion, an attempt at penetration, the exploitation of an old or newly discovered vulnerability. This forces information security teams to put into place the infrastructure and solutions, both active and monitoring, that will detect and (one hopes) prevent a successful attack. These solutions are always on alert, twenty-four by seven, three-hundred sixty-five days a year.
The problem with always being at a “heightened” state of security awareness in the infrastructure is twofold. First, real threats may go unnoticed amongst the hundreds of other “alerts” about anomalies that aren’t truly attacks. Out of the hundreds of failed log-in attempts in any given day how many of them are actually attempts at hijacking an account and how many are just attempts by legitimate users that forgot or fat-fingered their password? In many cases the determination of which is real and which is simply a case of user-error are left to a codified “process” that ends with a locked out account and, more often than not, a call to a help desk or an e-mail explaining the situation. Second, if every piece of infrastructure is always configured to be in “ultra paranoid” mode, it impacts the performance of all applications delivered through that infrastructure because the components are always expecting every packet to be “the one” that’s truly dangerous.
A dynamic infrastructure, enabled by Infrastructure 2.0, however, might resolve this problem – or at least give us the means by which we can architect an infrastructure that can.
WHAT if your INFRASTRUCTURE was SMARTER than THAT?
Strategic points of control will continue to emerge within the data center; points at which
context-aware solutions will be a requirement in order to take advantage of the necessary information from the network to the application layer to make
critical decisions regarding access control to network and application resources. By using all the available information we have a better chance at mitigating several classes of attacks, both those directed at the user and at the application or its supporting infrastructure. Leveraging a dynamic infrastructure further enables a more flexible and responsive security posture in the event that anomalies are detected as it necessarily allows infrastructure to collaborate
and indicate a credible threat.
For example, it’s nice that Facebook recognizes when a user is attempting to log in from a new location. But what if it could go further and notice that not only is it a new location but it’s also a new device. Perhaps it’s a mobile platform or a different user agent. Wouldn’t it be nice if that triggered an increased threat level across the infrastructure specifically for traffic exchanges until it’s been deemed “safe”? Perhaps that means activating a higher logging level for that user, or scrutinizing the payload more thoroughly by enabling a specific security profile that’s a bit more aggressive than is typically used. Perhaps it means activating additional application logic that requires more proof of identity before subsequently processing a query that will write into the database. And once it’s been determined that yes, this actually is the user we thought it was, we could “stand down” and relax the security posture of the application and supporting infrastructure back to more “normal” levels.
In other words, can’t we leverage strategic points of control in the application and network infrastructure to inspect and determine then whether it is a threat or not? And if it is – or appears to be suspicious - then we could heighten the security posture, rather than assuming everything is an attack?
In other other words, can’t we apply infrastructure 2.0 concepts to security so that it, too, can evolve along the path to being more active in differentiating legitimate from malicious? What we need is real time security; on-demand security. We need a way to inform those strategic points of control that a particular user session is “malicious” and hey, why don’t you block that access now? We need a way for infrastructure to inform the firewall on-demand that yes, that’s a UDP flood intended to DoS a particular application and no, we don’t want to process any of that traffic so go ahead, deny access won’t you? We need the solutions that sit in these strategic points in the network architecture to be more alert, more aware, and more importantly, able to share that information such that the security best able to thwart an attack is used at the right time. The firewall is the best place to stop a UDP-based DDoS. The application delivery tier is the best place to stop a TCP or HTTP-based DDoS. Leveraging the right solution at the right time may make the difference between no downtime and hours of downtime.
But we can’t leverage the best solution at the right time if we (a) don’t know there’s an attack ongoing and (b) can’t actually communicate in real-time with the solution. We talk a lot about “efficiency” when we talk about cloud computing and virtualization, but we don’t often talk about efficiency in the overall architecture. The entire architecture should be, optimally, designed to distribute all application delivery tasks to the appropriate components. Why should an application ever process requests that carry a malicious payload? Why should the application delivery tier ever see a UDP flood? Why do we let “bad” traffic past points at which a component could have stopped it? Doing so consumes bandwidth, compute resources, and storage resources that are completely unnecessary. When we architect a solution that’s more efficient we improve the overall performance of the architecture because there is less “bad” traffic crossing the entire network and fewer components processing what is already known to be “malicious.” That, in turn, improves application performance and capacity, which reduces costs to deliver and makes end-users more productive.
We certainly don’t want to relax our security posture overmuch, but we don’t want to keep it always elevated, either. Desensitizing both people and infrastructure to potential threats is dangerous because when a real threat comes along it gets lost in the mountainous packet storm of “maybe this is a threat” messages. Signal to noise ratios need to be reduced for both people and infrastructure, and one way to do this is to architect highly reactive security architectures that collaborate via Infrastructure 2.0 to automatically “scale” the threat level according to what’s really going on in the network and the application network.
