Authentication in a B2B environment

I have had a running discussion with a colleague of mine concerning the use of password expiration for B2B sites. We are talking here about partner sites accessed through the Internet to some type of web portal. My argument was that for a B2B site without mission critical or very sensitive data, it does not make sense financially or from a security perspective to require the external organizations to change their passwords or force two-factor authentication. Let's step back for a minute not to the nine solutions, which are running through your head right now, bit to the question of what we are trying to prevent - the question.

We are trying to prevent one of the following:

• An unauthorized person at the partner organization from accessing someone else's account and information, or performing some type of fraud with someone elses account.
• An unauthorized reckless wrongdoer on the Internet from accessing the partner's information, or accessing the target system and doing bad things that cost money to either side.
• Someone leaving partner firm A and going to work for partner firm B and still having their account active.

There are probably several I cannot think of right now, but let's concentrate on these for a moment, and break them down into several risks and address them.

Risk 1 - password cracking by someone internal or external to the partner firm guessing the password.

If the account locks after several attempts, then this will be largely ineffective, and if it doesn't they would be able to script a password cracker that would most likely break the password long before the password was due to change anyways. That is unless you are going to have them change their password daily (good luck with this one). But just use a token you say, then they wouldn't be able to break their password. This is certainly a good solution for very sensitive data, but for a large group of users it gets very expensive, and usually results in the token being taped to the monitor, perhaps with the code attached to it as well. Certificates are another solution, but are not as portable as most people would like and are a bitch to manage and revoke. The more you force a user, especially someone at an external firm who probably doesn't care much about their own company's security and even less about yours to change their password, the more likely the password will be written down on their monitor, or in the clear in a spreadsheet shared by everyone in the company.

Risk 2 - person leaves partner company A and goes to work for partner company B and their account is not disabled.

If the accounts are disabled after x days of not being used then this will have the same effect without causing heartache, and I would argue less security for the people that are logging in.

For what it is worth, here is my take on this, but I would appreciate any feedback on differing opinions.

1. Force users to pick passwords that are forced to be complex (contain no dictionary words, have a suitable length, Upper/lowercase, special characters, etc.)
2. Disable accounts that have not been logged in for more than x days
3. Lock accounts after 5 invalid attempts
4. Only use tokens for very sensitive sites with a smaller number of end users. Since two factor or ten factor authentication won't prevent the trojan installed on Partner A's system from letting the user logon and piggybacking on that connection the whole way to your site.
5. Audit authentication events and trigger alerts on things like several invalid attempts for several accounts being accessed from the same source, or a large number of attempts in a short period of time

In my opinion we either need to force users to change their passwords hourly or not at all. Passwords are ineffective for truly good authentication, but the alternatives are either too expensive, too difficult to mange or both to make good business sense. Furthermore, the strong authentication solutions are ineffective against today's threat, and their advantages are often circumvented by end users due to their difficulties. We need to make it easy enough for users to use without needing to circumvent the controls in place, and use risk analysis to ensure we are placing controls at the correct points to mitigate the problems mentioned earlier. Additionally, when you look at the reports from the Anti-phishing Workgroup, the FFIEC mandates that went into effect at the end of 2006, that included amongst other items, strong authentication has had no effect on phishing.

Targeted web ads

Charter Communications decided against using advanced web ad technology this week that would have allowed Charter to spy on where users were going on the web, and then sell that data to a company called NebuAd so it could provide targeted web ads to Charter subscribers. Of course Charter made this decision because of an outcry from privacy advocates, customers, and Congress. From what I understand of this technology; it is a device that NebuAd places in the ISP's stream to gather data on it's users, and then uses that data to deliver web ads targeted at what they are searching for and what kind of sites they visit. Unlike third-party cookies that you can control on your PC, these would be completely invisible, and would be controlled by the ISP, and the Marketers at these companies. This should definitely scare you a little, and you should check your ISP to make sure they are not contemplating the same, since it would most certainly be a very inexpensive, if not free way for the ISP to make more money on your traffic, as well as invade your privacy. HTTPS would be safe from the prying eyes of this technology, but even then, they could still tell what site you were on, and it is not beyond belief that an ISP would install a certificate into your browser, and set the proxy to their proxy when the nice guy from Craptastic shows up to install the cable modem, and talks someone into installing their CD, on the grounds that "I can't install the modem unless you run this". Once the certificate and proxy was configured, it would allow them to peek into the HTTPS traffic. Marketing folks will say that this is not a big deal, and they are improving the experience for people by only delivering ads they are interested in, but what if a computer is shared and the previous person had been researching medical conditions, mental health information, or some other private matter.

#$%^&*!

Sorry, I fell off the soapbox, and it is getting late.

Security Requirements for Software Development

I bought a new car last year, and being the way I am, I had a list of requirements and repeatedly ran sever cars through the requirements list until I narrowed it down to 5, of which I made my final decision. Things such as: it had to have 4 doors (for the princesses), it had to do 0-60 close to 5 seconds, it had to handle well, look good, and have lots of cool toys inside to play with. Some of theses requirements are easy to evaluate, while some are more subjective. Which brings me to the Information Security connection. In software development projects we are always asked to provide security requirements to the devleopment team that is either in-house or contracted.

"Make sure there are no vulnerabilities that can be exploited" is always one of my favorites, but it is a little vague, and they always seem to want something more concrete. Over the years, I have kept a running list of the items I usually include in those security requirements, so for those of you that are interested, I am including it here. The list is derived from things I have seen in projects and a lot of great external sources such as OWASP, Common Criteria, etc. This list is not meant to be an exhaustive or comprehensive list, but a list that can be used as a base to draw upon when completing these types of requests. you will still need to perform threat modeling, and in depth analysis of the project, and to check that the requirements are being met in the SDLC. If anyone has any updates, suggestions, or corrections, please let me know, and I will update the list.

The link below directs you to a Google Docs page with the doc.

Security Requirements

Thanks

Software vulnerabilities and updates

The Flash vulnerability last week that was initially thought to be a zero day, but was eventually categorized as a known issue that was already patched in the latest flash version got me to thinking. I know what you are going to say, and yes there was initially some smoke, and a slight headache, but eventually I recovered. OS patches are usually up to date on all of my systems, but there are so many ubiquitous applications on systems that there should be an easy way to check if they are up to date. Well Secunia has one. For those of you that don't know about this organization, they have for several years now delivered top notch vulnerability and patching information for any OS or application I can think of for free. Now they have leveraged that database of known insecure programs into both a personal and corporate edition of what they call a software vulnerability scanner. The personal edition is free, and uses their database to check applications on your computer to see if there are known vulnerabilities. The software does not perform a vulnerability assessment, it checks for known vulnerable versions, and in most cases provides a link to download the latest version. The software tries to launch in startup by default, but this is easily changed. Give this a try and you will probably be amazed at the vulnerable applications residing on even the most up-to-date system.

Crane collpases and Information Security

There was another crane collapse in NYC today, killing one person and critically injuring two others, according to CNN. This brings the death toll to 8 people in the last two months just in New York City due to crane collapses. These events are tragic, and they make the issues that we as Information Security and Privacy professionals seem minor by comparison. However, there is a connection between the people in New York that strive to reduce these types of incidents and us. Somewhere in the various departments and agencies in NYC that regulate and inspect these cranes, there are probably several people who have made the argument time and time again that they are understaffed or under budgeted, or that there are not enough controls in place to prevent these types of incidents. Unfortunately, it takes one of these incidents to obtain increased funding and controls that should have been in place in the first place. The same thing happens in InfoSec and Privacy. We all tell management (and anyone else who will listen) things like:

We need to install x to reduce the risk of y
We need to do x to minimize the risk y
We need a review or addition of controls
We need more staff
We need more budget

Unfortunately, it takes an incident like this to produce change and to get enough attention on a topic that something is done. There is one other constant between these subjects. Whether it is a crane collapse, or a DNS takeover for a giant cable provider - there will be a fall guy to blame for both of these.

Rock On

Stupid security trick of the month

The following story was reported by the Memphis News. Hopefully, some lawmakers in Nashville will ask their 12 year old about the Internet before creating anymore useless legislation that deals with technology.

[Memphis News]
Starting July 1st, Tennessee sex offenders are required to report their e-mail addresses, user names, and screens names to Tennessee’s Sex Offender Registry. Lawmakers created the new requirement for sex offenders during this year’s legislative session in Nashville. Police say the requirement will make it easier for them to spot sex offenders trolling for prey online.

Anti-virus not keeping up?

According to Panda Software there was a tenfold increase in the number of new malware strains detected in 2007 compared to 2006. More than 3,000 per day were detected in 2007. I don't have to tell you that with that many new malware strains, each day that your A/V software will, well, "strain" to keep up. The days where A/V signatures could be updated daily, or every couple of hours are simply gone, and even if you could update them every 5 minutes, the signatures simply aren't there to cover all of the new threats. Never mind the impossibility of updating signatures across thousands of systems on a network constantly. Some companies are working on behavioral based A/V like ISS. They take all of the common traits found in viruses and malware and try to stop the code based on behavior. In theory you would then only have to update the behavioral signature when a new malware strain does something you have not seen before. Almost all of the thousands of new malware strains a day do basically the same thing, but thanks to morphing and subtle differences, they are not always detected by traditional signatures. The behavioral model is not perfect either, since it suffers from false positives, just as IDS/IPS signatures do.

So what to do?
Defense in depth is called for here.

Systems need to be patched to minimize the attack surface
System administrators need to minimize the places users can get one of these files through the web, e-mail, IM, etc. by using content filtering.
Reduce or remove the number of local administrative users
Watch what is entering and leaving the network
Run IDS/IPS on endpoints as well as the network
Run A/V and update it often
Watch for registry changes
Run virtualization, so cleanup becomes much easier, and infections become temporary (hopefully)