“Build Security in your DNA”, also “BSI” in short, is a new software development methodology with security built in your development process. As its name indicates, various security practices are built in each stage of the software development. By introducing those security practices as early as possible, security feedback is acquired rapidly, security problems are prevented from happening. Before getting into details of BSI, let’s look at a case to see the security dilemma faced today by enterprises.
Company A is an Internet financial company planning to build up its own P2P platform, which requires core business development of a web app, a mobile app, a web-based business management system and backend services, the architecture is shown below. As the date of product launch has been fixed, the development team has only three months to finish this task.
P2P products involve large-value fund disposition and a large number of user privacy data. Those data always vulnerable to hacker attacks. It is clear to Company A that once a security incident happened in their system, they are bound to suffer from property losses, be entangled in legal disputes, and their reputation will be in tatters.
Alarmed by those severe consequences, Company A are very concerned from security aspects. They have developed security regulations such as security coding specifications, security testing specifications and information security specifications, setting up strict punishment rules, and included a number of security aspects in the performance review. Employees of Company A also recognized the importance of security. However, because of the short project duration and heavy development work load, it is already hard enough to catch the release date. In addition, team members have very limited security related skills. So the security of the system always draws very little attention.
It was nearly the launch date when the core function of this P2P product was rushed in. As Company A has its own security team, an internal security review of the system has been carried out and some security problems of different risk levels were found. Although the potential security problems were identified as the results of the process, there was quite limited time left for the development team to fix the vulnerabilities. Thus, the team decided to fix the vulnerabilities of high risk levels, and the remaining issues were postponed after the launch.
As expected, the live system was attacked by hackers. However, facilitated by the Incident Response Plan (IRP) developed in advance and skilled operation supervision, the team took actions immediately and fixed the security vulnerabilities explored by hackers in time. In addition, the market department handled the public relationship quite well in dealing with this crisis. Therefore, there were no serious financial consequences.
Although company A may sounds fictitious, the case is commonly seen in our real world. Measures taken by Company A, though had certain effect on security development, provided only temporary relief for such cases without reducing the number of security vulnerabilities, and the security incidents still occurred from time to time because the root of security problems had not been resolved fundamentally.
The first reason of the above problem lies in the late arrival of the security review, which is adverse to in-time vulnerability scan during development. This P2P product was developed within a short period of three months, and the security review was done after the core functions being developed. The vulnerability fixed by the development team based on the security report, though seems rational, was too late in fact. Security problems, similar to business deficiencies, require higher cost for fixing once detected late. In most cases, those security reviews are always arranged in about one week before system launch. Therefore, as the launch date is around the corner, time for vulnerability issue fixing is limited, adding great workload and pressure to the team.
The second concern is the long feedback cycle. In spite of many automatic vulnerability scan tools can be adopted to speed up the progress, a meticulous and thorough security review usually requires security teams or security experts one week or even several weeks. Development team have to wait for the results of a report to carry out the later work. Furthermore, the greater the project scale, the longer the review time it requires, let alone the repeated security review on vulnerability fixes based on report. The security review, due to its expensiveness respect to time cost, is usually performed only once usually before the formal launch, which means the development team will get only one feedback on security in the entire development life cycle. However, application changes constantly with the addition of new requirements and adjustment of the old functions, during which new security problems brought in and unfortunately will seldomly be discovered in time.
The third issue is passive receiving of the security problems. In the above case, Company A relies on IRP, tight operation supervision and even security review to expose problems. However, all of those are remedial measures to security problems, by which only detected problems can be solved. In this circumstance, the development team falls into a position passively receiving with security problems, no one knows whether and what security problem(s) that may still exist and when any problem may be explored.
Moreover, there is a common misconception that security team shall only be responsible for system security and development team shall only be responsible for implementing business functions. This leads to a contradiction: development team though admit the importance of security, however, consider the security team disrupting project progress and delaying the delivery. On top of this, lack of security skills within the team members is also a cause of the misconception.
Finally, the effect of the above traditional security practices is worth discussing. By adopting security review, certain problems can be found. However, limited by ability of the security team, not all security problems of system can be found, resulting in a very embarrassing situation: security of applications through internal review still cannot be guaranteed, so the company has to hire a third-party company for a second review, which not only discourages the security team of the company, but also leads to serious resource waste, needless to say there is no guarantee that all security problems can be found via penetration test conducted by the third-party security companies. Because they are unfamiliar with the business of the company and the security problems concerning the business logic cannot be discovered. What's more, all necessary security specifications and codes of conduct set up by the company exert little effect due to the poor implementation, as most employees are not familiar and don’t understand their contents. Once a number of security related items are included in the employee performance review, the development team and security team are placed in oppositions, resulting in the development team prone to conceal security vulnerabilities rather than expose and fix vulnerabilities as early as possible.
In response to deficiencies of the above measures, BSI has been formed: introduce proper security practice(s) in each critical stage of the application development; shorten the feedback cycle of security issues by taking advantage of the automation techniques; take the initiative to anticipate and resolve security issues by means of threat modeling, security driven development, etc; reduce the burden caused by the separation between the development team and the security team, and improve the efficiency to detect and solve security issues as a whole team.
BSI is not a disruptive innovation. Early in 1980s, a similar concept was proposed for spiral development model. In spite of this, till today, there are few teams have deep understanding of this idea and put it into practice. If they had adopted BSI, there would much fewer appearance of those painful security incidents reported by the media.