Overview
This document is designed to provide an overview of the procedures that we have in place to ensure that your systems are available and your confidential information is secure. It covers the information about your business and processes that you share with us, and your data that you maintain on our hosted environment.
You should read this policy in conjunction with our Service Level Agreement and service Terms & Conditions.
Responsibility matrix
Regarding security, some areas are the responsibility of our hosting provider, which rents us a data center. Some areas are the responsibility of Valiantys, which handles the service installation and support. Finally, some areas are the responsibility of Atlassian, that develop & maintain the software.
Valiantys Support
Valiantys Cloud
Definitions
| Term | Description |
|---|---|
| AWS regions & availability zones | Amazon EC2 is hosted in multiple locations world-wide. These locations are composed of regions and Availability Zones. Each region is a separate geographic area. Each region has multiple, isolated locations known as Availability Zones. |
| VPC & Subnet | A Virtual Private Cloud (VPC) is an on-demand configurable pool of shared computing resources allocated within a public cloud environment, providing a certain level of isolation between the different organizations (denoted as users hereafter) using the resources. The isolation between one VPC user and all other users of the same cloud (other VPC users as well as other public cloud users) is achieved normally through allocation of a Private IP Subnet and a virtual communication construct (such as a VLAN or a set of encrypted communication channels) per user. In a VPC solution, the previously described mechanism, providing isolation within the cloud, is accompanied with a VPN function (again, allocated per VPC user) that secures, by means of authentication and encryption, the remote access of the organization to its VPC cloud resources. With the introduction of the described isolation levels, an organization using this service is in effect working on a ‘virtually private’ cloud (that is, as if the cloud infrastructure is not shared with other users), and hence the name VPC. |
| Security group | A security group acts as a virtual firewall that controls the traffic for one or more instances. When you launch an instance, you associate one or more security groups with the instance. You add rules to each security group that allow traffic to or from its associated instances. You can modify the rules for a security group at any time; the new rules are automatically applied to all instances that are associated with the security group. When we decide whether to allow traffic to reach an instance, we evaluate all the rules from all the security groups that are associated with the instance. |
| Elastic IP | An Elastic IP address is a static IP address designed for dynamic cloud computing. An Elastic IP address is associated with your AWS account. With an Elastic IP address, you can mask the failure of an instance or software by rapidly remapping the address to another instance in your account. |
Data Center location
| Amazon Web Services | Orange Flexible Engine |
|---|---|
| US East N. Virginia, Ohio |
France Pantin, Aubervilliers et Saint Denis |
| US West N. California, Oregon |
|
| Canada Central |
|
| Europe Frankfurt, Dublin, London, Paris, Stockholm |
Standards
Valiantys aligns with ISO 27001, supported by strong processes, documentation and culture. Data centres used by us have the following accreditations:
| Amazon Web Services | Orange Flexible Engine |
|---|---|
See https://aws.amazon.com/fr/compliance/ for more details. |
See https://cloud.orange-business.com/en/3rd-az-in-paris-region/
|
Physical and environmental security
Fire detection and suppression
| Amazon Web Services | Orange Flexible Engine |
|---|---|
| Automatic fire detection and suppression equipment has been installed to reduce risk. The fire detection system utilizes smoke detection sensors in all data center environments, mechanical and electrical infrastructure spaces, chiller rooms and generator equipment rooms. These areas are protected by either wet-pipe, double-interlocked pre-action, orgaseous sprinkler systems. | Fire protection is provided by two complementary systems: high sensitivity smoke detection and a water mist fire-fighting system.
Supervision center |
Power
| Amazon Web Services | Orange Flexible Engine |
|---|---|
| The data center electrical power systems are designed to be fully redundant and maintainable without impact to operations, 24 hours a day, and seven days a week. Uninterruptible Power Supply (UPS) units provide back-up power in the event of an electrical failure for critical and essential loads in the facility. Data centers use generators to provide back-up power for the entire facility. | Energy management: in order to reduce infrastructures ecological footprint, Orange has selected eco-friendly data center. To avoid any power outage, the power supply is doubled and the sites have autonomous generators.
Redundant supply systems Redundant general table of low-voltage distribution Generator – with 72-hour minimal autonomy Inverters |
Climate and Temperature
| Amazon Web Services | Orange Flexible Engine |
|---|---|
| Climate control is required to maintain a constant operating temperature for servers and other hardware, which prevents overheating and reduces the possibility of service outages. Data centers are conditioned to maintain atmospheric conditions at optimal levels. Personnel and systems monitor and control temperature and humidity at appropriate levels. | N+1 redundancy, meaning that the failure of one air conditioning tool has no impact on the cold production chain |
Storage device decomissioning
| Amazon Web Services | Orange Flexible Engine |
|---|---|
| When a storage device has reached the end of its useful life, AWS procedures include a decommissioning process that is designed to prevent customer data from being exposed to unauthorized individuals. AWS uses the techniques detailed in DoD 5220.22-M (“National Industrial Security Program Operating Manual“) or NIST 800-88 (“Guidelines for Media Sanitization”) to destroy data as part of the decommissioning process. All decommissioned magnetic storage devices are degaussed and physically destroyed in accordance with industry-standard practices. | Protection of de-allocated customer data Customer data located on de-allocated resources cannot be accessed by another customer. This protection is provided by the internal mechanisms of the products used by Orange. For example, OpenStack has an internal process to erase the resource before allocating it to another customer. Deletion of customer data at termination of contract When the contract terminates, all the resources allocated to customers are de-allocated, and the customer data become unusable, as explained in the previous paragraph. Secure disposal or re-use of equipment All items of equipment containing storage media will be checked to ensure that any sensitive data and licensed software has been removed or securely overwritten prior to disposal. Orange has established security policies detailing the sanitization and disposal procedures for handling storage devices. |
Physical access to the Data Center
| Amazon Web Services | Orange Flexible Engine |
|---|---|
| AWS’s data centers are state of the art, utilizing innovative architectural and engineering approaches. Amazon has many years of experience in designing, constructing, and operating large-scale data centers. This experience has been applied to the AWS platform and infrastructure. AWS data centers are housed in nondescript facilities. Physical access is strictly controlled both at the perimeter and at building ingress points by professional security staff utilizing video surveillance, intrusion detection systems, and other electronic means. Authorized staff must pass two-factor authentication a minimum of two times to access data center floors. All visitors and contractors are required to present identification and are signed in and continually escorted by authorized staff. AWS only provides data center access and information to employees and contractors who have a legitimate business need for such privileges. When an employee no longer has a business need for these privileges, his or her access is immediately revoked, even if they continue to be an employee of Amazon or Amazon Web Services. All physical access to data centers by AWS employees is logged and audited routinely. |
Physical security: rigorous access control of data centers, including identifying persons after authorization is granted to enter data rooms. The sites are protected and supervised 24×7 with triple access control and video surveillance systems.
Tolerance to breakdowns and maintenance – The technical architectures used enable the following operating constraints to be met:
The management modes and the processes used ensure the security of personnel, buildings and the equipment in them. |
Business Continuity Management
Availability
| Amazon Web Services | Orange Flexible Engine |
|---|---|
| Data centers are built in clusters in various global regions. All data centers are online and serving customers; no data center is “cold.” In case of failure, automated processes move customer data traffic away from the affected area. Core applications are deployed in an N+1 configuration, so that in the event of a data center failure, there is sufficient capacity to enable traffic to be load-balanced to the remaining sites. | All our Cloud services have complete infrastructure redundancy over several sites (or, as a temporary exception, over several computer rooms), with high availability mechanisms so that local failures are made transparent: network (Internet access, VPN access, firewall), administration portal, virtualization, storage, etc.
Backups (configurations, customer backups) are in priority replicated on remote sites to guarantee the availability of data in case of a major incident on the production site. Depending on the service, remote customer backups may only be proposed as an option. Thus, if an operation site becomes totally unavailable, administration continuity is ensured for the Cloud services. |
Company-wide executive review
| Amazon Web Services | Orange Flexible Engine |
|---|---|
| Amazon’s Internal Audit group has recently reviewed the AWS services resiliency plans, which are also periodically reviewed by members of the Senior Executive management team and the Audit Committee of the Board of Directors. | A Security Committee meeting – including the Security Managers (Engineering and Operations) and the Product Manager – monthly reviews:
|
Network security
Secure network architecture
| Amazon Web Services | Orange Flexible Engine |
|---|---|
| Network devices, including firewall and other boundary devices, are in place to monitor and control communications at the external boundary of the network and at key internal boundaries within the network. These boundary devices employ rule sets, access control lists (ACL), and configurations to enforce the flow of information to specific information system services. ACLs, or traffic flow policies, are established on each managed interface, which manage and enforce the flow of traffic. ACL policies are approved by Amazon Information Security. These policies are automatically pushed using AWS’s ACL-Manage tool, to help ensure these managed interfaces enforce the most up-to-date ACLs. | The architectures apply the same model of separating the trust areas, including the Back-End (internal Orange) and the Front-End – which supports the Cloud services exposed to the customers. The Back-End – Front-End partitioning is physical, which means that some servers are dedicated to the Back-End and other ones are dedicated to the Front-End.
Within each trust area, security zones provide a logical partitioning by the implementation of certain features such as:
This logical partitioning guarantees the insulation of the different customer environments. The communications (network flow) between the different security zones are systematically controlled by firewalls (stateful filtering). The local configuration of the various components is also constructed to reinforce the partitioning and security (ex: ACL in routers). |
Secure access points
| Amazon Web Services | Orange Flexible Engine |
|---|---|
| AWS has strategically placed a limited number of access points to the cloud to allow for a more comprehensive monitoring of inbound and outbound communications and network traffic. These customer access points are called API endpoints, and they allow secure HTTP access (HTTPS), which allows you to establish a secure communication session with your storage or compute instances within AWS. To support customers with FIPS cryptographic requirements, the SSL-terminating load balancers in AWS GovCloud (US) are FIPS 140-2-compliant. In addition, AWS has implemented network devices that are dedicated to managing interfacing communications with Internet service providers (ISPs). AWS employs a redundant connection to more than one communication service at each Internet-facing edge of the AWS network. These connections each have dedicated network devices. | Flexible Engine provides services that allow a user to create a virtualized infrastructure over a shared physical infrastructure for all users. The virtualization mechanisms implemented ensure a strong logical partitioning of the client’s virtualized resources (one per client). The access to the resources of a tenant is done through the OpenStack APIs implementing a strong (login / password / token) and secure (in SSL via https) authentication.
The customers connect to Cloud environments for purposes of administration or access to applicative services. The environments can be accessed via the Internet and / or a private network (VPN client), based on the features and options selected by the customer. The customers’ access are always secured using SSL / TLS (HTTPS or SSH flows):
|
Transmission protection
| Amazon Web Services | Orange Flexible Engine |
|---|---|
| You can connect to an AWS access point via HTTPS using Secure Sockets Layer (SSL), a cryptographic protocol that is designed to protect against eavesdropping, tampering, and message forgery. For customers who require additional layers of network security, AWS offers the Amazon Virtual Private Cloud (VPC), which provides a private subnet within the AWS cloud, and the ability to use an IPsec Virtual Private Network (VPN) device to provide an encrypted tunnel between the Amazon VPC and your data center. | The customers connect to Cloud environments for purposes of administration or access to services.
The customers’ administration flows are systematically secured by protocols to ensure the authentication, the confidentiality and the integrity (SSLv3/TLS, AES256, …). The access methods vary depending on the features and options selected by the customer. The safety of service flows depends on the offer, but in general the exchanges are secured with SSL/TLS connections. Virtual Private Cloud (VPC) features, carried by the Neutron Openstack component, provide a logical partitioning of communications on the user network. Any form of network traffic that is not naturally authorized on the customers tenant is not processed by the devices supporting the client’s virtual network, preventing any use of spoofing technologies. All tenants traffic are routed northwise/upwards where routing is done under layers of security provided by industry level firewalling with state of the art firewalling device. |
Fault-tolerant design
| Amazon Web Services | Orange Flexible Engine |
|---|---|
| AWS has designed its systems to tolerate system or hardware failures with minimal customer impact. Data centers are built in clusters in various global regions. All data centers are online and serving customers; no data center is “cold.” In case of failure, automated processes move customer data traffic away from the affected area. Core applications are deployed in an N+1 configuration, so that in the event of a data center failure, there is sufficient capacity to enable traffic to be load-balanced to the remaining sites. | TIER classification – The data centers for Flexible Engine are built and operated to be compatible with TIER III requirements. Tolerance to breakdowns and maintenance – The technical architectures used enable the following operating constraints to be met : No impact on load when the first fault occurs. High breakdown tolerance, up to 2 major faults without impact. No interruption to service during maintenance operations. The management modes and the processes used ensure the security of personnel, buildings and the equipment in them. |
Network monitoring and protection
| Amazon Web Services | Orange Flexible Engine |
|---|---|
| AWS utilizes a wide variety of automated monitoring systems to provide a high level of service performance and availability. AWS monitoring tools are designed to detect unusual or unauthorized activities and conditions at ingress and egress communication points. These tools monitor server and network usage, port scanning activities, application usage, and unauthorized intrusion attempts. The tools have the ability to set custom performance metrics thresholds for unusual activity. AWS security monitoring tools help identify several types of denial of service (DoS) attacks, including distributed, flooding, and software/logic attacks. When DoS attacks are identified, the AWS incident response process is initiated. In addition to the DoS prevention tools, redundant telecommunication providers at each region as well as additional capacity protect against the possibility of DoS attacks. The AWS network provides significant protection against traditional network security issues, and you can implement further protection. The following are a few examples:
In addition to monitoring, regular vulnerability scans are performed on the host operating system, web application, and databases in the AWS environment using a variety of tools. Also, AWS Security teams subscribe to newsfeeds for applicable vendor flaws and proactively monitor vendors’ websites and other relevant outlets for new patches. AWS customers also have the ability to report issues to AWS via the AWS Vulnerability Reporting website at: http://aws.amazon.com/fr/security/vulnerability-reporting/. |
Orange Business Services has means of protecting its customers against denial of service attacks and network intrusion attacks in Flexible Engine. To simplify the complex defense-in-depth security design and implementation of security solutions, we have defined security zones and holistic network segregation strategy to minimize the impact of attacks based on business functions and security risks. In addition to advanced perimeter protection measures of Flexible Engine, the tenants can also set fine-grained policies on Anti-DDoS for their EIPs, security groups in VPC and access controls via IAM to strengthen overall protection against external threat actors and malicious insiders.
ECS uses resource isolation, network isolation, security group rules, anti-DDoS, and brute-force attack prevention to provide a secure environment. ECS supports 99.95% availability and 99.99995% data durability.
Virtual Private Cloud (VPC) features, carried by the Neutron Openstack component, provide a logical partitioning of communications on the user network. Any form of network traffic that is not naturally authorized on the customers tenant is not processed by the devices supporting the client’s virtual network, preventing any use of spoofing technologies. All tenants traffic are routed northwise/upwards where routing is done under layers of security provided by industry level firewalling with state of the art firewalling device.
To avoid network issues that may occur if users change their IP or MAC addresses at will, IP and MAC addresses are bound together using DHCP snooping. Spoofing is further prevented by using IP Source Guard and dynamic ARP inspection (DAI) to filter out packets from unbound addresses
This system protects against massive attacks by denial of service from the Internet, and is triggered as soon as the attack reaches 1 Gb of traffic. It is deployed in the heart of the Orange Group’s operator network and it uses safety equipment specifically designed for this purpose. The solution offers two levels of service, one standard and one optional:
Firewalls protect the Orange Cloud platforms against attacks with weaker volumes (less than 2 GB) but in a finer manner, filtering only the packets deemed suspicious by analyzing certain protocols, such as:
IDS probes are used to monitor Cloud administration services (administration portal, administration services, …). The virtual machines dedicated to a customer are not monitored by default because the analysis of the alerts requires knowing the customer’s context. The implementation of the monitoring of the customer’s servers can be proposed as an option. More generally, the monitoring implemented on all the components of the infrastructure ensures a global intrusion detection |
Account review and audit
| Amazon Web Services | Orange Flexible Engine |
|---|---|
| Accounts are reviewed every 90 days; explicit re-approval is required or access to the resource is automatically revoked. Access is also automatically revoked when an employee’s record is terminated in Amazon’s Human Resources system. Windows and UNIX accounts are disabled and Amazon’s permission management system removes the user from all systems. Requests for changes in access are captured in the Amazon per missions management tool audit log. When changes in an employee’s job function occur, continued access must be explicitly approved to the resource or it will be automatically revoked. | A review of authorizations and rights is carried out every semester. This activity consists in comparing the Human Resource file, describing the roles of each person, with the actual rights assigned in the systems. If non-legitimate rights are discovered, suitable measures are applied: Suspension of the account Examination of traces of use to reveal any incidents Corrective measures (updating procedures, having management made aware of the issue, etc.). These reviews are the subject of a report and are audited yearly by external auditors.The procedure for assigning/revoking an account and its associated rights, called CARM (Controlling Access Rights Management), is applied and monitored. This procedure is an ISMS security measure (Information Security Management Systems), certified ISO 27001 and deployed by Orange. Shared accounts are prohibited. |
Background checks
| Amazon Web Services | Orange Flexible Engine |
|---|---|
| AWS has established formal policies and procedures to delineate the minimum standards for logical access to AWS platform and infrastructure hosts. AWS conducts criminal background checks, as permitted by law, as part of pre-employment screening practices for employees and commensurate with the employee’s position and level of access. The policies also identify functional responsibilities for the administration of logical access and security. | Orange has formal policies in place to ensure background checks are executed within their team during the hiring process, conforming with local regulations. |
VPN
| Amazon Web Services | Orange Flexible Engine |
|---|---|
| A VPN connection can be set up as an option between your network and your VPC on AWS, in order to integrate tools from your infrastructure and tools hosted on our Cloud offer, e.g. LDAP/Active Directory integration, other Atlassian tools, remote data source… | VPN as a Service is available to connect your network to the Orange Flexible Engine VPC: https://cloud.orange-business.com/en/offers/infrastructure-iaas/public-cloud/features/vpn-as-a-service/ |
Workstations security
All members from our Managed Services team are equipped with Cisco AMP, protecting us from viruses, malware and data leakage.
Separated private clouds per customer
Each customer has its own VPC (Virtual Private Cloud), segregating its network and data from other customers’.
Firewalls
| Amazon Web Services | Orange Flexible Engine |
|---|---|
| Each server is connected to a Security Group that serves as a Firewall for inbound and outbound connections. | Each server is connected to a Security Group that serves as a Firewall for inbound and outbound connections. |
The default configuration is as follows:
| Inbound | Outbound | ||
|---|---|---|---|
| Port | Source | Port | Destination |
| 22 | Only bastion servers which are accessible only from Valiantys offices IP addresses | All | Anywhere |
| 80 | Anywhere* | ||
| 443 | Anywhere | ||
*please note that all requests sent on port 80 are rewritten to port 443 automatically with HTTPS using an Apache HTTPD rewrite rule.
That default firewall setup can be customized depending on the customer’s requirements.
Credentials
Individual user accounts
Each member of our Managed Services team has access to administration console & servers using an individual account.
All actions are logged and accessible at any time from our team. Access logs are kept for a period of 4 weeks.
Password policy
AWS & OFE Console access requires a password that contains at least 8 characters, including an upper-case letter, a lower-case letter, a number and a special character. The password must be changed every 40 days, and a similarity check is done with the 5 last passwords.
Multi-Factor Authentication
In addition to login/password protection, access to the AWS console requires a code that is generated by Google Authenticator (or Authy) mobile app associated to that user’s account. Codes are generated every 30 seconds.
Server access
Server access through SSH is only possible through bastion servers from the Valiantys different locations’ static IP due to security group and VPC peering configuration. Access is secured using an individual passphrase-protected private key.
Private keys are securely stored on each person’s computer.
Data security
Data access
Our providers (AWS or OFE) do not have access to any of the tools that we install for our customers. They also do not have SSH access to the servers that we deploy on their infrastructure.
As data is encrypted on volumes we deploy, they cannot have access to any stored data.
Data deletion at the end of the contract
Valiantys is committed to deleting all customer data at the end of the contract.
If a customer wishes not to renew its contract, we follow this process:
- We do a full backup of the customer environment (XML backup + attachments for all Atlassian tools)
- We provide the customer with this backup using a secure method (provided by the customer or by default using an AWS S3 bucket with dedicated login/password)
- Once the customer has successfully retrieved all data, we remove this data from the repository
- We shut down the server and delete it completely
- We wait for 1 month before deleting the snapshots of the servers in case the customer would have issues importing the data on his end. This delay could be reduced upon customer’s request.
Once all data has been deleted on our end, we send the customer an email stating that Valiantys does not hold customer data anymore.
SSL
Access to Atlassian tools is only possible through SSL (TLS v1.2 protocol) using our default *.valiantys.net certificate (2048 bits key), or certificates provided by the customer and associated to its own domain name.
Data encryption
| Amazon Web Services | Orange Flexible Engine |
|---|---|
| File system can be encrypted with a unique 256-bit key, all snapshots from that server would then be encrypted using the same key.
Amazon’s overall key management infrastructure uses Federal Information Processing Standards (FIPS) 140-2 approved cryptographic algorithms and is consistent with National Institute of Standards and Technology (NIST) 800-57 recommendations. |
File system can be encrypted with a unique 256-bit key, all snapshots from that server would then be encrypted using the same key.
LUKS encryption is used to encrypt the whole partition where Atlassian tools and the database is installed. |
Security logs
All sorts of logs are recorded on the servers we manage:
- SSH access logs that log all SSH accesses to the server
- Apache HTTPD access logs that log all HTTP requests that enters the server
- Applications access logs that log all HTTP requests that enters the tools
Those log files are accessible upon request.
Backups
Full VM snapshots are done automatically every night around midnight and kept for 7 days. Snapshots are encrypted.
In addition to those backups, XML backups are automatically generated every day on Atlassian tools. They allow for a quicker data retrieval in some cases (i.e. data deleted by error).
These XML backups can be disabled by our team on larger environments to avoid performance issues.
Backups retention
VM snapshots & XML exports are automatically deleted after 7 days.
Restore procedure
Restore procedure depends on the type of failure that is encountered. Our Managed Services team can choose from the two methods after analyzing your issue.
VM snapshot restore:
- We use the snapshot to create a new VM of the same size
- We redirect the server’s IP to the newly created server (usually takes ~10mn)
XML export restore:
- We copy the XML export to the restore folder
- We start the XML import process (can take from a few minutes to a few hours depending on your environment size)
Restore procedure check
In order to make sure our backups and backup procedures are working as expected, we run a restore test for all our servers once per year.
A report of the results can be provided to the customer on request.
Pen tests
We run black box penetration tests at least annually on all our servers.
We run white box penetration tests at least annually on a sandbox environment which we create using the standard setup process we use for creating client environment. This helps us continuously improving our security.
We also allow customers to run their own penetration tests (by themselves or through a third party).
If a customer wants to organize penetration tests, he needs to reach out to us at least 4 weeks in advance as we need to get approval from our providers.
Vulnerability Management
Detection process
We carry out a weekly review of our reference base using specialized tools in addition to any alerts provided by Atlassian.
Detection times
The detection period is 7 days (except for an Atlassian notification during this period)
Treatment delays
Treatment is immediate. As soon as the vulnerability is known, an incident ticket is automatically created on behalf of the customer, in order to organize the remediation with his agreement and in order to impact at least the production service.
Without a response from the customer within 7 days, the vulnerability will be automatically addressed without waiting for consent on unworked slots.
Operations
Security organization
The person accountable for security in the company is currently Nathan Chantrenne, CTO.
We do not have a dedicated security team. All members of our Managed Services team are aware of security rules applied at Valiantys and are able to deal with security incidents.
A corporate security policy is in place and is part of our company rules and regulations that needs to be accepted by any member of Valiantys. It includes the following sections:
Information Security Policy organization
- INTRODUCTION
- Purpose
- Scope
- History
- Responsibilities
- General Policy Definition
- Glossary
- NETWORK ACCESS POLICY
- Purpose
- Scope
- Policy Definition
- DATA, INFORMATION AND SECURITY POLICY
- General Use and Ownership
- Security and Proprietary Information
- Unacceptable Use
- POLICY COMPLIANCE
- Compliance Measurement
- Exceptions
- Non-Compliance
- IT ASSETS POLICY
- Purpose
- Scope
- Policy Definition
- ACCESS CONTROL POLICY
- Purpose
- Scope
- Policy Definition
- PASSWORD CONTROL POLICY
- Purpose
- Scope
- Policy Definition
- Statement of guidelines
- EMAIL POLICY
- Purpose
- Scope
- Policy Definition
- INTERNET POLICY
- Purpose
- Scope
- Policy Definition
- ANTIVIRUS POLICY
- Purpose
- Scope
- Policy Definition
- INFORMATION CLASSIFICATION POLICY
- Purpose
- Scope
- Policy Definition
- REMOTE ACCESS POLICY
- Purpose
- Scope
- Policy Definition
- OUTSOURCING POLICY
- Purpose
- Scope
- Policy Definition
- Mandatory
- PATCH MANAGEMENT POLICY
- Purpose
- Scope
- Policy Definition
- CLOUD APPLICATION INFORMATION POLICY
- Purpose
- Scope
- Policy Definition
Before hiring new employees, we run a background check that depends on the country where they are hired:
- A basic Criminal Disclosure
- Employment History & Gap Analysis
- ID Check
- Right to Work check
Change management process
Change submission
When in a Support ticket a change is requested by a customer or identified by the Support engineer, a workflow transition allows to reach a specific status. From that status it will be possible to create a Change ticket in the dedicated Jira project via a dedicated button. The created Change ticket includes the following information:
- Description – ex: Jira uprgade to 8.5.3 on MyCustomer PROD instance
- Priority – ex: Critical
- Origin – ex: Notification from Atlassian
- Reason for Change – ex: Security vulnerability on Jira version currently installed
- Risk analysis – ex:
- Same parameters in setenv.sh and server.xml configuration files
- Compatibility of installed apps – upgrade the impacted ones if needed
- Apps requiring paid license – client must be informed as well as the account manager
- No unforeseen security risk, as the data is not transferred anywhere
- Change procedure – ex: <link_to_the_corresponding_internal_documentation>
- Rollback procedure – ex: Restore of the snapshot generated before the operation
- Estimated duration – ex: 1h
- Link to the related Support ticket – Automatically defined by the Jira app creating the Change ticket
Change approval
After creation and depending on what type of Change is expected, the Change ticket is assigned to a Support Team Leader or a Cloud Architect. The designated assignee reviews the information provided by the reporter and decides to approve or reject the Change request.
There are some reasons to refuse a Change: technical risk, security risk, unclear or incomplete procedure, etc. In case the Change is refused, the Change ticket is closed and the workflow of the related Support ticket is automatically set back to the previous status in consequence.
If the Change is approved, a form allows to schedule the corresponding operation via the following fields:
- Start Date – i.e. date and time the Change operation will start
- End Date – i.e. date and time the Change operation will end
- Assignee – i.e. the resource in charge of the execution of that operation.
In consequence, the Change ticket is updated with those information and the workflow of the related Support ticket is automatically set to a new status indicating that a corrective operation is planned.
Change application
Once the Change has been applied, the resource assigned to the operation updates the workflow status of the Change ticket, which automatically triggers an update of the workflow of the related Support ticket so that the processing of that ticket resumes.
Emergency Change
In case of urgent issues – ex: blocking issue raised by a customer or security vulnerability raised by Atlassian impacting some application versions, an emergency Change process is applied, with the following deviations in regard of the regular process:
- A Support Team Leader or Cloud Architect handles the corresponding Support ticket, creates and approves the related Change ticket
- The Change is planned to the shortest delay possible, depending on the availability of the Support resources and the customer’s agreement
Change committee
Every Monday afternoon, a 30-minute Change committee including at least the Head Of Managed Services, the Support Offerings and Cloud Offerings Managers, and the Support Team Leaders, review the Change tickets processed over the last period using a dedidcated Jira Dashboard.
Incident management process
Incidents are created by customers using emails, our support portal or by the Valiantys Managed Services team.
An incident can be declared as severity 1, 2, 3 or 4. Definition for our severity levels can be found on https://valiantys.com/en/legal/sla/
Our Managed Services team handles tickets in the following priority order:
- Service down (incidents are automatically created from our monitoring tool) – with a 30mn recovery time objective
- Security incidents
- S1 incidents
- SLA breached tickets
- All other tickets ordered by SLA
Here is the incident workflow.
Workflow
- When the ticket is created, it arrives with “Submitted” status
- As soon as our team starts working on it, the ticket moves to “In progress” status
- If we need more information from you, the ticket is moved to “Waiting for customer” status, and a comment is added on the ticket detailing what information we need to solve the issue.
- If we need a third party to help solve the issue, the ticket is moved to “Waiting for customer” status. Third parties could be Atlassian, an add-on vendor or a hosting provider.
- When providing you with an answer, the ticket moves to “Closed” status. A comment is added providing you with all necessary information.
- If the answer does not fully meet your expectations, you have the ability to reopen it, which moves the issue to “In progress” status.
- If the ticket requires a planned operation in order to be solved (e.g. upgrade, planned restart), it will move to “Operation planned” status, letting you know in a comment when the operation will take place and who will be responsible for it.
- If the ticket is identified as a consulting task, it will be closed with resolution “Consulting”.
SLA
- Response SLA is measured from the “Submitted” status to the “Operation planned”, “Waiting for customer”, “Resolved” or “Closed” status
- Response SLA only counts the first hit of the “Operation planned”/”Waiting for customer”/”Resolved”/”Closed” status – this means that if an issue is reopened or gets back to “In progress” status, the SLA does not restart.
- Response SLA is paused on the following status: “Waiting for third party”.
- Response SLA mesured according to the coverage selected for the support contract: during business hours for clients who chose business hours coverage and 24/7 for clients who chose 24/7 coverage.
Notifications
- After ticket creation, the creator receives an email notification.
- At any moment, the creator is able to reply to this notification in order to add a comment to the ticket.
- The creator receives an email notification as soon as the ticket enters “In progress” status, meaning the issue has been taken into account.
- The creator receives an email notification when the ticket enters “Waiting for customer”, “Waiting for third party” or “Operation planned” status.
- Our support team receives a notification when the issues is reopened from “Waiting for customer” or “Closed” status.
- The creator receives an email notification when the ticket enters “Closed” status.
- The creator receives an email notification each time the ticket is commented by our support team.
Automations
- Tickets that have “Waiting for customer” status and have not been modified for 3 and 6 days are automatically commented, which sends a notification to the creator.
- Tickets with “Waiting for customer” status that have not been modified for a period of 12 days are closed automatically, but you are able to reopen them if required.
Escalation
- At any point in time, you have the ability to escalate the issue. Escalating the issue sends a notification to the Support Team lead and the Head of Managed Services so that they can review the ticket and take action if necessary.
- We recommend using this escalation button if
- You are not getting the required level of expertise for dealing with an issue
- You are not getting appropriate response time after you provided all information for the support agent to work on your ticket
- If you have a very urgent issue, we recommend you to call us directly rather than escalating the issue (as a reminder, our phone numbers can be found here: Raise a support request)
Periodic access rights review
Every month, a check is done on all applications used at the managed services level to check that access is granted only to authorized personnel.
A report is created and shared with the Managed services team manager. In case of erroneous access rights, immediate action is taken for fixing the issue by creating a security incident if necessary.
Security incident management
Our security incident process is covered through our incident response plan.
STEP 1 – Discovery & Categorization
Anyone who discovers the incident will contact Valiantys Support team by creating a Security Incident in the dedicated Jira Service Desk instance:
- Name of caller or source of incident alert (AWS or Software notifications) – ex: Email from Atlassian or ticket created by a customer on Valiantys Support portal
- Time of first report
- Nature of the incident – ex: Vulnerability on an Atlassian product
- What system(s) or persons were involved? – ex: impacted Atlassian applications (i.e. versions affected by the vulnerablilty)
- Location of equipment or persons involved – ex: Valiantys Cloud infrastructure
- How incident was detected – ex: Pen tests executed by a customer on their applications
All logs information from the server must be copied to the ticket for future investigation.
STEP 2 – Escalation & Exploration
Depending on the type of the Security Incident, the created ticket is assigned to the Support or Cloud Offerings Manager. The designated assignee:
- Reviews the contents of the ticket
- Assess the list of impacted environments. Those environments must be backed up (unless there is already a recent backup available) in order to protect the information for identification, collection, acquisition and preservation, which can serve as evidence
- Based on that assessment, the assignee decides the type of remediation to be applied so that the Incident is solved as quickly and efficiently as possible. Depending on the cases, the type of remediation will be:
-
- Deployment of a workaround, if any
- System or applicative upgrade – ex: OS, Apache, PostgreSQL, Atlassian tool or app
- Migration to a new environment
For each environment impacted by the Incident, and based on the Change Management process, Change tickets are created in the dedicated Jira project, with the following information:
Change Management process
- Description – ex: Jira uprgade to 8.5.3 on MyCustomer PROD instance
- Priority – ex: Critical
- Origin – ex: Notification from Atlassian
- Reason for Change – ex: Security vulnerability on Jira version currently installed
- Risk analysis – ex:
- Same parameters in setenv.sh and server.xml configuration files
- Compatibility of installed apps – upgrade the impacted ones if needed
- Apps requiring paid license – client must be informed as well as the account manager
- No unforeseen security risk, as the data is not transferred anywhere
- Change procedure – ex: <link_to_the_corresponding_internal_documentation>
- Rollback procedure – ex: Restore of the snapshot generated before the operation
- Estimated duration – ex: 1h
- Link to the related Support ticket – Automatically defined by the Jira app creating the Change ticket
Security breach definition
A security breach is defined as unauthorized acquisition of data that compromises the security, confidentiality or integrity of personal information maintained by Valiantys.
Good faith acquisition of personal information by an employee or agent of our company for business purposes is not a breach, provided that the personal information is not used or subject to further unauthorized disclosure.
Incident alert caller
Following are some examples of values to be indicated in the Origin field of the Change ticket:
- Customer
- Atlassian consultant for a customer
- Third party such as CVE database
- Valiantys
- Atlassian
- Unknown
Nature
Following are some examples of values to be indicated in the Reason for Change field of the Change ticket:
- Breach of personal information
- Denial of service/Distributed denial of service
- Excessive port scan
- Firewall breach
- Virus outbreak
- Exploitation of server resources
Classification / Criticality
Following are some examples of values to be indicated in the Priority field of the Change ticket:
CRITICAL
- Definition: Incidents that have a critical impact on the firm’s business or the service to Valiantys MS customers
- Example: Unauthorized system access
MEDIUM
- Definition: Incidents that has a significant or has the potential to have a critical impact on the firm’s business or the service to Valiantys MS customers
- Example: Password cracking attempt
LOW
- Definitions: Incidents that has the potential to have a significant or critical impact on the firm’s business or the service to Valiantys MS customers
- Example: Firewall scanning
STEP 3 – Remediation
Each concerned System is scanned for the open vulnerability before application of the remediation.
The Security incident is fixed via the application of the Change procedure – provided in a dedicated field of the Change ticket.
After validation of the corrective action, the concerned Systems are scanned again to verify that the vulnerability has been eliminated.
STEP 4 – Communication
- Valiantys MS is committed to ensure correct communication to customers or partners that could be impacted with the Security issue within a delay of maximum 24 hours, by sending an email (or creating a support ticket on behalf of the client) to all the concerned customers including the following information:
- Detail of the vulnerability (CVE number if available)
- How the vulnerability impacts their environment
- Description of the remediation plan
- Description of the communication plan
- Details of the investigation if the vulnerability was exploited already
- Valiantys Managed Services Management must be involved in the process as early as possible from the escalation step, and depending on the severity and the scope of the impacted environments:
- Valiantys Head of managed services must be involved for any security incident of Critical criticality
- Valiantys CTO must be involved if the scope of the Security Incident is Valiantys Cloud infrastructure and the criticality Critical.
- Valiantys CISO must be involved if the scope of the Security Incident is Valiantys infrastructure and the criticality Critical.
- Valiantys CEO must be involved if the Security Incident commits Valiantys from a legal or financial point of view and the criticality Critical.
STEP 5 – Post-mortem review of the response and update policies
In order to take preventive steps so the incident doesn’t happen again, we asked ourselves several questions:
- Would an additional policy have prevented the incident?
- Has a procedure or policy not been followed which allowed the incident? What could be changed to ensure that the procedure or policy is followed in the future?
- Was the incident response appropriate? How could it be improved?
- Was every appropriate party informed in a timely manner?
- Were the incident-response procedures detailed and did they cover the entire situation? How can they be improved?
- Have changes been made to prevent another incident? Have all systems been patched, systems locked down, passwords changed, anti-virus updated, email policies set, etc.?
- Should any security policies be updated?
- What lessons have been learned from this experience?
This discussion can take place in the weekly Change committee including at least the Head Of Managed Services, the Support Offerings and Cloud Offerings Managers, and the Support Team Leaders.
Periodic Testing
Valiantys Managed Services team has the responsibility to test and review the Security Incident Response Plan on a quarterly basis, at the following periods:
- Mid-March
- Mid-June
- Mid-September
- Mid-December
Disaster recovery
All our virtual servers (except Valiantys Cloud Starter offerings) are backed up every night. The backup is stored in the same region than the servers. For disaster recovery purposes, all snapshots are automatically copied to another region.
In case of an important failure on the main region, we are able to restart the service from the latest backup very quickly, limiting impact on the customers as much as possible:
Our recovery time objective and recovery point objectives are available at https://valiantys.com/en/legal/sla/
We test this process once every year on all our servers in order to be ready and efficient when the time comes.
Restauration de l'export XML :
- Nous copions l'export XML dans le dossier de restauration
- Nous démarrons le processus d'importation XML (peut prendre de quelques minutes à quelques heures en fonction de la taille de votre environnement)
Vérification de la procédure de restauration
Afin de nous assurer que nos sauvegardes et nos procédures de sauvegarde fonctionnent comme prévu, nous effectuons un test de restauration pour tous nos serveurs une fois par an.
Un rapport des résultats peut être fourni au client sur demande.
Pen tests
Nous effectuons des tests de pénétration au moins une fois par an sur tous nos serveurs.
Au moins une fois par an, nous effectuons des tests de pénétration en boîte blanche sur un environnement de type "bac à sable" que nous créons à l'aide du processus d'installation standard que nous utilisons pour créer l'environnement du client. Cela nous permet d'améliorer continuellement notre sécurité.
Nous permettons également à nos clients d'effectuer leurs propres tests de pénétration (par eux-mêmes ou par l'intermédiaire d'un tiers).
Si un client souhaite organiser des tests de pénétration, il doit nous contacter au moins 4 semaines à l'avance, car nous devons obtenir l'approbation de nos fournisseurs.
Gestion de la vulnérabilité
Processus de détection
Nous effectuons une revue hebdomadaire de notre base de référence à l'aide d'outils spécialisés en plus des alertes fournies par Atlassian.
Temps de détection
La période de détection est de 7 jours (sauf notification d'Atlassian pendant cette période).
Délais de traitement
Le traitement est immédiat. Dès que la vulnérabilité est connue, un ticket d'incident est automatiquement créé au nom du client, afin d'organiser la remédiation avec son accord et afin d'impacter au moins le service de production.
Sans réponse du client dans les 7 jours, la vulnérabilité sera automatiquement traitée sans attendre l'accord sur les créneaux non travaillés.
Opérations
Organisation de la sécurité
La personne responsable de la sécurité au sein de l'entreprise est actuellement Nathan Chantrenne, CTO.
Nous n'avons pas d'équipe dédiée à la sécurité. Tous les membres de notre équipe d'infogérance connaissent les règles de sécurité appliquées chez Valiantys et sont capables de gérer les incidents de sécurité.
Une politique de sécurité d'entreprise est en place et fait partie de nos règles et règlements d'entreprise qui doivent être acceptés par tous les membres de Valiantys. Elle comprend les sections suivantes :
Organisation de la politique de sécurité de l'information
- INTRODUCTION
- Objectif
- Champ d'application
- Histoire
- Responsabilités
- Définition de la politique générale
- Glossaire
- POLITIQUE D'ACCÈS AU RÉSEAU
- Objectif de la politique d'accès au réseau
- Champ d'application
- Définition de la politique
- POLITIQUE EN MATIÈRE DE DONNÉES, D'INFORMATIONS ET DE SÉCURITÉ
- Utilisation générale et propriété
- Sécurité et informations exclusives
- Utilisation inacceptable
- CONFORMITÉ DE LA POLITIQUE
- Mesure de la conformité
- Exceptions
- Non-conformité
- POLITIQUE EN MATIÈRE D'ACTIFS INFORMATIQUES
- Objet de la politique
- Champ d'application
- Définition de la politique
- POLITIQUE DE CONTRÔLE D'ACCÈS
- Objectif
- Champ d'application
- Définition de la politique
- POLITIQUE DE CONTRÔLE DES MOTS DE PASSE
- Objectif
- Champ d'application
- Définition de la politique
- Énoncé des lignes directrices
- POLITIQUE EN MATIÈRE DE COURRIEL
- Objectif
- Champ d'application
- Définition de la politique
- POLITIQUE INTERNET
- Objectif
- Champ d'application
- Définition de la politique
- POLITIQUE ANTIVIRUS
- Objectif
- Champ d'application
- Définition de la politique
- POLITIQUE DE CLASSIFICATION DES INFORMATIONS
- Objectif
- Champ d'application
- Définition de la politique
- POLITIQUE D'ACCÈS À DISTANCE
- Objectif
- Champ d'application
- Définition de la politique
- POLITIQUE D'EXTERNALISATION
- Objectif
- Champ d'application
- Définition de la politique
- Obligatoire
- POLITIQUE DE GESTION DES CORRECTIFS
- Objectif de la politique de gestion des correctifs
- Champ d'application
- Définition de la politique
- POLITIQUE D'INFORMATION SUR LES APPLICATIONS EN NUAGE
- Objectif
- Champ d'application
- Définition de la politique
Avant d'embaucher de nouveaux employés, nous vérifions leurs antécédents en fonction du pays où ils sont recrutés :
- Une déclaration de culpabilité de base
- Analyse des antécédents professionnels et des lacunes
- Vérification de la carte d'identité
- Vérification du droit au travail
Processus de gestion des changements
Soumission des changements
Lorsque, dans un ticket d'assistance, un changement est demandé par un client ou identifié par l'ingénieur d'assistance, une transition de flux de travail permet d'atteindre un statut spécifique. À partir de ce statut, il sera possible de créer une fiche de modification dans le projet Jira dédié via un bouton spécifique. La fiche de modification créée comprend les informations suivantes
- Description - ex :Jira uprgade to 8.5.3 on MyCustomer PROD instance
- Priorité - ex :Critique
- Origine - ex :Notification d'Atlassian
- Raison du changement - ex :Vulnérabilité de sécurité sur la version de Jira actuellement installée
- Analyse de risque - ex :
- Mêmes paramètres dans les fichiers de configuration setenv.sh et server.xml
- Compatibilité des applications installées - mettre à jour les applications concernées si nécessaire
- Applications nécessitant une licence payante - le client doit être informé ainsi que le gestionnaire de compte
- Pas de risque de sécurité imprévu, les données n'étant transférées nulle part.
- Procédure de changement - ex :<link_to_the_corresponding_internal_documentation> (lien vers la documentation interne correspondante)
- Procédure de retour en arrière - ex :Restauration de l'instantané généré avant l'opération
- Durée estimée - ex : 1h
- Lien vers le ticket de support correspondant - Automatiquement défini par l'application Jira créant le ticket de changement
Approbation du changement
Après sa création et en fonction du type de changement attendu, la fiche de changement est attribuée à un chef d'équipe de support ou à un architecte du cloud. L'assigné désigné examine les informations fournies par le rapporteur et décide d'approuver ou de rejeter la demande de changement.
Il existe des raisons de refuser un changement : risque technique, risque de sécurité, procédure peu claire ou incomplète, etc. Si le changement est refusé, le ticket de changement est fermé et le flux de travail du ticket de support associé est automatiquement ramené à son statut précédent.
Si le changement est approuvé, un formulaire permet de planifier l'opération correspondante via les champs suivants :
- Date de début - c'est-à-dire la date et l'heure auxquelles l'opération de changement commencera.
- Date de fin - c'est-à-dire la date et l'heure auxquelles l'opération de changement prendra fin.
- Destinataire - c'est-à-dire la ressource en charge de l'exécution de cette opération.
En conséquence, le ticket de changement est mis à jour avec ces informations et le flux de travail du ticket de support associé est automatiquement mis dans un nouveau statut indiquant qu'une opération corrective est planifiée.
Application du changement
Une fois que le changement a été appliqué, la ressource chargée de l'opération met à jour le statut du flux de travail du ticket de changement, ce qui déclenche automatiquement une mise à jour du flux de travail du ticket d'assistance connexe, de sorte que le traitement de ce ticket reprend.
Changement d'urgence
En cas de problèmes urgents - ex : problème de blocage soulevé par un client ou vulnérabilité de sécurité soulevée par Atlassian ayant un impact sur certaines versions d'application, un processus de changement d'urgence est appliqué, avec les déviations suivantes par rapport au processus régulier :
- Un chef d'équipe de support ou un architecte du cloud traite le ticket de support correspondant, crée et approuve le ticket de changement correspondant.
- Le changement est planifié dans le délai le plus court possible, en fonction de la disponibilité des ressources de support et de l'accord du client.
Comité des changements
Tous les lundis après-midi, uncomité de changementde 30 minutes comprenant au moins le responsable des services d'infogérance, les responsables des offres de support et des offres cloud, et les chefs d'équipe de support, passe en revue les tickets de changement traités au cours de la période écoulée à l'aide d'un tableau de bord Jira dédié.
Processus de gestion des incidents
Les incidents sont créés par les clients par le biais d'e-mails, de notre portail de support ou par l'équipe de Valiantys Managed Services.
Un incident peut être déclaré comme étant de gravité 1, 2, 3 ou 4. La définition de nos niveaux de gravité peut être consultée sur https://valiantys.com/en/legal/sla/.
Notre équipe Managed Services traite les tickets dans l'ordre de priorité suivant :
- Service down (les incidents sont automatiquement créés à partir de notre outil de monitoring) - avec un objectif de temps de rétablissement de 30 minutes
- Incidents de sécurité
- Incidents S1
- Tickets de non-respect de l'accord de niveau de service
- Tous les autres tickets classés par SLA
Voici le workflow des incidents.
Flux de travail
- Lorsque le ticket est créé, il arrive avec le statut "Soumis".
- Dès que notre équipe commence à travailler dessus, le ticket passe au statut "En cours".
- Si nous avons besoin de plus d'informations de votre part, le ticket passe au statut "En attente du client", et un commentaire est ajouté au ticket détaillant les informations dont nous avons besoin pour résoudre le problème.
- Si nous avons besoin de l'aide d'un tiers pour résoudre le problème, le ticket passe au statut "En attente d'un client". Les tiers peuvent être Atlassian, un fournisseur de modules complémentaires ou un hébergeur.
- Lorsque nous vous fournissons une réponse, le ticket passe au statut "Fermé". Un commentaire est ajouté pour vous fournir toutes les informations nécessaires.
- Si la réponse ne répond pas entièrement à vos attentes, vous avez la possibilité de le rouvrir, ce qui fait passer le problème au statut "En cours".
- Si le ticket nécessite une opération planifiée pour être résolu (par exemple, une mise à niveau, un redémarrage planifié), il passera au statut "Opération planifiée", vous indiquant dans un commentaire quand l'opération aura lieu et qui en sera responsable.
- Si le ticket est identifié comme une tâche de conseil, il sera fermé avec la résolution "Conseil".
SLA
- L'ANS de réponse est mesuré à partir du statut "Soumis" jusqu'au statut "Opération planifiée", "En attente du client", "Résolu" ou "Fermé".
- L'ANS de réponse ne compte que la première occurrence du statut "Opération planifiée"/"En attente du client"/"Résolu"/"Clôturé" - cela signifie que si un problème est rouvert ou revient au statut "En cours", l'ANS ne redémarre pas.
- L'ANS de réponse est mis en pause avec le statut suivant : "En attente d'un tiers".
- L'ANS de réponse est mesuré en fonction de la couverture sélectionnée pour le contrat d'assistance : pendant les heures ouvrables pour les clients qui ont choisi la couverture des heures ouvrables et 24 heures sur 24, 7 jours sur 7 pour les clients qui ont choisi la couverture 24 heures sur 24, 7 jours sur 7.
Notifications
- Après la création d'un ticket, le créateur reçoit une notification par courriel.
- À tout moment, le créateur peut répondre à cette notification afin d'ajouter un commentaire au ticket.
- Le créateur reçoit une notification par courriel dès que le ticket passe au statut "En cours", ce qui signifie que le problème a été pris en compte.
- Le créateur reçoit une notification par courriel lorsque le ticket passe au statut "En attente du client", "En attente d'un tiers" ou "Opération planifiée".
- Notre équipe d'assistance reçoit une notification lorsque le problème est rouvert depuis le statut "En attente du client" ou "Fermé".
- Le créateur reçoit une notification par courriel lorsque le ticket passe au statut "Fermé".
- Le créateur reçoit une notification par email chaque fois que le ticket est commenté par notre équipe de support.
Automatisations
- Les tickets qui ont le statut "En attente d'un client" et qui n'ont pas été modifiés depuis 3 et 6 jours sont automatiquement commentés, ce qui envoie une notification au créateur.
- Les tickets ayant le statut "En attente d'un client" et qui n'ont pas été modifiés pendant une période de 12 jours sont fermés automatiquement, mais vous pouvez les rouvrir si nécessaire.
Escalade
- À tout moment, vous avez la possibilité d'escalader le problème. L'escalade du problème envoie une notification au chef de l'équipe d'assistance et au responsable des services gérés afin qu'ils puissent examiner le ticket et prendre des mesures si nécessaire.
- Nous vous recommandons d'utiliser ce bouton d'escalade si
- Vous n'obtenez pas le niveau d'expertise requis pour traiter un problème.
- Vous n'obtenez pas le temps de réponse approprié après avoir fourni toutes les informations nécessaires à l'agent d'assistance pour travailler sur votre ticket.
- Si vous avez un problème très urgent, nous vous recommandons de nous appeler directement plutôt que d'escalader le problème (pour rappel, nos numéros de téléphone se trouvent ici :Soumettre une demande d'assistance).
Révision périodique des droits d'accès
Chaque mois, un contrôle est effectué sur toutes les applications utilisées au niveau des services gérés afin de vérifier que l'accès n'est accordé qu'au personnel autorisé.
Un rapport est créé et partagé avec le responsable de l'équipe d'infogérance. En cas de droits d'accès erronés, une action immédiate est entreprise pour résoudre le problème en créant un incident de sécurité si nécessaire.
Gestion des incidents de sécurité
Notre processus de gestion des incidents de sécurité est couvert par notre plan de réponse aux incidents.
ÉTAPE 1 - Découverte et catégorisation
Toute personne découvrant l'incident contactera l'équipe de support de Valiantys en créant un incident de sécurité dans l'instance Jira Service Desk dédiée :
- Nom de l'appelant ou source de l'alerte d'incident (AWS ou notifications logicielles) - ex :Email d'Atlassian ou ticket créé par un client sur le portail de support de Valiantys
- Heure du premier rapport
- Nature de l'incident - ex :Vulnérabilité sur un produit Atlassian
- Quel(s) système(s) ou personne(s) est/sont impliqué(s) - ex :applications Atlassian impactées (i.e. versions affectées par la vulnérabilité)
- Emplacement de l'équipement ou des personnes concernées - ex :infrastructure Cloud de Valiantys
- Comment l'incident a été détecté - ex :Pen tests exécutés par un client sur ses applications
Toutes les informations de logs du serveur doivent être copiées dans le ticket pour une investigation future.
ÉTAPE 2 - Escalade et exploration
En fonction du type d'incident de sécurité, le ticket créé est assigné au Support ou au Cloud Offerings Manager. La personne désignée :
- Examine le contenu du ticket
- Évalue la liste des environnements touchés. Ces environnements doivent être sauvegardés (à moins qu'une sauvegarde récente ne soit déjà disponible) afin de protéger les informations pour l'identification, la collecte, l'acquisition et la préservation, qui peuvent servir de preuves.
- Sur la base de cette évaluation, l'assigné décide du type de remédiation à appliquer pour que l'incident soit résolu le plus rapidement et le plus efficacement possible. Selon les cas, le type de remédiation sera le suivant
-
- Déploiement d'une solution de contournement, le cas échéant
- Mise à niveau du système ou de l'application - ex : OS, Apache, PostgreSQL, outil ou application Atlassian
- Migration vers un nouvel environnement
Pour chaque environnement impacté par l'incident, et en fonction du processus degestion des changements, des tickets de changement sont créés dans le projet Jira dédié, avec les informations suivantes :
Processus de gestion des changements
- Description - ex :Jira uprgade to 8.5.3 on MyCustomer PROD instance
- Priorité - ex :Critique
- Origine - ex :Notification d'Atlassian
- Raison du changement - ex :Vulnérabilité de sécurité sur la version de Jira actuellement installée
- Analyse de risque - ex :
- Mêmes paramètres dans les fichiers de configuration setenv.sh et server.xml
- Compatibilité des applications installées - mettre à jour les applications concernées si nécessaire
- Applications nécessitant une licence payante - le client doit être informé ainsi que le gestionnaire de compte
- Pas de risque de sécurité imprévu, les données n'étant transférées nulle part.
- Procédure de changement - ex :<link_to_the_corresponding_internal_documentation> (lien vers la documentation interne correspondante)
- Procédure de retour en arrière - ex :Restauration de l'instantané généré avant l'opération
- Durée estimée - ex : 1h
- Lien vers le ticket de support correspondant - Automatiquement défini par l'application Jira créant le ticket de changement
Définition d'une faille de sécurité
Une faille de sécurité est définie comme l'acquisition non autorisée de données qui compromettent la sécurité, la confidentialité ou l'intégrité des informations personnelles conservées par Valiantys.
L'acquisition de bonne foi d'informations personnelles par un employé ou un agent de notre société à des fins professionnelles ne constitue pas une violation, à condition que les informations personnelles ne soient pas utilisées ou ne fassent pas l'objet d'une divulgation ultérieure non autorisée.
Appel d'alerte en cas d'incident
Voici quelques exemples de valeurs à indiquer dans le champOrigine du ticket de changement :
- Client
- Consultant Atlassian pour un client
- Tierce partie telle que la base de données CVE
- Valiantys
- Atlassian
- Inconnu
Nature
Voici quelques exemples de valeurs à indiquer dans le champMotif du changement du ticket de changement :
- Violation d'informations personnelles
- Déni de service/déni de service distribué
- Balayage excessif de ports
- Violation du pare-feu
- Foyer de virus
- Exploitation des ressources du serveur
Classification / Criticité
Voici quelques exemples de valeurs à indiquer dans le champPriorité du ticket de changement :
CRITIQUE
- Définition : Incidents ayant un impact critique sur l'activité de l'entreprise ou sur le service aux clients de Valiantys MS.
- Exemple : Accès non autorisé au système
MOYEN
- Définition : Incidents ayant un impact significatif ou susceptible d'avoir un impact critique sur les activités de l'entreprise ou sur le service fourni aux clients de l'EM de Valiantys.
- Exemple : Tentative de piratage de mot de passe
FAIBLE
- Définitions : Incidents susceptibles d'avoir un impact significatif ou critique sur les activités de l'entreprise ou sur le service offert aux clients de Valiantys MS.
- Exemple : Analyse du pare-feu
ÉTAPE 3 - Remédiation
Chaque système concerné est scanné pour détecter les vulnérabilités ouvertes avant l'application de la remédiation.
L'incident de sécurité est corrigé par l'application de la procédure de changement - fournie dans un champ dédié du ticket de changement.
Après validation de l'action corrective, les systèmes concernés sont à nouveau analysés pour vérifier que la vulnérabilité a été éliminée.
ÉTAPE 4 - Communication
- Valiantys MS s'engage à assurer une communication correcte aux clients ou partenaires qui pourraient être impactés par le problème de sécurité dans un délai maximum de 24 heures, en envoyant un email (ou en créant un ticket de support au nom du client) à tous les clients concernés en incluant les informations suivantes :
- Détail de la vulnérabilité (numéro CVE si disponible)
- L'impact de la vulnérabilité sur leur environnement
- Description du plan de remédiation
- Description du plan de communication
- Détails de l'enquête si la vulnérabilité a déjà été exploitée
- La direction de l'infogérance de Valiantys doit être impliquée dans le processus le plus tôt possible à partir de l'étape d'escalade, et en fonction de la gravité et de l'étendue des environnements impactés :
- Le responsable des services d'infogérance de Valiantys doit être impliqué pour tout incident de sécurité de niveau critique.
- Le CTO de Valiantys doit être impliqué si l'incident de sécurité concerne l'infrastructure Cloud de Valiantys et que la criticité est critique.
- Le CISO de Valiantys doit être impliqué si l'incident de sécurité concerne l'infrastructure de Valiantys et que la criticité est critique.
- Le CEO de Valiantys doit être impliqué si l'incident de sécurité engage Valiantys d'un point de vue légal ou financier et que la criticité est critique.
ÉTAPE 5 - Examen post-mortem de la réponse et mise à jour des politiques
Afin de prendre des mesures préventives pour que l'incident ne se reproduise pas, nous nous sommes posé plusieurs questions :
- Une politique supplémentaire aurait-elle permis d'éviter l'incident ?
- Le non-respect d'une procédure ou d'une politique a-t-il permis l'incident ? Que pourrait-on changer pour que la procédure ou la politique soit respectée à l'avenir ?
- La réponse à l'incident était-elle appropriée ? Comment pourrait-elle être améliorée ?
- Toutes les parties concernées ont-elles été informées en temps utile ?
- Les procédures de réponse à l'incident étaient-elles détaillées et couvraient-elles l'ensemble de la situation ? Comment peuvent-elles être améliorées ?
- Des changements ont-ils été apportés pour éviter un nouvel incident ? Tous les systèmes ont-ils été corrigés, verrouillés, les mots de passe ont-ils été changés, l'antivirus a-t-il été mis à jour, des politiques en matière de courrier électronique ont-elles été définies, etc.
- Les politiques de sécurité doivent-elles être mises à jour ?
- Quelles leçons ont été tirées de cette expérience ?
Cette discussion peut avoir lieu au sein ducomité de changementhebdomadaire, qui comprend au moins le responsable des services d'infogérance, les responsables des offres de support et des offres de cloud, ainsi que les chefs des équipes de support.
Tests périodiques
L'équipe d'infogérance de Valiantys a la responsabilité de tester et de revoir le plan de réponse aux incidents de sécurité sur une base trimestrielle, aux périodes suivantes :
- mi-mars
- mi-juin
- mi-septembre
- mi-décembre
Reprise après sinistre
Tous nos serveurs virtuels (à l'exception des offres Valiantys Cloud Starter) sont sauvegardés chaque nuit. La sauvegarde est stockée dans la même région que les serveurs. Pour la reprise après sinistre, tous les snapshots sont automatiquement copiés dans une autre région.
En cas de panne importante dans la région principale, nous sommes en mesure de redémarrer le service à partir de la dernière sauvegarde très rapidement, en limitant autant que possible l'impact sur les clients :
Notre objectif de temps de récupération et nos objectifs de points de récupération sont disponibles à l'adresse https://valiantys.com/en/legal/sla/.
Nous testons ce processus une fois par an sur tous nos serveurs afin d'être prêts et efficaces le moment venu.