Web application design and coding defects are the main reasons to create a secure coding policy and guidelines. The policy/guidelines are to provide awareness and ensure security when developing code. Techniques to secure code review:
Generally, IT analyst can divide the secure code review process into two different techniques: 1. Automated tool based/ Black Box: In this approach, the secure code review is done using different open source/commercial tools. Mostly developers use them while they are coding, but a security analyst may also take help of them. Tools are very useful while doing code review when we implement the secure SDLC process in the organization and provide the tool to developers themselves to do a “self-code” review while they are coding. Also, the tools are useful in analyzing large codebase (millions of lines). They can quickly identify potential insecure pieces of code in the code base, which may be analyzed by the developer or a security analyst (Infosec). 2. Manual/ White Box: In this technique, a thorough code review is performed over the whole code, which may become a very tedious and tiresome process.
But in this process, logical flaws may be identified which may not be possible using automated tools, such as business logic problems. Automated tools are mostly capable of finding technical flaws such as injection attacks but may miss flaws like authorization problems. In this process, instead of going line by line through whole code base, we can concentrate on potential problems in the code. Those potential vulnerabilities can be given a high priority. For example, in C/C++, if we try to find any copying function in the code and check whether it’s using functions such as, strcpy() for performing copy function. As we know, strcpy() is known to be vulnerable to buffer overflow attacks. We may also want to check if any customized encryption is being used in the application, which automated tools may miss as they can identify standard algorithms only (Infosec). Introducing security into NIST’s Five SDLC Phases:
Initiation Phase – Consists of all activities used to identify the different requirements from all stakeholders. This includes defining stakeholders, conducting stakeholder interviews and possibly some basic prototyping. It is also important to identify security requirements (Harwood, 2011). Development & Acquisition Phase – Transition functional and technical requirements into detailed plans for an actual information system. Results from interviews, use cases, and mock ups are developed into sequence diagrams, activity diagrams, state diagrams, and other artifacts that can be interpreted by software developers. User interfaces are also defined in greater detail (Harwood, 2011). Implementation & Assessment Phase – Actual coding of an information system.
All of the analysis and design artifacts previously created are transformed into application code by developers/programmers. This phase also includes testing and debugging (Harwood, 2011). Operations & Maintenance Phase – Encompasses all activities required to keep the system working as intended (monitoring, patch management, application fault remediation and audits). Disposition Phase – Ensures that information is retained, as necessary, to conform to current legal requirements and to accommodate future technology changes that may render the retrieval method obsolete (Harwood, 2011). Summarization:
The Software Development Life Cycle (SDLC) is a process to help ensure the successful development, operation and retirement of information systems. The SDLC has numerous methodologies including: Waterfall, Fountain, Spiral, Build and Fix, Rapid Prototyping, Incremental, and Synchronization and Stabilize. While they share common processes such as Design, Implementation, and testing, one of the most promising methodologies is Waterfall. It has several advantages: It is one of the most widely used and accepted methodologies and nearly all other methodologies derive from Waterfall. Its linear approach makes it easy to demonstrate where security fits into each phase. A crucial part of the SDLC is the source code review.
The purpose of source code review is to discuss, exchange information, and explain the code. Explaining the code will help identify problems and may provide new solutions in the troubleshooting process. Effective code reviews can include automated reviews. It is vital to implement security controls at each phase of the SDLC (Harwood, 2011). Best practices should include policies and guidelines that explain that software should be free from exploitable code vulnerabilities to meet the level of confidence. The code should provide security functionality as intended. Review and maintain Best Practices and guidelines annually. Including security early in the information system development life cycle (SDLC) will usually result in less expensive and more effective security than adding it to an operational system (Harwood, 2011).
Harwood, M. (2011). In Security Strategies in Web Applications and Social Networking. Burlington: Jones & Bartlett Learning, LLC, an Ascend Learning Company. Infosec. (n.d.). Retrieved from Infosec: http://resources.infosecinstitute.com/secure-code-review-practical-approach/