Month: September 2015

There is a change happening within the security industry. There has never been a greater accumulation of security data available to organizations, in as many forms, from as many sources, as we have today. The mantra has consistently been, “more data is better,” with the hope that this influx would result in increased protection from threats, especially more damaging, targeted and unique attacks. The reality has not delivered on this great promise, with successful cyberattacks and data breaches continuing to occur in organizations around the world.

This raises the inevitable question: how do we improve our ability to identify and prevent targeted attacks?

Here at Palo Alto Networks, we realized the problem facing security teams was not a lack of data, but an inability to prioritize the most critical attacks and quickly take action on them. Over the past few months, we have had the opportunity to share our newest service, AutoFocus™, with hundreds of customers during our Community Access program. Throughout this early access period, we were able to refine our vision, and create a leading cyberthreat intelligence service, which we are proud to make available worldwide today.

AutoFocus was built to help security teams address three fundamental challenges:

• Prioritize alerts for advanced attacks that require immediate attention.
• Understand the context around attacks, adversaries, and campaigns – including targeted industries.
• Respond proactively to threats and prevent future attacks.

This new service provides security teams the intelligence, analytics, and context required to understand which attacks require immediate response, as well as the ability to make indicators actionable and prevent future attacks. As more security leaders consider how to efficiently implement threat intelligence within their organization, we must change the view from “more data” to “truly the right, actionable intelligence.”

We encourage you to learn more about AutoFocus: www.paloaltonetworks.com/autofocus

[Palo Alto Networks Blog]

Network intrusion prevention systems, referred to as IPSs, have long been considered a critical component of any network infrastructure.

Here is how a network IPS works. Vulnerability-based protections detect and block exploit attempts and evasive techniques on both the network and application layers, including port scans, buffer overflows, protocol fragmentation, and obfuscation. Protections are based on both signature matching and anomaly detection.  Anomaly detection decodes and analyzes protocols, and uses the information learned to block malicious traffic patterns. Stateful pattern matching detects attacks across multiple packets, taking into account arrival order and sequence.

Being part of a larger security program or platform, the links in Lockheed Martin’s Cyber Kill Chain that IPS set out to cut are Deliver and Exploit.

Network IPS solutions come with thousands of signatures. These signatures can range from severity levels of informational to critical with many in between. All of the signatures are useful; however, some need more context. This is what the tuning process is all about.

It is recommended to enable all of the signatures in alert only mode during the initial deployment phase, which should last approximately one week. These signatures are what you’ve paid for, so you should leverage as many of them as possible.

The perception of IPSs is that they are noisemakers, difficult to configure, and difficult to manage. Some of this may be the case. Effort is required to deploy an IPS. The purpose of this guide is to provide a methodology for tuning IPS alerts for maximum value of as many signatures as possible while being able to identify actionable incidents.

The best practice for tuning IPS alerts is to take a hierarchical approach. Start with investigating the signatures that trigger most. Alternatively, you may want to focus on the High and Critical severity ones first. From there, determine what the source and destination IP addresses should be doing in the environment. Finally, either fix the problem or create a filter. Fixing the problem may include making configuration changes on the source, destination, or other host. Fixing the problem may also mean preventing certain types of traffic or implementing a filter. Determining the purpose of the source and destination IP addresses by working with internal teams who manage them are going to be consistent tasks, which can take time. Play nice and make friends with these people!

At some point you will want to configure filters to ignore certain signatures in certain circumstances. The team that manages the IPS must take a leadership role and make more recommendations than ask questions when it comes to working internally to filter alerts. A process must exist before you start that includes:

• How long does the security team need to wait for responses prior to filtering?
• How are filters documented (in the IPS filter, in the IT ticketing system, etc.)?
• When changes can be implemented?

Now we can walk through a few examples using some real data from a Network IPS deployment prior to any tuning. The appliance has been in this particular environment for two weeks.

Step 1: Report on the Alert Data

There are many ways to report on which signatures are triggering and the frequency of the triggers depending on the IPS you are using.  You will often find this information by looking at a dashboard, looking through the logs, or running a report. Your goal in this step is to identify the names of the alerts being triggered, the severity of those alerts, and the number of times they are being triggered.

Depending on your preference, you may want to focus on the High to Critical severity alerts by number of triggers. Or you may just want to focus on every alert by the number of triggers.

Here is an example of pulling the top 25 alerts by count.

Step 2: Drill Into the First Alert

The goal of this step is to answer the question: when the sources and destinations triggering the alert are observed, is this worth investigating? If it’s something that is clearly a problem that needs to be resolved, you clearly need to take that path. When the answer is no, you would move to the next stage and tune the alert.

The first two signatures in the list have the same alert count, so are likely related.

• HTTP: User Authentication Brute-force Attempt 
• HTTP: Unauthorized Brute-force Attack (using web-browsing)

Step 3: Understand the Signature and Frequency

The alert description and severity let you know how urgent it is to investigate the issue. The severity on these is High.

It is, however, important to move through the rest of these steps, regardless of severity. The source and destination IP address will add context that is more concerning. For example, if you see an informational alert for DNS lookups, you may initially think that those happen all day long and are, therefore, too informational and irrelevant. If you have specified two unique name servers for all of your devices to use, it would be strange if a name server outside of the ones you provide is being used (it shouldn’t be allowed but that’s a least privilege story). Tuning the signature to only alert if a device is using a name server that is not yours turns this informational event into something much more critical.

Reading into the descriptions of each shows that the definition of the signatures is quite similar. The first brute-force attempt is looking for a certain number of authentication requests between a pair of IP addresses. The second brute-force attack is looking for the same thing and also checking to see if the target is rejecting the logins with an error.

Because the description and the count of these alerts are so similar, we may be able to investigate both of them at the same time.

Step 4: Investigate the Source and Destination IP Addresses, and Application

The source and destination IP addresses add an important piece of context. If both are internal, it is most often a configuration or informational issue for an alert like this. The exception would be if the signature identifies hacking or malware activity, but even those can sometimes be strange (read poor) application programing that looks like something bad. We often see buffer overflow-type attacks fall into this strangely coded category internally.

When we drill into each of the alerts, we find that the same source and destination IP addresses are found consistently.  Both addresses are internal. We can definitely investigate both of these signatures in parallel.

The application in this case is web-browsing, which means the source IPs are browsing or making HTTP GET requests to the destination IP.

If you are unsure what the IP addresses are, there are a variety of ways you can get more context:

• Nslookup <IP address> may provide you with a descriptive enough hostname.
• Browsing to the IP address in a web browser may display a familiar page.
• Connecting to port 80, 443, or 25 on the host may provide more information on what the host is.

In this particular case, we determined that the source of all these alerts was a server. The destination address is a proxy server (that we are working on removing from the environment because proxies are dead!).

Step 5: Determine a Course of Action

By working with the server and proxy administrators, we determined that someone had misconfigured the proxy settings on the server. The server was attempting to use the wrong account to authenticate to the proxy.

The course of action was to fix the setting on the server. The server team was motivated to make the change quickly because things weren’t working because of this. Once completed, all of the alerts stopped triggering. There was no need to make changes to the IPS in this case.

And, in one shot, we took care of 98% of the alerts.

The next 12 alerts make up over 98% of the remainder.

• HTTP: User Authentication Brute-force Attempt 
• HTTP: Unauthorized Brute-force Attack
  using ms-update, trendmicro, instagram, webdav, and sharepoint

The descriptions are the same for all of them. The alert count is also the same just like the first investigation. This means that the same source IPs appear to be trying to log in repeatedly to the same destinations, and they are failing the authentication. When investigating the source and destination IP addresses, they are all internal, except for Instagram.

More diligence is still required to figure out why each of these is triggering, and the application identified will help lead us to a solution. Following is a breakdown of each of the same signatures triggering broken out by application.

• MS-update – The source IP addresses are remote VPN hosts connecting to the network and having an issue authenticating with the internal Microsoft Update server. Speaking with the firewall team, there is a known issue with the VPN client that needs a patch on these systems. It’s worth waiting for the patch to be applied and reporting back to that team on their progress before filtering these alerts. There is a planned maintenance to patch these systems over the next two weeks, so no point in filtering these alerts right now.
• Trend Micro – These are internal hosts communicating with the internal OfficeScan server. This issue was discussed with the desktop support team who helped determine a user account had been disabled on many of the systems leading to these HTTP 404 errors. They were happy that the issue was identified and are working towards implementing the fix. No need to filter these alerts, as they will go away over the next week, once the user account information is updated.
• Instagram – The source IP addresses are all on the WiFi subnet. These are likely phones and tablets whose passwords were changed on the website and not updated on these apps. Because Instagram is not a critical application for this environment, we will create a filter with the source being internal networks, the application being Instagram, and the associated HTTP brute-force signatures, with the action to ignore.
• WebDAV/SharePoint – The source IP addresses are internal. The destination IP appears to be SharePoint, based on the DNS name. When drilling into the alerts, we can see that the URL being accessed is a SharePoint URL. According to the SharePoint administrators, that particular URL contains areas on the page with objects that only a small group of people have access to. The SharePoint team doesn’t want to change the site layout based on the business owner’s requirements. As a result the case will be escalated, documented, and a filter applied. The filter will include the internal source subnets, the destination URL, and these HTTP brute-force signatures, with an action of ignore.

Conclusion

There is always a trade-off of risk for functionality when tuning signatures. On the one hand, you want to use every signature for everything. On the other hand, it is important to tune out noise to make the relevant alerts noticeable.

In these example cases, we were able to find many misconfigurations in the environment that resulted in opening tickets to document the issues and holding them open until resolution. If a filter was the only route, we would no longer be able to see if an internal source address is doing an HTTP brute-force attack on these particular web servers using those specific applications. We are trading that functionality based on the fact that it is happening too often for us to find anything useful in those logs for that circumstance. If an internal host is doing an HTTP brute force, there will be other indicators of compromise that we will rely on, such as the source host getting compromised, malware being transferred to the source host, and the source host communicating with a command and control server.

There will be many signatures that require longer investigations, many Internet searches, and packet captures to validate. Once this process is complete, you should be safe to enable blocking on the High-Critical severity signatures and let the computer do its job of protecting the environment by preventing malicious behavior.

By tuning out alerts that cannot be eliminated by fixing something on the source or destination computers, we bring the IPS alerts to a useable level so we can focus on monitoring for real threats.

Stephen Perciballi

[Palo Alto Networks Blog]

Every day we send and receive requests to connect to people we know on social networks. LinkedIn is the world’s largest professional network with 300 million members in over 200 countries and territories around the globe. It is a great platform to develop and cultivate business connections, but can be rife with deceit and fraud. Fraudsters also use the platform as a social engineering tool, allowing them to connect with professionals and try to lure them into disclosing their real contact details – work email is always best – and then use this email address to send spam, or worse, deliver malware.

When discussing these potential pitfalls with a group of executives recently, I talked about people’s willingness to interact with strangers on sites, such as LinkedIn, potentially revealing sensitive information or otherwise exposing themselves or their employers to scams. An example I took them through was a paper by Thomas Ryan of Provide Security, who set up a profile of a fictitious person named Robin Sage on LinkedIn, Facebook and Twitter.

The profile described Robin Sage as “a flirtatious 25-year-old woman working as a ‘cyber threat analyst’ at the U.S. Navy’s Network Warfare Command.” The paper [1] Thomas Ryan wrote about the experiment and how he used the Robin Sage profile to establish connections with “executives at government entities such as the NSA, DoD and Military Intelligence groups. Other friends came from Global 500 corporations. Throughout the experiment Robin was offered gifts, government and corporate jobs, and options to speak at a variety of security conferences.” Thomas concluded that, “the propagation of a false identity via social networking websites can be rampant and viral.”

Some of the executives were intrigued, but others believed that they couldn’t be fooled. So I decided to walk through them a live example of identifying a fraudster on LinkedIn.

I used a previous invitation request I received and took a look at the profile of a female claiming to be a “senior sales executive who can help me generate more sales leads.” The profile looks detailed and complete with more than 500 connections and even the profile picture looked legitimate. A Google Search for her name and company yield very little. Still suspicious, I use the website whoisology.com to do some vetting on the email address and associated website listed on her profile page. All of these are non-existent.

In further review of the profile, I suspect that the LinkedIn profile photo is not what it may seem, so I use the Reverse Image Search [2] from Google to see what similar photos exist, which results in a surprising find. The same photograph has been used for multiple LinkedIn accounts with different names. All the roles are similar in nature; some even purport to be recruiters.  I also find links to an app on both the Google and Apple app stores, for a secure phone call application. One of the screen shots of the app is the same photo as the LinkedIn profile. This is clearly a case of someone reusing someone else’s photo.

There is no one single method to spot a fake account, though sometimes being a little bit suspicious helps. Here are some tips:

• First, the invitation will probably just contain the canned text mentioned above or some other generic text.
• Always check the profile before accepting an invitation, and do so via the LinkedIn message mechanism, not via the email received, as fake LinkedIn emails can cause more harm than checking.
• There may be simply illogical conditions. Why would someone with a degree from a top school or university, with a good job title and years of experience, have only a few connections, and now be asking you, a stranger, to connect?
• The profile might not have a photo, or the photo may be stolen from somebody else. Use the Google Image Search technique to see if it is a fake photo with a single click (sometimes).
• The profile may be incomplete, it may have misspellings (even in job titles), or the name might not be capitalized properly.

The nature of online social networking involves people establishing connections without having the opportunity to establish the person’s authenticity. This requires taking a leap of faith, which can easily be exploited by scammers. Think about the type of information you have posted in your profile, and ask yourself, “Have I given away too much information about myself and my company?” All too often I have seen security professionals who profess to not telling anyone the controls they have deployed in the environment, to the virtual world where they have no problem stating what solutions they manage or have implemented in their current organization. Care should be given to ensure that we are not making it even easier for cyber attackers to enter our places of employment.

[1] http://media.blackhat.com/bh-us-10/whitepapers/Ryan/BlackHat-USA-2010-Ryan-Getting-In-Bed-With-Robin-Sage-v1.0.pdf

[2] https://support.google.com/websearch/answer/1325808?hl=en

Sean Duca

[Palo Alto Networks Blog]