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.

The external Internet interface leverages OpenID user profile services to map incoming browser to the identity authority defined roles. On the backend level (micro-service APIs) sec-gate responds to Cynagora requests to grant or deny API access.

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 identity provider (IDP)