Nemesis: Theory of Operation - x684867/nemesis_server GitHub Wiki


Problem Statement:

(1) Sensitive data (including cryptographic keys, certificate files, usernames and passwords) are often kept on the same servers which use this information.  Even where encryption is used, the information is often maintained in cleartext on the same servers where the keys reside.  If the server is compromised, then the sensitive information on the server can be used to extend the attack to the data or other layers of the environment.

(2) No audit trail or functionality exists for monitoring or managing access to this sensitive information.

(3) Even where encryption is used, the cryptographic keys often reside on the same server as the encrypted data.

Nemesis Solution:

The Nemesis solution protects sensitive information first by dividing encryption keys from the encrypted data and moving both well behind the perimeter and away from the application servers where the information is used.  Second, Nemesis encrypts the data in-flight and at-rest.  It then obfuscates the data objects and keys by identifying them using unique, random identifiers (UUID) that cannot be easily compromised to exploit the stored data.  Key objects stored on a key server are identified using UUIDs that do not identify whether the key is a public key or private key or the pair to which the key belongs.  Data objects are identified by UUID which does not identify the keys used to encrypt/decrypt the cipher or even to identify what the data might have meant in its plaintext form.  Third, Nemesis creates an audit/policy framework for the service that controls how often and to whom the data is exposed as well as recording all access operations.  Fourth, encryption and decryption occurs on a separate "broker" server so that the keys and data are never in the same place as the other is stored.  Linux swap files are further protected using random encryption keys to prevent swapped memory from compromising the system.  Finally, and fifth, the servers each use encrypted storage to protect data objects and the Nemesis mechanisms.

Nemesis allows an application to store its sensitive data (objects) as a key-value pair in an encrypted, policy-driven storage solution.  The application can store and retrieve the information from one of two (2) methods:

     (a) Web API Access
     (b) NemesisFS Agent

The "Web API Access" method will expose a RESTful API to allow applications to connect via TLS encryption to the Nemesis front end web server ("broker") and perform basic
data-object CRUD (create, read, update, delete) operations.

     See https://broker.nemesiscloud.com/{create,read,update,delete}/{args}

This API is also used indirectly by the NemesisFS Agent.  This agent is a demonized shell script (/usr/bin/nemesis-master) which spawns a worker process for every data object to be exposed to an application server by Nemesis.  The NemesisFS Agent works with named pipes to allow legacy applications to realize the benefits of Nemesis.

USE CASE:
  1. Assume an application server runs Apache web server.
  2. The web server exposes a web application over SSL (HTTPS) and thus must have a public-key pair (x.509 certificate) consisting of both a public key and private key file.
  3. These files must be protected and should have an audit trail to ensure that policy regarding certificate usage is maintained.
  4. NemesisFS is installed and creates two named pipes: /etc/ssl/private/myprivate.key and /etc/ssl/cert/public.crt
  5. Once NemesisFS starts it will fetch the certificate contents and push them to the key and crt files.
  6. Apache can then start and read from these files.
  7. When the data is pushed to the named pipes, NemesisFS can report that the data is exposed.
  8. When Apache reads the information from the named pipes, NemesisFS will be able to report that the data was consumed.
  9. Nemesis can reload the information into the named pipes if policy allows.  But in the case of an Apache web server, this should not happen unless apache is restarted.


interactions


The Nemesis Web API exists at two (2) levels:

  • Control Layer
  • Data-Access Layer

The Control Layer allows systems administrators and control applications to create and manage data objects.  The Data-Access Layer allows Application servers (and Nemesis FS) to read information from the Nemesis stores (abstracting the encryption process completely behind the scenes).  There is a third management application allows users to manage data objects, policy and audit logs.  However, this application is built on top of the API and not parallel to it.

  • Control API
    • Allows Nemesis servers to report activity
    • Allows Nemesis servers to request policy objects
    • Periodically performs "audit polls" of cipher store and key store servers to collect store statistics
    • Periodically performs "broker audit polls" to collect statistics from the broker service
    • Presents "management web application" (NemesisWeb).
  • Data-Access API
    • Allows Application servers to perform data-object CRUD operations.
    • Allows NemesisFS Agent to perform data-object read operations.
    • Allows Application servers to poll the "heartbeat" of the Nemesis system.
The modularity of Nemesis gives the solution a great amount of flexibility:

(1) Nemesis could be deployed on a single machine as separate Linux Containers or even using virtual hosts.  Granted this would reduce the security benefits of the Nemesis design, and is most likely only appropriate for test/dev environments.

(2) Nemesis can also be deployed on multi-homed systems where each module is isolated into a separate network (e.g. VLAN) so as to maximize the benefits of the modular design.

(3) The Nemesis application is horizontally scalable at every level due to its modularity, scaling as each layer needs.

Modularity divides the Nemesis solution as follows:

  • Audit Service: https://audit.nemesiscloud.com/
    • The Audit service exposes the Control API to the systems administrators and to the other servers
    • Application servers cannot directly.
  • Broker Service: https://broker.nemesiscloud.com/
    • The Broker Server exposes the Data-Access API to the application servers.
    • This Broker Server performs object-CRUD operations including actual encryption/decryption operations.
  • Cipher Store Service: https://cipher.nemesiscloud.com/
    • This server stores encrypted data objects in a flat file system, where each data object is stored in a file named for its "cipherId" (UUID) values.
  • Key Store Service: https://keys.nemesiscloud.com/
    • This server stores the encryption keys (public and private) stored separately as individual data objects (files) named for their individual "keyId" (UUID) values.

Add a custom footer
⚠️ **GitHub.com Fallback** ⚠️