Information Security Entropy

The following article inspired this documentation: What Is Software Entropy & How to Manage It.

Concept of Entropy

Entropy is a scientific concept that is most commonly linked to disorder, randomness, or uncertainty in a system.

In a simple way, the entropy (S) is bigger when there are more possible ways the system (like a box of bouncing balls) can be arranged. The more ways things can be arranged (the bigger Ω is), the more disordered the system is (or can be), and the higher the entropy.

Imagine you have a big box full of tiny, invisible balls bouncing around inside. These balls can move in many different ways, and they can be in many different positions in the box.

Now, the idea behind Boltzmann's entropy formula is to measure how many different ways those balls can be arranged or how many possible "configurations" the system can have. The more ways there are to arrange the balls, the more "disordered" the system is, and the higher the entropy.

In other words, entropy is a way of talking about how chaotic or mixed-up things are. The higher the number of ways the balls can move around, the higher the entropy.

Software Entropy

“Software entropy” or “software rot” describes the tendency of systems to grow increasingly disordered, complex, and difficult to maintain over time. As a result, the software becomes harder to understand, modify, and support. Eventually, maintenance may become so challenging that the system becomes unusable.

The following are examples of what contributes to software entropy:

• Accumulation of technical debt: As new features are added, the codebase becomes more complex. Over time, this results in technical debt - the effort required to bring the system up to modern standards. This debt makes maintenance more challenging, as changes become increasingly difficult and time-consuming.

• Lack of documentation: Proper documentation is essential for software development and maintenance, yet it's often neglected. As a result, knowledge about the system becomes fragmented or lost, forcing developers to “reverse engineer” the code to make changes, contributing to software entropy.

• Inadequate testing: Insufficient testing leads to more bugs and unexpected behavior. Over time, these issues accumulate, making the system harder to maintain and more prone to failures.

• Unmaintainable code: Poorly written code that doesn't follow best practices becomes increasingly difficult to update and modify. Developers struggle with messy, inconsistent code, making long-term maintenance a challenge.

• Changing requirements: As software evolves, so do its requirements. Complex systems become even more intricate and opaque, leading to bad design choices, bloated code, and persistent bugs.

Security Entropy

Security is no exception to entropy. Over time, security systems and processes degrade, becoming more difficult to manage and often reaching a point where it becomes nearly impossible to maintain.

• Lack of documentation: Inadequate or outdated security documentation makes it difficult to track security policies, access controls, and system configurations. This can lead to misconfigurations, security gaps, lack of understanding of security processes, and difficulties in responding to incidents.

• Accumulation of vulnerabilities: Over time, unpatched software, outdated dependencies, and misconfigurations create a growing number of security vulnerabilities. As these accumulate, the system becomes increasingly difficult to secure and maintain.

• Complex security processes: Overly complicated security controls and procedures can lead to confusion, inefficiencies, and human errors. Simple, well-structured security practices are easier to follow and maintain.

• Lack of access control hygiene: Poorly managed user roles, excessive privileges, and orphaned accounts increase the attack surface. Without regular audits and strict enforcement, unauthorized access becomes more likely.

• Shadow IT and undocumented systems: Unapproved software, unmanaged devices, and undocumented infrastructure introduce unknown risks. These systems often lack security oversight, making them prime targets for exploitation.

• Inconsistent security policies: Disjointed or unenforced security policies lead to unpredictable security postures across an organization. A lack of standardization increases the likelihood of breaches.

• Poor incident response preparedness: Without a well-documented and tested incident response plan, organizations struggle to detect, contain, and mitigate security incidents efficiently. Delayed responses increase damage and recovery costs.

• Weak security culture: A lack of awareness and training among employees leads to risky behaviors, such as poor password management or falling for phishing attacks. Security should be an ongoing, organization-wide priority.

Managing Entropy

A fully ordered system is neither possible nor sustainable in the long run. Every system - by which we mean any collection of actions, events, or processes - will inevitably experience decay. However, while entropy cannot be eliminated, it can be managed. There are ways to reduce disorder and maintain systems that are relatively structured.

Security thrives in order and deteriorates in chaos. The more disorganized our systems and processes are, the harder they are to secure. Therefore, the Security team commits to being agents of order wherever possible, helping the company mitigate entropy and maintain stability.

When managing entropy, we stand by the following principles:

• Planning: Effective planning is essential for maintaining order and ensuring that our actions are aligned with long-term goals. By setting clear priorities, defining timelines, creating a security calendar, and anticipating potential challenges, we can approach tasks with greater efficiency and foresight. Planning also helps us allocate resources more effectively, ensuring that the most critical actions are prioritized.

• Simplicity over complexity: Complexity breeds unpredictability, which in turn increases security risks. We prioritize simple, well-structured solutions over unnecessarily intricate ones. Our processes should be as simple and straightforward as possible - both to understand and to follow.

• Scope definition: A clearly defined scope eliminates ambiguity, ensuring that security measures are focused, effective, and enforceable. Without clear boundaries, risk management becomes challenging. For example, our application security program is currently limited to a select few critical repositories, allowing us to concentrate our efforts and resources more effectively.

• Answered is always better than unanswered: We should respond to everything that requires our attention - whether it's directly answering an inquiry or adding comments to Jira issues, even if we're unsure of the exact solution. Engagement and communication are key.

• Document all things: What isn’t documented doesn’t exist. Clear, up-to-date documentation ensures consistency, enables informed decision-making, and allows for effective security enforcement.

• Monitoring: Security is not a one-time effort but an ongoing process. Continuous monitoring helps detect anomalies, enforce policies, and respond to threats before they escalate. Proactive oversight is essential to maintaining order and reducing risk.

• Cleaning up: Maintaining order requires periodic cleaning. Outdated systems, unused resources, and irrelevant data can create vulnerabilities. Regularly "cleaning up" - whether it's archiving old data, decommissioning legacy systems, or removing unnecessary privileges - ensures that security remains strong and systems stay efficient.

How does all of this translate into actionable steps? There are several key actions we can take.

For example, we currently have 542 repositories on our GitHub. Our main repository, Rocket.Chat, has 2.6k open issues and 678 open pull requests. The Security team can assist by archiving or deleting repositories that are no longer necessary. This helps maintain a clean and organized environment, making it easier to manage the remaining repositories. The same principle applies to open issues and pull requests. Many of them are approaching their 5th anniversary and are no longer relevant to our current code base. Cleaning these up allows us to focus on the issues and PRs that truly matter.

Previously, security documentation was limited and lacked a standard. Our security documentation should reflect a clear, structured, and consistent approach that ensures all security processes are easily accessible, understandable, and actionable. This includes maintaining up-to-date information on policies, procedures, access controls, incident response plans, and security best practices. Additionally, sensitive or internal processes should be clearly separated from public-facing documentation, ensuring that we maintain confidentiality while still fostering transparency where appropriate.

The documentation should also be organized in a logical, easy-to-navigate manner, allowing both new and experienced team members to find relevant information quickly. It should also include thorough explanations, guidelines, and examples to ensure that security practices are implemented consistently across the organization.

When it comes to vulnerability management, we previously had multiple boards and an overwhelming number of vulnerabilities, many of which were duplicates or irrelevant security issues scattered across different boards, making it difficult to manage. Now, we’ve streamlined the process with a single dashboard and have focused only on the vulnerabilities that truly matter.

Step by step, we are adhering to the principles mentioned earlier, improving the management of the chaos that once hindered our security processes and plans. We also anticipate being able to assist other departments in doing the same.

If you see anything that the Security team could help clean up and organize, please contact us over at security@rocket.chat or #rocketchat-security.