I just got back from The Credit Union Information Security Professionals Association 3rd annual National event in Austin Texas where Rohyt and I were talking to the folks about www.PhishMe.com.
I have never attended a CUISPA event before and welcomed the opportunity. It was refreshing to see this industry work together. Credit unions don’t have the budgets larger institutions do and many of their technologists wear multiple hats. Security is a group effort. (as it should be)

Two major takeaways I had from the conference:

1.) Credit Union security professionals have a can-do attitude and value networking with their peers to solve their security woes
2.) Don’t show up to a Credit Union event dressed in New York-Financial attire (unless you enjoy looking like that creepy sales guy)

On the heels of the CUISPA event is a good white paper I saw on BankInfoSecurity.com titled The State of Information Security 2008 - Survey Executive Overview (Free signup)

Tom Field (Editorial Director) did a good job putting the overview together. The top security issues I heard the Credit Union folks discuss are the same ones captured in this survey. (It’s good to see that this paralleled what I saw in person at CUISPA … too often these days a whitepaper is just a synonym for marketing fluff.)

Of course the #3 issue “3) Training - Employees, Customers Need More.” grabs our attention as our http://www.phishme.com/ moves from beta and inches towards launch.
I’m beyond excited.
-higB

p.s. If you happen to attend my ShmooCon 2008 presentation please be kind with the Shmooballs.

I always knew I loved SSH keys. Often, my love was for the convenience factor and that warm feeling you get from authenticating with 1024 bits of encryption goodness. But tonight I’m marveling in the simplistic setup beauty these babies can give any Unix/Linux sysadmin. Most of us have had to play the role at some point of setting up the FNG on the shared linux box. We create the account then email him/her some version of their password and hope they actually login at some point to change it. Any brute force password list worth its weight in electrons has a few versions of the famous “ChangeM3” password. I’ve also been hesitant to ever disable password authentication in my sshd_conf since I thought I’d have to flip it back on anytime there is a new user.

From this ugliness comes my new reason to love SSH keys. Lets change the policy for creating new accounts to require that your noob first sends you an SSH public key (send them off to get PuTTYgen if they don’t already have one). Remember, this is their public key so it’s totally cool to be sent over clear text, or simply posted on the internet. Now as the sysadmin, add their account and drop off their public key in their .ssh/authorized_keys file.

What does this solve? No more login passwords in clear text over email or IM. No more worrying about the FNG changing their password. No more brute force SSH concerns. And for an extra bonus, if I’m the FNG, now I have one less password I need to remember because before, I was setting a unique password on each box. Hey, you never know when your admin might decide to run john the ripper on the shadow file.

When you’re ready to take the plunge and have your own keys in place, the lines you’ll want in your sshd_conf file to require keys and disallow standard login passwords should look something like this:

…snip…
RSAAuthentication yes
PubkeyAuthentication yes
ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no
…snip…

-b3nn

1. I would be very busy the week of Christmas, while IT security staff is probably operating at 20% normal strength. Not only is it the weakness in numbers, but also the holiday mood.  How many of you are actually working full days? IDS logs - thats probably the last thing on your mind now that you have Guitar Hero III in the breakroom.
2. I would get busy if I heard that a company was being acquired. From my experience, most companies put a freeze on all discretionary spending from the time a deal is announced untill it closes. Unfortunately, security is often thrown into that discretionary spending budget, making it easy on the bad guys for several months!
3. If I really wanted to spend Christmas with my family, I would just come back another time and phish employees…that works irrespective of season.

Wishing you all a very Happy New Year! Stay safe.

-Rohyt

Here at Intrepidus Group, we do a lot of mobile application security reviews.  Much like standard web application reviews, some clients consistently turn out very secure apps.  However some apps have a detailed finding list longer then a copy of War and Peace.  One trend can often be seen across applications regardless of the client’s understanding of security.  Mobile applications, at some point of their process, typically rely only on a phone number and short numeric pin for authentication to a remote server.

We’ve all know that weak passwords are one of the easiest way on to a system. If you let users have the option of choosing a secure or weak password, they will often take the easier to remember, less secure choice.  I would say most major web based applications now require users to choose passwords with at least 6 characters, using mixed case and at least one number or special character.  Typing in complex passwords with your standard QWERTY keyboard isn’t such a problem, but can you imagine trying to multi-tap some of your complex passwords on a 0-9 keypad? And into a stared out password field? It’s somewhat understandable that most mobile apps only require a numeric pin for authentication.

The problem of course is that most of these server side components can’t be limited to only allowing access from mobile devices (break out your old school User-Agent hacks and give some “.mobi” addresses a try). Limiting access to restricted IP address pools usually don’t help either and typically is a nightmare if client is supporting multiple providers. So in almost all cases, you have to assume an attacker can easily script a brute force attack against some part of the authentication (with mobile apps, it’s typically not just the front door login, but also a web service burried somewhere in the site that will handle authentication).

What’s a mobile vendor to do? CAPTCHAs, you say? Some of these are barely readable on a 22″ monitor. Good luck figuring out that text on your 1.5″ Nokia screen.

Account lockouts seem to be a reasonable recommendations at this point. But even with a low number of attempts (lets say 3 just for fun), I bet I could script something to get into at least 25% of your user base. What are these magic pin numbers?

1234, 5555, 1111

Yup, that’s some 13373 H@x0r shiznit right there. And if I have more login attempts, lets try the last four digits of the mobile number as the pin. Oh, that mega-hurtz now!!! For the sake of security, we need something stronger than an all numeric pin. Maybe it’s in the form of one time token over SMS, or maybe just a decent password multi-tap box for now (I saw this well done on the Blackberry Pearl recently). If you know of any other good solutions to this issue, drop us a line. I’ll be talking about this and more mobile security issues next week at the NJ/NY OWASP meeting.

-b3nn

If you’ve been noticing a little silence on the blog recently, it’s been because a lot of the ranting has been going into developing what we think is a great anti-phishing user awareness tool. Take a peek at our main site at www.PhishMe.com

Conducting ethical phishing attacks has never been easier. User awareness will be improved, enforced, and for the first time for many users, easy to measure and trend over time. You can sign up for the mailing list right now that will let you know when the full blown service is launched. We will be offering free trial accounts that will allow you to get a taste of the features and test out if a few of your users will bite.

Another key feature of PhishMe is the built in templates to make your job of crafting phishing attacks simple yet effective and modern. How do you think your employees would respond to a message about a “virus outbreak”. Will they just follow the instruction in an email without verifying any of the information? What about a message to update their HealthCare information on a new third party site? The number of people that fall victim to these types of attacks will make you wonder why hackers even bother with anything that isn’t social engineering.

There is more to come in the future but for now, check out www.PhishMe.com

-b3nn

A recent survey of over 279 IT Executives indicated that the greatest security challenge they faced was building an effective security awareness program and encouraging their employees to embrace it.  Employees, albeit unaware, oblivious or unconcerned, continue to fall prey to conniving social engineers compromising sensitive data protected by millions of dollars worth of technology. The return on investment on building user awareness is apparent and no longer a hard sell for IT security staff. The real problem lies in building an effective program that actually changes the mindset of the employees.  In a society where 90% of recovering coronary bypass patients do not change their dietary and lifestyle habits, will an awareness program really change their attitude towards information security?

This year we conducted numerous social engineering exercises for Fortune 500 companies, whose success relies heavily on the protection of intellectual property. These exercises involved scripted telephone calls to the organization’s customer service departments and mass phishing emails targeting a randomly selected set of employees. The objective was to collect sensitive data; the results were astounding. At one organization, 627 of the 1000 people targeted by phishing emails (aimed at pilfering the employees’ corporate VPN credentials) succumbed to the attack and only 4 of the 373 that did not respond reported the issue to information security staff. It’s not so much those statistics that made the results astounding, but the fact that the organization had recently conducted user awareness workshops that addressed the threats posed by social engineers. So where did they go wrong? Are the information security personnel to blame for developing ineffective programs or the employees for their lack of following direction? I believe it’s a combination of both; but the information security staff must assume the onus of taking the initiative of developing innovative user awareness programs that make a lasting impression. The majority of the security awareness sessions I’ve attended whave been unstimulating affairs couching the do’s and don’ts of security. Another approach used involves mandatory computer based training (CBT) programs for employees.  At the end of the CBT session the employees had only improved their mouse-click speed. On the other hand, an approach I’ve found to be very successful entails sending out email to all employees (or to a representative sample of them) that mimics a true phishing attack aimed at garnering personal information. If the employees yield, they are immediately presented an informative message explaining the attack and redirected to the corporate awareness materials. This approach has proven to be very effective as the people who are most vulnerable are educated right away, and the next time a real phishing attack comes through, the emulation exercise will probably be the first thing that comes to the employee’s mind. One of our clients experienced a drop in the “hit rate” for such attacks from 67% to 4% over the course of three such phishing exercises!

-Rohyt

As a security consultant with exposure to many large enterprises I admit I’m biased to RSA SecurID tokens. During penetration tests, our company has cracked tens of thousands of passwords. When I’m standing in front of a customer explaining why their password policies failed, they want to believe that changing this policy will help them. Secretly I know that humans will defeat the spirit of any password policy and that the best approach is to take the responsibility of password composition away from the end user. (When you stare at thousands of clear text passwords you develop a cynicism.)

August2007, you’ve been a good password, but it’s time I move on to owning enterprises with September2007.

The other day a friend asked me if there are any other products like SecurID he should be evaluating for his company as part of their plan to introduce two-factor authentication. Apart from SecurID the only other device that left me thinking “Hey this thing works” is Vasco’s Digipass. Any two factor system worth its weight in salt should provide authentication hooks to the popular services. If you plan to use the solution with custom web applications, you may need to dig a little deeper…maybe a lot deeper. Most solutions have hook-in APIs, but it takes some effort to piece it all together.

If you are evaluating two factor authentication devices make a list of the top services you need authentication for:

• Network devices
• Windows authentication
• Unix authentication
• VPN users
• Wireless user authentication

If a solution can cover 80% of your authentication needs and is cost effective, go with it. 80% coverage is 80% better than letting humans pick passwords; chances are with a little effort and creativity you can put something together to rein in the residual 20%. If you don’t have a two-factor solution, evaluate Vasco with the others.

-higB

   Brad Kenney interviewed me about the unique information security challenges faced by manufacturing companies. Excerpts from that interview can be found in his IndustryWeek story -  From ID to IP Theft.

Moral of the story: Large employee bases whose skill set is not in technology, coupled with fragmented operations make the job of an information security officer in the manufacturing sector very challenging.

-Rohyt

Build that trans-continental security bridge!

While pen testing applications for one of my clients,  I found that all the security issues I identified had the same 2 or 3 systemic causes. I made “strategic recommendations” - security training for developers and a security-aware SDLC, to name a couple. Months later, I went back to the same company, this time to test a bunch of other applications. The outcome wasn’t too different – same systemic problems. Once again, I emphasized the trend to my client. He told me that the applications were developed offshore, so my strategic recommendations from the last review were “impractical”. What could my client do to fight this negative trend?

Over the years, I’ve had several discussions on this topic with security gurus, software developers working in offshore companies, and some folks at the receiving end of insecure code. The situation is best described by the everybody, somebody, nobody and anybody joke. In short, no one has taken the initiative on the security front. What can everybody do?

Firstly, the outsourcers need to be willing to PAY FOR SECURITY. Yes, security doesn’t come free. This shouldn’t really be an issue given the tremendous savings realized by offshoring. But don’t just pay for security, demand it contractually. Just like you define performance metrics that the applications should meet to be accepted, define and enforce security metrics. Ensure that the terms of the contract are enforceable in a jurisdiction in your country (the outsourcer’s country). Suing the development company in their country will be a frustrating and futile endeavor at best!

Secondly, find out what measures your offshore partner takes to protect your data, to educate their developers on security, and to implement security in the SDLC. Remember, an ISO audit doesn’t cover all these areas.

Now for the offshore development company – use security as a competitive advantage. The last time I said this to some friends of mine who work as developers in India they said “We need VP approval to add even an optional line item in a proposal”. We all know what that means.

If you want to hear more on this topic, you can hear the recording of a webcast I did with Watchfire:

https://www.watchfire.com/securearea/seminararchives.aspx?id=253

-Rohyt