New CVE's - Security Bulletin (#1510)

* New CVE's - Security Bulletin

* docs: order and language fixes

* docs: bulleting lanaguage fixed

* docs: DOC-859 security update

* docs: made titles unique

* docs: title fix

* chore: refactor code base

---------

Co-authored-by: Karl Cardenas <karl@spectrocloud.com>

docs/docs-content/security/_category_.json

@@ -0,0 +1,3 @@
+{
+  "position": 140
+}

docs/docs-content/security/core-principles.md

@@ -0,0 +1,101 @@
+---
+sidebar_label: "Core Principles"
+title: "Core Principles"
+description: "Learn about Spectro Cloud security principles for Palette."
+icon: ""
+hide_table_of_contents: false
+sidebar_position: 0
+tags: ["security"]
+---
+
+
+
+Security is about controlling who can interact with your information, what they can do with it, and when they can interact with it.
+
+We use the Confidentiality, Integrity, and Availability (CIA) Triad as the framework that guides the security and controls we provide in our products and services. This framework is often extended with Authentication, Authorization, and Auditing. Components of the CIA Triad are described below.
+<br />
+
+- **Confidentiality**: Preserve authorized restrictions on information access and disclosure to protect personal privacy and proprietary data. This includes confirming identity and access rights to resources. 
+
+
+- **Integrity**: Protect data against unauthorized modification - either accidental or deliberate.
+
+
+- **Availability**: Protect the services that provide data access.
+
+
+- **Authorization**: Apply access rights through privileges or access levels to secure resources such as data, services, files, applications, and more.
+
+
+- **Authentication**: Confirm the identity of the entity that wants access to a secure system.
+
+
+- **Auditing**: Track implementation-level and domain-level events to ensure certain actions have been performed in the product. 
+
+
+# Core Principles
+
+Our security philosophy is grounded in the following core principles that we apply to our decision-making and product.
+
+<br />
+
+## Secure by Design
+
+Your data security is a core business requirement, not just a technical feature. We apply this principle during the design phase of our product feature development lifecycle to dramatically reduce the number of exploitable flaws and prevent them from being introduced in a release.
+
+<br />
+
+## Secure by Default
+
+We believe that security should be the default setting for all of our systems and software. Our products are secure to use out-of-the-box with little or no configuration needed and at no additional cost – such as audit logs and access control for sensitive information. Palette also supports Multi-Factor authentication (MFA) using external Identify Providers (IDP), such as Okta. 
+
+<br />
+
+## Never Rely Just on Obscurity
+
+We believe that using security through obscurity by itself is the absence of a security strategy. While some organizations use this method as their main security method, it puts their network at risk if an attacker gains access to obscure resources. 
+
+Determined attackers use various methods to discover the hidden details of a system, and discovery eventually happens - either accidentally or deliberately. We believe that while obscurity alone is not a robust security strategy, it can be layered with security policies and controls. This is the principle of Defense in Depth.
+
+<br />
+
+## Defense in Depth
+
+We believe security should be layered and redundant with multiple defenses in place to protect against different types of attack. The intent is to provide redundancy in the event a security control fails or a vulnerability is exploited.
+
+<br />
+
+## Least Privilege
+
+This principle encourages system designers and implementers to allow runtime code with only the permissions needed to complete the required tasks and no more. 
+
+We use the principle of least privilege to ensure that all users have only the necessary access rights to fulfill their job roles. To ensure the security of our users and systems, we use mechanisms such as defined access rights, regular reviews, restricted privileges, and system monitoring.
+
+<br />
+
+## Secrets Handling
+
+We use the following methods for secrets handling, which contribute to a robust and resilient security infrastructure.
+
+<br />
+
+- Secure password manager. 
+
+
+- Dynamic secret retrieval, which automates the secret rotation process to reduce the risk of unauthorized access and limit sensitive data exposure.
+
+
+- MFA and Single Sign-On (SSO).
+
+
+
+## Continuous Improvement
+
+We believe security is an ongoing process, and we are committed to constantly improving our security posture through regular assessment and testing.
+
+We review and audit our internal setup regularly to ensure our employees have access to the tools they need while maintaining strong security standards.
+
+<br />
+
+<br />
+

docs/docs-content/security/lifecycle/_category_.json

@@ -0,0 +1,3 @@
+{
+  "position": 10
+}

docs/docs-content/security/lifecycle/lifecycle.md

@@ -0,0 +1,38 @@
+---
+sidebar_label: "Lifecycle"
+title: "Spectro Cloud Secure Development Lifecycle"
+description: "Learn how Spectro Cloud applies security throughout its development lifecycle."
+icon: ""
+hide_table_of_contents: false
+
+---
+
+
+
+
+Our comprehensive approach to security is ingrained in each stage of our development lifecycle. From initial design and coding to testing and deployment, our processes are designed to identify, prevent, and mitigate security risks to ensure we deliver reliable and secure solutions. 
+
+![Secure development flow from feature definition and design to development and release](/security_dev_lifecycle.png)
+
+Our Security team reviews early in the design process and identifies real and potential issues, which are logged in a ticketing system. Throughout development and before release we conduct more reviews and automated scans for common vulnerabilities. Scans go beyond our own code to include third-party libraries and container images. Should any vulnerabilities be found, we block the release and apply remediations. Our Security team must approve all our releases.
+
+
+
+## Resources
+
+- [Secure Development](/security/lifecycle/secure-development)
+
+
+- [Release Process](/security/lifecycle/release-process)
+
+
+<br />
+
+
+<br />
+
+
+<br />
+
+
+<br />

docs/docs-content/security/lifecycle/release-process.md

@@ -0,0 +1,53 @@
+---
+sidebar_label: "Release Process"
+title: "Release Process"
+description: "Learn about Spectro Cloud's release process for Palette."
+icon: ""
+hide_table_of_contents: false
+sidebar_position: 10
+---
+
+
+
+
+
+# Release Process
+
+We use semantic versioning for releases, where release versions follow the *Major.Minor.Patch* numbering pattern across all components, and we utilize and maintain *Integration*, *Stage*, and *Production* environments.
+
+<br />
+
+## Checklist
+
+Our release process includes a checklist of the features planned for release to ensure their completion or to ensure a completion plan is in place. 
+
+When all pre-deployment checklist items are complete, stakeholders review the checklist to make an informed decision about the state of the release and do the following: 
+
+<br />
+
+- Identify any steps that have not been completed.
+
+
+- Request additional information.
+
+
+- Follow up as needed. 
+
+
+## Signoff
+
+A new version deployment will not proceed until all stakeholders have signed off.
+
+<br />
+
+## Backup
+
+We back up the current release before starting a new one. Should a rollback be required and patching is not an option, a rollback request is submitted to the Spectro Cloud DevOps team. The DevOps team will restore from the backup and revert the production SaaS instance to the prior version.
+
+<br />
+
+<br />
+
+<br />
+
+<br />

docs/docs-content/security/lifecycle/secure-development.md

@@ -0,0 +1,29 @@
+---
+sidebar_label: "Secure Development"
+title: "Secure Development"
+description: "Learn about Spectro Cloud's secure product development."
+icon: ""
+hide_table_of_contents: false
+sidebar_position: 0
+---
+
+
+
+
+
+# Secure Development
+
+Our proactive *shift left*  approach to making security an integral part of our development process ensures we detect and address vulnerabilities and design flaws early in the development cycle. By integrating security measures into the development process, we improve our software quality and reduce vulnerabilities while minimizing manual intervention and potential human error. 
+
+We integrate security measures with our Continuous Integration/Continuous Delivery (CI/CD) pipeline. By regularly monitoring and improving our software to ensure product security, we are able to deliver high-quality solutions more quickly to you.
+
+We also employ a comprehensive suite of security scans that cover various aspects of our software: containers, container images, Kubernetes, source code, operating systems, and configurations. This extensive coverage enables us to identify and address a wide range of potential security issues before they can impact our end users. 
+
+We connect the results of our security scans directly to our ticketing system. This seamless integration ensures we promptly address any identified vulnerabilities or issues and validate them during our release checklist activities.
+In addition, we continually evaluate and adopt new security tools and practices to stay ahead of evolving threats. Our investment in security automation and tools demonstrates our commitment to safeguarding your data and maintaining the highest standards of software quality and security.
+
+<br />
+
+<br />
+
+<br />

docs/docs-content/security/product-architecture/_category_.json

@@ -0,0 +1,3 @@
+{
+  "position": 20
+}

docs/docs-content/security/product-architecture/data-encryption.md

@@ -0,0 +1,55 @@
+---
+sidebar_label: "Data Encryption"
+title: "Data Encryption"
+description: "Learn about Palette security controls for data and communications."
+icon: ""
+hide_table_of_contents: false
+sidebar_position: 10
+tags: ["security"]
+---
+
+
+Palette has security controls for the operating system, containers, and Kubernetes. Data is protected with secure keys, encryption, and secure communication, standard authentication and authorization, and API security. Audit logs record actions taken on the platform. Review the [Audit Logs](/audit-logs) guide to learn how to access and use them.
+
+
+<br />
+
+## Data At Rest Encryption
+
+Tenant data is encrypted using a 64-bit cryptographically secure tenant key. A unique tenant key is generated for each tenant. The tenant key is encrypted using the system root key and is stored in the database. The system root key is stored in the cluster’s etcd key-value store. All message communication uses tenant-specific channels.
+
+The following secure keys are unique and generated for each installation:
+
+<br />
+
+- **Root Key**: Encrypts the tenant-specific encryption key.
+
+
+- **JSON Web Token (JWT) signature key**: Used to sign the JWT token.
+
+
+- **Hash Salt**: Used to hash the user password and email ID.
+
+
+- **Tenant key**: A 64-bit cryptographically secure tenant key encrypts tenant data stored in the management cluster, such as user account name, user email ID, and tenant cloud credentials.
+
+
+In self-managed deployments, secure keys are generated during installation and stored as secrets in the management cluster’s etcd key-value store.
+
+<br />
+
+## Data In Transit Encryption
+
+Palette secures data in motion using an encrypted Transport Layer Security (TLS) communication channel for all internal and external interactions.<br /><br />
+
+- **End User Communication**: Public certificates are created using a cert-manager for external API/UI communication. In self-hosted deployments, you can import an optional certificate and private key to match the Fully Qualified Domain Name (FQDN) management cluster.
+
+
+- **Inter-Service Communication**: Services in the management cluster communicate over HTTPS with self-signed certificates and an Rivest–Shamir–Adleman (RSA) 2048-bit key.
+
+
+- **Database Communication**: The database connection between Palette internal services that are active in the management cluster and MongoDB is protected by TLS with Authentication enabled.
+
+
+- **Message Bus**: A Secure Network Address Translation (NATS) message bus is used for asynchronous communication between Palette management clusters and tenant clusters. NATS messages are exchanged using TLS protocol, and each tenant cluster uses dedicated credentials to connect to the message bus. Authentication and authorization policies are enforced in the NATS deployment to ensure message and data isolation across tenants.
+

docs/docs-content/security/product-architecture/platform-security.md

@@ -0,0 +1,34 @@
+---
+sidebar_label: "Platform Security"
+title: "Platform Security"
+description: "Learn how Palette provides platform infrastructure security."
+icon: ""
+hide_table_of_contents: false
+sidebar_position: 0
+tags: ["security"]
+---
+
+
+Based on the deployment model, Palette is composed of a multi-layer deployment stack: Cloud > VM > OS > Container Runtime > Kubernetes > Pods.
+
+To ensure maximum security, we follow defense-in-depth principles that prescribe securing each layer in a multi-layer deployment stack.
+
+For SaaS deployment models, cloud and Virtual Machine (VM) security are handled by SaaS platform operation security controls. For on-prem deployment models, the customer’s data center infrastructure team typically handles cloud and VM security.
+
+## Operating Systems
+
+The operating system that Palette uses for its Kubernetes management cluster is Ubuntu 20.04 LTS. We follow CIS standards to harden the operating system.
+
+These hardened images are used to launch control planes and worker nodes for the Kubernetes cluster hosting Palette. Additionally, all OS images are scanned for vulnerabilities prior to being published to a repository.
+
+## Container Security
+
+Spectro Cloud uses Containerd for container runtime. Containerd is an industry-standard container runtime that emphasizes simplicity, robustness, and portability in managing the complete container lifecycle. It runs as a demon on Ubuntu instances.
+
+Container images for various application services are built using distroless images, which have significantly fewer packages and improve security by reducing attack surface.
+
+All container images are scanned for vulnerabilities prior to being published to a repository or deployed to the SaaS platform.
+
+## Kubernetes Hardening
+
+We secure Palette's Kubernetes version based on Center for Internet Security (CIS) Kubernetes benchmarks. Several additional rules are also enforced on components such as the API Server, Controller Manager, Scheduler, and Kubelet.