Soft audit Checklist・No11: Security Requirements Management Technology
The fourth requirement management checklist is security
In this article, we will introduce each item of the audit checklist used for software development audit . The audit checklist is divided into ( 1) development process, ( 2) requirements management, (3) testing, and (4) design and implementation. In this article, (2 ) individual items of configuration management in requirements management are introduced. (The checklist itself can be found in the article on Software Audit Practice / Checklist No. 8: Development Technology / Requirements Management (General Management) , so please refer to that.)
What we see in software audits is the security of software installed in products, which is mainly the confirmation of vulnerabilities.
News about the server war has begun to appear on general television and newspapers, and interest in security has recently increased in Japan as well . It’s a good trend, but unfortunately it’s more than 10 years behind the world. However, in today’s world where everything is connected to the Internet, embedded software also needs to have strong security measures.
However, security is not directly related to the functions and performance of the original device or device, so if you do not decide exactly what level of security measures should be adopted, you will be in trouble at the development stage. increase. Therefore, it is important that the requirement specifications also include security requirements as specifically as possible . The number of cases is still small, but I think it is necessary to increase the number of check items for this security in the future.
The items in this checklist used in the software development audit are related to the security of the software installed in the product. This is a check to see if there are any vulnerabilities such as the shipped equipment or equipment being hijacked or used as a stepping stone when attacking others.
When it comes to security, the general public often talks about how to work, not the security of such products. For example, the topic is whether the personal information of customers and employees in the company may be leaked or stolen. This kind of security is about how you work and the rules.
Of course, this security is also important, but the software development audit focuses on the software installed in the product, so the checklist items are also about the security of the software installed in the product. Security about how to do things requires something like another security audit, but it is out of scope for software development audits. In the checklist, the item numbers start with SE-, so let’s look at them in order.
[Item number: SE-01]
The security measures for software installed in products are basically how to reduce software vulnerabilities . If vulnerabilities remain, there is a risk that they will be attacked and the system will be hijacked, important information will be stolen, or functions will be stopped, allowing various inconvenient situations. There are two main ways to reduce vulnerabilities. The first is to investigate known vulnerabilities and confirm that they are not lurking. And the other is to check if there are any unknown vulnerabilities . Both are methods for finding vulnerabilities, but the approach is different . Therefore, if security requirements are written in the requirement specifications, whether to take measures against known vulnerabilities or unknown vulnerabilities alone, or whether to take measures together. It is important that a basic policy regarding security measures has been established. Carefully check if there is a policy for such security measures .
[Item number: SE-02]
In order to take countermeasures against known vulnerabilities, the method of taking countermeasures will change by further classifying the known vulnerabilities into two categories. The first is a known vulnerability that has already been published , and the other is a known vulnerability that has not yet been published .
Why is there public and private information? In fact, the vulnerability is a security hole suitable for attacks . If the existence of a vulnerability is known , the attacker, that is, an attacker who wants to take over the system or steal information, exploits the vulnerability and launches an attack . So basically, if you find a vulnerability, you need to fix it before it becomes known to the attacker. Therefore, the discovered vulnerabilities will be kept private until many manufacturers take countermeasures, and only the manufacturers with the vulnerabilities will be notified as information.
After the vulnerabilities have been addressed in the products of most manufacturers, the vulnerabilities will be disclosed and preventive measures will be taken to prevent the same vulnerabilities from being created in future products. As for the information of such known vulnerabilities, since the disclosure / non-disclosure of the information is controlled , the method of dealing with it depends on which vulnerability information is used.
Therefore, it is necessary for the requirement specifications to describe specific requirements such as which vulnerability to use and how to obtain vulnerability information. Pay attention to such points and check with the checklist. Then, when using information on known vulnerabilities, it is decided how to obtain specific information such as where to obtain the information and how to use the information for product development. Must be. We will confirm from the perspective of whether such points are written in the requirement specifications.
[Item number: SE-03]
Another of the vulnerabilities is an unknown vulnerability . The possibility that an undiscovered vulnerability is lurking somewhere in the software source code cannot be eliminated. Various cyber attack units in each country continue to search for vulnerabilities hidden in various software that have not been found yet. Then, if a new vulnerability is discovered , we will prepare for an attack method that exploits the vulnerability, and then gently hide the attack method for future use . This is because once it is used as an attack method, it will be known that the vulnerability exists, and countermeasures for the vulnerability will be taken.
Since itachigokko continues to discover vulnerabilities and take countermeasures against them, it is also necessary to investigate whether unknown vulnerabilities are lurking there when developing software. There are various methods, such as using a tool or having an expert attack, but each method costs a lot of money. Therefore, if you do not clearly describe the level of investigation for unknown vulnerabilities in the requirement specifications, the actual work will be difficult. We will check such points while paying attention to such points.
Next to maintainability is security
After checking maintainability, we will introduce the items to check about security in the next article.