HoneyPoint Security Server Allows Easy, Scalable Deception & Detection

Want to easily build out a scalable, customizable, easily managed, distributed honey pot sensor array? You can do it in less than a couple of hours with our HoneyPoint Security Server platform.

This enterprise ready, mature & dependable solution has been in use around the world since 2006. For more than a decade, customers have been leveraging it to deceive, detect and respond to attackers in and around their networks. With “fake” implementations at the system, application, user and document levels, it is one the most capable tool sets on the market. Running across multiple operating systems (Linux/Windows/OS X), and scattered throughout network and cloud environments, it provides incredible visibility not available anywhere else.

The centralized Console is designed for safe, effective, efficient and easy management of the data provided by the sensors. The Console also features simple integration with ticketing systems, SEIM and other data analytics/management tools.

If you’d like to take it for a spin in our cloud environment, or check out our localized, basic Personal Edition, give us a call, or drop us a line via info (at) microsolved (dot) com. Thanks for reading! 

My Time as a HoneyPoint Client

Prior to joining MicroSolved as an Intelligence Engineer, I was the Information Security Officer and Infrastructure Manager for a medical management company.  My company provided medical care and disease management services to over 2 million individuals.  Throughout my tenure at the medical management organization, I kept a piece of paper on my bulletin board that said “$100,000,000”.

 

Why “$100,000,000”?  At the time, several studies demonstrated that the average “street value” of a stolen medical identity was $50.  If each record was worth $50, that meant I was responsible for protecting $100,000,000 worth of information from attackers.  Clearly, this wasn’t a task I could accomplish alone.

 

Enter: MicroSolved & HoneyPoint

 

Through my membership with the Central Ohio Information Systems Security Association, I met several members of the MicroSolved team.  I engaged them to see if they could help me protect my organization from the aforementioned attackers.  They guided me through HIPPA/HITECH laws and helped me gain a further understanding of how I could protect our customers.  We worked together to come up with innovative solutions that helped my team mitigate a lot of the risks associated with handling/processing 2 million health care records.

 

A core part of our solution was to leverage the use of HoneyPoint Security Server.  By using HoneyPoint, I was able to quickly gain visibility into areas of our network that I was often logically and physically separated from.  I couldn’t possibly defend our company against every 0-day attack.  However, with HoneyPoint, I knew I could quickly identify any attackers that had penetrated our network.

 

Working for a SMB, I wore many hats.  This meant that I didn’t have time to manage another appliance that required signature updates.  I quickly found out that HoneyPoint didn’t require much upkeep at all.  A majority of my administrative tasks surrounding HoneyPoint were completed when I deployed agents throughout our LAN segments that mimicked existing applications and services.  I quickly gained the real-time threat analysis that I was looking for.

 

If you need any assistance securing your environment or if you have any questions about HoneyPoint Security Server, feel free to contact us by sending an email to: info@microsolved.com.

 

This post contributed by Adam Luck.

Brent Huston to Lead ICS/SCADA Honeypot Webinar with SANS

Our Founder and CEO, Brent Huston (@lbhuston) will be leading a SANS webinar on ICS/SCADA honeypots. The webinar is scheduled for November, 25th, 2013 and you can find more information and register by visiting this page.

The webinar will cover when honeypots are and are not useful, basic deployment strategies and insights into using them for detection in field deployments and control environments. 

Check it out, tune in and give Brent a shout out on Twitter. Thanks for reading and we hope you enjoy the webinar.

HoneyPoint Security Server ICS/SCADA Deployment Example

Recently, there have been several questions about potential deployment scenarios for HoneyPoint Security Server in and around ICS and SCADA organizations. Here is a quick, high level view of what a sample deployment might look like in a utility or other ICS environment. Note that the sample environment has fully embraced enclaveing. The network is fully segmented based on function.

In organizations where segmentation or the use of enclaves has not been established, HPSS can still be used and would be deployed in much the same manner.

Please let us know if you have any questions about this diagram or about deploying HPSS in your environment. We would be happy to set up a free consultation with you to discuss how the tool could aid in your detection program and give you increased visibility throughout your enterprise.

PS – If the graphic is difficult to read, right click on it and select view in new tab. The theme for the site is having trouble with this particular graphic.

HighLevelEnclaves

What is HPSS? :: HoneyPoint Agent

This post builds on the What is HPSS? Series. Previous posts are here and here


HoneyPoint Agent is the original detection capability of the HoneyPoint Security Server suite. Basically, it allows a system to offer up a variety of “fake services” to the network for the purpose of detection. These services can either be simple port listeners or can be complex, deeper emulations of protocols like SMTP, HTTP, Telnet, FTP, etc. These ports have no real users and no legitimate traffic flows to them. This means that anytime these ports are tampered with, the interactions are “suspicious at best and malicious at worst”. 


HPAgentOverview

Because the Agent is designed to be extremely light weight in terms of computing power needed, the Agents can be sprinkled throughout the network environment easily. Many organizations simply add Agent into default server and workstation builds, turning most of the systems in their network into sensors for detection. 

 

Other organizations deploy Agent more sporadically, either using virtual or physical appliances dedicated to HoneyPoint hosting. These organizations often assign multiple physical or virtual interfaces to the devices, allowing them to have a presence on many network segments at the same time.

 

Still other users leverage an approach called “scattersensing” by deploying HoneyPoint on systems that they move periodically around their environment. This makes for a less dependable detection mechanism, but gives them the capability to get more vision into “hotspots” where targeting is expected or where malware is more likely to pop-up. 

 

The most successful HoneyPoint Agent deployments use a combination of these tactics, along with including strategies like DNS redirection of known command and control sites and other more active forms of getting bad traffic into the HoneyPoint systems.

 

HoneyPoint Agent has proven to be very useful in identifying scanning and malware outbreaks. Customers with supposedly secure networks have found malware that had been missed for years by their traditional internal security tools. These were detected when the ongoing slow and low scanning triggered HoneyPoint deployments, particularly for SQL, Terminal Server and other commonly targeted ports.

 

HoneyPoint Agent can be configured through the command line or via a GUI application, making it easy to manage and deploy. Once installed, it is a “deploy and forget” style tool which doesn’t require ongoing tuning or signature updates. Generally speaking, customers deploy Agent and it runs for years without feeding and care.

 

HoneyPoint Agent also features MSI’s patented “defensive fuzzing” capabilities (previously known as HornetPoint mode), which can create self-defending services that attempt to take down attacker tools during their probing to interfere with propagation. Still other users automate defense with Agent using it as a means for black holing hosts that probe their environment. In these optional, more active roles, Agent can help organizations strengthen their posture with a “one strike and you’re out” kind of approach. 

 

HoneyPoint Agent runs in Linux, Windows and OS X. It communicates securely with the HoneyPoint Console. It also features user configurable services, a known scanning host ignore list (for ongoing vulnerability assessment clients) and a wide variety of common service emulation templates (available through support). 

 

To learn more about HoneyPoint Security Server or to get a demo, please contact us. We would be happy to walk you through the product and discuss how it might fit into your environment. There is even a free for personal use “Community Edition” available to get you started or to let you experience the power, ease and flexibility of the platform yourself. Just give us a call to learn more about HoneyPoint Security Server and HoneyPoint Agent. You’ll be glad you did! 


What is HPSS? :: The Console

This article builds on the What is HPSS? Series. The original overview article is here

The HoneyPoint Security Server Console is the “brain” of the HoneyPoint product platform. It is the central component responsible for getting alert data from the sensors, tracking and maintaining the alert data, presenting it to the user and safely passing the essential alert data on to the automated plugins or other systems in the security event chain.


HoneyPointConsoleRole

The Console is a GUI application that includes a built-in database engine for tracking Alert Data state and to empower reporting and analysis over time. Alert Data from the sensors are sent to the Console over TCP and the data is encrypted. The Console application runs on Windows, Linux and OS X. 

 

Once the Console receives Alert Data from the sensors, it parses it to validate that the data is good and checks to see what actions it should take based on the alerting configuration, assigned admins list, ignored hosts lists, and other trust rules in place. 

It then presents the alert data to the appropriate mechanisms, alerting users, passing the desired elements of the alert data to syslog/event log on the Console system for upstream processing by SEIMs or other event tools. The Console also passes certain event data as determined by the configuration into the “plugins mechanism”. 

 

The plugins then execute the desired operations on the data, easily allowing the security team to further extend reporting to custom event handlers or perform automated responses. This flexible solution empowers the security team to integrate HoneyPoint Security Server fully into whatever technology platform/response process they desire or have in place.

 

Reporting from the Console is very simple. The included reporting engine can create a wide variety of canned reports in either CSV or HTML format, ensuing that the data in the HoneyPoint system is easy to use. Additionally, other reporting tools like Crystal Reports or the like, or even languages like PERL, Python or Ruby, can easily attach to the Console database to create whatever types of custom reports you desire.

 

All in all, HoneyPoint Security Server was designed to make it easy to use and yet flexible enough for the most demanding and mature infosec teams. The console interface is friendly, functional and easily understandable. Most teams require less than a 30 minute walk through before they are off and running with the basic detection power HoneyPoint provides. When they get comfortable with the system, they quickly master the plugins meta-language and are soon automating large groups of detection and response tasks.

 

To learn more about HoneyPoint Security Server or to get a demo, please contact us. We would be happy to walk you through the product and discuss how it might fit into your environment. There is even a free for personal use “Community Edition” available to get you started or to let you experience the power, ease and flexibility of the platform yourself. Just give us a call to learn more about HoneyPoint Security Server Console. You’ll be glad you did! 


What is this HoneyPoint Thing Anyway?

Launched in 2006, initially as a distributed honey pot product, HoneyPoint Security Server (HPSS) has grown well beyond the initial concept. Today HPSS is a platform of components woven into a tightly integrated, fully capable, extremely flexible threat detection product. Organizations around the world are using it as a means of early detection of internal and external attackers, malware outbreaks and signs of users poking around where they shouldn’t be. Mature organizations have leveraged the product as a means of deterring attacks through automated black holing of scanning hosts on their perimeter, embedded detective controls inside their web applications to cut off users violating their terms of service and gather real world threat metrics to feed back into their mature risk management initiatives.

 

In the world of ICS/SCADA, HoneyPoint has found a quickly growing set of fans. HPSS can be deployed in a completely passive way that has no chance of interfering with critical operations, yet still brings incredible detection capability and vision into even the most sensitive of networks. ICS/SCADA environments have traditionally embraced the honeypot ideal, coining the term “canary” for these tools, but never before have they had such an easy to use, distributable, centrally monitored honeypot capability like HoneyPoint brings to the table.

 

Over the next few months, we will be deep diving into each of the HPSS components, but for now, as a high-level overview, here is a quick and dirty explanation of each of them:

 

  • HPSS Console – This is the central “brain” of the product. Designed as an easy to use GUI application, it receives the alerts detected by the sensor components and presents them to the user for analysis. It includes the “plugin” capability which allows for additional reporting and security automation based on the event data detected. The Console provides for “point and click” easy integration with SEIM products for clients who have deeper back-end data aggregation systems in place.
  • HoneyPoint Agent – This is the original HoneyPoint detection capability. Agent creates “fake services” on the network that have no real use other than detection. Since the services aren’t real, any interaction with them is “suspicious at best and malicious at worst”. Agent is capable of emulating a great variety of services and is completely user configurable. Agent runs on Windows, Linux and OS X. 
  • Wasp – Wasp is HoneyPoint’s hybrid client for Windows systems. It offers many of the port dilation features of Agent, but layers on top of that a whitelisting detection mechanism, file change detection for key files and some simple heuristics to identify the most common signs of intrusion. Tiny footprint, immense flexibility, self tuning whitelisting and no interference with operations make it an excellent choice for critical infrastructure use.
  • HoneyPoint Web – This is a completely emulated web environment with a mock up of applications that the organization uses. The entire environment is “fake” and studded with detection mechanisms that capture and measure attacker behavior, intent and capability. It might seem to be a new version of a banking application “accidentally” exposed to the Internet, or a replica of an HMI or maybe a login portal for Sharepoint/VPN or some other mechanism. What it really is is a detection mechanism for the good guys. Completely customized, able to detect the difference between a human attacker and most malware, it offers organizations a deeper, sneakier way to detect illicit behavior and measure the attacker attention various attack surfaces receive.
  • HoneyElements – Embeddable HTML and Javascript objects that can be added to new or existing real web applications, these HoneyPoints extend detection into the layers of the application itself. Integrates well with automated response and attacker black holing defenses to stop attackers and those engaging in undesired behaviors in real time.
  • HoneyBees – These work with Agent to simulate users authenticating to emulated services with plain text credentials. Organizations use this combination of tools to detect sniffing attacks and other attempts to harvest credentials off the wire or from network monitoring systems. 
  • HoneyPoint Trojans – Trojans are “fake” documents, applications or archives that appear to be real, but are actually detection mechanisms. For example, they might appear to be a PDF of some acquisition plans, while in reality they are armed with code to alert the security team when they have been opened or tampered with. Trojans use many of the same tactics as attackers, but instead of infection as a goal, they provide for detection and alerting.
  • HoneyPoint Handler – The Handler is a mechanism for getting external events into the HoneyPoint data ecosystem. Organizations often use the handler to receive events generated by custom nuance detection scripts. For example, a script might routinely check for new files in a directory or new files that contain the call base64decode(). When the script identifies a new file, the script can send an alert to the Handler, which will create a standard HoneyPoint alert from the script’s data and send it to the Console for easy and standardized security event management.
  • HoneyPoint Decoy Appliances – This is a set of hardened Linux powered devices that serve as an appliance for other components, usually Agent and Web. The appliances are available in three physical form factors (a rack mountable server, a mini-desktop, and a field deployable power substation solid state system) and/or a set of virtual appliances for most common virtualization platforms.
  • HoneyPoint Proxy – Lastly, this component is designed to act as an alerting data aggregator to simplify firewall ACLs that might be deployed between DMZ segments, enclaves or other network segments. The proxy can receive events from HoneyPoints and send them on to the Console without the need to expose the Console to each individual HoneyPoint. This makes managing global and highly distributed deployments significantly easier.

 

To learn more about these components and how they can be leveraged to give your organization new, flexible and deep detection capabilities, give us a call. Our engineers would be glad to discuss the technical capabilities and an account executive would be happy to work with you to create a HoneyPoint deployment that meets your needs AND your budget. At MicroSolved, we are passionate about information security and HoneyPoint Security Server is just another that way it shows!

How Honeypots Can Help Safeguard Your Information Systems

 

 

 

 

 

 

 

A honeypot is a trap set to detect or deflect attempts at unauthorized use of information systems. Generally it consists of a computer, data or a network site that appears to be part of a network but which is actually isolated and protected, and which seems to contain information that would be of value to attackers.

It is important to note that honeypots are not a solution in themselves. They are a tool. How much they can help you depends upon what you are trying to achieve.

There are two different types of honeypots: production and research. Production honeypots are typically used by companies and corporations. They’re easy to use and capture only limited information.

Research honeypots are more complex. They capture extensive information, and used primarily by research, military, or government organizations.

The purpose of a production honeypot is to mitigate risk to an organization. It’s part of the larger security strategy to detect threats. The purpose of a research honeypot is to collect data on the blackhat community. They are used to gather the general threats against an organization, enabling the organization to strategize their response and protect their data.

The value of honeypots lies in their simplicity. It’s technology that is intended to be compromised. There is little or no production traffic going to or from the device. This means that any time a connection is sent to the honeypot, it is most likely to be a probe, scan, or even attack. Any time a connection is initiated from the honeypot, this most likely means the honeypot was compromised. As we say about our HoneyPoint Security Server, any traffic going to or from the honeypot is, by definition, suspicious at best, malicious at worst. Now, this is not always the case. Mistakes do happen, such as an incorrect DNS entry or someone from accounting inputting the wrong IP address. But in general, most honeypot traffic represents unauthorized activity. What are the advantages to using honeypots?

  1. Honeypots collect very little data. What they do collect is normally of high value. This eliminates the noise, making it much easier to collect and archive data. One of the greatest problems in security is sifting through gigabytes of useless data to find something meaningful. Honeypots can give users the exact information they need in a quick and easy to understand format.
     
  2. Many security tools can drown in bandwidth usage or activity. NIDs (Network Intrusion Detection devices) may not be able to handle network activity, and important data can fall through the cracks. Centralized log servers may not be able to collect all the system logs, potentially dropping logs. The beauty of honeypots is that they only capture that which comes to them.

Many of our clients swear by our HoneyPoint family of products to help save resources. With its advantages, it’s easy to see why! Leveraging the power of honeypots is an excellent way to safeguard your data.

 

How HoneyPoint Security Server Minimizes Risk For Your Network

If you’re looking for a security tool that goes beyond NIDS, you’re in luck.

MicroSolved’s HoneyPoint Security Server has revolutionized the ease and power of what honeypots can do and be. With the emergence of HoneyPoint Wasp, you can also apply the HoneyPoint magic to your Windows desktops. 

HoneyPoint Wasp monitors your desktops for any new applications it has not seen before (Anomaly Detection). Should Wasp detect new code, the end-user will never see a pop-up alert. Instead, you will be notified and able to quickly take action. Should the notification go without follow-up action, HoneyPoint Wasp assumes the allowed application, and no future notification will be sent to the console (Self-Tuning White Listing).

As you’ll see in a moment, the HoneyPoint Security Server is much more than a mere intrusion detection system.. It’s an underlying framework of rock-solid code that’s been built to achieve three important goals: identify real threats, isolate and tamper with the attacker’s results, and “smart” detection processes that allow you to target attacker availability.

Let’s take a look at each of these goals, and why they matter to what you’re doing online…

Click to continue…

InfoSec Insights: Getting Indexed Via Twitter – Good & Bad

Earlier this week, I did a quick experiment in the MSI Threat Lab. I wanted to see what happened when someone mentioned a URL on Twitter. I took a HoneyPoint Agent and stood it up exposed it to the Internet on port 80.

I then mapped the HoneyPoint to a URL using a dynamic IP service and tweeted the URL via a test account.

Interestingly, for the good, within about 30 seconds, the HoneyPoint had been touched by 9 different source IP addresses. The search engines, it seems, quickly picked the URL out of the stream, did some basic traffic and I assume queued the site for crawling and indexing in the near future. A few actually indexed the sites immediately. The HoneyPoint cataloged touches from 4 different Amazon hosts, Yahoo, Twitter itself, Google, PSINet/Cogent and NTT America. It took less than an hour for the site to be searchable in many of the engines. It seems that this might be an easier approach to getting a site indexed then the old visit each engine and register approach, or even using a basic register tool. Simply tweet the URL and get the ball rolling for the major engines. 🙂

On the bummer side, it only took about 10 minutes for the HoneyPoint to be probed by attacker scanning tools. We can’t tie cause to the tweeting, but it did target that specific URL and did not touch other HoneyPoints deployed in the range which certainly seems correlative. Clearly, search engines aren’t the only types of automated applications watching the Twitter stream. My guess is that scanning engines watch it too, to some extent, and queue up hosts in a similar manner. Just like all things, there are good and bad nuances to the tweet to get indexed approach.

Further research is needed in what happens when a URL is tweeted, but I thought this was an interesting enough topic to share. Perhaps you’ll find it useful, or perhaps it will explain where some of that index traffic (and scanner probes) come from. As always, your mileage and paranoia may vary. Thanks for reading!