As security problems arise inevitably during application development, most enterprises will arrange security review before bringing an application online, to understand the security of the application through the security report derived from the review and then make the next move. A typical example is that security review is undertaken by the enterprise’s own security team, as in the P2P case herein. Or the enterprise hires a third-party security company to carry out penetration test, who will list the security vulnerabilities found in detail and give suggestions for fixing such vulnerabilities in the security report, the development team will fix such vulnerabilities based on the report, and the decision makers will decide whether to bring the application online based on the report, the fixing of problems and other factors.
Some enterprises establishes an emergency response mechanism for security incidents, so that they can actively take such measures as service switching, immobilizing the scene, collecting evidence, making investigation and publishing safety announcements according to the emergency plan if a security vulnerability is found by attackers or reported by white hats after being brought online.
No matter how many security problems can be found by penetration test and whether the emergency response mechanism is designed complete and highly efficient, such practice is within the range of passive response after the event, namely that some remedial measures are taken to find the security vulnerabilities and mitigate damages after the vulnerabilities have existed for a long time and even have evolved into security incidents. This is just like a person taking regular physical examination each year finds from the medical report that he has got a disease, and then hurries to take medical treatment. In fact, many diseases cannot be found through physical examination, and hence severe disease will be highly probable if a person only goes to the hospital for examination and treatment when he feels extremely uncomfortable. When a disease has formed, either physical examination or emergency treatment is a remedial measure after the event.
BSI advocates active response to security issues through analyzing potential threats, making clear security needs and implementing the way of security test-driven development, possible security problems can be foreseen during application development and thereby prevented by certain measures in advance, leaving no chance for security vulnerabilities to take root and sprout. For example, by introducing threat modeling in project requirement analysis and architecture design, it can be achieved to actively analyze security threats confronting the application while analyzing business requirements and designing system architecture, formulate countermeasures and further transform them to security needs; In coding practice, developers can prepare security test cases corresponding to security needs when developing a certain function, and even can strengthen this step. Therefore, security test-driven development can be achieved by preparing security test cases before writing code. Compared to traditional security review and emergency response, those practices advocated by BSI are carried out before the generation of security vulnerabilities and are active responses to security vulnerabilities.
If we conduct a survey on who should be responsible for a product’s security, it can be foreseen that most teams will consider this as the testers’ duty, for testers carry out various tests on the product and accordingly should perform security test, by which security problems of the product can be found. If there is a special security team in the enterprise, the survey result is likely to change to this: the security team should play a leading role in and shall be responsible for ensuring product security, and the reason is quite simple: isn’t it the innate duty of a security team? But unfortunately, this is in fact a misunderstanding.
Once the whole team considers that the responsibility of security shall be borne by testers or the security team, such an atmosphere will be formed: there are people responsible for security test anyway and we just need to make modification when they find problems. Many disadvantages lie in such an atmosphere. First, it is very passive and can easily give rise to a situation where people stand on opposite sides; second, looking for security vulnerabilities is almost an insurmountable task for most testers; finally, such an atmosphere goes against the establishment and improvement of the team’s security capability.
Passiveness
If the team considers testers or the security team plays the role of a goalkeeper, such a misconception will emerge that there are people responsible for security test anyway and we just need to leave this work to them. It seems to be trust in other team members but in fact is a negative attitude toward security problems, which will in time result in relaxed vigilance during the development. In this way, some security problems which could have been found early and eliminated will be hidden in the product quietly, and when they are finally found, it may be too late, or high cost of fixing must be paid or they have been utilized by attackers and resulted in even greater loss.
Opposition
In this atmosphere, since the team considers that ensuring security is the responsibility of testers, mutual imputation and opposition may emerge between team members. Business analyzer considers that security is a technological issue and has nothing to do with business analysis, developers are unwilling to voluntarily admit that there are security problems in the code and consider it as the fault of testers who fail to find such problems, while testers think that it is unfair that they are taking the blame for developers who single-handedly cause the security problems.
Insurmountable task
It is unfortunate though true that most testers lack security skills and either is incapable of performing security test or can only perform simple security scanning with automated tools, and hence they can do nothing about those hidden vulnerabilities which require in-depth manual analysis and test, which exactly tend to be the most destructive vulnerabilities. Therefore, it is very hard for ordinary testers to find security vulnerabilities in a complete and deep way.
Security skills of the team
If a team depends on an individual or a role to ensure product security, there is a risk of single point of failure. Once such an individual or role leaves for some reason, the team will inevitably undergo great impact. Though such an individual or role can find security problems, they meanwhile constitute the bottleneck for the improvement of security capability of the whole team, because the team depends too much on them, who discover and solve all security problems, and hence other team members will think that it makes no difference whether they have security capability or not and then will not actively pay attention to building and improving their own security skills.
Besides, the situation allows no optimism from the perspective of security team. A great many small and medium-sized enterprises don’t really have a full-time team for application security and security review is usually conducted by the IT department as a part-time job, but as they have other works to do such as management and maintenance of the enterprise’s IT and network equipment and even product operation and maintenance, it is hard for them to conduct complete and deep security review. Only a small number of enterprises are equipped with a full-time security team, and even rare enterprises have a large security team staffed by personnel with excellent security skills. There are various factors leading to this situation, and a key factor is high human cost resulting from extremely scarce high-quality security talents in the market. However a security team an enterprise has, a vicious cycle is easy to form if product security only depends on penetration test by the security team. Namely, the development team considers that the product will be indirectly proved safe if no complaint is received from the security team who check the security at the last step, whereas the security team finds it very hard to promote improvement in security in the enterprise for the development team doesn’t consider this as part of their duty and hence lacks motivation for improvement.
Taking an injection or medicine may cure current disease, but after all, it is not a long-term solution. Only by finding ways to improve immunity can one decrease the probability of getting diseases or recuperate health more quickly.
Unlike traditional ways which highly depend on an individual or security team to ensure product security, BSI assigns divided security duties to each role in the team and lets everyone participate and jointly solve security problems. Since everyone assumes the responsibility of maintaining product security, each team member will make active efforts for it. Business analyzers will take product security into consideration while analyzing business requirements, and if they don’t have relevant security skills, they will actively cooperate with technicians to achieve the goal of clear security requirements; developers will consciously shun security risks while coding and will assist testers in product security test. When the product is delivered to the security team for security review, some vulnerabilities have already been found and fixed or even have been deliberately prevented in requirement analysis. Such a product is already considerably secure now and can spare the security team more time so that they can put more energy on looking for deep security vulnerabilities.
Through such a way of shared responsibility, some security problems will be exposed earlier and solved in time, the development team will be enhanced in internal cohesion on security problems, team members will be more willing and motivated to improve their security capability and continuously get positive feedbacks, and meanwhile the security team will collaborate better with the development team. In this way, a virtuous cycle will be gradually formed.
Security is forever something every company must pursue and is especially of vital importance in the age of Internet. The CEO of one of the largest banks in U.S. once said that he was only worried about three things which would destroy his bank overnight: “aerolite from the sky, nuclear weapon and Internet security”. After all, most enterprise-level software has already connected to the Internet and this trend will surely keep going in the near future. So you can imagine the security challenges that companies are facing. Two main factors affecting security are the human and the system. Human security is a complex matter, whereas system security is an engineering matter and can help reduce security problems caused by human. So system security shall be given priority. The key point of system security is developing a secure system, and hence how to develop a secure system is the premise of system security, without which system security is out of the question.
BSI is aimed at ensuring that the software system is secure enough in both business and technology aspects before release by adding various security practices in its development process. Currently, since most software systems are not developed in a one-time way but are subject to subsequent maintenance and development after delivery (e.g. fixing bugs and adding new functions), BSI is to be implemented not only in software development process but also in subsequent maintenance process (as some software systems are not maintained and developed by the same team). However, it’s not that the software system is free of trouble after implementation of BSI, because post-delivery operation and maintenance are also very important. Even for a very secure software system, without proper operation and maintenance, many security problems may emerge, such as those caused by deliberately damage from internal personnel. Therefore, a software system also needs a set of security operation and maintenance, but as it is beyond the scope of this article, no further discussion is given to it here.
It cannot be denied that adopting BSI surely will increase development cost, such as costs of business analysis, of security scanning built on CI and of review of security scanning result. But compared to such costs, more attention should be paid to the loss caused by security vulnerabilities of the system which are found and utilized by hackers. Therefore, the reasonability of BSI can be understood by comparing the increased cost arising from security development with possible future loss caused by security vulnerabilities. If the loss may be greater than cost increment for a system, such as financial systems for banking and insurance, BSI shall be used to reduce vulnerabilities and loss; if the loss may be less than cost increment for a system, such as a blog system, the loss of which cause by an hacker attack is fairly small, priority of BSI will not be high (on the premise that the loss of customers using this system is not cared about).
Till now, there is a question not mentioned yet—how to measure BSI. For a software development team which plans to implement BSI, putting aside the operation-related matter of how to implement it, enterprise management must first be concerned with how to evaluate the team’s BSI maturity, how to define it and with what criteria. This part will be specially introduced in follow-up articles.
There is no absolute security, and thus BSI’s ensuring security is also relative. But for software systems which serve more and more complex business and become bigger and bigger, the secure software development process of BSI and its practice methods will surely reduce security risks at the source, greatly lower the possibility of hacker attack, and thereby significantly decrease the loss caused by security problems after the system has been put into operation and enable the system to be fitter for survival in the major wave of the Internet.