Vulnerability and security policy

Companies that run core parts of their operations via software from GX naturally value security and reliability. This page informs about this. Is there anything you're missing? Let us know. 

First of all, we start with independent certification. 

ISO certificate

You receive an ISO certificate the moment you act according to set standards. For instance, GX is ISO27001:2022 certified. This is a standard for information security. One of its components is that you must have a policy in place the moment a vulnerability becomes apparent. GX's policy and process are described below.

External libraries

XperienCentral is a product that uses external libraries. XperienCentral is a product that uses external libraries (pieces of pre-written code that are easy to implement). The main advantage of using external libraries is that it saves time, because you don't have to develop the functionality provided by the library. Instead, you focus on the core business logic: the functions that really matter. This means that vulnerabilities can occur in software written by others -than GX- (often referred to in the market as "CVE": Common Vulnerabilities and Exposures).

Roles involved

• R&D: Research and Development. This is the department where XperienCentral is made.
• Customer Services: the service desk that acts as a single point of contact and can be regarded as a source of information during a vulnerability.
• Architect: bears responsibility for high-level design choices, over the overall system structure. Architects collaborate in customer scrum teams.
• Technical Consultants: provide technical implementation advice and collaborate in organisations' scrum teams.

First (re)action - timeframe: execute within 1 hour

A vulnerability can have major consequences. Hence, security takes priority over all development work. The stringent deadline of 1 clock hour encourages this. 

• Starting point: an issue is reported by customer or colleague and this is logged in GX's service management system.
• Customer Services forms a group including a (product) architect.
• Customer Services links the incident to someone who can estimate its severity and impact.
• When the issue is created, Customer Services decides (in consultation with (product) architects, Data Protection Officer and Security Officer of GX) whether the severity is such that the issue must be made public. There are two possible outcomes:
   
  • No, issue is kept in the service management system with the attribute 'security' and treated as a regular issue that is processed in accordance with the Maintenance and Support Agreement.
    
    
  • Yes, in the case of High-High (NCSC validation) a more extensive scenario occurs, which is written out below.

Process at incident with NCSC valitation High-High

If the National Cyber Security Centre (the NCSC) has assigned the classification 'High-High', it means that a vulnerability has been found with both a high probability of the vulnerability being abused + high severity of the damage that occurs when the vulnerability is abused. Because we want to avoid any negative consequence, in this case GX scales up immediately and starts acutely informing customers and colleagues in real time so that appropriate action can be taken. This process is outlined below.

• Create communication channels:
  • Internal information page for colleagues
  • Make portal page available to inform externals
• Customer Services has a text written by R&D, system administration and Customer Services itself.
  • The initial text shows that the issue has been received and GX is investigating the impact and follow-up steps.
  • The page is in both English and Dutch.
  • The page enters the portal as the first article.
• Customer Services sends an update to all GX colleagues with the stated procedure and where to get internal information.
• The moment someone (customer or colleague) needs information, Customer Services refers the customer to the Portal page and the colleague to the Wiki page. The information on the Portal is updated as soon as new information is available and at least every two hours.   

An example in this process are the following pages: 

• Vulnerability in Spring4Shell
• Vulnerability in Log4J
• CVE-2022-42889 in Apache Commons Text library (Text4Shell / Text2Shell / Act4Shell)

Follow-up

Turns out there are no follow-up actions:

• Customer Services posts a closing message to indicating that the article is 'closed'
• Customer Services posts a short summary at the top of the Portal article "X was going on, we did Y so no more cause for concern".
• Customer Services closes the issue

Turns out it does have follow-up actions (e.g. patching/upgrading):

• Customer Services closes the issue in the service management system with a notification that GX will upgrade/patch installations and with which 'tag' these tickets are characterised
• Customer Services posts a closing message to indicating that the investigation is 'closed' for now and what's next.
• Customer Services posts a short summary at the top of the Portal article "X was the issue, we did Y and we are now going to contact everyone for appropriate next steps".

The text below discusses the procedure when it is necessary to approach all (or several) customers for a patch/upgrade.

Policy after the above is settled and Customer Services proceeds to patching/upgrading

Timeframe: maximum one week from discovery to patch placement.

When a product issue is discovered that is very sensitive and potentially affects several people (think security, privacy), Customer Services personally contacts the CISOs of each affected organisation to patch all installations as quickly as possible. Below is the procedure that is followed the moment serious incidents occur.

1. Provide a patch that has been checked by a technical consultant, business consultant and architect.
2. R&D determines in which versions of the CMS the issue occurs;
3. Check in which organisations use the version in which the issue occurs (and therefore needs to be patched);
4. Establish an overview to create structure. Purpose of the document is: 
   1. Keeping track of which installations need to be patched;
   2. Whether the contacts have been notified;
   3. Whether the contact person has read the message, otherwise;
      - send a reminder after 1 week;
5. Customer Services approaches the Chief Information Security Officer (CISO) of affected organisations. They indicate in the message what the issue is, what the impact is, what the solution is and how to test an implemented solution.
6. For speed and efficiency, standard operating procedures are allowed. Customer Services also adds relevant metadata so that reports can be made of it later. A minimal attribute is something that describes the vulnerability, such as 'Log4J' or 'Spring4Shell' and 'security'.
7. Reminders are sent automatically as soon as a contact fails to respond.
8. When patches are implemented, Customer Services provides another reminder of how to test the resolved issue. 

The further process sequence depends on the XperienCentral Release used (does it fall within the recency policy*) and whether the XperienCentral installation runs on the GX Cloud or whether the organisation itself is responsible for hosting.

• Used Release falls within recency policy and in GX Cloud: is patched for you by GX
• Used Release falls within the recency policy and organisation is responsible for hosting: GX provides patch, organisation takes care of correct placement itself
• Used Release falls outside recency policy: organisation submits request to GX for patching for their specific release and has its build scheduled at GX.

(* recency policy: GX provides support on Releases that are up to one (1) year old)

Communicating CISO

Customer Services acts directly with each organisation's Chief Information Security Officer (CISO) in these cases. If you are unsure whether GX has the details of your CISO, you can provide them here for completeness.