(continued from previous page)
have the same significance as far as it would for Symantec and the damage to our brand and the damage that it would do to our customers who are willing to trust us.
Does that mean you don't sleep at night?
Mather: No, I do sleep at night. It just means I have a lot to think about, before I go to sleep.
Does automation help lessen the worry?
Mather: Absolutely. Wherever possible, we do want to automate, and we do automate. The issue becomes about how you coordinate all that automation, especially with regard to reporting and the correlation of events. But if you have an opportunity, you always want to automate for a couple of reasons.
People like to take days off, like weekends and nights. Or they get sick occasionally or they go on vacations sometimes. That's good, but when you are trying to ensure consistency, you still need to be able to run (the network securely) regardless. And let's not kid ourselves?when do you think the most electronic break-ins occur at companies? Nights and weekends, of course.
Automation is a good thing, not only because of the timing, but also to ensure you're consistent in your testing and checks. Does my Stockholm office have the same configurations as what we're set here in Singapore? Do people at the two sites understand English to the same degree that they actually understand (how to carry out) the
So there're a number of reasons why you want to automate. It's more efficient, it's more consistent, and therefore the integrity of the testing is far higher.
Are there areas that you just don't feel comfortable automating?
Mather: Two common areas usually come up. One of which is automating the patching of servers. The technical capability exists. The issue, is with servers, particularly those running mission-critical applications, can you trust that you will be able to patch without actually breaking your application? And for most companies, unfortunately, the answer to that is still "no." In fact, it will probably be "no" for a while. So it's still a case of manually testing the patch first and then rolling it out.
Another area where there's still a reluctance to automate is with regard to response. My firewall and IDS (intrusion detection system) have detected an attack. Do I trust the fact that it has properly classified or categorized that attack, and it is not instead turning off legitimate traffic? Was it a false positive?
Everyone talks about false negatives, but people don't generally pay attention to false positives, with one exception to that, and that's spam. False positives become quite an issue, too, for people. They can take legitimate traffic and misclassify that as an attack.
One of the problems with security policies is that they can be tough to enforce. How do you then implement a system that is enforcement-free, so to speak? For example, tools that scan devices for the latest patches before giving them access to the network. Can they help do that?
Mather: Nobody's there yet. If you're leading to an analogy that Cisco Systems has with NAC (Network Admission Control) or Microsoft with Quarantine, these are on the right track. We're a participant in Cisco's NAC. We share that goal and are working with Cisco and other vendors to help make that a reality.
What tools like that will do initially is provide a big improvement over what we have today. But to be honest, from my perspective, it's still limited. Ideally, we would go much further than that. First of all, you need to have a way to detect all types of devices across the network.
No. 1: to have universal authentication and authorization. Most businesses today don't even know who's on their network and can't tell you with any certainty--let alone can they determine--if that user should be on that system. That's very tough to do itself.
Second, you have to determine the state of the device. Those are tall orders. And remember, we're not just talking about desktops and laptops. These days, we're talking about PDAs and cell phones. Next year, we'll probably be talking about my watch authenticating into the network. The form factor will change. And these are running on how many operating systems, connecting over how many different media?
Zero-day attacks seem to be getting nearer to becoming a reality. How should we address this?
Mather: Oh, that's very real. And it's not just the fact that an attack is out, and there isn't a patch for it. It's the fact that the exploit already exists, and nobody knows the vulnerability was there.
If you look at the threat lifecycle here, there are two time lags. First, the time when a vulnerability is discovered and a patch made available. Second, the time the vulnerability is discovered--which may
1 commentJoin the conversation! Add your comment