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.”
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.
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.
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.
On Sept. 17, I hosted our first NextWave Huddle, a global channel partner webcast and a key component of my commitment to deliver more clear and consistent communications to you, our partners in FY16.
If you couldn’t attend, click here to listen to the replay and click here to review the presentation.
Together in FY15 we drove phenomenal results: we had nearly 500 partners double their business in FY15, we had more than 12,000 partner security professionals earn technology or sales certifications and we added a record-breaking, 2,000-plus new customers in Q4 FY15, bringing our total number of customers to more than 26,000 worldwide.
Make no mistake, we wouldn’t be the company we are today without you, our partners, and we can’t achieve our goal of becoming the largest enterprise security company in the next two years without expanding the scale and productivity of our partner ecosystem. To achieve this we will focus on three key pillars:
Building a channel partner ecosystem that provides the coverage, capacity and capabilities to elevate our leadership position in the enterprise security market.
Optimizing our channel programs, training, tools, systems & initiatives to strengthen partner differentiation & profitability.
Remaining committed to those partners that are investing in us.
By focusing on these pillars we have an opportunity to drive unprecedented success, as long as we keep you aware and informed. With this in mind, let me highlight a couple of key items for Q1 FY16:
We have a new evaluation tool for you to use with customers, called the Security Lifecycle Review (SLR). Click here to download the Quick Start Guide for Partners today.
On Sept. 15, we announced Aperture, a new SaaS security offering. Make sure youunderstand Aperture and the opportunity to expand your security business.
We have a huge opportunity ($80B) to help transform the data center with VMware, make sure you understand the VMware NSX plus Palo Alto Networks
If you aren’t already, start following us on Twitter @NextWavePartner for real-time updates.
I couldn’t be more excited about the opportunity in front us. We are in the right market with the right strategy, philosophy, platform and partnerships. I am confident we are building a world class channels organization, which includes you, our partners, and look forward to accelerating together in FY16.
In the last few years, a decades-old problem has taken on a new name: cyberattacks. This is now in the top five global risks in terms of impact and probability [1]. The reason for this is well-documented: attacks have become far more personalized, leveraging the techniques and tactics first seen in nation-state APT attacks. For cybercriminals, focusing on getting a hold of the golden nuggets that make each business uniquely profitable, such as intellectual property, businesses process, and data, has far greater impact than the traditional generic attacks.
Likewise, we are sprinting toward a hyper-connected society, and companies’ dependency on technology in order to function and be profitable is increasing. Concerns around BYOD are being overridden by concerns of the much broader Internet of Things, whether that is wearables, mobile payments or connected cars.
It’s easy to see why this has become a topic that is high on national and global risk registers. There is a growing perception that failure is inevitable, breaches will happen, and attackers will get in. My question is: are we giving in too easily?
Human nature means we make mistakes, but, more importantly, that we learn from them. One of the most significant traits we have is determination. We cannot and should not overly focus on recovery. We must find a better way to prevent the problem in the first place. While we accept that road accidents happen, we don’t focus only on emergency recovery services. Instead we continue to evolve the safety measures to prevent harm and loss of life. As such, a key motivation for my joining Palo Alto Networks was to work for a company that is resolutely focused on innovating solutions to stop cyber incidents from occurring.
So what does the next evolution of preventing successful cyberattacks look like? We can learn a lot from technology’s own evolution. Historically, technology was built with a purpose in mind, but the implementation all too often failed, as it was built by engineers for engineers. Usability has become the key to success – if we cannot intuitively use the technology today, the likelihood is that it will fail.
Over decades we have built a broad spectrum of security components that each solve parts of the problem, some of which, I would challenge, are no longer fit for this purpose, while others still have significant value. However, the major challenge is drawing these pieces of the security puzzle together to detect and block the attack. This is a requirement, as most incidents today leverage multiple components in their lifecycle, and the challenge is being able to piece together the jigsaw puzzle to see the entire picture, when so much information is being generated by so many component parts. We have effectively evolved to something so unwieldy and complex that it is unusable. Fragmented solutions, creating so much noise that we become immobile, take too long and use too much processing power to give the complete view, causing the solution to become ineffective.
If we are to be as agile and dynamic as the adversaries we face in cyberspace, we must focus on usability and automation because our most scarce resource is undoubtedly people. Time and efficacy must be key metrics, as should the ability to recognise and gather multiple indicators of modern attacks across the diverse IT ecosystem. It is also necessary to dynamically correlate these against our own and our peers’ intelligence to quickly and accurately stop an incident before harm occurs.
As cars went faster, safety had to evolve. At no point did we give up and simply get more ambulances or insurance; life is too precious. In the same way, the cyber world is becoming increasingly dynamic and precious to society. We should not accept that breaches have to occur, but should strive instead to evolve our capabilities to ensure a safe online experience.
