Daily Log Monitoring and Increased Third Party Security Responsibilities: Here They Come!

For years now we at MSI have extoled the security benefits of daily log monitoring and reciprocal security practices between primary and third party entities present on computer networks. It is constantly being proven true that security incidents could be prevented, or at least quickly detected, if system logs were properly monitored and interpreted. It is also true that many serious information security incidents are the result of cyber criminals compromising third party service provider systems to gain indirect access to private networks. 

I think that most large-network CISOs are well aware of these facts. So why aren’t these common security practices right now? The problem is that implementing effective log monitoring and third party security practices is plagued with difficulties. In fact, implementation has proven to be so difficult that organizations would rather suffer the security consequences than put these security controls in place. After all, it is cheaper and easier – usually – unless you are one of the companies that get pwned! Right now, organizations are gambling that they won’t be among the unfortunate – like Target. A fools’ paradise at best! 

But there are higher concerns in play here than mere money and efficiency. What really is at stake is the privacy and security of all the system users – which one way or another means each and every one of us. None of us likes to know our private financial or medical or personal information has been exposed to public scrutiny or compromise, not to mention identity theft and ruined credit ratings. And what about utilities and manufacturing concerns? Failure to implement the best security measures among power concerns, for example, can easily lead to real disasters and even loss of human life. Which all means that it behooves us to implement controls like effective monitoring and vendor security management. There is no doubt about it. Sooner or later we are going to have to bite the bullet. 

Unfortunately, private concerns are not going to change without prodding. That is where private and governmental regulatory bodies are going to come into play. They are going to have to force us to implement better information security. And it looks like one of the first steps in this process is being taken by the PCI Security Standards Council. Topics for their special interest group projects in 2015 are going to be daily log monitoring and shared security responsibilities for third party service providers.

That means that all those organizations out there that foster the use of or process credit cards are going to see new requirements in these fields in the next couple of years. Undoubtedly similar requirements for increased security measures will be seen in the governmental levels as well. So why wait until the last minute? If you start now implementing not only effective monitoring and 3rd party security, but other “best practices” security measures, it will be much less painful and more cost effective for you. You will also be helping us all by coming up with new ways to practically and effectively detect security incidents through system monitoring. How about increasing the use of low noise anomaly detectors such as honey pots? What about concentrating more on monitoring information leaving the network than what comes in? How about breaking massive networks into smaller parts that are easier monitor and secure? What ideas can you come up with to explore?

This post written by John Davis.

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.

Here’s Why You Don’t Want RDP on the Internet

For those of you that are unfamiliar with the HITME project, it is a set of deployed HoneyPoints that gather real-world, real-time attacker data from around the world. The sensors gather attack sources, frequency, targeting information, vulnerability patterns, exploits, malware and other crucial event data for the technical team at MSI to analyze. We frequently feed these attack signatures into our vulnerability management service to ensure that our customers are tested against the most current forms of attacks being used on the Internet.

It’s also important that we take a step back and look at our HITME data from a bird’s-eye view to find common attack patterns. This allows us to give our customers a preemptive warning in the event that we identify a significant increase in a specific threat activity. We recently analyzed  some of the data that we collected during the month of November. We found that over 47% of the observed attacks in the public data set were against the Remote Desktop Protocol (RDP)(often also known as Microsoft Terminal Services). This was more than attacks against web servers, telnet servers and FTP servers combined!

Be sure that all recommended security measures are applied to RDP systems. This should include requiring the use of RDP clients that leverage high levels of encryption. If you need any assistance verifying that you are protected against attacks against your terminal servers, feel free to contact us by sending an email to info(at)microsolved(dot)com.

This post by Adam Luck.

Remember, Log Analysis is Important, Especially Now

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!

Client Calls HoneyPoint a “No Lose” Deployment

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. 

Best Practices for DNS Security

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. 

You can find it here.

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.

The Big Three Part 2: Incident Detection

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!

Monitoring: an Absolute Necessity (but a Dirty Word Nonetheless)

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:

  • Properly illustrate the necessity for human monitoring to management, business and IT personnel; make them understand the urgency of the need. Make a logical case for the function. Tell them real-world stories about other organizations that have failed to monitor and the consequences that they suffered as a result. If you can’t accomplish this step, the rest will never fall in line.
  • Ensure that personnel assigned to monitoring tasks of all kinds are properly trained in the function; make sure they know what to look for and how to deal with what they find.
  • Automate the logging and monitoring function as much as possible. The process is difficult enough without having to perform tedious tasks that a machine or application can easily do.
  • Ensure that you have log aggregation in place, and also ensure that other network security tool output is centralized and combined with logging data. Real world cyber-attacks are often very hard to spot. Correlating events from different tools and processes can make these attacks much more apparent. 
  • Ensure that all personnel associated with information security communicate with each other. It’s difficult to effectively detect and stop attacks if the right hand doesn’t know what the left hand is doing.
  • Ensure that logging is turned on for everything on the network that is capable of it. Attacks often start on client side machines.
  • Don’t just monitor technical outputs from machines and programs, monitor access rights and the overall security program as well:
  • Monitor access accounts of all kinds on a regular basis (at least every 90 days is recommended). Ensure that user accounts are current and that users are only allocated access rights on the system that they need to perform their jobs. Ensure that you monitor third party access to the system to this same level.
  • Pay special attention to administrative level accounts. Restrict administrative access to as few personnel as possible. Configure the system to notify proper security and IT personnel when a new administrative account is added to the network. This could be a sign that a hack is in progress.
  • Regularly monitor policies and procedures to ensure that they are effective and meet the security goals of the organization. This should be a regular part of business continuity testing and review.
Thanks to John Davis for writing this post.

HoneyPoint IP Protection Methodology

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.

HP_IPProtection

Using HoneyPoint to Inventory Windows Boxes on a Segment

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…)