SLA is the acronym for Service Level Agreement, a contractual tool with which the service metrics that must be respected by the service provider (Cloud Provider) towards its clients are defined.
Specifically, the SLA relating to the service contract offered by CoreTech refers to:
In the diagrams we can distinguish the difference between IaaS and SaaS systems and the differences in responsibility for CoreTech as a cloud provider and for the client.
For IaaS services, CoreTech manages and is responsible for: Network, Storage, Servers and Virtualization. The client is instead responsible for: Operating System and all of the above installed.
For SaaS services, CoreTech manages and is responsible for the entire stack, from the Network to the Application. The client, on the other hand, is responsible for his own data and for the security inherent in the custody of the same and for the authentication parameters for the service.
By its nature, SaaS services having N additional levels compared to IaaS services, are subject to potential greater disruptions due to the components overlying the architecture, such as the operating system and installed applications.
For these reasons, the SLAs of services related to IaaS are generally higher than those related to SaaS services.
The following SLAs serve the purpose of giving indications on the levels of service that systems hosted in the CoreTech cloud can have. The servers hosted in the CoreTech cloud have the same network infrastructure, hardware and software as the systems whose service levels are shown on this page.
La gestione, la cura, il monitoraggio e la tempestività nella gestione dei server dei clienti rimane a carico del cliente e non di CoreTech, salvo diversamente concordato attraverso appositi servizi opzionali.
Therefore CoreTech with the publication of the following service levels guarantees that the network infrastructure is able to maintain high levels of SLAs and therefore minimum disruptions, but does not guarantee that the server of each customer can have the same SLAs, as it is only the customer is responsible for managing the servers for problems that go beyond the CoreTech cloud architecture.
October | Las 60 days |
99,986% | 99,951% |
Best | Worst |
99,998% | 99,888% |
October | Las 60 days |
99,975% | 99,869% |
Best | Worst |
99,993% | 99,759% |
The monitoring probes are located in another data center on an external network.
The systems indicated in the example are monitored constantly every 60 seconds.
The indicated SLAs are calculated from the average of the SLAs of the individual servers for each system considered.
For the indicated SLAs, the times of unreachability of services due to scheduled activities, such as reboots of operating systems or software updates, were not deducted. The monitoring probes refer to HTTP / HTTPS access and not to the simple PING of the system (which only determines its reachability).
It means periods of one or more minutes of disruption.
Partial minutes or intermittent outages for a period of less than one minute are not counted as outages.
Suspensions, technical assistance and maintenance as per contract art 16 and art 34 are not considered disservice.
Maintenance is indicated in advance on the page System Status
It means the total number of minutes in a month, minus the total number of minutes of outage in a month, divided by the total number of minutes in a month.
Inefficiencies are calculated on a monthly basis.
Example:
Calculate UpTime:
Uptime | Downtime by month |
100% | 0m |
99.999% | 0.4m |
99.99% | 4m |
99.9% | 43m |
99.8% | 1h 26m |
99.7% | 2h 10m |
99.6% | 2h 53m |
99.5% | 3h 36m |
99.4% | 4h 19m |
99.3% | 5h 2m |
99.2% | 5h 46m |
99.1% | 6h 29m |
99.0% | 7h 12m |
In case of disservice beyond the terms of the SLAs guaranteed in one month, the client is entitled to a service credit as the only and exclusive form of reimbursement. The client cannot unilaterally interrupt the payment of the monthly fees applicable to the service which is the subject of a complaint about disservice.
In case of disservice beyond the terms of the SLAs guaranteed in one month, the client is entitled to a service credit as the only and exclusive form of reimbursement.
To receive any refund request relating to the unexpected event, the client must notify CoreTech by opening a ticket to Technical Support within 7 days of detecting the event. Simultaneously with the opening of the reports to the support, the client must provide the server log files from which the loss of connectivity to the outside can be verified with the date and time in which such errors occurred, including by way of example the description details of the problem encountered, the number and users affected by the problem (if applicable), the description of the attempts made to resolve the unexpected event when it occurred.
If this information is not provided, the client waives the right to receive a refund credit.
With respect to a complaint related to Cloud services, CoreTech will evaluate all information reasonably in its possession such as logs and logs of its systems, reports of the monitoring systems or other information. At the end of the checks, no later than 20 days, it will determine in good faith whether the client is entitled to a Service Credit.
If the company (end-client) has purchased a service from a partner, the Service Credit will have to receive it directly from the reseller and the reseller will receive the credit directly from CoreTech.
IaaS | |
<99,95% (21m 54s) = 10% | |
<99,85% (1h 5m 44s) = 20% | |
<99,00% (7h 18m 17s) = 50% | |
SaaS | |
<99,8% (1h 26m) = 10% | |
<99,5% (3h 36m) = 20% | |
<99,00% (7h 18m 17s) = 50% | |
Example:
SLA <99,95%
That is, over 21 minutes of disruption
Refund Credit 10% of the service = 10 Euros
Recognizing 10% of the service value as a refund means recognizing the client a multiple of the value of the downtime of the service itself, for example, 10 Euros correspond to 4329 minutes of service. So a client who has an outage of 23 minutes, i.e. 1 minute longer than the minimum SLA level (99.95%), will receive a credit corresponding to 4329 times the price paid for the service per minute.
Version 3 dated 05/09/2024
Description | |
Remote cloud backup service
Link |
|
Roles and responsibilities | |
CoreTech acts as Manager or Sub Responsible for all treatments, while it is the owner of customer contact data only.
With regards to compliance and data security, CoreTech and the customer are both responsible albeit on different fronts. Link |
|
CoreTech Responsibilities | |
Daily check of the status of 1Backup servers and storage. Keep systems updated with the most stable and secure software versions released by the manufacturer.
Monitor servers to ensure continuity of service |
|
Customer Responsibility | |
Check the outcome of the backups daily. Adequately configure the backup jobs and related retention according to your needs. Carry out a restore test at least monthly/bimonthly.
Set complex service access passwords. Carefully safeguard Backup agent access data and limit its disclosure. Carefully protect the encryption password if it differs from the one used for the Backup agent. Inform CoreTech promptly of any anomalies that may lead to a data security problem. Intervene promptly in the event of reports from CoreTech on problems relating to the service. |
|
Datacenter | |
TIER4 - It is the highest level of guarantee that a data centre can offer, with 99.9% availability. Identifies a data centre that is completely redundant in terms of electrical circuits, cooling and network. This indicator refers to an architecture that allows you to deal with serious technical incidents without ever interrupting server availability.
Link |
|
Geographic location | European Union |
Labeling | |
The software does not offer standard levels of information classification. However, the client can apply labels and possibly a classification level through the machine name or create a suitable group for privacy. | |
Features available on the Control Panel | |
1Backup has 2 control panels available. One Dedicated and one on Sygma. The customer is autonomous until the closure of their Administrative account associated with the instance (Reseller account). The deletion of the agent does not terminate the service. Once the agent cancellation is requested, a tracking email is sent. | |
Admin Panel | The user can choose the algorithms and encryption key length for the backup. The user can choose which data to back up, schedule its frequency and destination. The user is autonomous in setting their own Retention policies. The Admin user and agents' passwords must comply with minimum security criteria. It shows the number and outcome of backups, restores, modifications, and backup set and data deletions. |
SLA | |
Monthly SLA 99,8% (1h 26m) Ordinary and extraordinary maintenance activities reported on the site 24 hours in advance are excluded (except for emergencies related to safety problems that require our immediate intervention) |
|
Penalties | |
SLA SaaS <99,8% (1h 26m) = 10% <99,5% (3h 36) = 20% <99,00% (7h 18m 17s) = 50% for more information visit the site https://www.coretech.it/it/service/systemStatus/SLA_servizi.php |
|
Backup | |
The service is offered with 1 replicated storage (Backup Set) The Backup Set is replicated on Cloud Storage S3 - located in a Data Center outside Italy in a European Union country. The user is autonomous in setting his own retention policies and verifying their outcome through monitoring. |
|
Problem Tolerance | |
Multiple Servers |
The servers that provide the 1Backup service are different. These servers are virtual machines residing on Vmware clusters consisting of 3 physical nodes. The customer should take care to allocate the Backup agents on different servers. The Backup Servers benefit from the Stellar infrastructure. Stellar site |
Configuration Storage Raid6 | The disk configuration of the backup destination storage is RAID6. The storage on which the data backups reside has dual power supplies and dual network connectivity. The disk controller is double. |
Disaster Recovery | Backup set to another Datacenter in S3 mode |
Support | |
Support Page - Link | |
Access to Data | |
Available and web interface or specific client software.
The customer is the only one who has the passwords to access the archive boxes. CoreTech cannot access the data as it is encrypted. |
|
Contract Cancellation / Closure | |
The user is autonomous in the cancellation of their data. If not canceled, CoreTech will cancel them after 30 days from the cancellation of the service. To request cancellation of the service, you must send via pec coretech@pec.coretech.it within 30 days from the automatic renewal of the service. |
|
Portability | |
The data can only be exported using Restore by the customer | |
Assistance process for the satisfaction of the rights of interested parties | |
Data Processing Agreement (DPA) - Link page | |
How personal data breaches are handled | |
Data Processing Agreement (DPA) - Link page | |
Evidence Collection | |
If the customer needs to collect evidence or request assistance, he can send the request to the email address ufficio@coretech.it, in the event that the assistance requested is not the responsibility of support or for other reasons, he can contact the Privacy contact person at email privacy@coretech.it. | |
User Manual Link | |
Support page - Link
Product page - Link |
|
FAQ | |
Faq - Link
Terms and conditions - Link |
|
Security measures | |
Pagina Data Processing Agreement (DPA) Link |
|
User Management | For customer users, it is possible to manage Sygma users. |
Personal userids for users | For customers, it is possible to create users with personal user IDs. |
Level of detail with which access rights to systems can be configured (single feature, single transaction, etc.). | With the admin panel, users who can access, their permissions, and authentication methods (including password length and complexity) are independently defined. |
Verification of permissions to access or view processes |
Customers can view users and permissions from the control panels of individual purchased services (including Sygma). CoreTech can view AdS users by checking individual systems |
Option to change the password on first use. |
This is used when a new user is created or when the password is changed by system administrators (for example, if the user forgot it). For Sygma users: - in case of user creation, changing the password is mandatory; for password resets, the user starts the procedure independently. For services, admin user IDs and passwords are assigned to customers, who manage them independently. |
Changing the password by the user |
For customers: for password reset, the user initiates the Sygma procedure independently. For internal AdS, passwords are managed through Sygma. |
Password hidden in the password entry field. | Yes |
Block the user account |
Possibility to block the user account after a certain number of incorrect password attempts (not applicable to all system administrators because, in case of an attack, no one would be able to access the system). On Sygma, email notification is enabled for every failed attempt. Additionally, after a certain number of attempts, a slowdown procedure is triggered. For CoreTech AdS, Sygma is used. Virtual machines block accounts for 5 minutes after 5 failed attempts. However, no alarms are currently triggered. |
Administrative password recovery methods. | It is possible to contact CoreTech support. |
Possibility to assign administrative powers to multiple users, even on individual parts of the system. | Yes |
Customization of credentials for system administrators (and personal user IDs). | Yes |
Disabling default userids. | Yes |
Automatic control of password characteristics so that users do not choose simple passwords. | Yes, automatic control of password characteristics so that users do not choose simple ones: complexity (must include letters and numbers; or lowercase letters, uppercase letters, numbers, and special characters), length (minimum 8 characters), expiration (so they are changed at least every 3 months), lockout in case of user inactivity (after no more than 6 months), and non-reuse of the last 5 or 10 passwords. |
Automatic control of password characteristics; e.g., password not in the dictionary. | Yes, automatic control to ensure password complexity; e.g., passwords not in the dictionary, not a variation of the user ID like Cesare1970, not a variation of the application name like Oracle70, and not a popular password like 12345678 (these rules are considered an alternative and more secure than those related to complexity described above). |
Availability of MFA tools. | Available at the administrator's discretion. |
Authentication error messages that do not specify details (e.g., "incorrect credentials"). | Yes |
Configuration to log out users after 5, 10, or more minutes of inactivity. | It depends on the system. |
Configuration so that users cannot connect at specific times or from certain countries. | No |
Interfacing methods with other programs or with the user, including encrypted connections, digital certificate exchange, and mutual authentication without administrative or generic accounts. | In some cases, service credentials are used, but with IP origin control. |
Encrypted data storage. | Unencrypted data. |
Encrypted data transmission | All connections are encrypted. |
Signing or logging mechanisms to ensure certain levels of non-repudiation of activities. | In some cases, service credentials are used, but with IP origin control. |
Cryptographic Mechanisms | The algorithm used to encrypt files is AES 256-bit. Communications with the 1Backup server are over 128-bit SSL. |
Access to cryptographic keys is limited to system administrators or internal software processes only. |
Internally, private keys are used with certificates, and certificates can only be modified by AdS. Customers manage certificates: - independently for services that provide for it; - through CoreTech AdS for other services (e.g., email). |
Cryptographic keys generated using secure methods, starting from randomly generated seeds. | External certificates used. |
Availability of application logs and logs of system administrator activities. | Application logs depend on the application. |
User logs | See above. |
Mechanisms to ensure log security. | Security ensured by the application. |
Mechanisms to establish log retention duration. | Set 6 months. |
Methods for connecting the system to existing monitoring systems | See "Infrastructure". |
Clock can be synchronized with an NTP server. | See "Infrastructure". |
Definition of acceptable performance | See "Infrastructure". |
System modularity, allowing its various components to be installed in different environments. | Servers are divided into clusters to optimize performance. Each service, where appropriate, is further divided into additional servers, preferably in different clusters. |
Backup (frequency, retention time, location) | See above. |
Verification and sanitization of incoming data at the server level, especially when received from untrusted sources such as the web (e.g., if a date is expected, the system verifies that it is a date and not other characters; if a certain number of characters are expected, the system verifies that the length is not exceeded). | Package, managed either through its own interface or through the Sygma interface (see below). |
Filters when modifying data, such as messages like “are you sure you want to modify” or requests for validation from other users. |
Depending on the criticality of the operation, the following confirmation mechanisms are activated: - reversible changes, which therefore do not require confirmation; - confirmation required for non-reversible but non-impactful changes (e.g., ticket deletion); - email confirmation required for non-reversible and impactful changes (e.g., VM deletion); - confirmation request with additional input data as an alternative to the previous one. |
Limitation of search capabilities so that a user cannot view data they are not authorized to access. | N/A |
Data on screen and printed without confidential information or information the user is not authorized to access. | N/A |
Possibility of anonymization or pseudonymization of data | N/A |
Types of messages and alerts issued by the system that provide sufficient information to authorized personnel but do not disclose information to malicious users (e.g., providing too many details about the type of error when incorrect credentials are entered). | Yes. Example: error and confirmation messages for incorrect passwords and password changes. |
Systems for automatic data deletion or warning when the retention time has been exceeded. | Responsible for customers |
Data deletion methods | Backups are encrypted. |
Guarantee of vulnerability management and patching (the vendor must provide a notification and correction service). | The services provided are in the cloud, and therefore CoreTech updates packages according to the supplier's specifications. |
Version 3 dated 05/09/2024
Description | |
Archiving of e-mail in the cloud. The software generates 1: 1 copies of all emails in a central repository and ensures the long-term availability of large amounts of data to assist with regulatory compliance. Product Page |
|
Roles and responsibilities | |
CoreTech acts as Manager or Sub. Responsible for all processing, while it is the owner only for the customer contact details.
With regards to compliance and data security, both CoreTech and the customer are both responsible albeit on different fronts. Link |
|
CoreTech Responsibilities |
Daily check of the status of Mail Archive servers and storage
Keep systems updated with the most stable and secure software versions released by the manufacturer. Monitor servers to ensure continuity of service. Daily backup control to ensure data integrity. |
Customer Responsibility |
Check the result of archiving according to set requirements or schedules. Properly configure archiving jobs. Perform a restore test at least monthly/bimonthly.
Set complex service access passwords. Carefully guard the access data to the archive boxes and limit their disclosure. Inform CoreTech promptly in case of anomalies that could lead to a data security problem. Intervene promptly in the event of reports from CoreTech on problems relating to the service. |
Datacenter | |
TIER4 - It is the highest level of guarantee that a data center can offer, with 99.9% availability. Identifies a data center that is completely redundant in terms of electrical circuits, cooling and network. This indicator refers to an architecture that allows you to deal with serious technical incidents without ever interrupting server availability.
Link | |
Geographic location | European Union |
Labeling | |
It is possible to label processed data in Mail Archive when creating mailbox archiving and set a meaningful name for that archive, naming it appropriately. |
|
Features available on the Control Panel: | |
Interface from Sygma or Client Admin on the server or PC itself. Full control through the App dashboard. Full view on Sygma. Customer portal allows the customer to view. Autonomy until the closure of their Master account or instance associated with the partner. Service cancellation request required. Archiving profile deletion - a cancellation request email is sent to Sales, who process it manually. |
|
Admin Panel |
- With the admin panel, users who can access archiving profiles, permissions, and authentication methods (including password length and complexity) are independently defined. - Admin user and agent passwords must meet minimum security criteria |
SLA | |
Monthly SaaS 99,8% (1h 26m) Ordinary and extraordinary maintenance activities reported on the site 24 hours in advance are excluded. (except for emergencies related to safety problems that require our immediate intervention) |
|
Penalties | |
SLA SaaS <99,8% (1h 26m) = 10% <99,5% (3h 36) = 20% <99,00% (7h 18m 17s) = 50% for more information visit the site https://www.coretech.it/it/service/systemStatus/SLA_servizi.php |
|
Backup | |
The Mailarchive service includes the Backup service replicated on Cloud Storage S3. Backup is done using the 1Backup service |
|
Data Backup | Daily - 60 day retention - 1Backup encryption. |
VM backup of the server | Daily night - 3 day retention. |
Restore | By request to customer support who will restore what is requested |
Geographical replication | The Backup is replicated on Cloud Storage S3 - located in a DataCenter outside Italy in a country of the European Union. |
Problem Tolerance | |
Multiple Servers | The servers that provide the Mailarchive storage service are different and multiple. These servers are virtual machines residing on Vmware clusters consisting of 3 physical nodes. The customer should take care to allocate mail storage domains on different storage servers. MailArchive Servers benefit from the Stellar infrastructure. Stellar site |
Disaster Recovery | Replicated data and backup set on another Datacenter. |
Configuration Storage Raid6 | The disk configuration of the backup destination storage is in RAID6 The storage on which the data backups reside has double power supply and double network connectivity and the disk controller is double. |
Support | |
Support Page - Link | |
Access to Data | |
Available and web interface or specific client software. The customer is the only one who has the passwords to access the archive boxes. CoreTech cannot access the data as it is encrypted | |
Contract Cancellation / Closure | |
.The data is deleted after 30 days from the termination of the service. | |
Portability | |
Independently by exporting the mail pst file. | |
Assistance process for the satisfaction of the rights of interested parties | |
Link | |
How personal data breaches are handled | |
Link | |
Assistance process for the satisfaction of the rights of interested parties | |
Link | |
Evidence Collection | |
If the customer needs to collect evidence or request assistance, he can send the request to the email address ufficio@coretech.it, in the event that the assistance requested is not the responsibility of support or for other reasons, he can contact the Privacy contact person at email privacy@coretech.it. | |
User Manual Link | |
Cloud Email Archiving - Link
KB User Access - Link |
|
FAQ | |
Faq - Link | |
Security measures | |
Data Processing Agreement (DPA) - Link page | |
User Management | For customer users, it is possible to manage Sygma users. |
Personal userids for users | For customers, it is possible to create users with personal user IDs. |
Level of detail with which access rights to systems can be configured (single feature, single transaction, etc.). |
Customers can view users and permissions from the control panels of individual purchased services (including Sygma).
CoreTech can view AdS users by checking individual systems |
Option to "change password on first use" when a new user is created or when the password is changed by system administrators (e.g., if the user forgot it). |
For Sygma users,
- in case of account creation, password change is mandatory; - for password reset, the user initiates the procedure independently. For services, admin user IDs and passwords are assigned to customers, who manage them independently. |
Changing the password by the user |
For customers: for password reset, the user initiates the Sygma procedure independently. For internal AdS, passwords are managed through Sygma. |
Password hidden in the password entry field. | Yes. |
Possibility to block the user account after a certain number of incorrect password attempts (not applicable to all system administrators because, in case of an attack, no one would be able to access the system). |
On Sygma, email notification is enabled for every failed attempt. Additionally, after a certain number of attempts, a slowdown procedure is triggered. For CoreTech AdS, Sygma is used. Virtual machines block accounts for 5 minutes after 5 failed attempts. However, no alarms are currently triggered. |
Administrative password recovery methods. | It is possible to contact CoreTech support. |
Possibility to assign administrative powers to multiple users, even on individual parts of the system. | Yes. |
Customization of credentials for system administrators (and personal user IDs). | Yes. |
Disabling default userids | From Sygma |
Automatic control of password characteristics to ensure users do not choose simple ones: complexity (must include letters and numbers; or lowercase letters, uppercase letters, numbers, and special characters), length (minimum 8 characters), expiration (changed at least every 3 months), lockout for user inactivity (after no more than 6 months), and non-reuse of the last 5 or 10 passwords. | Sygma |
Automatic control to prevent simple passwords; e.g., passwords not in the dictionary, not a variation of the user ID like Cesare1970, not a variation of the application name like Oracle70, and not a popular password like 12345678 (these rules are considered an alternative and more secure than the complexity rules described above). | Sygma |
Availability of MFA tools | For internal AdS: Yes for Sygma. |
Authentication error messages that do not specify details (e.g., "incorrect credentials"). | Yes |
Configuration to log out users after 5, 10, or more minutes of inactivity. | It depends on the system. |
Configuration so that users cannot connect at specific times or from certain countries. | NO. |
Interfacing methods with other programs or with the user, including encrypted connections, digital certificate exchange, and mutual authentication without administrative or generic accounts. | In some cases, service credentials are used, but with IP origin control. |
Encrypted data storage. | Unencrypted data. |
Encrypted data transmission | All connections are encrypted. |
Signing or logging mechanisms to ensure certain levels of non-repudiation of activities. | N/A |
Cryptographic Mechanisms | The archive is always encrypted with algorithms established by the Mailstore software manufacturer. Communications are via HTTPS with a valid certificate. |
Access to cryptographic keys is limited to system administrators or internal software processes only. |
Internally, private keys are used with certificates, and certificates can only be modified by AdS. Customers manage certificates: - independently for services that provide for it; - through CoreTech AdS for other services (e.g., email). |
Cryptographic keys generated using secure methods, starting from randomly generated seeds. | External certificates used. |
Availability of application logs and logs of system administrator activities. | Application logs depend on the application. |
User logs | See above. |
Mechanisms to ensure log security. | Security ensured by the application. |
Mechanisms to establish log retention duration. | Set 6 months. |
Methods for connecting the system to existing monitoring systems | See "Infrastructure". |
Clock can be synchronized with an NTP server. | See "Infrastructure". |
Definition of “acceptable performance” | See "Infrastructure". |
System modularity, allowing its various components to be installed in different environments. | Servers are divided into clusters to optimize performance. Each service, where appropriate, is further divided into additional servers, preferably in different clusters. |
Backup (frequency, retention time, location) | See above. |
Verification and sanitization of incoming data at the server level, especially when received from untrusted sources such as the web (e.g., if a date is expected, the system verifies it is a date and not other characters; if a certain number of characters are expected, the system verifies that the length is not exceeded). | Package, managed either through its own interface or through the Sygma interface (see below). |
Filters when modifying data, such as messages like “are you sure you want to modify” or requests for validation from other users. |
Depending on the criticality of the operation, the following confirmation mechanisms are activated: - reversible changes, which therefore do not require confirmation; - confirmation required for non-reversible but non-impactful changes (e.g., ticket deletion); - email confirmation required for non-reversible and impactful changes (e.g., VM deletion); - confirmation request with additional input data as an alternative to the previous one. |
Limitation of search capabilities so that a user cannot view data they are not authorized to access. | N/A. Differentiated permissions are always active on Sygma and the CoreTech site. |
Data on screen and printed without confidential information or information the user is not authorized to access. | N/A. All reports are monitored. Internal reports are accessed based on each individual's role. Specific reports are available for sales, with data by department or person, but they are set centrally. |
Possibility of anonymization or pseudonymization of data | Report with minimized data. |
Types of messages and alerts issued by the system that provide sufficient information to authorized personnel but do not disclose information to malicious users (e.g., providing too many details about the type of error when incorrect credentials are entered). | Yes. Example: error and confirmation messages for incorrect passwords and password changes. |
Systems for automatic data deletion or warning when the retention time has been exceeded. | It depends on the configuration established by the customer. |
Data deletion methods | The customer cannot delete their own emails due to service characteristics; at the end of the service, the single instance is deleted (without encryption; the file is still compressed and deduplicated). |
Guarantee of vulnerability management and patching (the vendor must provide a notification and correction service). | The services provided are in the cloud, and therefore CoreTech updates packages according to the supplier's specifications. |
Version 3 dated 05/09/2024
Description | |
Scalable Web Hosting Product Page |
|
Roles and responsibilities | |
CoreTech acts as Manager or Sub Responsible for all treatments, while it is the owner of customer contact data only.
With regards to data compliance and security, both CoreTech and the customer are both responsible, albeit on different fronts. Link |
|
Responsabilità CoreTech |
CoreTech acts as Manager or Sub Responsible for all treatments, while it is the owner of customer contact data only.
|
CoreTech Responsibilities |
- Daily backup check. Backup retention is 35 days (5 weeks)
- Keep Web Hosting servers updated with the most stable and secure software versions released by the manufacturer. - Daily check regarding the update status of the integrated antivirus. - Tenere sotto monitoraggio il server web al fine di garantire la continuità di servizio. - Check the presence of any security-related anomalies that are highlighted through the system logs or alerts. - Inform the manufacturer of the software relating to the web servers if you become aware of flaws relating to the security of the system. - Disattivazione del servizio se a seguito di segnalazione da parte di altri service provider, il sito si sta comportando in modo anomalo (spam, phishing, contenuti inerenti al terrorismo, frode, sito hackerato). |
Customer Responsibility |
- Set passwords for access to the Plesk management panel, the FTP site or the website management system (for example WordPress admin access) with a difficulty level compliant with the defined policies and password change according to the reference standards (e.g. ISO 27002 ).
- Carefully guard your Plesk, FTP and website access data and limit their disclosure. - Intervene promptly in the event of reports from CoreTech on problems relating to the security of its website. - Proceed to periodically update the elements relating to the security of your website (for example updating the WordPress version). - Make a personal backup of your website at least once a month. - Periodically check the integrated data restore functionality of your website. - Check weekly for any anomalies relating to the use of your website resources. - Informare tempistivamente CoreTech in caso di anomalie che possano determinare un problema di sicurezza dei dati. |
Datacenter | |
TIER4 - It is the highest level of guarantee that a data centre can offer, with 99.9% availability. Identifies a data centre that is completely redundant in terms of electrical circuits, cooling and network. This indicator refers to an architecture that allows you to deal with serious technical incidents without ever interrupting server availability. catacenter |
|
Geographic location | European Union |
Labeling | |
Labeling functionality is not provided. Folders can be named as deemed most useful. |
|
Features available on the Control Panel: | |
- Interface from Plesk. - Reseller only sees their own sites and users. - Autonomy until the closure of their Reseller account. - Where necessary, request for cancellation of service. |
|
Admin Panel |
- Enabled on HTTPS. - Allows setting password length and complexity criteria for anyone accessing the service. |
SLA | |
Monthly SaaS 99,8% (1h 26m) Ordinary and extraordinary maintenance activities reported on the site 24 hours in advance are excluded. (except for emergencies related to safety problems that require our immediate intervention) |
|
Penalties | |
SLA SaaS <99,8% (1h 26m) = 10% <99,5% (3h 36) = 20% <99,00% (7h 18m 17s) = 50% |
|
Backup | |
The RocketWeb service includes Backup with replication on Cloud Storage S3 The Backup is done through Plesk and subsequently through the 1Backup service |
|
Data Backup | Daily - 35 day retention - 1Backup encryption. |
VM backup of the server | Daily night - 5 day retention. |
Restore | By request to customer support who will restore what is requested |
Geographical replication | The Backup is replicated on Cloud Storage S3 (in the EU).) |
Problem Tolerance | |
Multiple Servers |
The servers that provide the service are different and multiple These servers are virtual machines residing on Vmware clusters consisting of 3 physical nodes The Services benefit from the Stellar infrastructure Stellar site |
Configuration Storage Raid6 |
The disk configuration of the backup destination storage is in RAID6 The storage on which the data backups reside has dual power supplies, dual network connectivity and dual disk controllers |
Disaster Recovery | Replicated data and backup sets on another Data Center. |
Support | |
Support Page - Link | |
Access to Data | |
The customer has access data to the Plesk management panel and the site's FTP access data. In the case of Wordpress, the customer is the only one with access data to the administrative backend. Upon customer request, CoreTech can access the data contained in the site from the management panel or directly from the file system. |
|
Contract Cancellation / Closure | |
The data is deleted after 30 days from the cancellation of the service | |
Portability | |
It is possible via FTP access to extract all data including databases. | |
Processo di assistenza per il soddisfacimento dei diritti degli interessati | |
Data Processing Agreement (DPA) - Link page | |
How personal data breaches are handled | |
Data Processing Agreement (DPA) - Link page | |
Evidence Collection | |
If the customer needs to collect evidence or request assistance, he can send the request to the email address
support@coretech.it in case the requested assistance is not within the competence of the support or for other reasons he can contact the Privacy contact at email privacy@coretech.it |
|
User Manual Link | |
KB RocketWeb - Link | |
Security measures | |
Data Processing Agreement (DPA) - Link page | |
User Management | For customer users, it is possible to manage Sygma users. |
Personal userids for users | For customers, it is possible to create users with personal user IDs. |
Level of detail with which access rights to systems can be configured (single feature, single transaction, etc.). | The end customer can request (for a fee) the creation of multiple FTP users who can access different areas of the site. |
Verification of permissions to access or view processes |
Customers can view users and permissions from the control panels of individual purchased services (including Sygma). CoreTech can view AdS users by checking individual systems |
Option "change password at first use" when a new user is added or when the password is changed by system administrators (for example, if the user has forgotten it). |
For Sygma users, - in case of account creation, password change is mandatory; - for password reset, the user initiates the procedure independently. For services, admin user IDs and passwords are assigned to customers, who manage them independently. |
Changing the password by the user |
For customers: for password reset, the user initiates the Sygma procedure independently. For internal AdS, passwords are managed through Sygma. |
Password hidden in the password entry field | Yes. |
Possibility to block the user account after a certain number of incorrect password attempts (not applicable to all system administrators because, in case of an attack, no one would be able to access the system). |
On Sygma, email notifications are enabled for every failed attempt. Additionally, after a certain number of attempts, a slowdown procedure is triggered. Sygma is used for CoreTech AdS. Virtual machines block accounts for 5 minutes after 5 failed attempts. However, no alarms are currently triggered. |
Administrative password recovery methods. | It is possible to contact CoreTech support. |
Possibility to assign administrative powers to multiple users, even on individual parts of the system. | Yes. |
Customization of credentials for system administrators (and personal user IDs). | Yes. |
Disabling default userids | From Sygma |
Automatic control of password characteristics to ensure users do not choose simple ones: complexity (must include letters and numbers; or lowercase letters, uppercase letters, numbers, and special characters), length (minimum 8 characters), expiration (changed at least every 3 months), lockout for user inactivity (after no more than 6 months), and non-reuse of the last 5 or 10 passwords. | From Sygma |
Automatic control to prevent simple passwords; e.g., passwords not in the dictionary, not a variation of the user ID like Cesare1970, not a variation of the application name like Oracle70, and not a popular password like 12345678 (these rules are considered an alternative and more secure than the complexity rules described above). | Sygma |
Availability of MFA tools. | For internal AdS: Yes for Sygma. |
Authentication error messages that do not specify details (e.g., "incorrect credentials"). | Yes. |
Configuration to log out users after 5, 10, or more minutes of inactivity. | It depends on the system. |
Configuration so that users cannot connect at specific times or from certain countries. | NO. |
Interfacing methods with other programs or with the user, including encrypted connections, digital certificate exchange, and mutual authentication without administrative or generic accounts. | In some cases, service credentials are used, but with IP origin control. |
Encrypted data storage. | Unencrypted data. |
Encrypted data transmission | All connections are encrypted. Certificates with Certum. |
Signing or logging mechanisms to ensure certain levels of non-repudiation of activities. | N/A |
Cryptographic Mechanisms | Customers can enable https with their own digital certificates. Coretech offers the service with Letsencrypt or with CAs chosen by the customer. The server is not encrypted. |
Access to cryptographic keys is limited to system administrators or internal software processes only. |
Internally, private keys are used with certificates, and certificates can only be modified by AdS. Customers manage certificates: - independently for services that provide for it; - through CoreTech AdS for other services (e.g., email). |
Cryptographic keys generated using secure methods, starting from randomly generated seeds. | External certificates used. |
Availability of application logs and logs of system administrator activities. | Application logs depend on the application. |
User logs | See above. |
Mechanisms to ensure log security. | Security ensured by the application. |
Mechanisms to establish log retention duration. | Set 6 months. |
Methods for connecting the system to existing monitoring systems | See "Infrastructure". |
Clock can be synchronized with an NTP server. | See "Infrastructure". |
Definition of “acceptable performance” | See "Infrastructure". |
System modularity, allowing its various components to be installed in different environments. | It depends on the system. |
Configuration to log out users after 5, 10, or more minutes of inactivity. |
Servers are divided into clusters to optimize performance. Each service, where appropriate, is further divided into additional servers, preferably in different clusters. For Rocketweb, the use of distribution techniques is not significant because it is offered to those with limited needs (for more complex cases, IaaS servers are purchased to install what is necessary). |
Backup (frequency, retention time, location) | See above. |
Verification and sanitization of incoming data at the server level, especially when received from untrusted sources such as the web (e.g., if a date is expected, the system verifies it is a date and not other characters; if a certain number of characters are expected, the system verifies that the length is not exceeded). |
Package, managed either through its own interface or through the Sygma interface (see below). Active: Plesk WAF. |
Filters when modifying data, such as messages like “are you sure you want to modify” or requests for validation from other users. |
Depending on the criticality of the operation, the following confirmation mechanisms are activated: - reversible changes, which therefore do not require confirmation; - confirmation required for non-reversible but non-impactful changes (e.g., ticket deletion); - email confirmation required for non-reversible and impactful changes (e.g., VM deletion); - confirmation request with additional input data as an alternative to the previous one. |
Limitation of search capabilities so that a user cannot view data they are not authorized to access. | N/A |
Data on screen and printed without confidential information or information the user is not authorized to access. | N/A |
Possibility of anonymization or pseudonymization of data | N/A |
Types of messages and alerts issued by the system that provide sufficient information to authorized personnel but do not disclose information to malicious users (e.g., providing too many details about the type of error when incorrect credentials are entered). | Yes. Example: error and confirmation messages for incorrect passwords and password changes. |
Systems for automatic data deletion or warning when the retention time has been exceeded. | N/A |
Data deletion methods | At the end of the service, the single instance is deleted (without encryption). |
Guarantee of vulnerability management and patching (the vendor must provide a notification and correction service). | The services provided are in the cloud, and therefore CoreTech updates packages according to the supplier's specifications. |
Version 3 dated 05/09/2024
Description | |
E-mail service on a shared server Product Page |
|
Roles and responsibilities | |
CoreTech acts as Administrator or Sub Responsible for all treatments, while it is the owner of client contact data only
With regards to data compliance and security, both CoreTech and the customer are both responsible, albeit on different fronts. Link |
|
CoreTech Responsibilities |
-Daily backup check. Backup retention is 60 days.
-Daily check regarding the update status of the integrated antivirus. -Daily check regarding the presence of servers in the public Black Lists. -Keep email systems updated with the most stable and secure software versions released by the manufacturer. -Keep the mail server monitored in order to guarantee service continuity. -Check the presence of any security-related anomalies that are highlighted through the system logs or alerts. -Notify the customer if, by reading the mailserver logs, situations are highlighted that could endanger the email accounts and the data contained therein. -Inform the mailserver software manufacturer if you become aware of system security flaws. -Immediate password change, if the account has been hacked and is sending spam, delete all emails in the queue relating to the specific account (whether valid or spam). .-Notification to the customer for appropriate checks and password change. - Upon customer request, availability to export mail archives on magnetic media or in exchange areas (activities to be quantified economically). |
Customer Responsibility |
-Set passwords to access the mail service with a level of difficulty compliant with the defined policies and change password according to the reference standards (e.g. ISO 27002).
-Carefully guard mailbox access data and limit their disclosure. -Inform your users about the proper use of email in relation to security and the dangers of phishing and viruses. - Intervene promptly in the event of reports from CoreTech on problems relating to the mailbox. -Periodically make a backup of your mail archive on your own storage systems to have a copy of the archive in case you want to change supplier. -Avoid using mailboxes to make SPAM or send mass emails not authorized by recipients. -Promptly inform CoreTech in case of anomalies that could lead to a data security problem. -Evaluate the frequency or event for changing passwords in your company procedures. |
Datacenter | |
TIER4 - This is the highest level of assurance a datacenter can offer, with 99.9% availability. Identify a catacenter completely redundant in terms of electrical, cooling and network circuits. This indicator refers to an architecture that allows you to cope with serious technical incidents without ever interrupting the availability of servers. | |
Geographic location | European Union |
Labeling | |
Kerio |
Kerio: On Webmail, it is possible to use tagging as labeling
SmarterMail: It is possible to use email software more suitable for personal use. |
Features available on the Control Panel: | |
Sygma interface, Kerio has its own Management Control Panel, and the same applies to SmarterMail.
Control through the Sygma dashboard, although autonomous management through the product's control panels is not provided. Autonomy until the closure of their Master account, a confirmation request email is sent (still subject to service cancellation to avoid continued charges). Cancellation: a tracking email with a confirmation request is sent. |
|
Admin Panel |
See above.
Passwords are already set with password complexity requirements for all users and service operators. |
SLA | |
Monthly SaaS 99,8% (1h 26m) Ordinary and extraordinary maintenance activities reported on the site 24 hours in advance are excluded. (except for emergencies related to safety problems that require our immediate intervention) |
|
Penalties | |
SLA SaaS <99,8% (1h 26m) = 10% <99,5% (3h 36) = 20% <99,00% (7h 18m 17s) = 50% |
|
Backup | |
the e-mail service includes the backup service replicated on Cloud Storage S3 Backup is done using the 1Backup service |
|
Data Backup | Daily - 60 day retention - 1Backup encryption |
VM backup of the server | Daily night - 5 day retention |
Restore | By request to customer support who will restore what is requested |
Geographical replication | The Backup is replicated on Cloud Storage S3 - The replica is located in a second Data Center located within the European Union (not in Italy) |
Problem Tolerance | |
Multiple Servers |
The servers that provide the service are different and multiple These servers are virtual machines residing on Vmware clusters consisting of 3 physical nodes Sygma Servers benefit from the Stellar infrastructure Stellar site |
Configuration Storage Raid6 |
The disk configuration of the backup destination storage is in RAID6 The storage on which the data backups reside has dual power supplies, dual network connectivity and dual disk controllers |
Disaster Recovery |
Replicated data and backup sets on another Data Center. |
Support | |
Support Page - Link | |
Access to Data | |
The customer in possession of the access data to the service can access the data only via webmail or mail client The customer is the only one who has the passwords to access the mailboxes CoreTech, upon customer request, can access data via file system |
|
Contract Closure/Data Cancellation | |
The data is deleted after 30 days from the cancellation of the service | |
Portability | |
Autonomous export to PST of all mail, with any mail client o At the customer's request, willingness to export mail archives on magnetic supports or in interchange areas (activity to be quantified economically) | |
Processo di assistenza per il soddisfacimento dei diritti degli interessati | |
Data Processing Agreement (DPA) - Link page | |
How personal data breaches are handled | |
Data Processing Agreement (DPA) - Link page | |
Evidence Collection | |
If the customer needs to collect evidence or request assistance, he can send the request to the email address
support@coretech.it
in case the requested assistance is not within the competence of the support or for other reasons he can contact the Privacy contact at email privacy@coretech.it |
|
User Manual Link | |
KB Kerio Connect Cloud Link
KB RocketMail Link |
|
Security measures | |
Data Processing Agreement (DPA) - Link page | |
User Management | For customer users, it is possible to manage Sygma users. |
Personal userids for users | For customers, it is possible to create users with personal user IDs. |
Level of detail for configuring access rights to systems (single feature, single transaction, etc.) | Sygma interface. Kerio and SmarterMail have their own control panels |
Verification of permissions to access or view processes |
Customers can view users and permissions from the control panels of individual purchased services (including Sygma).
CoreTech can view AdS users by checking individual systems |
Option to "change password on first use" when a new user is created or when the password is changed by system administrators (e.g., if the user forgot it). |
For Sygma users: - in case of account creation, password change is mandatory; - for password reset, the user initiates the procedure independently. For services, admin user IDs and passwords are assigned to customers, who manage them independently. |
Changing the password by the user |
For customers: for password reset, the user initiates the Sygma procedure independently.
For internal AdS, passwords are managed through Sygma. |
Password hidden in the password entry field | Yes. |
Option to block the user account after a certain number of incorrect password attempts (not applicable to all system administrators because, in case of an attack, no one could access the system). |
On Sygma, email notifications are enabled for every failed attempt.
Additionally, after a certain number of attempts, a slowdown procedure is triggered. Sygma is used for CoreTech AdS Virtual machines block accounts for 5 minutes after 5 failed attempts. However, no alarms are currently triggered. For email, the originating IP is blocked after 5 failed login attempts. |
Administrative password recovery methods | It is possible to contact CoreTech support. |
Possibility to assign administrative powers to multiple users, even on individual parts of the system. | Yes. |
Customization of credentials for system administrators (and personal user IDs). | Yes. |
Disabling default userids | Custom user-id. |
Automatic control of password characteristics to ensure users do not choose simple ones: complexity (must include letters and numbers; or lowercase letters, uppercase letters, numbers, and special characters), length (minimum 8 characters), expiration (changed at least every 3 months), lockout for user inactivity (after no more than 6 months), and non-reuse of the last 5 or 10 passwords. | Sygma. |
Automatic control to prevent simple passwords; e.g., passwords not in the dictionary, not a variation of the user ID like Cesare1970, not a variation of the application name like Oracle70, and not a popular password like 12345678 (these rules are considered an alternative and more secure than the complexity rules described above). | Sygma. |
Availability of MFA tools. |
For internal AdS: Yes for Sygma;
For the user's mailbox: - for SmarterMail, available at the administrator's discretion; - for Kerio, the functionality is available but will be provided after some accessibility and usability checks; - for KerioConnect, the functionality is available but will be provided after some accessibility and usability checks. |
Authentication error messages that do not specify details (e.g., "incorrect credentials"). | Yes. |
Configuration to log out users after 5, 10, or more minutes of inactivity. | It depends on the system. |
Configuration so that users cannot connect at specific times or from certain countries. | NO. |
Interfacing methods with other programs or with the user, including encrypted connections, digital certificate exchange, and mutual authentication without administrative or generic accounts. | In some cases, service credentials are used, but with IP origin control. |
Encrypted data storage. | Unencrypted data. |
Encrypted data transmission | All connections are encrypted. For email, CoreTech provides certificates. |
Signing or logging mechanisms to ensure certain levels of non-repudiation of activities. |
Signature tools are not available. Users can independently activate signature services on email. |
Cryptographic Mechanisms |
Email is on TLS from 1.0 to 1.3. The server is not encrypted. |
Access to cryptographic keys is limited to system administrators or internal software processes only. |
Internally, private keys are used with certificates, and certificates can only be modified by AdS. Customers manage certificates: - independently for services that provide for it; - through CoreTech AdS for other services (e.g., email). |
Cryptographic keys generated using secure methods, starting from randomly generated seeds. | External certificates used. |
Availability of application logs and logs of system administrator activities. | Greylog (linked to ElasticSearch) is used for email services. |
User logs | See above. |
Mechanisms to ensure log security. |
Greylog Security.
Data is recorded on a NoSQL database. |
Mechanisms to establish log retention duration. | Set 6 months. |
Methods for connecting the system to existing monitoring systems | See "Infrastructure". |
Clock can be synchronized with an NTP server | See "Infrastructure". |
Definition of “acceptable performance” |
See "Infrastructure". For email, maximum users are set on Crab, which also keeps track of active users. |
System modularity, allowing its various components to be installed in different environments. |
Servers are divided into clusters to optimize performance
Each service, where appropriate, is further divided into additional servers, preferably in different clusters. |
Backup (frequency, retention time, location) | See above. |
Verification and sanitization of incoming data at the server level, especially when received from untrusted sources such as the web (e.g., if a date is expected, the system verifies it is a date and not other characters; if a certain number of characters are expected, the system verifies that the length is not exceeded). | Package, managed either through its own interface or through the Sygma interface (see below). |
Filters when modifying data, such as messages like “are you sure you want to modify” or requests for validation from other users. |
Depending on the criticality of the operation, the following confirmation mechanisms are activated:
- reversible changes, which therefore do not require confirmation; - confirmation required for non-reversible but non-impactful changes (e.g., ticket deletion); - email confirmation required for non-reversible and impactful changes (e.g., VM deletion); - confirmation request with additional input data as an alternative to the previous one. |
Limitation of search capabilities so that a user cannot view data they are not authorized to access. | Not applicable for the type of service offered. |
Data on screen and printed without confidential information or information the user is not authorized to access. | Not applicable for the type of service offered. |
Possibility of anonymization or pseudonymization of data | Not applicable for the type of service offered. |
Types of messages and alerts issued by the system that provide sufficient information to authorized personnel but do not disclose information to malicious users (e.g., providing too many details about the type of error when incorrect credentials are entered). |
Yes.
Example: error and confirmation messages for incorrect passwords and password changes. |
Systems for automatic data deletion or warning when the retention time has been exceeded. | Paid to the customer. |
Data deletion methods | At the end of the service, the single instance is deleted (without encryption). |
Guarantee of vulnerability management and patching (the vendor must provide a notification and correction service). | The services provided are in the cloud, and therefore CoreTech updates packages according to the supplier's specifications. |
Version 3 dated 05/09/2024
Description | |
Cloud Server - virtual machine (VM) in Vmware Cluster environment Product Page Stellar site |
|
Roles and responsibilities | |
CoreTech acts as Administrator or Sub Responsible for all treatments, while it is the owner of client contact data only
With regards to data compliance and security, both CoreTech and the customer are both responsible, albeit on different fronts. As reported below Link |
|
CoreTech Responsibilities |
-Keep the software infrastructure updated with the most stable and secure software versions released by the manufacturer
- Monitor the infrastructure of virtualization, hypervisor and storage systems in order to guarantee continuity of services -Controllare la presenza di eventuali anomalie relative alla sicurezza che si evidenzino attraverso i log o alert del sistema -Deactivation of the service if, following a report from other service providers, the server is implementing anomalous behavior (spam, phishing, content relating to terrorism, fraud, hacked site) -Inform the customer if problems are found on the server during monitoring or log analysis. |
Customer Responsibility |
-Impostare delle password di accesso al server e ai software in esso installato con livello di difficoltà conforme alle policy definite e cambio password secondo gli standard di riferimento (es ISO 27002)
-Carefully guard server access data and limit their disclosure - Intervene promptly in the event of reports from CoreTech on problems relating to the security of its server -Correctly configure the backup jobs of your data with the tools made available by CoreTech and ask for support in case of doubts about the configurations -Check the results of data backups daily -Periodically check the correct functioning of the VM backup by consulting the results from the Sygma panel -Periodically organize VM restore tests with CoreTech in order to ensure correct execution of VM backups -Periodically check the event logs and operating system logs on your server in order to prevent any problems -Promptly inform CoreTech in case of anomalies that could cause a security problem d |
Datacenter | |
TIER4 - This is the highest level of assurance a datacenter can offer, with 99.9% availability. Identify a catacenter completely redundant in terms of electrical, cooling and network circuits. This indicator refers to an architecture that allows you to cope with serious technical incidents without ever interrupting the availability of servers. | |
Geographic location | European Union |
Labeling | |
Customizable instance name + tag | |
Features available on the Control Panel | |
Sygma interface Control through the Sygma dashboard; for anything not provided, a request must be made. Autonomous in increasing necessary resources upon purchase Cancellation: tracking email with a request is sent He confirms |
|
Admin Panel |
Sygma Complete Server Management (including Audit) Passwords are already set with complexity requirements for all users and service users. |
SLA | |
IaaS Monthly 99,95% (21m 54s) |
|
Penalties | |
SLA IaaS <99,95% (21m 54s) = 10% <99,85% (1h 5m 44s) = 20% <99,00% (7h 18m 17s) = 50% |
|
Backup | |
stellar's service includes the Backup service replicated on Cloud Storage S3 | |
Data Backup |
CoreTech provides the 1Backup tool for VM data backups The complete management of the backup schedules is the responsibility of the customer The customer is responsible for retention of the backup data (retention period) 1 Full VM backup every 30 days (night time). The backup overwrites itself every 30 days |
VM Backup |
1 Full VM backup every 30 days (night time). The backup overwrites itself every 30 days 1 Full VM backup every 30 days (night time). The backup overwrites itself every 30 days The VM backup is performed on a different storage than the one used for the VM itself The customer must verify the success of the backups and verify the consistency by periodically trying the restore |
Restore | By request to customer support who will restore the requested VM |
Geographical replication | The Backup is replicated on Cloud Storage S3 - The replica is located in a second Data Center located within the European Union (not in Italy) - only for Backup performed with 1Backup Service |
Optional Service - for a fee |
It is possible to request VM backups with retention or frequency other than the one included You can optionally request a disaster recovery in another data center. It is possible to optionally request a Business Continuity project |
Problem Tolerance | |
Multiple Servers |
Stellar Cloud Servers are configured on 3-node server cluster on shared storage These servers are virtual machines residing on Vmware clusters consisting of 3 physical nodes These servers are virtual machines residing on Vmware clusters consisting of 3 physical nodes The servers have dual power supplies and dual controllers Hypervisor Vmware environment |
Configuration Storage Raid6 |
The disk configuration of the backup destination storage is in RAID6 The storage on which the data backups reside has dual power supplies, dual network connectivity and dual disk controllers |
High Availability Function |
Default function, in the event of a fault on one of the nodes, the cloud server is started on one of the other hypervisors that make up the cluster In this case the VM is restarted. |
Fault Tolerance function |
Service that can be requested as an option. In the event of a fault in one of the nodes, the cloud server is not restarted, as there is continuous synchronization of the RAM and CPU registers between the hypervisors that make up the cluster |
Disaster Recovery – Business Continuity | The VM Backup included in the standard service allows for disaster recovery at the same data center. |
Support | |
Support Page - Link | |
Access to Data | |
The customer in possession of the access data to the server can access the data contained therein CoreTech does not have direct visibility of the data contained in the server but only of the image file of the VMware virtual machine CoreTech can access the server only at the request of the customer which must take place as per procedure |
|
Contract Cancellation / Closure | |
The data (server image files) are deleted 30 days after the service is canceled | |
Portability | |
On request export in ova of the VM. 1 time for free, the following times to be paid according to the hourly rate. | |
Processo di assistenza per il soddisfacimento dei diritti degli interessati | |
Data Processing Agreement (DPA) - Link page | |
How personal data breaches are handled | |
Data Processing Agreement (DPA) - Link page | |
Evidence Collection | |
If the customer needs to collect evidence or request assistance, he can send the request to the email address support@coretech.it in the event that the assistance requested is not within the scope of support or for other reasons, you can contact the Privacy contact person by email privacy@coretech.it |
|
User Manual Link | |
KB Stellar Link | |
FAQ | |
FAQ Stellar Link | |
Security measures | |
Data Processing Agreement (DPA) - Link page | |
User Management | For customer users, it is possible to manage Sygma users. |
Personal userids for users | For customers, it is possible to create users with personal user IDs. |
Level of detail with which access rights to systems can be configured (single feature, single transaction, etc.). | Paid to the customer. |
Verification of permissions to access or view processes |
Customers can view users and permissions from the control panels of individual purchased services (including Sygma).
CoreTech can view AdS users by checking individual systems |
Project-Id-Version: coretech PO-Revision-Date: 2025-05-09 15:20+0200 Last-Translator: Language-Team: Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Plural-Forms: nplurals=2; plural=(n != 1); X-Generator: Poedit 3.4.2 X-Poedit-Basepath: ../../.. X-Poedit-KeywordsList: _;_( X-Poedit-SourceCharset: UTF-8 X-Source-Language: it X-Poedit-SearchPath-0: . X-Poedit-SearchPathExcluded-0: backend X-Poedit-SearchPathExcluded-1: menagement X-Poedit-SearchPathExcluded-2: en X-Poedit-SearchPathExcluded-3: it/service/public/passwordChecker |
For Sygma users - in case of account creation, password change is mandatory; - for password reset, the user initiates the procedure independently For services, admin user IDs and passwords are assigned to customers, who manage them independently. |
Password change by the user |
For customers: for password reset, the user initiates the Sygma procedure independently.
For internal AdS, passwords are managed through Sygma. |
Password hidden in the password entry field | Yes. |
Option to block the user account after a certain number of incorrect password attempts (not applicable to all system administrators because, in case of an attack, no one could access the system). |
On Sygma, email notifications are enabled for every failed attempt. Additionally, after a certain number of attempts, a slowdown procedure is triggered Sygma is used for CoreTech AdS. Virtual machines block accounts for 5 minutes after 5 failed attempts. However, no alarms are currently triggered. |
Administrative password recovery methods | Paid to the customer. |
Possibility to assign administrative powers to multiple users, even on individual parts of the system. | Yes. |
Customization of credentials for system administrators (and personal user IDs). | Yes. |
Disabling default userids | Not assigned. Default user-id assigned and customized. |
Automatic control of password characteristics to ensure users do not choose simple ones: complexity (must include letters and numbers; or lowercase letters, uppercase letters, numbers, and special characters), length (minimum 8 characters), expiration (changed at least every 3 months), lockout for user inactivity (after no more than 6 months), and non-reuse of the last 5 or 10 passwords. | Sygma. |
Automatic control to prevent simple passwords; e.g., passwords not in the dictionary, not a variation of the user ID like Cesare1970, not a variation of the application name like Oracle70, and not a popular password like 12345678 (these rules are considered an alternative and more secure than the complexity rules described above). | Sygma. |
Availability of MFA tools | For internal AdS: Yes for Sygma. |
Authentication error messages that do not specify details (e.g., "incorrect credentials"). | Yes. |
Configuration to log out users after 5, 10, or more minutes of inactivity. | It depends on the system. |
Configuration to prevent users from connecting at specific times or from certain countries. | NO. |
Methods of interfacing with other programs or with the user, including encrypted connections, digital certificate exchange, and mutual authentication without administrative or generic accounts. | In some cases, service credentials are used, but with IP origin control. |
Encrypted data storage |
Unencrypted data.
For Stellar (IaaS) customers, encryption at the OS level is obviously activatable. |
Encrypted data transmission | N/A |
Signing or logging mechanisms to ensure certain levels of non-repudiation of activities. |
Signature tools are not available.
Users can independently activate signature services on email. |
Cryptographic Mechanisms | Server encryption is the customer's responsibility. |
Access to cryptographic keys is limited to system administrators or internal software processes only. |
Internally, private keys are used with certificates, and certificates can only be modified by AdS.
Customers manage certificates: - independently for services that provide for it; - through CoreTech AdS for other services (e.g., email). |
Cryptographic keys generated using secure methods, starting from randomly generated seeds. | External certificates used. |
Availability of application logs and logs of system administrator activities. | N/A |
User logs | See above. |
Mechanisms to ensure log security |
Greylog Security.
Data is recorded on a NoSQL database. |
Mechanisms to establish log retention duration | Paid to the customer. |
Methods for connecting the system to existing monitoring systems | See "Infrastructure". |
Clock can be synchronized with an NTP server. | See "Infrastructure". |
Definition of “acceptable performance” | See "Infrastructure". |
System modularity, allowing its components to be installed in different environments. |
Servers are divided into clusters to optimize performance.
Each service, where appropriate, is further divided into additional servers, preferably in different clusters. |
Backup (frequency, retention time, location) | See above. |
Verification and sanitization of incoming data at the server level, especially when received from untrusted sources such as the web (e.g., if a date is expected, the system verifies it is a date and not other characters; if a certain number of characters are expected, the system verifies that the length is not exceeded). | Package, managed either through its own interface or through the Sygma interface (see below). |
Filters when modifying data, such as messages like “are you sure you want to modify” or requests for validation from other users. | N/A |
Limitation of search capabilities so that a user cannot view data they are not authorized to access. | N/A. |
Data on screen and printed without confidential information or information the user is not authorized to access. | N/A. |
Possibility of anonymization or pseudonymization of data | N/A. |
Types of messages and alerts issued by the system that provide sufficient information to authorized personnel but do not disclose information to malicious users (e.g., providing too many details about the type of error when incorrect credentials are entered). |
Yes.
Example: error and confirmation messages for incorrect passwords and password changes. |
Systems for automatic data deletion or warning when the retention time has been exceeded. | N/A |
Data deletion methods | Paid to the customer. |
Guarantee of vulnerability management and patching (the vendor must provide a notification and correction service). | The services provided are in the cloud, and therefore CoreTech updates packages according to the supplier's specifications. |
Version 3 dated 05/09/2024
Description | |
Sygma, Platform Defined IT Work. The Sygma Panel is an exclusive customer management system which, in addition to integrating a customizable database with all the information required for optimal management of your customers' IT infrastructure, also has integration systems with Mail, Firewall, VoIP, Remote Backup and Email Archiving. With Sygma it is possible to manage the Cloud in all its areas and, at the same time, organize work processes. Thanks to the integration of the Cloud, with Sygma you can manage from a single platform Server, Backup, Email, Email Archiving, SMTP Account, Storage and various other services. The Sygma Connect remote control system is included in the Pro and Unlimited versions. Product Page |
|
Roles and responsibilities | |
CoreTech acts as Manager or Sub Responsible for all treatments, while it is the owner of customer contact data only.
With regards to data compliance and security, both CoreTech and the customer are both responsible, albeit on different fronts. Link |
|
CoreTech Responsibilities |
-Keep systems updated with the most stable and secure software versions released by the manufacturer.
- Monitor servers and data synchronization processes to ensure continuity of service. -Daily backup checking to ensure data integrity. -Additional Backup (on another data center). |
Customer Responsibility |
-Export data (tickets, activities etc.) to have a backup copy.
-Export data at least monthly/bimonthly. -Set complex service access passwords. -Carefully guard your access data to Sygma and all the services included and limit their disclosure. With particular attention to the password encryption used to store credentials in Sygma. -Promptly inform CoreTech in case of anomalies that could lead to a data security problem. - Intervene promptly in the event of reports from CoreTech on problems relating to the services. |
Datacenter | |
TIER4 - This is the highest level of assurance a datacenter can offer, with 99.9% availability. Identify a catacenter completely redundant in terms of electrical, cooling and network circuits. This indicator refers to an architecture that allows you to cope with serious technical incidents without ever interrupting the availability of servers. | |
Geographic location | European Union |
Labeling | |
Via Tag and priority, a Tag filter is available | |
Features available on the Control Panel | |
-Web interface and Mobile App.
-Mobile App allows viewing of tickets, activities, backups, and servers. -Web Interface provides full management of Sygma. -Reseller access shows all purchased services with (customized) indication of the end customer. -Customer portal allows the end customer to view their services shared by the reseller. -Reseller can delete, disable services and customer accounts, using their own cancellation rules. -End customer has service-related permissions set by their Reseller -Reseller autonomy until the closure of their Master account, where a service cancellation request is required. |
|
Labeling | |
Customer Responsibility |
-Through the Sygma interface, the Admin user can create users with access to certain dedicated services, either on Sygma or on individual service consoles.
-Admin user independently sets permissions and authentication methods (including password length and complexity). -All User Passwords must meet minimum security criteria -Option for OTP usage |
SLA | |
IaaS Monthly 99,95% (21m 54s) |
|
Penalties | |
SLA SaaS <99,8% (1h 26m) = 10% <99,5% (3h 36) = 20% <99,00% (7h 18m 17s) = 50% |
|
Backup | |
The Sygma service includes Backup with replication on Cloud Storage S3 The Backup is done through Plesk and subsequently through the 1Backup service |
|
Data Backup |
Front-end server data is replicated between web server nodes. The databases are replicated in a master/slave configuration. Retention 60 days With further copy on another Storage in another Datacenter located in the Netherlands |
VM backup of the server |
Database Server Backup every 3 hours - Front End Server backup daily nightly. Other servers that make up the infrastructure have different backup and retention schedules. |
Restore | restoration available on request at dev@coretech.it - hourly cost |
Geographical replication | The Backup is replicated on Cloud Storage S3 - The replica is located in a second Data Center located within the European Union (not in Italy) |
Problem Tolerance | |
Multiple Servers |
The Sygma Infrastructure consists of a large number of servers. These servers are virtual machines residing on multiple Vmware clusters with 3 physical nodes. It is recommended that the customer allocate mail storage domains on different storage servers Sygma Servers benefit from the Stellar infrastructure. The infrastructure can have balancing elements at other data centers or at other cloud providers. Stellar site |
Configuration Storage Raid6 |
The disk configuration of the backup destination storage is in RAID6 The storage on which the data backups reside has dual power supplies, dual network connectivity and dual disk controllers |
Disaster Recovery |
Replicated data and backup sets on another Data Center. |
Support | |
Support Page - Link | |
Access to Data | |
The client is in possession of the access data to the Sygma management platform. The client must provide for the 2-factor authentication that the platform makes available. CoreTech can access some data contained in the system databases CoreTech cannot access encrypted information contained in the database such as passwords. |
|
Contract Cancellation / Closure | |
.The data is deleted after 60 days from the termination of the service. | |
Portability | |
Excel export for ticket and activity list or you can request specific development at an hourly rate | |
Data Processing Agreement (DPA) - Link page | |
How personal data breaches are handled | |
Data Processing Agreement (DPA) - Link page | |
Evidence Collection | |
If the customer needs to collect evidence or request assistance, he can send the request to the email address
support@coretech.it in case the requested assistance is not within the competence of the support or for other reasons he can contact the Privacy contact at email privacy@coretech.it |
|
User Manual Link | |
Sygma Site Link
KB Sygma Link Forum Sygma Link |
|
Security measures | |
Data Processing Agreement (DPA) - Link page | |
User Management | For customer users, it is possible to manage Sygma users. |
Personal User IDs for users | For customers, it is possible to create users with personal user IDs. |
Level of detail with which access rights to systems can be configured (single feature, single transaction, etc.). | Each user has access to individual features and single customer data |
Verification of permissions to access or view processes |
Customers can view users and permissions from the control panels of individual purchased services (including Sygma).
CoreTech can view AdS users by checking individual systems |
Option "change password at first use" when a new user is added or when the password is changed by system administrators (for example, if the user has forgotten it). |
For Sygma users
- in case of account creation, password change is mandatory; - for password reset, the user initiates the procedure independently. For services, admin user IDs and passwords are assigned to customers, who manage them independently. |
Changing the password by the user |
For customers: for password reset, the user initiates the Sygma procedure independently.
For internal AdS, passwords are managed through Sygma. |
Password hidden in the password entry field. | Yes. |
Possibility to block the user account after a certain number of incorrect password attempts (not applicable to all system administrators because, in case of an attack, no one would be able to access the system). |
On Sygma, email notifications are enabled for every failed attempt.
Additionally, after a certain number of attempts, a slowdown procedure is triggered. Sygma is used for CoreTech AdS. Virtual machines block accounts for 5 minutes after 5 failed attempts. However, no alarms are currently triggered. |
Administrative password recovery methods. | It is possible to contact CoreTech support. |
Possibility to assign administrative powers to multiple users, even on individual parts of the system. | Yes. |
Customization of credentials for system administrators (and personal user IDs). | Yes. |
Disabling default userids | User-id chosen by the user. |
Automatic control of password characteristics to ensure users do not choose simple ones: complexity (must include letters and numbers; or lowercase letters, uppercase letters, numbers, and special characters), length (minimum 8 characters), expiration (changed at least every 3 months), lockout for user inactivity (after no more than 6 months), and non-reuse of the last 5 or 10 passwords. | Sygma. |
Automatic control to prevent simple passwords; e.g., passwords not in the dictionary, not a variation of the user ID like Cesare1970, not a variation of the application name like Oracle70, and not a popular password like 12345678 (these rules are considered an alternative and more secure than the complexity rules described above). | Sygma. |
Availability of MFA tools | For internal AdS: Yes for Sygma. |
Authentication error messages that do not specify details (e.g., "incorrect credentials"). | Yes. |
Configuration to log out users after 5, 10, or more minutes of inactivity. | It depends on the system. |
Configuration so that users cannot connect at specific times or from certain countries. | NO. |
Interfacing methods with other programs or with the user, including encrypted connections, digital certificate exchange, and mutual authentication without administrative or generic accounts. | In some cases, service credentials are used, but with IP origin control. |
Encrypted data storage | Unencrypted data. |
Encrypted data transmission | All connections are encrypted. Certificates with Certum. |
Signing or logging mechanisms to ensure certain levels of non-repudiation of activities. | N/A |
Access to cryptographic keys is limited to system administrators or internal software processes only. |
Internally, private keys are used with certificates, and certificates can only be modified by AdS.
Customers manage certificates: - independently for services that provide for it; - through CoreTech AdS for other services (e.g., email). |
Cryptographic keys generated using secure methods, starting from randomly generated seeds. | External certificates used |
Availability of application logs and logs of system administrator activities. | Application logs depend on the application. |
User logs | See above |
Mechanisms to ensure log security | Security ensured by the application. |
Mechanisms to establish log retention duration | Set 6 months. |
Methods for connecting the system to existing monitoring systems | See "Infrastructure". |
Clock can be synchronized with an NTP server | See "Infrastructure". |
Definition of “acceptable performance” | See "Infrastructure". |
System modularity, allowing its components to be installed in different environments. |
Servers are divided into clusters to optimize performance.
Each service, where appropriate, is further divided into additional servers, preferably in different clusters. Modular services are: -RocketBox with web server, database, and data storage; -Sygma with web server and storage. |
Backup (frequency, retention time, location) | See above. |
Verification and sanitization of incoming data at the server level, especially when received from untrusted sources such as the web (e.g., if a date is expected, the system verifies it is a date and not other characters; if a certain number of characters are expected, the system verifies that the length is not exceeded). |
Developed in-house:
-all inputs validated, also part of a development checklist; -Internal WAF for Sygma (on public calls, with greater caution for authenticated user activities). |
Filters when modifying data, such as messages like “are you sure you want to modify” or requests for validation from other users. |
Depending on the criticality of the operation, the following confirmation mechanisms are activated:
-reversible changes that do not require confirmation; -confirmation request for non-reversible but non-impactful changes (e.g., ticket deletion); -email confirmation request for non-reversible and impactful changes (e.g., VM deletion); -confirmation request with additional input data as an alternative to the previous one. |
Limitation of search capabilities so that a user cannot view data they are not authorized to access. |
N/A.
Differentiated permissions are always active on Sygma and the CoreTech site. |
Data on screen and printed without confidential information or information the user is not authorized to access. |
N/A.
All reports are monitored. Internal reports are accessed based on each individual's role. Specific reports for sales, with data by department or individual, are set centrally. |
Possibility of anonymization or pseudonymization of data | Report with minimized data. |
Types of messages and alerts issued by the system that provide sufficient information to authorized personnel but do not disclose information to malicious users (e.g., providing too many details about the type of error when incorrect credentials are entered). |
Yes.
Example: error and confirmation messages for incorrect passwords and password changes. |
Systems for automatic data deletion or warning when the retention time has been exceeded. |
The only data related to services concerns legal entities and is therefore retained.
Internal users must be deleted after 10 years. Manual operation scheduled for Sygma. |
Data deletion methods | Data is deleted without encryption. |
Guarantee of vulnerability management and patching (the vendor must provide a notification and correction service). | The services provided are in the cloud, and therefore CoreTech updates packages according to the supplier's specifications. |
Version 3 dated 05/09/2024
Description | |
Remote Control Software Product Page |
|
Management platform | |
Roles and responsibilities | |
CoreTech acts as Administrator or Sub Responsible for all treatments, while it is the owner of client contact data only
With regards to data compliance and security, both CoreTech and the customer are both responsible, albeit on different fronts. As reported below Link |
|
CoreTech Responsibilities | Project-Id-Version: coretech PO-Revision-Date: 2025-05-09 15:20+0200 Last-Translator: Language-Team: Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Plural-Forms: nplurals=2; plural=(n != 1); X-Generator: Poedit 3.4.2 X-Poedit-Basepath: ../../.. X-Poedit-KeywordsList: _;_( X-Poedit-SourceCharset: UTF-8 X-Source-Language: it X-Poedit-SearchPath-0: . X-Poedit-SearchPathExcluded-0: backend X-Poedit-SearchPathExcluded-1: menagement X-Poedit-SearchPathExcluded-2: en X-Poedit-SearchPathExcluded-3: it/service/public/passwordChecker |
Customer Responsibility | Project-Id-Version: coretech PO-Revision-Date: 2025-05-09 15:20+0200 Last-Translator: Language-Team: Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Plural-Forms: nplurals=2; plural=(n != 1); X-Generator: Poedit 3.4.2 X-Poedit-Basepath: ../../.. X-Poedit-KeywordsList: _;_( X-Poedit-SourceCharset: UTF-8 X-Source-Language: it X-Poedit-SearchPath-0: . X-Poedit-SearchPathExcluded-0: backend X-Poedit-SearchPathExcluded-1: menagement X-Poedit-SearchPathExcluded-2: en X-Poedit-SearchPathExcluded-3: it/service/public/passwordChecker |
Datacenter | |
TIER4 - This is the highest level of assurance a datacenter can offer, with 99.9% availability. Identify a catacenter completely redundant in terms of electrical, cooling and network circuits. This indicator refers to an architecture that allows you to cope with serious technical incidents without ever interrupting the availability of servers. | |
Geographic location | Mainly in Italy, then Germany and Great Britain |
Labeling | |
The software does not offer standard levels of information classification. However, the customer can apply labels and possibly a classification level through machine naming or by creating a suitable group for privacy. | |
Features available on the Control Panel | |
-Interface from Sygma or Client Admin on the server or PC itself. Full control through the App on your client. Complete view on Sygma (list, settings, status, and session logs if set to record). Autonomy until the closure of the Master account or associated partner instance. Service cancellation request required (see Sygma). |
|
Admin Panel | see Sygma |
SLA | |
IaaS Monthly 99,95% (21m 54s) |
|
Penalties | |
SLA IaaS <99,95% (21m 54s) = 10% <99,85% (1h 5m 44s) = 20% <99,00% (7h 18m 17s) = 50% |
|
Backup | |
All user and Peer data are saved in Sygma, therefore no Backup is necessary as it is already provided for the Sygma service on which it relies. |
|
Backup | |
All user and Peer data are saved in Sygma, therefore no Backup is necessary as it is already provided for the Sygma service on which it relies. |
|
Problem Tolerance | |
Multiple Servers |
The Sygma Connect service consists of an infrastructure consisting of a large number of servers located on different Datacenters (for example Aruba, Azure, Stellar) The service is based on Docker |
Configuration Storage Raid6 | N/A |
Disaster Recovery | N/A |
Support | |
Support Page - Link | |
Access to Data | |
The customer in possession of the access data to the server can access the data contained therein CoreTech does not have direct visibility of the data contained and cannot remotely access the machines unless it is expressly requested and authorized by the customer (via id and secondary password) |
|
Cancellation/Closing of Contract | |
.The data is deleted after 60 days from the termination of the service. | |
Portability | |
Since Sygma it is possible to export session list with necessary details and logs Since sygma also has an address book with a list of devices available for remote connection. |
|
Assistance process for the satisfaction of the rights of interested parties | |
Data Processing Agreement (DPA) - Link page | |
How personal data breaches are handled | |
Data Processing Agreement (DPA) - Link page | |
Evidence Collection | |
If the customer needs to collect evidence or request assistance, he can send the request to the email address support@coretech.it in the event that the assistance requested is not within the scope of support or for other reasons, you can contact the Privacy contact person privacy@coretech.it |
|
User Manual Link | |
KB Sygma Connect Link
Forum Sygma Connect Link |
|
Security measures | |
Data Processing Agreement (DPA) - Link page | |
Level of detail for configuring access rights to systems (single feature, single transaction, etc.). | Not applicable. |
Verification of permissions to access or view processes |
Customers can view users and permissions from the control panels of individual purchased services (including Sygma). CoreTech can view AdS users by checking individual systems |
Option to "change password on first use" when a new user is created or when the password is changed by system administrators (e.g., if the user forgot it). |
For Sygma users - in case of account creation, password change is mandatory; - for password reset, the user initiates the procedure independently. For services, admin user IDs and passwords are assigned to customers, who manage them independently. |
Password change by the user |
For customers: for password reset, the user initiates the Sygma procedure independently. For internal AdS, passwords are managed through Sygma. |
Password hidden in the password entry field. | Yes. |
Possibility to block the user account after a certain number of incorrect password attempts (not applicable to all system administrators because, in case of an attack, no one would be able to access the system). |
On Sygma, email notifications are enabled for every failed attempt. Additionally, after a certain number of attempts, a slowdown procedure is triggered. Sygma is used for CoreTech AdS Virtual machines block accounts for 5 minutes after 5 failed attempts. However, no alarms are currently triggered. |
Administrative password recovery methods. | It is possible to contact CoreTech support. |
Possibility to assign administrative powers to multiple users, even on individual parts of the system. | Yes. |
Customization of credentials for system administrators (and personal user IDs). | Yes. |
Disabling default userids | Not assigned |
Automatic control of password characteristics to ensure users do not choose simple ones: complexity (must include letters and numbers; or lowercase letters, uppercase letters, numbers, and special characters), length (minimum 8 characters), expiration (changed at least every 3 months), lockout for user inactivity (after no more than 6 months), and non-reuse of the last 5 or 10 passwords. | Sygma. |
Automatic control to prevent simple passwords; e.g., passwords not in the dictionary, not a variation of the user ID like Cesare1970, not a variation of the application name like Oracle70, and not a popular password like 12345678 (these rules are considered an alternative and more secure than the complexity rules described above). | Sygma. |
Availability of MFA tools | For internal AdS: Yes for Sygma. |
Authentication error messages that do not specify details (e.g., "incorrect credentials"). | Yes. |
Configuration to log out users after 5, 10, or more minutes of inactivity. | It depends on the system. |
Configuration so that users cannot connect at specific times or from certain countries. | NO. |
Interfacing methods with other programs or with the user, including encrypted connections, digital certificate exchange, and mutual authentication without administrative or generic accounts. | In some cases, service credentials are used, but with IP origin control. |
Encrypted data storage. | Unencrypted data. |
Encrypted data transmission | All connections are encrypted. Certificates with Certum. |
Signing or logging mechanisms to ensure certain levels of non-repudiation of activities. | N/A |
Cryptographic Mechanisms |
Communications are on https with TLS from 1.0 to 1.3. The server is not encrypted. |
Access to cryptographic keys is limited to system administrators or internal software processes only. |
Internally, private keys are used with certificates, and certificates can only be modified by AdS. Customers manage certificates: -independently for services that provide for it; -through CoreTech AdS for other services (e.g., email). |
Cryptographic keys generated using secure methods, starting from randomly generated seeds. | External certificates used. |
Availability of application logs and logs of system administrator activities. | Application logs depend on the application. |
User logs | See above. |
Mechanisms to ensure log security. | Security ensured by the application. |
Mechanisms to establish log retention duration. | Set 6 months. |
Methods for connecting the system to existing monitoring systems | See "Infrastructure". |
Clock can be synchronized with an NTP server. | See "Infrastructure". |
Definition of “acceptable performance” | See "Infrastructure". |
System modularity, allowing its various components to be installed in different environments. |
Servers are divided into clusters to optimize performance. Each service, where appropriate, is further divided into additional servers, preferably in different clusters. |
Backup (frequency, retention time, location) | See above. |
Verification and sanitization of incoming data at the server level, especially when received from untrusted sources such as the web (e.g., if a date is expected, the system verifies it is a date and not other characters; if a certain number of characters are expected, the system verifies that the length is not exceeded). | N/A |
Filters when modifying data, such as messages like “are you sure you want to modify” or requests for validation from other users. | N/A |
Limitation of search capabilities so that a user cannot view data they are not authorized to access. | N/A |
Data on screen and printed without confidential information or information the user is not authorized to access. | N/A |
Possibility of anonymization or pseudonymization of data | N/A |
Types of messages and alerts issued by the system that provide sufficient information to authorized personnel but do not disclose information to malicious users (e.g., providing too many details about the type of error when incorrect credentials are entered). |
Yes. Example: error and confirmation messages for incorrect passwords and password changes. |
Systems for automatic data deletion or warning when the retention time has been exceeded. | N/A |
Data deletion methods | N/A |
Guarantee of vulnerability management and patching (the vendor must provide a notification and correction service). | The services provided are in the cloud, and therefore CoreTech updates packages according to the supplier's specifications. |
Version 3 dated 05/09/2024
Description | |
Mail Marketing RocketNews, Newsletter Sending System. RocketNews is an alternative to MailChimp and MailUp designed to satisfy all those companies that have the same communication needs as large companies but have a limited number of recipients. With RocketNews, companies can send their newsletters independently. Product Page |
|
Management platform | |
Roles and responsibilities | |
CoreTech acts as Administrator or Sub Responsible for all treatments, while it is the owner of client contact data only
With regards to data compliance and security, both CoreTech and the customer are both responsible, albeit on different fronts. As reported below Link |
|
CoreTech Responsibilities |
-Daily backup check. Backup retention is 35 days (5 weeks) -Keep RocketNewslettr servers updated with the most stable and secure software versions released by the manufacturer. -Keep the web server monitored in order to guarantee continuity of service. |
Customer Responsibility |
-Set passwords to access the RocketNewsletter panel. -Carefully guard your access data to the RocketNewsletter service and limit its disclosure. - Intervene promptly in the event of reports from CoreTech on problems relating to the security of its website. -Promptly inform CoreTech in case of anomalies that could lead to a data security problem. |
Datacenter | |
TIER4 - This is the highest level of assurance a datacenter can offer, with 99.9% availability. Identify a catacenter completely redundant in terms of electrical, cooling and network circuits. This indicator refers to an architecture that allows you to cope with serious technical incidents without ever interrupting the availability of servers. | |
Geographic location | European Union |
Labeling | |
Name newsletter lists and templates to determine if the data type is more sensitive than others. | |
Features available on the Control Panel | |
RocketNewsletter Web Interface request to increase necessary resources. Deletion upon request, and CoreTech sends a confirmation email of the deletion. |
|
Admin Panel | The user is unique. |
SLA | |
Monthly SaaS 99,8% (1h 26m) Ordinary and extraordinary maintenance activities reported on the site 4 hours in advance are excluded |
|
Penalties | |
SLA SaaS <99,8% (1h 26m) = 10% <99,5% (3h 36) = 20% <99,00% (7h 18m 17s) = 50% |
|
Backup | |
RocketNews is a service based on Rocketweb and therefore the Backup features correspond to Rocketweb SLA RocketWeb
|
|
Problem Tolerance | |
Multiple Servers |
RocketNews is a service based on Rocketweb and therefore the Tolerance characteristics correspond to Rocketweb. - Servers are virtual machines resident on Vmware clusters made up of 3 physical nodes. - RocketNewsletter Servers use the Stellar infrastructure. - The disk configuration of the backup destination storage is in RAID6. High Availability function: the storage on which the data backups reside has double power supply and double network connectivity. The disk controller is unique. Fault Tolerance Function: Optional (data replicated and backup set on another Data Center). |
Configuration Storage Raid6 |
The disk configuration of the backup destination storage is in RAID6 the storage on which the data backups reside has double power supply and double network connectivity, the disk controller is double |
Disaster Recovery |
VM Backup included in the standard service allows disaster recovery in the same data center. it is possible to optionally request disaster recovery in another data center. Rocket Newsletter: the user is unique |
Support | |
Support Page - Link | |
Access to Data | |
The customer has the access data and can independently insert, delete, view, modify, download and upload images, email contacts, text and templates created (or create templates) on the platform Always independently, the customer can extrapolate all the reports relating to the mailings made with all the details associated with them When the user cancels from the service, the data is anonymized |
|
Contract Cancellation / Closure | |
The data is deleted after 30 days from the cancellation of the service | |
Portability | |
The customer has the access data and can independently insert, delete, view, modify, download and upload images, email contacts, text and templates created (or create templates) on the platform Sempre in autonomia il cliente può estrapolasi tutti i report inerenti agli invii fatti con tutti i dettagli ad esse associati |
|
Processo di assistenza per il soddisfacimento dei diritti degli interessati | |
Data Processing Agreement (DPA) - Link page | |
How personal data breaches are handled | |
Data Processing Agreement (DPA) - Link page | |
Evidence Collection | |
If the customer needs to collect evidence or request assistance, he can send the request to the email address support@coretech.it in case the requested assistance is not within the competence of the support or for other reasons he can contact the Privacy contact at email privacy@coretech.it |
|
User Manual Link | |
KB RocketNews Link | |
Security measures | |
Data Processing Agreement (DPA) - Link page | |
User Management | For customer users, it is possible to manage Sygma users. |
Personal userids for users | For customers, it is possible to create users with personal user IDs. |
Level of detail with which access rights to systems can be configured (single feature, single transaction, etc.). | Rocket Newsletter: the user is unique. |
Verification of permissions to access or view processes |
Customers can view users and permissions from the control panels of individual purchased services (including Sygma).
CoreTech can view AdS users by checking individual systems |
Option "change password at first use" when a new user is added or when the password is changed by system administrators (for example, if the user has forgotten it). |
For Sygma users
- in case of account creation, password change is mandatory; - for password reset, the user initiates the procedure independently. For services, admin user IDs and passwords are assigned to customers, who manage them independently. |
Password change by the user |
For customers: for password reset, the user initiates the Sygma procedure independently. For internal AdS, passwords are managed through Sygma. |
Password hidden in the password entry field. | Yes. |
Possibility to block the user account after a certain number of incorrect password attempts (not applicable to all system administrators because, in case of an attack, no one would be able to access the system). |
On Sygma, email notifications are enabled for every failed attempt.
Additionally, after a certain number of attempts, a slowdown procedure is triggered. Sygma is used for CoreTech AdS Virtual machines block accounts for 5 minutes after 5 failed attempts. However, no alarms are currently triggered. |
Administrative password recovery methods. | It is possible to contact CoreTech support. |
Possibility to assign administrative powers to multiple users, even on individual parts of the system. | Yes. |
Customization of credentials for system administrators (and personal user IDs). | Yes. |
Disabling default userids | The assigned user-id is personalized. |
Automatic control of password characteristics to ensure users do not choose simple ones: complexity (must include letters and numbers; or lowercase letters, uppercase letters, numbers, and special characters), length (minimum 8 characters), expiration (changed at least every 3 months), lockout for user inactivity (after no more than 6 months), and non-reuse of the last 5 or 10 passwords. | Sygma. |
Automatic control to prevent simple passwords; e.g., passwords not in the dictionary, not a variation of the user ID like Cesare1970, not a variation of the application name like Oracle70, and not a popular password like 12345678 (these rules are considered an alternative and more secure than the complexity rules described above). | Sygma. |
Availability of MFA tools. | For internal AdS: Yes for Sygma. |
Authentication error messages that do not specify details (e.g., "incorrect credentials"). | Yes. |
Configuration to log out users after 5, 10, or more minutes of inactivity. | It depends on the system. |
Configuration so that users cannot connect at specific times or from certain countries. | NO. |
Interfacing methods with other programs or with the user, including encrypted connections, digital certificate exchange, and mutual authentication without administrative or generic accounts. | In some cases, service credentials are used, but with IP origin control. |
Encrypted data storage. | Unencrypted data. |
Encrypted data transmission | For email, CoreTech provides certificates. |
Signing or logging mechanisms to ensure certain levels of non-repudiation of activities. | N/A |
Cryptographic Mechanisms | Communications are on https with TLS from 1.0 to 1.3. The server is not encrypted. |
Access to cryptographic keys is limited to system administrators or internal software processes only. |
Internally, private keys are used with certificates, and certificates can only be modified by AdS.
Customers manage certificates: -independently for services that provide for it; -through CoreTech AdS for other services (e.g., email). |
Cryptographic keys generated using secure methods, starting from randomly generated seeds. | External certificates used. |
Availability of application logs and logs of system administrator activities. | Application logs depend on the application. |
User logs | See above. |
Mechanisms to ensure log security. | Security ensured by the application. |
Mechanisms to establish log retention duration. | Set 6 months. |
Methods for connecting the system to existing monitoring systems | See "Infrastructure". |
Clock can be synchronized with an NTP server. | See "Infrastructure". |
Definition of “acceptable performance” | See "Infrastructure". |
System modularity, allowing its various components to be installed in different environments. |
Servers are divided into clusters to optimize performance.
Each service, where appropriate, is further divided into additional servers, preferably in different clusters. |
Backup (frequency, retention time, location) | See above. |
Verification and sanitization of incoming data at the server level, especially when received from untrusted sources such as the web (e.g., if a date is expected, the system verifies it is a date and not other characters; if a certain number of characters are expected, the system verifies that the length is not exceeded). |
Developed in-house:
All inputs are validated (Rocket Newsletter has also undergone VA) and are part of the development checklist -Plesk WAF active for RocketWeb (and therefore Rocket Newsletter). |
Filters when modifying data, such as messages like “are you sure you want to modify” or requests for validation from other users. |
Depending on the criticality of the operation, the following confirmation mechanisms are activated:
-reversible changes that do not require confirmation; -confirmation request for non-reversible but non-impactful changes (e.g., ticket deletion); -email confirmation request for non-reversible and impactful changes (e.g., VM deletion); -confirmation request with additional input data as an alternative to the previous one. |
Limitation of search capabilities so that a user cannot view data they are not authorized to access. | N/A |
Data on screen and printed without confidential information or information the user is not authorized to access. | N/A |
Possibility of anonymization or pseudonymization of data | N/A |
Types of messages and alerts issued by the system that provide sufficient information to authorized personnel but do not disclose information to malicious users (e.g., providing too many details about the type of error when incorrect credentials are entered). |
Yes.
Example: error and confirmation messages for incorrect passwords and password changes. |
Systems for automatic data deletion or warning when the retention time has been exceeded. | N/A |
Data deletion methods | Responsible for the user. |
Guarantee of vulnerability management and patching (the vendor must provide a notification and correction service). | The services provided are in the cloud, and therefore CoreTech updates packages according to the supplier's specifications. |
Version 2 dated 05/09/2024
Description | |
File sharing service Product Page |
|
Management platform | |
Roles and responsibilities | |
CoreTech acts as Administrator or Sub Responsible for all treatments, while it is the owner of client contact data only
With regards to data compliance and security, both CoreTech and the customer are both responsible, albeit on different fronts. As reported below Link |
|
CoreTech Responsibilities |
-Daily backup check. Backup retention is 35 days (5 weeks)
-Keep Rocketbox servers updated with the most stable and secure software versions released by the manufacturer. -Keep the web server monitored in order to guarantee continuity of service. |
Customer Responsibility |
-Set passwords to access the RocketBox panel.
-Carefully guard your access data to the RocketBox service and limit its disclosure. - Intervene promptly in the event of reports from CoreTech on problems relating to the security of its website. Periodically check the integrated Restore data functionality of your website. -CoreTech in case of anomalies that could lead to a data security problem. |
Datacenter | |
TIER4 - This is the highest level of assurance a datacenter can offer, with 99.9% availability. Identify a catacenter completely redundant in terms of electrical, cooling and network circuits. This indicator refers to an architecture that allows you to cope with serious technical incidents without ever interrupting the availability of servers. | |
Geographic location | European Union |
Labeling | |
Name the files as most appropriate | |
Features available on the Control Panel | |
Rocketbox panel. Control through the Sygma dashboard, which allows resource increase upon purchase. | |
Admin Panel |
-The admin can create users who can access; shared users can act according to sharing criteria set for each folder.
-Passwords are set with complexity requirements for all users and service users. |
SLA | |
Monthly SaaS 99,8% (1h 26m) Ordinary and extraordinary maintenance activities reported on the site 4 hours in advance are excluded |
|
Penalties | |
SLA SaaS <99,8% (1h 26m) = 10% <99,5% (3h 36) = 20% <99,00% (7h 18m 17s) = 50% |
|
Backup | |
The Rocketbox service includes the Backup service replicated on Cloud Storage S3 Backup is done using the 1Backup service SLA RocketBox
|
|
Data Backup |
daily - 40 day retention - 1Backup encryption |
VM backup of the server |
ogni 15 giorni - retention 2 backup dopo si sovrascrive |
Restore |
By request to customer support who will restore what is requested |
Replica Geografica') ?> |
Il backup viene replicato su Cloud Storage S3 - situato in un DataCenter fuori dall'italia in un paese dell'Unione Europea |
Problem Tolerance | |
Multiple Servers |
The servers that provide the Rocketbox storage service are different and multiple These servers are virtual machines residing on Vmware clusters consisting of 3 physical nodes The Services benefit from the Stellar infrastructure Stellar site |
Configuration Storage Raid6 |
The disk configuration of the backup destination storage is in RAID6 The storage on which the data backups reside has dual power supplies and dual network connectivity Il controller dei dischi è doppia |
Disaster Recovery | Replicated data and backup set on another Datacenter. |
Support | |
Support Page - Link | |
Access to Data | |
The customer in possession of the access data can access the data only via web interface or synchronous client or WEBDAV protocol Sono disponibili sistemi per recuperare o modificare il conto password tramite interfaccia web |
|
Contract Cancellation / Closure | |
The data is deleted after 30 days from the cancellation of the service | |
Portability | |
Download complete with the Rocketbox client by yourself. | |
Processo di assistenza per il soddisfacimento dei diritti degli interessati | |
Data Processing Agreement (DPA) - Link page | |
How personal data breaches are handled | |
Data Processing Agreement (DPA) - Link page | |
Evidence Collection | |
If the customer needs to collect evidence or request assistance, he can send the request to the email address
support@coretech.it in case the requested assistance is not within the competence of the support or for other reasons he can contact the Privacy contact at email privacy@coretech.it |
|
User Manual Link | |
KB RocketBox Link | |
Security measures | |
Data Processing Agreement (DPA) - Link page | |
User Management | For customer users, it is possible to manage Sygma users. |
Personal userids for users | For customers, it is possible to create users with personal user IDs. |
Level of detail for configuring access rights to systems (single feature, single transaction, etc.). | With the admin panel, users who can access, their permissions, and authentication methods (including password length and complexity) are independently defined. |
Verification of permissions to access or view processes |
Customers can view users and permissions from the control panels of individual purchased services (including Sygma).
CoreTech can view AdS users by checking individual systems |
Option "change password at first use" when a new user is added or when the password is changed by system administrators (for example, if the user has forgotten it). |
For Sygma users -in case of user creation, password change is mandatory; -for password reset, the user initiates the procedure independently. For services, admin user IDs and passwords are assigned to customers, who manage them independently. |
Password change by the user |
For customers: for password reset, the user initiates the Sygma procedure independently.
For internal AdS, passwords are managed through Sygma. |
Password hidden in the password entry field | Yes. |
Possibility to block the user account after a certain number of incorrect password attempts (not applicable to all system administrators because, in case of an attack, no one would be able to access the system). |
On Sygma, email notifications are enabled for every failed attempt. Additionally, after a certain number of attempts, a slowdown procedure is triggered. Sygma is used for CoreTech AdS Virtual machines block accounts for 5 minutes after 5 failed attempts. However, no alarms are currently triggered. |
Administrative password recovery methods. | It is possible to contact CoreTech support. |
Possibility to assign administrative powers to multiple users, even on individual parts of the system. | Yes. |
Customization of credentials for system administrators (and personal user IDs). | Yes. |
Disabling default userids | Yes. |
Automatic control of password characteristics to ensure users do not choose simple ones: complexity (must include letters and numbers; or lowercase letters, uppercase letters, numbers, and special characters), length (minimum 8 characters), expiration (changed at least every 3 months), lockout for user inactivity (after no more than 6 months), and non-reuse of the last 5 or 10 passwords. | Sygma. |
Automatic control to prevent simple passwords; e.g., passwords not in the dictionary, not a variation of the user ID like Cesare1970, not a variation of the application name like Oracle70, and not a popular password like 12345678 (these rules are considered an alternative and more secure than the complexity rules described above). | Sygma. |
Availability of MFA tools. | For internal AdS: Yes for Sygma. |
Authentication error messages that do not specify details (e.g., "incorrect credentials"). | Yes. |
Configuration to log out users after 5, 10, or more minutes of inactivity. | It depends on the system. |
Configuration so that users cannot connect at specific times or from certain countries. | NO. |
Interfacing methods with other programs or with the user, including encrypted connections, digital certificate exchange, and mutual authentication without administrative or generic accounts. | In some cases, service credentials are used, but with IP origin control. |
Encrypted data storage | Unencrypted data. |
Encrypted data transmission | All connections are encrypted. Certificates with Certum. |
Signing or logging mechanisms to ensure certain levels of non-repudiation of activities. | Signature tools are not available. |
Cryptographic Mechanisms |
Communications are on https with TLS from 1.0 to 1.3.
The server is not encrypted. Customers can encrypt their data independently. |
Access to cryptographic keys is limited to system administrators or internal software processes only. |
Internally, private keys are used with certificates, and certificates can only be modified by AdS.
Customers manage certificates: -independently for services that provide for it; -through CoreTech AdS for other services (e.g., email). |
Cryptographic keys generated using secure methods, starting from randomly generated seeds. | External certificates used. |
Availability of application logs and logs of system administrator activities. | Application logs depend on the application. |
User logs | See above. |
Mechanisms to ensure log security. | Security ensured by the application. |
Mechanisms to establish log retention duration | Set 6 months. |
Methods for connecting the system to existing monitoring systems | See "Infrastructure". |
Clock can be synchronized with an NTP server. | See "Infrastructure". |
Definition of “acceptable performance” | See "Infrastructure". |
System modularity, allowing its various components to be installed in different environments. |
Servers are divided into clusters to optimize performance.
Each service, where appropriate, is further divided into additional servers, preferably in different clusters. Modular services are: -RocketBox with web server, database, and data storage; -Sygma with web server and storage. |
Backup (frequency, retention time, location) | See above. |
Verification and sanitization of incoming data at the server level, especially when received from untrusted sources such as the web (e.g., if a date is expected, the system verifies it is a date and not other characters; if a certain number of characters are expected, the system verifies that the length is not exceeded). | Package, managed either through its own interface or through the Sygma interface (see below). |
Filters when modifying data, such as messages like “are you sure you want to modify” or requests for validation from other users. |
Depending on the criticality of the operation, the following confirmation mechanisms are activated: -reversible changes that do not require confirmation; -confirmation request for non-reversible but non-impactful changes (e.g., ticket deletion); -email confirmation request for non-reversible and impactful changes (e.g., VM deletion); -confirmation request with additional input data as an alternative to the previous one. |
Data on screen and printed without confidential information or information the user is not authorized to access. | No for the type of service. |
Possibility of anonymization or pseudonymization of data | No for the type of service. |
Types of messages and alerts issued by the system that provide sufficient information to authorized personnel but do not disclose information to malicious users (e.g., providing too many details about the type of error when incorrect credentials are entered). |
Yes.
Example: error and confirmation messages for incorrect passwords and password changes. |
Systems for automatic data deletion or warning when the retention time has been exceeded. | No for the type of service. |
Data deletion methods | At the end of the service, the single instance is deleted (without encryption). |
Guarantee of vulnerability management and patching (the vendor must provide a notification and correction service). | The services provided are in the cloud, and therefore CoreTech updates packages according to the supplier's specifications. |
Version 2 dated 05/09/2024
Description | |
Sigillo is the advanced electronic signature that allows you to sign contracts with a simple and fast workflow. The process of sending the contracts is carried out entirely via web browser, both for those who send the contract and for those who receive it. | |
Roles and responsibilities | |
&nbps; | |
CoreTech Responsibilities | Mantenere la piattaforma. |
Customer Responsibility | Use the platform diligently. |
Datacenter | |
TIER4 - This is the highest level of assurance a datacenter can offer, with 99.9% availability. Identify a catacenter completely redundant in terms of electrical, cooling and network circuits. This indicator refers to an architecture that allows you to cope with serious technical incidents without ever interrupting the availability of servers. | |
Geographic location | European Union |
Labeling | |
N/A | |
Features available on the Control Panel: | |
Admin Panel | N/A |
SLA | |
Monthly SaaS 99,8% (1h 26m) Ordinary and extraordinary maintenance activities reported on the site 24 hours in advance are excluded. (except for emergencies related to safety problems that require our immediate intervention) |
|
Penalties | |
SLA SaaS <99,8% (1h 26m) = 10% <99,5% (3h 36) = 20% <99,00% (7h 18m 17s) = 50% |
|
Backup | |
Sigillo is a service based on Rocketweb and therefore the Backup features correspond to Rocketweb. | |
Problem Tolerance | |
Sigillo is a service based on Rocketweb and therefore the characteristics of Tolerance correspond to Rocketweb. | |
Support | |
Standard | |
Access to Data | |
The user in possession of the access data to the platform has been authorized and has access to all the data contained in the documents and the tracking of signature data. CoreTech has no direct visibility of the data contained and cannot remotely access the machines unless it is expressly requested and authorized by the client. |
|
Contract Cancellation / Closure | |
.The data is deleted after 60 days from the termination of the service. | |
Portability | |
N/A | |
Processo di assistenza per il soddisfacimento dei diritti degli interessati | |
Data Processing Agreement (DPA) - Link page | |
How personal data breaches are handled | |
Data Processing Agreement (DPA) - Link page | |
Evidence Collection | |
If the customer needs to collect evidence or request assistance, he can send the request to the email address support@coretech.it in case the requested assistance is not within the competence of the support or for other reasons he can contact the Privacy contact at email privacy@coretech.it |
|
User Manual Link | |
KB Sigillo Link | |
Security measures | |
Data Processing Agreement (DPA) - Link page | |
User Management | For customer users, it is possible to manage Sygma users. |
Personal userids for users | For customers, it is possible to create users with personal user IDs. |
Level of detail with which access rights to systems can be configured (single feature, single transaction, etc.). | Access guaranteed for every user. |
Verification of permissions to access or view processes |
Customers can view users and permissions from the control panels of individual purchased services (including Sygma).
CoreTech can view AdS users by checking individual systems |
Option "change password at first use" when a new user is added or when the password is changed by system administrators (for example, if the user has forgotten it). |
For Sygma users
- in case of account creation, password change is mandatory; - for password reset, the user initiates the procedure independently. For services, admin user IDs and passwords are assigned to customers, who manage them independently. |
Password change by the user |
For customers: for password reset, the user initiates the Sygma procedure independently. For internal AdS, passwords are managed through Sygma. |
Password hidden in the password entry field. | Yes. |
Possibility to block the user account after a certain number of incorrect password attempts (not applicable to all system administrators because, in case of an attack, no one would be able to access the system). |
On Sygma, email notifications are enabled for every failed attempt.
Additionally, after a certain number of attempts, a slowdown procedure is triggered. Sygma is used for CoreTech AdS Virtual machines block accounts for 5 minutes after 5 failed attempts. However, no alarms are currently triggered. |
Administrative password recovery methods. | It is possible to contact CoreTech support. |
Possibility to assign administrative powers to multiple users, even on individual parts of the system. | Yes. |
Customization of credentials for system administrators (and personal user IDs). | Yes. |
Disabling default userids | Not applicable |
Automatic control of password characteristics to ensure users do not choose simple ones: complexity (must include letters and numbers; or lowercase letters, uppercase letters, numbers, and special characters), length (minimum 8 characters), expiration (changed at least every 3 months), lockout for user inactivity (after no more than 6 months), and non-reuse of the last 5 or 10 passwords. | Sygma. |
Automatic control to prevent simple passwords; e.g., passwords not in the dictionary, not a variation of the user ID like Cesare1970, not a variation of the application name like Oracle70, and not a popular password like 12345678 (these rules are considered an alternative and more secure than the complexity rules described above). | Sygma. |
Availability of MFA tools. | For internal AdS: Yes for Sygma. |
Authentication error messages that do not specify details (e.g., "incorrect credentials"). | Yes. |
Configuration to log out users after 5, 10, or more minutes of inactivity. | It depends on the system. |
Configuration so that users cannot connect at specific times or from certain countries. | NO. |
Interfacing methods with other programs or with the user, including encrypted connections, digital certificate exchange, and mutual authentication without administrative or generic accounts. | In some cases, service credentials are used, but with IP origin control. |
Encrypted data storage. | Unencrypted data. |
Encrypted data transmission | All connections are encrypted. Certificates with Certum. |
Signing or logging mechanisms to ensure certain levels of non-repudiation of activities. | Signature product itself. |
Cryptographic Mechanisms | Communications are on https with TLS from 1.0 to 1.3. The server is not encrypted. Customers can encrypt their data independently. |
Access to cryptographic keys is limited to system administrators or internal software processes only. |
Internally, private keys are used with certificates, and certificates can only be modified by AdS.
Customers manage certificates: -independently for services that provide for it; -through CoreTech AdS for other services (e.g., email). |
Cryptographic keys generated using secure methods, starting from randomly generated seeds. | External certificates used. |
Availability of application logs and logs of system administrator activities. | Application logs depend on the application. |
User logs | See above. |
Mechanisms to ensure log security. | Security ensured by the application. |
Mechanisms to establish log retention duration. | Set 6 months. |
Methods for connecting the system to existing monitoring systems | See "Infrastructure". |
Clock can be synchronized with an NTP server. | See "Infrastructure". |
Definition of “acceptable performance” | See "Infrastructure". |
System modularity, allowing its various components to be installed in different environments. |
Servers are divided into clusters to optimize performance.
Each service, where appropriate, is further divided into additional servers, preferably in different clusters. |
Backup (frequency, retention time, location) | See above. |
Verification and sanitization of incoming data at the server level, especially when received from untrusted sources such as the web (e.g., if a date is expected, the system verifies it is a date and not other characters; if a certain number of characters are expected, the system verifies that the length is not exceeded). |
Developed in-house:
All inputs are validated (Rocket Newsletter has also undergone VA) and are part of the development checklist -Plesk WAF active for RocketWeb (and therefore Rocket Newsletter). |
Filters when modifying data, such as messages like “are you sure you want to modify” or requests for validation from other users. |
Depending on the criticality of the operation, the following confirmation mechanisms are activated:
-reversible changes that do not require confirmation; -confirmation request for non-reversible but non-impactful changes (e.g., ticket deletion); -email confirmation request for non-reversible and impactful changes (e.g., VM deletion); -confirmation request with additional input data as an alternative to the previous one. |
Limitation of search capabilities so that a user cannot view data they are not authorized to access. | No for the type of service. |
Data on screen and printed without confidential information or information the user is not authorized to access. | No for the type of service. |
Possibility of anonymization or pseudonymization of data | No for the type of service. |
Types of messages and alerts issued by the system that provide sufficient information to authorized personnel but do not disclose information to malicious users (e.g., providing too many details about the type of error when incorrect credentials are entered). |
Yes.
Example: error and confirmation messages for incorrect passwords and password changes. |
Systems for automatic data deletion or warning when the retention time has been exceeded. | The information belongs to the user, who therefore decides independently whether to delete it. |
Data deletion methods | At the end of the service, the single instance is deleted (without encryption). |
Guarantee of vulnerability management and patching (the vendor must provide a notification and correction service). | The services provided are in the cloud, and therefore CoreTech updates packages according to the supplier's specifications. |
Document title: | SLA_services |
---|---|
Document version: | V. 2 |
Date of last adjustment: | 04/11/2021 |
Management and quality
Management of data and security information
Security management
for Cloud Providers
Management of personal data
in Cloud
Information management
on Privacy
Data protection