Self-cultivation of security architects: from principles to practice

25 min readDec 18, 2024

Translate from https://fz.cool/Things-About-Me-And-Enterprise-Cyber-Security-Architecture/
https://fz-cool.translate.goog/Things-About-Me-And-Enterprise-Cyber-Security-Architecture/?_x_tr_sl=zh-CN&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=wapp

0x00 Introduction

Six years ago, I started to record knowledge related to “architecture” on my blog (see “ Fangzhi#Security Architecture “), and three years ago, my ideas for enterprise security were basically formed (see “ My View on Enterprise Security “). Over the years, I have hesitated and doubted. As the saying goes, a slow horse can only be driven ten times faster if it keeps going. Today, I will talk about my understanding of enterprise security, or in other words, my self-cultivation as a security architect.

0x01 Security Design Principles in Architecture Evolution

Applications have evolved from stand-alone to distributed. The architecture has also gradually evolved, starting from a single machine, to a C/S architecture, and to server-side clustering. Then to a layered architecture, then to SOA, as well as microservices and Serverless architecture. Some people say that business needs drive the evolution of the architecture, while others say that changes in computing power drive technology iterations. As for the reasons behind this, you may need to experience it yourself to know something. I haven’t experienced it, so I won’t make random guesses. However, these are not new things, whether it is the application architecture or the security design concept. Least Privilege was first proposed in the 1970s, Defense in Depth was proposed in the 1990s, and even the latest Zero Trust was created by Dr. Stephen Paul Marsh in 1994 before it was promoted by Google in 2010.

Note: The Application Architecture column has both Architecture Style and Architecture Pattern. For easy comparison, Application Architecture is used here to refer to them uniformly.

Back to the beginning, let’s not talk about the essence of the evolution of technology trends. Corresponding to the changes in programming languages, from process-oriented programming languages represented by C to object-oriented programming starting with C++, and subsequent functional programming (Function Programming), etc. Excluding early AD-HOC programming, configuration (there should be no concept of security design in the early days, at least not found when searching for these security design principles). When the application began to develop from a monolithic architecture to a client-server (C/S) architecture, the design principles also began to gradually shift from focusing on isolation to minimizing privileges (Least Privilege). It is speculated that the monolithic architecture period was mostly client programs (here from the timeline of development, not referring to the monolithic architecture applications that still exist today), and only needed to pay attention to isolation. Whoever can open the computer can access it. When server-side programs began to appear later, the architecture gradually programmed the client-server model. At this time, it is necessary not only to pay attention to the isolation of the end side that provides services, but also to consider the control of access rights, so the principle of minimizing privileges appeared. At the same time, the RBAC model and so on were also created. If you are interested, you can go to Wikipedia.

Similarly, the principles of security by default and minimal exposure gradually emerged for the server side. Later, the introduction of layered architecture shifted the concept of security design to depth in depth. Even in the SOA architecture and microservice architecture period, the concept of security design has always been based on DID (which is actually enough), until cloudification, containerization and cloud native gradually developed, IAAS, PAAS, SAAS, and even serverless architecture (Serverless Archiecture) also came out (I once heard a risk control director say that using serverless architecture does not need to pay attention to application security). When microservices are expanded on a large scale, authentication between services becomes a strong demand. The zero trust model finally has the possibility of landing. With the emergence of Istio and K8S on the application side, Boundary products on the infrastructure side, Zscalar for access, and SASE products on the end side, the overall zero trust architecture can be said to have been barely implemented. Domestic alternatives will be discussed later, especially One Agent products that will eventually reunite after a long period of separation and eventually separate after a long period of reunion.

Back to security products, let’s take a look at how these security products support security design principles. Initially, it should be just manually configuring file permissions on Unix servers to achieve the principles of isolation and minimization of permissions. Later, firewall products gradually appeared, but now it seems that these products may be more like scripts and tools. Later, various products gradually appeared, from Logging to SIEM, from iptables to UFW, from Encryption to KMS, from Nginx WAF to RSAP (this is only through search and inference, not personally experienced, no evidence. I look forward to seeing the text records of Party B’s predecessors in the future.) And CSPM products were introduced on the cloud, etc. There is an illusion of a big explosion of security products, and all kinds of them are doing professional things in vertical fields. But compared with foreign and domestic products, the ecology is still far apart. Especially for the integration of infrastructure within the enterprise and the integration between security products.

1. From Isolation to Zero Trust

The introduction of new security design principles does not mean that the old security design principles are abandoned .

The evolution of application architecture has led to major changes in the attack surface of services. In the process from 127.0.0.1 to 0.0.0.0, the complexity of the business has gradually increased. Both the isolation of access and the isolation of permissions (I regard the principle of minimization as another isolation, that is, the isolation of permissions, because it is essentially to reduce the minimum resource overlap between the two entities of the service requester and the service provider) can no longer fully meet the security requirements. From the network dimension, if the isolation is still achieved through the five-tuple of the firewall, a large number of rules for coupled business scenarios will become unmaintainable, and it will also hinder “agile development” (at this time, security will often hear complaints from the business: “You blocked Production!!”). From the application dimension, there is almost no protection inside the microservice, and there is no so-called isolation. Although I have heard the concept of “micro-isolation” for a while, it seems to have disappeared before I figured out what this concept is.

Isolation is one of the most common security design principles. From the physical dimension, there are independent building isolation, access control isolation, dedicated line isolation, cage isolation, electromagnetic shielding cabinet isolation, and dedicated hardware such as hardware encryption machines; from the network dimension, there are VLAN, MPLS, VPN, network firewall isolation, and iptables, ufw, etc.; in the application and data dimensions, the financial industry prioritizes isolation through physical and network dimensions, which obviously causes big problems in operation and maintenance, although this does not hinder the normal operation of the business under the priority of supervision. Secondly, it provides isolation control at the application level by providing authentication and authorization (SSO, MFA, RBAC, etc.), sandbox, virtualization, etc., and achieves “isolation” at the data level by providing segmentation, masking, encryption (using different keys, homomorphic encryption), multi-party computing, etc. In addition, when ideal isolation cannot be achieved in actual situations, it is often implemented in the form of proxy design mode supplemented by detection and monitoring. For example, Web firewall, outbound proxy, mail gateway, Internet behavior proxy, DLP, bastion host, etc.

For zero trust, it is more like taking over the isolation and control measures at the physical and network levels at the application level. For example, by introducing ZTA applications, we can take over the access control between Applicatoin and Application, the access control between User and Application, and the access control between User and Machine. The form of software-defined security is indeed closer to the business. Introducing Istio inside K8S to use mTLS to enhance the security authentication and authorization between Services, while supporting encrypted transmission. Using SASE, you can use any Internet access point. After completing the compliance detection on the client side, you can dial into the network access point of SASE using SSO and surf the intranet, and complete the access to internal applications through Citrix. The accessed applications (including SASE and Citrix) can configure the corresponding user and group authorization when doing IDP integration. But at the same time, the control background of SASE products can also manage user access rights to specific applications.

Design principles represented by isolation include ACL and minimizing permissions. As for the design of the zero-trust principle, on the one hand, it refines the authorization scenarios, and on the other hand, it enhances the strength of authentication. From the design pattern point of view, they are all centralized control based on agents, singletons, and chain of responsibility models (CoR/Chain of Responsibility). Personally, I feel that although the security control achieved by zero trust is indeed more efficient from the application level, it still needs to be covered by basic isolation. For example: basic physical isolation, corresponding Security Zone (when combined with zero trust, the granularity of the Zone can be appropriately relaxed)

2. From simple encryption to privacy computing

If we continue to use the design thinking of isolation, the control of key access rights is essentially the control of data access . From a technical point of view, starting from the use of symmetric encryption algorithms for static storage of data (DARE/Data At Rest Encryption), to the use of asymmetric encryption algorithms to complete data interaction between the two ends (TLS key negotiation, Data At Transit Encryption), and then to the development of the PKI system, the identity of the entity is required to be authenticated while encryption. We know that even if we gradually move from RSA to the ECC series, we may not be able to resist the cracking under quantum computing. The emergence of Kyber represents the entry of encryption algorithms into the Post-Quantum era. // Embarrassingly, I suddenly found that IBM Quantum LAB was out of service.

From an operational perspective, let alone the self-created “encryption” algorithm, the self-created “SDK”, N business parties using the same fixed IV, the “key” displayed in plain text, the unequal protection of Secret Sharing, the incorrect use of certificates (more scenarios), the username and password are stored as cookies on the front end (this is what I found in an article from 2018 when I was writing this article, incredible!), and the incorrect configuration and use of hashing and encryption. This can involve a series of various sand sculpture problems encountered in the process from root of trust (RoT/Root Of Trust) to end-to-end encryption (E2E). But it is obvious that on the one hand, the algorithm strength is improved at the technical level, and on the other hand, the encryption of data storage and transmission is achieved by ensuring the security of private keys and shortening the rotation cycle (whether it is keys or certificates) in the operational dimension.

However, none of these actually solves the security problem of data in use. Even if the confidentiality of symmetric encryption key generation can be improved through a high-intensity asymmetric algorithm, the hybrid encryption system does not involve ciphertext calculation. Based on the principle that keys and plaintexts are equally important, the result of data plaintext calculation cannot be separated from the key link, but the calculation of ciphertext data removes the coupling between keys and plaintext data during data use . As for the technology of privacy computing, there are many categories, and there was a wave of publishing hype two years ago. For details, please refer to this study note: A Brief Discussion on Privacy Computing and Data Security . Although it is not common in actual implementation scenarios, overall, in the context of increased computing power and cloud computing, when there are more participants who do not fully trust each other, how to ensure data security and meet the computing needs of each participant will definitely increase. // Of course, this involves another topic, how to measure the cost of contractual solutions and the cost of technical solutions.

3. From secure by default to shift to left

Actually, there is not much to say, but it is not easy for everyone to understand the concept and implement it. If you want to learn more about security by default and security left shift, you can refer to the following two articles:

From the era of monolithic architecture, which focused on security by default, to the SDLC proposed after the application lifecycle management was started, and the subsequent microservice era, the rapid iteration brought by agile development undoubtedly led to a large number of potential problems. Even if the security scanning tools are built into CI/CD, new threats cannot be avoided. For example, supply chain poisoning: poisoning of basic tools such as xshell, poisoning of pypi sources, and poisoning of docker images, etc. So the security shift to the left was proposed. At this time, we not only need to pay attention to the ability of security by default, but also hope to advance the ability of security by default. But the actual situation is that as a design principle, it is good, but enterprises cannot even do a good job of security by default (please think about the so-called security by default, what dimensions are covered in the process and tools, and what businesses or infrastructure are invaded). Not to mention the concept of shifting to the left.

4. From logging & monitoring to security verification

In terms of basic security, the design principles have evolved from isolation to zero trust, in terms of application security, from default implementation to advance capabilities, and in terms of data, from simple encryption to ciphertext calculation. This article does not include the design evolution related to operations, but considering that operations are essential after the actual security design is implemented, I will briefly write about the changes in security operations in my opinion.

But if I am not ashamed to say, in the early stage of the domestic process of Party A security, there should be no overall security design. The main focus is on security operations, which are dazzling and can be exported. It is glamorous and awesome on the outside, but the hard work of front-line operations on the inside. This was also the time when I was most disgusted with the “culture” of security operations in 2018, because everyone was advocating security operations, but in reality it was case-by-case problem handling and the “circle and circle” culture, so that I tried my best to turn to the direction of data security architecture. Of course, now I no longer reject the topic of security operations, and the troll status has improved a lot. Because I found that even if you are doing architecture, operations are indispensable. For the operation of architecture, you can refer to the one or two things about the operation of security architects

Back to the design perspective, enterprises initially completed data collection through centralized log centers (there should not have been any earlier). Security log collection can be done independently or as part of the standard infrastructure within the enterprise. At this time, there was no concept of dataization and automation. With the emergence of SIEM products, the functions became more and more abundant, and scenario-based analysis of data began to be performed, and the results of disposal were automated. The SOP of the operation process and the process system for external release were formed. This period was a process of transition from manual to automated, and the organizational structure requirements for SOC teams were also formed during this period. The SOC team was further required to achieve indicators, such as the pressure reduction of alarms, the detection of intrusions, and the shortening of response time, and to make dashboards and IM alarm notifications. Later, a major dividing line was the formation of commercial products such as SOAR, which got rid of the process of manually maintaining custom scripts (I personally think that the platform dimension is more beneficial than manual maintenance). Looking at the product dimension, it is the research from SIEM to SOAR to BAS products (but I feel that BAS products are not completely included, because the concept of security verification can also be fully realized through customized SOAR scripts). It is the process of security operations being gradually automated and then the security design being verified. Because there are many hidden problems in the design implementation process, the design needs to be corrected through the results of daily operations. Of course, this involves another topic, which is that you can trust the team, but you cannot completely trust the delivery results of the operation.

0x02 The key balance point in architecture governance

When achieving business goals, how to balance management, operations, and technology is related to the development of the enterprise. In the technology part, how to achieve a new balance to ensure that IT and business are compatible is also crucial. The difficulty of balancing management and operations again in the process of implementing technology is also very important.

Considering the scale of implementation, this section discusses the key balance points in architecture governance through a series of questions (to avoid the balance becoming an infinite nesting doll), but there is no absolutely correct answer to these questions. Who is the decision maker? Who chooses between operating costs, security protection and high performance? For architecture, a large part is the art of balance.

1. Where is the baseline?

The baseline determines the height of the short board of the barrel, but the implementation of the baseline cannot be completely achieved through technical means. It must be in line with the business scenario and implemented through process systems and platform tools. If we start from the perspective of accountability, in order to pay attention to who will break the baseline, we need to first determine who is the last gatekeeper. Is it the so-called process system, or the key functional personnel, or the automated platform tool? In the case of process priority and tool support, the last gatekeeper is the last node person in the exception approval process. In the case of business priority, the last gatekeeper is the process system. Remember that it is not X who is making things difficult for Y, but the process here, although the essence here is that the process system people are the gatekeepers. However, sometimes it is impossible to avoid the result of giving way to the business, but it should be noted that some baselines can be compromised, and some must not be. For example, whitelisting of externally exposed endpoints can be compromised, using wildcard certificates can be compromised, and using HTTP is unacceptable.

2. Where is the depth?

It is generally difficult to fully implement defense in depth and zero trust due to insufficient understanding and inadequate components/tools (Party B’s products are good at professional functions but not necessarily in terms of infrastructure integration). For example, in “From Isolation to Zero Trust”, there are different ways to isolate from the physical dimension to the application dimension to the data dimension, whether independent access control, independent electromagnetic cabinet, hardware encryption machine, dedicated line or IP whitelist, etc. What should end-to-end zero trust look like? How to protect the security of the client, to the network side, to the application side? And between applications. From the data dimension, how is encryption performed? In the case of untrusted communication links? What if the storage is also untrusted? Even the KMS on the cloud is not trusted? Corresponding to these problems, there are corresponding technical means to solve them. But how to balance high performance and cost efficiency? For example, can TEE be introduced for K8S? Sometimes it triggers the regulatory policy? Should depth be abandoned? As mentioned earlier, is the data flow ensured by the contract really much worse than privacy computing technology? In what scenarios can the process system make up for the shortcomings of technology? In what situations must platform tools be used to improve the effectiveness of operations? Or is it not necessary at all? The word “must” is just a self-motivation of technical people? For example, how can the release of the operation be blocked without affecting business iteration? For example, for vulnerability operations, what dimensions should be added to the evaluation of the vulnerability with a 9-point cvss score in your enterprise? If others do not have a window to fix it, will it be a farce? Can we implement the encryption library ourselves? Do we have the ability to develop fizz like FB? Should the indicator trap be avoided? Or should we withhold the number of work orders and alarms every day? Do we need to conduct due diligence on SAAS services one by one? Before determining which ones to automate, first determine which ones should not be automated? But for this question, in actual scenarios, the business side must provide security with the requirements that need to be automated, while security hopes that the business side will first sort out the existing scenarios. In the process of back and forth, it can only be said that whoever stands in the position of the gatekeeper is qualified to make the decision.

3. Where is the cost?

In “Pour Your Heart Into It”, Howard regards employees as the most core assets of the company. Whether it is personnel or tools, the cost issue needs to be considered when it is implemented. I have several typical problems in the cost scenario. If there are insufficient resources, should we first make a first-phase plan, and then make a second-phase plan based on the resource situation? HC is about to be closed, should we hire someone to do it first? Should the cost of operation be counted as part of the best practice design? In other words, if you design a sloppy plan and the operation is miserable, whose KPI is it? Or have we achieved a win-win situation? The low-cost solution meets the company’s needs, and the multi-event output completes the operation report? When a group of people with strong soft power but no hard power get together, most of them don’t want to solve the problem, but want to get rid of the person who found the problem. I don’t want to discuss what went wrong in the cost section. But we should not only use human batteries and processes under the thinking of “it’s not unusable”, muddle through, and make do again and again.

0x03 Self-cultivation of security architects

One day, I was complained about, and the next day I was complained about again. I showed my boss my phone and chat history, and he said, “ Look, you were complained about because you don’t know why you were complained about. “ Later, I put a “Think Twice Before Acting” label next to my workstation, and my boss started to say that I was “Think Twice But Not Acting.”

This is an ancient Chinese poem，translate may not such good

There is a saying in the “Words of the World” that one must experience three realms in life, which are: “Last night the west wind withered the green trees, I went up to the high building alone and looked at the end of the world”, followed by: “My clothes are getting looser and I will never regret it, I am exhausted for her”, and finally: “I have searched for her among the crowd for hundreds of times, but when I look back suddenly, she is there, in the dim light”. Here are three questions for the time being. Is it cold to go up to the high building alone? Do you regret that your clothes are getting looser? When I look back suddenly, is she there?

1. Is it cold going up to a tall building alone?

Four years ago, I was taught: “Be objective, not subjective. Discuss the issue from a technical perspective and manage your emotions well. As long as you have two of the three, communication, experience and technology, you can grow well.” In the past year, my boss taught me: “Protect what is deep in your heart. Don’t expect or demand that others follow the same principles as you. Practice more, Just Do It Later.” Two months ago, I stopped the pendulum in my heart and wrote an article to commemorate this journey. It’s cold to go up a tall building alone, but you have to endure the cold. If you have people who share the same path, the road ahead will not be bitter.

a. Is it feasible to drive security through architectural design?

According to Dr. Werner Vogels (AWS CTO)’s speech at this year’s re:Invent, Everything starts with security. So how can we start with security? Speaking from my own experience, I never felt Security By Design when I was doing forward design. Instead, I saw a series of problems caused by more failed designs. Then I realized that if you want to keep starting with security, you must start with security by design. Another way to ask is, is the framework useful? Is experience useful? Because good design must be based on best practices. In addition, according to Tesler’s Law (the law of conservation of complexity): For any system, there is a certain degree of complexity that cannot be reduced, and the inherent complexity can only be balanced and transferred through product design. Then the transfer of system complexity must be completed by planning the system design in advance, looking at the overall situation, and drawing on experience. Finally, if the designer himself does not believe in the role of architectural design, what qualifications do he have to do any architectural design?

b. What do you think of the latest security trends?

If you have implemented cutting-edge designs and have been running stably for a period of time, you can try to investigate and use the so-called new security trends. For very traditional industries, you don’t necessarily need to pay absolute attention to them, because even if they are out of the trend of evolution, they can actually be replaced in one step in the end.

c. How to see the big picture from the small during the process of magnitude change?

Do a good job of simple design and consider complex implementation, make the architecture flexible (consider technical skills), and try to consider a variety of scenarios (test business experience). According to Kidlin’s Law, when the problem is clearly written out, it is half solved. Therefore, don’t worry about not being able to cope with the change in magnitude. Master the method, use system thinking to analyze more, and don’t think that some scenario problems are ridiculous. Finally, complete the design based on the results of the system analysis.

d. Security team service-oriented?

The premise of service-oriented is to increase the visibility of the team and provide the internal security product capabilities to the outside world. However, service-oriented should not be based on human consumption units, but should be supported by tools and platforms. Otherwise, it means that the security team at this time does not have the service-oriented capabilities.

e. What can the security architecture team do?

Provide training to Security BP, PM, Peer Team; write Policy/Strategy; do architecture design (overall security architecture design, single product solution); architecture review; provide security consulting and other security services;

2. Do you regret it now that your clothes are getting looser?

The belt in the lyrics is getting wider, which means the person is getting thinner. I hope to be fatter and more relaxed (note: the idiom is used incorrectly here), and then add more loose clothes. When I discussed career growth with my friends before, I talked about “If you are lucky enough to work in the industry you love and get development, you are really lucky.” Coincidentally, I am lucky to work in my love for security work so far. I looked back at the series of security architecture articles I wrote before and found that it started with the operation and maintenance of security equipment, and gradually came into contact with the solution architecture of different security products, and then to the overall security architecture. In this process, I also realized that technology-driven should never be an empty talk. When everyone doesn’t care about the results, someone needs to stand up and fulfill their responsibilities. When no one cares about the results of security construction, security architects need to stand up. This is not only a responsibility, but also a professional ethics. Later, I will continue to improve myself from three directions and strive to do what I think is right.

Communication and collaboration:
Follow the Senior Leadership and learn from him. Put into practice what you have learned about communication and emotional management from books, and turn the warnings in front of you into something to reflect on, until one day you tear off the sticker. Always give strangers a chance to trust, so as to build mutual trust and mutual respect. But once lost, there will never be a chance to rebuild.

Project experience: There is no other way, just read more, learn more, practice more, and summarize more. When dealing with people who do not have a professional background, you must try your best to explain it clearly in a language that the other party can understand.

Technical changes: Although I understand the overall design and the solutions of individual products, I also began to find that sometimes I can no longer grasp every technical detail clearly. Of course, I also found that some people’s approach to dealing with this situation is not desirable, but it can ensure that there is no pot. But I decided not to adopt this method. My idea is to quickly analyze and migrate applications through systematic thinking. And maintain inner humility and trust in more professionals.

3. Looking back, are you there?

Five years later, although I feel that I have lost a lot of sharpness and I feel that I have become much gentler in terms of technology and communication, there are still people who think that I am a “troll”. I don’t know how big of a troll I should be in the eyes of my friends back then. When I was practicing communication, all kinds of tips were just mottos floating in front of my eyes; I thought I had practiced it, but in the end I just didn’t encounter it. Now that I have experienced everything, I understand that not every Charlie Simms has Frank to defend his crossroads, and it is not easy to protect the integrity in your heart. Even if the beef tendons are of the same quality, the taste of the braised beef made after being thawed in cold and frozen is different, regardless of the heat or the seasoning. Although it has not deteriorated, the taste is different.

In the next five years, I hope to build a good Security Architecture & Engineering team to implement enterprise security in a design-driven security manner, pay attention to the service quality of operations, and make it a continuous deliverable. I also hope to strike a balance between Security First, Cost Efficiency, and High Performance .

0x04 Future Vision of Security Architecture

Analyzing problems often requires systematic thinking, but imagining the future requires romanticism. In the past, when learning Machine Learning/Deep Learning, I did not understand the design of neural network layers and was pessimistic about parameter adjustment. Gradually, I only used it as some application tools migrated to the security field, such as webshell classification using CNN, WAF with LSTM, etc. The first time I saw the application of machine learning technology in commercial products was Radware’s anti-D product. But with the development of ChatGPT, B-level parameter models have emerged. After trying to do some prompting engineering in questioning scenarios, I began to tend to believe that the future of security will be in the form of AI-Powered Security .

Especially for some of the job functions provided by the architects mentioned above, a large part of the security consulting and security training services can be achieved by designing prompts.

In the above figure, I divide the prompt design into several parts ( Chatgpt: taking the above prompt as an example ). The first part is the basic settings, where you can configure various basic parameters. The second part is the prompt itself, which is divided into several parts:

Instructions (what role you play and what abilities you have)
Input (tells what the user might enter in subsequent questions and answers)
Domain/Context (Context of a specific scenario // If you write a specific scenario for code analysis, it will be better to use it)
Output (output content and format)
Tricky (It is said that adding words of pity and praise can get better results)

After frequent use, you will find that the efficiency and professionalism of Prompt designed for specific scenarios are no less than those of junior security architects, and in some aspects, they are even better than manual work. Especially in the dfrat stage, it can save a lot of manpower. The future of security architecture will rely heavily on AI, which may have unexpected effects for some small companies. Similarly, security research on AI itself will enter a new stage. Whether it is Prompt’s jailbreak protection, the security of the privatization model itself, the poisoning of training data, etc., a new set of architectural solutions will be formed. For example, Google’s current SAIF framework.

0x05 Summary

Security serves the business, which actually corresponds to the security architecture, that is, the security architecture serves the business architecture and IT architecture. However, for various reasons, the business and IT infrastructure cannot adapt to each other, and at the same time, IT and security cannot adapt to each other. This means that there was once a scenario: some people successfully avoided the best solution and obtained the complement. This then caused new operational problems, and so on. Looking at the changes in the form of architecture and the changes in security design, the principles and development context are clear. Almost all security problems can be solved by technical solutions, but often they are not solved by technology. What does this show? The reason why I summarized this article on architecture (originally intended to be named “My Enterprise Security View 2”) is that in the past year, I have had unprecedented self-doubt about doing architecture, and even for a while I couldn’t convince myself. Although I also know that there is not only one way to solve the problem, and although I also know that few people really care about whether it is done well or not. But it is inevitable to be decadent. The GAP between design and implementation is really outrageous and beyond imagination in some environments.

Let me tell you another communication case, from my own experience. When you put forward a solution in the email loop, others will directly skip your email and continue to “discuss”. When you replay all again, others will just skip your email again in their replies, and so on and so forth, exhausting. Although I think I have done my duty, my leadership has been completely consumed by this incident, and my spirit for the whole day has become worse. I never reject learning, whether it is learning communication or learning technology. But when you find that the situation has not been eased between advancing and retreating, but the other party has become more aggressive, you don’t have to retreat anymore. I would like to call it “Think twice but not acting”. Of course, I have thought that it is not a bad idea to be so confused. But after only half a day, I was ashamed of my idea again. At that moment, I extremely doubted whether it was meaningful to do architecture. Often you think that others don’t understand security technology, but you don’t know that others laugh at you for not understanding the ways of the world.

As an architect, you need to keep practicing between simple design and complex implementation. Stay humble and avoid arrogance. A friend said: “Sometimes the architecture makes some seemingly self-conscious and smart designs, but in fact it is not very useful.” He called it “architectural juggling” , and I use it to remind myself to avoid juggling. Finally, when it was almost time to get off work, I asked my boss what a business-driven report was. The boss smiled and said: “Have you saved money for the company? Have you made money for the company?” Later, it was discovered that for commercial companies, business behaviors that are not for profit are considered to deviate from the essence and basis of the company’s existence.

“there is one and only one social responsibility of business — to use its resources and engage in activities designed to increase its profits so long as it stays within the rules of the game, which is to say, engages in open and free competition without deception or fraud”. — Milton Friedman

PS: Outline for October, started on December 9th, finished today. I found that there is still a draft in April about payment architecture, and there are still two books that I haven’t finished reading in this year’s plan. Time really waits for nostalgia, which is one of the signs of getting old.