In order to determine whether senders are “good” or “bad”, organizations must have ability to accurately identify sender of an email. Spammers and their ilk would prefer to hide their identities – especially for those that are engaged in open fraud such as phishing attacks. They modify email headers in an attempt to fool recipients into thinking email is coming from a legitimate source. This practice, called “spoofing”, is a common tactic used by spammers to obfuscate their true identities.

To confront this issue, Microsoft, CipherTrust and other industry leaders have worked to create standards that allow organizations to determine whether an email is coming from a legitimate sender. To date, there continues to be debate as to which technology will prevail. Microsoft’s Caller ID (now dubbed Sender ID Framework or SIDF) has emerged as a front-runner along with Meng Weng’s Sender Policy Framework (SPF) .

Unfortunately, merely knowing who is sending an email doesn’t necessarily stop spam. As it turns out, spammers have been early adopters of new standards, they are better about applying for sender authentication technologies than normal corporations, and they are eager to participate!

Regardless of how many spammers adopt “honest” emailing practices, technology to identify email senders is quickly being adopted by major ISPs and corporations. Armed with that knowledge, reputation-based filtering can have a significant impact on level of spam in everyone’s inbox.

There are a number of methods companies use to determine whether a given email sender has a “good” reputation. Some of most common tactics are:

By far most costly method in terms of human resources, In-house lists require IT staff to maintain whitelists and blacklists in order to cut down on spam problem. The difficulty with these programs is that they require that IT staff become knowledgeable about a host of email security and spam issues, and investment is rarely sufficient to overcome thousands of variations of nuisances and threats posed by spammers, phishers, and other dubious email senders. By time administrator becomes aware of a new spam attack, spam has already gotten onto network, and into users inboxes.

How to Easily Secure Your E-mail System and Comply with HIPAA, Sarbanes-Oxley, and GLBA Regulations

While recent government regulations vary in scope and purpose, need to protect and ensure integrity of information is universal. Much of information germane to business today is assimilated and communicated over messaging platforms such as e-mail. As a result, need for a comprehensive approach to secure delivery of e-mail affects almost all organizations, regardless of industry or size. As with many management challenges, unknown is most significant cause for concern. In case of e-mail and messaging security, most ominous threat is often lack of ability to measure information flowing in and out of corporate e-mail network.

E-mail has traditionally been sent “in-the-clear,” meaning that e-mail headers and contents have been readily accessible to anyone with ability to monitor network traffic. Traditionally, encryption technologies have been sufficiently difficult to implement that many businesses chose to sacrifice security in name of user-friendliness given an application as mission-critical as e-mail. For example, some encryption and authentication technologies require ubiquitous adoption by each entity attempting to communicate, and few have ever agreed on which technologies are best or most efficient. Many businesses, committees and users have been attempting to standardize such use for well over a decade.

Over last few years, however, regulations have been enacted that require business and technology communities to generate and implement secure e-mail solutions. Easy-to-use encryption and authentication are now readily available. The new challenge for enterprise is to determine where and how to implement these new solutions to ensure compliance with new regulations. Understanding how each regulation affects e-mail security and delivery is important to understanding pressures all IT managers will be under in months and years to come.

E-mail Security Issues for Sarbanes-Oxley

The Sarbanes-Oxley Act of 2002 took effect in June of 2004 and requires CEOs, CFOs, independent auditors and audit committees to certify accuracy, confidentiality, privacy and integrity of financial statements -- and effectiveness of internal controls and procedures for financial reporting and disclosures. The most relevant sections of Sarbanes-Oxley to e-mail security are sections 404 and 802.

• Section 404 deals with internal controls, and requires organizations to implement controls over release of information to individuals or organizations outside company’s network.
• Section 802 addresses records management, and how long and in what manner documents (including e-mail) should be retained.

Sarbanes-Oxley does not detail specific steps organizations should take to comply with these regulations. Rather, it requires that companies implement programs that ensure secure flow of information, and then to be able to document success and deficiencies of those programs. There exist some programs that are commonly used as a basis for implementation.

Corporations and business partners of companies affected by Sarbanes-Oxley, are required to ensure that sensitive information remains secure. Similar to HIPAA solutions, “Insider information” should not be accessible outside of perimeter of a company’s network. Encryption policies should be enforced whether a busy executive remembers to encrypt a message or not. Rogue employees should not be capable of transmitting sensitive financial information outside network. Detailed reports should be available to auditors showing how system has successfully protected network and archived relevant communications. All of this can be handled swiftly with an e-mail governance policy and a central implementation mechanism. Without a mechanism in place, these requirements create a tangled web of complicated transactions and increased risk.

Unlike HIPAA, however, Sarbanes-Oxley often creates a need for organizations to prevent end-user encryption of information because encrypted information cannot be filtered for inappropriate content or trade secrets as it moves through e-mail servers and onto Internet. E-mails should be sent to server as clear-text, and only once content has been cleared for release should it be encrypted according to organization’s policies.

The need to enforce centralized content policies, as well as need to provide detailed reports to audit committees, requires server-level control and administration. The servers should be flexible in terms of encryption technology in order to maximize utility of e-mail, while at same time network should be defended from external attacks

E-mail Security Issues for HIPAA

The Health Insurance Portability and Accountability Act (HIPAA) came into effect on April 21, 2003. The act is designed to protect confidentiality, integrity, and availability of Protected Health Information (PHI) for individuals. PHI is defined as information that includes any individually identifiable health information. Healthcare organizations that must comply with HIPAA regulations are known as Covered Entities (CEs). CE’s include hospitals, insurance providers, employer health plans, physicians, business partners, and contractors working with healthcare providers.

The primary rule within HIPAA that affects e-mail is Security Rule. Exposed PHI within e-mail is considered a risk that will surface during a HIPAA risk assessment. Covered Entities are required to perform a HIPAA risk assessment and then to adopt appropriate safeguards depending upon outcome of assessments they perform.

Healthcare organizations have reacted to new rule in a variety of ways, and with varying degrees of effectiveness. The efficiency of e-mail offers an attractive means to transmit healthcare information from one organization to another; however need to secure each transmission of PHI has created complications as secure e-mail solutions are new and not fully implemented at many sites that transmit and store PHI.