Of all the activities in the software development life cycle, this is probably the one that may not seem very important. Unfortunately as members of the security community we have all too often seen organizations fall victim to issues that were fixed in other parts of the organization - sometimes even within the same team! While this is embarrassing, it is often a symptom of the lack of effective knowledge management. Valuable lessons can be learned from the experiences and mistakes of others both within the same organization and externally. However, most development teams have no way of drawing these lessons and it is therefore vital to share this information through an appropriate channel. While training is certainly an important aspect in improving overall security consciousness among developers, it is also important that developers have access to a central repository and portal for providing them with guidance on a day to day basis. This is especially important in large development organizations.
In our experience, the medium that lends itself best to this form of information sharing is a software security portal. Such a portal would provide a number of key functions such as:
· Document repository to house all of the policies, methodologies, process documents, guidelines and best practices developed as part of the security enhanced SDLC process.
· Threat modeling artifact storage so that incremental threat modeling can be easily performed after the initial effort of building the first threat model. Moreover, this is especially significant since it is not uncommon that a number of the applications within an organization or group are architecturally similar in nature and technology and hence share a similar attack surface. Thus the threat model for one such application can serve as an excellent building block for the others.
· Metrics reporting to provide the stakeholders with measurements to justify the return on security investment. These can include statistics from actual measurements within the organization on effectiveness of the S-SDLC process, improvements in productivity, decrease in security vulnerabilities, and other data points of interest.
In addition, another tremendously effective tool is an organization wide knowledge sharing Wiki. Through its support for effective content management and quick refactoring, Wiki technology is an excellent model for collaboration between large numbers of individuals. One has to only look at the success of wikipedia.org at building a collaborative online encyclopedia to understand the potential contained within this technology. Having been in the field working with development teams it is quite common to observe that a number of groups and development teams are already using Wikis within their teams to document design and architecture as well as lessons learned from prior bugs and testing efforts. When this is the case extending such a Wiki to encompass the software security drive is not hard. Further, there are a number of free and useful Wiki solutions available such as the very popular MediaWiki .
A software security Wiki would be a central repository providing readers with a single and common location where they can find information covering aspects such as:
• security architectures that are in use within other groups
• thoroughly reviewed and tested code snippets for commonly used tasks
• links to additional information about software security on the Internet as well as,
• lessons learned from previous security issues identified in applications during internal testing or third party reviews.
We strongly believe that by encouraging such sharing, development teams and organizations can recognize tremendous gains by the wide distribution of best practices, prevention of the repetition of similar mistakes, improved productivity through code and knowledge sharing, and overall better software quality.
Especially when considering the disclosure of information about vulnerabilities onto such a knowledge sharing platform, some considerations are vital. Firstly, such sharing must only be considered after the issues in question have been fixed and tested in production applications. This will mitigate any risk of the issue being exploited. Special care must be taken when the vulnerability affects other applications or if it exists in a product or library that maybe shared. The bottom line is the risk of disclosing the vulnerability too soon and before affected applications have been thoroughly patched must be weighed against the benefits to be gained by the knowledge sharing. Secondly, for each issue it is important to sufficiently anonymize specific data. The aim behind doing this is to avoid any kind of finger pointing that could have a negative impact on morale. On the other hand all such sharing must be performed with a positive outlook of learning from past mistakes rather than focusing on the person or team that made the mistake. Finally, it is also vital that not just the issue be shared but also if possible the mechanism used to discover that issue, the design and architectural changes and thought process that went into fixing the issue, the fix itself as well as root cause analysis covering why the issue was introduced, why it was not caught earlier in the lifecycle and if and how the software development lifecycle process and mechanisms will be tweaked to prevent such issues from making their way undetected into applications. It is off course vital to make sure that any code shared thus be thoroughly reviewed and be free from security bugs and flaws itself.
Another aspect of knowledge sharing deals with the handling of third party components. A number of software development projects these days leverage third party components (both open source and otherwise) and ship these with their applications. Perhaps the biggest case in point is libraries such as OpenSSL and zlib . While as much as possible it is recommended to use existing tried and tested solutions, it is also important to track updates and changes to those solutions. Because components such as these are used so often they are extensively tested both by the teams that produce them as well as by the security researcher community . This in turn implies that security updates and patches are being constantly released. If development teams are not tracking these updates it is quite likely that they would be distributing an old and possibly vulnerable version of these shared, third party libraries. On the other hand, the typical developer may not have the wherewithal to be constantly scouring the Internet and security mailing lists to keep track of the latest security vulnerabilities and patches. It is therefore vital that as a team or an organization a process be created to deal with this issue.
An effective way of doing this is to create a listing of all the open source and shared third party components in use across the organization along with a matrix that tracks which applications use which components. Alongside this listing, it is also important to maintain a link to the mailing list maintained by the vendor through which it notifies about security updates and patches. All of this information can in fact be maintained on the software security portal and wiki mentioned above. Beyond this however, it is important to assign a point person to each component whose responsibility it would be to track such mailing lists for their specific component. As soon as they learn of an update they can then notify the other teams using that component based on the matrix described above. Further it is also important that the point person also track aspects such as reliability issues with the patches that may affect the decision about whether to deploy the updated components.
In our experience without such a mechanism it is all too common to see applications that are free from vulnerabilities themselves but are exposed to highly critical problems in third party components. A knowledge management scheme as mentioned above not only can help prevent this by defining the appropriate roles and responsibilities but can also help share that information across the development team and organization to prevent others from falling victim to it as well.