Audio Blog: Brent Huston – HoneyPoint Security Server Manifesto Part Two

We continue our interview with Brent Huston as he answers a few questions about HoneyPoint Security Server, and HoneyPoint Agents.

In this installment, you’ll learn:

  • What HoneyPoint Agent is and its role in the suite
  • How information techs are using HoneyPoint
  • How can people use Agent with DNS and blacklisting, and why it’s significant
  • What HoneyPoint Decoy is and how it is utilized in an environment
  • The three different “flavors” of HoneyPoint Decoy

Click the link to listen or right-click to download it.

Security Alert: RSA Breach and 7 Ways to Secure Your Tokens

Since the compromise of the RSA environment several months ago, much attention has been paid to the potential impact of the attack on RSA customers.

Given the popularity of the RSA products and the sensitivity of the processes that they protect, the situation should be taken very seriously by RSA token users.

Last night, RSA made a public announcement that their breach and information stolen in that breach has now been used in attacks against RSA customers. The primary focus, as far as is known, has been the defense sector, but it is very likely that additional threat-focus has been placed on other critically sensitive verticals such as financial and critical infrastructure.

There are a number of things that RSA customers should do, in the advice of MicroSolved, Inc. Below is a short list of identified strategies and tactics:

  1. Identify all surfaces exposed that include RSA components. Ensure your security team has a complete map of where and how the RSA authentication systems are in use in your organization.
  2. Establish a plan for how you will replace your tokens and how you will evaluate and handle the risks of exposure while you perform replacement.
  3. Increase your vigilance and monitoring of RSA exposed surfaces. This should include additional log, event and intrusion monitoring around the exposed surfaces. You might also consider the deployment of honeypots or other drop-in measures to detect illicit activity against or via compromised systems available with the RSA exposed surfaces.
  4. Develop an incident response plan to handle any incidents that arise around this issue.
  5. Increase the PIN length of your deployments as suggested by RSA, where appropriate, based on identified risk and threat metrics.
  6. Teach your IT team and users about the threats and the issue. Prepare your team to handle questions from users, customers and other folks as this issue gains media attention and grows in visibility. Prepare your technical management team to answer questions from executives and Board-level staff around this issue.
  7. Get in contact with RSA, either via your account executive or via the following phone number for EMC (RSA’s parent company): 1-800-782-4362

In the meantime, if MSI can assist you with any of these steps or work with you to review your plan, please let us know. Our engineers are aware of the issues and the processes customers are using to manage this problem in a variety of verticals. We can help you with planning or additional detection and monitoring techniques should you desire.

We wish our clients the highest amount of safety and security as we, as an industry, work through this challenge. We wish RSA the best of luck and the highest success in their remediation and mitigation efforts. As always, we hope for the best outcome for everyone involved.

Thanks for your time and attention to this issue. It is much appreciated, as is your relationship with MicroSolved, Inc.

Horrible Ideas, Modeled & Profiled

Just a quick note this time about the HITME (HoneyPoint Internet Threat Monitoring Environment). One of the best uses for having the kind of global honeynet that we have deployed in the incarnation of the software is that you can create actual working models for a mistake or a horrible security idea.

Want to know what happens if you accidentally expose an internal system to the public Internet for 24 hours? We can quickly (in less than 30 mins) build an emulation for it and use a decoy dropped into place on your network to measure and model that risk over a period of time. You can get a real life set of metrics for how many probes it receives, from where and for what the attackers are looking. You can find out how long the average time is before the issue is identified by an attacker. You can even work up a profile of what sources, their locale and their capability to add to your risk assessments. These kinds of metrics, tied to a strong mathematical model (like FAIR) make for fantastic real world analysis.

You can do the same with web applications. Want to know what kind of attacks you can expect if you put in a new VPN portal at your managed hosting provider? No problem. We create an emulation and drop a decoy into their ESX(i) infrastrcuture, monitor it for 30 days and work up the data into a report for you. Now you can take that data and feed into a risk assessment, work out compensating controls and even get a budget idea for what it will take to secure such an infrastructure. We can also do this in multiple places and then work with the reporting you get from several vendors, using this mock up as a bake off data point to help you determine if your exposures and risks are higher from one hosting provider to another, what kinds of reporting you get from each, how effective their prevention and detection programs are, etc. We’ve even had a couple of organizations drop in temporary HoneyPoint decoys while being audited or undergoing penetration testing to get a third party view of how effective and capable their assessment and testing process has been.

The coolest thing to me about HoneyPoint is not the bleeding-edge attacks you can capture, nor the insights into attacker behavior it brings. Instead it’s the wide array of business problems that it can lend real world insight to inside the security world. It truly makes it easy to model and measure some of the most horrible ideas that an admin or developer can have. Wanna know more about the mistakes you make or might make in the future? Wanna measure attack interactions or generate metrics to feed a better risk assessment? Give us a call, we’ll be glad to discuss how you can take the next step in threat-centric information security with HoneyPoint!

From the Tweetstream: What HITME Caught: Ongoing Defacement Campaign

Recently, we noticed our @HoneyPoint account, (HoneyPoint Internet Threat Monitoring Environment or HITME) was getting pinged. What we found is explained below:

 

[blackbirdpie url=”http://twitter.com/#!/lbhuston/status/67954775886544896″]

[blackbirdpie url=”http://twitter.com/#!/lbhuston/status/67955056300920832″]

[blackbirdpie url=”http://twitter.com/#!/lbhuston/status/67955546187243520″]

[blackbirdpie url=”http://twitter.com/#!/lbhuston/status/67973785218859008″]

[blackbirdpie url=”http://twitter.com/#!/lbhuston/status/67974149250879489″]

[blackbirdpie url=”http://twitter.com/#!/lbhuston/status/67984136337498113″]

[blackbirdpie url=”http://twitter.com/#!/lbhuston/status/67985250583715840″]

[blackbirdpie url=”http://twitter.com/#!/lbhuston/status/67985707125325824″]

[blackbirdpie url=”http://twitter.com/#!/lbhuston/status/67990169353068544″]

 

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!

Jumphosts Are a Great Place For HoneyPoint Wasp

As the idea of network segmentation, or enclaving, becomes more and more popular, many organizations are also implementing so called “jumphosts” for their critical systems. Typically, a jumphost is a terminal server or Citrix host that users and admins connect to, then ride a terminal server or Citrix connection into the segmented critical hosts. This connection is usually filtered by a firewall, screening router or other access control method which segments the critical hosts from other parts of the infrastructure. Given the critical role these jumphosts play in the operations, it is essential that they be highly protected and monitored.

This is where HoneyPoint Wasp comes in. One of the strongest use cases for Wasp in the field has been to help protect these critical jumphosts from compromise and give the security team deeper visibility into their operation. Wasp lends itself well to this task, especially given the static nature of the systems, by extending normal anti-virus to include deeper, more accurate behavior-based anomaly detection. For example, Wasp maintains a white-list of known applications on the jumphost. If a user or attacker starts a new process that Wasp has never seen before, an alert is generated for the security team to investigate.

This white-listing approach is not reliant on signatures or heuristics to determine if a process is malware or the like, it just learns what is known on the jumphost and when something new is observed, it alerts. In addition, with Wasp in place, the jumphosts are continually monitored for other common signs of infection and intrusion, like newly opened listening IP ports, changes to critical files in the file system, new accounts being created locally or changes to the population of the local administrators group, etc. This new vision into changes on the jumphost can give the security team a heads up when an attack against the critical core is in process. Further, it does so without false positives or noise to degrade their performance over time.

Pricing for HoneyPoint Wasp is comparable to anti-virus pricing. Wasp is designed to work in conjunction with normal anti-virus and is available for Windows systems. Other components of the HoneyPoint product suite are also being used heavily in enclaved environments to bring detection to areas of the network defined as being of the highest priority. Deployments of these tools are in place in government systems, financial organizations, telecomm, manufacturing and critical infrastructure, including SCADA networks. For more information about what HoneyPoint Wasp can bring to your IT environment, give us a call or drop us a line.

Tip: Pre-loading Wasp Configuration Databases

Thanks to a couple of users who have provided this excellent tip for reducing the initial number of alerts that come in when you first deploy HoneyPoint Wasp as it learns it’s environment.

The tip is to load an initial copy of Wasp on a trusted, fresh desktop workstation image and then execute all of the applications your organization generally supports. Then, let the Wasp run for about 48 hours and populate its database with the accepted applications and the like from the default image.

Once complete, use copies of this database in your installation across the enterprise. You will then get delta alerts instead of the base alerts for things you already know and trust. This eliminates the initial set of alerts from each Wasp workstation you deploy and greatly reduces the management load of the initial roll out.

Thanks to the two folks who really worked out this method, tested it and wrote up notes for us to share the idea with you. Much appreciated!

To learn more about using Wasp to extend your malware protection, gain security visibility easily to the workstation layer and create anomaly detection techniques for your security program, give us a call or drop us a line. We look forward to sharing tips like these and success stories with you as they come in from users.

HoneyPoint Wasp is Almost Ready to Leave the Nest

As many of you may know, the MSI team has been hard at work the last several months finishing the beta of our new compromised workstation detection product, HoneyPoint Wasp. It is a fully integrated component of HoneyPoint Security Server, capable of executing distributed detection and threat monitoring on Windows workstations across enterprises. The initial feedback by the beta group have been absolutely amazing. We are finding bots, malware and compromised hosts in a variety of locations, once thought to be “clean” and “safe”.

Wasp accomplishes this mission by being deployed as a service on workstations and by monitoring for the most common signs of compromise. It can watch for changes in the users, admins, port postures and such. It does white list detection of the running processes and it is even capable of detecting DNS tampering and changes to selected files on the operating system.

Even better, it does this work without the need for workstation event logs, signature updates or tuning. It “learns” about the workstation on which it is deployed and adapts its detection techniques to focus on important changes over the long run.

We designed Wasp to be easy to install, easy to manage and to be transparent to the end – user. As such, it is deployed as a 0-interface piece of software. There are no pop-ups, no GUI and no interaction at all with the user. All alerts are routed to the HoneyPoint console and the security team, eliminating any chance of increased help desk calls, user push back and confusion.

In the next couple of weeks, we will be making some announcements about the general availability of the Wasp product. I hope you will join me in my excitement when we announce this launch. In the meantime, think about what you are doing today to protect against initial stage compromises and congratulate the MSI development team and our beta testers on a job well done. I think you are going to be amazed at how easy, capable and advanced Wasp is, when it is released. I know I continue to be amazed at what it is detecting and how much stuff has evaded current detection techniques.

In the meantime, while we await the full release, check out this PDF for some more information about where we are going with Wasp and our HoneyPoint product line. I think you are going to like the diagrams and the explanations. If you would like to book a special sneak preview of Wasp and the rest of HoneyPoint, give your account executive a call. We will be happy to sit down and discuss it with you. As always, thanks for reading!

An Explanation of Our HoneyPoint Internet Threat Monitoring Environment #HITME #security

One of the least understood parts of MicroSolved is how the HoneyPoint Internet Threat Monitoring Environment (#HITME) data is used to better protect our customers. The engineers have asked me to drop this line into the newsletter and give you a “bees knees” perspective of how it works! First, if you don’t know about the #HITME, it is a set of deployed HoneyPoints that gather real world, real time attacker data from around the Internet. 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. You can even follow the real time updates of attacker IPs and target ports on Twitter by following @honeypoint or the #HITME hash tag. MSI licenses that data under Creative Commons, non-commercial for FREE as a public service to the security community.

That said, how does the #HITME help MSI better protect their customers? Well, first, it allows folks to use the #HITME feed of known attacker IPs in a blacklist to block known scanners at their borders. This prevents the scanning tools and malware probes from ever reaching you to start with. Next, the data from the #HITME is analyzed daily and the newest, bleeding edge attack signatures get added to the MSI assessment platform. That means that customers with ongoing assessments and vulnerability management services from MSI get continually tested against the most current forms of attack being used on the Internet. The #HITME data also gets updated into the MSI pen-testing and risk assessment methodologies, focusing our testing on real world attack patterns much more than vendors who rely on typical scanning tools and back-dated threats from their last “yearly bootcamp”.

The #HITME data even flows back to the software vendors through a variety of means. MSI shares new attacks and possible vulnerabilities with the vendors, plus, open source projects targeted by attackers. Often MSI teaches those developers about the vulnerability, the possibilities for mitigation, and how to perform secure coding techniques like proper input validation. The data from the #HITME is used to provide the attack metrics and pattern information that MSI presents in its public speaking, “State of the Threat,” the blog, and other educational efforts. Lastly, but certainly not least, MSI provides an ongoing alerting function for organizations whose machines are compromised. MSI contacts critical infrastructure organizations whose machines turn up in the #HITME data and works with them to mitigate the compromise and manage the threat. These data-centric services are provided, pro-bono, in 99% of all of the cases!

If your organization would be interested in donating an Internet facing system to the #HITME project to further these goals, please contact your account executive. Our hope is that the next time you hear about the #HITME, you’ll get a smile on your face knowing that the members of my hive are working hard day and night to protect MSI customers and the world at large. You can count on us, we’ve got your back!Â