Encryption Algorithm Implementation
Daycast—a real-time web application for time-tracking and team awareness—uses over half a dozen Node.js microservices behind a web proxy to communicate with third-party applications and services for authentication, data storage, project management, and reporting. Leaning heavily on the cryptography primitives and algorithms in the Node.js framework and following the twelve-factor methodology principle of storing secrets (and other configuration artifacts) in environment variables, CSNW interns successfully designed and implemented an encryption algorithm for Daycast configuration variables. In doing so, they greatly reduced the possibility of accidentally leaking unencrypted secrets to log files or memory dumps and added a layer of protection from attackers—if one were able to gain code execution privileges to the production server, they would not be able to obtain our access tokens and acquire access to those resources. This project required a multifaceted development and devops guidance team with a high level of encryption knowledge, significant automated testing and deployment experience, as well as familiarity with best practices for secure container management. These are all core components of Systems Security Engineering (SSE) practice.
Our goal for this project was twofold: (1) harden the Daycast application by encrypting service account passwords and other tokens used to connect microservices, and (2) provide real-world work to our software development interns.
After prioritizing according to SP 800-37 Guide for Applying the Risk Management Framework (now superseded by SP 800-37 Rev. 2), the team began by researching the encryption algorithms available in our software framework and choosing one that was suitable for the task of encrypting our secret environment variables. Then they wrote a module that encrypts and decrypts strings passed to it using a private key (per SP 800-63B Digital Identity Guidelines: Authentication and Lifecycle Management) while utilizing the Continuous Testing (CT) methodology to automatically test the encryption changes with each commit.
An audit of the Daycast codebase came next. The team looked carefully for all uses of sensitive environment variables and wrapped each with a just-in-time call to the new module, which generates random initialization vectors for strings it encrypts and returns them with the encrypted value for use in decryption. They also ensured that the decrypted result was ephemeral and never stored in a global or easily-accessible location.
Using Continuous Deployment (CD) to automatically deploy the changes once they were fully tested and approved, CSNW interns successfully used git, docker, and Jenkins to roll out the change to our servers.
One of the first places attackers look is in the environment variables, since that's often where applications store database access tokens and other proverbial keys to the kingdom. By encrypting these, we put a significant roadblock in any potential attacker's way. To our knowledge, the Daycast system has not been subject to intrusion before, the system is even more protected now.