Jun. 30, 2008 - Securing Email

Email is one of the most dangerous activities any of us does online. The way most companies implement email, it’s trivial for email account access to be compromised and for sensitive information (human resources, budgets, etc.) to get into the wrong hands. SPAM reduces our organizational efficiency and malicious software often enters networks through email. What can be done to lower these risks?

First, find out - by looking at your email settings or talking to your network staff or ISP - if you are using an unencrypted protocol (POP or IMAP) to get your email. If so, then someone – an employee or other fellow network user using a ‘sniffer’ tool - can capture your login information and intercept the emails. If your email provider can’t provide you a secure protocol, you must take other steps to encrypt the emails.  If you are using a public network, you can encrypt all your network traffic – including your emails – by using a Virtual Private Network (VPN). If your company has a firewall that includes VPN capability and you connect to it before checking your email, then the traffic can’t be ‘sniffed’ as easily.

Note that my blog is hosted by Internet Crusade, and their email solutions are fully capable of secure protocols such as SSL encryption for POP mail – according to Mike Barnett you just have to ask for it and they can hook you up!

You can also encrypt your email and attachments in other ways. While this doesn’t stop people from ‘sniffing’ an insecure email protocol, it can stop people from reading email and opening attachments that are sent to them by accident. Encrypting the whole email is not easy for the non-techie, depends on the platform being used for sending and receiving email, and gets most complex when the sender and receiver are on different platforms. Helping the reader navigate this maze is not something that can be done in a short article. In terms of encrypting files and email attachments on Windows computers, I’m fond of free-to-inexpensive products from http://www.kryptel.com/.  

The next tool in your security arsenal is to use company policy to educate employees on safer email behaviors. The policy can include instructions not to use email to distribute offensive materials, not to send or forward SPAM, how to try to recognize phishing, pre-texting, or other social engineering involving email, not to send confidential information via email and when to use encryption, and not to open attachments from un-trusted sources – or even from trusted sources without phone verification. The policy should also set the expectation that email may be monitored for policy compliance, and that there should be no expectation of privacy. The policy may also set email security standards for technical staff to implement, such as whether email servers pass on executable attachments at all.

None of the above steps address SPAM and the tremendous threat of malicious software that can be attached to email. At a time when spammers are becoming ever more sophisticated at evading anti-spam tools and there are free tools are available for hackers to create malicious software that cannot be detected by most anti-virus and anti-malware tools, making the right technology choices is more important than ever. As part of the ongoing support provided after an Information Security Assessment, Clareity Consulting has guided many clients through the maze of technical options that might work best for their individual needs, and strongly encourages its clients to take reasonable steps to secure their email, as it is one of the largest threats to organizational information security.

Jun. 19, 2008 - Firefox 3 security

I'm very excited about some of the new security improvements in the new Firefox 3 browser release.

One improvement is some built-in protection against Cross-Site Scripting (XSS) attacks, though it's important to note that the vulnerabilities extant on many of our industry sites are still not caught by the Firefox filter. Firefox add-ons that I have mentioned in the past on this blog, including NoScript and NoRef are still of value, and the Firefox improvements don't mean vendors don't need to follow secure coding practices consistently and that users don't need to be very careful about the sites they visit.

Another improvement is seen just to the right of the address bar (now called the "Awesome Bar" in Firefox). That area now shows the site's icon (or a blank page if the site has no icon) with a color background that makes it easier for users to see the security status of the page. As you can see below, colors include gray, blue, green (and red) and if you click on the icon you can get more information about the site.

• Grey is normal - no SSL encryption on the connection or other identifying information about the site.
• Blue means you are viewing the site through an SSL certificate and all content (even images) are being transmitted to and from the site encrypted.
• Green means there's not only an SSL certificate, but also an "Extended Validation Certificate" (a.k.a. EV Cert) that means the site owner (not just the site) has been validated in some way by a "certifying authority". These certificates are spendy (about $500 / year), and some people complain that they are an unnecessary expense. That will certainly be an ongoing argument!
• There's also a RED color - this means a site is known to cause compromise - I'm not going to a site of that nature to collect an image - sorry!

The 'More Information' button lets you see if you have visited the site before today, if there is a cookie (and lets you see the cookie contents), if you have saved passwords for the site in the browser (tsk!), if the connection is encrypted, and also lets you see information about the site owner.

Internet Explorer 7 and Opera 9.5 both also have support for the EV Cert, but I think that Firefox's implementation is the most 'in your face' and in that way, the best.

Some believe (and others don't) that the color approach (including EV Cert) is still vulnerable to homograph and picture-in-picture attacks (sorry about the tech-vocab...) - but I still think this approach is a worthwhile endeavor toward reducing phishing attacks and I applaud Mozilla Firefox for improving its interface to be helpful in this way.

Jun. 16, 2008 - Improving PDA Security

More than half of REALTORS^® use Personal Digital Assistants (PDAs) – devices that create a significant information security risk. Real estate professionals use PDAs to store sensitive data, including email, contacts, documents, spreadsheets, passwords, bank account information, and MLS data. More than a quarter of PDAs are lost, according to a 2003 survey conducted by Pointsec Mobile Technologies, and that’s just one part of the problem. PDAs and memory cards are stolen or infected by viruses; wireless transmissions are intercepted, and many professionals don't enable passwords on their devices, allowing anyone who finds or steals their PDA to see their data. Besides keeping as little information as possible on your PDA, there are many steps you can take to secure it:

The most basic step is to reduce the risk of losing the PDA. Keep it locked up in a briefcase, desk drawer, or lockable case when not in use - do not leave the PDA unattended in plain sight.

Require a hard-to-guess password to access the device and its applications - if you don't already require a password on startup, there's nothing to stop someone from accessing your information. Whatever you do, don't configure your PDA applications to memorize your application and web site passwords.

Most people are not aware that viruses can affect their PDA. There are many anti-virus tools for PDAs, and you can download free antivirus software for some PDA models from Trend Micro (http://www.trendmicro.com/download/product.asp?productid=2).

Using a wireless connection poses a substantial risk that your information can be intercepted. If you must use an unencrypted wireless connection, the web sites and email providers you use should provide an SSL encryption option to reduce your risk. If your office or service provider offers a Virtual Private Network (VPN), that will provide an even greater degree of protection.

Many security products for PDAs exist to encrypt the information on the device - they put a password on your data, which you must enter to access the information. Examples include:

• Kaspersky: Security for PDAs, http://www.kaspersky.com/
• Utimaco: SafeGuard PDA, http://www.utimaco.us/products/pda/
• Applian: PocketLock (PocketPC only), http://www.applianmobile.com/
• Softwinter: Sentry 2020 for PocketPC (PocketPC only), http://www.softwinter.com/

To encrypt your data on a Blackberry with a password already set, just click Options > Security and set Content Protection to "Enabled".

There's no such thing as perfect security. If you run a program from an untrusted source on your PDA, none of the steps mentioned above will be a cure-all. But, if you've taken the basic steps to secure your PDA and have your email address on the back, you don't have to worry as much about the information on a lost PDA – and you may even get lucky and have it returned to you.

Jun. 2, 2008 - Negotiating Win-Win Technology Contracts

When customers negotiate technology contracts infrequently, the contracts may be short-sighted, incomplete, or inflexible. Such contracts can lead to impasses between the parties, and in turn to rapid vendor turnover and frequent system changes. This is expensive for the organization and unsettling for members. Clareity Consulting negotiates dozens of technology contracts every year and prefers to see contracts that provide a foundation for a long-term relationship. Although no article full of tips can replace a practiced eye, Clareity Consulting’s finely-honed contract language recommendations, and the use of a seasoned technology contract attorney, can save time and prevent error. This article will provide, at minimum, a baseline for contract review.

Define the Product. A strong contract must include a complete product definition by reference, with the documentation included as an addendum. The contract must define every function and interface, so that if the product does not meet expectations, both sides can reference the documentation to see whether the agreed-on performance was delivered. If a Request for Proposal (RFP) process resulted in a detailed description of deliverables, the contract also should reference and include the response to the RFP. The contract should include all definitions of initial customization and integration, or at least define a process by which the contract can be amended to include them as they are discovered. The customer should take the time to document all verbal promises, including delivery dates for specific functionality. If the product is highly dependent on vendor-supplied data, define data update periods and standards for data accuracy. If the contract includes upgrades, it should not lock the organization into a specific version. The product will change over time, and a process to update the product description, along with descriptions of any customizations made for the organization over time, must be written into the contract. 

Define the Service. Products rarely are sold without services; the contract should include complete descriptions of all included services, as well as detailed descriptions of initial and ongoing training for both staff and members. Training descriptions should specify whether training is lecture-style or hands-on, class size, and responsibilities for facilities and training materials. The contract should describe support services in detail, including the days and hours of support for staff and members, exceptions for holidays, processes for emergency staff support, and metrics (such as average hold times, voicemail thresholds, and email and voicemail response speed). Especially if support is a shared responsibility, it may be important to include access to a common support system or knowledge base. The contract should establish processes for bug fixes, including severity classifications and processes for different classes of bugs, reporting, and metrics (such as time to resolution). If the contract properly defines services, service expectations, and reporting methods, the parties should never disagree regarding the service level received.

Plan Implementation and Deployment. To minimize risk, the contract should specify a schedule for implementation and deployment/delivery, including visible milestones, procedures for missed milestones, and project management communication. The contract should always define a testing and acceptance period before delivery, training, and cutover. It also must specify documentation and help files which have been customized to the installation for delivery – definitely before the software is fully in use and ideally before training. If the software is customized for the organization, it probably will not identify all customizations required by the members before they are using the software en masse. Therefore, it is ideal to specify a grace period for changes identified post-deployment, during which time modifications are completed as part of the original price.  

Define the Product/Service Future. The contract must answer many questions to set appropriate expectations for how the product and service will change over time. Which enhancements will be provided for free? How often will enhancements be provided? Must the organization accept new features developed by the vendor and provide them to members? What is the hourly programming rate for custom programming? How are customer requests included as enhancements rather than costly custom programming? What are the processes for enhancement specification, cost estimation, acceptance, and deployment? Does the cost include a certain number of hours per year of custom programming? If the contract adequately answers these questions, it will leave less chance for conflict about the product and service levels.

Set Protections. Most contracts define “uptime” only in terms of availability, but to be meaningful, uptime must be defined in terms of three criteria together: availability, performance, and functionality. What is the use of reaching the MLS server if the search function is broken? If users can search but the search runs painfully slow, the system is basically unusable and shouldn’t be considered “up.” It is important for the contract to link these criteria into a unified definition of uptime. Many contracts specify 99% uptime, which is inadequate for a typical web application! Uptime percentage often is reckoned in terms of “five nines”: these refer to unplanned downtime per year:

A sound technology contract should also include protections such as:

• reasonable definitions of and limitations on performance in the case of civil or natural disaster (“Force Majeure”)
• Representations and warranties
• reasonable security precautions by the vendor
• intellectual property definitions and mutual confidentiality agreements that cover all content the organization and its members enter or cause to be entered into the system
• terms of contract assignment for both parties
• definitions of which provisions survive contract termination (such as confidentiality)
• assurances that the vendor cannot market other products to the organization’s members directly without written permission of the customer
• terms for the escrow of source code
• setup documentation.

Dispute Resolution. The contract must specify a meaningful method of dispute resolution. It must define mechanisms for notification of non-performance and an issue resolution process. It should include a definition of default events, penalties and remedies, and a period within which defects and non-compliance can be cured. The contract should define mediation and/or arbitration mechanism to deal with more serious disagreements, and for the most serious issues, the contract should specify legal interpretation, legal cost-bearing, governing law, and jurisdiction. Monetary holdbacks or termination for cause should be the last resort in dispute resolution.

Getting Your Data Out. It is important to define the mechanisms and costs for obtaining constant access to your updated data for use in integrations, regular access to an organization-owned backup for risk mitigation or disaster recovery, and/or a way to extract and convert your data near the end of your contract.  Ideally, the contract should specify the data in question to include any information or documents that the organization or its members enter or cause to be entered into the system. For an MLS system, this might include not only listing data but photos, virtual tours, video files, contact data, documents, and even calendar and preferences, such as saved search criteria, listing carts, and prospect searches. In this example, does your MLS contract also specify what information – other than listings – will be imported from the old system? As technologies continue to expand their scope, one must eliminate unreasonable limitations on the scope of the data one can contractually convert to or retrieve from the system for use in other systems. It is particularly difficult for a contract to define the format in which data can be retrieved from the system. A delimited file or RETS standard can be used for listing data – but we currently lack an ”industry standard” format for other MLS data or data/documents in transaction or document management systems, contacts, calendars, and similar areas. This means that even if one can contractually extract the data, there’s no good way to ensure that it will be in a format usable by another vendor. Currently the most one can do is to specify existing standards and write the contract to apply other industry standards as they emerge. Finally, if the client requires real-time read-only database or RETS connectivity, the contract should specify it. 

Pricing. Clareity always advises clients to start by selecting the system desired, then consider price. Too often, real estate organizations reject their preferred technology because it is more expensive – but then are dissatisfied with the selected technology and end up spending more money and member good-will converting to a better technology. Negotiate a fair price, remembering that you get what you pay for. If your technology partner isn’t making a decent profit, chances are your organization will get inadequate service, the vendor will lack the money to perform adequate R&D, and may even go out of business. The contract should try to anticipate any “extras” that may be needed and specify all costs explicitly. Ideally, the contract’s pricing should be variable to protect both parties. For example, it is no longer unusual for contracts to tie pricing to Consumer Price Index adjustments. Also, if the technology’s pricing would vary based on the number of users, the contract should include a grid showing the price differences if your membership size changes.

Conclusions. Aim for a win-win contract that protects both parties. Watch out for contract language that does not adequately define product or service, account for change, or identify dispute resolution methods. Inflexible contracts often lead to dissatisfaction that is difficult to resolve through renegotiation and to relationship failures that hurt both parties. The goal of this article is to help you understand risks in your current contracts and identify some areas where you can improve your new contracts -- but no simple set of tips can replace a business consultant’s practiced eye, the time savings created by using finely-honed contract language, and the use of a seasoned technology contract attorney. I negotiate enough real estate technology contracts to be able to say with assurance that the devil is in the details, and a single word can make all the difference between a bad and a good contract.