Security

In-App Chat Security

Container security

Using eRTC Scanner:

The eRTC container scanner does the layer-wise static analysis of the container that is running on the client’s machine. We ensure that a hardened and certified image is delivered to our customers, using our own private repository. By providing vulnerability reports to the customers (on-demand), we ensure the quality of our deliverables.

Where to view:

Benefits: Since it is providing on-demand security scanning, it gives an added cushion, allowing customers to rest assured that the containers provided are secured and safe to use.

How do containers change the security definitions?

Benefits: Since it is providing on-demand security scanning, it gives an added cushion, allowing customers to rest assured that the containers provided are secured and safe to use.

What is adopted in our product and operations?

Automation has shifted security across the standard definitions so far - because containers encapsulate all their dependencies, they can move easily from a development environment to a test environment to a production environment, making frequent deployments by way of automation the new reality.

Containers scale up and down far more significantly; applications built using a microservices architecture consists of many interrelated entities. The number of deployed entities can grow quickly as orchestrators seamlessly scale your apps up or down according to demand. Additionally, manually creating and maintaining security rules for each entity is impractical.

Our development cycles have shrunk from months to days or hours. Developers, as they aim to deliver business value, are deploying more quickly than ever before using CI-CD pipelines in times measured in hours and days, not months. Integrating security into CI/CD workflows and implementing DevSecOps best practices while in the development, building, testing and delivery phases provides incredible security advantages in the world of containers that we use.

How do we aim to secure the entire container stack?

A container environment, in general, encompasses your images, containers, hosts, container runtime (docker and containers), registries (Dockerhub and Harbor), and orchestrator (Kubernetes, Docker Swarm and Rancher). Understanding potential risks and how to protect the environment against them is essential.

  • Image vulnerabilities and compliance concerns: Vulnerabilities can impact container images just like any other legacy code framework, which is why scanning images for both vulnerabilities and compliance issues, building a bill of materials, identifying any embedded secrets or malware, and correlating risk to individual image layers ensures developers are building secure images.

    Additionally, organizations need to remember drift can be a big problem for containers. An image that was scanned and passed your vulnerability and compliance requirements today may not be secure in the future; new threat data can identify components that are actually vulnerable when they were originally thought to be secure. This is why today’s enterprises need to continuously monitor images and run time-scanning containers for drift.

  • Container runtime protection: The container runtime is one of the most difficult parts of a container stack to secure because traditional security tools were not designed to monitor running containers. They can’t peer inside containers or establish good baselines for what a secure container environment looks like. Our Runtime security focuses on securing the running dockers, rather than only relying on network-level security tools to keep them safe using the security agents deployed within the environment.

    Our dev-ops, infrastructure, and security teams are embracing the concept of immutability: replacing existing containers with new containers whenever you make an update to your applications or services. Immutability presents security advantages, so users aren’t attempting to perform live updates on running containers, preventing configuration drift and poor enforcement of security policies.

  • Compliance: Protecting the Host OS and meeting the CIS compliance. The OS that hosts your container environment is perhaps the most important layer of the stack, because an attack that compromises the host environment could provide intruders with access to everything else in your stack. That’s why hosts need to be scanned for vulnerabilities, hardened based on specific CIS Benchmarks, and protected to prevent improper access control (Docker commands, ssh commands, sudo commands, etc.) or file tampering. With our paid plans, we are providing the underlying host vulnerability status using our host agents.

    The roadmap is to make a workflow where the customer can raise a ticket with RBN support to initiate the remediation of the open vulnerabilities as per their environment needs.

  • Configuration:
    • For Free Plans: Everything is autoconfigured.

      For Hosted Plans: Everything for container security and compliance will be autoconfigured, based on the plan purchased by the customer. Customers can initiate on-demand scans as per the provision.

    • For On-Premise: Everything is autoconfigured.
      • We can offer basic vulnerability insights from our private registry in the future with Harbor.
      • We can offer an Integration Module with the customer’s existing vulnerability scanning solutions.
      • We can offer/sell/recommend a security solution to be purchased for best results. (NOTE: For now, we are using Qualys to be used as container security and compliance).

What do we display on the portal?

  • Container Security:
    • We can offer basic vulnerability insights from our private registry in the future with Harbor
    • CVE numbers assigned for it
    • Possible remeditation method by daemon/tool vendor
    • Severity level of each vulnerability
  • Compliance
    • Host wide results for CIS compliance based on customer purchase/deployment plans
    • Level of severity
    • Remediation information
    • CVE numbers