The number and frequency of Information Security Incidents continue to grow exponentially, but countermeasures’ methodology and effectiveness have stagnated for years. Because information about these incidents is confidential, there was no way to improve the situation with technology based on real-life experiences.
IBM commissioned a study to determine what can be attributed to the growing cost of handling these incidents. The Poneman Institute reported a correlation between the time required to close an Incident and the overall cost of the Incident.
Information Security professionals and Software Developers banded together to solve a complex problem. Members of the team, who had pioneered the Information Security field, noticed that one part of the process had not improved for thirty years. The process depended on an Incident Response Plan, a “ToDo” list with sequential tasks for responding to an Incident contained in a text-based document.
Technology has only complicated the problem. Plans were now located on remote servers. When an incident occurs, these servers may not be available, and staff relies on whatever version of a plan is accessible. There are many types of possible incidents. Every company needs a custom plan for each type. So, there was no way for a tech company to develop a universal solution.
After every Response, it is “Best Practice” for a team to meet and discuss Lessons Learned. The objective is to improve the Plan and not repeat past mistakes. Companies never share this information. Hundreds of companies could respond to the same Incident in a given day, but each must face it alone. There was no way to collect the combined Lessons Learned and create a model to be used by AI.
The Greybelt team created an application to solve the above issues and developed several new technologies in the process. The solution is called Reflex.
The Reflex platform was designed by a group of Chief Information Security Officers (CISOs) who began their careers as software engineers. The project’s stated goal was to advance the process of incident response by addressing its weakest link: the paper-based plans that responders rely on, which are often inaccessible when needed.
A common workaround was to copy PDF-formatted plans to the mobile devices of incident responders. This approach failed for multiple reasons. A PDF formatted for a large screen was unmanageable on a mobile device, and plans are frequently updated, requiring staff to manually update their mobile copy after each revision. In practice, when an incident was declared, team members worked from whatever version was on their device—often different versions of the plan. Most companies reverted to using paper.
An ideal solution would not simply be a document reformatted for mobile screens but rather a custom mobile application that allowed a team to work through the remediation of an incident. However, this approach required a custom mobile app for each type of incident, which meant that every time a plan was updated, the application would also need to be updated. No software company has solved this problem. A generic app could be created, but it would still require a company-specific plan. The goal of our team was to create a platform that would allow organizations to build custom mobile applications from the text-based documents currently in use, delivering them automatically to users when needed.
## Please look under the menu item “How it works” for more details than provided below.
The workflow is as follows: The system compiler reads and interprets an electronic document (Word). This step can be skipped if desired, and plan items can be entered directly. A “Reflex Plan” is created.
The Orchestrator (the manager who created the plan) enters rules for each plan item. For example:
- Can item 9 be completed before item 8 is marked complete?
- Does a team member have the privilege to mark item 9 as complete?
- When an item is marked “in progress,” should notifications of its status be sent via email to specified stakeholders?
- Should a message be sent at the completion of the item?
Reflex allows the Plan Orchestrator to set preferences based on how they would prioritize these options.
Once all the rules and dependencies are established, a Reflex Plan is created. The Reflex Plan is a binary object. From a security standpoint, there is no way to reverse-engineer the original document from the binary object. The original plan document remains on the Orchestrator’s desktop computer or wherever they choose to store it.
A Reflex Plan is not the actual application sent to mobile devices. The binary package sent to mobile devices is known as a Reflex. A Reflex contains the Reflex Plan along with several other components. In addition to listing the required steps and linking supporting documentation, it includes a built-in email system, a messaging system, and a forum manager that allows team members to exchange information during the incident.
Why duplicate functionality that already exists on mobile devices? Using an individual’s personal device introduces potential conflicts of interest. Company data should remain separate from an employee’s personal data. For example, incident-related emails should not be mixed with personal emails, and confidential company messages should not be stored alongside personal messages. Reflex creates a firewall between company data and personal data. At the end of an incident, all exchanged data is archived with the results of the Reflex, ensuring that no incident-related data remains on the user’s device. The concepts of virtual messaging and virtual forums were original innovations built into Reflex.
Reflex Plans do not contain information about specific resources that will execute the plan. Best practices dictate that plans should not include named resources, as available personnel will depend on staffing levels when an incident occurs. Instead, Reflex uses response groups—teams of people assigned to handle a particular incident type.
The Orchestrator creates response groups with skill sets relevant to the specific type of incident. If needed, the Orchestrator can assign specific members to tasks. The Orchestrator also specifies when a group is “activated.” Activation means that group members receive a text instructing them to open Reflex on their mobile devices.
Creating groups and controlling the order in which they are activated is a powerful feature unique to Reflex. A response team may include members from Information Security, IT, Legal, HR, PR, and other departments. Not every member of Information Security will participate in every incident. Reflex ensures that those not involved can continue their everyday activities without unnecessary disruption.
In some cases, the nature of an incident may be unclear at first. The Orchestrator may create a general “First Responders” group. If this team determines that the declared incident type was incorrect, they can cancel the incident and start a new one of the correct type.
Escalation is another key feature. In real-world information security incidents, it is crucial to have a contingency plan. If an incident is not being resolved effectively with the current resources, Reflex supports escalation. For example, a company may have an external contractor who specializes in a niche area, such as recovering data from a damaged hard disk. This individual is not needed full-time but can be activated in specific cases. Reflex allows for rapid escalation and activation of additional resources as needed, regardless of their location.
A Reflex is a template that combines one Reflex Plan with resource-specific data. A Reflex Plan can be reused in as many Reflexes as necessary. Organizations can choose to have a single, generic Reflex covering all incident types or create multiple Reflexes tailored to specific incidents. The platform is designed to accommodate organizations of all sizes, from small businesses to large government agencies. Reflex has even been considered for military applications.
I would be remiss if I did not mention an advanced feature of Reflex that has been part of the design from the beginning: predictive analysis of incident outcomes.
Artificial intelligence is a major topic today, attracting billions in investment. However, when I first developed AI applications 30 years ago, it received little attention. When I wrote the functional specification for the Reflex platform over a decade ago, AI was already a key consideration. The following is a direct excerpt from that specification:
The following Is a line copied and pasted directly from the functional specification I wrote 12 years ago. “It is important that the application measures statistics regarding how the participants perform in handling the incident. There must also be a way for a participant’s knowledge and skill level to be quantified. If a participant’s skill can be assigned a recognized value, and the required skills to handle a particular incident are expressed in these values, then it would be possible to predict the outcome of an incident before it happens.
An application could use the archive created during an incident response and tell you what resources were not present that led to a failure. The problem is that some standards organization must maintain the definition of the skill sets and what is required to earn certain values. This must be universal, or there is no way to compare “apples to apples” and “oranges to oranges.” I am building this feature into Reflex, but it cannot be used cross-organizationally until there is a standard. It is hoped that in the future, there will be an artificial intelligence that can use the information gained from companies worldwide and instantly detect what is happening in an incident and what it will take to stop it.”
The current version of Reflex contains such a system. An Orchestrator can go through his or her address book and specify his or her staff’s skills. We are providing a list of established incidents, and the believed skill sets it takes to mitigate them successfully. The AI built into Reflex can analyze the expected skills to mitigate an incident versus the people who are participating in the incident. At the beginning of every incident, all team members must check-in. If a person has not checked in after a set period of time, it is assumed that his or her skill set will not be available to handle this incident. The Orchestrator is warned that more resources are needed to complete the incident. Reflex can look at all available team members in every group and suggest a substitute. It allows the orchestrator to make predictions as to resource shortages.
Taking this one step further, a Manager can ask the Builder to look through all requirements in all incidents and compare requirements with everyone who is entered as an incident response. This information can then be presented to the manager to argue for more staff or at least get agreements in place for outside help when needed.
Borrowing from a concept in video games, Reflex uses the idea of NPC (non-playable characters). There is an “artificial person generator”. A manager can create a person and give them specific skills. He or she can then have Reflex predict the outcome of an incident as if this person was an authentic available resource. As a hiring manager, this is a convenient tool. One can compare multiple job candidates and see how they would fit into the group.
There is another practical use of the person generator. Application testers have told me this is one of their favorite features. When you install the Builder, you begin with an empty address book. You can’t use the features of Reflex without at least having some people in the address book. It would be quite tedious to set up if you wanted to test some of the advanced features. However, the “people builder” can create a staff and specify many things about the individuals on your artificial staff.
## It is important to mention that everything I have listed here under very advanced features is invisible to the user unless they specifically want to play with them.
The architecture of the Reflex platform has resulted in advanced capabilities that are not available in any other software platform. Some of these capabilities may seem impossible, but they have been successfully implemented in the current working version. I will explain these features and the rationale behind their design. I refined these concepts while working on a project in Russia, under the watchful eye of the Russian KGB, where I had the opportunity to observe the many ways software can be compromised or disrupted.
The three main features of Reflex are:
- Impossible to hack
- Impossible to disrupt
- The only SaaS solution that can exist anywhere
The platform consists of more than 30 individual modules. These modules interconnect to form the application, but what makes Reflex unique is that they do not communicate using IP addresses. In fact, no module knows the exact location of any other module. This is accomplished through a system referred to as ART (Almost Real-Time). Real-time data is packaged and sent using a proprietary system that functions similarly to a mail system, but without relying on any traditional email protocols or components.
To explain this concept, I’ll use the analogy of mailboxes. Each component only knows the location of the main mailbox. Encoded within each message is the location of the sender’s mailbox. This system functions much like the layered architecture of the Internet. However, a potential weakness in such a system is that a hacker monitoring the mobile app could determine the location of the main mailbox and launch a Denial-of-Service (DoS) attack to disrupt communications.
When designing the Reflex protocol, I recognized that no startup—or even a large company—could build a mailbox-like server that could withstand a Distributed Denial-of-Service (DDoS) attack. A critical design goal was to find a black hole—a server that has been proven to be impossible to crash. The only requirement of the ART system is that the main mailbox must be hosted by a major provider such as AWS. AWS has built such a black hole, investing millions, if not billions, of dollars to ensure its resilience. It has never been successfully taken down, making it highly unlikely that Reflex could be disrupted by a hacker.
Some government and military organizations will not use any application that cannot run on their own infrastructure. This is understandable, as certain information is classified. As a senior information security manager working for a multibillion-dollar corporation, I have encountered organizations that refused to adopt a product unless it could be fully hosted on their internal systems. My employer was unable to meet this demand. There are companies that will build a custom version of their product for such organizations, but at a very high cost. That cost includes not only the initial development but also a separate maintenance plan, with difficult and costly upgrades due to the restrictions placed on external access. This is one of the most common objections I have encountered in my role as a senior information security manager.
As far as I know, Reflex is the only platform that solves this problem. As mentioned earlier, every module in the system operates without knowing the location of other modules. When running in Docker containers, even the system itself does not know where it is running. This means Reflex can operate from any environment. During demonstrations, I often run every module on my laptop simultaneously. It functions perfectly, but the previously mentioned challenge remains: if an organization does not permit the use of a major provider’s black hole infrastructure, they must host a substitute on their own systems. While their infrastructure may not be as bulletproof as AWS, in a secure, air-gapped environment, the risk of external hacking is significantly reduced. Organizations of this nature typically have robust defenses against DDoS attacks.
Although Reflex is capable of providing this option, there would still be additional costs. Supporting and upgrading the system in such an environment requires extra effort, but it can be done without modifying our core system. During development, scenarios involving military use and FEMA-specific features were considered. The system was even offered to the U.S. government at no cost for potential deployment during emergency situations, including the COVID-19 outbreak.