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

0x02 Occupation-related

  • 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

  • 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

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

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