About Brent Huston

I am the CEO of MicroSolved, Inc. and a security evangelist. I have spent the last 20+ years working to make the Internet safer for everyone on a global scale. I believe the Internet has the capability to contribute to the next great leap for mankind, and I want to help make that happen!

Why Replacing Internal NIDS with HoneyPoint is Critical to Your Organization

We are in a new age of information security. The primary threats to our critical data assets are well within the firewalls and layered architectures of the degenerative “perimeter”. Attackers can and will leap your firewalls, tunnel through your DMZs and trick your users into being the gateway to attack. The idea of the walled castle as a form of defense is destroyed and no longer serves anyone well.

With 55% of all attacks that cause financial damages to organizations originating internally, it makes sense that organizations change their focus to internal prevention, detection and response. But using a “false positive generator” like Snort!, Proventia or other NIDS approach is just madness. These mechanisms are so fraught with bad data when focused on the typical internal network that applying any attention to them at all is a huge waste of resources. Of course, the vendors will respond with their magic phrases – “tuning” and “managed service” both of which are just marketing speak for “spend more time and resources that you already don’t have on making our tool actually useful”. Don’t believe me, just ask them about applying their tool to a complex internal environment. Our polls, interviews and questions to users of these technology showed immense amounts of time, money and human resources being applied to keeping signatures up to date, tweaking filters and rules to eliminate false positives and spending HUGE amounts of security team time to chase ghosts and sort out useful events from the noise.

Our initial metrics, as we discussed previously showed that we could cut those resource requirements by 60-90% using a different approach. By leveraging the power of HoneyPoints, their deploy and forget architecture and their lack of false positives your organization can reap the reward of better security with less time, money and work. By combining HoneyPoint Security Server and an appropriate log monitoring tool (like OSSEC), organizations have been able to greatly simplify their deployments, reduce their costs and increase their abilities to focus on the security events that matter. Many have relegated their NIDS deployments at the perimeters to being another source of forensic data to be used along with syslog server data, file system analysis and other data sources compiled to provide evidence when a true incident occurs. NIDS at the perimeters have their value here and being a part of solution as a forensic tool makes them effective when needed, but prevents the “attention overload” that they require when used as a data source on a daily basis.

Detection of attackers in your environment IS CRITICAL. But the way you go about it has to make sense from both a security and manageability standpoint. NIDS has proven to be an ineffective solution in terms of allowing organizations with average resources to succeed. There is a way forward. That way is to change the way we think about information security. HoneyPoint Security Server and MicroSolved can help your organization do just that!

Check out http://www.microsolved.com/honeypoint/ for more information, or give us a call and we will be happy to explain how it works!

Please note: Snort! and Proventia are trademarks of their respective companies. They are great tools when applied to appropriate problems, but in the case of internal network security – we just have a better way! 🙂

3 Reasons Why Internet Voting is a Bad Idea

One of the questions I get asked the most when I speak on electronic voting is why voting is not done over the Internet. While I can clearly understand the idea of online voting being easy and efficient, I wanted to take a moment and give you the three biggest reasons why I think it is a bad idea, at least currently.

1. End Point Security. Voting online would mean that we would allow users to come into an online portal and cast their respective votes. The problem is that we have zero control over the security of the PC doing the voting. Your machine could be under the control of an attacker who could perform any myriad of attacks against you or the voting system. It would be trivial for an attacker who has gained control of your machine to both know how you voted and to modify your vote in real time. Everything from the simple to the sophisticated is within the realm of likely threats against home machines, for proof just look at the number and rates of bot-net infections. Imagine the chaos that could result from voting on compromised systems on a wide scale. The number of variables in this part of the equation alone is enough to give you nightmares.

2. Anonymity. The very processes that would be required to secure and authenticate the voter to the online voting system would also greatly impact their ability to remain anonymous. In order to verify the online identity of the voter, ensure that they only vote once and secure the voting session would require the system to correctly identify the voter against a database and then allow the voter to vote online. Such identification would involve a plethora of logged events and data records. Each of those log entries and data records could be compiled to help an attacker, especially an insider, identify particular voters and perhaps even isolate their vote cast. This has shown to be true with time stamps of paper trails in the current e-voting systems and would be only easier to accomplish with purely digital data.

3. Denial of Service Attacks. This is a severe issue. DoS attacks are trivial to perform these days, even against large scale systems and those with advanced capabilities. The prevalence and ease of bot-net attacks reduce the complexity of shutting down a site to the trivial level. If entire nation’s networks can be knocked off the net, then what chance would a voting portal have? Given the sensitivity, time requirements and public confidence that is needed in the electoral process, any successful denial of service attack against the voting system would be likely to cause chaos. In worst case scenarios, the entire electoral process could be disrupted or forced back to the alternative measures anyway.

In addition to these 3 reasons, many others exist. Sure, there are solutions for some of the problems – but they each range in scale from small to immense. While some countries have worked on or even adopted online voting, it continues to be a bad idea, in my opinion for the United States. The added complexity, cost and security issues certainly raise the idea well beyond the level of current workability. Cost alone is a killer given our current state of the economy, in my opinion.

So, the bottom line is that our current e-voting processes are not perfect. They do leave a lot to be desired, but work is being done in this area. Online voting, however, faces significant issues before it could even be considered as a relatively workable idea.

If you are interested in hearing more about e-voting, I will be presenting this Friday at TechColumbus on the issue, along with another member of the EVEREST team from the Ohio Secretary of State’s office. You can learn more and sign up at: http://www.techcolumbus.org/en/cev/314

Save Time and Money with HoneyPoint Security Server

Well, the initial round of metrics are in. Organizations that have changed the way they think about information security can seriously benefit from changing the way they use NIDS (if they use them at all) and embracing the evolution in information security that HoneyPoint represents. Here are some pretty amazing metrics that have come back from our clients:

Strategy:

Customers who have continued to use NIDS have been able to cease daily monitoring of the alerts and relegate the NIDS to basically being a forensics tool when odd events occur.

Customers who combined our technology with a high signal, low noise log monitoring tool (such as OSSEC) have seen the largest return on investment and simplification.

Metrics:

Basically, when compared with a FREE NIDS (like Snort) using a registered rule set (with a 30 day delay), clients still achieved total cost of ownership savings of 50% by eliminating signature updates, IDS/IPS tuning and management human costs. The elimination of false positives and drastic reduction of events to process (from 5-18K per day) to less than 20 actual events per month, on average also aided these savings. The time savings they reported on average was about 90% per full time employee engaged in security monitoring!

Customers had nothing but praise for HoneyPoint’s strategy, performance and commitment to “deploy and forget” security.

That’s right! Let me recap that again: TCO reduction of 50% and time reduction of 90%! — Better security with less time and money…

The numbers increase significantly from there when compared with commercial (pay for play) software and managed services from a variety of companies. A couple of clients who were using commercial software managed services to try and manage their internal security were able to save between $30K and $82K in their first year with HoneyPoint and then up to $95,000 per year in subsequent years!

The last key point we have taken away from the quick summary of the interviews we have done so far is the amount of respect that the approach, strategy and implementation has earned from regulatory auditors. They have examined the product very thoroughly and done very deep reviews of the both the strategy and the capabilities. The outcome of these regulatory reviews, to date, have been excellent. Regulators have seemed to appreciate the forward thinking and the payoff that customers are receiving. Feedback has been excellent and continues to make us very proud of the work that we and our clients have done to bring HoneyPoint to market.

We will be putting together a more formal way to demonstrate these numbers in the near future. Our use cases and the attack results that we have been able to capture continue to come in and some simply amaze us! Stay tuned for more details as we finish analyzing the interviews and the use cases.

If your organization is interested in trying HoneyPoint and is willing to be a use case or public reference, we would like to talk to you. Deep discounts are available to firms who are willing to engage in this manner with us and we are certainly looking for more verticals outside of our existing markets. Give us a call if you would like to discuss it!

BTW – customers using HoneyPoint Security Server and HornetPoints exposed to the Internet have achieved some significant reduction is scans, probes and attacks by leveraging both “defense fuzzing” and our “one strike and you’re out black hole” approach. Let us know if you would like to hear more about how these strategies and tactics can reduce your Internet risk.

Yet More on SockStress…

OK gang, the story gets interesting again….

Check this out for some deeply technical details on some level of the basics of the attack. Fyodor has done an excellent write up of his guess.

You can also check out the response from the relevant researchers here.

I do like and understand Fyodor’s point that this smells like marketing. Perhaps we are supposed to believe that the vendors will have their responses coodinated and completed before the talk and disclosure? If not, then what is the point of waiting to disclose except to sell tickets to the conference?

This is a pretty HUGE can of worms that seems to have been opened by Kaminsky during the recent DNS issue. I guess it is just another nuance of this new age of attackers that we have entered. We will have to deal with more “huge holes” accompanied by media-frenzy, hype, researcher infighting and security vendor blather until the public and the press grow tired of it.

My point yesterday was that one of these days we will reach a point when some of these major vulnerabilities will not be able to be easily repaired or patched. When that becomes so, we may have to find a way to teach every day users how to plan for, and engineer for, acceptable failures. Until then, we should probably hone those skills and ideas, because it looks like where we are headed may just be fraught with scenarios where some levels of ongoing vulnerability and compromise may be a fact of life.

I believe strongly that we can engineer for failure. We can embrace data classification, appropriate controls and enclave computing in such a way that we can live with a fairly high level of comprise and still keep primary assets safe. I believe that because it seems to be the way we have dealt with other threats throughout history that we could not contain, eliminate or mitigate. We simply evolved our society and ourselves to the point where we could live with them as “accepted risks”. Some day, maybe even soon, we will be able to spend a lot less time worrying about whether or not users click on the “dancing gnome”, keep their workstations patched or if there is a vulnerability in some deep protocol…

The Protocol Vulnerability Game Continues…

First it was the quaking of the Earth under the weight of the DNS vulnerability that kept us awake at night. Experts predicted the demise of the Internet and cast doomsday shadows over the length of the web. Next came a laser focus on BGP and the potential for more damage to the global infrastructure. Following that came the financial crisis – which looks like it could kill the Internet from attrition when vendor, customer, banking and government dollars simply strangle it to death with a huge gasp!

Likely, we haven’t even seen the end of these other issues when a new evil raises it’s head. There has been a ton of attention on the emerging “sockstress” vulnerability. According to some sources this manipulation of TCP state tables will impact every device that can plug into a network and allow an attacker to cause denial of service outages with small amounts of bandwidth. If this is truly a protocol issue across implementations, as the researchers claim, then the effects could be huge for businesses and consumers alike.

What happens when vulnerabilities are discovered in things that can’t be patched? What happens when everyday devices that depend on networking become vulnerable to trivial exploits without mitigation? These are huge issues that impact everything from blenders to refrigerators to set top cable boxes, modems, routers and other critical systems.

Imagine the costs if your broadband ISP had to replace every modem or router in their client’s homes and businesses. What choice would they have if there were a serious vulnerability that couldn’t be fixed with a remote firmware upgrade? Even if the vulnerability could be minimized by some sort of network filtering, what else would those filters break?

It doesn’t take long to understand the potential gravity of attackers finding holes deep inside accepted and propagated protocols and applications.TCP is likely the widest used protocol on the planet. A serious hole in it, could impact risk in everything from power grid and nuclear control systems to the laundromat dryers that update a Twitter stream when they are free.

How will organizations that depend on huge industrial control systems handle these issues? What would the cost be to update/upgrade the robots that build cars at a factory to mitigate a serious hole? How many consumers would be able or willing to replace the network firewall or wireless router that they bought two years ago with new devices that were immune to a security issue?

Granted there should always be a risk versus reward equation in use, and the sky is definitely NOT falling today. But, that said, we know researchers and attackers are digging deeper and deeper into the core protocols and applications that our networks depend on. Given that fact, it seems only reasonable to assume that someday, we may have to face the idea of a hole being present in anything that plugs into a network – much of which does not have a mechanism to be patched, upgraded or protected beyond replacement. Beginning to consider this issue today just might give us some epiphanies or breakthroughs between now and the tomorrow that makes this problem real…

Book October 17th Now… E-Voting Issues with TechColumbus

We finally got everything arranged and we got all of the ducks, not just in a row, but quacking nicely together and we are going forward with the TechColumbus presentation on E-Voting. Come out on October 17th and hear about the EVEREST project, attacks against voting systems and the work that the entire EVEREST team has done to make sure that voting is more secure for Ohioans in 2008.

If you have an interest in voting security, elections or application/device security then this should be a must attend!

You can register here and get more information.

HoneyPoint:Network Trust Agent Helps IT Team Identify Serious Network Hole

We got a great story this week from a user of HoneyPoint:Network Trust Agent (NTA). This user touched base with us to let us know how his NTA deployment on his laptop helped his security team identify a critical network hole.

His story started as usual, he had downloaded NTA after one of our conferences and installed it on his laptop. He felt very strongly that it gave him unique insights into how safe he was as he traveled around and used a variety of public wi-fi and other networks. Users often tell us stories of catching various worms and scans with the product as they work from coffee shops, airports and hotels. Sure enough, the logs he sent us also showed the capture of several PHP scans and some other “wormy” activity against his laptop. He included that he has become a strong believer in “when the light turns red, it is time to go”.

But, his logs also showed us something else. He confided that his laptop had “gone red” while he was using his corporate protected network. Since this was unusual, he notified his network administration team. They, in turn, inspected his laptop and pulled his NTA log. Aghast, they found that the log contained evidence that an Internet host had attempted a telnet connection to his box. That should not be possible, since the firewall should be blocking all inbound telnet attempts. After a short discussion, the admin team analyzed the firewall rules and found a misconfiguration problem. Over the previous weekend, one of the administrators had needed to allow a remote vendor to telnet into a network device for some maintenance, however, the admin is question had applied the wrong netmask to the ACL on the firewall. This had inadvertently exposed the entire internal network to telnet probes from the global public Internet!

Obviously, the admin team took immediate action to properly configure the firewall and teach the administrator in question the proper method for ACL creation. They also began to look for other signs of intrusion and to examine the logs of routers, switches and other systems that could have been exposed to compromise from the error. After they had done a careful review and knew that they were OK, they took the time to have the gentleman let us know about their experience and thank us for the helping hand. “That may be the best 10 bucks we ever spent!”, one of the team members exclaimed.

Do you have a good story about how one of the HoneyPoint products has helped you? Have you caught malicious inbound traffic on your laptop at a coffee shop? If so, let us know.

If you are interested in learning more about HoneyPoint:Network Trust Agent, Personal Edition or our critically acclaimed Security Server product for enterprises, please feel free to email us at info<_at_>microsolved.com or give us a call. We would love to talk with you about how honeypot technologies and our products in particular can help you create effective, efficient and affordable security controls throughout your environment!

Morfeus Scanner soapCaller.bs Scans

Our HoneyPoint deployments have been picking up a recently added (August 08) scan signature from Morfeus, the bot-based web scanner, that has been around for a long time. The new scans were first detected on our consumer grade DSL/Cable segments in late August and have now also been seen on our Corporate environment sensors as well.

The scans check for “soapCaller.bs” and then “/user/soapCaller.bs”. Returning a 200 result code did not bring any additional traffic or attacks from the original source within 96 hours of the initial scans. In fact, returning the 200 did not seem to cause any change in behavior of the scans or any additional attacks from any source. Likely, this means that vulnerable hosts are being cataloged for later mass exploitation.

Morfeus scans are quite prevalent and can include searches for a number of common PHP and other web application vulnerabilities. Google searches on “morfeus” return about 259,000 results, including quite a few mentions of ongoing scans from the bot-net.

Here is a blog post that discusses using .htaccess rules to block scans with the morfeus user agent.

Morfeus has shown itself to be quite adaptive and seems to be updated pretty frequently by the bot-masters with new application attack signatures. The scanning is very widespread and can be observed on a regular basis across platforms and ISP types.

The soapCaller.bs page is a file often associated with Drupal content management system. There have been a number of vulnerabilities identified in this package in the past, including during our recent content manager testing project. Users of Drupal should be vigilant in patching the systems and in performing application assessments.

Blog Layout Plainess and Distributed, Syndicated Threats

Just got a great question about the visual layout of the blog page.

To answer the questionof why we don’t increase the “flash” of the blog page that RobM asked about, the answer comes from Marketing Guru Seth Godin – we want you to focus on the signal contained in the blog posts, not the “noise” that would enter into the equation if we added a bunch of screen gadgets, flair or other eye (and attention) grabbing stuff.

We hope that you read the blog to get information about the state of information security, technology/privacy issues and the other topics we cover here.

So, RobM, that’s the long and short of it. We want your attention to be focused on the quality of the content we deliver and nothing else. If you want to know what the latest weather forecast is, what virus alerts or the like are going on – check out one of the many information security “portals” out there. They are very high on gadgets, heads up displays and all kinds of other stuff. They certainly have their purpose, but they just present too much “noise” to “signal” for the vision of the MSI team.

That said, to keep this blog post more on topic than marketing strategy – have you ever considered the threats that could stem from syndication into things like portals? Imagine the cookie theft that be performed by a rogue entry in a syndicated RSS feed or other mechanism that got wide distribution. I know this has seen a POC in the past and I have tested more than a few RSS clients that were vulnerable to embedded XSS attacks.

One scenario that the team has discussed is the injection of XSS or the like inside of corporate feeds on the intranet. This could be a quick, easy way to gain several forms of access to a variety of internal web apps in an enterprise. Would your internal feed mechanisms catch the attack? Would your internal users be exploitable? If your organization has moved forward with embracing RSS feeds and other syndication techniques – this might be something to add to your next assessment.

Revision of Twitter Strategy

OK, I spent the last week or so working on my Twitter capability. But, I have to say, after a week, Tim Ferriss’s strategy of not following people really seems to be limiting the capabilities that Twitter seems to bring to the table in terms of information aggregation, conversation and leveraged crowd sourcing on ideas. So, effective now, I will start to follow key people who add good rapport, valuable information and good conversation.

Again, if you are interested in following me on Twitter, you can find me at http://www.twitter.com/lbhuston

I will continue to tweak out how I use Twitter and see if I can find a good leverage point for the tool. The more I learn, the more I will report back here, in the hopes of eventually being able to build a methodology of sorts….

Thanks again for reading the blog, tolerating the noise and being interested. Blogging and Twittering rank right up there with public speaking in my book. Being able to speak, teach and work with the public is one of the things that truly makes me “The Luckiest Guy In The World”(TM)…..