In regards to computer security, one of the most important aspects of creating a secure solution or product is to focus on security from the start, it cannot be tested in. Many organizations make extensive use of security testing products to help find security vulnerabilities that exist in currently deployed products. But how did those vulnerabilities get there in the first place? It may have been that computer security was not a consideration from the start.
There are many different terms and processes being developed in organizations throughout the world to ensure security (SDL) is integrated into the Systems Development Life Cycle SDLC but my focus here is to summarize what I think is important and why. The challenge is that implementations of information security processes are commonly different from one organization to another and therefore, it is one topic that is difficult to learn in an information security course. The difference is due to various factors that include (1) risk tolerance, (2) security culture and (3) capability maturity levels of information security processes within an organization.
Here's a scenario to consider: You’ve just completed and delivered the latest business requirements document for a new product and you think things will be getting back to a normal 45 hour work schedule.... That's when your manager strolls into your office and says you will now be responsible for security during the development of this new product and you have no idea what is being asked of you. Understanding the 3 factors described above are very important in this scenario. One example of a secure culture would be an organization that has already established an information classification standard. This will assist in determining a level of risk for the “information” being processed by a computer application or solution being implemented. If this is non-existent, you may have to get advice from a risk consultant or research what is being done in the industry to place a value on the type of information needing to be protected. Information Security processes for an entire organization can follow recommendations and concepts as documented in the ISO 27000 series standards. Obviously, if the processing involves handling or storing of information that is considered personal identifiable information (PII), that is a good indicator of where there is value to a potential attacker. Note that information can still be considered private in the sense that a person may not wish for it to become publicly known, without being personally identifiable. Another risk could be the disclosure of intellectual property which is always more difficult to value but fits into the category of risk tolerance for the organization.
Most importantly, security is a process and not a one size fits all process at that. Some of the things to consider when developing a process to integrate security:
One of the first steps in integrating security is by threat modeling. This process involves creating a list of reasons an attacker would want to find vulnerabilities in your product or solution, and then defining the possible attack vectors which are the ways of that attacker being able to succeed. Understanding the business drivers and usage models is important in this process and can help identify areas of most concern. Estimating value of a threat materializing begins the definition of risk and it includes the possibility of someone gaining access to the valuable asset of which the “type” information described above. Most importantly, we come out of the threat modeling process with a list of threats rated based on information being handled by the new system. A feature set being implemented may be obviously too risky at this point but can be confirmed only after completing the next phase of defining security requirements.
With the threat model complete, we can create the security requirements that may evolve throughout the development of the product. It should be considered an expectation that changes will take place so this process can work in an agile methodology. The threat model and security requirements can be updated throughout the lifecycle so that as changes are approved for the current or next iteration, those changes are properly evaluation for security related risks. This phase also allows for the creation of a defense-in-depth security strategy as the design can include the consideration of other security mitigations and levels of access restricted for different functions.
Checkpoints are a good practice and are intended to ensure security mitigations are appropriate and that the defined process is being followed throughout the development cycle. These checkpoints should be done several times before implementation. A qualified representative should be assigned to own information security requirements and can be the focal point for all questions, testing, and follow-up.
Also called penetration testing. Although this process is most oftentimes the first consideration for security, it should be one of the last. Before deployment, this phases could be performed internally, externally (i.e., 3rd party) or both. Security testing should be done to evaluate that all the security requirements have been implemented appropriately. If time permits, consider testing security for other areas outside of what has been defined as a threat and the results may be surprising. It is possible that the threat modeling did not capture all possible threats and therefore, new security requirements might be needed at the last minute. This should not be considered bad or that all the work performed in previous steps were not valuable. On the contrary, it is only through evaluating what went well and what didn’t that improvement can occur and maturing models increase.
The security process in an organization of any size should be one targeted for constant improvement. Processes for integrating security into the SDLC can provide valuable contribution to a defense-in-depth security strategy. Moreover, there have been many estimates throughout the industry that have proven security issues to be much less costly to an organization when they are found during development rather than after deployment. For this reason, a security process defined and integrated early in the development cycle is very important.