BT MSSP « SecureThinking

Posts tagged BT MSSP

Friday, August 13, 2010

Five Common Myths of Unified Communications

By Douglas Drew, Christopher Heinz, Senior Consultants, BT

Information technology is fundamentally about enabling business communications. Yet when business owners consider a technology to facilitate this process, they often face resistance from the information security team. Open communications and information security are diametrically opposed.

Tremendous power and capability are to be gained with the deployment of a Unified Communications and Collaboration (UCC) solution. However, a lack of clarity around UCC needs and their security implications can hinder the deployment. The issues may not be as clear as they would seem on the surface — we’ll call these the “myths” of UCC Security challenges.

Myth #1: We have to open the firewall up too much.

When considering deploying a UCC solution, the conversation often ends at the firewall. “I will not be able to open 10,000 ports” seems to be a common response, albeit a simplistic analysis. In an ironic twist, more effective communication between the UCC team and security personnel reveals that those ports are only open to the UCC server. That permits the deployment of the UCC server within the DMZ and the access controls to limit those open ports to a single server or pair.

Myth #2: Those 10,000 ports are always open.

Those ports are dynamically opened during the call set-up process and are used for the streaming of media. That means the number and allocation of ports varies during usage, since ports are only open during an active communication session. Ports are opened on an “as needed” basis, so the claim, “10,000 active listeners,” just isn’t so; reducing available attack vectors dramatically.

Myth #3: UCC communications should be run across a VPN.

Doing so would be redundant. Current UCC implementations run over SIP-TLS. That means that the SIP traffic, the actual data stream, is encrypted via TLS. TLS is an encryption protocol functionally equivalent to SSL, which is a protocol accepted for online banking transactions. Adding a secondary encryption induces significant overhead, possible degradation of service, for little to no gain in security.

Myth #4: Identifying remote nodes will be a security challenge.

Actually, current UCC architecture best practices deploy/leverage Public Key Infrastructure (PKI) for remote node identity management. PKI is the cornerstone of most secure encryption methodologies, including https. By deploying/leveraging a certificate server, remote nodes are validated automatically.

Myth #5: UCC security challenges are complex and there’s no one to help.

BT is here to help with a full suite of complimentary information security solutions. Service offerings include penetration testing, scheduled remote scanning, etc. Please contact your local BT account manager for more information.

Have we missed a myth? Please add to our list by posting a comment below.

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?

Monday, March 29, 2010

Missing elements in PCI DSS

By Sushila Nair, Product Manager, Managed Security Solutions Group, BT Global Services

It is interesting to note that chip and pin was missing from the study initially done by the PCI council in 2009 on emerging technologies and yet is mentioned specifically by Bob Russo during a panel discussion at RSA. Key Management Insights recently posted this to their blog:

Bob Russo, General Manager of PCI Security Standard Council, boiled it down to: “There needs to be a mind shift from just compliance to security [since] compliance is a byproduct of good security.” And when it comes to PCI DSS, Russo added, “PCI DSS is the baseline.” Russo hinted at some of the clarifications coming in the PCI DSS update in October 2010. He identified three of the technologies which are likely to receive clarification as:

Chip & PIN technology
End-to-end encryption
Tokenization

The focus on new technology, though not a panacea, is an acknowledgement that our current methodology for securing payment data is difficult to secure. Retail sectors, which operate on tight profits, are struggling to have the in-house expertise to put the right controls in place to protect the data they house.

Given that Payment card data was stolen in 84 percent of the 285 million security breaches recorded in 2008, according to the most recent Verizon Business Data Breach Report, the payment card industry realizes that something needs to be done. Security breaches are ever increasing and if the industry does not take action, then it is likely that the federal government will impose additional regulations.

The focus on continuous control monitoring is key to understanding what your security posture is. While it is impossible to have impenetrable security, it is critical to be monitoring your network so when a breach does occur, the correct action can be taken.

Undoubtedly, the stakes of not complying with PCI-DSS are rising. Companies that don’t take PCI-DSS seriously are exposing their customers and themselves to an unacceptable business risk, and their cost of doing business will surely rise to cover the net impact of breaches. The real question is whether the costs will rise in a controlled fashion as companies put in place best practices, such as outsourcing, to enable their security to be in the hands of seasoned experts — or if businesses will allow costs to spiral as they pay for fines, compensation, and remedial activities in response to data breaches.

Wednesday, March 17, 2010

Guest Post: Reaction to Cyber Shockwave

By Richard Bejtlich, Director of Incident Response, General Electric

Last month, I posted a story called “Reaction to Cyber Shockwave” on my TaoSecurity Blog. Cyber Shockwave was a real-time simulation of a U.S. National Security Council meeting, where former government, military and national security officials acted as the NSC principals (National Security Advisor, Director of National Intelligence, Attorney General, and so on). The participants dealt with a malware outbreak that disrupted telecommunications and critical infrastructure. CNN recorded and then broadcast the event. Overall my reaction was positive, yet online commentary was mixed at best. What was the disconnect? The answer, strangely enough, involves the title of this BT Blog — “Secure Thinking.”

Please forgive me as I share some professional history. I am a former U.S. Air Force military intelligence officer. One of the programs that prepared me for that role involved a graduate degree at the Harvard Kennedy School, then known as the Kennedy School of Government. As a candidate in the Master of Public Policy (MPP) program, I interacted with students, faculty and guests who were former, current or aspiring public servants. These included other military officers, members of Congress and their staffs, lobbyists, non-government organizations (NGOs), and others involved with developing and delivering public policy. All of them brought unique points of view to the national security and domestic policy debates at HKS.

What does this have to do with secure thinking and Cyber Shockwave? The reason I found the event fascinating had nothing to do with the realism of the scenario or the accuracy of the technical details. I found Cyber Shock Wave intriguing because it taught me how high-level officials think. I consider knowing how a person thinks to be one of the most important factors in any professional relationship. When you know how a person thinks, you can tailor your message to make an impact.

Watching Cyber Shockwave, the participants revealed how they think about digital incidents. For example, the simulated Secretary of Defense assured the simulated National Security Advisor that the nation’s nuclear weapons and command-and-control were secure. That is so very important, but if he hadn’t made that statement, I would never have considered it in the context of this scenario.

One of the President’s simulated advisors advocated deploying the National Guard in order to maintain the peace and assure citizens that the government was still in charge of the country. Again, I would not have imagined that recommendation during a digital incident. Some simulated advisors advocated taking action despite lack of Presidential or Constitutional authority, while the simulated Attorney General said she would not be bullied into “signing an order” because her name had to appear on it. All of these vignettes revealed very important aspects of policy-making at the national level.

For me, the lesson of Cyber Shockwave is to first determine how your leaders think, then recommend policy actions. In the realm of digital security, this requires identifying what priorities your management places on digital security. With a better understanding of their thought process, you can tailor your message to match their strengths, weaknesses, hopes, fears, and biases. Please note this does not mean “learning to speak the language of the business.” Trying to shoehorn digital security problems into “return on investment” or “value at risk” formulas is a recipe for disaster. Rather, determine how your listener is likely to receive your message, and make sure that he or she hears what you want to convey.

Richard Bejtlich is Director of Incident Response for General Electric, and serves as Principal Technologist for GE’s Global Infrastructure Services division. Richard is a graduate of Harvard University and the United States Air Force Academy. He wrote, “The Tao of Network Security Monitoring” and “Extrusion Detection,” and co-authored “Real Digital Forensics.” He also writes for his blog (taosecurity.blogspot.com) and TechTarget.com, and teaches for Black Hat.

Tuesday, March 2, 2010

Guest Post: Our Future in the Cloud

By Sanjay Mehta, senior vice president of Breach Security

Cloud computing is a hot topic at this week’s RSA Security Conference in San Francisco. The amount of time the conference has designated to discuss, explore and debate the numerous security issues surrounding cloud computing is proof positive that more business – and supporting technologies – are taking place in the cloud.

But as more business technologies utilize cloud computing, new opportunities have emerged for hackers and cyber criminals to exploit vulnerabilities and profit from business applications using outdated security solutions for protection. In short, the evolution of business technologies using cloud computing means that security solutions must follow suit – now.

Rapidly changing security needs require the benefits and advantages that Software-as-a-Service (SaaS) and cloud computing provides. Security providers that don’t leverage cloud technology are quickly becoming antiquated as all technology – business and security – moves into the cloud.

Using SaaS or cloud computing provides security technology with distinct technological advantages, such as making security updates and code changes instantly available to clients. In addition, new security technology needs to be developed specifically for the protection of business conducted in the cloud. The technology landscape has changed and security needs to keep up by including cloud security needs and requirements at the forefront of the development process.

Breach Security is working with partners, such as Akamai, to provide web application security in the cloud. For example, when deployed with Akamai’s Web Application Firewall service, Breach’s WebDefend Global Event Manager is the first web application security management solution to defend against global application security threats by enabling customers to make distributed cloud and data center defense-in-depth architectures operational.

Breach and Akamai are guarding their clients against security threats in the cloud. Are you protected?

Sanjay Mehta has more than a decade of experience driving revenue growth and strategic business opportunities at Internet security and technology companies. As Senior Vice President, he is responsible for overseeing Breach Security’s go-to-market strategy, expanding the company’s channel and maintaining and growing its existing customer base.

Thursday, December 17, 2009

It’s Not Just Santa Who Wants Your Cookies: Securing Your Network Through Logical Separation

Rob Jamison, Manager, Network Intelligence, Managed Security Solutions Group, BT Global Services

The logical or physical separation of computers between those using the intranet and those able to access extranet/intranet sites is an often overlooked but essential part of securing your network. By NOT separating computational environments, businesses run the risk of exposing otherwise well-patched systems with prudent users to all sorts of attacks, including Man In The Middle attacks carried out via a functional flaw in the ubiquitous TLS/SSL protocol.

A frightening, yet real scenario, is that there are so many ways to lose confidentiality and integrity in your cookies, that doing something about it may seem overwhelming.

For instance, working from any public location with a wireless network card leaves you vulnerable to hijacking. It is surprisingly easy to have your wireless card commandeered into a non-broadcasting access point by someone who has set up a trap at your local coffee shop. Without too much effort, they can capture sessions coming from your wireless card, including many Smart-Phones, which are often configured to seek out wireless access points by default. If you’re using wireless, make sure the latest firmware drivers are installed and that they are configured to refuse all networks except those explicitly allowed with a WPA2 key.

However, even when you’ve established a legitimate network connection with a trusted gateway, it’s wise to consider other exploits, like Cross Site Request Forgery (CSRF) and Cross Site Scripting, both of which can redirect your browser and result in private information theft. A recent test exploit obtained Twitter passwords by taking advantage of Twitter’s rudimentary password encoding scheme. This exploit, coupled with shortcuts taken by OpenSSL in not reestablishing a full encrypted handshake when rebuilding a prematurely terminated connection, allows us a little window into what could be a very big deal in cloud computing security.

This is a building block attack, as the magnitude of damage is a function of how much confidence and trust the backend systems give to that session’s user. Security is the enemy of convenience, so reasonable limitations are often tilted in favor of getting more work done, more quickly.

As earlier inferred, in renegotiation between client and server, OpenSSL trades integrity cycles for efficiency cycles. Essentially, it’s similar to a painter who leaves a ladder in place overnight (to easily return to it the next day), enabling a thief to access the ladder to climb in through the window. It assumes that a recently disconnected client doesn’t need to repeat the entire SSL handshake to revisit the level of trust established during the previous session. This “assumption” of continuous integrity allows an attacker to get into the communication stream (MITM attack) and obtain any confidential or privileged information that only the victim should be privy to. Worse yet, it allows the attacker to submit input to the server as if they were the authenticated user.

If using an OpenSSL-based VPN with persistent session privileges, the keys to the kingdom could be at stake. If that session has involved a client’s escalation (e.g., “enable config” privilege on a Cisco router), then there is a strong possibility that the attacker could inherit those privileges temporarily. Any time that a session is hijacked — while the utilized vulnerabilities may be transient and pose only a single session breach, an attacker may be able to install a rootkit allowing them to return at leisure.

Very briefly, this TLS/SSL renegotiating vulnerability affects almost all software using the OpenSSL package to perform encrypted exchanges between client and server. This vulnerability is independent of cipher strength, input validation and other implementations of best practices. What it does allow is for someone acting as a rogue server to get in the middle of a properly created TLS/SSL session, obtain a new session key, and superimpose their malicious instructions on the conversation between the client and the server. For a more thorough explanation of how this attack works, start here:

http://www.ietf.org/mail-archive/web/tls/current/msg03928.html

For the entire thread on how this is being dealt with by the community, check this site: http://www.ietf.org/mail-archive/web/tls/current/threads.html#03928

Because this is such a complicated concept, and one that affects so many business critical applications, there is no easy backwards compatible solution. A solution that will work against these types of attacks in the future may be technical in nature, but mitigation against potential damages can be done now by having IT staff focus resources on the separation of internet and intranet (business critical) web environments. Installing separate sandboxes and building a browser environment that encapsulates cleared and non-cleared sessions between different HTTP workers—essentially a dual “browser” mode based on whitelisting/non-whitelisting — may be a partial solution here. One project dealing with a virtual sandbox can be downloaded through the following link, however our BT MSSG security group has not yet tested it:

http://github.com/eligrey/jsandbox/zipball/master

These attacks are particularly complex and stealthy because they are usually session-based and nearly impossible to track while they are in progress. While we’re not claiming that “the cloud is falling” if you’ve got network design on the horizon, it’s a good opportunity to consider forcing a logical separation between critical and non-critical networks. We are not recommending any particular tactics but rather a strategy. Our readership is too broad in requirements for even a handful of technical solutions, but our Ethical Hacking and Consulting Groups can engage your groups to assist in this endeavor.

So, as you begin to review the list of IT security projects you’d like to propose and accomplish in 2010, take a moment to reflect on some of the less common ways that your network might be exploited.

After all, it’s not just Santa who’s looking for some delicious cookies this season.

Monday, November 30, 2009

Security Trends and Cyber Monday: What John Pescatore’s Comments Mean To You

Toby Weir-Jones, Vice President of Product Development, Managed Security Solutions Group, BT Global Services

Most internet users give little thought to security issues beyond asking their teenaged neighbor if it’s safe to send pictures of Fluffy to their kids at college. Despite untold billions spent on awareness campaigns for the home user and at work, seemingly endless patches to Internet Explorer and Firefox, and any number of other reparative measures, we still have the same basic problems today that we had 10 years ago: users make mistakes that appear to have no real consequences, but in fact can be massively troublesome, and even potentially expensive.

John Pescatore, VP and Research Fellow for Gartner Research, was recently interviewed by Tom Field at BankInfoSecurity.com, in which he gave his opinion on the pressing security issues of the day. Among his various suggestions, the most intriguing is the notion that internet activities should be insured and, more importantly, that users should have some kind of incentive structure in order to become insurable.

Cyber Monday is just the beginning of the online seasonal frenzy that will run its course over the next few weeks. Your family, your colleagues and your staff are all likely to buy something online. Some of them will start by looking for coupon codes, or responding to apparent promotions received by email. And a smaller subset will end up going to the wrong sites, picking up some kind of nasty malware, and generally having a rotten time when their machine gets taken over, or they enter the credit card information into the wrong place. Who is really responsible for the costs of cleanup and recovery under those conditions?

Right now we pay for clean-up, but very indirectly, because the losses are generally borne by the banks that issue the credit cards. Sometimes, after a failed PCI audit, the merchants might be penalized, or suffer a chargeback if they didn’t validate a transaction correctly. Those costs – plus administrative overhead and markup – do eventually come back to the consumer in the form of fees, higher prices, or reduced availability of purchasing options. But since we don’t see them on the “Checkout” page, it’s as if they don’t really exist.

And this is the root of the issue. As users we perceive that everything we do online is free unless we consciously choose to accept to pay for it ourselves. But we also feel entitled to push all remaining costs (for development, or delivery, or risk management) back to the supplier, manufacturer, or their proxies. The status quo is so powerful that any one provider who tries to change it will see their customer base evaporate overnight, shifting to a competitor who could withstand the expense an extra day.

The system, for all its efficiencies, has introduced costs which wiggle their way into all the little nooks and crannies brought about by automation and complexity. “But if I buy it online, it has to be cheaper!” you cry. But what constitutes “it”? Yes, you’ve removed retail space and all those expenses, and your order fulfillment is doubtless more efficient, but you’ve also introduced multiple new opportunities for risk, fraud, and expense, none of which you, as a consumer, are currently willing to pay for.

There is evidence, however, that the balance is beginning to shift. Some credit card issuers are already charging a premium if you make a purchase in a country foreign to your billing address – this is nominally a hedge against the increased risk of fraud, and it has the added benefit of being a massive profit center to off-set other costs incurred in the domestic market.

Pescatore’s notion that the users need to demonstrate some form of insurability requires at least two steps: the user goes through the motions and then the underwriter bestows its blessing. This will fail as long as a single-step option, i.e., the status quo, is available. Think of Pescatore’s suggestion as PCI for retail consumers, but with much sharper teeth. There will be huge outcries against such a scheme, but as consumers we must accept that our choice to use e-commerce vendors introduces additional costs into the system. We can pinpoint where those costs originate quite accurately, based on the nature of the abuse, and it is those locations which should bear the costs (if they are legitimately responsible) or be able to pass them along the supply chain (if they are not). While I am rarely a defender of banks, the current regulations limiting consumer liability to $50, simply because a credit card in their name was involved, are far too simplistic.

One way to make such a model more palatable is to pool the risk. Lots of cards track purchases and accrue credits to a cash-back credit account, so we know the mechanics are easy enough. Instead of charging consumers outright (thereby increasing transaction costs each time they make a purchase), collect fees on certain higher-risk transactions, pool the premiums, and then disburse those funds on a quarterly or annual basis to cover loss from any transaction using that issuer’s cards. Don’t allow the banks simply to treat this as a fresh revenue stream; require any fees collected to be used first to offset incentive and IT conversion costs, second, to cover losses for otherwise-compliant merchants, and only third, to go to the bank’s bottom line.

In the meantime, modify the merchant fee structure to offer immediate penalties and incentives for compliance with next-gen PCI. Create a new PCI demarcation for IT shops that can help smaller merchants modify their web sites to use more robust processor engines. Help the smaller merchants by making it more attractive for them to run their credit card processing through larger, more established e-commerce providers, and create a market for those providers to buy books of business (via a combined cap cost and annuity) from the small and fringe processors.

Finally, make the increased cost of all this visible to the consumer. Pescatore wants a dashboard to tell a CEO if his network is safe, but a consumer needs to know that his purchase price is paying for more than just the item and the “free” super-saver shipping. Smart merchants and credit card issuers can leverage their compliance with such programs as a stronger value proposition to attract consumers, and more active participants in the risk-pooling model will help distribute accountability while amortizing recovery costs.

Friday, October 30, 2009

Don’t Let H1N1 Impact Your Business

Jill Knesek, Head of Security, BT Global Services

H1N1 has been a topic in the news for some time and shows no sign of slowing down. Since April, more than a million Americans have caught H1N1, more than 10,000 have been hospitalized and about 1,000 people have died.

While public health officials are working to distribute the vaccine for H1N1 through state and local government agencies, the rest of us need to ensure that we are preparing for what is to come. Last year, when I blogged about this topic, the state of the pandemic flu was not nearly what it is today. Now, it becomes more critical than ever for organizations at all levels to have a plan in place.

A business continuity plan is a must for organizations of all sizes. Consider the following when you think about what this plan should include:

Take preventative steps: Encourage employees to be proactive in their health and follow the guidelines set out by public health officials.
Take advantage of telework policies: By allowing employees to work remotely, businesses increase efficiencies and lower the chances of spreading the virus throughout the office.
Prepare for downtime: There will be employees around the globe who will be absent from work due to illness. Make sure your employees know to report absences so that hotspots can be identified and workload and critical services can be managed. Companies need to prepare for downtime and have a plan in place for when downtime occurs.
Determine what is critical: Take a look at your business operations and services and determine what is most critical. Once priorities are set, think of the worst case scenario and then develop a plan to ensure that these critical business operations remain up and running.
Develop a communications plan: In case of an emergency, ensure that there is a plan for communicating to all of your employees. Take into consideration that phone trees alone may not be effective due to issues with technologies. A communication plan should have more than one way for employees, customers, vendors, and other key members to get information about the status of the company.

The bottom line is that companies must realize that disaster planning and business continuity is essential to ensure that businesses continue to run even when a pandemic or any other disaster occurs. Planning, practice and action will make all the difference to your business if you are impacted by H1N1.

http://www.nytimes.com/2009/10/12/opinion/12offit.html?_r=2&th&emc=th

http://bt-securethinking.blogspot.com/2008/11/what-is-your-business-continuity-plan.html

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.