IPS « SecureThinking

Posts tagged IPS

Monday, August 9, 2010

What CSOs Talk About at Dinner

By Jill Knesek, Chief Security Officer, BT Global Services

Last week I had the pleasure of meeting with some of Chicago’s outstanding CISOs and CSOs. We met for dinner to discuss those thorny and gnarly issues that keep us working overtime to make sure that our companies are secure and our employees excel at work. So, what was on our menu that night?

The first hot topic was methods of securing data across companies with disappearing perimeters. BT, like many companies, works to enable its workers to literally work anywhere to boost their productivity and enhance their work-life balance. But as the office walls disappear, new challenges abound.

While we touched on what value firewalls and IDSs provide, much more time was spent discussing endpoint security, such as personal firewalls, antivirus products and good patch management processes. I see particular value in hard disk encryption on laptops, which renders stored data nearly useless to thieves.

Obviously, mobile devices are top of mind for us. Not only do we have to worry about laptops — with more companies supporting a “BYOD” (bring your own device) policy, we have a whole new set of things to be concerned about. For example, it seems inevitable that companies will need to let employees bring their own hardware platform into the workplace. And, while we all love our iPads, iPhones, Blackberries, and Android phones, with hundreds of thousands of apps available for download and many thousands more becoming available each day, how do we secure them? While I wish I could say that we came up with a solution during dinner, this topic, for now, still generates more questions than answers.

The other topic that provoked a great deal of discussion as the economy emerges slowly from recession is how we secure new acquisitions. The biggest problem facing CSOs in this area is — how do we change the culture of a new acquisition without breaking the business model that made them a desirable target? But, the bottom line is that at the end of the day, CSOs are responsible for the security of all company assets, whether organic or acquired. From my view, the key is good communication with the acquired management team and a strong security awareness campaign, since employees remain our first line of defense. After that, it comes down to pure risk management and understanding the biggest threat against the acquired company — and mitigating that piece first.

And, from that discussion, we found ourselves deep in the nitty-gritty of Risk Management. I know this message is getting tired, but the reality is that having a mature risk management program with real stats and data to back up your risk register can be a great tool in communicating at the boardroom level. We can’t be Chicken Little, but we do need to rely on cold hard facts that resonate with the senior management team.

The example I used was how to relate a fraud case to the senior leadership team in terms of revenue lost from the bottom line. For example, if you lose $1 million in a fraud, how much revenue would it take to make up for that net loss? Well, if the revenue was from a service with a 15% margin, it would take nearly $7 million in new revenue to make up for the loss. Putting the cost of crime in terms of revenue helps the CFO and senior management appreciate the importance of reducing crime through security.

By the time we reached dessert, we’d hashed through these and other very interesting topics. And, while we didn’t come up with concrete solutions or definitive answers, we learned a lot from sharing our common experiences and unique responses.

I’d like to thank everyone who came and invite you all to carry on the conversation in cyberspace. Leave a comment below, or let me know what you think in the Security Leaders Group on LinkedIn.

Thursday, June 10, 2010

To Disclose or Not to Disclose: That is the question

With many of the security incidents that have occurred, customers are now uncertain as to which companies they should trust and which companies they should be concerned about. One way to overcome this hurdle is to disclose information on a company’s security strategy in order to instill confidence.

But the question arises – is it in the best interest of a company to reveal security controls? Or is disclosing this information making the company a target for hackers? We asked our experts for their thoughts on this issue.

Vaune Carr, a principal consultant for BT Global Services, expressed her opinion on the topic:

When it comes to disclosing a company’s security defenses, many organizations insist on being secretive. I happen to agree. If a company has a need to talk about their security strategy, my suggestion is to be more controlled about any discussion of their specific computing environment as opposed to openly publicizing the information where it can possibly be used against them. Why?

Well, it is simple, really. An organization that reveals its specific hardware and software measures to the public or to competitors or to others runs the risk of opening themselves up to attack, or they make it easier than it would have been if an attacker had to guess what was on their end. In fact, while having a public discussion of its security posture, the company may be unintentionally drawing attention to incomplete controls, literally inviting hackers into their networks. And for those who are confident in their controls, it seems they are basically daring a criminal to prove them wrong and hack into their systems. Why put your organization in that position?

Ultimately, it is not the investment in tools that makes an organization good at security. What makes ALL the difference is how you manage, monitor and maintain these tools. But in the end, as you decide with whom you want to discuss how good your organization is at security, just make sure to provide some pertinent metrics.

Jim Tiller, vice president, Security Professional Services for BT Global Services agrees:

I agree with Vaune. And it’s worth briefly exploring the pros and cons of sharing security information. Most enterprises will have standardized, best-practice security controls, such as firewalls, IDS/IPS, and the like – generally very predictable. Add to this that even entry-level script kiddies can determine the type, software and version of many systems. So it can be argued that you may not be giving away information that can’t be easily discovered surreptitiously. What we’re really talking about are the details and nuances.

Let’s ask the big question — Are there any advantages of sharing security information? Well, in some ways, yes. A prominent security challenge is knowing what works and what doesn’t. By sharing information with others, you can learn from one another and find a more refined and effective balance for your environment.

Then there is concept of information as a deterrent, which is based on the “path of least resistance” for a threat, assuming that when a potential attacker knows your network is being monitored, for example, they will move on to another, less secure target. Unfortunately, this doesn’t apply to many forms of threats – deterrence in infosec is a gamble at best. Lastly, a consistent and popular argument is consumer impression. An online bank that shares details on their security controls to customers may increase customer confidence and loyalty; seemed to work for Bank of America.

What we’re really talking about is that disclosing details about your security controls publicly can play to a hacker’s desire to make an example of you. It’s like poking a dangerous animal — you’re increasing the chances of getting bit. You better be sure of those controls, because they’ll be tested. In fact, I will go as far to say it’s less about the content of the information and more about the culture of the threat. Tell a hacker you’re secure and, regardless of your security control sophistication, they are attracted to you like a shark to blood – you become something to be conquered.

Therefore, as with all things security, it’s weighing the advantages against the risk and managing information disclosure. It is well within reason to share certain information at varying degrees of detail with different groups and in different conditions, as long as there is clarity on the value-to-risk ratio you get from doing so. Nevertheless, being a professional paranoid… my default rule is “loose lips sink ships.”

Weigh in with your thoughts. Do you believe an organization should share security information or keep it under wraps?

Friday, March 5, 2010

Past the Point of PCI

By: Sushila Nair, Product Manager, Managed Security Solutions Group,

BT MSSG &

Sanjay Mehta, Senior Vice President, Breach Security

The nirvana of that moment in time when you are completely secure without a single vulnerability in sight is unfeasible and, even if it were possible, it would be fleeting. Despite our fondest wishes for this moment, we accept the fact that our networks are vulnerable and are in a constant state of flux, causing the vulnerabilities to alter and the risks to change. Organizations struggle with how to continue to develop their core business while managing their risk and doing it all with fewer people and resources than they had last year. The only way this is possible is to work smarter – but how does that translate into practice?

We accept that our security is flawed, so it becomes critical that we place security devices wherever we have high or unacceptable risk. It is essential that the security alerts from security products like WAFS, firewalls, IDS/IPS as well as host information and application logs are centralized. The devices we select are critical and should be chosen in line with risk. It is worth bearing in mind that web applications are one of our largest areas of risk and were one of the key areas of focus in PCI DSS 1.2 which was based on the forensics of card breaches.

Once the devices are selected, then the complexity of managing this new technology comes into place and again, outsourcing is a serious option for companies that are constrained by head count. The footprints of what has happened on our network is in our log files, and it’s impossible to check the multitude of consoles for the vast array of product that we have, so it is critical we centralize our log files and have the capability to correlate and look for patterns of attacks. Unfortunately, security breaches are not limited to 9 to 5 or business hours, so our security monitoring framework must be built to take this intelligence, look for patterns of attacks and be manned 24×7.

This week’s RSA Conference pinpointed the problem of treating compliance as a single point in time.

Most companies breathe a sigh of relief once PCI compliance is “achieved” via an audit or code review. IT professionals move on to the next priority, and often, compliance “maintenance” is forgotten. In doing so, they fail to understand that audits and code reviews are outdated the moment they are completed. Web applications continue to be developed and altered, and as a result, continued compliance can’t be ensured with the “one-time look” that occurs with audits and code reviews. And it would certainly be cost-prohibitive to conduct an audit or review with each application change.

Fortunately, continuous PCI compliance can be achieved using a web application security solution that provides real-time, continuous security for all protected web applications.

In today’s compliance landscape, it’s simply not enough to know that a problem exists. Sophisticated web application security solutions help companies mitigate problems. Organizations need to have a real-time solution – not just a single look in time – to be truly secure and PCI compliant.

Here is more information on how vulnerability scans and code reviews compare to web application firewalls:

Vulnerability Scans and
Code Reviews

VS.

Web Application Firewalls

Looks at one web application at a single point in time.

Provides real-time, continuous security for all protected web applications.

Must be repeated for each application change.

Profiles each application’s acceptable behavior and automatically learns changes.

May not cover every line of code.

Secures the entire web application.

Can result in inconsistent findings due to vendor interpretations.

Provides factual information on vulnerabilities.

Does not fix vulnerabilities that are found.

Serves as a “virtual patch” that protects each application’s vulnerabilities.

Is expensive.

Offers immediate ROI.

Wednesday, October 28, 2009

Guest Post: McAfee – Day Zero is Dead … Long Live Day Zero!

Mike Nielsen, Director for Network Security, McAfee

It wasn’t very long ago that Network Intrusion Prevention System (N-IPS) vendors were in furious debate over who released the signature first after a new exploit was discovered, protecting their customers fastest from the attack du jour. The story line went something like this:

1) Microsoft announces <some large number> vulnerabilities on Tuesday

2) Fast forward 80 days: Threat X is discovered, targeting one of the above vulnerabilities – this is the classic Day Zero

3) Fast forward somewhere between eight minutes and two weeks: numerous IDS vendors release some large number of exploit-based signatures

The winner of the “competition” was always the vendor who released their exploit signatures in the shortest timeframe after Step 2; and then, issued the press release. So went the early days of Network IPS.

Then, rather suddenly (around 2005), Step 2 shortened from 80 days to 10, then five, to two, and then finally to one day. This made some of us in the industry take pause, and to think – there’s something far more sinister at work here.

What was ignored broadly then, and is glossed over broadly now by many IPS vendors, is that the above timeframe is nonsense at its core.

Instead, we need to look at this very differently:

1) New software is released to market. This is Day Zero.

2) Fast forward 0 seconds: Vulnerabilities exist in this software, but not many people know about them

3) Fast forward several weeks: Attacks are underway against these vulnerabilities, but they are isolated and targeted

4) Fast forward three months: Software vendor announces vulnerabilities and patch on Tuesday

5) New, broadly used exploits are discovered against those announced vulnerabilities

6) Security vendors scramble to be the first to market their protections to Step 5

What is overlooked (Steps 2-3) is fundamental to the challenge we face: the day a new piece of software is released to the market, there are vulnerabilities, and there are certainly hackers exploiting them as fast as they can discover them. The protection gap — rather than being from the time a new vulnerability is announced to the day a new attack is discovered — is actually the time from when the software is released to the time the vendor issues the patch. Then the cycle starts all over again.

So what is Day Zero now?

Day Zero needs to be thought of as the day a new piece of software is released. And in order to protect yourselves in our second scenario above, you need to know that your network protections are guarding against what we don’t know, versus what’s made the headlines.

That’s where Vulnerability Analysis on your IPS comes into play. It’s no longer adequate to look for what’s been announced. You need to be ready for what the hackers are doing long before the press release comes out. That’s where McAfee and BT come in – we have more than 350 researchers on staff finding vulnerabilities and fixing them long before the software patches come available, and eons ahead of the rest of the industry. And it’s why we can claim that our platforms, and hence BT Managed Security Solutions Group, protect customers on average 80 days ahead of the threat.

The proof is in the results. Verifying a vendor’s claims can be a challenge, and it’s precisely why independent validation is so important. Want more info? Visit http://nsslabs.com/IPS/McAfee-M8000.html for more information and to understand why vulnerability analysis and IPS detection accuracy are so important.

As Director for Network Security, Mike Nielsen is responsible for all elements of McAfee’s Network Intrusion Prevention Systems on the highly successful I and M-series platforms. Mike is a veteran of the telecom and security industries, with more than 15 years experience in developing, deploying and marketing high-speed network and security solutions.

http://nsslabs.com/IPS/McAfee-M8000.html

Monday, October 26, 2009

National Cybersecurity Awareness Month Tip 4: Testing Your IDS/IPS

Tom Le, Director Research and Development, Managed Security Solutions Group, BT Global Services

Do you perform any testing on your IDS/IPS? What are your test procedures when applying a signature update, deploying a policy change, or enabling some new analysis module? After all, you wouldn’t consider releasing production software without adequate testing, so shouldn’t the same apply to the IDS/IPS deployment process in a production network environment?

The reality is that few organizations perform much, if any, testing on their IDS/IPS infrastructure. Many consider IDS/IPS as part of the networking infrastructure, where most changes are considered operational tasks that do not go through a development life cycle that would include testing in a lab environment prior to a production rollout. The big problem with this approach is that while most changes to a router or firewall can be validated immediately, IDS/IPS changes typically have no immediately measurable impact.

Without having an explicit list of measurable test objectives, you have to rely on empirical testing. This is actually simple to do with an IDS/IPS because you have an abundance of empirical data available, i.e., your existing network traffic. To empirically test the impact of IDS/IPS changes, a simple procedure would include:

Capturing a good sample size of existing network traffic, such as 24-hours of network traffic.
Replaying the captured network traffic against the current and new IDS/IPS configuration using a tool such as the open source tcpreplay.
Compare the alerts generated by the IDS/IPS in both replay runs to determine any impact of the new configuration.

This same traffic payload is now kept as a baseline and used for automated testing before every future IDS/IPS update. Another feature of tcpreplay is that you can replay a lot of captured network traffic in a short period of time, which allows for testing many hours worth of network traffic in a few minutes and for load testing your IDS/IPS.

The current version of tcpreplay is 3.4.3 and is available at http://sourceforge.net/projects/tcpreplay.

Wednesday, February 11, 2009

Conficker: What’s Next?

Senthil Venkatachalam

While the Conficker worm has caught everyone’s attention because of its ability to propagate rapidly, what comes next may be even more damaging and costly to businesses.

Conficker is a classic worm in that it propagates through un-patched windows systems, specifically through a particular service known as Windows SMB (port 445). In addition to the classic worm behavior of self-propagation by finding other un-patched MS Windows computers, this worm also takes advantage of the “autorun” facility within memory sticks to propagate itself. While this is a nuisance, the greater security threat comes from the fact that the worm tries to crack the administrator password of the host system.

If the worm is successful in cracking the administrator password, it effectively has “the keys to the kingdom” and it has the potential to reach out to controllers out on the internet, participate in a botnet and turn the host system into a zombie.

Our concern that infected hosts could be roped in to participate in a botnet, seems to be coming true. The Trojan – which is the malicious executable placed by the worm in the infected system – has coded into it instructions to contact command and control servers out on the internet. Since “static” internet domains can be easily identified and shutdown by law enforcement, the malicious command and control servers controlling the Trojan use clever and sophisticated methods known as fast flux DNS to cover their tracks and make detection very difficult.

Monitoring a customer network’s security devices such as IDS/IPS platforms and firewalls provides significant protection against the propagation and further spread of the worm; the new software updates and signature sets from vendors of these security devices will help. However, despite these measures, Trojans could go undetected without further protections in place. Consider for example, an infected laptop that is inserted into the network: even if the worm’s propagation attempts are blocked via the firewall and the host system is patched for the worm – the Trojan is still active until the host is clean up. During this period, the Trojan can and will contact the preprogrammed malicious C&C domains.

In order to detect such behavior, BT has developed custom signatures for the SNORT IDS/IPS platforms. Once installed, these signatures will fire when they detect Trojans attempting to contact C&C hosts, alerting the BT SOC to their presence. Customers can then pinpoint the location of the infected host location, isolate it and perform clean up to get rid of the problem and not just the symptoms.

BT MSSG also recommends several steps to protect their networks and systems on a proactive basis:

Keep all Windows systems updated with the most current Windows OS patch levels as well as the most current Anti-Virus (AV) engine and definition files
Keep all security devices including firewalls and intrusion detection/prevention systems (IDS/IPS) up-to-date on signatures and software patches
Close the Microsoft/SMB port 445 to traffic that traverse firewalls
Strengthen administrative passwords on host systems and follow best practices on password protection
Monitor firewalls, IDS/IPS systems and hosts for greatest protection
Educate users on strong password policies as well as the need to actively scan new media including memory sticks using AV client products

For further technical details, visit:

http://bt.counterpane.com/Risk_Assessment_W32.Conficker_Worm_Update2.pdf