WSO2 Managed Cloud Security Policy
WSO2 Managed Cloud is a hosted service offering for WSO2 products. It allows you to get a team of WSO2 product specialists to run your cloud for you. We can deploy, run, and maintain any WSO2 product or a combination of products for which you purchased production support.
WSO2 Managed Cloud subscription offers the following services:
- Managing Deployments: We provision infrastructure, deploy WSO2 products, and perform configuration management, monitoring, disaster recovery, migration, upgrade, and secure deployments.
- Providing Support: We provide JIRA-based support with different priority levels and defined SLAs.
WSO2 Managed Cloud follows security best practices when handling operations and ensures security of the deployments. The platform is designed to regularly apply security updates without the customer’s interaction and service interruptions.
WSO2’s Commitment to Trust
Each and every member of the WSO2 Managed Cloud team (MC team) is committed to trust, responsibility, and for protecting the customers’ privacy and the safety of data.
Reporting Security Vulnerabilities
WSO2’s security team welcomes contributions that reinforce security of our products from users, developers, and security researchers. We encourage you to first report security vulnerabilities in our private security mailing list, which is firstname.lastname@example.org, before disclosing them in public forums. This mailing list is treated as top priority.
We maintain ‘Security Researcher Hall of Fame’ to thank individuals who have discovered security vulnerabilities and worked with us to resolve them.
Please send deployment related security vulnerabilities, if any, to email@example.com
For more information, see https://wso2.com/security.
Data Center Security
Based on the customer’s preferences, the WSO2 MC team uses Amazon Web Services (AWS), Microsoft Azure, or GCP to deploy infrastructure. We also support on-premise deployments that contain WSO2 products.
|Cloud Vendor||Supporting Compliances||For More Info|
|AWS||ISO 27001, SOC 1 and SOC 2/SSAE 16/ISAE 3402 (Previously SAS 70 Type II), PCI Level 1, FISMA Moderate and Sarbanes Oxley (SOX), GDPR||https://aws.amazon.com/compliance/|
|Azure||General Data Protection Regulation (GDPR), ISO 27001, HIPAA, FedRAMP, SOC 1 and SOC 2, as well as country-specific standards, including Australia IRAP, UK G-Cloud, and Singapore MTCS.||https://azure.microsoft.com/en-us/overview/trusted-cloud/|
|Google Cloud||ISO27001, ISO27017, ISO27018, SOC1,SOC2,SOC3,HIPAA,GDPR,FISMA||https://cloud.google.com/security/compliance|
|On-Premise||Compliances that are supported by customer datacenter|
|Category||Component||Description||Applied Cloud Vendor/Groups|
|Control traffic flow||Network Access Control List (NACL)- firewall rules||Whitelist and blacklist traffic coming/going from/to IPs or CIDR block for subnets.||AWS, Azure|
|Security groups - firewall rules||Whitelist traffic coming in/going out from/to IPs, CIDR blocks or security groups for VMs.||AWS|
|Host OS firewall rules (IPTABLES,UFW etc.)||Whitelist and blacklist traffic coming/going from/to IPs or CIDR block.||Not applied by default. Can be applied based on requirement.|
|Transition traffic||HTTPS (SSL/TLS)||Enabled on load balancers to offload SSL and databases (optional).||All|
|Data at rest||Block volume stores||Encryption is enabled.||AWS|
|Objects/file stores||Encryption is enabled.||AWS|
|Deployment Access||SSH||SSH via public and private keys.||For all WSO2 Managed Cloud team members and customers, upon request.|
|Management Console of Products/cloud vendor accounts||Enabled MFA, separate IAM users with minimum permissions, Okta logins etc.||For all WSO2 Managed Cloud team members and customers, upon request.|
|Private connections (VPNs)||Links to customer data center and cloud deployments||VPNs- IPSec, AWS direct connect etc.||AWS, Azure|
|Operating system||Patch and update OS||Linux - Ubuntu, CentOS, Amazon Linux, and Redhat.||AWS, Azure|
|Products||Security updates||Applying patches and WUM updates on servers.|
We manage documentation about the customers’ deployments in an internal site that is only accessible by the WSO2 MC team.
Access Credential Security
- All MC team members have their own usernames, passwords, and managed private keys.
- The WSO2 MC team uses only encrypted laptops that are given by WSO2 to manage customers’ cloud operations.
Penetration Testing and Vulnerability Assessments
WSO2 has a dedicated, in-house security team to guarantee the security of all WSO2 products. The team conducts penetration tests and issues vulnerability assessments that different WSO2 product teams immediately act upon to take preventive actions.
Customers are responsible for performing penetration tests on their Managed Cloud deployments. However, the WSO2 Security team is available to perform these tests for them upon request.
Environmental and Network Security
Datacenter safeguards and network security are specific to the cloud vendor. Each cloud vendor maintains their own best practices as well as global standards.
The customers manage all applications and artifacts in their managed cloud deployments and are responsible for the source code of JARs and other artifacts. The WSO2 MC team can deploy artifacts provided by customers in their managed cloud setups.
WSO2 Managed Cloud provides an additional security layer by enabling the data encryption capabilities of the cloud vendor, such as encrypting data at rest and in transit.
WSO2 Products are GDPR compliant. We do not have to access or store customer data in order to provide managed cloud services. In instances such as troubleshooting, WSO2 might access customer data upon request and permission by the customer.
Based on the deployment architecture and business requirements, some services might route sensitive customer data, but that will happen within the customer’s internal network, ensuring data security and compliance.
The WSO2 MC team deploys systems on OS images that are up-to-date with configuration changes and security updates. Existing systems get decommissioned as they get replaced with up-to-date systems.
Only the WSO2 MC team has access to the operating systems and such access requires username and key-based authentication. We do not allow password authentication due to the risk of brute force attacks, theft, and sharing. Also, we do not allow public SSH. Instead, we use hardened bastion servers (jump boxes) that are only accessible through the WSO2 network.
Diagram 1 - Remote SSH access to the customer’s setup from the WSO2 corporate network
The WSO2 MC team has privileged access to the customer’s infrastructure (e.g., AWS, Azure, Gcloud). The WSO2 support team gets read-only access to logs and dashboards.
Note the following:
- IAM users and roles are attached with specific policies for log publishing and clustering.
- Multi factor authentication (MFA) is enabled for platform logins.
- Applications (WSO2 services) are running on low-privileged users.
- In AWS, CloudTrail is used to track down events from the IAAS platform for auditing.
WSO2’s security vulnerability management process is designed to remediate risks without the customer’s interaction. We get notified of vulnerabilities through internal and external assessments, system patch monitoring, and through the firstname.lastname@example.org email group. We review each vulnerability to determine if it is applicable to our environment, rank it based on risk, and assigns it to the appropriate team for resolution.
WSO2 deploys new systems with the latest updates, security fixes, and WSO2 configurations. Existing systems get decommissioned as customers are migrated to the new instances. This process allows WSO2 to keep the deployment environment up-to-date.
The WSO2 MC team installs security updates for the operating system daily. We release application security updates monthly and apply those updates within a week after release. For production environments, we apply the updates through a pre-scheduled maintenance window. We give prior notice before applying security updates and ensure that the security updates do not affect any OS and system updates.
WSO2 Application Security
WSO2 applications undergo penetration and vulnerability tests and source code reviews. Our security assessments cover all areas of all platforms including testing for OWASP top 10 web application vulnerabilities and customer application isolation.
Customer Applications, Configurations, and Meta Information
The WSO2 MC team takes backups of deployment components that are business critical such as:
- Block store volumes of nodes. See AWS and Azure.
- Database backups (snapshots)
- Artifact backups
- Configuration management scripts
- Userstore backups (LDAP)
Accessing Logs and Alerts
Centralized Logging System
The WSO2 MC team maintains a cloud-specific, centralized log management tool for all managed cloud customers. We direct all WSO2 product specific logs and syslogs to this centralized log system. The MC team gets read/write access to the log system whereas the WSO2 support team and customers get read-only access.
Following are the log management tools of each cloud vendor:
- AWS Cloudwatch - For AWS based deployment
- Log Analytics - For Azure based deployment
- Icinga - For any deployment despite of the IAAS platform
The WSO2 MC team uses the PagerDuty third-party service for receiving alerts over the phone for service disruptions. Services can only be accessed via WSO2 MC team member profiles. SMSs and voice calls are generated only for pre-configured MC member mobile numbers.
Customer Data Retention and Destruction
WSO2 maintains the database’s storage volume for one week only. In case a disaster occurs during this period, we recover the customer’s data. After this period, data storage volumes are automatically destroyed, and it will not be possible to recover data any further.
The infrastructure provider decomissions hardware using a process that is designed to avoid exposing customer data.
To destroy data, FAWS uses techniques outlined in National Industrial Security Program Operating Manual (DoD 5220.22M) or Guidelines for Media Sanitization (NIST 80088).
For more information on AWS and Azure, see https://aws.amazon.com/security and https://docs.microsoft.com/en-us/azure/security/azure-security.
For more information, see https://wso2.com/privacypolicy.
Access to Customer Data
The WSO2 MC team accesses customer data or applications only at the request of the customer or when required by the law. Access is accompanied by the customer’s approval or government mandate, specifying the reason for access, actions taken by the MC team on the data, and duration of access (e.g., support start and end time).
Employee Screening and Policies
As a condition of employment, all WSO2 employees agree to company policies, including security and acceptable use policies.
WSO2 Security Team
The WSO2 security team is lead by the Director (Security Architect) at WSO2 and includes staff responsible for application and information security. The security team works closely with the entire organization and customers to address risks and continue WSO2’s commitment to trust.
Customer Security Best Practices
Encrypt Data in Transit
WSO2 uses HTTPS to transmit data to and from the Managed Cloud deployment components.
We also recommend that all WSO2 Managed Cloud customers enable and use HTTPS for applications and SSL database connections to protect sensitive data transmitted to and from applications.
Follow these guidelines to prevent unauthorized account access:
- Use a strong passphrase for both your WSO2 user account and SSH keys.
- Store SSH keys securely to prevent disclosure.
- Replace keys if lost or disclosed.
- Use WSO2’s user management model to invite contributors rather than sharing user accounts.
We maintain application and systems logs in a secure manner. Logs are retained for 90 days within the log management tool. The retention duration can be changed depending on requirements.