Email has always been a non-conformer, the maverick of the information security world. Don’t talk to strangers is a concept your email server doesn’t understand. It breaks the standard security model by allowing unauthenticated and unidentified connections from an untrusted source to a trusted destination. Furthermore your firewall doesn’t lift a finger to help secure it.
To operate email needs both inbound and outbound access. The very fact that companies want to receive email from strangers – potential customers – means that asking for authentication, the standard way to verify a connection passing through a firewall to a protected network, simply does not work. So the firewall just passes the responsibility to the mail server. Putting the mail server on the DMZ is not an answer either, this just moves the problem rather than addressing the insecurities of email, and makes it more difficult for internal users to read their email.
Securing email is a complex problem, with denial of service attacks on the increase and the convergence of spamming, viruses and hacking techniques, the new genre of email firewalls that are now available have not come a moment too soon. By upgrading their email infrastructure to include an application specific firewall that is able to protect against known and future exploits as well as spam, viruses and content, organisations will achieve greater and more effective security. But how can they be certain that the product chosen does “exactly what it says on the box” and not inadvertently expose their networks to further vulnerabilities?
Those organisations that put information security first look to schemes such as the Common Criteria accreditation to provide assurance that a certain level of security is provided. Common Criteria is an internationally recognised certification scheme that requires a thorough definition of the product’s functionality and more detailed documentation on how the defined functionality ensures secure operation. The level of documentation required depends on the level of certification and classification and ranges from EAL1 (Evaluation Assurance Level) to EAL7, this being the highest.
EAL4+ certification gives assurance that the solution is not susceptible to holes and vulnerabilities, and that vendor's development and support processes have also been audited. Many government departments, military organisations and an increasing number of commercial organisations require that products installed at the network perimeter hold this level of certification.
To qualify for Common Criteria EAL4+, the developer must provide detailed design documentation to show how the security claims documented are implemented and submit the product to a thorough vulnerability analysis. The vulnerability analysis requires both a detailed written analysis of how the product is designed to protect against identified vulnerabilities appropriate to the product’s intended use and extensive independent testing to ensure that the product lives up to its design claims.
Third party vulnerability tests are the only way to ensure that a security product is well-designed and configured, minimising the chance of system compromise through hidden vulnerabilities. Lower levels of Common Criteria certification, such as EAL2 require only developer vulnerability testing. The danger of relying on the developer to carry out these tests is that errors and assumptions made in design and development are likely to be repeated in testing, thereby increasing the risk of overlooking product weaknesses.