23 Jan 2013

5 minutes with Packetloop Beta

0 comments Permalink Wednesday, January 23, 2013

Thanks for the terrific response we have had to the launch of the Packetloop Beta!

For those of you that want to check it out but creating an account is too much for you here is a video ;) Remember this is the Beta. We have some tricks left for our commercial launch.



The key features the video reinforces are;
  • Analysis of attacks within massive full packet capture datasets is simple and fast.
  • Zoom in from years to minutes [wicked fast] with no loss of fidelity.
  • Pan left and right to go forward and back in your timeline.
  • View attacks from different perspectives or lenses.
  • Filter or Search on any criteria and make it relevant to the time period being analysed.
  • Guides help identify anomalies and outliers.
  • Data panels provide additional information and are linked to the period being analysed.
You could read all these bullet points but what I really want you to do is enjoy/love using the product :) So signup and give your mouse wheel a scroll and feel the power of zooming in and out and filtering on anything that interests you.
22 Jan 2013

Packetloop On Premise

0 comments Permalink Tuesday, January 22, 2013
We are receiving a lot of questions about when we are going to make Packetloop available as an on premise appliance solution. The fact that these requests are coming before our commercial release is humbling and we really appreciate your interest and support.

We understand that there are some legal or regulatory situations where your data simply can't leave your network. Whilst we are committed to releasing an on premise solution for Packetloop in the future, please keep in mind we are still a small company, early in our development phase, and with limited resources (time and money) we have had to choose a direction that gives us the best return on effort and gets users working with Packetloop.

Packetloop is designed for the Cloud, and part of our rationale for the product was to make Big Data Security Analytics accessible to everyone and unshackle it from a significant capital purchase. Our Cloud approach is simple:
  • Easy to use - just upload a packet capture, no complex integration needed.
  • Cost effective - pay per GB you upload, no large capital expenditure.
  • Agile - the cloud allows us to continually deploy new software features quickly and frequently.
  • Scale - terabytes and terabytes of data that make our product more accurate and intelligent.
The risk inherent in uploading captures to our service is different from customer to customer and can only be calculated by you. Some of our customers have little concern as they are tapping their Internet connection above their perimeter firewall. In this way sensitive data is already protected through encryption. Others are looking at monitoring sensitive networks and absolutely require an on premise solution.

We have four methods of uploading captures to Packetloop:
  1. Web Upload - drag and drop or select packet captures for upload.
  2. Secure File Transfer - batch or schedule upload using SFTP.
  3. S3 Bucket - provide access to your S3 bucket for us to process storage packet captures.
  4. Send us a disk - send a USB drive with up to 8TB of packet captures to us for processing.
The roadmap for all 4 methods of upload is to support encrypted archives where a passphrase (optional) is required to decrypt the packet captures prior to processing. In this way they are encrypted in transit and at rest.

Once all of our upload methods are complete we will focus on other solutions for you to access Packetloop. Currently we are looking at:
  • Packetloop Onsite Appliances - depending on the speed of your network and the period you wish to retain your data for a number of Packetloop Appliances are installed inside your network. By stacking these appliances (2 RU servers) we can scale the compute, storage and database required to run Packetloop on premise.
  • Packetloop CloudTap - your data is tapped as it flows through a Packetloop geographic instance that we manage either via BGP or via a Direct Connection to your data centre. In this way all data passes through our implementation and there is no requirement for data to be uploaded. This has the added advantage of allowing us to process and update the application in real time.
  • Packetloop AMI - a downloadable Amazon Machine Instance that receives packet capture information from systems you operating in EC2 or VPC and forwards the data to Packetloop allowing us to update it in real time.
Now the question I expect to get is ....WHEN!?!?. At the moment our focus is 100% on the Cloud and delivering what we said we would on that platform. We want Packetloop to do what it says on the box! Once we deliver everything we are currently working on, we will shift some focus to these solutions.

As you can see, we have a lot on! The best way you can help us get these alternative solutions to market is to support us by uploading to www.packetloop.com once we have the commercial Cloud release out!


15 Jan 2013

Packetloop Beta Release is here!

4 comments Permalink Tuesday, January 15, 2013
After nearly two years of development, many sleepless nights and lots of coffee, Packetloop is ready for its Private Beta release, and ready to let you experience Big Data Security Analytics first hand!

In creating Packetloop, we wanted to develop a tool that we would want to use everyday, that would assist us in unravelling security incidents and understanding what happened during an attack. We have certainly achieved that, as we love using it and we are constantly marvelling at how quickly Packetloop finds us exactly what we are looking for, even in huge data sets.

This release will feature our Threats module, and will give you the opportunity to explore and understand the power of Packetloop and work with some well know public data sets. You will quickly see how Packetloop allows you to visualize terabytes of full packet capture data, and how it enables you to focus on specific attacks through intuitive filtering and beautiful visualizations. Most importantly you will witness the speed at which Packetloop can explore the data and bring you results.

We had an overwhelming response to our invitations for the Private Beta and we will be bringing on Beta users in groups over the next few days. If you have registered for the Private Beta, keep checking your mail as we will send out login details and a key to access Packetloop over the coming days. If you haven’t yet registered for the Private Beta, there is still time! Head to our sign-up page and get registered and we will send you an invitation.

At this stage we are only supporting Google Chrome browser, but we are working on additional browser support for the commercial release, as well as additional modules that will allow you a deeper look at your data.

The Private Beta users will be fully supported by our Service Centre, and you can log tickets at support@packetloop.com or by clicking the Support link once you are logged in. We will also be sharing and discussing the progress of the Packetloop Private Beta through our Google+ page, via Twitter (@Packetloop) and this Blog (blog.packetloop.com). We really value your feedback, and encourage you to communicate with us on anything to do with your use of Packetloop.

The ability to upload your own full packet captures for review will be available in a few weeks time when we release the commercial version and we will keep you posted as to the release date. For more information on the commercial release or to talk to us about using Packetloop in your organisation, contact us at info@packetloop.com.

We hope you enjoy using Packetloop as much as we do, and know that it will become an invaluable tool for security professionals everywhere as they continue to deal with an ever increasing volume and sophistication of attacks.


11 Jan 2013

Finding Zero Day Attacks with Packetpig

0 comments Permalink Friday, January 11, 2013

Introduction

When Russell Jurney and I first teamed up to write these posts we wanted to do something that no one had done before to demonstrate the power of Big Data, the simplicity of Pig and the kind of Big Data Security Analytics we perform at Packetloop. Packetpig was modified to support Amazon's Elastic Map Reduce (EMR) so that we could process a 600GB set of full packet captures. All that we needed was a canonical attack to analyse. We were in luck.

In August 2012 a vulnerability in Oracle JRE 1.7 created huge publicity when it was disclosed that a number of Zero Day attacks had been reported to Oracle in April but had still not been addressed in late August 2012. To make matters worse Oracle's scheduled patch for JRE was months away (October 16). This position subsequently changed and a number of out of band patches for JRE were released for what became known as CVE-2012-4681 on the 30th of August.

The vulnerability exposed approximately 1 Billion systems to exploitation and the exploit was 100% effective on Windows, Mac OS X and Linux. A number of security researchers were already seeing the exploit in the wild as it was incorporated into exploit packs for the delivery of malware.

What is a Zero Day?

Put simply it's any vulnerability that can be exploited without an available mitigation. The mitigation most people measure Zero Days by is a patch from the software vendor (in this case Oracle).

If we look at the timeline of this exploit you can see how long it was Zero Day for;
  • The Bug was introduced to JRE on July 28th 2011.
  • It was Disclosed to the Public on April 2nd 2012.
  • The Exploit was available in the Metasploit Framework on August 26th 2012. With other PoC's publicly available around the same time.
  • Detection was available via Snort IDS/IPS on August 28th 2012.
  • Lastly a Patch was available from Oracle on 30th August 2012.
If you compare the date the Bug was introduced and the date of the Patch the Zero Day time is 399 days. Comparing the date of Disclosure with the Patch date is still a staggering 150 days. To put this in perspective, a software bug that affects around 1 Billion devices was able to be exploited for well over a year and certainly was being seen in the wild. Whether you take the view that the Zero Day period is around 150 days (from disclosure)  or over a year (from introduction) both are extremely scary.

So how can you tell whether you were exploited using this JRE bug in the last 6 months or year? How can you prove your network or important systems haven't been exploited using this vulnerability?

Finding Zero Day attacks

Packetpig provides you with the ability to search vast amounts of network packet captures for Zero Day attacks. To demonstrate this I executed the Metasploit Exploit for the JRE bug against a Windows XP workstation and recorded the packet capture. I then went and hid this 500KB capture amongst 600GB of Full Packet Captures from a system we monitor on the Internet. Every packet is captured to an S3 bucket so we can quickly scan the S3 bucket for Zero Days using Amazon's Elastic Map Reduce.

So for the purpose of this demonstration as soon as the Snort Signatures were updated on the 28th of August I downloaded them. This allowed me to scan my 600GB of packet captures with the old signatures (in this case 2905) and then against with the new signatures (in this case 2931).

Let's run through the Packetpig job 'snort_comparison.pig' to see how this was done. The key to understanding the job is that we use the Packetpig SnortLoader() to scan the network packet captures with the old signatures and again with the new signatures. Anything in the old signature scan is removed from the new signature scan leaving only the Zero Day attacks.

In the same way as our last post we setup a number of variables using an include.pig file. After that we define old_snort_conf and new_snort_conf;

The SnortLoader() is used with the old snort.conf and the new snort.conf to scan the packet captures;

Next we group (COGROUP) the old and the new Snort scans and we filter out any signatures that appear in both;

Lastly we re-project the data and then store it. The snort_comparison_new/part-r-00000 file is a verbose version of snort_comparison/summary/part-r-00000.

To demonstrate this in practice I test the job on a small number of packet captures on my local development laptop. Watch the video to see how to do it.


Next I take it to the cloud and use 80 x m2.4large instances to process 600GB of full packet captures to find the Oracle JRE 1.7 attack. The 80 nodes spin up, install the Packetpig software (bootstrap) and then go to work crunching the network packet captures. Check out the video to see the full process.