Security Architecture I — Application Part

As time grows, the way things are looked at can also change. Looking back at some of the ideas and details of the previous security architecture review, compared with the present, there is some reflection. Record here for the benefit of the reader
— This article was written in Chinese on November 20, 2019

0x01 The architectural foundation

You may find the following list a bit of a blur, but from experience, a competent security architect does need to have these capabilities. Of course that doesn’t mean you need to have all the knowledge in the first place. But if the security architect you encounter doesn’t have that knowledge and doesn’t have the desire to understand, he won’t be a qualified security architect to a large extent. Of course, these are only a family’s words, right for reference. If there is a difference, you can also exchange e-mail.

0x02 Occupation-related

• Basic knowledge of software engineering, such as agile development, software development processes, etc.
• Basic architectural knowledge, e.g. SOLID principles, component architecture, microserver, SOA, etc.;
• Experienced basic security knowledge and risk identification capabilities, e.g. network security wind identification and solutions, SDL solutions, etc.
• Master the relevant product knowledge involved in basic security, e.g. waf, hids class solution implementation, etc.
• Experienced security research and development knowledge, e.g. OWASP TOP10 in specific programming language-reinforced coding implementation;
• A security architect would do well to have the ability to lead your team in developing security tools, but this may not be critical based on your needs within the enterprise.

0x03 Enterprise-related

• Internal research and development system processes, such as: language stack, release cycle, release system, basic class library, middleware, etc.
• On-premises infrastructure deployment, e.g. network planning, server location, VPC division on the cloud, etc.
• Internal organizational structure, e.g. X-side research and development Leader, project manager, product owner, etc.

0x04 Security architecture

1. Solution

Solutions focus on a number of issues, from evaluation to design and implementation and operation. The complete solution design process is not intended here, just the technical focus of the security architecture when outputing the solution.

Architecture is a big level, in addition to architectural design principles, the security architecture itself depends on the application architecture, network architecture, business architecture. This means that there are at least three levels to consider, infrastructure, applications, and business. This is almost the interaction involved when users access the business through an application on top of the infrastructure. This application may be a web application, or it may be a pc application, or a Mobile application ,etc. (generally external is an application, but the internal is actually composed of several applications). The security architecture is concerned with architectural security both ends and between them. Common concerns are the following:

• The business interaction process is really about seeing what features are provided, what data is provided, what logic is provided, and so on. For example, from the business level to see whether it will involve sensitive data, whether the data involved has been processed, etc.
• Applications and middleware, applications and middleware are the concrete embodiment of the whole business, but also the focus of application security and data security concerns, from security research and development training to security package SDK, from code white box scanning to card release, data production is how to provide applications, how to be applied consumption, how to achieve the corresponding permission control and so on;
• The underlying network architecture, how a request arrives at the service from the client, and which routes the service routes through. This can be a problem, and it’s important to note that the network architecture diagram that the software architect gives you in your review documentation may only be part of what he understands, and more often than not, they don’t seem to care;
• Physical deployment status, IDC or cloud, blade server or ECS? The words on the cloud are IAAS, PAAS or SAAS, and different forms of deployment focus differently. as well as specific ACLs, VPC division, network planning. The location of safety products and so on need to be considered;
• Global stability, whether to set and be able to follow SOP, grayscaness mechanism, rollback mechanism, etc., to ensure that in the event of an error can narrow the scope of damage, and quickly recover the problem, in addition to considering the safety product itself SLA, as well as the introduction of security products for the entire link after the addition of how many ms delay, whether it is acceptable and so on;
  In fact, these are concerns on the surface, each part in addition to the general consideration point also need to combine the enterprise’s own situation, depending on the research and development system, operation and operation system.

2. Architecture review

When it to security architecture, it is inevitable to say another major output point for security architects: architecture review. So the first thing we need to know is: What is the meaning of the security architecture review? The original purpose may be to identify potential threats early in the project and propose a corresponding solution. What about the second? On the other hand, it can also be seen as an attempt to increase the influence of the security team. Of course, high-quality output is to increase influence, improve the voice. The usual words are just brushing down the sense of being. The deverity of the people is a problem since ancient times, even in the architect level, front and back end of the field, network field, database field and security field students may be self-professed “high” situation. Of course, many times it may also be due to the inability of the security architects involved in the architecture review to get to the point, the lack of a global perspective, and some of the preparatory knowledge mentioned earlier, which may also make the security department unsuitable for other architects to recognize. Of course, the security architect himself has a part of the problem, the focus of the review is too arbitrary and not sufficiently structured, or there is no unclear business characteristics and not fully understood in advance so that communication problems lack of relevance and so on.

From the SDL perspective, if there is a problem with the architecture review, that is, the first step of the SDL is not done well. Once you know what the architecture review is for, it is important to remember that while implementation may not be possible at this stage, it must be presented at the architecture review stage. So how do you move the architecture of your project in the desired direction? How can we have a better output? Let’s look at the next HOW section based on the WHY, WHAT, HOW steps:

1. Design domain risk checks based on PRD documentation and threat modeling for large projects
2. Export safety research and development and safety testing knowledge to research and development students and test students respectively
3. Confirm and output solutions or mitigations during the architecture review session
4. Introduce relevant security products and provide them in the form of continuous deployment
5. For the output of the scheme for closed-loop inspection, tracking the relevant landing and vulnerability

Security architects are more focused on the security domain than architects, which doesn’t mean basic architectural knowledge is not required. So when doing the architecture review, the most original and most direct understanding of the business side is the corresponding architecture diagram in the PRD documentation (note here the difference between the architecture diagram provided by the business and the global architecture diagram):

• Business area diagram
• The system depends on the diagram
• Data flowchart
• Physical deployment diagram

Through the above schematic diagram can be very direct understanding of business logic, physical deployment, data flow and so on, skilled security architects can more directly identify the corresponding problem points. But to achieve the so-called confidante, a hundred wars, still rely on the experience of stepping on the pit. (For example, using Alibaba Cloud ODPS services for permission control in a business logic architecture may seem secure, but it’s easy to ignore whether the data has been marked.) If there is no marking, then this ODPS-based data flow permission control has some defects. After understanding the overall architecture, the threat modeling step should be to first decompose the application, discover external dependencies, find entry points, analyze what assets the service uses, the resulting attack surface, analyze the corresponding data flow, and so on. (You and his mother are really a talent, like a textbook). Of course, this is only the theory, or to refer to the design domain, and related Checklist. From system functions, system deployment, system dependencies and so on to analyze threats, threat modeling since ancient habits STRIDE, not much is introduced. So how do threats priorities? Specific reference can be made to Microsoft’s docs.

However, even if a review mechanism can be established for genuine compliance, there may still be a lot of work to be done on the architecture review in large companies.” Business iterations change very quickly, there are several architectural reviews every week, how to improve efficiency?

Start with automated automation, such as the deployment of security products, and black-and-white box scanning. Second, the ability that cannot be automated is transferred, and the related capabilities are transferred to the test department, the research and development department, so that it has safety attributes. Let the research and development understand the use of security packages, and have the ability to write security code, while allowing the testing department to have some basic penetration testing capabilities. Finally, the ability to neither automate nor transfer precipitates the knowledge base and case base (Checklist of the pit-stepping experience). This is the first step, and the second step is to track the results, build positive feedback based on the results, and drive or push other teams to continue to follow.

Of course, there are some details not written, and the relevant architecture review form has not been posted, so how in the end can be a qualified security architect? Believe that your heart has its own answer. And when you have that vision, a lot of things don’t work that their own.

0x05 Summarize

Security architecture is not a one-off, enterprises can not rely solely on penetration testing to improve the construction of security defense. Under the premise of keeping up with technological progress, it is more necessary to be able to accurately distinguish whether to hype or follow the trend. As an important player in enterprise security, continuous learning is an important aspect that cannot be ignored while having the ability to do so. It is hoped that there will be more qualified security architects among future security industry practitioners. As a child in the security industry, there are still many places to learn. Come all the way, thank you. Late at night, shelving the pen.