Recently, while we were discussing a contract, an industry executive needed me to give an explanation of the difference between a “security audit” and a “penetration test.” The party with whom the executive was negotiating the contract had changed the contractual requirement from the one to the other. Since this might be of interest to others, I’ll provide the explanation here on the blog.

The short explanation is that a “penetration test” is just one small component of a “security audit,” and that the software / service provider was aiming for a much lower bar than we were aiming for on behalf of the executive and her MLS. Following is an explanation of how much lower it is.

A penetration test is an attempt to find weaknesses in the defenses in a computer system’s security. Sometimes the term is used in reference to non-computer security, but typically not. The test usually consists of a combination of automated and manual testing to find specific attacks that will enable the attacker to bypass certain defenses, then working to find additional vulnerabilities that can be found only once those initial defenses are defeated. As a result of this testing, risk can theoretically be assessed and a remediation plan put in place. One can also evaluate how well an organization detects and responds to an attack.

One significant problem with penetration testing is that, if the system being tested has good outer defenses, a penetration test may not find security risks lurking inside of the defenses. It may then present as its finding that risk is low and no action is needed. Then when there is a change to the outer defense that causes a vulnerability (or a vulnerability is discovered in that outer defense) actual attackers will breach all of the inner layers where security has not been well designed. It’s a well-known principle of security design that one designs multiple levels of security (a/k/a “defense in depth”). Penetration testing, on its own, doesn’t reliably measure whether this has been done properly.

For the more technical readers, I will provide an example:


The other problem with using a penetration test as the sole way to measure security is that information security is a much broader area of exploration, normally measured during a full security audit. Most of the breaches we’ve had in this industry have been the result of weak policy and procedure or the contracts that reflect those policies, inadequate human resources practices, and physical security issues. Still other technical security issues have resulted from a lack of protection against screen scraping, and yet others from authentication related issues – both items that most penetration testing tools cannot easily uncover. Looking at the security configuration of network equipment, servers and workstation operating systems, platforms, and installed software, mobile devices, antivirus, printer and copier configuration (yes, I really said copiers!), password selection, backup practices and so much more – all of that falls outside the purview of typical penetration testing and is only reliably addressed via a full security audit.

There’s nothing wrong with using a penetration test as a part of a security audit – just don’t mistake the part for the whole.

The Groundbreaking Definitive Paper on the Subject

Ongoing bad publicity related to real estate transaction wire fraud threatens to damage the reputation of the real estate industry. Previous issue descriptions have been incomplete and have also not provided thorough guidance for those brokerages, title companies, attorneys, and others that engage internally in the wiring of funds or interact with the consumer regarding wire transfers. This paper provides information relevant not just for those directly establishing and communicating wiring instructions, but also for those just acting in an advisory role to the consumer during the transaction.

The paper includes best practices – sample procedures and communications gathered from franchises, brokers, title companies and others. It also includes a sample company policy Clareity Consulting has created based on both these best practices and on our experience advising brokerages and other companies regarding information security. Not all aspects of this paper will apply to all companies involved in the transaction, and what is relevant will still need to be tailored to an individual company’s business processes. Still, it provides a valuable starting place toward reducing the risk of wire fraud.

Please download the paper here:
Reducing the Risk of Real Estate Wire Fraud

Don’t Be Afraid of the ‘Audit’

Information security laws are still a patchwork nationwide, but an increasing number of industry organizations are finding that they need our assistance to comply with laws and other applicable requirements. The purpose of this post is to help demystify the process.

Many industry organizations are just realizing all of the requirements that apply to them. For example, the latest Payment Card Industry Data Security Standards (PCI DSS) now require compliance even from organizations that outsource their e-commerce transaction-processing functions to a third-party service provider, but where the organization’s website controls the redirection to that provider. Understanding those types of compliance requirements, as well as those mandated by federal, state. or provincial legislation, is a starting point for any assessment.

A lot of clients take comfort in my approach to assessing security. For many organizations, especially for the IT people, a security assessment can seem daunting. What if issues are found? Will we look bad in front of the assessor? All I can do is assure clients that I’m there to help, not to judge. Yes, typically issues are found, especially if it’s an organization’s first assessment or if they haven’t had an assessment in a few years. Finding issues is simply the first step toward addressing them. Some assessors spend most of their time by themselves using their assessment tools, then presenting a report that feels like an adversarial “Gotcha!” to clients. I take a very different approach, one where I’m working alongside my client, using tools and checklists in collaboration with them. This has some important benefits. Without there being any surprises at the end of the assessment, there’s less of an adversarial feeling. Also, by educating my client in the use of common and free (or inexpensive) assessment tools and other security resources, they become empowered. IT staff are left feeling more educated and valuable, rather than feeling defeated by an outsider finding issues. The best part is that, by empowering my clients to be able to perform at least some level of ongoing self-assessment, they are more likely to maintain better security in the long run.

Before the visit: Typically, I schedule two to three days for a visit with my client. A few weeks before the visit, I ask for any security-related information the organization might have: a list of websites and apps, information security policies (usually a part of an employee handbook), a list of third-party service providers and parts of contracts that are relevant to security, and the office and data center internet address (IP) ranges. If some of that information isn’t available, that’s okay. If I’m going to do any testing of applications hosted by third parties, at that point I need my client to coordinate that testing with their service provider. Then I review the materials provided and perform some initial “external” testing prior to my visit. If assistance with PCI DSS compliance is requested, I work with my client to start that process as well.

During the visit: I like to start discussions with management – looking together at staffing practices, physical security, policy and procedure, contracts, and other less-technical aspects of security. Then I dive into the technology with the staff (or sometimes contractors) who are responsible for managing it. Together, we’ll look at everything from routers and firewalls all the way down to the operating systems, and everything between. If PCI DSS compliance is in progress, we will review any outstanding questions my client needs assistance with. At the end of the visit, if everyone is available, I like to bring everyone involved together to discuss findings and the process of planning issue remediation.

After the visit: Sometimes there are subsequent discussions of findings after the visit. Also, I provide a lot of phone and email support and follow up, to ensure that the organization is efficiently moving forward in their efforts to improve security and to answer questions that arise along the way.

Hopefully this post has demystified the security assessment process. When it comes to information security, our industry has a lot of work to do. I benchmark the industry regularly in a number of ways. One small measure I take is “What percent of websites are running on known insecure web server platforms?” My present benchmark for that measure is: 28% of the top 50 MLSs (by subscriber count), 46% of the top 50 brokers (by transaction volume), 40% of top local associations, and 35% of our state associations. That measure is just the tip of the iceberg, too –again, there’s a lot of work to do! Contact me (612-747-5976), and let’s start working on it together.

How Many Times Must a Tech Provider Download the Same Listings?

I received a call recently from an MLS administrator who wanted to talk about a RETS issue that had been bothering him. His MLS charges a small fee to subscribers for a RETS feed; the fee covers the costs related to the feed, including compliance audits. He was noticing that many of the RETS credentials that subscribers were paying for weren’t being used and thought this was a bit of a mystery. Should he disable the unused RETS credentials and stop charging the subscribers? That course of action would make sense if his subscribers truly no longer needed the data. But there was a more likely culprit behind most of his mystery.

Quite often a subscriber’s RETS feed isn’t just associated with the subscriber, but with a third-party vendor providing IDX, VOW, CMA, statistics, and/or broker back-office systems to multiple MLS subscribers. Let’s say the vendor has downloaded the IDX data on behalf of one broker. If the vendor has 19 more customers associated with that MLS, does it really make sense for the vendor to download and store the data 19 more times, using the additional 19 RETS credentials? That seems like a real waste of server, bandwidth, and storage resources. On the other hand, suppose the vendor re-uses the credentials. Further suppose that the MLS administrator turns off unused credentials, the subscriber whose credentials have been used by the vendor to download data goes inactive, and his or her credentials are disabled by the MLS. The flow of data to the other 19 websites will be cut off. That’s not good!

Besides the potential for data disruption, there are other reasons why an MLS administrator may not like re-use of credentials:

1.    Credential re-use takes authorization control out of the hands of the MLS. If the vendor doesn’t know that a subscriber whose credentials they aren’t using has gone inactive, the vendor may accidentally service him or her using data obtained using another subscriber’s credentials.
2.    Similarly, re-use may defeat opt-outs for individual uses.
3.    The problem is actually even more complex if the vendor has multiple products. The vendor may download a superset of all data they need for a broker back-office use. Then, by re-using a subset of the data for an IDX site, the vendor may accidentally use fields and listings in certain statuses that would not normally be available to the IDX feed, inadvertently using the data inappropriately.
4.    Credential re-use partially defeats the use of data seeding, i.e., trying to figure out where exactly there’s a data leak.

Having unpacked some of the issues, there seem to actually be two questions regarding RETS credential re-use that need to be considered:

1.     Is it okay to re-use data feed credentials for multiple parties with the same use?
2.     Is it okay to re-use data feed credentials for one or more parties with different uses?

So, re-stating the conundrum simply: it’s terribly inefficient for all parties when vendors download and store multiple copies of data, one for each customer and credential, but there are valid reasons why MLSs have looked negatively at the practice of credential re-use. How do we solve this for everyone?

There are several possible ways to address the authorization control and opt-out issues including, but surely not limited to, the following:

The vendor can log in using all MLS-provided credentials at least once per day to figure out what subscribers no longer have rights to use data based on RETS login failure. They won’t download data with each login, just for one of them. But this way, the MLS will have a record that the vendor has checked whether a login / use is still active on the RETS server and should have taken steps to eliminate data use for that subscriber.

The vendor can be given a RETS login by the MLS that gives the vendor access to the roster, limited to a subscriber identifier and status (active, inactive). The vendor can use this to check if they need to stop re-using credentials on behalf of a specific customer.

RETS standard and server functions can be designed to return validation codes for all authorized specific MLS users and uses based on a single login credential, and return data based on that information. This will directly reflect the kind of master agreements and addendums that many MLSs have with these vendors already. If no MLS users are active and related to a vendor credential, the vendor credential will not provide data access.

The inappropriate data use issue is a bit trickier. It is an issue that can be mitigated today to some degree via very clear license agreements, vendors being careful to use the data subsets as specified by those agreements, and by MLSs auditing the end-uses of the data (i.e., the IDX websites and VOWs) – something they should be doing anyway. Additional mitigations may require some RETS standard and server-side function enhancements. For example, additional usage opting information can be passed to vendors where relevant. Also, a server-side function could be created to efficiently determine whether several credentials provide different data for a query – without downloading and comparing the data to the data on the client side. Knowing that different credential use would provide different data may make it easier for a vendor to know whether re-use is appropriate or not.

I don’t think there’s a way to fully resolve issue the data seeding issue while allowing credential re-use but tracking an issue down to who received the feed is still possible. Vendors just need to cooperate with any seeding investigation to help figure out what specific usage is involved. Data seeding is only of use in a very limited subset of illegitimate use detections anyway.

There are more conversations to have on this subject, looking at additional business and legal issues as well as technical reflections of those issues, but this is a starting point. Let’s figure this out, so that RETS service can be efficiently provided to stakeholders while addressing legitimate issues that arise with that efficiency. What’s next? Let’s discuss these and other ideas for solving the issue here on this blog, on Facebook, and perhaps at the upcoming RESO meeting and see if some consensus can be reached among both vendors and MLSs. If changes to RETS are desired, this can be dealt with in RESO workgroups and implemented by vendors as need be.

I know many vendors that simply must engage in credential re-use so they don’t overwhelm MLS RETS servers and so they don’t needlessly increase their costs to service multiple customers – but they don’t like being in violation of some of their license agreements with regard to credential use. I’ve even had clients fine such vendors – and while this is in accord with the letter of some current license agreements, it’s really not fair. These are not “bad vendors.” By not defining our standards, process and legal agreements to reflect the technical reality of data aggregation and use, we’ve created this ugly issue together. But together, we can solve it, and we should do so as quickly as possible.

As a consultant often called on by MLSs for help with VOW and IDX compliance audits as someone who is always pushing for improved information security in the real estate industry, I love that information security is featured prominently in the VOW rules, section 19.5: “A Participant’s VOW must employ reasonable efforts to monitor for, and prevent, misappropriation, ‘scraping’, and other unauthorized use of MLS listing information. A participant’s VOW shall utilize appropriate security protection, such as firewalls, as long as this requirement does not impose security obligations greater than those employed concurrently by the MLS.” The last part of that rule is also reflected in optional IDX rule section 18.3.14. Auditing these rules has allowed me to help many brokers improve their VOW and IDX security and reduce the risk of an information security incident.

I’ve already written about guidelines for anti-scraping and monitoring and, although anti-scraping is a constantly evolving challenge, that article provides at least a baseline for evaluating VOW rule compliance.

But, what else should MLSs be looking for when evaluating VOW and IDX security?

First, as specifically mentioned in the rule, appropriate firewall protection must be established. When I audit a VOW, I look to make sure that there are only a few specific network ports open on the server – 80 and 443 as needed for the web server to function, and ports needed to provide a secure method of server administration, such port 22 – or 989 and 990. If ports like 21 and 3389 are open and actually used to administer the website, it should be a big compliance red flag because they are common security incident causes – and issues I see the majority of the time when auditing a VOW or IDX site.

Second, you want to verify that all the web server software is up to date and properly configured. That means checking the web server (IIS, Apache, etc.) version, the operating system version (when possible) and the platform (.NET, JSP, ColdFusion, WordPress, etc.) version, making sure that those are the most current versions or that newer versions don’t have fixes for significant security vulnerabilities. You might think that keeping systems patched would be second nature for a technology provider, but in my experience, it seems not to be the case.

Third, you want to evaluate any externally obvious security misconfigurations of the server and platform. Every server and platform has its own security configuration guidelines and it’s reasonable to expect that obviously poor configurations should not be visible to an external evaluator.

Fourth, and probably the most complicated part of evaluating VOW security, you want to evaluate application security – at least the OWASP Top 10 Vulnerabilities: Injection, Cross-Site Scripting (XSS), Broken Authentication and Session Management, Insecure Direct Object References, Cross-Site Request Forgery, Security Misconfiguration, Insecure Cryptographic Storage, Failure to Restrict URL Access, Insufficient Transport Layer Protection, and Unvalidated Redirects and Forwards. I usually evaluate Information Leakage and Improper Error Handling as well. Some of these items can’t be easily validated externally (i.e. Insecure Cryptographic Storage) though I’m always glad to hear that a web developer has encrypted the passwords and so cannot technically be compliant for VOW rule 19.3b. (“The Participant must at all times maintain a record of the name, email address, user name, and current password of each registrant.”). I’ve seen every one of these OWASP vulnerabilities while auditing VOWs and many times there are half a dozen issues on a single VOW.

If you’re a staff person at an MLS and a lot of the preceding read like gobbledy-gook to you or you don’t know how to audit security, you may want someone like me auditing VOWs and IDX sites for you, or at least auditing the security and anti-scraping related portions. It has been a blessing for the industry that the VOW and IDX rules give MLSs the opportunity to ensure that at least some reasonable security best practices are in place for VOW sites. I’ve had brokers tell me they were actually grateful someone was keeping an eye on their technology provider in this area, since they lacked the capacity to do so themselves and just figured that all appropriate measures had been taken.

Please keep in mind that website security is the smallest portion of overall brokerage security. Taking appropriate steps in terms of policies and contracts, physical security, account management and password controls, internal networking and computing, mobile device security, and internal web applications are all important. The NAR sponsored security workshops and security articles and blogs that I write, and which many MLSs and Associations reprint, are helping me reach some brokers and agents – but it’s a very difficult task to try to improve information security in this industry and I hope that I can count on my readers to act as security allies and spread the word.

How Does YOUR IT Guy Respond to a Security Audit?

Just last week I was interacting with four organizations regarding significant information security vulnerabilities I had identified. Each had a dramatically different reaction to the news that they had issues to deal with. It reminded me of the Jewish Passover Seder (ritual feast), during which the participants discuss, in elevated language, “Four Children” – the wise, the wicked, the simple, and the one who does not know to ask. So, here are the Four IT Guys:

The Wise IT Guy

The Wise IT Guy is thankful for having a skilled resource helping assess his systems and is instantly attentive when he finds out he has a vulnerability to address. He is not defensive – he knows that even the biggest companies with the most resources have security vulnerabilities and, at some point, his organization will too.

The Wise IT Guy asks, “What are the vulnerability vectors and what are the best ways to defend against the problem?” And you shall answer the Wise IT Guy thoroughly, carefully describing all of the best practices and methods of deployment.

And the Wise IT Guy will use commercially reasonable best efforts to address the vulnerability, seeking it out throughout his organization and creating a plan, balancing the need for speedy remediation with the requirements of proper testing and deployment practices, including post-deployment testing.

The Wicked IT Guy

The Wicked IT Guy is against having anyone look at his systems in the first place, putting the audit off as long as he can, and placing his own fear and/or arrogance ahead of the good of the organization. He doesn’t take the vulnerability seriously and thinks he knows better than security specialists – he hasn’t been hacked yet, right? He knows he can baffle his CEO with BS and maybe talk his way out of dealing with the vulnerability.

The Wicked IT Guy responds to the news of the vulnerability: “What is this vulnerability to you? How likely are we to be affected by it? Will taking the steps you recommend make us perfectly secure?” In asking these questions, the Wicked IT Guy is isolating himself from well-known security best practices. Rather than taking the simple steps to address a vulnerability, he would rather spend that time rationalizing his own inaction. There’s no such thing as “perfectly secure,” but at home the Wicked IT Guy still locks his door on the way out – he just won’t take the obvious and simple steps to protect his organization.

Therefore, he must be rebuked with the explanation that, “These recommendations are made so you can comply with your organization’s information security policy.” By referring to the company’s policy, one is none-too-subtly letting him know that information security is about more than “IT”, and if he flouts it, he might find himself dealing, in his last meeting as an employee, with another two-lettered department, “HR.”

The Simple IT Guy

The Simple IT Guy asks, “What is this vulnerability?” and you shall carefully explain the steps to remediate the issue, offering to have calls with the vendors and contractors he will no doubt need to get his systems out of trouble. The Simple IT Guy usually means well, but will then sit, perhaps transfixed by the blinking lights on his computer, and do nothing. The Simple IT Guy will worry about the issue once in a while but not take action. Sometimes the Simple IT Guy has some smarts but does not understand how to balance information security with his other responsibilities. Either way, the CEO will usually need to be re-engaged regularly to make sure progress is being made to address the vulnerability. Unless the CEO is forceful about getting it fixed and engages help for his Simple IT Guy, the problem will likely persist.

The IT Guy Who Does Not Know to Ask

So far we have seen the Wise IT Guy who is both intelligent and pious about his security responsibilities, the Wicked IT Guy who is intelligent, but, let us say, impious or unwise about organizational security, and the Simple IT Guy – who means well, but lacks the capacity to manage all the technology with which he is entrusted. The IT Guy Who Does Not Know to Ask for help with information security is both unintelligent and foolish. He doesn’t understand the need for assessment and has neither the interest in nor the capacity to respond to security vulnerabilities when they are identified. This IT Guy is all about letting the issue drop – he hopes your first email on the subject will be your last, and that his luck in not getting hacked – or no one finding out about it –holds up. As with the Simple IT Guy, the issues will require thorough explanation of the vulnerability, but you may need to get his CEO to impress his duties on him in order to overcome his foolish nature – otherwise security vulnerabilities will surely persist.

So, as for The IT Guy Who Does Not Know to Ask, you shall say unto his CEO, “This is what your IT Guy needs to do for you in order that you may be more secure. And we must review progress regularly to ensure this is done.”

Working Toward Redemption

An organizational approach to information security is not rocket science – most of it isn’t even computer science. It starts with management making the commitment to best practices and engaging in assessment (auditing) and re-assessment. When I conduct an audit, I’m probably going to find issues. That’s normal, and it doesn’t make me lose any respect for the organization being audited or its employees. Where I do lose respect for some people, especially IT people, is when their response to the prospect of an audit or the results of the audit is poor and does not serve their organization well. As organizations, it is management’s responsibility to keep a watchful eye and, besides paying attention to the non-technical aspects of information security, make sure that The Wise IT Guy is on staff. If not, that liability must be mitigated in some way so that the organization is taking reasonable steps toward good information security practices.

Strong Authentication Needed to Protect Against Login Credential Sharing and Theft

Introduction
MLS data is the core asset of the real estate industry, and it is crucial that it be protected. An increasing number of MLSs and real estate companies have asked Clareity to research online system access control and data protection methods in order to come up with security solutions that are more reliable than the current username-password mechanism. Unauthorized system access and theft of data has become a national epidemic due to lax password-only security.

Over the past two years, Clareity has performed significant research on data protection and user authentication (system access control). We first presented “strong authentication” as an important security component for MLSs to consider implementing during our presentation at the Council of MLS meeting in 2002 and at subsequent Clareity Workshops. We believe it is now time for the industry to take action to improve its lenient security practices.

To quote Bob Butters, Partner with the law firm of Arnstein & Lehr, Chicago, IL (formerly Deputy General Counsel at NAR and a lawyer with the FTC):

“Unauthorized use of Participant access codes can lead to MLS liability and loss of MLS’ valuable proprietary rights. Not only can the economic value of the MLS’ database compilation be undermined, but non-public showing instructions falling into the wrong hands can lead to MLS liability for personal injury and property damage.”

The following pages:
•    Explore the security issue facing real estate web site and MLS operators
•    Explain “strong authentication” and how it solves the current issue
•    Present the most viable and practical authentication solution

The Current Security Issue
The simplest and most common form of authentication (the process of verifying the identity of an individual) used in IT today is user login name and password. However, there is a fundamental flaw with this method of authentication: there is no guarantee that the user of the password is the owner of the password.

According to a poll conducted by the Human Firewall Council (now known as the “Information Systems Security Association”):

•    52% of office workers polled would download company information if asked to by a friend
•    42% would tell a friend their password
•    64% already gave their password to a colleague
•    2 out of 3 gave their company password to the pollster!

A separate survey conducted in April 2004 by the organizers of the Infosecurity Europe conference found 71% of office workers were willing to part with their password for a chocolate bar. (Yes, a chocolate bar.) Some 37% of the workers in that survey immediately gave their password to the pollster, and prompting questions raised that number substantially. There is no reason to believe that the real estate industry protects its passwords any better.

As long as there has been an electronic MLS, agents and brokers have shared their MLS passwords. Clareity has found MLS members sharing their login information with technology vendors, friends and family, and even the consumer. With the advent of easy-to-use web-based systems, password sharing has become even more widespread. Whether these passwords are used by “harmless” non-member users, such as part-time Realtors who are not paying for MLS service, or unauthorized data pirates, the simple truth is that MLSs are no longer members-only systems. MLS system passwords – and access – are simply out of control nationwide.

Recent postings to MLS e-mail groups confirm the real estate industry is in need of a solution to stop the illegal access and distribution of MLS data. Andy Duplay, MLS Director of the Toledo Board of Realtors, asked, “How do we … not let others ‘capitalize’ on this and share ID and password among licensed staff in their office, to avoid paying MLS dues?”

To quote Carl DeMusz, President and CEO of Northern Ohio Regional MLS (NORMLS):

“We have … stiff fines for sharing user names and passwords. That does not mean we can now sit back and not police it … You can’t be weak on your enforcement if you want to control the data and keep it from falling into the wrong hands.”

“I think we need to remember that the MLS has been given protective custody of the listing broker’s listings. I see many MLS’s these days taking that for granted … If we as MLS’s can’t prove to be trusted with the listing broker’s listings there can be retaliation and there could be a price to pay for not getting our house in order.”

John Mosey, President of Regional MLS of Minnesota, said:

“Most of us are blissfully, and in most respects, willfully, unaware of what is happening to the data. We jump all over any cases of misuse or piracy that come to our attention, but I believe what we don’t know is where the true threat to our rights of ownership will be found. It is most certainly the duty and responsibility of MLS Executives to be constantly on guard regarding the security of our systems and data.”

Controlling access to the MLS – and to transaction management systems, broker systems, and other real estate information systems – is now more critical than ever, since it is no longer just listing information at stake. MLS systems now include a host of contact management and CRM applications that store personal information about clients and prospects. With transaction management system adoption on the rise, access to the MLS system now provides entrée to a whole new world of sensitive property and personal financial information. While these systems have not yet been subjected to scrutiny under the FTC’s Gramm-Leach-Bliley Act Standards for Safeguarding Customer Information, Clareity believes that higher security standards are only a matter of time, given the expansion of sensitive data stored in MLS and transaction management systems.

Password secrecy is now, more than ever, subject to the frailties of human nature:

•    Forgetting passwords
•    Writing passwords down
•    Sharing passwords
•    Using a common password for all their accesses
•    Stolen passwords

User techniques for avoiding password security obviously negate the intent and purpose of the password. Therefore, reliance on this form of login authentication has caused MLS access to become inadequately controlled. It is only a matter of time before there is an embarrassing and damaging public incident involving a breach of privacy on an MLS system.

In order to deal with the inherent weaknesses in password-based login authentication, which both protects MLS dues revenue and provides a proper level of protection for listing, consumer and financial information, Clareity recommends that MLSs implement “strong authentication.”

Strong Authentication Solves the Password Problem
There are three factors of authentication: 1) something you know, for example, a password; 2) something you have, for example, a smart card or other token; and 3) something unique about you, such as a fingerprint.

That third item, “something about you,” is commonly referred to as “biometrics.” Biometrics eliminates the problems associated with password management by measuring human characteristics such as voiceprint, fingerprint, iris pattern, and facial contours, which are virtually impossible to duplicate and cannot be lost like traditional passwords. While biometrics can be a very powerful tool, Clareity does not recommend it for MLS or other real estate systems because of the high implementation and support costs, especially in our industry’s distributed and mobile work environment. Therefore, Clareity focused its strong authentication research on combining “something you have” with “something you know.”

A common example of this type of strong authentication is your ATM or bank card. Such cards are called ‘tokens’ in IT security parlance. Tokens require something you have (your card), and something you know (your PIN). You wouldn’t want your bank to allow access to your account with just one of these factors – the risks are far too great. Yet in the real estate industry, sensitive data can be accessed with just one factor – a weak, memorized password! Strong authentication eliminates password risks by providing multi-factor authentication. Best of all, strong authentication is not new behavior for humans, as we can all relate to the ATM card example.

“Something you have” can take several forms, but is generally classified as follows:

•    A physical smart card or USB token
•    A ‘digital certificate’ / software token

The best form of these tokens generates a dynamic, one-time pass code that the user enters to access the system. Most of the vulnerabilities of memorized passwords (sniffing, guessing, hacking, sharing etc.) are eliminated if the user requires a different password each time they log into the system, as any pass code obtained or given to a non-member user would be outdated as soon as it was used.

Instead of entering a username and password into their login screens, users type in their user name, push the token button (and possibly a PIN code for extra security), and enter the pass code that the token displays. It’s simple, fast and painless. Once a pass code is used, it can’t be used to log in again.

There are hundreds of companies offering various types of strong authentication products today. Clareity spent significant time researching and identifying which company could provide the right solution for the real estate industry.

About Secure Computing
Clareity selected Secure Computing as the leading candidate for providing an MLS strong authentication solution based on several factors:

•    The company’s proven track record and company stability
•    The full range of the security solution offering
•    24 x 7 x 365 staff support
•    History of innovation
•    Ease of integration with other systems
•    Competitive pricing

The company and its strong authentication product are extremely well regarded in the security industry. In 2002, SC Magazine rated it the Best Buy and gave SafeWord PremierAccess five stars out of five in every category (features, ease of use, performance, documentation, support, value for money). According to SC Magazine, the product offers “Great choices, strong security, extremely scaleable and ease of manageability exceeded expectations.”

To quote Frank Gillman, Director of Technology at the large law firm of Allen, Matkins, Leck, Gamble and Mallory LLP, “I wish every technology we deployed was this successful. PremierAccess worked right out of the box.”

Secure Computing is also eager to work with Clareity to tailor its security products and services for MLS and the real estate industry – and that process has already begun.

Track Record and Stability
Secure Computing (NASDAQ: SCUR) has been securing the connections between people and information for over 20 years. Specializing in delivering solutions that secure these connections, Secure Computing is qualified to be a security solutions provider to organizations of all sizes. The company has over 11,000 global customers, including the majority of the Dow Jones Global 50 Titans and the most prominent organizations in banking, financial services, healthcare, telecommunications, manufacturing, public utilities, and government. Secure Computing has close relationships with the largest agencies of the United States government, including multiple contracts for advanced security research.

SafeWord PremierAccess customers include hundreds of leading firms in banking, finance, government, and various high-tech industries, totaling over three million end users. Deployments range from very small companies and government organizations to one of the world’s largest aircraft manufacturers with 100,000 users and one the world’s largest banks with 800,000 users. There is no question that the SafeWord PremierAccess solution can scale to meet the needs of even the largest MLS.
Secure Computing is consistently rated to perform at or above the rest of the market segment, and revenues for this profitable and growing company have more than doubled in the past four years:

Year    2000    2001    2002    2003
Revenues    $34.64M    $48.35M    $61.96M    $76.21M

Secure Computing is headquartered in San Jose, California. (For more information on the company, see http://www.securecomputing.com.

Full Range of Solutions
Secure Computing’s SafeWord PremierAccess solution provides many authentication options, including passcode-generating tokens, digital certificates, smart cards, biometrics, and text-messages to wireless devices such as cell phones, pagers and Palm Pilots. An MLS can mix and match any or all of these solutions to offer the best, most flexible solution for all of its members.

Clareity believes that a combination of any of the following three forms of strong authentication will make the most sense for the real estate industry:

Silver 2000
In a convenient keyfob package, Silver 2000 authenticator tokens generate one-time passwords with the simple touch of a button. These passwords, like those generated by the Platinum or Gold 3000 tokens, can be used once, ensuring secure access. No PIN is required to activate this authenticator, although MLS customers may wish to take advantage of the SoftPIN feature, which allows the addition of a PIN entry with the token-generated password providing two-factor authentication.

MobilePass
MobilePass transmits one-time passwords as text-messages directly to most wireless phones, pagers, or PDAs. This zero-footprint solution provides the security of a token without requiring any other hardware or client software – MobilePass works with the devices users already have. MobilePass sends one-time passwords to the user’s cell phone, pager, or wireless PDA.

SofToken II
Secure Computing’s software-based token, SofToken II, is for users who want the security of one-time passwords but do not want to carry a hardware token. SofToken II generates a dynamic password just as the handheld tokens do, but the SofToken II software resides on the hard drive of the user’s laptop or desktop system.

24 Hour Support
Secure Computing provides 24x7x365 staff support. Clareity will help your organization through the process of integration, and provide staff training and on-site assistance during implementation. Optionally, Clareity can also provide end-user training during the deployment.

Clareity will also function as a front-line account representative for staff and on-call troubleshooting partner with Secure Computing.

Comparison with the Competition
In May 2004, Secure Computing’s strong authentication solution was awarded the Editor’s Choice and the only “A” rating by Network Computing’s Secure Enterprise Magazine in a head-to-head comparison with other market-leading authentication products. Those products included ActivCard’s ActivCard Token, RSA Security’s RSA SecurID, and Vasco’s Vacman Middleware and Controller.

Further comparing the Secure Computing solution with its competition:

•    The US Department of Justice performed tests on both Secure Computing tokens and those of a major competitor – including washing machine, freezer and oven tests. Secure Computing tokens had a 95% survival rate while the competitor’s tokens had a 95% failure rate
•    Secure Computing has the simplest integrations, as documented in all of the magazine articles quoted above.
•    Secure Computing has the only automated deployment and self-enrollment mechanisms Secure Computing does not charge for failover servers, while the competitors (at least those that support such important functionality) charge extra.
•    Secure Computing does not charge extra for 24x7x365 support

Secure Computing’s competitors simply do not offer the variety and quality of products, and while some of them sell cheaper authentication tokens, their extra costs add up.

Secure Computing’s solutions offer world-class authentication security and Clareity estimates the total cost of implementation, including 24 x 7 technical support, to be in the $1.50 to $3.50 per member per month range, depending on the security solution and financing options selected by the MLS.

According to Eric Hemmendinger, Research Director, Security and Privacy of the Aberdeen Group, “Fitting together authentication and access control solutions from different suppliers is an integration nightmare that is usually handed off to high-priced consultants. With the introduction of SafeWord PremierAccess, Secure Computing is delivering pre-integrated solutions for access control and user authentication that are plug-compatible with existing applications. The result for IT buyers is less time and money spent on integration, and a better fit between the old and the new security solutions.”

When Security Pipeline tested a number of competitors in the strong authentication space, including Secure Computing’s SafeWord PremierAccess, ActivCard’s ActivCard Token, RSA Security’s RSA SecurID, and Vasco’s Vacman Middleware and Controller, the PremierAccess product came out on top again:

“So who wins? Secure Computing’s SafeWord PremierAccess offers one of the easiest ways to build AD-linked hardware authentication into your security plan. It’s our overall winner because its schema modifications are performed according to Microsoft standards and its plug-in approach to integration makes tying it to AD easy.”

Clareity is confident that Secure Computing is the best company to provide strong authentication to the real estate industry.

Clareity and Secure Computing
After considering the aforementioned test results and rigorously comparing available solutions, Clareity has become Secure Computing’s vertical market partner for the real estate industry. Clareity will be working to help Secure Computing tailor its world-class security technologies to provide powerful and practical products for real estate. The customized solutions will provide security across a broad spectrum of real estate IT systems and will be specifically designed for mobile professionals. They will provide MLSs and real estate companies with heightened security while being easy to use and inexpensive.

Clareity will help your organization through the process of tailoring and implementing the right security solution for your MLS. This includes planning the installation with your vendor or staff, system integration, staff training, and providing on-site assistance to guarantee the success of your deployment. Clareity supports Secure Computing products and functions long-term as the company’s front-line account representative for staff and as its troubleshooting partner. Clareity’s ongoing relationship with Secure Computing will help ensure your organization receives the highest level of service over the life of your contract. Clareity can also coordinate cooperation and compatibility in markets where there are multiple or neighboring MLSs implementing Secure Computing’s products.

Ease of Product Integration

Secure Computing has already developed integration methods that bypass the usual nightmare of application integrations that have plagued other authentication solutions. The following integration methods will make it easy and economical to integrate the Secure Computing solution with applications used by the MLS and others in the real estate industry:

Universal Web Agent and Web Login Server
Many organizations providing extranet access or web content have a range of different web servers, such as IIS, iPlanet, Apache or custom application servers. Most access control solutions rely on agents or plug-ins that install on the Web server software, which are limited to specific Web server software or versions. PremierAccess solves these problems with the Universal Web Agent. While most agents protect a specific program, the Universal Web Agent protects the entire operating system that the Web Server operates on.

The Universal Web Agent protects both Windows 2000 and Solaris 7&8 servers. PremierAccess also includes a Web Login Server (WLS) that works in conjunction with the UWA. The WLS is an independent Web server that you can install on the same box, or on a separate box from the UWA. The WLS intercepts Web traffic, requests authentication, and verifies user identity with the PremierAccess AAA (authentication, authorization, administration) server. Once a user is authenticated, a session cookie is created with a session ID number and role-based authorization information. These credentials are passed to the UWA, which enforces what pages or Web resources the user can access.

SafeWord PremierAccess support for VPNs
SafeWord PremierAccess adds critical strong authentication to positively identify a user before an encrypted VPN tunnel is established–an essential component of any secure VPN solution. Secure Computing offers robust and scalable solutions that work with all major VPN vendors including Cisco (Concentrator 5000 and Altiga 3000), Check Point (VPN-1/FireWall-1), Microsoft Windows 2000, Nortel (Contivity), and Alcatel (7130 Secure VPN).

SafeWord Agent for Windows Domain
The SafeWord Agent for Windows Domains is a Windows domain login module that lets companies provide secure access to NT and 2000 domain-based networks.

Additional Integrations
Secure Computing provides integration modules for Citrix®, TACACS+, NT remote access server (RAS), Novell Modular Authentication Service (NMAS), Pluggable Authentication Modules (PAM) and SID2.
Software Development Kit (SDK)
Going even further, Secure Computing, published the PremierAccess SDK (software development kit), designed to enable developers to add SafeWord authentication to their own applications. The SDK contains code, documentation, strategies for building configurations, and sample programs that demonstrate how to use the API. The SafeWord Authentication SDK provides several advantages to developers. It includes a facility for authenticating passwords using SafeWord technology. The SDK allows programmers to easily add SafeWord capability to their applications and is ideally suited to both new development and retrofits. SafeWord’s SDK integrates into applications developed for Microsoft NT, Solaris/SPARC, Linux, and other operating environments.