- There is no silver bullet – There is no one service or a tool that can fully keep your application secure.
- Think Strategically, not Tactically – Don’t use the patch-and-penetrate model (fixing a bug, but not reporting the root cause of it).
- SDLC Is King – it is extremely important to incorporate security into each phase of the SDLC.
- Test Early and Test Often – Find common security issues and test them in each phase of the SDLC.
- Understand the Scope of Security – Information needs to be classified depending on how important/valuable they are. For example, personal information should be treated with due care.
- Develop the right mindset – You have to think outside the box to find some security vulnerabilities. Think like an intruder rather than the average user. Automatic testing tools lack the ability to think outside the box.
- Understand the Subject - Accurate documentation of an application must exist (data-flow diagrams, use cases). It is also important to have some type monitoring system setup to monitor intrusions.
- Use the right tools – Although tools are not perfect, they do help “automate many routine security tasks” (20).
- The Devil in the Details – Don’t just breeze through the security testing. Go into every possible “section of [the] application logic” (20).
- Use Source Code when Available – You shouldn’t just always do a black box testing. Since the source code is there, use it find security flaws.
- Develop Metrics - it is important to quantify the results to make sure the security testing is actually doing its job.
- Document the test results - All testing results should be documented for "developers, project managers, business owners, IT department, audit and compliance" (20). This will allow the right person to make the right decision moving forward.
- Manual Inspections & Review
- It's the idea of talking to the system owner or looking at the system documentation and finding out "how something works and why it was implemented a specific way" (21). It's a way to make sure the SDLC works as desired and has the right policies in place. Identifies threats during development of the system.
- Threat Modeling
- Is the idea of finding out potential threats that the web applications could face and allocating resources to mitigate these threats. Identifies threats during design of the system.
- Code Review
- It is one of the best way to test for security concerns. It is the idea of looking at the source code and finding inherent security flaws. A lot of threats cannot be found with simply a black box approach. Identifies threats during development of the system.
- Penetration Testing
- Is the idea of testing an application or network from a user perspective. Source Code is not given and thus this testing is akin to how most hackers will try to penetrate the system. Although it works well for networks and operating systems, it is often a poor choice for application testing because applications are always custom coded (bespoke) and different exploits exists in different applications.
- OWASP recommends in using a balance approach (using a combination of the above techniques) when trying to test for security flaws because it will "cover testing in all phases of the SDLC" (25). Most of the testing should take place in the early stages of the SDLC (define, design…) with emphasis on manual inspections & review and code review. Again, black box testing is not recommended for web applications.
- The objectives of the testing are placed in the security requirements document . The content of this document derives from our business requirements. For example, if our business is selling products online, then we must have security guidelines to product customer data and also comply with government regulations. We validate our security requirements document by testing it at various stages of the SDLC.
Foreword
What’s limiting our technological advancements is the security aspect of it. The goal of the Open Web Application Security Project (OWASP) is to take out this limiting factor so technological improvements can continue to progress. To do this, OWASP created the Testing Guide (v3) for software developers, software testers, and security specialists (IT Audit companies). It is important for people to actually understand security issues rather than relying on automated tools. Automatic tools are a great asset to have if they are used as a supplement rather than fully relying on them. This is due to the fact that generic tools are not to find issues in custom code (ex, applications), but rather, they are suited for an already defined environment (ex, network security).
Frontispiece
OWASP recommends that when viewing application security, we must view it as a “people, process, and technology problem because…security includes improvements in all those areas” (14).
OWASP describes testing “as a process of comparing the state of a system/application against a set of criteria” (16). OWASP wants developers, testers, and specialists to all understand the “criteria” before any testing begins. Testing should be done as a means to eliminate the differences between a company’s security practices and that of the industry’s best practices.
So when should the testing process begin? Surprisingly, most people only test applications once it has been deployed (code already created). This not only increases headaches, but also costs. OWASP recommends that security testing be done at each phase of the project’s SDLC.
Once security is implemented, we must decide what exactly should be tested. OWASP recommends that we take a holistic approach and test not just the software (technology), but also the people and processes. A lot of companies just test the technology, which leads to problems down the road when the companies’ people and process could include security risks in the technology. This approach “eradicates bugs early and identifies root causes of defects “(17).
Before any testing occurs, one must first understand the principles of security testing
Testing Techniques
Which testing to use?
What are the objectives of testing?
