Previously, I wrote about the supposed lack of SSL/HTTPS support in the Twitter API. However, thanks to Tony for pointing me in the right direction. I DID find support for HTTPS in the API and I have since updated my own tool (released by me as freeware and not associated with MSI) to use it.

For those of you who are interested, you can find the new release of TweetCLI 1.10 that supports updates via HTTPS here:

Windows, Linux, OS X versions.

Thanks to everyone that uses it and feel free to let me know your thoughts and feelings on twitter @lbhuston.

The new version should work as a simple replacement in the previously released HPSS plugin.

You can also subscribe to a “bad touches” feed from some of our Internet exposed HoneyPoints around the world. We are publishing source IP and destination ports only currently, as we work on ways to publish the payloads we get in some manner as well. More on that in the future. The current “bad touches” feed is @honeypoint.

Apologies to twitter for the SSL issue. Additions to the API documentation to show HTTPS examples as the default would be much appreciated.

Hope everyone is having a wonderful holiday season. Thanks for reading and we look forward to more infosec news and research in the future.

In the US several “secondary financial services” exist. They range from check cashing/money transfer to short-term lenders and various other financial services. Many of these organizations also offer additional services like payroll check loans, check “floats”, tax preparation and a variety of services. In many cases these organizations aim their marketing for immigrant workers, people sending money to foreign countries and the economically challenged.

Unlike traditional banks and credit unions, these organizations are loosely regulated, if at all. In many states few rules for their operation exist and certainly they do not face the security and regulatory requirements of traditional financial services organizations. Several cases have been made about the predatory, aggressive and border-line criminal activities that seem to abound in this industry.

Recently, Panda, an anti-virus vendor, completed a study of the check cashing centric businesses associated with this tier of financial services. Their study found that thousands of machines in these businesses were running out of date security software, including anti-virus trial versions. They observed more than 1500 machines running these out of date basic security tools. Of those, they found more than 60 percent to be actively infected by some form of malware. 80 percent of the machines studied were actively being used to process financial transactions.

Basically, this demonstrates a true lack of concern for information security in this sector. By not providing for even the most basic of security functions, anti-virus, they leave the identity and financial data of their clients vulnerable to theft and tampering.

To make matters worse, in many locations in our state, Ohio, the check cashing organizations require a lot of information about you to obtain their services. Normal contact information, plus social security number, driver’s license and other identity details are often maintained in their databases. In more than one case of calling around various locales near us, several of the companies asked for a “client number” and when pressed, we were told this was the same as our social security number and could be found on our “membership card”. Needless to say, this very fact that SSN is being used so carelessly, gave us more than a chill. We truly hope that those consumers choosing to use these organizations for financial services take note of the insecurity and risks to which they may be exposing themselves.

Ohio has just passed new laws to regulate the practices of these organizations and to prevent some of their more abusive tactics. Let’s hope that additional regulatory oversight and attention to information security is also coming for these businesses. Until then, they and the consumers who choose them, remain in the low hanging fruit category for cyber-criminals and identity thieves.

I got a lot of response from folks about my last cheat sheet post. Here is another one that many folks might find useful.

This one, from Microsoft, describes quick references for the Microsoft Web App Security Framework. This is a pretty useful sheet and one that our techs use a lot.

I also find this one for Nessus and Nmap to be pretty useful.

I found this one for you CISSP study folk.

This one for PMP study folk.

And, lastly, for all the new waxers of armchair economics, this one about sub-prime mortgages…

OK,OK, I could not resist this one, THE INTERACTIVE SIX DEGREES OF KEVIN BACON CHEAT SHEET!

Hope you enjoy these, and now back to your regularly scheduled infosec blogs… 🙂

Our tech lab reviews several financial applications every year from a variety of vendors that are focused on the financial institution market space. The majority of these applications perform poorly to some extent in either security and/or usability. Here are three key tips for vendors to keep in mind when they or their clients ask us to do an assessment of their application.

1. Make sure the application actually works as it would in a production environment. Make sure it is reasonable in terms of performance. The idea of performing our lab assessment is to model risks in a real world simulation. Thus, if the system is not configured and working as it would in a real deployment, then the validity of the test is poor. Many of the applications we test simply do not function as expected. Many times, their performance is so slow and horrible that it impacts the availability metric. Basically, by the time it is submitted for the complete application assessment or risk assessment, it should work and be installed in a QA environment just as it would be in production. If there are any variances, be prepared with a document that explains them and their anticipated effects. Be ready to discuss and defend your assertions with a team of deeply technical engineers.

2. Do the basics. Make sure you meet an established baseline like PCI, ISO or some other basic security measure. That means ensuring that controls are in use to provide for confidentiality, integrity and availability. That means that you are protecting the data properly during transit, storage and processing. That means that you and/or your client have an idea about how to provide preventative, detective and responsive capabilities around your product. Make sure your documentation clearly explains any security assumptions or add-on products required.

3. Be ready to handle issues. If/When we find a security issue, be it overflows, input problems, and/or best practice variances, be ready to mitigate the issue and submit a fix. Many times it takes months for vendors to handle the issues we find and this is certainly NOT good for their relationship with the client. Almost every full assessment our lab conducts involves some kind of deployment timeline and crunch from the customer. Nothing seems to go worse for vendors whose products we test as when an issue is found and they become unresponsive to us and/or their client. Seriously, JUST DON’T DO THIS. Be prepared to apply resources to fix issues when we test the application. Very few applications (less than 2%) pass through the lab process without some sort of issue. This is NOT a basic process, it is a seriously deep, complex and heavily leveraged process for finding holes and measuring impact. Be prepared.

I hope this post helps both clients and vendors be better prepared for their testing. I think it gives the basic ideas for the approaches that we know do not work. We really want your applications to be secure, thus the level of detail we apply. Let us know if you have any questions. We are also about to open the lab registration window for 1Q09, so if you have applications you would like tested, let us know and we will try and get them on the schedule.