I had an interesting and odd conversation with some folks today who were trying to determine how fast NIDS would identify potential attacker traffic that was innocent appearing. When I entered the debate, they were deep in conversation that centered around threshold settings in various IDS/IPS products and their recognition of port scanning. They seemed to be engrossed in how many connection attempts in a second should be considered malicious.

Eventually, they asked me about HoneyPoint and how many connections it takes for it to decide that traffic is malicious. I simply responded “One.” Finally, I explained that since HoneyPoints are psuedo-services and have no real reason for any traffic at all – that ANY CONNECTION to a HoneyPoint was by nature suspicious and we would alert. After about 15 minutes of discussion and further debate, I think I made believers out of them and they have all requested to demo the product for 90 days in their environment.

This is simply another way that HoneyPoint changes the IDS/IPS paradigm. It doesn’t really matter how MANY connections an attacker makes per second unless they are causing DoS on the network. IT REALLY MATTERS WHAT THEY ARE CONNECTING TO!

HoneyPoint can help you determine the criticality of even a single connection to a pseudo-service. You could take action then, or wait to see how things develop. If the attacker hits multiple HoneyPoints on a single host or multiple HoneyPoints on multiple hosts, you can determine what to do based on the risk of the behavior you see. If they begin to probe the HoneyPoints, you can likely very quickly determine what tools they are using, what they seem to be focusing on, etc. All of that helps you make better decisions and to craft smarter, more effective responses.

So, the bottom line is this: As wierd a metric for comparison as port scanning thresholding may be, HoneyPoint can help you drop that number to 1. Using HoneyPoint smartly and effictively – you can secure your environment more rapidly, easily and with greater insight than other technologies. How is that for an unusual metric?

Please pardon the overt marketing interruption.

You can now get your very own HoneyPoint Swag from Cafe Press. If you are interested in showing the world you are helping to change the way Intrusion Detection is done, please feel free to order your merchandise from here.

http://www.cafepress.com/honeypoint

Also, while we are overtly promoting this morning, please don’t forget to use the HoneyPoint forum if you have interest in learning more about HoneyPoint, strategies or the like. Real users, a real community. Up and coming – for sure! But check it out if you are a fan of HoneyPoint or honeypots in general. Registration is required.

http://www.honeypoint.net 

Sorry for the overt marketing interruption and we now return you to your regularly scheduled blog.

After a discussion today, I wanted to post about a couple of ideas for helping managers keep their security teams engaged in the process.

Burn out is a very common thing in infosec, as it is in a lot of IT – especially in organizations today, when there is so much going on and so few resources to aim at the problems. Here are 3 quick ideas to help you fight burn out amongst the security team.

1. Training or Cross Training – Few things engage people more than learning a new skill, especially one that is new and interesting or that can really help them solve their work problems. Consider teaching a new skill like Perl scripting (or any other language) that might help them automate some of their tasks. If they embrace it, it can mean less work for them and more quality, repeatable results for the team. That is a pretty cool win/win. You might also consider swapping your team around and rotating their responsibilities where possible. Encourage large scale cross-training as way to keep things fresh and to keep new eyes on your common duties. Often times, this plays out well and can lead to some big new ideas or mechanisms that can have huge paybacks!

2. Engage in some branding – Create a team image that exudes confidence. Brand the team members with special events, shirts or other items. Let them name the team and encourage a few group events that establish trust and reinforce rapport. If appropriate, let them build an image around themselves as being “elite” or such. Those images are good for morale and good for building the internal image of you and your group – just make sure it stays realistic and doesn’t go to far.

3. Let some of your team rotate on pet projects – Has your team been bugging you about a new tool or process they need? Have they been asking to build a wiki to maintain their documentation or a new Intranet site for communication with other teams? If so, add it as a project, but communicate that they must rotate who works on it and set a maximum of 2 hours per week. Let them choose a project leader and have that person schedule the work on the pet project and report monthly status updates to the whole team. You just might be suprised how much they get done, and how much such a simple indulgence might reenergize some or all of them!

Leverage these 3 quick ideas to keep your team engaged and running on all cylinders. Got some other ideas you might have had success with? Post them as a comment and I will make sure they get added!

How much is it worth to know that a new vulnerability has been found in your organization’s favorite application or operating system? Would you pay $50,000.00 a year for alerts to new exploits or attacker trends? Does knowing that these issues exist give your organization a measurable heads up to prevent damages that you don’t have from your regular scanning and assessments? Would that knowledge actually spark action that reduced your risks?

Many other security firms are hoping you say “Yes!” to the above. And, with prices for those alerting mechanisms ranging from that 50K to nearly 200K per year, you had better be pretty sure of the value of those alerts.

At MSI, we believe that such knowledge is valuable. We believe that properly acted upon, such data could help many organizations prepare for security issues, tune their protective postures and increase vigilance around possible weaknesses. However, we just don’t believe that most organizations are willing to spend that 50K per year for such insights, nor do we believe they should. For several years now, we have offerred such a service, called WatchDog for FREE. That’s right, FREE per year.

Our organization does this to give back to the community. We do this because we already have to do the major work anyway to stay current and serve our clients at the level of excellence we are committed to, so why not aggregate that knowledge and give back to the world?

If you are not a WatchDog user yet, or you are considering how you might integrate an intelligence product into your security posture, feel free to give us a try. You can download the product here.

Oh, and if you like it, or the data we provide, please feel free to donate $50,000 or more to your favorite charity. They will thank you and the world will be a better place, just as it should be.

We are hearing more and more rumblings these days about making PCI the default standard for infosec, and a lot more legal rumblings of making their standards enforceable as state laws. Already Minnesota has passed the standards into law and Texas seems to be next.

While I see the PCI standards as a step forward for credit card companies, I am not so sure that enforcing it as law is a good thing. Over legislation has done little to secure the Internet thus far (remember the “Can Spam Act”) and in some cases has caused so much legal confusion that small rebellions have broken out (See the DMCA for this one!). I am not sure that organizations will become compliant just because it is law, as opposed to just being a rule from their card processors. After all, does the amount of “large fines and penalties” really matter? Does it really change behavior? I just don’t believe it does.

Nonetheless, PCI has certainly gained momentum and public recognition. Many of our clients who don’t even process credit cards have begun asking about it, siting it as a standard and asking for gap analysis between their processes and the DSS standards. Many of them believe that in the not too distant future, courts may see PCI DSS as the defacto security baseline that helps them determine the difference between liability and negligence for just about all organizations, not just credit card dependant ones. One thing is certain, now would likely be a good time to become familiar with the PCI rules because your management may be asking you sooner rather than later.

Our HoneyPoint sensors have been picking up quite a large number of scans for open proxies lately. As usual, much of this traffic is originating in China, where open proxies are used for a number of reasons from spam to political activity to simple uncensored Internet access.

Interestingly, we are seeing a pretty decent increase in the number of probes for open web proxies using a site called www.loanscandyloans.com as the target. This site, owned by a person in China and hosted in the US seems to be a front site with the main purpose of simply hosting a set of PHP scripts used to verify open proxies and other connections.

Quick Google searches about LoansCandy reveal a short history of scans, probes and semi-malicious activity. Likely, the site is used simply as a collection point for the data and offers little else in real terms. However, it might be wise for organizations to consider blocking any connections to the site, just in case open relays or proxies might be present in their environment.

HoneyPoint has been an essential part of MSI’s infosec intelligence program and continues to prove itself an amazing tool for threat analysis on Internet or internal networks. We continually monitor several HoneyPoint deployments around the world for interesting activity and attacker trends. Look for us to share more data from our captures in the future.

As I write this, I am sending my final weekly column over to ITWorld.

After more than six years, ITWorld and I decided to make some changes to the column and site and as a part of those changes, I will be moving my writing over to the blog and focusing on it more in the future.

ITWorld and MSI will continue to work together, and I will likely pop in on the security site from time to time with an occasional article, whitepaper or multi-media presentation. We will also continue to work together on other items as well. They are a great team, and we truly enjoy working with them on a regular basis.

Part of these changes are based on a new direction for the ITWorld site, and part of it is to allow me to focus more on new media work, like blogging and creating richer materials and content to further evangelize MSI and HoneyPoint technologies.

Look for more content here on the blog, more coverage and maybe even some site enhancements as I switch my focal point to be more centered on StateOfSecurity.com. In the meantime, thanks for your patience, and if you are just coming over from the traditional column, please let me extend a big WELCOME and to point you to the archives. There are a lot of good topics there, and I can assure you a lot more to come.

As always, thanks for reading, in the past and in all of the days to come! You folks really make all of this possible, so Thank You!!!

I recently came back across a prank that was pulled some years ago against a local news station. Some college students had found out that the school and business tickers that you are probably familiar with, accepted input directly from the news website. All that was required was to sign up, and put in your business, contact, and hours opened/closed. Now one might think that somebody would check these before they go on live TV, but that’s exactly what didn’t happen in this case. The students proceeded to sign up humorous businesses, and have them displayed on live TV. This happened numerous times before someone at the station caught on and disabled the feature.

What I’m getting at here, is that this could have easily been turned into an attack to harm a company’s reputation. They could have easily posted that Joe Shmoe Inc. was doing something illegal, and potentially caused an HR and legal nightmare for that company. Might even be possible to “Denial of Service” the company! Word spreads that there was no work today, nobody shows up, and no work gets done.

The lesson this shows is that user input should never be trusted. When “user input” is described, usually we think about bad characters in input fields, SQL injections, or cross site scripting. But this example goes to show that those issues are not the only things to be considered.

On my way in to work this morning I heard a fairly disturbing news report about criminals using basic social engineering techniques to get family members of US military members, that are deployed to Iraq and Afghanistan, to divulge the servicemen and women’s personal information. Here’s how the attack played out:

Criminal obtains a list of members of a specific unit or command and tracks down the phone numbers of family members of those soldiers. Criminal then calls the family member and states that they are calling from the Red Cross and that their son/daughter/spouse has been injured in the course of performing their duties.  Then the criminal states that in order for the Red Cross to be able to transport the service member to a military hospital in Germany, the Red Cross needs to verify the Social Security Number and date of birth of the injured soldier. While the family member is upset, they quickly give out the information to ensure that their loved one gets the medical attention they need. At this point, the criminal now has all the information they need to begin the identity theft that we hear so much about.

This type of attack, while completely abhorent, has worked numerous times.  I have not been able to find any conclusive data that speaks to how many people have been affected, nor do I think it is important for the purposes of this blog.  What is important though, is to consider a couple of things.

1.) The Red Cross would never contact a military member’s family directly, without going through military channels.

2.) The Red Cross or military would never need to verify that type of information in order to proceed with medical attention.

3.) No person should ever give out that type of information over the phone, especially if you did not initiate the call

What really interests me though, is the creativeness of the attack.  It plays on emotion to be successful. Whether you are for the war or against doesn’t matter, everyone should be able to agree that it is an emotional subject, especially when talking about a loved one.  The lesson to learn from this is simple. Guard your personal identity very closely. This example only strengthens the notion that criminals will do very nasty things to get access to your information. This is a business to them…a very profitable business at that.

We know that the average consumer will always choose the metaphorical “Dancing Bear” when confronted with these types of attacks. At MSI, we have refined our services to include rigorous social engineering exercises for our clients.  While we have seen improvement in the security posture of our client’s user base (at least the one’s who have taken advantage of the service offerings), there is a part of me that believes that those users aren’t taking the knowledge we are giving them and applying it to their personal lives.  For the one’s that are, we commend you and hope you continue to interact with the masses in a secure way.  We would love to not hear any more of these types of stories.  Unfortunately, we truely believe that this current trend of identity theft is only going to continue.  At least until “average Joe” begins to understand the threat.

I received an email the other day from a buddy from my former life in the Marine Corps. The email was basically a mass spam letting all of his friends know that he was planning on having a party in the coming months and had created a website with a forum to track reservations and random conversation. Since it’s an 8 hour drive back out there to Virginia, I only get to visit a couple of times a year and this party sounded like a pretty good excuse to make the trip. So, I went ahead and registered for an account on the website and logged in to make my reservation and see what everyone had to say about the party and what they’ve been up to.

As soon as I logged in, I made my way to the forum links to join the conversations. When I clicked on the very first link, can you guess what I was offered? That’s right, a very juicy error message letting me know that an error had occurred in the application. Now, it’s great that the server informed me that an error had occurred, but i was astonished at all of the information it was giving me…just a normal user. The first thing that I noticed is that the error page showed the average user the complete, full path to the location of the script that had failed. Not only did it give me the full path, it also showed me the exact number of the line in the script that was causing the problem…in addition to 3 lines above and below the faulty line. In those lines I got to see several interesting SQL arguments being passed, complete with tables and fields and object names. If I were specifically attacking this site, this error message would have given me some great information. Since I wasn’t attacking the site, I promptly emailed my buddy and told him about the problem I had just seen and suggested that he customize those error messages so that they don’t give out too much information. Needless to say, he got right to work on identifying the problem and limiting the amount of information that was being divulged.

Now, you might say to me, “why would it matter, it was a fairly useless website with no useable information”. I’d tell you that you are right, in the grand scheme of things. Sure, I probably wouldn’t be able to get my hands on any uber-sensitive information. That’s not what is important. What is important is that my buddy who built the site also creates some fairly powerful custom web applications for the government. If his useless website is configured in such a way, is he making the same mistakes when building applications for the people that want to keep the secrets….well, secret?

By offering up an error message like that, an attacker is able to use the information to refine their attacks. In addition to that, we used to have a saying in the Marine Corps when preparing for a wall locker inspection. “If the presentation of the wall locker is such that the inspector doesn’t want to mess it up to inspect it, you’ll do just fine. If it looks like trash, the inspector is going to start digging into things, ultimately finding more problems.” The same idea holds true for attackers. If you present an application or website that doesn’t give away too much information and appears to be well secured, most attackers will move on to the next site. If simple things like error messages divulging tons of information are found, you can bet that the attacker is going to believe that there are other configuration errors and will begin to dig around. We don’t want them doing that, now do we?

I don’t mean to pick on him about this because he is a very good programmer, security savvy and very smart guy. He and I spent many, many hours in the Marine Corps investigating incidents together and solving problems. I simply wanted to use this real world experience to illustrate how important it can be to make sure that your web applications are configured securely. Even if they appear to be useless websites that no one would be interested in, they can lead to attack escalation and possibly compromise.