Security testing is a key component of software quality. A program may meet functionality and performance requirements, but that does not guarantee security. In this blog post I will present different security testing methods and provide a few tips for conducting a more secure code review. But first, let’s understand what software security is intended for.
The Goal of Software Security
Software security is intended to help the CIA. No, not the CIA you’re thinking of, but rather, CIA as in “confidentiality, integrity, and availability.” Here’s how NIST defines these terms:
- Confidentiality. The process of preserving authorized restrictions on access and disclosure, including a means for protecting personal privacy and proprietary information.
- Integrity. The act of guarding against improper information modification or destruction, which includes ensuring information nonrepudiation, accuracy, and authenticity.
- Availability. The ability to ensure timely and reliable access to, and use of, information.
The Impact of Inadequate Software Security
Some of the consequences of a lack of security include:
- Damage to the organization’s brand name
- Loss of customer trust
- Negative impact on sales
- Expensive vulnerability remediation cost
- Production impact
- The cost of downtime and expenditures required to recover from a website crash, such as reinstating services, restoring backups, and so on
- Fines, fees, and legal repercussions
How to Achieve Software Security in the Software Development Lifecycle
A very effective way to achieve secure software is to implement secure development, deployment, and maintenance principles and practices in the development lifecycle. In the testing process, this means making sure that systems are protected and can function as needed.
Security Testing Approaches and Techniques
Let’s look at three security testing types that cover the software development lifecycle from end to end.
1. Threat Modeling
A threat is a potential source that can exploit system vulnerability. Threat modeling is a constant iterative process of identifying and prioritizing these probable threats and documenting the actions that need to be taken in each case. As a result, threat modeling helps teams identify and investigate potential threats and vulnerabilities, and find architecture risks earlier in the development lifecycle. Threat modeling allows testing teams to be involved in the whole application development process so they can identify critical bugs and make better security decisions.
The Threat Modeling Process
Let’s see how the threat modeling process works:
- Planning. Defining your application, data flow, and assets involved.
- Identification. Classifying or identifying which type of threats the application is exposed to, such as data manipulation or SQL injection.
- Mitigation. Identifying tools and technologies to protect software from the identified risks.
- Remediation. Validating software against the tool and capturing risks. Risk identification must be a continuous process. Tools need to be run on every iteration of a certified development build.
Some examples of threat modeling tools include:
- OWASP Threat Dragon
- Microsoft Threat Modeling Tool
- Cairis
2. Penetration Testing
A penetration test, also known as a pen test, is a simulated cyber-attack against your software system to check for exploitable vulnerabilities. Penetration testing targets the security weaknesses that enable attackers to gain access to the data. As a result, penetration testing helps in assessing the overall security posture and identifying vulnerabilities before the attackers do.
The Pen Test Process
Here’s how the penetration testing process works:
- Define the scope. Determining the testing methods and the level of exploitation required when trying to find vulnerabilities.
- Exploration/access vulnerabilities. Discovering all possible vulnerabilities and intrusions.
- Penetration testing. Testing all possible exploitations in order to discover new vulnerabilities. In this stage, the web application is attacked to uncover vulnerabilities and check if a bad actor is able to access the application and gain in depth access.
- Risk analysis and mitigation. All the vulnerabilities found during the test should be listed and recommendations should be provided for filling security gaps. Information on which sensitive data was accessed and the duration of attack should also be provided to patch solutions in order to prevent these attacks in later phases.
- Pen test report. A detailed report of the list of issues along with severities should be shared with the team so that severity 1 issues can be prioritized and fixed.
Types of penetration testing:
- Network service tests. Evaluating the network system and the services provided for probable security issues. Issues could be on servers, routers, switches, DNS, IPs, and so on.
- Web application tests. Testing all functionalities and interfaces with all sets of data in web applications.
- Client-side tests. Various actions performed in client-side application programs like email clients, web browsers etc. to exploit vulnerabilities.
- Wireless network tests. Exploration and identification of wireless networks, vulnerability examination, exploitation, test report, and remediation.
- Social engineering tests. Emphasizes people and processes and the vulnerabilities associated with them. This type of test consists of an ethical hacker directing attacks such as phishing, or impersonating a person during the course of their work.
Some examples of penetration testing tools include:
3. Code Reviews
Code reviews can improve software security by removing common vulnerabilities, such as memory leaks, format string exploits, and buffer overflows. As a result, code reviews help developers find and fix software vulnerabilities in the development cycle itself. This makes the mitigation process less expensive than correcting code after deployment to production.
Application security code review focuses on high-risk parts of code. Vital actions in this process include leveraging threat/vulnerability assessment to identify which part of the code should be manually reviewed and where static application security testing (SAST) tools need to analyze source code to identify probable security flaws in the application.
Code reviews can be either automated or manual, and should address issues like security risks from open-source tools, business logic, and QA test layering.
Following are some best practices for doing security code reviews:
- Sensitive data that is used in the codebase should always be encrypted.
- Ensure unit tests have a combination of input data validation so that attacks like injection, and cross-site scripting can be prevented.
- Ensure there are no memory flaws in the code and safe memory practices are followed. This helps avoid SQL injection and OS command injection.
- Avoid any indirect object reference with files or path traversal method.
- Collaborate and share your knowledge with the team about bugs and security issues identified in earlier stages so they can be addressed and avoided.
Some examples of code review tools include:
- GitHub
- Veracode
- Review Board
Conclusion
By incorporating security testing practices into your software development lifecycle, you can help minimize the attack surface. For more information, reach out to your CISO, or IT and security team.
