Author Archives: Brent Huston

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!

The “TSA Week at a Glance” Content – Huh???

Posted on by
Reply

This just in from the “No, we swear this isn’t propaganda” department.

The TSA seems to have added a section to their web site where you can keep tabs on just what they have been up to this week. You can check it out here.

As of this moment, here is what they have been doing so far this week:

* 15 passengers were arrested due to suspicious behavior or fraudulent travel documents

* 18 firearms found at checkpoints

* 12 incidents that involved a checkpoint closure, terminal evacuation or sterile area breach

* 16 disruptive passengers on flights

So, basically, according to those figures – they apparently have worked 61 “incidents” this week alone. Unfortunately, what they don’t seem to show is a graphic that shows where this lies as a historical piece of data. Wouldn’t it be whiz bang cool if they had a graph that showed historic trending? Maybe they could also do some sort of predictive “threat radar” that could turn various colors and make beeping sounds when they think more disruptive passengers are expected- like say the next time airlines go out of business, strand travelers, treat them without dignity – oh wait, that seems to be usual air travel today. No wonder they don’t have any sort of historic metrics…
I also particularly liked the large window at the top of the page that currently says something to the effect of “Chilling details have emerged about a trans-atlantic terror plot.” I am pretty sure that’s what I want to read from the TSA – horror stories. Is it just me or does this stuff seem like maybe it belongs someplace else? I really don’t want to view that material from the government group that’s supposed to protect me. Sure, you have the details. Sure, you might even have caught them, but I also think it induces more fear than it calms and reassures.
Hey TSA, how about a lot less marketing and a lot more focus on the presenting the details that we NEED TO KNOW. Please, refrain from using FUD to justify your presence in our lives and your budget dollars. Thanks!!!

The Dangers of “We Find Vulns or It’s Free” Security Offers…

Posted on by
Reply

I was astounded at this posting this morning in Credit Union Times.

These types of offers always make me cringe when I see them. At first blush, they may seem like a good idea. Why not, after all, we all want to believe that our application is secure and we all want something for free. This certainly seems like the best of both worlds. How could this be bad?

Well, first off, security testing choices should not be based on price. They should be based on risk. The goal is to reduce the risk that any given operation (application, network, system, process, etc.) presents to the organization to a level that is manageable. Trust me, I have been in the security business for 20 years and all vendor processes are NOT created equal. Many variations exist in depth, skill level, scope, reporting capability, experience, etc. As such, selecting security testing vendors based upon price is a really really really bad idea. Matching vendors specific experience, reporting styles and technical capabilities to your environment and needs is a far better solution for too many reasons to expound upon here.

Second, the “find vulnerabilities or it’s free” mentality can really back fire for everyone involved. It’s hard enough for developers and technical teams to take their lumps from a security test when holes emerge, but to now also tie that to price makes it doubly difficult for them to take. “Great, I pay now because Tommy made some silly mistake!” is just one possibility. How do you think management may handle that? What about Tommy? Believe me, there can be long term side effects for Tommy’s career, especially if he is also blamed for breaking the team’s budget in addition to causing them to fail an audit.

Thirdly, it actually encourages the security assessment team to make mountains out of mole hills. Since they are rewarded only when they find vulnerabilities and the customer expectations of value are automatically built on severity (it’s human nature), then it certainly (even if only unconsciously) behooves the security team to note even small issues as serious security holes. In our experience, this can drastically impact the perceived risk of identified security issues in both technicians and management and has even been known to cause knee-jerk reactions and unneeded panic when reports arrive that show things like simple information leakage as “critical vulnerabilities”. Clearly, if the vendor is not extremely careful and mindful of ethical behavior among their teams, you can get serious skewed views between perceived risk and real-world risk, again primarily motivated by the need to find issues to make the engagement profitable.

Lastly, I am the first to admit that such marketing approaches simply “bother me”. They lend a certain air of “used car dealer” salesmanship to the security industry. This is hardly something that, in my opinion, our industry needs. We are already working hard to overcome the idea that many vendors have glommed onto for decades – that fear sells products. This enough challenge for us for now, so the last thing we need is for our industry to be viewed as is another marketplace full of “gimmicks”.

In my opinion, let’s stick to plain old value. My organization helps you find and manage your risk. We help you focus on the specific technical vulnerabilities in networks, systems, applications and operations that attackers could exploit to cause you damage. To do this, my company employs security engineers. These deeply skilled experts earn a wage and thus cost money. Our services are based around the idea that the work we do has value. The damages that we prevent from occurring save your company money. Some of that money pays us for our services and thus, we pay our experts. Value. End of story.

No gimmicks, sales hype or catchy marketing will ever replace value or the truth. Between you and me, I think that’s a very good thing!

Bot-nets Continue to Grow in Scope and Danger

Posted on by
Reply

There is quite a bit of talk online right now about a new bot-net that is supposedly quite a bit larger than Storm. This new bot-net, called Kraken, was discovered and initially revealed by another security team. Various folks are pointing at it as another evolutionary step in the growth of the bot-net threat and as a major new development in the area of cyber-crime.

Bot-nets, it seems, are today’s Internet worms. Their power, capability to produce FUD and impact make them on par with the Slammer, Code Red and Nimda worms of the past as significant threat evolutions. However, just like the worms of yesterday, there are some pretty common – albeit sometimes tough – things you can do to help minimize your risk of exposure.

First, segregate your network. Create enclaves that separate and manage access to servers that hold critical or sensitive data. Basically, segregate any and all user systems into untrusted areas and manage them as if they were untrusted systems (they are!!!)

Next, deploy egress controls as tightly as possible for all user -> Internet activity. Apply egress controls as tightly as possible to all enclaves.

Now, ensure that you have proper preventative and monitoring controls on all of the enclaves. Check for unneeded services, missing patches (OS and applications), bad configurations and known security issues. Mitigate or repair as many as possible. Monitor everything at the egress point for forensics and help with finding infected hosts. Deploy HoneyPoint sensors in user community and all enclaves.

Harden the user systems to the largest extent possible. AV, personal firewalls, patches, consider hardening or changing browsers. No matter what, consider user systems as untrusted hosts!

Educate your users about threats, their responsibilities and security mechanisms for their systems when outside the corporate network.

Monitor, manage and handle incidents quickly and with public consequences. If you find an infected machine and can trace it back to porn downloads on a company machine, fire the person and make a public example of the fact that actions against security policy (you have one of those, right?) have consequences…

Doing these basics will increase your overall security and greatly reduce your risk from bot-nets (and other threats). Is it easy? No. Is it expensive? It can be, depending on your size, complexity and technology level. Is it worth doing? Yes. It reduces risk and is much more interesting than ignoring the problem and/or continually working reactively to various incidents and compromises.

The Application Layer is Where the Action Is…

Posted on by
Reply

I thought this particular “hacker” article was pretty interesting. Thanks to Dr. Anton Chuvakin’s “Security Warrior” blog for pointing it out.

Once you look beyond the manifesto hype, you can really get a feel for what it represents. It represents a call to action to remind security professionals that the game has changed. The network and systems that it is composed of remain but a part of the security equation. The real target of the attackers that represent the REAL THREAT is the data that the network and systems hold.

Attackers have definitely moved up the stack. They do not care that most organizations are still focused on the network layer and more than a few are still trying to get the basics of that right. In fact, it simply empowers them more.

Today, attackers are focused on the application. That is true whether you look at holes like SQL injection and XSS or at the browser vulnerabilities that are at the root of a majority of malware and bot-net activity today. Today’s attackers have excellent tools for exploit development that have seriously changed the security landscape. More attackers understand the deeper nuances of computer science than ever before. Man security teams and professionals are lagging behind in knowledge, resources and capability.

One of the big reinforcers of this ideal to me was a presentation I gave a few weeks ago about application security. During the research for it, I found that according to several sources, a HUGE amount – roughly a third – of all reported security incidents last year involved SQL injection and XSS. Almost 2/3s of all reported incidents were web-application focused. Clearly, there is no denying that the attackers have moved up the security stack – the question is – have the defenders…

What are you, your security team and your security partners doing today to ensure that your data is protected tomorrow?

Patent Wierdness and the Security Market

Posted on by
Reply

CrowdedMarket.jpeg

So I was doing some patent research today and I have to say that some of the patents out there for information security are pretty weird.

I found patent applications for wireless access points that turn on radio jammers in response to attacks (thus blocking even legitimate users), ethernet cables that can be colored with special markers depending on the security of the system they are attached to, a physical key-based device that controls an ethernet air-gap and even a patent application that was denied for patenting the word “security”.

I had no idea that so many things had been patented, or attempted to be patented. Maybe I am not a “patent insider” – but a lot this sounds like junk, bad infomercials and “seen on TV” security products.

I think I should find a VC and maybe patent the special “security gnomes” that some software vendors believe protect their software from well-known exploits. Or the “magic security dust” that some managers believe allows them keep their data protected without investing in any real security staff or initiatives. If those don’t work, maybe I will patent some sort of “cyber-ninja” that seeks out and destroys cross-site scripting vulnerabilities and SQL injections. Why not? It might be as effective a control as colored ethernet cables…

For a couple of years now, Allan and I have been talking about just how noisy the information security market has become. Even after a large consolidation phase, there are still a bunch of vendors, some selling solutions and some selling snake oil. The average IT manager is probably getting 10+ calls a day from vendors selling them everything from firewalls to NAC and from AV software to USB blockers. No wonder average security consumers are having so much trouble knowing the real from the hype!

I didn’t start this blog post to be a rant or anything, but the oddity of the patent searches really left me in awe. The security space is crowded, noisy and a lot like a downtown Delhi market. There are exotic spices, rarities and a number of arcane items everywhere you look. Hopefully, there are also some honest to goodness, back to basics solutions mixed in too. Your mission, should you accept it, is to sort them out…

A Very Good Idea – Open Source SQL Application Firewall

Posted on by
Reply

A few weeks ago I ran across this project, called GreenSQL. It is an open source database firewall to help organizations mitigate application vulnerabilities due to common SQL attacks like SQL injection and such.

It is a list-based heuristic proxy firewall that you can use to filter SQL traffic between the web server and the database server. This is a pretty powerful tool, even being list-based. As this project evolves, perhaps it will also include more powerful approaches such as anomaly-based analysis.

For now though, black listing, white listing and their approach to transaction risk weighting is a very powerful approach and much better than nothing.

That said, MSI has has not tested the application or performed any formal review, we just liked the idea that they were working on. Perhaps, in the future we will donate some lab cycles to a review and some testing, but we wanted to help them at least get the word out about their project.

If you are using MySQL for your web-based applications, it might be a good thing to spend some time looking at this project and testing the capabilities of the tool for your environment. Eliminating SQL attacks from web-applications will reduce a significant amount of risk from their deployment. By some estimates, that risk could be as high as 25% of the aggregate risk an application causes. No matter the metrics, this project is certainly a step forward.

Playing with VoIP Hopper

Posted on by
Reply

I have spent just a little time playing with VoIP Hopper, which was updated in mid-February. Thus far, this seems like a pretty useful tool for doing penetration testing and enumeration of your VLAN segments and VoIP deployments.

The tool is very capable. It can easily help you scan your installations with CDP discovery and can be very useful in testing VLAN architectures for common security holes.

It is a command line tool written in C, but you should have no problem compiling it in your favorite Linux environment. It even works nicely on a default BackTrack install, so it playing with it should be easy on your lab schedule.

There has been a lot of attention paid to VoIP security over the last couple of years and this is certainly a nice quick and dirty tool for looking around your install. It also sheds a little light on the mistaken idea that some service providers like to pretend is the gospel – VLANs really won’t keep your VoIP secure. You can use this tool to prove them wrong if they just won’t listen to reason…

Play nice with it and make sure you only use it in the lab or on authorized networks…

Be Careful Who You Trust…

Posted on by
Reply

j0289379.jpg

This usually goes without saying, but trusting the wrong people, organizations of mechanisms can seriously bite you.

Take for example, the current situation with ORDB.org. They are one of the older spam blacklists and they have been around a while. So long in fact, that when they shut down in 2006 few people took notice. But, we should have.

It turns out that a few organizations and a few vendors used the blacklist provider as another source for spam prevention. Since the project was shut down, the list was un-updated since the end of 2006. Mostly, that is no harm – no foul – unless you happened to have inherited one of those IP addresses on the list, then you might be a little mad…

But, as of this week, the ORDB list suddenly changed behavior for an as-of-yet-unknown reason. All of a sudden the blacklist started to block ALL IP addresses!

Now many folks would say, if the list shutdown in 2006, why do we care? Well, it turns out that a lot of vendor products and a few careless admins had left the list in their systems. They were still trusting the contents of the blacklist as a spam prevention tool. As you might imagine, what has ensued is a TON of blocked e-mails, a few mad customers and some bewildered troubleshooting technicians…

But, this is just that same old IT problem. Often, we build systems with trusts, configurations and dependencies that exist today. Maybe (most likely) they will not exist in the future. What happens when/if they don’t? Usually, things break. Maybe, if you are lucky, they break in big ways so that people notice. But, if they break in some small way, say in a subtle way that goes unnoticed, they could have dire affects on confidentiality, integrity and availability. As a quick example, what if you were scraping financial data from a website for use in a calculation – maybe an exchange rate. What happens if no one is checking and that website stops updating? Could your calculations be wrong? How would you know? If the exchange rate didn’t vary grossly, but only had small changes over time, what would the effect be? You see, even small issues like this could have HUGE impact. In this scenario, you could lose, mis-bill or the like by millions of dollars over time…

Trust for abandoned projects also raises another security issue. It is pretty likely that projects, systems and applications that are abandoned could become lack on being patched or maintained. If this were to occur and you are still dependent on the data – what would happen if an attacker took control of the project or system hosting it? I am not saying this happened at ORDB, but suppose it did. It seems to me that attacking and compromising old abandoned projects that people might still be dependent on is a pretty creative approach to causing some amount of chaos.

I guess the big question that the ORDB situation raises is; what other things like it are out there? What other abandoned projects or technologies are we dependent upon? How might this mechanism come to be used against us in the future?

3 Application Security Must Dos Presentation Now Available

Posted on by
Reply

We are pleased to announce the general availability of the slides and audio of our presentation from March 25, 2008.

The event was focused on three strategies for application security.

You can download the slides and audio MP3 from the links below.

PDF of the slides:

http://microsolved.com/files/3AppSecMustDo.pdf

MP3 URL:

http://microsolved.com/files/3AppSecMustDos032508.mp3

** Please Note: the audio MP3 did not come out as well as our others due to a mic issue. The problem has been resolved, but please remember to lower the volume on your MP3 player as the clip is overly loud and a bit “clipped”. We apologize for the issue.