Meet the Bloggers

Vaune Carr, Principal Consultant, BT Global Services

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

Jill Knesek, Chief Security Officer, BT Global Services

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

Ben Rothke, Senior Security Consultant, BT Global Services

Pete Russo, Senior Marketing Manager, BT Global Services

Bruce Schneier, Chief Security Technology Officer, BT Global Services

Ray Stanton, Global Head of BT’s Business Continuity, Security & Governance Customer Capability Unit

Jim Tiller, Vice President, Security Professional Services, North America, BT Global Services

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

Twitter Blogroll About BT

Posts tagged Managed Security Monitoring

Wednesday, September 1, 2010

Back to School Security: Or, What Insider Threats I Mitigated This Summer

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

The summer heat waves are hopefully behind us, and the kids are starting to make their way back to school.  Do you remember those days?  The first lessons of the year are always occupied by new teachers doing a quick refresher to make sure the students are familiar with the necessary material.

As such, it’s a good idea to revisit the basics of information security and, specifically, what we know about the most common source of trouble — insider threats.  And it’s important to remember one crucial lesson — not all insider threats are malicious.  Most are, in fact, accidental.  A quick review of our “Confirmed Kill” data shows that more than 70% of such events that originated from inside customer networks were ultimately due to individuals trying to do the right thing, but falling afoul of policy, acceptable use restrictions, or change control windows. 

The tricky part of this is that, since these incidents aren’t running exploits, or allowing malware to propagate, or otherwise doing something which looks inherently dangerous, signature-based tools are unlikely to have anything to say about them.  Yet if someone, using valid credentials, from an authorized source, happens to make a temporary change to a firewall rule or an ACL on a database, and then forgets to remove it, there is a potentially huge exposure created entirely by accident.  The risk calculation from these insider threats is therefore largely about what might happen next.

The best solution is to couple behavior-based anomaly detection with a monitoring program which is able to incorporate normal activities and escalate them against contextual policy requirements.  If you have a rigid change control window for certain types of activities, and they are observed outside of that window, then you still need to know about the configuration changes, even if they are done correctly by authorized users.  If you don’t have such rigid controls, but your work patterns tend to cluster around common sources or timeframes, a behavior-based system can generate a reasonable profile of “normal” activity and still raise a flag if something appears to deviate.

What about if you’re a global business, with activity happening all the time, from sources all over the world?  Consider that you can still differentiate by internal subnets, or groups of usernames, or other logical groupings, even while everyone works within a single policy framework.  Your monitoring controls therefore should be architected to be able to observe data which is logically consistent with your internal groupings.  This gives you greater flexibility to tolerate different applications of policy without forcing a global team to jump through too many hoops.

Let us know in the comments if you’ve stumbled upon other considerations or techniques, and if you’d like someone to contact you to discuss your particular organizational needs down these lines — we’d be happy to talk with you.

Tuesday, November 24, 2009

All your signatures are dead

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

In early 2003, I visited a customer headquartered in a sedate Midwestern city. They are an industrial equipment manufacturer who had contracted with us to monitor their networks. The company had a strong in-house security staff who were excited about the Managed Security Monitoring (MSM) model. They wanted the oversight we provided as well as monitoring coverage while they were sleeping, on vacation, or out of the office for any reason. While this was a pretty standard arrangement, as was their SNORT IDS, the ruleset our customer contact was running was anything but standard.

There were no signatures to catch FTP attacks, HTTP GET CGI/PL script abuse, or Trojan software connecting out from their network. There were none of the standard signatures detecting myriad CVE’s and BID’s generated over the years — not a single one with an identifiable SID we were used to seeing in SNORT instances! How could someone have been so careless as to bring up a PRODUCTION IDS with so little coverage for targeted or worm-based attacks that had been proliferating the Internet?

CODERED and NIMDA had destroyed networks in the summer of 2001, and SQL SLAMMER had knocked even some of the most robust non-Windows networks offline, due to the saturation of UDP traffic just months earlier. Could this gentleman really have enough confidence that his application servers and Microsoft domain infrastructure was patched, and that no one was running any rogue services on the network?

Truth of the matter was that our customer knew exactly what he was doing. He only wanted to see a handful of signatures that were generic and could indicate that “something” was amiss that REALLY needed to be looked at. Not that something was a quasi attack or could be successful if only that OS was running this configuration of application X — just the nuts and bolts fundamentals of good ‘ole fashion network monitoring. His SNORT’s ran fast, faster than any other IDS of the same hardware investment, because pattern matching was reduced to a handful of rules.

Just as there are three primary colors that make up a continuous spectrum of light, here are three rules our savvy customer was running:

1. Error 404: A client has requested something from my webserver that it does not have, or does not have at the location some client was looking for. When a high number of distinct web servers report 404 to a single client host, that host is not up to any good.

2. DARKNET: There was some IP traffic (ICMP/TCP/UDP doesn’t matter) from an RFC1918 (private) host that we didn’t allocate, or just don’t know about. This is the equivalent of the Police “running” a license plate, and the response coming back “not in system.” How many police would consider that a routine false positive and let the driver go without further questioning?

3. TCP/UDP/ICMP Portscan: With a suitable threshold, applicable target network range, and tuning out verified false positives, something or someone has solicited a bunch of connections to our internal servers. While this is one of the most common false positives, if correctly deployed and monitored, it can be the most useful of all signatures.

There are some clear lessons to be taken away from this short story about a Mid-Western IT manager and his seemingly peculiar rulesets. The bottom line is that keeping it simple is a great strategy. Provided you have a strong working knowledge of your network and its operating environment, simple red-flag conditions can bring a whole world of mischief to light in short order.

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

Monday, February 9, 2009

Conficker – The Largest Worm Yet

Tom Le

We are currently in the middle of the largest worm outbreak in history. Estimates for the number of PC’s infected by this polymorphic worm, known as Conficker or Downandup, ranges from 9 million to 15 million PC’s. Even at 9 million, that is still almost a full order of magnitude larger than the Storm worm which peaked with a 1 million zombie army in September 2007.

To understand how staggering the infection numbers are for Conficker, consider that at its peak Conficker was growing at a rate of over 1 million new infections per day compared to the Storm Worm’s peak of 1 million total infections.

What Can We Learn from Conficker?

While it is likely that this saga is only in its beginning stages, since security experts are still waiting to see what this massive worm will do once it is given its attack instructions, we can learn some lessons about security monitoring immediately. The good news is you can take action right now to prepare yourself for the next wave of attack. These lessons should not be new to anyone using BT’s Managed Security Monitoring solutions, but they are worth repeating again.

1. Monitor everything. We all know that the sooner you know about an attack, the easier it is to contain and the less damage that will be done to your network. While we all have to operate within security budget constraints, it may be worth revisiting how those dollars are being spent. Consider what devices can be added to your current event monitoring. While IDS/IPS monitoring often comprises the core of most security monitoring implementations, BT MSSG actually detected more Conficker worm attacks from monitoring firewall traffic logs.

2. Revisit your Security ROI. The return-on-investment for your security dollars is often underappreciated in the same way to how homeowners or auto insurance is not appreciated until a loss occurs. In the case of a worm outbreak that may have large operational costs, or potentially real business losses, you have to factor in the probability of a loss and the expected cost of a loss to determine your ROI.

3. Don’t be complacent about process. Security is a process. We saw a few incidents this past month where users thought they had IPS signature coverage for Conficker, but, in fact, did not. Users often rely on automated signature updates, but there are many scenarios where specific policies or configuration changes need to be made actively to enable the IPS signatures. If you have an internal process to verify regular updates are active, make sure they are beging followed. You may want to consider adding an additional process so that when BT (or other security vendor) sends out a Risk Assessment, internal verification of vendor IPS/IDS signatures and proper configuration occurs. If you are not staffed to perform these types of functions, consider outsourcing alternatives, such as letting BT manage your IPS/IDS devices.

Beware of Patched, Yet Infected Systems

Even if you have applied the MS08-067 updates, be aware that your Windows hosts may have been infected prior to applying patches!

Let’s look at some data from Qualys to provide some perspective on the expediency of applying Windows patch updates.First, recall that Microsoft believed the vulnerability was so significant that it released an unusual out-of-cycle patch update on October 23, 2008. There was an alert issued 2 days prior to the patch update and the news and awareness cycle around MS08-067 and Conficker has continued since then. Despite this high level of awareness, Qualys’ Wolfgang Kandek reported that 30-days after the MS08-067 update, 50% of Windows machines were unpatched and that after 120 days, 30% of Windows systems were still unpatched. Keep in mind that organizations using Qualys vulnerability scanning tend to have greater security awareness and procedures in place, so the percentage of unpatched systems in the wild is likely much higher.

Secondly, consider whether any Windows systems in your environment may have been vulnerable to attack , even if for a brief period of time, before patches were applied. Do you have mobile users who take their laptops out of the office where the attack could have occurred? If you do this would mean that none of your security monitoring infrastructure would have detected the initial infection. Do you allow users to plug in USB keys that could have been infected from outside your network? Do you have VPN, extranets, or any other types of network access that could allow a system outside of your control to communicate with systems within your network?

If you answered yes to any of the above questions, it is possible that you could still have infected, yet fully patched systems.

As a worst case scenario, consider the risk of having an idle Conficker worm. The Storm Worm had large subsets of the worm population idle which were communicating only to its command & control hosts but not spreading or performing any reconnaissance activity so as to minimize detection. If the rumor is true that the people behind Conficker are the same as those behind the Storm Worm, it would not be unreasonable to assume that detection avoidance tactics may be employed with Conficker.

Bottom Line

Patch now, patch often! Make sure that all your monitoring is enabled and any signs of attack activity are investigated. Where ever possible, monitor everything: IDS/IPS, firewall traffic, host and application activity. Run the Windows Malicious Software Removal Tool (MSRT) on all Windows hosts, even if you do not suspect they are infected. This can be an enormous task for large organizations, but consider running the MSRT in silent mode as part of a domain login profile.

Windows MSRT: http://support.microsoft.com/kb/890830

Deployment of MSRT in an enterprise environment: http://support.microsoft.com/kb/891716

Finally, be ever vigilant and don’t forget that we’re still early in the life cycle of this worm. For all the attention that the Storm Worm received, remember that Conficker is at least a full order of magnitude greater in size. Moreover, we have yet to see what the impact will be when Conficker’s controllers finally tell it to “do something.”

Monday, September 15, 2008

Keys to Establishing an End-to-End Security Strategy

By Jill Knesek

With the anniversary of Sept. 11, 2001, last week, I’m reminded of how security in the 21st century has changed. Today, companies are providing more access (via telecommuting and mobile workforces) to more people (partners, contractors, outsourcing). The result? An erosion of the company’s perimeter. So, how does a company establish an end-to-end security strategy?

First, secure a seat at the boardroom.

Then, think about security in terms of process, people and technology.

Process

1. Create a risk register that is built using annual loss expectancy (ALE) and present it to senior management using a risk matrix

2. Connect security policies with HR, Legal, Marketing, Finance, Facilities and Sales and audit for compliance

3. Adapt policies to support business/cultural changes

4. Have an incident management plan that includes a crisis team

5. Develop a business continuity management plan

People

1. Develop mandatory security training program and ensure compliance

2. Refresh the content periodically

3. Routinely disseminate security messages to ingrain security into the company

Technology

1. Physical security – access control with strict reinforcement

2. Network/systems security involves routine audits of networks and systems to monitor for abnormal activity

3. People Security includes security investigations, incident reporting, fraud monitoring program, intelligence/crime monitoring and travel security

If you are interested in learning more on how to establish an end-to-end security strategy, please join me on Wednesday, Sept. 17, for the “Flexibility is Key: Building a Successful Security Strategy” virtual tradeshow.

subscribe - log in