Let us now look at analyzing and resolving security issues. A safety assessment process can be divided into four stages: asset classification, threat analysis, risk analysis, and conformance to design. In general, the implementation of security assessment in accordance with this process will help avoid big issues. The implementation of security assessment is progressive; there is a causal relationship between the steps. Assessment of any system should start from the first stage of implementation; if it is under long-term maintenance by a dedicated security team, then some stage can be implemented once. In the process, the former stage will determine the targets and level required of the next.
Asset classification is the basis for all work; this will make clear the objective that you want to protect.
There are three elements of security, confidentiality, and integrity of all data related to the availability, for which we use the term resources. Resources, as a concept, describes a more extensive range than data, but in many cases, the availability of resources can be understood as the availability of data.
If the infrastructure of the Internet has been relatively complete, the core of the Internet is actually driven by the user data—user-generated business operations data. For Internet companies, in addition to some fixed assets, such as servers and other hardware, the core value is user data. -So the core issue of Internet security is the issue of data security.
Does security relate to asset evaluation? Of course, Internet companies have an asset classification, the data classification. Some companies are most concerned about customer data; some companies are even more concerned about employee data; the focus is different depending on the respective business. In the process of asset classification, we need to communicate with the persons in charge of each business unit to understand the company’s most important asset. After the interviews, security departments become familiar with and understand the company’s business and its data, as well as the importance of different data, which directs the follow-up assessment process.
After the completion of asset classification, the objective forms into a rough idea; the next step is to divide the trust domain and trust boundaries. Usually, we use one of the simplest divisions, which is based on network logic. For example, if the most important data is in the database, then we circle the database server; the web application can read/write data from the database and external services, and then the web server is circled; most of what is outside the Internet cannot be trusted.
This is the simplest example; we will encounter many more complicated problems than this in practice. For example, if the two similar applications exchange data, then we must consider the interaction—whether it is credible, whether we should draw a boundary between the two applications, and finally whether data flowing through the boundary need security checks.
Having provided the definition of trusted domain, we can now determine where the danger comes from. In the security field, harmful elements to the source are known as threats, and losses that may occur are known as risks. Certain risks are associated with losses, but many professional security engineers often confuse these two concepts and mistake their identity in a written document. Distinguishing these two concepts can help us go to the next two stages, “threat modeling” and “risk analysis,” which are closely related.
What is threat analysis? Threat analysis is finding out all threats. How to find them? By brainstorming. Of course, there are some other more scientific methods as well, such as the use of models to help us identify threats; this process can avoid omission and is known as threat modeling.
Threat analysis should aim, as much as possible, to identify all possible threats; the attack surface can be determined by the brainstorming process. When maintaining system security, the most frustrating part is that engineers spend a lot of time and effort to implement security programs, but attackers assess the vulnerabilities and are able to invade successfully. This is often caused by neglect on the part of the engineers when determining the surface of attacks.
Let us consider the case of Conquer Mountain Hua, an old Chinese movie that is based on a true story. The Battle of Shaanxi started in mid-May 1949; the remnants of the KMT brigade and the chairman of the 8th District Commission Han Zaipei escaped to Mount Hua with more than 400 people in a last-ditch attempt to form a natural barrier, taking the only road leading to the mountain. Road East Corps decided to send General Staff Liu Jiyao to reconnaissance; Liu Jiyao led the squadron, and with the help of local villagers, he found another path up the mountain. They overcame all difficulties and ultimately successfully completed the task. After the war, Liu Jiyao was honored as a national hero and was conferred the honorary title of “principal war hero.”
Let us look at this event from a security angle. Nationalist troops during the threat analysis only took into account the “only road” and completely ignored the other possibilities. This was the flaw in the implementation of their security program, and once this happens, all illusions of safety will be disrupted by attacks.
Threat analysis is a very important stage; a lot of time is also needed to regularly review and update the existing model. There may be many threats, but not all of them can cause a major loss. How much harm can a threat cause and how to measure this? This is why it is necessary to take into account the risk, which is done during the risk analysis process. At this stage, there are models that can help us scientifically assess the different types of risks.
Risk is composed of the following factors:
Risk = Probability * Damage Potential
Besides the size of the losses and high or low factors affecting risk, the likelihood of occurrence also needs to be taken into account. For example, volcanic earthquakes frequently appear at the edge of continents, such as in Japan and Indonesia. In the continental center, if the geological structure is on an entire rock, the risk of earthquake is much less.
When we consider the security issues, we need to weigh the possibility of occurrence in order to correctly determine the risk factor. How do we assess risk scientifically?
For example, if the KMT brigade, after threat modeling, found two principal threats to circumventing the mountain—a threat of stormy weather on the main path and a treacherous trail to contend with—the corresponding risks could be calculated as follows:
The main path:
Risk = D(3) + R(3) + E(3) + A(3) + D(3) = 3+3+3+3+3=15
The mountain trail:
Risk = D(3) + R(1) + E(1) + A(3) + D(1) = 3+1+1+3+1=9
The level of risk is defined as follows:
Thus, the main path is the most high risk and bound to be heavily guarded; however, the mountain trail too turns out to be at risk and therefore cannot be ignored. The reason why we regard the mountain trail as a medium-level risk in this model is because whenever it is broken, the loss is too large to afford.
Let us now take a look at the security assessment of the overall process. Remember at all times that the model is the same; it is only the people who keep changing. No matter how good the model, we need trained people to use it. Once the attack surface and risk level are determined, one needs an experienced hand. This is where a security engineer adds value. Like STRIDE and DREAD, there may be many different standards corresponding to different models; as long as we feel that these models can help us, we can use them. However, the model can only play a supporting role—decisions will ultimately have to be made by people.
Design of Security Programs
The output of security assessment is the security solution. Solutions must be target-specific, that is, they must be broken down by asset class, threat analysis, and risk analysis. To design solutions is not difficult; what is difficult is to design a good solution. Designing a good solution is the true test for security engineers. Many people think that if the security conflicts with business, some business will be sacrificed because of ensuring security; however, I do not agree with this view. From a product perspective, security is essential. Without considering security, a product will be incomplete.
For example, if we want to evaluate a cup, we need to consider—apart from how much water it can hold—whether the toxic coating on the cup will dissolve in water or whether it will melt at high temperatures or even be brittle at low temperatures. These issues have a direct impact on the security of the users. For the Internet, security is for the development and growth of products. We cannot enforce security solutions as that would hinder the normal development of products; thus, security should be built on consensus with the motto: no unsafe products, only unsafe operations. Businesses should focus as much as possible on designing security solutions without affecting the commercial viability of the product. As security engineers, we should think of simple and effective solutions to solve security issues. Security programs must be able to effectively counter threats but should not interfere with the normal business processes nor hold back the functional performance. Good solutions should be as transparent as possible and should not affect the user’s way of working.
Microsoft launched Windows Vista with a new feature called UAC; whenever there is any software-sensitive action, the UAC will pop up asking the user whether to allow this behavior. This feature has been vastly criticized—if the user were able to tell what kind of behavior is safe, then why do they need security software? Lots of desktop security softwares have the same problem; they frequently pop up a dialog box asking the user whether to allow the target behavior, which is ridiculous.
Good security products or modules need to take user experience into account but also need to facilitate continuous improvement. A security module should be an excellent program as well, designed to achieve high polymerization, low coupling, and ease of expansion, and should be compatible for Nmap users, for example, who, according to the need, should be able to write plug-ins to achieve some of the more complex functions in order to meet individual requirements.
Ultimately, a good security program should have the following characteristics:
- Should be able to solve problems effectively
- Should provide good user experience
- Should be performance oriented
- Should have low coupling
- Should be easy to expand and upgrade