As security has received more and more attention, some security-related theories (such as <u>BSI</u>) stand out. Although these theories have been proposed for some time, they are rarely seen in the
development team. Successfully applied. Considering the difficulty of its implementation on the ground, many enterprises retreat due to difficulties, so do these security theories really help our software security? Can security practices be implemented?
Fortunately, I had the opportunity to go through the process of "from completely without security practices to BSI" in a mature agile development delivery team. We have also encountered many difficulties, but in the end we have been recognized by customers and successfully managed Security practices have been extended to the entire team, so I want to share with you how we put security on the agile team, and hope to give you some help. In this article, we will take Web system as an example, but some of the practical practices are also applicable to non-Web systems.
Why is it difficult to implement safety theory?
Combined with the understanding of some teams, most of the reasons come from the following three aspects:
Think safety is not important
I think that security is too difficult and requires a very wide and deep domain knowledge, only professionals can do it
I don’t know what process should be used for security
So for the first point, because I am also a member of the delivery team, most of the
software development teams I observed, whether business analysts, developers, testers, experience designers or project managers, few people really Taking "security" as a very important thing, especially in the case of relatively high delivery pressure, we will abandon the investment in security and spend time on user functions that are easier to visualize. Security is often like a fire extinguisher. If there is no fire, we will not even feel its existence. So, is safety really important?
Think about it differently. If we are users, which of the following two options will we choose?
System A: The design is perfect, there are almost no functional defects, and the performance is also great, but without any security-related protection, the user's sensitive information is easily leaked;
System B: The design is relatively poor, there are some functional defects, and the performance is a little bit worse, but a lot of security measures have been taken to ensure the user's data security;
I believe that almost everyone will not hesitate to choose the B system, unless this is a system that does not have user sensitive data at all, and does not need security at all (what is the use of such a system?), so as long as we put ourselves in the product From the perspective of the manufacturer, not the perspective of the product manufacturer, it is easy to understand and recognize that security is a more important factor for software systems than functions, and security is the soul of software.
So for many teams that have deeply understood the importance of security, why is it still difficult to implement security theory? Most of the reasons come from the second and third points mentioned above. One is that technology is considered to be a difficult field and requires professional security personnel; the second is that the process does not know how to proceed; from these two From a perspective, "security" requires huge investment, so many teams are discouraged. Is security really so difficult to land? Next, I will briefly introduce some Web security knowledge, and then give you an answer through the landing process of my team.
How to make security in the agile team
What is web security?
The so-called
Web security problem refers to a series of problems that an attacker can gain access to the Web system through abnormal means, thereby destroying the behavior of the website, stealing and even modifying user data.
So why can an attacker gain access to the Web system? How big is this chance? If the possibility is very small, do we not have to spend too much energy on safety?
Let's take a look at the composition of the Web system. The simplest system has at least these parts:
The browser sends a request to the server, and the server responds to the browser. The server queries the database, and the database returns the result. In this process, the web programs we develop inevitably have security holes, and even the programming languages used by our
development systems will have security problems. During development, we often refer to some third-party tools and components, and the security of the third-party cannot be guaranteed. Even the protocols used in the data transmission process and the operating system itself have security issues. So it is conceivable that if we do not do any security precautions, then every software is a very fragile system and it is easy to have security problems.
Common web security issues
Since so many links have potential security risks, how do you proceed? You can refer to <OW>OWASP TOP 10</u> to get a general understanding of the most serious web application security issues.
Status of agile development model
We are a team that has been implementing agile development for seven years. There are a total of more than 50 people. It is divided into different Feature groups for daily work. Its agile development model is very mature. The Feature team I am in has 6 developers. 1 A business analyst, a QA, the delivery model of each of our teams is like this:
Taking <u>user stories</u> as a unit, all user stories will go through a life cycle from analysis to final presentation to customers. Multiple user stories will form a Feature, and then we will conduct a functional test of Feature to customers. Show the entire function, and finally before the release, customers will invite third-party professional security companies to do penetration testing, and then find our development team to fix security defects.
So what's wrong with this approach?
Goalkeeper mode, safety test is very lagging
Very limited time to fix security issues
Only a few people pay attention to and understand safety
Rely on independent penetration testing
The so-called goalkeeper mode refers to keeping all problems and risks at the end and relying on a small number of people to protect them. In the development mode at that time, the third-party security company was the security goalkeeper of our system. As you can imagine, if our The team does not have any knowledge of security. The security issues introduced in the development phase of the user story cannot be discovered until the release. The security test is very lagging and the feedback cycle is particularly long.
In addition, when a third-party security company finds a problem, the time left for our team to fix the problem is particularly limited, because penetration testing is the last stage before release, and long-term repair will lead to postponement of the release, so it often leads to security fixes with patches Way.
And apart from a handful of developers who have fixed security flaws and have a little understanding of security, no one in the team cares about security.
The biggest problem is that all security precautions depend on the final independent penetration test. Although it is a professional third-party security company that performs penetration testing, they have professional security knowledge, can find many public security issues, and can also provide professional and authoritative security reports, but this way of penetration testing has This is a fatal weakness. They don’t have enough knowledge of business, and it is difficult to find business-related security issues, and this type of security issues account for a large proportion.
It can be seen that the current status of this
agile development model is: trying to inject security into an already formed system.
Safe landing
So after understanding the problems of the previous development model, security is so important, customers and teams hope to change this situation, improve the quality of security, reduce patches, and let everyone care about security, but we are worried that security requires huge investment , Will affect the release of functions, so we decided to choose a Feature group as a security pilot, with a target period of one month (our release cycle), observe the input-output ratio, and then decide whether to implement it in the entire team.
First of all, our group began to study BSI. We believe that it conveys these ideas:
Integrate security into the entire software development process
All team members are responsible for safety together
Safe design and implementation of an ongoing process
So in a team with little security knowledge, how to apply the above concepts to the team? We have encountered many difficulties, such as:
I don't know how to combine security with daily development
I don't know how to write security requirements and how to do security tests
Received a lot of safety training, don't know how to start
Lack of professional awareness of security and lack of confidence in
security development and testing
Don't know how to meet customer expectations
Analyzing these difficulties, we began to take a difficult first step.
First of all, the core members of the team (including business analysts, developers, testers, technical leaders), and we invited a security expert of the company to help us solve the problem, everyone <u>brainstorming</u> With reference to OWASP TOP 10, combined with the security issues that have occurred in previous projects and an in-depth understanding of the business field, try to summarize our own security issues and associate them with OWASP TOP 10.
It can be seen that the ten items we have summarized are not as simple as changing the order of OWASP TOP 10. We are reorganizing and organizing them in accordance with business needs, such as <u>Sensitive Data Exposure</ u>, we will divide it into four categories (1.Authentication, 2.Error Handling, 3.Code Leak, 4.Cookie Management) in combination with the project. The reason why it is so specific is because our own TOP10 is more Close to the realization. In addition, we also added examples on the project for each item as a reference, so that everyone in the team clearly knows what our own TOP 10 is and the security issues that may arise in business scenarios.
Then we added the project-specific TOP 10 as a template to each user story, which has two benefits:
First, business analysts can use it as a reference to write safety acceptance standards when writing user stories;
Second, if it is difficult for business analysts to write security requirements without security knowledge, we can use them directly as security requirements to prevent omissions.
Of course, this is not enough. The more ideal situation is that in the stage of requirements analysis, business analysts and customers should try to refer to some basic principles, such as the principle of least authority, to determine and write more accurate safety acceptance standards . As shown below. It can also allow more people to participate in the requirements analysis phase and analyze more comprehensive security requirements through <u>threat modeling</u> and other means. Of course, this requires our business analysts to increase their safety-related knowledge reserves, and we are also working in this direction.
