Ivan Gevirtz

At Clique, we understand that security of software and systems is of utmost importance to our customers.  We maintain strict internal security requirements, and strive to exceed the needs of our clients.  Because security is a multifaceted problem, and we take a multi-pronged approach, starting with internal processes and ending with third party auditing.  This paper will outline, at a high level, some of the practices we employ to ensure that all our products meet a high bar of security while simultaneously remaining accessible to legitimate users.  This paper will then describe some specific techniques utilized in Clique Video Greetings ("CVG").

Because systems are only as secure as their weakest link, real product security is achieved by implementing processes around product development and deployment, and a culture of security is important to maintaining security over time.  At Clique, we understand that security is an ongoing process, and we have taken the efforts to ensure that it is a core competency of our company.  We have periodic developer training on security best practices, and have rigorous processes to maintain this standard.  All code undergoes a peer review process, which can reveal simple and complex security assumptions.  Our entire code-base undergoes continuous testing, and daily automated testing under a myriad of simulated user environments and network configurations.  This catches potential timing, processor speed, memory, and network related vulnerabilities.  In addition, every night our code undergoes third party static analysis which can reveal a host of potential security vulnerabilities including buffer overflows, user input validation, or memory management issues.  Our subsystem and deployment architectures undergo periodic review by an internal panel of experts.  Finally, we employ a light-weight, rapid development process which allows us to rapidly correct and deploy any software vulnerabilities detected.

The systems architecture of CVG has been designed to have security built-in from the ground up.  All communications channels can be encrypted using SSL, effectively preventing replay attacks.  All user input is white list validated.  This prevents SQL injection, even in cases of escaped alternate encodings like Unicode.  User input, such as usernames and passwords, can also be validated against a name server (such as LDAP), before login is deemed successful.

The web servers themselves are protected via firewall.  This prevents compromise via management channels, as only ports 80, 443 and 1935 are open for TCP communication.  The web servers are updated whenever a patch is available, and a roll-back mechanism is in place to make sure any bad patches can be quickly reverted.  The web servers are also behind a load balancer, allowing servers to be rotated in and out of service as needed, ensuring continuous service even during maintenance.  In addition, this allows any server with unusual behavior to rapidly be isolated and removed from service.

Back end servers are further isolated from the Internet, and will only respond to requests from known, authenticated, internal web servers.  This includes the mail servers, the SQL servers, and the Flash Media servers.  These servers are not directly accessible, and are firewall and load balancer protected.

Any Internet application which results in the generation of email will be attacked by spammers looking for an open mail relay.  CVG is no exception, and has been designed to prevent compromise of the mail server.  In CVG, the mail server is protected by a firewall.  This firewall blocks all incoming requests to the mail server.  Indeed, the firewall only allows outbound mail, and the mail server will only accept authenticated mail requests from the firewall-protected, internal web servers.  These mail requests must have the right credentials and type of data to be accepted.  Mass mail requests - both emails with too many destinations, as well as emails repeated with only the "to:" address changed - can be blocked and will not propagate.

Finally, the database is further isolated from direct external visibility.  It is only accessible via secure private channel (SSL) from the internal SQL server, and additionally uses UN/PW validation.  Packets from all other hosts are dropped by firewall before they even get to the database.  This helps prevent side channel attacks because the databases are only accessible to the SQL server via direct, known channels.

Denial of Service ("DOS") attacks have generated much media publicity over the past several years.  These attacks attempt to prevent legitimate users from being able to use the service.  They often work by attempting to consume all of a given, finite resource.  CVG systems use several mechanisms to reduce the threat of DOS attacks.  Load balancers are configured to rate throttle multiple requests from host IP's, reducing their ability to flood the system with creation or retrieval requests.  Username and password verification allow tracking usage, and allow CVG operators to deny access to malicious users.  New user creation requires a valid email address, preventing automatic generation of user accounts.  Human verification tasks can be added to account creation, and even message sending.  Public (eg. hotmail, yahoo) email addresses can be disallowed, if deemed necessary by the operator.  Greeting messages are limited in length and duration, preventing attacks on the system's storage capabilities.  Messages are periodically automatically removed from the system.  Message retrieval can be pipelined, staggered, or delayed, preventing server load due to multiple users concurrently, simultaneously retrieving the same message.

In summary, Clique utilizes industry best practices to help ensure the security of its products.  CVG has been designed to eliminate many threats, and limit exposure to other threats.  While no useful product can ever be stamped "100% secure", CVG strikes a strong balance, offering an easy to use product that protects its users and operators from undue vulnerabilities.