Home » Articles

PacketSled is Recognized for the Second Year in a Row as SC Magazine’s Industry Innovator in Next-Generation Security Monitoring and Analytics

in Articles, News, PacketSled by Christina Patten Comments are off

SC Magazine’s 2016 Industry Innovator names PacketSled one of only five who have defined what it really means to be “next-generation.”



“Applying advanced analytics to threat hunting and evolving an analyst’s tool into an analyst’s tool that also has very strong monitoring, detection, case management and alerting functions.”

The article comes after technology editor Peter Stephenson conducted a second review of the product. In the review, he quickly arrives at yet another one of PacketSled’s key tenants:

“We never have seen that level of support response in any of the products we have reviewed and it provides a realbeneift both to new users and experienced users with a difficult problem.”

Read the Article

SC Magazine Names PacketSled Innovator in Next-Generation Security Monitoring and Analytics

in Articles, News, PacketSled by rrhyne Comments are off

SC Magazine’s 2015 Industry Innovator segment names PacketSled one of only three innovators in the space. The magazine describes the next generation of monitoring products as:

“sophisticated analytic algorithms, machine learning and heavy, cloud-based analysis allowing very lightweight agents on the enterprise.”
Network forensics dashboard

The article comes after technology editor Peter Stephenson conducted a thorough review of the product, in both live traffic and research environments. In the review, he quickly arrives at one of PacketSled’s key tenants:

“in managing security incidents, speed counts. PacketSled provides easy, fast understanding that allows analysts to pick useful information out of the noise”

Read the Article

Detecting ShellShock Using PacketSled

in Articles, PacketSled, Threat Detection by Web Admin Comments are off
Knock Knock. Bash Bash.  The scope and scale of the bash attack is fairly well known even though its only been public for 24 hours, but in case you’ve missed out on it somehow, here’s a quick recap of the CVE summary that will provide some context:
GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution.
Most of the early exploit activity has leveraged CGI to exploit shell commands. Exploit POCs for other protocols will follow for sure, and we’ll be posting about detections for those in real-time. For the time being, we can make one broad assertion, which is that the payload of the attack will exist in a relatively obvious place, as it did with the HTTP proof that’s out. In order to properly detect and investigate sessions that leverage this vulnerability in your environment, the first step is to isolate the various attributes and their values (HTTP headers in this example). The good news –  If you already have PacketSled, you have all of this data preloaded, not only for HTTP, but for telnet, DHCP, and 2000 other protocols. As Troy Hunt mentioned in his post today, there will likely be additional iterations of the vulnerability. Automatic detection of ShellShock atttempts on a running system: PacketSled behavioral detections were updated for all customers today with a level 10 alert that will fire for ShellShock exploit attempts. The severity of this attack will likely go down over time, as systems become immune or at least improve their resistance to the problem. If you see this detection on your dashboard,
ShellShock Detection in Dashboard

ShellShock Detection in Overview

then the good news is that you already have the detection built in, and any incidents that have been identified are made available for investigation simply by clicking them. If you do not see this security incident, and want to manually identify any sessions that may be exhibiting shellshock behavior, you can also use the natural language search engine in investigator to look through all of your network traffic, with one easy query. For instance:
today http user_agent like /\(\)\s{\s.*;/

ShellShock Investigation in PacketSled

This same query can be run against any attribute in an http flow. Other common places to look include:
  • The User-Agent HTTP header (user_agent)
  • Cookie (cookie)
  • Host (server)
  • Referrer (referrer)
  Finding your highest risk hosts: Now that we’ve identified attempts to exploit this vulnerability, the next logical step is to determine how many hosts we have that are actively executing code out of /cgi-bin. Simply use the investigator to search through all the web transactions that happened in your production environment:
today http user_agent like /\(\)\s{\s.*;/ uri like /cgi-bin 
This search will identify hosts with active applications that run out of cgi-bin, who are currently targets of the attack. Total elapsed time: 30 seconds. 

The Challenges of Threat Detection in a Changing Landscape

in Articles, Big Data Security Analytics, PacketSled, Threat Detection by Web Admin Comments are off
Having spent 20 years being exposed to the real world security problems of customers as a trusted advisor, I’ve had the unique privilege of observing the common challenges that large financial, retail, defense, and critical infrastructure organizations face when trying to address complex, evolving threats. I’ve also watched the security community go from a niche, perhaps misunderstood group of ex-hackers trying to solve the problems that they discover in the soft underbelly of the early Internet to building an entire multi-billion dollar industry who’s goal it is to address the problems that plagues every employee, officer, director, and consumer. Companies have spent millions of dollars on security products to protect themselves and their customer’s data. However, there are still holes, and so-called advanced threats are getting through the cracks. What is needed, once and for all, is a solution that does a better job of detecting advanced threats, as well as providing a means for containing, analyzing and remediating unknown threats that have gotten through traditional defenses. Today’s security practitioners, engineers, and operating teams are currently using SIEM and/or full packet network forensics. Let’s talk about these options. Screen Shot 2013-12-17 at 6.15.33 PMOption 1- SIEM Tools – The idea here is that millions and millions of events being generated by hundreds or thousands of devices are cataloged in a central repository for correlation and processing. Let’s consider this for a minute; In order for technologies that rely on log data to correlate events, three things have to happen: 1. The devices that matter in the context of a security event have to be pointing log data at the SIEM. Most organizations typically prioritize this by starting with their security infrastructure (FW, IPS/IDS, Endpoint). This requirement to prioritize the output of these technologies seems to ignore the fact that the attack vector may have been designed specifically to avoid or elude them, and that the entry point for advanced threats may be somewhere else entirely. 2. Accuracy of the logs you require relies on integrity of the endpoints generating these logs – Attackers compromise IPS/FW technologies routinely, pivoting from internally compromised hosts into the admin interface of these technologies. At that point, its fairly trivial to create or disable rules that enable them to add a pathway for tunneled traffic that goes undetected by said devices, and certainly isn’t generating any useful log data that might be caught by the SIEM. 3. Alerts setup correctly – So what do you do with all the data you now have in one pane of glass? (if you’re even able to do that). Most analysts will tell you that the bulk of alerts they currently look at are not valuable, and that a very small percentage of the data coming across the console pertains to real security threats. Getting meaningful event correlation out of standalone SIEM using noise reduction techniques is difficult to do correctly, and even some of the best security organizations struggle with it.   full packetOption 2- Full Packet Solutions– Traditional full packet technologies offer the promise of much deeper insight into the activities of attackers than traditional log-only solutions, but they exhibit some fundamental problems that preclude them from operating in a manner that is consistent with anything other than “after the fact” scenarios. Areas of concern include: 1. Historical forensic record length – If a user issues a SQL query that results in a dump of thousands of records, and the network forensics solution has visibility into that session, guess what – you’re storing those thousands of records now. If you place a sensor on the ingress/egress points of your network, and someone watches a 40 minute youtube video on bonsai gardening, you get to keep that too. Neither of these things are valuable in the context of a security incident, but nevertheless, they’re quickly eating up expensive storage on your network. While your SOC team may learn some new root trimming techniques, they aren’t getting security value from the data. The fundamental challenge here is that storage requirements exceed the need to retain the data. One saturated 10Gbps link can produce up to 108TB of stored data per day, or 3.2 petabytes per month. It’s no mystery why these tools aren’t being deployed enterprise-wide. The incidents are buried in forests of tiny trees. 2. Fast, intelligent access to the data – Full IP packet data is by definition binary. Other than augmentation of the data with descriptors, full packet solutions have no way of answering user queries or machine generated analytical inquires in a reasonable timeframe that is acceptable for a typical incident response plan. In short – pulling back full packet is slow and ineffective in a real-time solution. It also makes it impossible to distribute the solution over very large environments, because sending the same data to a remote central repository would absolutely destroy even the most resilient networks. 3. Cost of retention –78% of all breaches are being discovered months, or sometimes even years after they’ve occurred. The data is already gone, and the damage is already done. Buying more disks may sound like a cheap option, but ask anyone in charge of buying these solutions, and you will quickly be corrected to understand that an enterprise-wide deployment of full packet capture simply isn’t an option financially. At PacketSled, we care deeply about the issues that plague today’s technology-enabled companies. We’re delivering solutions to these very difficult problems by building a next generation of products that can produce answers about attacker behavior, assets that are or may be impacted, and fastest path to threat eradication / remediation. We do it at scale, in real-time, for the entire enterprise, and in the cloud, at a cost that is commensurate with the security budgets of our customers. I’m very excited to be here, and I look forward to working with you. Matt Harrigan President & CEO PacketSled

© 2017 PacketSled, Inc.