Whitepaper

Compliance for Third-Party scripts on your website

and how to ensure it

Compliance: as far as you know you are in control, but

what about your third-party scripts on your websites?

Index

About the author and Cert2Connect ..................................................................................................... 3

Why this paper?........................................................................................................................................ 4

Quick example of a script in our own website ................................................................................... 4

Out of reach ........................................................................................................................................... 5

Third-party scripts and ISO27001 compliance .................................................................................... 6

Annex A.15: Supplier relation management ...................................................................................... 7

Annex A.8: Assets management ......................................................................................................... 8

Annex A.9: Access control ................................................................................................................... 9

Annex A.12: Operations security ....................................................................................................... 10

Annex A.13 Communications security ............................................................................................. 12

Annex A.14: System acquisition, development and maintenance ................................................ 13

Annex A 17: Information security aspects of business continuity management ......................... 14

Annex A 18: Compliance .................................................................................................................... 14

Conclusion............................................................................................................................................ 15

How Reflectiz can help organizations comply with the controls described above ........................ 16

Reflectiz in a nutshell .......................................................................................................................... 16

Reflectiz supporting risks analyses. .................................................................................................. 16

Reflectiz and Annex A.8: Assets management. ............................................................................... 18

Reflectiz and Annex A.9: Access control.......................................................................................... 19

Reflectiz and Annex A.12: Operations security. .............................................................................. 20

Reflectiz and Annex A.13 Communications security ...................................................................... 21

Reflectiz and Annex A.14: System acquisition, development and maintenance ........................ 21

Reflectiz and Annex A.15: Information security in supplier relationships .................................... 21

Reflectiz and Annex A 17: Information security aspects of business continuity management . 22

Reflectiz and Annex A 18: Compliance ............................................................................................ 23

Compliance: as far as you know you are in control, but what

about your third-party scripts on your websites?

About the author and Cert2Connect

Tiennot van Dilst is a senior security veteran, who has been working in the information security

industry since 2000. His broad knowledge and experience include, but is not limited to, conducting

security assessments and pentesting and ISO implementation expertise. Tiennot has been a qualified

PCI:QSA and was head of delivery for an international security consulting firm, CSO at a hosting

provider. He is a security solution implementation and secure software development expert.

Tiennot has been serving as CTO for Cert2connect since 2019. Our mission is to help and support

clients in raising their security posture by automating various tasks and visualizing their security

status. By doing so, we believe we enable security professionals to look at their own environments in

a more offensive manner.

Cert2Connect BV is the go-to party in the field of advanced digital security solutions, security

services and cyber security. Cert2Connect helps large companies and SMEs achieve a stronger

cyber defense and better security risk management.

Our vision is that cyber security:

1) Should be easy to use and manage;

2) needs to be adaptively based on risk;

3) has to be continuous, automated and effective.

Whether it is on-premise, cloud or hybrid, Cert2Connect’s innovative solutions offer a

comprehensive series of advanced functionalities: everything users need in order to be able to do

digital business with confidence.

For more explanation about our vision, services and solutions, please visit our website www.cert2connect.com

Why this paper?

In my years in information security I have seen the overall maturity level grow. Many organizations

recognize the importance of information security. I see more and more organizations following the

secure development lifecycle principle when creating (web) applications. Security is becoming an

integral part of the complete product lifecycle.

However, on the other hand, many organizations are under a constant time pressure. Agile is the

keyword of the moment. Applications need to be finished securely, but releases are expected to

have a faster time to market, which means deadlines are more frequent. Websites and applications

are no longer a “IT only” party. The business is responsible, and it wants to get its information out

there as quickly as possible. It also needs to receive metrics back as quickly as possible.

Luckily, there is help out there. There is a lot of technology available, like premade scripts you can

embed in your application and/or websites that refer to third-party domains and will do some of the

work for you. Think about scripts and technologies like Google Analytics, tag managers, marketing

trackers, bots and reCAPTCHA, but also out of the box scripts (like, for instance, jQuery or cdnjs).

(See https://cdnjs.com)) These will introduce all kinds of nice features into your application, without

you having to reinvent the wheel.

On one hand, this is great: we have an easy way of getting all these additional (security) features. On the other hand, well …. Let’s first have a good look at what some of those scripts actually do.

Quick example of a script in our own website

I am taking Google reCAPTCHA as an example. Many organizations are using this, and, I am more

than happy to say, we are also using it on the Cert2Connect-site.

On our site, Google reCAPTCHA makes use of the following scripts:

https://www.google.com/js/bg/LDZrVZajNqBFLPI0dDPQFgDGzKBsBU5Mf63QslDcBME.js

https://www.google.com/recaptcha/api.js

https://www.gstatic.com/recaptcha/releases/zItNOfzbrqVGbb4QFYpPpcrw/recaptcha__en.js

Let us have a look at the following scripts:

https://www.gstatic.com/recaptcha/releases/P6KLRNy7h3K160ZmYNUOAce7/recaptcha__en.js

This script is focused on the forms part of the website, specifically on this page: http://

www.cert2connect.com/en/contact

And it specifically monitors the following fields:

search, contact_form, form_ncn_contact_form, tw_name, tw_last_name, tw_company, route-end,

tw_email, tw_telephone, tw_stay-informed, submit_form, gmap_key, route-start

Other than that, the scripts are communicating with various URLs one way or another. While there

are many more, for clarity I will provide two of those:

https://www.gstatic.com/recaptcha/releases/zItNOfzbrqVGbb4QFYpPpcrw/recaptcha__en.js

https://www.google.com/recaptcha/api2/bframe?hl=en&v=zItNOfzbrqVGbb4QFYpPpcrw&k=6LfBhFYUAAAAAIVrL3jdj2nzoK_sPwQlpGwuPNLG&cb=p5d32qn2lhma

You will find that the script is loading from https://www.gstatic.com (which is not owned, nor

managed by Cert2Connect) and some of the data is sent to www.google.com (which is also not

owned, nor managed, by Cert2Connect).

And basically the actions that are being performed are “accessing user input data” and “reading

session storage data”.

But wait. If those domains are not under control of Cert2Connect, what control do we actually have

over those scripts and the data that is sent there? The answer is little to none.

The scripts are located on a domain we do not control. So if anyone changes these scripts on that

location, how can I detect or even stop it? Also, the scripts control where the data is sent. Again, if

this is changed in the script (which I don’t control), how can I tell? And if any of the external domains

are being hacked, altered, sold or something else, how can I timely detect this?

Please keep in mind that the example above is just an example of a well-known Google application.

However, our site, as most sites, has various other scripts that are not as well-known. Some of them

have been there since before I started as CTO.

Out of reach

As you can see, even a widely used script like Google ReCAPTCHA introduces several connections

to external domains that are out of websites owners’ reach.

And to make things worse, the scripts are not running on your webserver, but in the browser visitors

use to visit your website. So, in many occasions, alterations, changes or mishaps within those

external part of the scripts will not be detected by most of the security solutions that are

implemented by the website owners. These can be considered blind spots on their security radar.

As you can see, from a security perspective, there are quite some challenges here for website

owners. How can they monitor this? How do they detect those changes, and how do they guarantee

the privacy of their visitors?

Third-party scripts and ISO27001 compliance

Other than security challenges, there are also many compliance challenges. Ever since several

major breaches like Magecart took place, those have been getting more and more attention of

auditors and supervising authorities. In this paper I will sum up some of the controls in the ISO27001

standard, which, in many cases, are overlooked when thinking about third-party scripts in web

applications.

However, before we really delve into those controls, it is very important to first take a quick look at

the ISO27001 standard itself. What exactly is it? Why is it there?

ISO27001 is not a standard operational standard, like for instance the PCI:DSS, that provides you

with a list of controls you need to implement to have a compliant system. No, ISO 27001 is more like

a high-level standard, that describes how you should set up a management system or ISMS. This

ISMS aims to create a process that ensures security measures are implemented correctly by

organizations.

Every organization is different, and the measures that are implemented can (and will) vary between

organizations. The company mission/vision, risk analysis, risk appetite and other factors determine

which measures are implemented. Each control can be used to determine the effectiveness of a

measure. It can consist of various measures, and each measure can help to cover several controls in

various business processes.

It is not mandatory to stick to the controls that are provided in the Annex A of the standard; these

can be considered a best practise. However, because those controls are implemented by the

majority of the ISO27001 certified organizations, in this paper I will stick to this default control set.

The Annex of the ISO27001 standard describes 35 control objectives, and has 114 controls. Many

organizations think that they should focus mostly on A13.2 and A15, however I strongly advice to

look at some of the other controls as well. Chances are the auditor will look at these as well when

taking a look at your organization, and specifically at the ‘website’ asset. The auditor would like to

verify whether you thought of all the possible risks.

As is shown in the example, third-party scripts and applications introduce additional attack vectors

and thus introduce additional risks, that in many cases are not monitored.

In order to keep this risk acceptable an organization can apply controls to monitor the risk and make

sure it stays within acceptable levels. In the following pages, I will go over the controls provided in

Annex A of the ISO standard, and my view on what they could imply when third-party scripts are

used on a website.

At the end of the paper, I will provide an overview of how Reflectiz can help reach a high level of compliance towards those controls

Annex A.15: Supplier relation management

I am starting with the most obvious control in the standard, as many organizations will think that

when these controls are in place, they are covered regarding third-party scripts. However, in many

cases these scripts are opensource, i.e. “without a real owner”. Also, one will see those scripts will

report to external domains and applications and make use of other external domains and

applications themselves. This implies that even if soft controls were sufficient, it would be very

difficult to get them in place.

An organization indeed needs to keep these controls in mind when working with third-party scripts.

Note, however, that these controls are created to monitor suppliers. Scripts and its domains are not

always a typical supplier. In many cases, the scripts (and the domains they report to) will from a

website user’s perspective be a part of the website itself. And, as noted earlier, in the case of open

source technology it can be very hard to make contractual agreements with the creator of the

scripts.

Next to that, there are some real big organizations, like Google, Facebook, LinkedIn, etc, that have

created scripts for you to implement on your site. Although you know “the owner” of those external

domains and applications, you are still not able to make agreements with those domains (unless you

are part of a real big organization) and can only accept their Terms of Service. In both cases, one

should really keep in mind the other Sections of the ISO27001 as well.

15.1 Information security in supplier relationships

There should be policies, procedures, awareness etc. to protect the organization’s information that is accessi-

ble to IT outsourcers and other external suppliers throughout the supply chain, agreed within the contracts or

agreements.

15.2 Supplier service delivery management

Service delivery by external suppliers should be monitored, and reviewed/audited against the contracts/

agreements. Service changes should be controlled

Annex A.8: Assets management

Information Asset management describes how an organization should be in control over its assets.

What assets does an organization have, and who is responsible for each of those. During the various

red-team activities I took part in, one thing became very clear to me. In most cases I found that the

assets that are part of the assets management process normally are secured correctly. The

organization knows what they are and monitors them closely. Any changes will be detected in a

timely manner, which gives an organization time to respond adequately. However, during the tests I

did in the past we (in most of the cases) gained access through assets organizations were not aware

off and/or were not correctly monitored and managed.

In relation to websites, I came to the conclusion that the parts of a website that were developed /

managed by a security aware organization are usually managed and controlled with security in mind.

Many of the important sites are pentested, code reviews are regularly performed and security

monitoring and other measures like WAFS routers and segregation are in place. However, third-party

scripts are in many cases overseen. Surely, in some organizations scripts are monitored for old

versions, but activity and communications are mostly left unmonitored. The same goes for the

domains scripts report to; I have seen domains changing ownership several times, without the

organization using those scripts on its website ever being aware.

There are many scripts out there. All of them have different functionalities. Some third-party scripts

monitor input data on your site, while others measure how many times a specific page is visited. An

organization should keep and inventory of the websites it is running and register which scripts are

running on those sites, who owns the scripts, and what they are intended to do.

Data classification policies should (amongst others) describe who or what can access which

information and by what means. The scripts of a website and the domains the scripts are reporting to

and running code from are in some cases accessing data that, in the mind of the visitor, is meant

only for the owner of the website. And an organization should clearly describe what data can be

accessed by which means. This also comes in handy when a visitor wants to know what happened to

his personal information. As a result of GDPR legislation, companies are compelled to provide this

info.

8.1 Responsibility for assets

All information assets should be inventoried and owners should be identified to be held accountable for their

security. ‘Acceptable use’ policies should be defined, and assets should be returned when people leave the

organization.

8.2 Information classification

Information should be classified and labelled by its owners according to the security protection needed, and

handled appropriately.

Annex A.9: Access control

Annex A.9.2 is all about user access management. The objective in this control is to ensure users are

authorised to access systems and services and able to prevent unauthorised access.

One could argue about that a script is not a user, however in some cases those scripts harvest data

users fill in. In some cases, this can even be authentication or credential data. Since an organization

not always has control over the scripts and where data is sent to, it is advised to strictly monitor what

is accessed, and where it will be sent to.

In the case of third-party scripts a company should clearly describe what is allowed, and what is not.

There should be a clear description of each script, which domains it is connected to, and what it is

allowed to do. This should be monitored, and if something changes, the script should be disabled for

further analysis.

As described earlier, some scripts read the data users enters on websites. And even scripts that are

not used to access data can eventually “change”. In many cases, third-party scripts load parts of

code from a forth or even fifth-party. If code changes in third-, or even in fourth or fifth party

domains, a script could start carrying out other tasks than it was intended to. Since this is out of

reach and control of the organization that owns the websites, and in many cases the scripts run in

the browser session of the website visitor, it is strongly suggested to monitor, from an end user

perspective, what is actually happening.

9.4 System and application access control

Information access should be restricted in accordance with the access control policy e.g. through secure log-

on, password management, control over privileged utilities and restricted access to program source code.

9.1 Business requirements of access control

The organization’s requirements to control access to information assets should be clearly documented in an

access control policy and procedures. Network access and connections should be restricted.

Annex A.12: Operations security

Annex A.12.1 is about Operational Procedures and Responsibilities. The objective of this area is to

ensure correct and secure operations of information processing facilities. Together with A13 and

A14, this section is what most of the auditors will focus on when looking at a website that belongs to

an organization that depends heavily on its website to do business.

An organization should describe how it stays in control over the security of its operational systems.

This is easier for self-created and controlled code and applications compared to third-party scripts.

As described earlier, the scripts sometimes connect to external domains. In order to monitor the

website as a whole one should keep this in mind. Controlling domains out of your reach most of the

time is not possible. Strict policies and procedures regarding the nature of the scripts should be

drawn up, and baselines should be created. Other than that, the need for monitoring third-party-

scripts, and how they communicate with external domains, should be recognized.

In case of 3rd party script monitoring this can be a challenge. Some of the scripts actually invoke

code located on a server outside an organization’s control. And to make matters even more difficult,

that code will not be run on the organization’s webserver, but in a website visitor’s browser. To

monitor the exact actions of those scripts, an organization has limited possibilities. One of the best,

and most exact, is to monitor the website as an external website user and see which scripts are

actually run when visiting a specific site. This way a baseline can be created. If, during a second

scan, something changes an alarm needs to be raised.

One can take an exact look at which scripts are installed on the webserver itself, however some

scripts can invoke scripts on external domains, which in turn can invoke other scripts (fourth-parties).

Even though for the website owner nothing changes, the website actually changes from a user or

visitor or application perspective. And to make it even more complex, this change could be different

for every single website user . Again, an organization has no control over an external domain, but an

organization could choose to monitor the website as an external user. And, if something from that

perspective changes to the site, even disable the specific functionality or script on its own

webserver.

12.5 Control of operational software

Software installation on operational systems should be controlled.

12.1 Operational procedures and responsibilities

IT operating responsibilities and procedures should be documented. Changes to IT facilities and systems

should be controlled. Capacity and performance should be managed. Development, test and

operational systems should be separated.

12.4 Logging and monitoring

System user and administrator/operator activities, exceptions, faults and information security events should

be logged and protected. Clocks should be synchronized.

Like any other kind of code, third-party scripts can be vulnerable as well. Many scripts (like for

instance jQuery) are updated on a regular basis. Make sure you keep an up-to-date inventory of your

scripts (which is also needed for asset management). Once you know which scripts you have you

can either keep track of the reported vulnerabilities or use a solution to do so.

*Screenshot of https://www.cvedetails.com/google-search-results.php?q=jquery&sa=Search

12.6 Technical vulnerability management

Technical vulnerabilities should be patched, and there should be rules in place governing software

installation by users.

Annex A.13 Communications security

Annex A.13.1 is about network security management. The objective in this Annex is to ensure the

protection of information in networks and its supporting information processing facilities. This can be

a real challenge in the case of third-party scripts. As has been said many times already, some third-

party scripts communicate with a domain, which in many cases is out of the control of the

organization owning the website. In some cases those external domains also communicate with

other domains which are even less visible for you.

Networks have to be managed and controlled in order to protect information within systems and

applications. Simply put, Compliance for Third-Party scripts on your website and how to ensure it the

organization should use appropriate methods in order to ensure it is protecting all information within

its systems and applications. In the case of website security you will find that some organizations will

carefully review the scripts before implementing them. However, since some of the scripts

communicate with external domains, it is possible that this code changes and functionality changes

or is even used for other means. Therefore, an organization should not only review and research the

scripts upon installation, but also on a regular basis. The importance of a site to an organization

should be kept in mind when determining the frequency of reviews.

For instance, a static marketing website could have a very low risk rating that only needs to be

reviewed on a monthly or bimonthly basis, whereas a primary ecommerce site for a large web shop,

containing multiple scripts, should be analysed multiple times a day.

If something changes, the organization should have a way to disable the responsible script on its

website.

Policies, procedures and baselines can be drawn up in regard to third-party scripts (for instance,

take a look at the site from a visitor perspective) and see where the site loads from, what it loads,

and what it monitors. Next to that, it is very important to monitor which types of data are sent or

received. When no NDA’s can be closed with the external parties, risks should not be accepted.

Due to the organic nature of some of the scripts, continuous monitoring is advised.

13.1 Network security management

Networks and network services should be secured, for example by segregation.

13.2 Information transfer

There should be policies, procedures and agreements (e.g. non-disclosure agreements) concerning infor-

mation transfer to/from third parties, including electronic messaging.

Annex A.14: System acquisition, development and maintenance

Information security related requirements need to be included in any requirements for new

information systems or enhancements to existing information systems. When an organization uses

third-party scripts on its websites it should closely monitor how these scripts interact with website

users on one hand, and possible external domains on the other. Changes should be detected,

because in many cases these actually can very well be changes outside of your network.

The information involved in application services passing over public networks need to be protected

from fraudulent activity, contract dispute and unauthorised disclosure and modification. For services

being provided over a public network, like the internet, it is important to understand the risk levels

involved and the business requirements for protecting information.

When financial transactions or sensitive personal information are part of the service, it is especially

important to consider security to minimise the risk of fraudulent activity. GDPR comprises minimum

requirements for encryption and other safeguards. Once operational, it is important to ensure that

such services are constantly monitored for attack or undesired activity.

The very nature of third-party scripts makes it difficult to comply to this specific control. One should

keep an up to date inventory of which scripts (and versions) are used, what they are supposed to do

and with which domains they communicate. In case the script itself needs to be changed, strict

change procedures need to be followed. However, the external domains should be monitored as

well, and any changes to those domains should be detected and reported upon.

14.1 Security requirements of information systems

Security control requirements should be analysed and specified, including web applications and transactions.

14.2 Security in development and support processes

Rules governing secure software/systems development should be defined as policy. Changes to systems

(both applications and operating systems) should be controlled. Software packages should ideally not be

modified, and secure system engineering principles should be followed. The development environment

should be secured, and outsourced development should be controlled. System security should be tested,

Annex A 17: Information security aspects of business continuity management

Annex A.17.1 is about information security continuity. The objective in this Annex A control is

embedding information security continuity in the organization’s business continuity management

systems. In the case of third-party scripts in a website, which is important to an organization from a

business continuity perspective, one should - in many cases - look further than just their own

webserver. Many of the scripts are leaning on external domains that, if changed or inaccessible, can

cause (parts of) the website to not function properly anymore.

The organization must determine its requirements for information security and continuity of

information security management in adverse situations, e.g. during a crisis or disaster. One should

have a good look at the domains to which third-party scripts communicate, and ask yourself the

question: what if something goes wrong? What if, for instance, this domain is bought by another

party, can we still use the script then, and if not, what alternatives are there?

Annex A 18: Compliance

When working with third-party scripts, it is very important to have a good look at which laws your

company needs to adhere to, and to check on a regular basis if those scripts actually do so as well.

Even though illegit functionality might originate from an external domain, the organization owning the

website a user visits is still responsible. Scripts can have a variety of functionalities; inputs could be

monitored from other domains and cookies could be sent to the website visitor without the owner of

the website even realizing it (which, for instance, could create a breach with GDPR).

One should keep a clear track of what the scripts exactly do and make sure this is in line with local laws and legislation and their own policies.

17.1 Information security continuity

The continuity of information security should be planned, implemented and reviewed as an integral part of the

organization’s business continuity management systems.

18.1 Compliance with legal and contractual requirements

The organization must identify and document its obligations to external authorities and other third-parties in

relation to information security, including intellectual property, [business] records, privacy/personally identifia-

ble information and cryptography.

The screenshot above of the Cert2Connect site shows (via Reflectiz) which data is monitored by

what script and where it is sent to.

Another screenshot shows which cookies are read and written by external parties using scripts from

the website.

Conclusion

As you can see, scripts on websites can have a large impact on your compliance posture. Having

soft controls in place in many cases will not (fully) cover compliance; organizations are ultimately

responsible for the actions performed via their website. Even though, as the many cases above

demonstrate, it is not always possible for a site to fully control actions of a script, an organization is

responsible for monitoring them closely and, if needed, taking action as quickly as possible

How Reflectiz can help organizations comply with the controls described above

Reflectiz is a solution created to monitor third-party scripts. It is a cloud-based solution which

normally runs on AWS in Europe and GCP. The solution monitors a website as a “visitor’ and does

not need to install anything on the webserver of the website it monitors. In order to start monitoring,

a URL needs to be supplied, and if applicable credentials to log on to the site.

One of the major strong points of Reflectiz is, that it is easily understandable, as well as the output. It

takes humanly unreadable scripts, combines and groups them into applications and shows the user

the status in clear, understandable language. Instead of reading thousands of minified lines of code,

you will be presented a summary of the most important items, created by Reflectiz.

Below you will find a quick overview on how Reflectiz could help you to comply with specific sections

of the standard. I just shows some aspects of the functionality. For a full demo, please contact us at

info@cert2connect.com .

Reflectiz in a nutshell

As described above, Reflectiz is a solution created to monitor third-party scripts on websites. These

scripts are normally run in a visitor’s browser, and can have various functionalities and perform

actions. Reflectiz monitors those by automatically browsing the webpages as a “normal” website

visitor. That way the scripts are run, analysed and reported via either a provided dashboard, or

automatic email alerts and syslog alerts to a syslog server. Reflectiz monitors the scripts and the

domains with which those scripts interact, creates a baseline and warns about any changes to the

scripts on your website.

Reflectiz provides full insight about the script actions and the fields in the website that are monitored,

as well as some privacy-related actions performed on the website visitor’s console by third-party

scripts. Reflectiz calls its approach WWW (WHO, WHAT, WHERE): WHO are the third-parties,

WHAT are they are doing with regards to security and compliance and WHERE are they going with

your data.

Reflectiz supporting risks analyses

After the first scan of the site, Reflectiz provides the following data, thoroughly supporting risk

analysis.

Location of the domains: Reflectiz provides an exact overview of the domains that are in contact with your script and which data flows to them.

By clicking on a country you will have a complete overview of exactly which script is reporting to

which specific domain residing in that country. Note that some dots are yellow, which means these

domains did not fully pass the security checks and need to be looked into.

Popularity of the script: The Reflectiz monitoring provides information on how many times a

specific script is seen out in the field. If a script (like Google Analytics) is used commonly, the risk of

something being wrong with that script is lower than with scripts that are almost never seen.

Information regarding the domains: Reflectiz provides an exact overview of the domains which are

being used by the scripts.

Note that some domains are yellow, which means they did not fully pass security checks. (When those are displayed red, they are high risk). In this case, this domain was recently added to the site.

Vulnerability information (CVE) of the used scripts: If any of the scripts have known

vulnerabilities, Reflectiz will send an alert and present a detailed description of the vulnerability.

The screen shows detected vulnerabilities in the used jQuery script.

Reflectiz and Annex A.8: assets management

Reflectiz will give a very clear overview of the exact scripts and domains that are being used by your site in a

way that is readable. Anyone can open and see the scripts that are on a website, however they are not

humanly readable. Reflectiz presents them in a way that one can understand exactly what is happening. If

multiple scripts work together, Reflectiz graphically connects them and combines them with applications. The

owner of the website, or even specific scripts owners, can approve those scripts or mark them in the

dashboard for investigation (please note that Reflectiz cannot block anything).

Next to that Reflectiz provides information on what each script does on what field.

Reflectiz and Annex A.9: Access control

As shown in the screenshots of the previous paragraph, Reflectiz will provide a clear overview of

what is being reported to which domain.

Reflectiz can scan the site on a pre-agreed upon frequency. In the first scan it will go over the alerts,

and approve those if they show expected behaviour. By doing so you can create a baseline. If in

future scans any deviations to the baseline are detected, new alerts will be sent to you.

Reflectiz and Annex A.12: Operations security

As described and shown in the previous paragraphs, any changes in or additions of scripts or

domains will be detected. External domains are monitored. Any deviation of the previous accepted

baseline is reported. And, as shown in the below screenshot, Reflectiz reports about any known

vulnerabilities or CVE’s in scripts.

Reflectiz and Annex A.13 Communications security

If a new domain is introduced an alert will be sent. The overview of domains visualizes which

domains have been recently added.

List of domains on the left-hand side, on the right-hand side you see that a domain was added. Please note the yellow shield on the left side: it means that this domain needs to be looked into.

Reflectiz and Annex A.14: System acquisition, development and maintenance

As shown in the previous screenshot a full list of domains is available. The screenshot below shows a

list of installed scripts.

List of installed scripts on the left-hand side of the screen

Reflectiz and Annex A.15: Information security in supplier relationships

Reflectiz will show you exactly which third-parties use fourth-parties and who these are. Next to that an

overview of the status of the external domains is presented, and if something suspicious is detected, it will be

presented.

Overview of 3rd and 4th parties and their relations

Overview of the domains. Notice the colour on the left-hand side of the screen, a yellow shield means: attention required. On the right-hand side you can see the reason why: domain tracking. in case of serious issues (For instance if the domain is about to expire, the shield will be red)

Reflectiz and Annex A 17: Information security aspects of business continuity

management

By having a full overview of the script, what it is doing, and being alerted when the functionality changes,

Reflectiz enables you to map out exactly which script does what, and thinks about alternatives before they

happen.

Reflectiz and Annex A 18: Compliance

Reflectiz comes with a privacy dashboard, showing organizations exactly which data flows via their third-party

scripts, but also for instance which cookies end up on your client endpoint systems. Please note that on the

bottom right side of the screen a geographic map is presented, showing exactly where the data flows to.

Cookies from external sites

Monitoring specific input

Reflectiz and Annex A 18: Compliance (continued)

Cross domain trackers

For more info visit our website www.cert2connect.com

or contact us at info@cert2connect.com

Copyright ©2020 Cert2Connect. All rights reserved.