redpesk®cybersecurity model

An applicative security model derived from Tizen

Our view on cybersecurity

redpesk security model
  • Security can not be added after the fact
    • Must consist of the built-in APIs & be transparent for applications
    • Developer SHOULD not be in charge of security
    • Baked in from day one : architecture, dev., QA, maintenance
  • Security must be well balanced
    • Minimizing attack surface area at every stage
    • Same effort from low to high levels
  • Do not rely on humans but on platform

Security model

  • LSM Smack or SELinux for enforcing separation of applications and protecting the system objects
  • Cynagora database derived from Tizen for checking dynamic permissions
  • Framework for integration of the security model
redpesk security model

Secure gate

OpenID-Connect Secure-gate AFB-Extension (sec-gate-oidc) is an openid-connect/oAuth2 compliant extension to the application framework binder. It provides a secure filtering gate for the REST and websocket incoming requests.

On the external, Internet interface is leveraging OpenID user profile services to map incoming browser to the profile and roles as defined by the identity authority. On the backend level (micro-service APIs) it responds to Cynagora privilege request for lower micro-service API to accept or deny a given request.

sec-gate-oidc complies with any OpenID-connect identity public authority such as github, google, microsoft, facebook, ... it also complies with internal authorities such as Dex, Keycloak, Forgerock, ... For local authentication an optional PAM plugin is provided as a sample local authentication template.

secure gate

Key benefits of our security model

  • Same security model from sensors to the Cloud:
    • Secure gate handles access to target services
    • Able to secure both Linux and RTOS/Zephyr services
  • Implemented via SELinux/Smack
  • Supports 2 factor authentications for additional security
  • Auditability
  • Can authenticate against a remote IDP