My Opinion on document protection is similar

I read the article "some common problems I encountered in the process of selling iron coils", so I can't speak up.

First, the full text is referenced as follows:

======================== =

1. problems that may result from enterprises' document protection requirements
1.1. requires selective encryption

When selecting an electronic document anti-leak product, some enterprises will put forward the following requirements:

For the same type of documents, I hope we can choose which documents need to be encrypted and which documents do not need to be encrypted. In this way, employees will not be troubled in use.

Problem Analysis: This requirement seems reasonable, but it is contrary to the original intention of preventing leaks in Enterprise Documents. If you allow selective encryption, the following problems may occur:

How can we prevent original document leakage?
As long as the company retains a plaintext confidential document, who can ensure that this document will not be transmitted?
If only selective encryption is required, why not pack and compress confidential files and passwords?

According to the FBI and CSI investigations, more than 70% of internal information leaks are caused by leaks of internal personnel. Therefore, for electronic document leaks, it is important and critical to prevent active leaks.
The fundamental purpose of Enterprise Document Protection against leaks is to ensure the security of electronic documents. This is the original intention of the purchase and the purpose of the purchase. From this point, the powerful anti-leak software will be useless.
Therefore, the demand for selective encryption is not in line with the enterprise's procurement objectives.

1.2. You want to control the internal document permissions of the enterprise.
Some enterprises may make such requirements when purchasing:

I hope that your software can be implemented: even within our company, you can implement strict document permission control. For example, if you share the same document, Michael Zhang can see that Li Si can print and edit the document ......

Problem Analysis: At present, Chinese organizations generally find electronic documents in a state of "unordered Management". To change this situation, we need to start from the technical and management aspects, on the one hand, encryption is implemented by technical means (solutions similar to iron coils), on the other hand, corresponding management methods should be developed, and the electronic documents should be gradually managed hierarchically in practice, and the identification work should be done well to standardize them. After completing these two aspects, we can finally establish a complete set of technical solutions to encrypt and decentralize electronic documents.
An obvious example is a well-known information leak prevention software in foreign countries. This software has several application cases in China. We visited the relevant users and found that there is no exception, all users are spending the money, and the software functions are useless because their enterprise management level has not reached the appropriate level, there is no electronic document identification, confidentiality, management of this series of management systems and methods, at this time directly on a set of software, users are completely at a loss.
Let's imagine the following scenario:

An employee a wrote a document. When saving the document, he suddenly jumped out a window asking a to select the document he wrote. At this time, a suddenly did not know how to choose, because the company did not specify what kind of documents belong to what kind of confidentiality level, for the sake of convenience, a chose all people to read this document.
Q: What is the difference between having internal permission control and having no internal permission control? This feature will only cause inconvenience to users.

Let's imagine another scenario:

An employee a wrote a document. When saving the document, he suddenly jumped out a window asking a to select the document he wrote. At this time, a suddenly did not know how to choose, because the company did not specify what kind of document belongs to what kind of confidentiality level, a thought, think this document is to be sent to B Manager. Select one option that only allows B to view data. And sent this document to B via email.
After reading this document sent by a, B thought it was well written. He thought that all the people in the company had learned it and forwarded it to all the employees of the company. However, the following employees cannot open this document after receiving this email. So I called B manager one after another, so B Manager received several hundred calls from the company one day ......
Manager B asked the Administrator what happened and understood that the Administrator had internal permission to control such a thing. Then, he forwarded all the documents sent to him to the Administrator, ask the Administrator to help him reset the permissions for these documents. Similarly, Manager C, Manager D, and manager e ...... The Administrator is also required to help him reset the permissions for all their files. The Administrator cannot handle other tasks every day, and the document permissions are reset every day ......
Company leaders were quite dissatisfied with the purchase. After a while, the software was abandoned.

The above is a real example.From the above example, we can see that a software with a certain function may not be suitable for use by enterprises, but may also cause great troubles to enterprises. When enterprises choose to release leaked documents, they should not embrace the idea of "security first. Selecting products based on the actual situation of the enterprise is the most suitable for the enterprise's own needs.

2. Problems with document protection software products
2.1. Software Vulnerabilities
The additional functions of a software product are powerful and won in the bidding of an enterprise. However, during the application process, enterprises have discovered many problems with the software:
With the simple function of "Save as", you can easily convert a document from ciphertext to plain text.
Rename an unrelated software as a special file name, open the ciphertext document, and then save it to make the ciphertext document into plaintext.
Some public tools can be used to decrypt a ciphertext document.
You can copy the text, images, and other contents of confidential documents to other unencrypted files by dragging the mouse.

These bypassing methods make the enterprise quite angry. After contacting the software vendor for multiple times, the vendor is still unable to solve the problem. The Enterprise requested a return and the vendor refused to take the software vendor to court.

2.2. Poor Software Design
Document anti-leak software has a common feature: users will require normal use of documents within the company, and once the information is taken out of the company, it cannot be opened (except for legally authorized non-confidential documents ). However, in some special cases, the software vendor does not consider the following for users:

The software must be able to work offline to meet the needs of employees on business trips and Home Office.
The software must be able to easily decrypt certain documents to meet the issue of external communication of non-confidential documents.
The user must initiate a request for offline approval by the Administrator. And offline is subject to time restrictions. You cannot go offline without limit. When you are offline, the effect must be the same as when you are online to prevent leaks.

When going offline, you must consider the following:
Does the user maliciously extend the offline time using operations such as clock callback?
If an employee is on a business trip and cannot connect to the company's server, but it really needs to be extended offline. Is there a perfect solution?

For file decryption problems, the user must also initiate an application for approval by the Administrator. At this time, each department is required to be able to set a "department administrator", because a general administrator cannot understand the documents of each department very well. If you do not know whether the document is confidential, it is sufficient to allow or deny the document to be decrypted.

With the development of enterprise information construction, more and more documents are stored in the form of electronic documents. As a result, the document Leakage Prevention concept is gradually introduced in China, the software for document Leak Prevention is selling more and more, but the products in this software market are mixed, and enterprises are expected to start from their own needs, select a document anti-leak Software suitable for your enterprise.

======================== =

My opinion is as follows:

First of all, the customer's requirements are always "reasonable". Specifically, there is always a reasonable side. It must be acknowledged that the customer's needs are sometimes strange or even ridiculous. In this case, I will tell the other party the truth, just as in the citation, listing some arguments. However, it's okay not to persuade the customer or sell the product. I will also think about why my products cannot meet the customer's needs while implementing functions? The customer's needs are often extracted from their actual work experience and habits, rather than being "unreasonable.

Specific to document encryption issues. The customer needs to be able to select encryption protection for each document. Iron is used to forcibly encrypt specified types of documents (I hope I do not understand it ). Forced encryption must be used based on "selective encryption and anti-Disclosure Violation ". In my opinion, Here iron is stuck in the inertial Thinking of "driving-level transparent encryption and decryption", believing that only mandatory is safe. (Why do I say "again "? Haha .) I think the reason for this idea is that it is too easy and "perfect" to use a driver for forced encryption, so that the designer cannot imagine what the product can do after it is mandatory. Yes, everything is free. Is there security? I want to sell a secret. Let's talk about the rationality of selective encryption.

If my company wants to deploy iron coils tomorrow, the first thing I need to do now is to back up all my documents (DOC/XLS/PPT or even TXT/CPP) to the mobile hard disk. Because many documents on my computer are not confidential and need to be modified and shared with others at any time. I cannot tolerate the encryption and protection of these documents, and the external common documents cannot be simply returned to others after being processed on my computer. Although work computers can be separated from everyday computers, the fact is that I use the same computer at home, at the company, or on a business trip, so that nothing will be delayed. I can also list the rationality of selective encryption, which is collected during communication with customers.

In essence, the main problem facing forced encryption is that it seriously affects the circulation of common documents. Security is often in conflict with convenience. If it is impossible to use physical isolation, it will be difficult and difficult to resist. However,Coordinates the relationship between security and ease of use, and maximizes flexibility while ensuring security. This is the value of a good security product.

Return to the requirement issue. According to the citation, forced encryption can solve the active leakage problem. Is that true? Is there a better solution? It can be discussed in two cases:

In the first case, the customer has not used document protection products, and even has not managed important documents in a centralized manner. All documents are out of control. Therefore, the deployment cost will be required when the document protection mechanism is introduced.

First, neither force encryption nor encryption can prevent plaintext data from being backed up to uncontrolled locations before deployment. This is not a technical problem, but must be solved by administrative means.

Second, the deployment process is "one-size-fits-all" like iron rolling. Although all specified types of documents are encrypted, it is a "one-size-fits-all" process in terms of ease of use ". Selective encryption provides customers with at least two solutions: one is that each employee actively classifies their own documents and uploads confidential documents to the server for encryption and storage, at the same time, this operation is monitored and restricted by administrative means. Second, an automated tool is run on each computer to upload all specified types of documents to the Document Server, delete the local documents, and then the designated person (such as the department leader) reviews all uploaded documents, leaving confidential documents and returning common documents to employees. Of course, documents returned to employees cannot be forcibly encrypted on the terminal. The two solutions can be combined during actual deployment. For example, employees actively perform classified encryption, but first all the plain text is backed up to a server for "case". Once someone finds that important documents are not encrypted according to regulations in the future, the backup server will be well documented. Or some types of documents (paper) should be reviewed by leaders, and others (such as Doc) should be selected by themselves. After talking with the actual customer, I found that these solutions are acceptable to the customer.

Obviously, the key to the problem is that forced encryption during deployment cannot prevent users from secretly backing up confidential documents in advance, so it makes no sense to forcibly encrypt all documents without partitioning, selective encryption is a more reasonable solution.

In the second case, how can we prevent the original author of the document from disclosing the information after the deployment is complete. To solve this problem, you must first pay attention to how this confidential document is generated.

If the document is written out of thin air, the author just needs to find a "clean" computer and then write it again to "leak". This is not beyond the control of any document protection product. Fortunately, the content of other documents is often referenced when writing documents, which is the significance of encryption protection.

If the confidential document references all the content of common documents, the logical writing process is not disclosed, and the general documents do not need to be encrypted, because the real secret is in the author's mind. In addition, a common document means that its content may be obtained by deploying a path other than the security domain of the document protection product (such as browsing the webpage. Therefore, the author of the security domain can still write a "confidential document. Therefore, I believe that, in order to reduce the way to obtain common information, the use of forced encryption to prevent simple circulation of common documents is totally worth the candle-security is not substantially improved, but it is a lot of trouble.

If some or all of the confidential documents reference the content of other confidential documents, the new confidential documents must be protected first according to the concept of classified protection. That is, to directly copy content from other confidential documents, you must first encrypt the document being written. In this case, selective encryption is automatically "forced" and will not cause security vulnerabilities.

Forced encryption can effectively defend against the possibility of copying confidential information to common documents by means such as typing. However, due to the limited types of forced Encryption Files, you only need to replace a format that will not be forcibly encrypted to copy files. For example, you can use a TXT file to copy a file. TXT files can also be encrypted using RTF, HTML, and CPP. If it is a drawing, it is a little complicated. You can write down the component parameters and draw them out in a "clean" system. In addition, the current "Driver-level transparent encryption and decryption" products generally use file names and hash to identify applications. You only need to change the file handler name and add a shell to avoid forced encryption. First open the confidential document with the original application, and then create a new document with the modified application, you can copy the file in the same format. (Although some programs can only have one instance, at least one word or Excel can exist, and the ug may also exist .)

In short,Forced encryption to prevent active leaks is just a beautiful lieIt does not do better than selective encryption, but seriously reduces the flexibility. In addition, it is easy for a product with selective encryption to implement forced encryption, so it is not an opportunity for users to choose. However, in turn, the forced encryption product must provide the selective encryption function, with no small change. This change is not as simple as allowing users to customize encryption policies, but also involves many user experience adjustments. From this perspective, it is obvious that the selective encryption and forced encryption mechanisms are more applicable.

Next I will solve the above questions-What else can I do without being mandatory. First of all, you should clarify your point of view and avoid trying to prevent the author of the document from disclosing the document. This is definitely a thankless thing, as we have mentioned above. The purpose of document protection is to ensure that confidential documents that have been included in the protection system are always transferred and shared in a controllable security domain. The design ideas and technical content between different products are reflected in the win-win situation of security and flexibility. In my opinion, the solution is to combine autonomous access control and mandatory access control in classified protection. For documents stored, transferred, and shared in the form of private documents, use autonomous access control to control the viewer's scope and permissions by the author. This part of the document is valuable to some people, so use autonomous access control to prevent passive password loss. More important documents are submitted by the author to the Administrator for review or directly imported by the Administrator. They are rated as confidential and subject to mandatory access control. Each user accesses these confidential documents with different permissions through a predefined role. (This solution seems nothing remarkable, but the interesting part is the details. However, I will not elaborate on this article. It takes a lot of space. I am not writing a thesis .)

Next, let me talk about the internal document permission control issues. The quote states that "the enterprise management level has not reached the corresponding height" does not require permission control such as classified protection. I strongly disagree with this point of view. A well-designed product with classified protection features can be easily simplified to two "classified protection" types: protection and non-protection. If the customer feels "at a loss", it will not be able to use classified protection for the time being. If a product clearly fails to achieve classified protection, but tells the customer that classified protection is useless, "if you do not use it", is it too self-righteous ?! Similarly, if we come to the conclusion that "the world is black" based on the so-called case of a poorly-designed product in the quote, it would be a little bit. Classified protection can also meet the requirements of "Transparent operations" to a large extent, and there is no need for ABCDE managers to constantly seek administrators.

In the information security circle, there has always been a saying that "three-point technology and seven-point management. You can go to the post on the cissp Forum-"What do you think about the three-point technology and seven-point management ?". The relationship between management and technology is discussed in detail, which is enlightening. My idea is that, regardless of the proportion of management and technology, we should first add the "shortest board.

For large domestic and foreign enterprises reported to have serious information security incidents, I believe they have always had sound and strict security regulations in terms of management, but they have not been effectively implemented. This is the technical responsibility. Security regulations often require users to change their original work habits. It can be said that they must conflict with convenient and flexible requirements, and "the more secure, the more inconvenient ". However, products with excellent technologies can better reconcile this contradiction, enhance the user experience, and ensure the implementation of (mandatory) specifications to a certain extent. They can also provide comprehensive audit functions for future tracking. Therefore, there is no doubt that the technical investment needs to be strengthened in the case of "having the law not to comply with the law" and "having the law not to comply with the law.

In most cases, Chinese enterprises lack both technology and management, or management lags behind. How can this problem be solved? The discussion of cissp vividly compares technology to Western medicine and management to traditional Chinese medicine. Many people agree that it makes sense. "Western medicine is quick." If technology and management are missing, first strengthen technology. What should I do if the management cannot keep up? I would like to say that the practice of waiting for the management level to gradually improve is to escape the problem. From the perspective of software developers, we sell not only a good product, but also a security model or security concept. Customers who have security requirements and agree with your security philosophy will accept your products. What developers should do is to design a rigorous, standardized, and flexible Document Protection Model to adapt to various customer needs and different management levels. Like Microsoft's Sharepoint, both teams, small businesses, large enterprises, and a number of business partners have a suitable architecture to meet their needs. Technology is not omnipotent, it cannot replace management, but technology can be a "Catalyst", the so-called "Science and technology change life ". Enterprises can deploy flexible classified document protection products, from nothing to specification, to guide employees to gradually accept the enterprise's security system.

In short, when selecting document protection products, enterprises should have a long-term vision. They should not only view the current security requirements, but also consider the security requirements that will inevitably increase in the near future. (Do not expect that the products you bought will be upgraded in the future and meet your new needs. Even so, they will not be delivered in vain .)

Finally, let's talk about the vulnerability. Vulnerabilities such as "Save as", "RENAME", "drag", and a certain tool (probably thread insertion) that can be decrypted are the consequence of excessive pursuit of "Transparency. Product design, R & D, and testing personnel should be ashamed of their laziness. That's right. It's just laziness! In addition, this "bean curd residue project" should be eliminated during the tender. Companies are also responsible for failing to detect problems in advance (they should ask me to inspect the goods ). As for offline access, Offline Control, and offline append permissions, there is nothing to say.

Please forgive me for all the mistakes mentioned above.