We here at Clearview Social are often asked by potential customers to perform audits and security questionnaires about the compliance standards of our software. We always remain willing to complete your specific IT department's compliance investigation. That said, there are some recurring themes that occur in every security questionnaire we fill out. Please peruse these common themes below if you are curious about our security and compliance.
Storing LinkedIn Data
ClearView Social is often asked how it handles sensitive data. It is ClearView Social's official policy that, in accordance with the LinkedIn API Terms of Service, we do not store any of the information retrieved from a user's LinkedIn profile. The LinkedIn API TOS explicitly forbids the offline caching of the information that is made available when a user grants our application OAuth access to their account. The information is only to be used transiently for computations in memory and then discarded. Your profile picture remains on LinkedIn's servers, referenced to but never stored by us, and your networks, connections, and personal information are not retained. The only data we may save is the OAuth access token which grants the ClearView Social application specifically the right to post updates to your network for the next sixty days.
Explanation of OAuth Tokens
ClearView Social never asks for a user's password to any third-party sites. A user never turns over complete access to their LinkedIn, Twitter, or Facebook accounts. We use a widely-accepted industry standard called OAuth which is the accepted way to grant limited access to a part of a user's account.
The control flow of OAuth is:
The user begins on ClearView Social by clicking Login with LinkedIn (or, Connect your Twitter/Facebook).
The user is taken to the third-party site to conduct a login there, under that site's domain. In this phase it is crucial to understand that the user is not entering their password on clearviewsocial.com; they are conducting a private login procedure completely within the secure https context of that site's own ecosystem, as though they were logging in normally to that account.
The user is prompted to grant our application specific rights to do certain things and only those things, as seen in the photo below.
When the user's login and approval are successful, the third-party site grants us a token (a uniquely identifiable, long key string) valid for sixty days that accompanies requests to post to the customer's account.
The token may be revoked by the user at any time in the "Connected Applications" or "Privacy" sections of the third-party site.
This token is all the data that is ever stored by ClearView Social as pertains to the users' identity on a third-party site. It cannot be faked by other sites, and in the event of a serious data breach incident, tokens can be revoked from within LinkedIn and reissued. Because of its limited scope to do only exactly the actions listed above, the height of maliciousness ever possible in the event of such a breach would be the ability of an attacker to see profile photos and post an update to the users' LinkedIn profile. It does not grant the ability to further compromise the account, change passwords, or access other sites.
Lack of Physical Data Center
Security questionnaires often involve a detailed section about the physical security of the facility that houses ClearView Social's servers, and procedures such as physical keycard access for the staff, natural disaster recovery policies, and the like. ClearView Social maintains no physical data center of its own, preferring to house its architecture entirely in the cloud on virtual machines at the worldwide recognized leader in virtual cloud computing, Amazon Web Services.
All ClearView Social systems, ranging from servers to networking to databases to firewalls to domain names, are hosted on virtual machines at AWS. For this reason, we refer all questions regarding the physical attributes of our data center to the section of Amazon's website set up to explain their physical security architecture in detail.
This whitepaper contains in-depth explanations of their security processes, including some that frequently come up on security questionnaires such as background checks for all employees that have physical access to servers, key card access controls, and resistance of the building to natural disasters. Our answers to these questions become those of the white paper.
The facility at which ClearView Social data is stored is compliant with at least all the following standards:
Statement Regarding Antivirus
A common feature of security questionnaires is the demand to know the antivirus software we use at ClearView Social. Because our architecture is 100% open-source Linux with no Windows or OS X machines used as part of our production architecture, we have no need for commercial antivirus as it is commonly understood. While exploits and security problems certainly exist for Linux systems, "viruses" in the sense that commercial antivirus protects against do not. Our antivirus security measures are instead more an issue of keeping our servers patched with the latest updates than anything else.
Statement Regarding Patches
All servers are patched with all security updates for every package they use no less often than monthly, and as often as weekly. The machine image is rebuilt to include all security updates by default no less often than monthly.
Brief Description of Architecture Security
Here are some facts about the network security of our cloud computing setup (inasmuch as this can be discussed without too much detail).
All production systems live within a VPC (Virtual Private Cloud) which is the cloud equivalent of a private network. They have 10.10.*.* private addresses and no public IP's that can be accessed from the general internet. There are only two network paths into or out of the VPC: (a) the load balancer which serves as the front for app.clearviewsocial.com, directing only port 80 & 443 (HTTP & HTTPS) traffic to one or more web servers, and (b) a single "jump box" accessible from the public internet which, when SSH'd into, can then SSH into other production systems. The jump box is protected with 256-bit AES-encrypted private keys. Further keys are necessary afterward to access the other production servers.
All AWS assets are protected with IAM Roles and Security Groups that disallow all traffic from all sources except for specifically permitted exceptions. For instance, the web servers are part of a security group and security role that disallows all inbound traffic on all ports with the exception of SSH from the jump box's IP only and HTTP(S) traffic from the load balancer's IP only.
All development assets live outside the production VPC and cannot talk to the production database or servers, even accidentally.
All operating systems are AWS Linux (a unique Linux distribution but the closest analog is a relative of CentOS 6/7 Linux). One WordPress server for the company blog, hosted outside of the production VPC, uses Ubuntu.
Statement Regarding Keys Over Passwords
A common feature of security questionnaires is asking about our password policy. All ClearView Social systems are not protected with passwords at all, but rather by AES-encrypted 256-bit public/private key pairs. Access to servers cannot be obtained with any password at all, but only a privately signed key certificate that allows access to the jump box. These keys can be revoked and reissued at any time (and have been). Access to the entire production stack can be revoked in an instant if necessary.
This key-based architecture in place of a password-based one does effectively obsolete or "n/a" common questions regarding password strength and rotation.
Lack of Personal Workstations
Security questionnaires often include questions about the interactions between ClearView Social Employees and their company workstations. Many of these do not apply because ClearView Social workstations have no special relation to the ClearView Social architecture or system. Possessing a ClearView Social workstation does not grant access to any system. ClearView Social workstations are not part of any company network. They are more "dumb clients" than anything else. Regardless of whether one is working from a company-issued laptop or a home computer, there is one and only one way ever to access data and systems, and that is through an SSH session in a terminal via the key-protected jump box.
Shared Tenancy of Data is Not Possible, but All Data is Non-Sensitive
Some clients demand dedicated exclusive tenancy of their solution—in other words, they wish for the ClearView Social platform that their access to be segregated by itself in its own ecosystem, with a database that contains only their data, separate from all other users of the software. This is not something we offer at this time.
However, do understand that no sensitive data is ever stored by ClearView Social. As iterated above, we store no personally identifiable information from any social network, in accordance with their terms of service. Beyond that, ClearView Social's database stores little more than a list of shareable items along with metadata that accompanies those shared items. Even in the horrific event that a full data breach was ever suffered, or that shared tenancy resulted in information from one organization appearing in another customer's software, there is nothing to be seen but the contents of some queues containing existing firm content, usually from the customers' already public blog. We have never stored and will never store phone numbers, personal email addresses, addresses, credit card numbers, or private information about organizations or their users. The majority of ClearView Social data stored is titles and images from the articles already intended to be posted publicly to users' social media networks.
If there is anything else we can assist you with, you can contact ClearView Social Support either by emailing firstname.lastname@example.org or through the Intercom chat button in the bottom right of the site.