Architecture & Security

Introduction

We strongly believe that engagement, interaction and actually working with your customers, instead of just serving them, via a community can contribute extensively to reaching a very diverse selection of business goals.

With 10+ years of hands-on experience with building communities, from both a technical, security and community management perspective, we have proven that inSided makes a difference when it comes to customer interaction and engagement. 

Our (enterprise) customers are active in very diverse markets; from software, to telecom operators and financials. This means that our customers have diverse demands when it comes to their communities. We have got it all covered with our platform and services. 

The current inSided Software-as-a-Service (SaaS) platform is a result of our experience. We know our customers (and their end users) have high demands regarding product specifications. Especially security, scalability, flexibility, integration, and speed are of the utmost importance. We have taken all of that into account and have built a platform that makes sure all of these aspects are covered and tested to the extreme. In this document, we will explain how we do this, how all aspects are taken care of in the platform and how you can be sure we will maintain our high standards. 

inSided is ISO/IEC 27001 certified, which shows our (future) customers that we have a continuous commitment and effort to provide a secure environment for our customers and their end-users.

inSided Customer Success Community Platform

Making sure our customers can activate the right components within the inSided platform, in the different stages of the community lifecycle, has helped tremendously for more natural growth of the communities.

Which components are activated in a certain period, all depends on the market, type and size of the customer in combination with the chosen KPI’s and business goals. 

Our platform consists of a (growing) set of components that can all be used separately or in combination. All components can work with one another and with external components which creates a dynamic eco-system that contributes to a stable and feature-rich platform.

All components are part of the inSided platform and can be activated per customer. These components are fully configurable when it comes to look & feel, configuration and data sets.

Software-as-a-Service 

SaaS has been a hype for a long time but not for inSided. We know SaaS is the way forward and that is why we decided while being focused on customer advantages, to provide our platform via a SaaS architecture.

There used to be a natural fear with (some) IT departments regarding SaaS; “not having components on-premise goes against the way ‘we’ used to do things”. inSided strongly believes that SaaS leads to better platforms, services, security and a better IT- landscape/ecosystem in general. Recent studies, led by Forrester Research, show that IT departments are getting more comfortable with offloading non-critical components to SaaS vendors. To provide clarity on why we believe SaaS is the way forward, we have summed up the greatest SaaS advantages. 

No large investments

Large upfront investments are non-existent when using SaaS, as platforms are instantly available without investments for the creation of software, IT infrastructure and other platform development costs. With SaaS the costs are granular in nature without spikes, allowing for more control over costs without surprises.

Lower Total Cost of Ownership

The inSided platform can be used via a subscription model, which includes everything from managing IT infrastructures to application updates. Not having to manage complex architecture and software, which makes the community platform, consistently lowers costs for software, hardware, bandwidth, and IT staff substantially. 

By taking away the concerns listed above helps our customers focusing on their core systems. This reduces business and financial risks because internal IT resource requirements are minimal when implementing a community on the inSided SaaS platform. They are not specifically required (they are optional based on customer requirements) during the implementation and lifecycle of a community. 

Security

The inSided platform was built upon 10+ years of experience building and operating communities. Since some of our communities were aimed at (and attracted loads of) highly critical tech-savvy visitors, security was (and is) always the first priority in every layer of the platform, organization, and business in general.  

By using a SaaS architecture to host the full range of communities for our customers, which are active in a wide range of markets and having different demands and experiences regarding security, we are able to incorporate a wide range of security measures into our platform that is instantly available for every customer. This results in an extremely safe environment in which user-generated content leads to success, not a failure. inSided believes that more and different types of customers result in a more secure and robust SaaS platform. 

Scaling

inSided has built a multitenant architecture, which is able to scale instantly and infinitely. By using detailed monitoring on our architecture we are able to automatically pinpoint which component within the architecture should scale up or down in real-time. We have experienced several extreme traffic-peeks throughout the years that were easily dealt with by allowing the inSided platform to decide when to scale up and down.

Continuous upgrades

inSided is continuously improving the platform on which our customers build their communities, engage with their end-users and let them interact with each other. We make sure all the upgrades are dealt with so our customers don’t have to and are able to focus on their core business. Security patching, new features or adding new components to the platform; it is all taken care of by inSided. 

Of course, we communicate our upcoming releases with our customers via our community and product managers, so our customers know what is coming. By upgrading the platform as a whole we can make sure all of our customers instantly benefit from the improvements that we make. Deploying a new release is not something our customers need to worry about. We do it for them and make sure everything is tested thoroughly via unit testing, functional testing, user acceptance tests, etc.

Easy integration and customization

The inSided platform has been built from the ground up with flexibility in mind. Allowing our customers to easily extend the functionality is a key element of our business focus. Our customers can adapt the platform to perfectly suit their needs during every stage of the platform lifecycle. This means you can start with simple integrations and easily expand when your demands change and/or your user base grows bigger over time. A selection of the possibilities:

• Configuration of look & feel on customer level
• Use company domain name(s): community.company.com 
• Integrate external elements via SSI (Service Side Includes)
• Use available data everywhere in- and outside the platform
• Integrate and combine data into the platform 
• Extensive (third-party) data integration via the inSided REST API
• Extensive (third-party) data integration with CRM and SaaS platforms
• Easy (third-party) integration via the inSided Embed codes (create/copy/paste)
• Single Sign On (via multiple methods) allows for seamless user experience

Configuration over customization

Our proven vision is based on Customization by configuration, with the following benefits:

• Community managers in charge
• Technical features configurable
• No help needed from technical colleagues
• UI/UX changes with preview
• Menus for everything

Amazon Web Services

inSided has carefully chosen Amazon Web Services (AWS) to become the provider of our infrastructure on which we offer our platform and services to our customers.

With AWS as our provider, we are able to provide our customers with a fast, flexible, scalable and safe environment.

We are able to serve our platform from several regions in the world (listed below) to ensure the requests are handled as fast as possible. Within these regions, there are several data centers available on which the platform is hosted. This makes sure we can provide great security, uptimes, speed, and flexibility. Current InSided infrastructure runs in the following regions:

• Ireland, Europe
• USA (Oregon)

AWS maintenance and development

AWS allows every company to set up its own cloud architecture. However, although AWS is providing basic security, it is still the responsibility of the company using AWS to set up specific security on servers, databases, caching and other parts of the architecture. 

inSided aims to be the best when it comes to cloud architecture and security and goes to great lengths to live up to this statement. inSided focuses on cloud knowledge when hiring new IT personnel and is (very) actively involved in the AWS community to spread knowledge about AWS, cloud architecture and security while at the same time get access to the best experts in regards to knowledge about AWS in combination with SaaS. 

Since inSided is constantly providing new functionalities in a changing (AWS) cloud landscape, inSided has incorporated continuous security tests in the development processes and changes in the AWS infrastructure setup, aligned with our ISO27001 certification, which is specifically focused on AWS security (including security groups, access levels, etc.). Next to this, there is a very active partnership with an AWS consultancy firm that is well known in the AWS community and has written numerous books about AWS (published by O’Reilly). It allows inSided to gain access to best practices and learn from other companies that are active in the SaaS field on an AWS architecture. 

When improvements are made to our AWS architecture (for example: server updates, scaling and security improvements, backup changes, etc.) the dedicated technical consultants are notified and approve the changes that are made. This includes documentation on the changes that are made to the AWS architecture including instructions on re-configuration of the whole architecture which in correspondence with our change management process and aligned with our ISO27001 certification. 

Architecture overview

The main benefits of our platform architecture are highlighted below.

AWS

• The inSided platform is hosted on AWS 
• AWS is ISO27001 certified
• AWS is PCI DSS Level 1 compliant

Data Location

• You choose the data center (AWS Region) where your community is hosted
• Data stays in the Region you choose. Data in the EU stays in the EU, data in the US stays in the US
• 100% isolated private network for each Region, no interconnectivity

Decoupled

• Critical components are decoupled
• Components communicate via messages
• No single point of failure

Multitenancy

• Load balancer & firewall (including SSL and latency checks to ensure nearby datacentres are used)
• Separated databases per customer
• Separated file & statics storage per customer
• Custom configuration per customer

Secure

• Servers and clusters separated with internal firewalls
• Security against Denial-of-service attacks on Endpoint level per customer with a built-in AWS Firewall
• Continuous Integration incorporated in AWS infrastructure change deployments

Scalable

• Infinitely and instantly scalable to take on traffic spikes
• Autoscale when certain thresholds are reached
• Scalable in different regions/continents

Architecture Details

VPC

The InSided platform is based on the best practices coming with AWS VPC. InSided works with DTAP environments, each environment has its own separate AWS Account, with one VPC per supported region. For production InSided has a fully isolated private network for both EU and US environments. There cannot be a connection between any of the VPC’s. Meanwhile also Development, Test and Acceptance have completely isolated VPC’s in their respective AWS accounts with the exact same configuration as Production. Each of the environment is independently scalable. Builds of changes are done in a central place. Deployment of the built code takes place inside the VPC of the environment (the pipeline is part of the private network and has no artificial access).

Isolation

The platform is for each environment strictly isolated in the private network that VPC provides. Internal traffic between the services happens with synchronous requests over HTTPS API’s and messages over AWS SNS. This internal traffic makes use of IP addresses that are defined in rfc1918 within AWS Private subnets. Also, services are isolated by Cloudformation stack and configured with AWS Security groups to grant access between services where appropriate. Resource sharing between stacks is logically disallowed, bringing the benefit to scaling per service to the actual demands of the platform. As a consequence, only what is in the stack affects the scaling, monitoring and logging of that service, resulting in more resilience and predictability. We communicate between services by making use of HTTPS (synchronous) and SNS (asynchronous messaging).

External traffic

External traffic is only allowed through SSL protected front-end applications and the Public API. Those external components interface with our platform by only making the SSL protected endpoint public, while keeping everything behind it private (e.g.the  API is a private service in Private Subnets, with only the endpoint of the Elastic Load balancer in a Public Subnet).

There are 3 ways to access those public applications: 

• Guest access a.k.a. visitors (web applications) 
• Logged in access with a Session Cookie (web applications)
• Token access (API)

To avoid abuse of the community endpoints, AWS WAF is deployed as a Firewall in order to mitigate threats. Amongst others Rate limiting (Client and XFF), Bad bot protection, Injection protection (XSS, SQLi) and IP Block lists are applied and monitored.

For management purposes InSided also allows access through a bastion host per VPC. The bastion host is only accessible under strict permissions (restricted location, ssh keys per InSided administrator). For outbound traffic each VPC is using a NAT instance. 

Scaling

In order to ensure that the platform can handle high peaks of traffic and assure availability, web applications are built by using AWS Autoscaling together with AWS Elastic Load Balancing. In several cases serverless components are chosen to make scaling of services a non-event. Due to the isolation of stacks, each of the services can scale independently to current demand. By delegation of work by applying messaging in the background, performance can be guaranteed while still the low performance tasks are performed in the background.  

Tech stack

Web applications are built with PHP, management services and asynchronous services can be running in Python. The core of the inSided platform is built in-house. In order to not reinvent the wheel and provide more guarantees, InSided chooses pre-built software libraries and frameworks that are well tested and monitored on security vulnerabilities by central systems like packagist. 

By choosing AWS services as a baseline for the Community platform, InSided chooses for the stability and resilience that AWS has built up as one of the primary cloud providers. This consists amongst others of EC2, RDS, Elasticache, S3, Autoscaling, Route 53. 

InSided furthermore makes use of the following AWS concepts 

• Multiple Availability zones for Application and Database layers 
• Daily snapshots and off-site backups for full database recovery 
• Point in time restore for recovery per minute 
• Message driven architecture to decouple processes through AWS SNS 
• Infrastructure as code with Cloudformation to avoid manual mistakes
• Testing strategies and Continuous Integration

Encryption

Encryption in transit, encryption in rest, isolation of services, security groups, network routing, subnets, audit logging and server hardening are part of InSided’s responsibility and practices, most often by using the tools and practices provided by AWS.

Databases have regular configuration improvements to increase performance. All databases are encrypted in rest with Amazon KMS (AES) by default. Databases are always running in private VPC networks and protected by AWS IAM. 

Technology stack

inSided works with a technology stack that enables us to easily scale, add new functionality and keep everything extremely flexible for our customers while maintaining SLA’s.

The stack also allows our customers to change the core features of the platform within their own domain. 

Custom(er) loadbalancers & firewalls 

The entry point for each end-user consisting of a loadbalancer & firewall per customer which can be used with SSL. The customer can setup a CNAME record for the chosen domain names that point to this loadbalancer. Whitelist and blacklists can be setup if needed (customer option). 

Full page caching

If full-page caching is enabled (customer option) page loads for non-authenticated users will be loaded from cache. Time To Live (customer option) is a standard set to 3 hours.  

Look and feel

The front-end look and feel can be adjusted by configuration in the Control Environment. Administrators can change the community configuration including styling, branding, the setup of reward management, the community structure, (featured) content, profile fields, custom user roles, platform visibility, etc.

Configuration loader

The configuration loader includes our domain validation mechanism. The domain should be a valid ‘holder’ of an application within the inSided platform. If this is the case then the request is allowed to proceed and the current configuration is loaded from cache. If the configuration is not available from the cache it will be created from the different available configuration layers: 

• inSided default
• Customer-specific
• Application general

Application

The application loader will fetch the right application from the application repository and provides it to the incoming request from the configuration loader. The fetched application is loaded and handles the actual HTTP request. It scans the request (data) for malicious content or security attacks on an application-level among which: 

• XSS attacks
• Man-in-the-middle attacks (CSRF)
• SQL-injections
• Spam

REST API

The REST API uses an authentication mechanism, which ensures that only authorized requests are allowed to fetch, store, update and delete data. When a fetch request is available in the REST API cache this is always served. If there is no cache available the request is scanned for malicious content (see 6) and handled. The caching gets refreshed when the TTL (Time To Live) is reached or when a certain data set changes. 

Workers

Workers make sure the layers within the stack can communicate via a series of central (scalable) queues (see 11). By using workers inSided has enabled a true decoupled system that makes components independent of one another. Different types of messages are communicated throughout the system: events, notifications (including e-mail), logs, etc. Workers also make sure that the data between our search database and relational database systems are in sync. 

Database cluster

Every customer has its own relational database which is hosted on the scalable platform. The relational database holds all the important data like authentication, authorization, users, content, settings, etc. 

Search & Analytics

inSided stores all events, analytics data and searchable content in separated services that allow storing huge amounts of data per customer while maintaining high availability. Those systems are highly scalable and are used to perform complicated calculations and serve all data in real-time whenever, and wherever, needed. 

Messagebus

Messagebus is used to allow components (layers in the stack) to communicate.

Datatime

Datatime security stores everything that happens within the community. It is the default logging mechanism and allows for inSided to restore a community back to a certain point in time up to the nearest seconds.

System Development Life Cycle (SDLC)

The SDLC that is used within inSided has been adapted to the needs of our customers and allows our multidisciplinary development teams to work agile with an absolute focus on delivering secure, fast and feature-rich applications and architecture while maintaining full focus on our customers. 

inSided has implemented an agile workflow for all development teams to ensure a smooth transition from idea to a fully tested feature on production. By handling the development work this way the developers are able to adapt rapidly to new priorities on a day-to-day basis, which is necessary to serve our customers with the agility they need in order to create successful communities. 

inSided has built-in security and privacy checks throughout every stage in the development process. Via a strict protocol, in combination with regular internal (and external) audits by certified ISO 27001 auditors, inSided is able to ensure this protocol is followed while maintaining the flexibility to change requirements in the development process. This protocol enforces functional, security and load tests from the early stages of (technical) design up until the final deploy to the production environment. 

DTAP (Development, Test, Acceptance, Production) is used to bring structure to the several phases on which deliveries and user acceptance tests are performed to the product teams. Test and Acceptance are non-scaled versions of the Production environment. The Acceptance level environments are available to our partners and customers to test integrations like SSI, SSO and API connections and making sure they work properly.

Development stages

Within the development process, inSided identifies the stages below which are enforced by a continuously integrated pipeline in which code changes can only occur by using a pre-defined and automated process. inSided processes are reviewed bi-weekly by the development teams during a retrospective and optimized if necessary. All procedures are available in full detail for inSided employees via the inSided intranet. 

Creation

The Product Owner creates functional requirements based on input from business requirements. These requirements can arise from different sources including customer requests, technical requirements/maintenance and general platform development requests from within inSided. In most cases, the IPB is notified of the functional requirements that are packed in a ticket (called an ‘epic’ in terms of Kanban) to decide if the ticket is corresponding with business needs. 

Refinement and estimation

After the Product Owner finishes the functional requirements in an ‘epic’ or ticket, they are reviewed by one of the IT Architects. They ensure that threat/security assessments and load reviews are performed, prioritize and describe risks in regard to the new functionality and in which part of the system and code the change should be made in order to deliver the functionality. In most cases, the IT Architect and Product Owner meet directly to the developers within the development teams to ensure that both the functional and technical requirements are clear. During these meetings, the actual refinement and estimation of the amount of work are done including the discussion about what tests and (technical) documentation is necessary for the required functionality. This is mandatory before tickets can move through the pipeline to be worked on by the development teams. 

Building

The deliverables are (usually) created via TDD (Test Driven Development). Coding is done and architectural changes are made on the development and test environments at first. After changes are made to the code and/or architecture on the development environments they are sent to other developers via Pull Requests (PR). These PR’s allow developers to review and test each other changes by discussing the changes that have been made and asking questions about certain decisions. Only after a certain amount of approvals from other developers the changes are accepted onto the test environment where it will be extensively tested (both automatically and manual). Usually, the creator of the change and the persons who are responsible for approving the change do this. 

Automated Testing

inSided uses Continuous Integration (CI) as a way to ensure a smooth-running delivery pipeline. By ensuring that automated tests are added before/during/after the development of functionality inSided can maintain a stable platform without regression and a speedy development process. inSided uses automated tests for part of the system (Unit tests) but also end-to-end tests (Acceptance tests via Selenium) on a multitude of browsers/platforms. These include OWASP level tests including XSS, SQL-Injections, etc. and are performed on every code change (commit) to the codebase  (see next chapter). 

Manual Testing (QA)

The shippable deliverable is tested thoroughly by our Quality Assurance (QA) engineers. Testing is done with numerous tools and browsers to identify possible flaws in software and architecture. If a vulnerability is found or a test fails, the specific deliverable is put back into the development pipeline. In order to maintain an agile delivery pipeline inSided has chosen to make QA engineers part of the development teams. They are in sitting with the developers and can discuss issues when they occur. QA engineers are partly responsible for ensuring that the acceptance test coverage is correct and that edge cases are covered. QA engineers also check up on documentation (although it is not yet final in this stage) and give feedback. QA engineers have a list of standardized manual tests, which are always performed. This list is continuously improved when new functionality becomes available.  

Documentation

When the changes to the codebase are finalized the (technical) documentation should be delivered within the ticket. This is usually done via a shared document and/or internal development Wiki. In most cases, the documentation is already available and checked by the QA engineers. Note that in some cases there is no documentation is necessary and this step is skipped entirely. 

Product Owner approval

When the deliverable is put to the staging environment it is production-ready including documentation, tests, and approvals from other developers and the QA engineer. The Product Owner’s approval is the final stage before the actual release of the deliverable. During this approval, the Product Owner will look at the functional and business requirements of the ticket. The Product Owner can, in some cases, ask for a demo from the development teams to ensure that everything is as it should be. When the Product Owner approves the deliverable it can be deployed. If the Product Owner decides that the deliverable is not yet good enough a decision can be made to run it through the pipeline again or to make necessary (small) changes as a hotfix.

Release

The deliverable has been fully tested and approved by the Product Owner. It will be released during the next release cycle, which happens several times per day. The deploy to the production systems is done automatically and includes a retest from the deploying developers. The development teams are able to deploy themselves and are directly responsible for the production environment.  

Review (retrospective)

The inSided development teams have a bi-weekly retrospective meeting in which they improve their way of working by focusing on better quality, speed, communication and take away any impediments. This review moment has led to a series of great productivity improvements for the development teams and ensures that technical priorities (like maintenance) are discussed during the IPB meetings.

Continuous Integration

inSided uses Continuous Integration (CI). It allows the development teams to ‘fail fast’ and continuously integrate each other’s code while developing new features. This is important when there are multiple development teams working on the same platform and codebase. 

During the CI ‘builds’ are continuously created which test the new code changes in the system. Only if a build succeeds the change can move to the next phase. inSided developers are running the tests locally before the CI pipeline is actually used so failed builds are exceptional. 

The builds are divided amongst several parts (repositories) of the system which are all tested on every change in the architecture and/or code on the test and staging environment in our DTAP street. 

API cluster

The inSided API cluster holds all architecture and functionality for the REST API that serves data to the application cluster, customers/partners, etc. 

Application cluster

The inSided Application cluster holds all the applications and core functionality that is visible for end-users of the platform (including admins/moderators). 

Worker cluster

The inSided worker cluster holds all functionality to keep the architecture decoupled and ensures that the queues are always empty. 

Search synchronization

The inSided Search synchronization makes sure that all content in the relational database is synchronized with the search cluster that makes content available to our API and Analytics modules.

All of the above parts of the inSided architecture are automatically tested in the CI pipeline. However, also manual (QA) testing is performed to ensure that edge cases are also dealt with. The automated part of the testing includes at least these items:

• Lint check
• Unit tests 
• Acceptance (end-to-end / OWASP) tests 
• Mess detection
• Test coverage metrics
• Complexity metrics
• Duplicated code
• Code standards (PSR-2)

Application security

Apart from the general architecture, the inSided platform, which includes all the modules (applications), is secured in different areas. 

inSided has built its security component in such a way that it can be reached from every area within the stack and is automatically implemented in new modules. The security component includes the following:

Chinese walls

The inSided platform has been built with principles like Chinese walls being a key element from an architectural and security point of view. Allowing our customers to be separated on almost every layer in the technology stack (including loadbalancing, API, database, configuration, look & feel, caching, etc.) ensures a secure platform while still benefiting from the multi-tenancy as a key-feature. 

Authentication & authorization

The extensive authentication and authorization system provides strict control over every module and features within. The system ensures a safe journey through the platform while maintaining access levels for each individual users and content holders (forums, blogs, control, social knowledgebase, etc.). All actions are logged and can be easily traced back. 

Data validation (input & output)

All data, which is provided to and from the system, is controlled via our data validation system. The system ensures a specific level of consistency when it comes to data validation and purification that is available throughout the platform. Data is only allowed to pass through when it meets the requirements and validation rules (XSS, SQL-injections, etc.)

Datatime security

inSided’s datatime security feature records (logs) every action of every single visitor (including guests, users, moderators, spiders/bots, etc.) in a centralized event-system to ensure easy insights after a certain event, like spamming from the user, has taken place. Datatime security allows inSided to restore a community back to a certain point in time up to the nearest seconds. 

CSRF security

inSided has a centralized security component against CSRF (Cross-site-request-forgery) in place. This ensures only requests from controlled environments are allowed to pass. Requests to the inSided platform need to come with a valid token that is only available to control (inSided) environments. 

Object validation

To ensure only validated objects, like users and topics, are used in the front-end layers of our components, inSided has created the object validator. When an object is used in the front-end templates that request data from our application layer, it has to be cleared by the validator. If a used object is not validated an error is returned. 

Domain validation

Domain validation is used to ensure that requests are only performed from pre-defined whitelisted domains. This is especially important when customers are using client-side JavaScript embed codes for integrating inSided components in their website. 

Data access

The inSided REST API is the only layer within the technology stack that is able to access databases directly. Fetching, storing, updating and deleting data is not possible in any other layer. 

Password hashing 

Passwords are hashed using bcrypt hashing. Bcrypt has salts built-in to prevent rainbow table attacks that are used to guess passwords. 

E-mail security (SPF, DKIM and DMARC)

The inSided platform supports the use of SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) and DMARC (Domain-based Message Authentication, Reporting, and Conformance) to ensure the safe sending of e-mails from the inSided platform. 

Using your own mail server to forward mails sent by the inSided platform is not possible, as we set it up to be all handled by Amazon SES 

Data transfer in and out

End users access the insided platform over the customer-specific public endpoint of the community. The applications here include. 

• Insided community platform
• Insided control panel (client-facing back office)
• InSided Embeddable widgets in customer’s sites

End-users can make use of those applications either as a Guest or Logged in user. In both cases a session exists, which is used in the back-end to determine the identity of the user. Https is always enforced and the only things that the users can access are the public endpoint of the tenant. In order to allow for SSL termination per customer, a cloudfront distribution is placed in front of the application. Logically it looks like this. In practice, the services architecture behind it is more complex, but it all follows the same pattern.

API access and integrations

Every customer can request its own API key and secret to make use of the inSided API. With this API key, customers can access their own data from their own data centers and systems. Customers can also choose to enable one of InSided’s integrations with 3rd party systems, in which case the customer assesses the risk whether to enable or not.

Management

A very limited amount of InSided employees can access the private VPC network by making use of the bastion host. On the bastion host, there is a restriction on the users SSH key, passwords are disallowed. Access gets revoked as soon as their AWS account is removed. The access to the bastion host is restricted to the inSided office & VPN. With host-level monitoring, we monitor if repeated access attempts are made.

Data storage

The database layer in the inSided technology stack database consists of two parts. The first part is the relational database that stores the platform most important data like topics, users, authorizations, etc. The second part holds all the community events and analytics data.

All databases run on redundant architecture components that are able to scale to multiple locations to ensure Service Level Agreements are maintained. Data centers that host our architecture, and databases, are compliant with several security standards and certificates.

ISO 27001:2013

Achieved ISO 27001 certification of the Information Security

Management System (ISMS) covering infrastructure, data centres and services.

inSided makes use of the AWS shared responsibility model in which AWS is responsible for securing and certifying the foundation infrastructure (Security of the Cloud)

https://aws.amazon.com/compliance/shared-responsibility-model/

Database encryption

All community data, managed through Amazon Relational Database Service (RDS), are encrypted in REST by using AES-256 encryption.

Our cryptographic keys are managed outside the inSided architecture using AWS Key Management Service (KMS).

Characteristics

• Using the Advanced Encryption Standard (AES) algorithm in Galois/Counter Mode (GCM), known as AES-GCM
• Using 256-bit secret keys
• Using only symmetric encryption

Backup policy

Although all data is stored in multiple zones in our data centre architecture to ensure real-time availability, inSided considers the creation of backups a core functionality and responsibility for its customers and thus it is considered equally important as other core features like CSRF and XSS security.

inSided creates off-site backups of the primary database including all primary data including all content, users, configurations, etc. inSided can easily restore a community to a certain point in time if necessary by using our point in time feature. 

Analytics and event data backups are continuously updated in real-time while changes occur. These backups can be restored quickly without interfering with the core system(s) which means less (or in most cases none) downtime. 

Static files like templates, CSS, JavaScript and images are synchronously back-upped to external disks in our secure data centres. 

inSided has a backup recovery plan in place which is integral part of our ISO27001 implementation. Backup recovery plans are periodically tested to ensure that they work flawlessly and are indeed effective when needed.

inSided has the following objectives set:

Privacy and data policy

inSided wants to make sure our (international) customer base can provide their end users with the right privacy settings, terms and conditions and more. Lots of privacy options are available to the end user to ensure a safe visit to the community. 

inSided’s general data policy is compliant to the Privacy Directives which describes the protection of individuals with regard to the processing of personal data and on the free movement of such data. However, each customer is able to create its own conditions to which the end user consents. 

Customer data 

• Customer is (legal) owner of the data
• When a customer decides to end the contract with inSided all of the data is transferred to the customer 
• Data includes database dump(s) and static files (images, CSS, JavaScript)
• inSided is not allowed to use customer data for any purpose other than providing services (like analytics) for the customer

Platform options

• Custom terms and conditions to which the end user agrees before creating an account
• End user can hide certain profile fields
• End user has several settings available for (turning off) notifications
• Hide information per user, group, level, status, rewards, etc.

Cookies

inSided uses cookies for certain parts of the functionality. An overview is available upon request. InSided recommends terms and conditions that explain the usage of the cookies, while the customers can make changes and improvements. 

Please note: a selection of customers has implemented a system on the inSided platform to get explicit permissions from the user to place non-functional cookies.

Data removal policy

In line with European data regulations (GDPR) shall inSided commit to removal of all customer data, including all personal data of consumers, upon termination or expiration of the service contract.

The data removal policy and procedures tap into all relevant sectors of the inSided Customer Success Community Platform across the architecture and application layers. The following sectors are manipulated to make sure all customer data is safely and thoroughly removed.

Sectors

• Builds and backups
• Static File Delivery Storage (AWS Cloudfront and S3)
• Databases on all development instances and release stages, including local environments (DTAP)
• Offsite backups related to Disaster Recovery Plan (DCP)
• SSL domain certificates
• DNS records (AWS Route 53)
• Load balancing instances and logs (AWS Elastic Load Balancing (ELB))
• API key/secrets for all environments
• Configuration settings
• Event store
• Technical analysis and consultancy exports
• Search indexes

Integrations

The inSided platform can be seamlessly integrated into any existing website, portal, intranet, etc. This can be achieved via several options among which the following. 

Domain 

By allowing users to visit the inSided platform via a customer domain (e.g. ‘community.customer.com’) a seamless integration within the customer’s ecosystem can be created. Users will not notice the fact that inSided is hosting the platform. 

How

By filling a CNAME record in the DNS records of the main domain (e.g. ‘customer.com’) with the value of the custom load balancer created by inSided for the customer. 

Look & feel

Several options are available for allowing our customers to change the look & feel of the inSided platform. inSided can make sure the look & feel of all the features matches the company style by configuration of the complete style guide. Combined with Server Side Includes (SSI), which allows customers to include pieces of front-end code from existing pages like headers en footers, this will result in a completely integrated look & feel. 

Single Sign On

By supporting multiple types of Single Sign On (SSO), inSided allows its customers to create a seamless flow for its users when it comes to registration and signing in/out. By using internet standards like SAML2, oAuth 2.0, OpenId Connect or Social Logins like Facebook, LinkedIn, etc. 

How

An SSO implementation begins by investigating and deciding on the best possible SSO method for the customer by using documentation and reviewing internal/external requirements. After the decision is made to use a certain type of SSO, and based on what type is chosen, a link between the (staging) systems is created. The systems are enabled, tested and can be rolled out to production when testing has been successful. 

API

All of the inSided applications are all build on our own API. This ensures that our customers have access to all their platform data within their domain. The API is equipped with an extensive caching mechanism to ensure quick loading of data. The inSided API can be used to build custom applications, combine data with other parties, import and synchronize users, etc. 

How

To access the API, the customer needs to enable a certain application by creating an APIKEY & SECRET combination via inSided control. With this combination certain parts of the data set can be accessed (GET) or created (POST). Our analytics and monitoring systems are enabled on all API calls to ensure a safe transaction.  

CRM data

inSided offers the possibility to create (custom) profile fields to store extensive amounts of CRM data. The CRM data can be used in the customer templates if they are given the flag ‘public’ but can also be used as a data field that is only accessible by administrators. CRM data can be stored or read via the inSided REST API, Single Sign On method (mapped to SSO fields) and bulk- import and export via an automated process. 

How

By creating profile fields via inSided control, customers are able to store CRM data on the inSided platform which can be used for a variety of purposes including (but not limited to) showing data in templates, combining data with external sources, filter users and related data (like posts, topics, articles, etc.) on CRM data, etc.

Monitoring

inSided has an extensive range of internal and external services that monitor the full range of the platform 24 hours a day, 7 days a week.

The main (internal) tool monitors individual components on both architectural/network and application levels. External tools monitor uptimes, latency and load from a multitude of locations throughout the world. 

By using our datatime feature we are able to log everything that occurs on the platform; from webserver logs to user events. It enables inSided to quickly respond to certain events and act accordingly. 

inSided monitors the health of the servers in real-time and has a system in place that automatically replaces (virtual) instances which are not performing according to our standards. 

By using unit and functional tests in our continuous integration we are able to quickly scan for application failures in early stages and are able to automatically roll back/forward releases when necessary.

Security testing

Our platform is continuously tested by independent organizations on behalf of our customers and/or the internal security departments. The inSided platform is tested against several OWASP levels. 

Security tests

Security tests include:

• Injection: SQL, OS, LDAP injections
• Cross-Site Scripting: untrusted data insertions
• Authentication and Session management: assume identities 
• URL Access: unauthorized access
• Invalidated Redirects and Forwards: redirects without proper validation 
• Insecure Cryptographic Storage: weakly protected data
• Insecure Direct Object References: access control
• Cross Site Request Forgery: forged HTTP requests
• Security configuration: platform and architecture
• Insufficient Transport Layer Protection: encrypted network traffic

Change management

inSided works with a strict change management procedure which includes excessive security testing of all changes which are made to the platform (architecture and software). Tests and code reviews are performed during several times in the process. The following tests are performed for each individual change:

• Validation insert data (XSS, SQL injections)
• Validation output data (SQL, encryption/decryption) 
• Validation system level (CSRF)
• Validation between components (CSRF, queues) 
• Penetration tests (architecture changes)
• Capacity/load tests (periodically)

We invite every customer to perform security and penetration tests. However, please inform inSided before the test takes place so that our security tools can be configured to allow a (limited) attack during a certain timeframe.

ISO 27001

inSided is aware of the fact that our customers demand the best possible security regarding the platform, data and services but also within our physical facilities.

We have an Information Security Management System (ISMS) in place that is based on ISO 27001, the international standard for information security. inSided currently is ISO 27001:2013 certified (renewed every year) and has been ever since April 1, 2013 (issue date of certificate by DEKRA).

The inSided ISMS is a dynamic governance system which describes all the current procedures and measures regarding information security for both internal and external use to meet the information security needs of our customers, the markets we are working in, the laws we have to comply with and the general standards we, as a digital company, have. We are continuously improving and optimizing our procedures within every layer of the organization. 

inSided has a clear view on threats, impact and risks when it comes to information security. Internal (a team of certified auditors is part of the organization) and external audits are performed on regular basis to ensure our standards are continuously met and possible improvements are registered and followed through.

Environment

Cloud computing is more environmentally friendly on itself since calculation power is distributed over multiple customers in need of such power to run their applications. 

AWS, the provider of the inSided cloud infrastructure, is very much aware of the demand for using 100% renewable energy to power the infrastructures of their customers. This is why AWS has a long-term commitment to using clean energy. Next to this AWS works hard to reduce the amount of energy which is consumed by its global infrastructure. This automatically means that inSided is benefitting from these efforts. 

AWS is focused on increasing the sources of renewable energy powering its infrastructure. AWS operates at a massive scale and has invested in significant hardware, software and operational efficiencies that drive several times improvement in server utilization levels as compared to the average corporate data center. AWS Infrastructure uses rack-optimized systems that use less than 1/8th of the energy of the blade server enclosures that are often used in corporate data centers. Because AWS pools resources, customers who deploy applications in the cloud reduce their carbon footprint by default and significantly reduce the amount of environmental waste that occurs when individual data centers don’t operate near their capacity.

Wind farm 

In January 2015 AWS announced it has teamed with Pattern Development to support the construction and operation of a 150 megawatt (MW) wind farm in Benton County, Indiana, called the Amazon Web Services Wind Farm (Fowler Ridge). This new wind farm is expected to start generating approximately 500,000 megawatt hours (MWh) of wind power annually as early as January 2016 – or the equivalent of that used by approximately 46,000 US homes in a year. The energy generated by Amazon Web Services Wind Farm (Fowler Ridge) will be used to help power both current and future AWS Cloud data centers.