Preventing an IP Infection: Clean Room Development Procedure

“All people involved must be impressed with the importance of the development project and the seriousness of the endeavor. They must be made to understand that violations of the procedures will have serious consequences for the company and, in turn, for them.”

As I described in my previous article about the protocol for clean room product development, there are often situations where a company has come into contact with intellectual property that it cannot allow to spread to a product in development. In that article, I described the concepts of a clean room. In this article, I describe the practical implementation details.

Once a clean room protocol has been set up, the following sections describe the recommended procedure to implement.

A. Write a Detailed Description

As with all critical procedures, the first step is to write a detailed description of the procedure. This document is especially critical for clean room development should the new product created in the clean room ever be challenged in court. This document is to be shared with everyone involved in the project: the clean room developers, the dirty room developers, the monitors, and the project managers. The detailed description should include all of the following things:

1. The purpose of the clean room development. This should be well defined from the beginning so that all parties involved know what the goal is. For example, in a litigation settlement, the goal may be to rewrite specific sections of software code that have already been determined to contain misappropriated intellectual property from another program (“infectious IP”). In another case, the clean room development may be required to produce a device that can interoperate with another device that contains the infectious IP. In yet another case, the purpose may be to reverse engineer and copy the functionality of some other party’s product without literally copying it.
2. Location of rooms. The physical locations of the clean room and the dirty room should be specified. Ideally the rooms should be as physically separate as possible, for example, in separate locations, though such extreme separation is not required. Note that the clean room and dirty room may actually encompass sets of rooms or entire buildings, or they may be virtual. If the rooms are virtual, this should specify how they are set up, which software is used to access them, and how the various developers in each room are given access to their room and blocked from access to the other room.
3. Security measures. If the clean rooms have physical locations and the locations are within easy access of each other (e.g., in the same building), the following measures should be put in place: Locks on doors leading to the rooms are mandatory, and security systems requiring electronic access and that record who accesses each room and when are highly recommended. Each person entering or leaving the room should be required to note the times of entering and leaving if this is not done automatically by the security system. Any people who are removed from the teams must immediately have access to their room revoked.
4. Designated developers in each room. The developers in the dirty room and those in the clean room should be designated by name. Any developers who are brought onto one team or let go from a team should immediately be noted in this document.
5. Designated monitor. The person or persons designated as monitors for the procedure should be named in this document. If a company is designated as a monitor, only specific employees of that company should be allowed to act as monitors, and those persons should be named in this document. Any people who are subsequently named as monitors or who are removed as monitors should immediately be noted in this document.
6. Communications methods and procedures. This section of the document should specify how dirty room and clean room developers are to communicate. This section should also specify how communication is to take place, whether it is by written documents, printed documents, flash drives, other removable drives, email, or some other method or combination of methods. Whenever possible, encryption methods should be used for any information coming out of the dirty room. All communications should be clearly labeled so that it can be understood that such communications relate to the project. For example, a project name or code can be used so that each communication can be tracked. Alternatively, special email addresses can be set up for communicating about the project. Direct communication between the two sets of developers should be severely restricted, though it is usually not possible to curtail all communications, especially when they are located in the same building or within the same corporate entity. The developers should not be simultaneously assigned to any other projects that might require additional communication to the other team.
7. Activity report format for each room. Developers in each room should prepare regular reports on their activities. This section of the detailed description should specify the format of those reports, the media used for the reports, and the frequency of the reports. It should also specify whether each individual developer is responsible for producing a report or whether a team leader is responsible for producing a report for the entire team.
8. Documents relied upon. This detailed description should list those documents that will be relied upon for each room’s tasks. Each room will rely on a different set of documents, each to be listed in this detailed description. Any documents discovered later or determined to be necessary during the development procedure should be added to this list.
9. Hardware and software. A detailed description of the hardware and software that will be relied upon should be in the document. In the case of the dirty room, this includes all hardware and software used to examine and reverse engineer the original product. In the case of the clean room, this includes all hardware and software used to develop the new product. This can be particularly useful if the tools introduce artifacts that appear to be due to the infectious IP but in fact are not, because they can be shown to have been introduced by the tools.

B. Sign Agreements

The clean developers and dirty developers and the monitor should all sign agreements not to violate the written clean room procedures and commit to following the documented procedures. All people involved must be impressed with the importance of the development project and the seriousness of the endeavor. They must be made to understand that violations of the procedures will have serious consequences for the company and, in turn, for them.

C. Examine the Original Product in the Dirty Room

The developers in the dirty room now can begin the process of reverse engineering or otherwise understanding the functionality of the original product. They must write a specification of the functionality to be developed in the clean room that does not include any of the infectious IP.

D. Transfer Specification to the Monitor and then to the Clean Room

The developers in the dirty room then transfer the specification to the monitor, who examines it for any infectious IP. If the monitor determines that the specification does not contain any infectious IP, the monitor then transfers it to the clean room. If the monitor finds some infectious IP in the specification, the monitor then sends the specification back to the dirty room with markup showing the problems to be resolved. The dirty room developers continue to rework the specification and transfer it to the monitor until the monitor verifies it as containing no infectious IP and then transfers it to the clean room.

E. Begin Development in the Clean Room

Using the specification that was sent to them from the dirty room via the monitor, the clean room developers begin development of the new product. Any communications from the dirty room intended for the clean room are sent to the monitor for review before passing it on to the clean room. Communications from the clean room can go directly to the dirty room as long as the monitor is copied. This is a way of ensuring that there are no communications between the clean room and the dirty room that go unmonitored—for every question that the monitor receives from either room, the monitor should have a corresponding reply from the other room.

F. Questions from the Clean Room to the Dirty Room

The developers in the clean room transfer any questions through the monitor or directly to the dirty room and copied to the monitor, who examines them for any issues that may potentially divulge infectious IP by the developers in the dirty room. If there are any such issues, the monitor marks those questions with a warning not to divulge any infectious IP in answering the question.

G. Answers from the Dirty Room to the Clean Room

The developers in the dirty room then transfer the answers to the questions to the monitor, who examines them for any of the infectious IP. If the monitor determines that the answers do not contain any infectious IP, the monitor then transfers them to the clean room. If the monitor finds some infectious IP in the answers, the monitor sends the answers back to the dirty room with markup showing the problems to be resolved. The dirty room developers continue to rework the answers and transfer them to the monitor until the monitor verifies them as containing no infectious IP and transfers them to the clean room.

H. Check Final Product for Inclusion of Infectious IP

For added protection, the monitor may verify that the final product created in the clean room does not contain the infectious IP. This verification can be done manually and/or by using a tool that compares the original product to the new product to determine whether any correlation is due to the infectious IP.

I. Violations of the Procedure

Any violations of the procedure must be reported to the monitor, who will determine whether any infectious IP was shared. If infectious IP was inadvertently shared, some sort of remediation must occur. Remediation may include removing certain developers from the project who have violated the procedure. Remediation may also include removing clean room developers from the team who have received infectious IP, to ensure that this information is not shared with other developers in the clean room. In cases where the intellectual property has significantly contaminated the clean room, it may be necessary to start the procedure from the beginning with a new team of clean room developers.

Image Source: Deposit Photos
Image ID: 370351540
Author: deagreez1

Bob Zeidman

Bob Zeidman is the creator of the field of software forensics and the founder of several successful high-tech Silicon Valley firms, including Zeidman Consulting and Software Analysis and Forensic Engineering. […see more]

Story originally seen here