Remember, during the holiday season, attacks tend to increase and so do compromises. With vacations and staff parties, monitoring the logs and investigating anomalies can quickly get forgotten. Please make sure you remain vigilant during this time and pay close attention to logs during and just after holiday breaks.
As always, thanks for reading and we wish you a safe and happy holiday season!
One of the clients we were working with recently wanted me to share their thoughts on deploying HoneyPoint Security Server with the blog audience.
His company recently installed the HoneyPoint Security Server suite into their network. Their management teams were a little nervous, at first, that offering a honeypot to attackers might attract bad people to their networks. But, when the security team explained that these were going to be simply deployed on the INTERNAL networks and not visible from the Internet, so someone would already have to be inside the network to see them, they gained approval. The security team explained that they planned to use HoneyPoint as a supplement to their existing perimeter network IDS, and their log monitoring tools.
The security team convinced their immediate manager of the HoneyPoint product by describing it as a “No Lose” product to deploy. If they dropped in the HoneyPoint Agents and captured bad actors or malware moving in the network, they would win by identifying existing compromises. If they dropped in HoneyPoint and never got a hit at all, they would win, and could tell the management that even upon closer examination with the new detection tools, the network seemed to be clean of malware and overt attacker activity. This, in combination with the other forms of detection and reporting they were doing would further strengthen their position with management that the security team was remaining vigilant.
In the end, the team observed a few pieces of malware within the first 90 days and quickly eliminated the infections. They then began to plan on deploying HoneyPoint Agent into a malware black hole, in coordination with their internal DNS team. As of this writing, the deployment in the new position should go live within 30 days. In most cases, teams using HoneyPoint in this fashion quickly identify other more deeply hidden malware. The security team looks forward to leveraging the data from the HoneyPoint black hole to clean the environment more aggressively.
So, there you have it. Another client strikes a win with HoneyPoint. You can learn more about this “No Lose” product by getting in touch with your MSI account executive. You can also find more information by clicking here.
I wanted to share with you a great FREE resource that I found on the Cisco web site that details a great deal of information about DNS and the best practices around securing it. While, obviously, the content is heavy on Cisco products and commands, the general information, overview and many of the ideas contained in the article are very useful for network and security admins getting used to the basics of DNS.
Additionally, there are great resources listed, including several free/open source tools that can be used to manage and monitor DNS servers.
If you are interested in learning more about DNS or need a quick refresher, check this article out.
Several other resources are available around the web, but this seems to be one of the best summaries I have seen. As always, thanks for reading and let me know on Twitter (@lbhuston) if you have other favorite resources that you would like to share.
Did you know that less than one out of five security incidents are detected by the organization being affected? Most organizations only find out they’ve experienced an information security incident when law enforcement comes knocking on their door, if they find out about it at all, that is. And what is more, security compromises often go undetected for months and months before they are finally discovered. This gives attackers plenty of time to get the most profit possible out of your stolen information, not to mention increasing their opportunities for further compromising your systems and the third party systems they are connected to.
Of the Big Three strategies for fighting modern cyber-crime, (incident detection, incident response and user education and awareness), incident detection is by far the hardest one to do well. This is because information security incident detection is not a simple process. No one software package or technique, no matter how expensive and sophisticated, is going to detect all security events (or even most of them to be completely honest). To be just adequate to the task, incident detection requires a lot of input from a lot of systems, it requires knowledge of what’s supposed to be on your network and how it works, it requires different types of security incident detection software packages working together harmoniously and, most importantly, it requires human attention and analysis.
First of all, you need complete sources of information. Even though it can seem to be overwhelming, it behooves us to turn on logging for everything on the network that is capable of it. Many organizations don’t log at the workstation level for example. And you can see their point; most of the action happens at the server and database level. But the unfortunate reality is that serious security compromises very often begin with simple hacks of user machines and applications.
Next, you need to be aware of all the software, firmware and hardware that are on your network at any given time. It is very difficult to monitor and detect security incidents against network resources that you aren’t even aware exist. In fact, I’ll go a step further and state that you can improve your chances of detection significantly by removing as much network clutter as possible. Only allow the devices, applications and services that are absolutely necessary for business purposes to exist on your network. The less “stuff” you have, the fewer the attack surfaces cyber-criminals have to work with and the easier it is to detect security anomalies.
The third thing that helps make information security incident detection more manageable is tuning and synchronizing the security software applications and hardware in your environment. We often see organizations that have a number of security tools in place on their networks, but we seldom see one in which all of the output and capabilities of these tools have been explored and made to work together. It is an unfortunate fact that organizations generally buy tools or subscribe to services to address particular problems that have been brought to their attention by auditors or regulators. But then the situation changes and those tools languish on the network without anyone paying much attention to them or exploring their full capabilities. Which brings to the most important factor in security incident detection: human attention and analysis.
No tool or set of tools can equal the organizational skills and anomaly detection capabilities of the human brain. That is why it is so important to have humans involved with and truly interested in information security matters. It takes human involvement to ensure that the security tools that are available are adequate to the task and are configured correctly. It takes human involvement to monitor and interpret the various outputs of those tools. And it takes human involvement to coordinate information security efforts among the other personnel employed by the organization. So if it comes down to spending money on the latest security package or on a trained infosec professional, I suggest hiring the human every time!
—Thanks to John Davis for this post!
There is no easier way to shut down the interest of a network security or IT administrator than to say the word “monitoring”. You can just mention the word and their faces fall as if a rancid odor had suddenly entered the room! And I can’t say that I blame them. Most organizations do not recognize the true necessity of monitoring, and so do not provide proper budgeting and staffing for the function. As a result, already fully tasked (and often times inadequately prepared) IT or security personnel are tasked with the job. This not only leads to resentment, but also virtually guarantees that the job is will not be performed effectively.
And when I say human monitoring is necessary if you want to achieve any type of real information security, I mean it is NECESSARY! You can have network security appliances, third party firewall monitoring, anti-virus packages, email security software, and a host of other network security mechanisms in place and it will all be for naught if real (and properly trained) human beings are not monitoring the output. Why waste all the time, money and effort you have put into your information security program by not going that last step? It’s like building a high and impenetrable wall around a fortress but leaving the last ten percent of it unbuilt because it was just too much trouble! Here are a few tips for effective security monitoring:
Here’s another use case scenario for HoneyPoint Security Server. This time, we show the methodology we use to scope a HoneyPoint implementation around protecting a specific set of Intellectual Property (IP).
If you would like an in-depth discussion of our process or our capability, please feel free to reach out to us and schedule a call with our team. No commitment and no hard sale, guaranteed.
If the graphic below is blurry on your device, you can download a PDF version here.
For quite some time now, we have been using HoneyPoint Agent and Console to do some passive inventory and mapping exercises for clients, particularly those involved in ICS and SCADA deployments where active scanning to get inventories is often strongly discouraged. We had particular success with a specific client in this space a couple of weeks ago, and I wanted to discuss it here, since it has proven itself to be a useful tool and is on the top of my mind at the moment.
To get an inventory of the Windows systems on a collision domain, you simply install the Agent on a Linux box (or I suggest using the virtual appliance we already have built for your ease) and implement it and the Console. Once HoneyPoint is operational, you configure a UDP listener on port 138. From there, all of the NETBios speaking Windows systems will begin to send traffic to the host, as per the usual behavior of those systems. In this case, however, HoneyPoint will capture each source IP and log it to the Console. It will also capture the UDP datagrams from that conversation and place them as event data in the logs. By reviewing the source IPs, you can quickly and easily take stock of the Windows systems on the collision domain without sending any traffic at all to the systems. As a bonus, if you dig into the datagram data, you will also see the names of the hosts and other information.
Most of the time, this technique captures only Windows boxes, but if you have other devices out there running NETBios, they will likely get detected as well. This can include embedded systems, Unix systems running SAMBA, printers and copiers, Windows CE systems (often seen in many field equipment deployments), etc. You might be surprised what you can find.
Try this with a laptop, and move the laptop around your environment. You can pretty quickly and easily get an inventory by collision domain. You can also try dialing other NETBios ports and see if you get traffic that is routed across your switching fabric. Depending on your configuration, you might be able to gather a great deal of inventory data from a single location (especially if your network is flat and switches are poorly configured).
Give this a shot or get in touch if you would like us to come onsite and perform the inventory for you. We think it is a pretty useful technique and one that many folks are enjoying the benefits of. Let us know what you think when you give it a run in your network!
As always, thanks for reading, and until next time, stay safe out there!
PS – You can also do this with HoneyPoint Personal Edition on a Linux system, which makes it very easy and cheap to do if you don’t want to invest in a full blown HoneyPoint Security Server implementation. (You should invest though, it is a FANTASTIC detection tool!)
**(The link above is for HPPE on Windows, but if you purchase a license and contact us, we will send you the Linux build right away. You can’t easily capture port 138/UDP traffic in Windows HPPE because Windows has those ports in use…)
Don’t forget, Brent will be presenting on the SANS webinar today to discuss ICS/SCADA honeypots. Check it out and register here.
See you online and we hope you enjoy the event!
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.
This time around, we got a question from a client where HoneyPoint was being demoed for the experts.
Q: “What is your favorite component of HoneyPoint and why? How have you used it to catch the bad guys?”
Jim Klun started off with:
My favorite component is the simplest: HoneyPoint Agent.
It’s ease of deployment and the simple fact that all alerts from an agent are of note – someone really did touch an internal service on a box where no such service legitimately exists – makes it attractive.
No one will argue with you about meaning.
I have recently seen it detect a new MSSQL worm (TCP 1433) within a large enterprise – information obtained from my own laptop. The Agent I had deployed on the laptop had a 1433 listener. It captured the payload from an attacking desktop box located in an office in another US state.
The HoneyPoint Agent info was relayed to a corporate team that managed a global IPS. They confirmed the event and immediately updated their IPS that was – ideally – protecting several hundred thousand internal machines from attack.
Honeypoint Agent: It’s simple, it works.
Adam Hostetler added his view:
I’m a simple, no frills guy, so I just like the regular old TCP listener component built into Agent. We have stood these up on many engagements and onsite visits and picked up unexpected traffic. Sometimes malware, sometimes a misconfiguration, or sometimes something innocuous (inventory management). I also find it useful for research by exposing it to the Internet.
John Davis closed with a different view:
My favorite HoneyPoint is Wasp. Watching how skilled attackers actually compromise whole networks by initially compromising one user machine gives me the shivers! Especially since most networks we see aren’t properly enclaved and monitored. If I were a CISO, knowing what is on my network at all times would be of primary importance; including what is going on on the client side! Wasp gets you that visibility and without all the traditional overhead and complexity of other end-point monitoring and white listing tools.
Have a question about HoneyPoint? Want to talk about your favorite component or use case scenario? Hit us on Twitter (@lbhuston or @microsolved). We can’t wait to hear from you. Feel free to send us your question for the experts. Readers whose questions we pick for the blog get a little surprise for their contribution. As always, thanks for reading and stay safe out there!