ProVault recognizes the critical level of security needed for handling, storing, and delivering most of the client information within ProVault. Most companies have some amount of customer information that would be considered critical with regards to security, such as billing information, based upon the risk/consequences of exposing the data to unauthorized users. The type of data stored within ProVault’s application, as well as the clients’ relationships with their attorneys and other parties in their legal matters, heighten and specialize ProVault’s requirements for security.
ProVault’s extensive measures ensure that we have state-of-the-art security for our customers’ sensitive information including:
1. ProVault contracted a qualified systems architect to gather and document the security requirements, and design and document security procedures and system requirements (collectively “security mechanisms”) to meet these security requirements.
2. ProVault contracted software engineers with extensive experience in the security procedures and technologies specified.
3. ProVault’s founder and CEO has a software engineering background and personally held the contracted software engineers accountable to abiding by the specified security mechanisms.
The security requirements and mechanisms used to meet those requirements are described below.
Type of Data
Clients enter personal and financial information, as well as information about their legal matter, that is considered private. This information, if accessed by unauthorized persons, could be potentially damaging to clients. Examples of this information are the clients’ social security number (which could be used for identity theft) and bank account information (which, if compromised, could result in financial loss).
Clients of attorneys have legally protected client-attorney privileges. One of the most important of these privileges is confidentiality. Attorneys are ethically bound to safeguard their clients’ confidentiality. Since ProVault stores this protected information on behalf of the attorney, we must ensure that it can never be compromised, even when we store this privileged information from both sides of the same case, so that attorneys can be confident their clients’ confidentiality is safeguarded. This means that ProVault staff (including IT personnel with the highest access level) does not have access to this confidential client data.
Online Application Data Handling
Online applications must not only ensure that the data is securely stored in the database on the server (back-end information security), but also that the data is transferred back and forth between the browser and the server safely (front-end information security). We must address various threats to the storage and transfer of information.
Defining the Unauthorized Access Threat
Threats to data confidentiality come from four main areas: unauthorized access by ProVault staff, unauthorized access by firm users not affiliated with the client user, unauthorized access by hackers, and compelled access by U.S. government agencies. Each of these areas will be discussed below.
Unauthorized access by ProVault staff
The recent Presidential election highlighted the risks businesses or government agencies face when employees access confidential data not because of valid organizational need, but instead because of curiosity, or a desire to exploit their access for personal gain. Newspapers regularly carried stories regarding data confidentiality being breached in this manner, much to the embarrassment of the organizations involved. Furthermore, as mentioned previously, ProVault must meet the requirements of Client-Attorney confidentiality privileges while handling data for both sides of the same case. ProVault cannot be successful as a business if Firm and Client users cannot trust that Client data remains private and accessible only to those they approve for access. Because of this, information collected by ProVault must be protected in a manner which makes it impossible for ProVault staff to access elements which are not directly related to the delivery of ProVault services.
Unauthorized access by unaffiliated firm users
ProVault acts as a broker between Client user data, and the Firms which require that data in order to deliver a service to that user. In the same manner that Client users must have confidence that ProVault itself is not accessing their data in improper ways, they must be equally confident that their personal data is only accessible by the Firms they specifically authorize to have access. Further, once given access, Firm users should have access only to the data necessary to provide the authorized service(s) and no more. ProVault information systems must be designed in a “fail-safe” manner which prevents information release to unauthorized users.
Unauthorized access by hackers
The release of Client data through the activities of Internet hackers would result in serious damage to ProVault and its clients. Data held by ProVault has potentially great value to hackers: the release of any user's information provides information that could expose that user to immediate threat of identity theft and could result in significant financial loss. The design of ProVault information systems must presume that ProVault will be under sustained and intense attack by hackers at all times; industry best practices for information security must be applied and maintained.
Compelled access by U.S. Government agencies
In recent years, the power of government agencies to demand access to data held by third parties has been greatly expanded as part of the response to terrorist actions on 9/11. A key provision of these expanded powers are the provisions of the USA Patriot Act, which enabled US government agencies to demand secret access to data held by third parties without judicial oversight. Thus, agencies may simply issue a “National Security Letter” demanding the data. Further provisions of the USA Patriot Act enabled the government agencies to demand that their request of the data – and the nature of any data provided – be kept secret, barring the third party from disclosing to the Client that their data had been released. This gag order provision has only recently (as the result of a December, 2008 Federal Court of Appeals ruling) become subject to court oversight. Prior to December 2008, no judicial oversight was required for any aspect of government agency use of USA Patriot Act provisions. Since the ruling, agencies are now required to seek Court approval to enforce National Security Letter gag provisions. It is important to note that seeking the authority to enforce the gag order provisions is done without either the third party or the Client in question having the opportunity to argue against the restrictions.
ProVault – and its underlying information systems – are 3rd parties when it comes to client user data, and do not have standing when it comes to attorney-client privilege. Thus, the data collected by ProVault may be of particular interest to U.S. Government agencies as a way to collect data that would otherwise be denied to them as part of attorney-client privilege. It is therefore necessary to protect Client data in a manner which makes the U.S.A Patriot Act information release provisions irrelevant to government agency attempts to compel data release.
Back-End Information Security Mechanisms
ProVault’s entire online system is comprised of two main sections: the website, which uses Drupal as its content management system; and the actual ProVault application, which is accessed via the website, stores confidential client data, and is developed in PHP. The Drupal CMS manages all information that ProVault wants everyone to see (e.g. marketing information, vendor website listing service, and forum), and user account information and functionality useful to service our customers (e.g. client contact data, billing information, and helpdesk functionality). The ProVault application manages all the client confidential information used by their attorneys to represent them, used by ProVault to generate their financial affidavits, and used for their legal matters (e.g. disclosure documents).
Protecting Client data against unauthorized or compelled access outlined the sections above, while still enabling ProVault to provide the services necessary as an information broker, was a daunting task. Two fundamental tenets were applied to the design of ProVault’s system which address all of these concerns. The first tenet is that all personal /confidential Client data is stored in an encrypted format on ProVault systems. The second tenet is ProVault only holds the decryption keys for high-value data stored on the ProVault system in a separate database to which only two ProVault staff have access.
High-Value Data Stored Encrypted
ProVault encrypts all of its sensitive information, including most data in the ProVault application, and customer billing information in our ProVault application, generated via an 128-bit Advanced Encryption Standard (AES) algorithm. Client users, Firm users, and Firms each have one password for their ProVault user account, which is encrypted according to a ProVault generated key.
ProVault Limits the Access to Decryption Keys
ProVault does not process/manipulate Client data itself. Client data is only accessed /manipulated when an authorized user (the Client or an authorized affiliated Firm) accesses the data. This recognition, then, is the key to how ProVault’s system has been implemented which protects Client data from all forms of unauthorized access, as well as from compelled release via a National Security Letter.
Public-Key cryptographic systems suggested how such a system was implemented for ProVault. Client users have a second password, or “Secret Key”, to access their ProVault application data. This Secret Key is the key that encrypts and decrypts their own key, so that their sensitive information can only be accessed by those who have their Secret Key. This Secret Key is never written down in an unencrypted format anywhere in ProVault, neither in a database field, or when it is passed from one page to another page.
Firms must be able to access their clients’ data, but it would be cumbersome for the firm to manually keep track of all their clients’ Secret Keys. Therefore, e ach Firm has their own Secret Key which is used to encrypt and decrypt all of their clients’ Secret Keys. If client users lose their ProVault password, ProVault can give it to them again or reset it. If client users lose their ProVault Application Security Key, ProVault cannot give it to them or reset it, but their law firms can remind them what their Security Key is. If a Law Firm loses its Security Key, ProVault cannot remind them what it is.
The ProVault system addresses each of the four threats outlined at the beginning. ProVault staff cannot access data which they do not need to see since they lack the necessary decryption keys. Similarly, unaffiliated Firms cannot access data, because they also lack the decryption keys. Hackers could at best access non-high-value data by penetrating the database (again, lacking the decryption keys) which, at worst, compromises data already available via public sources. Finally, while not a comprehensive mitigation against U.S. Government access to data (the solution does not, for instance, provide either repudiation, or plausible deniability), it does “raise the bar” to the level where U.S., government agencies would be required to seek access to data via the public subpoena process. (“Wiretapping” of the sort that would be required to capture decryption keys as a user is accessing the data does not fall within the provision of the National Security Letter.)
Front-End Information Security Mechanisms
Protection of Client user personal information does not stop at the data storage layer. Data must be equally protected while in transit across the public networks between ProVault servers and the user’s browser.
To this end, all browser communications from ProVault are via the HTTPS protocol using secure sockets layer (SSL) encryption beginning at User login. The connection between the User’s browser and our servers remains SSL-encrypted until the User logs out or the session expires (system logs the user out).
When the Secret Key is passed from one page to another via CGI, it is first encrypted by a known key, and decrypted dynamically in the code in the receiving page, to provide the key to decrypt sensitive client data live and on-the-fly, so that anyone “shoulder surfing” (looking over the shoulder of a user) will not see an unencrypted password in the URL.
Because browser defects are significant security holes on the client side, the ProVault system must be compatible with all modern browsers. ProVault’s system supports Internet Explorer 7 or later, Firefox 3 or later, and Safari 3 or later, and will stay up-to-date, which will also ensure that we take advantage of upgrades that enhance security and close holes.