Here's a funny thought I had today, and hopefully one that will not put me out on the streets.
Dynamic web application testing tools ("D.A.S.T.") such as HP WebInspect, HP QAInspect, and HP AMP are just the tip of the iceberg. These are the first tool sets a new security program sees and starts with, but they are in no part the full program. Fortify Software has been saying this for years. In their view, ostensibly as purveyors of code analysis tools ("S.A.S.T."), only beginners depend on dynamic scanners. And you know, they are right to some degree.
Certainly implementing a dynamic DAST tool is the quickest thing to do to help your broken system and begin to catch those security defects. It is also cheaper and faster to enact than the true solution, the implementation of a full Secure Software Assurance program or Secure SDLC a la OpenSAMM. Too many companies are checking for security only in a silo, right before the code goes out the door. Too frequently the security testers are portrayed as the bad guys, the bottle neck that gums up the product releases. This is partly why HP QAInspect exists, because once upon a time SPI Dynamics customers experienced bottlenecks from having HP WebInspect used in the final stages of approval and not having security testing earlier.
We all know that secure code is better than insecure code. The Rugged Code Manifesto, OWASP, and many others have been trying to make security an integral part of the development process. This is where the largest portion of our security iceberg is found with mature processes, system governance, stream-lined efforts, and security baked in. This requires reviews and changes to the current development process, but the ultimate outcome will be code that is self-hardened. Now the security team can serve as the trusted advisers they should be, focusing on the logic attacks and tougher items inherent with implemented code.
Dynamic scanners still serve a purpose. Auditors need them. There are classes of vulnerabilities that are based on the implementation or not an issue on the code-level. These scanners can operate in the absence of code access. Or with periodic post-production test runs, they can identify new zero-day vulnerabilities that are live on the company web sites after the full SSA process has been completed. So if your company just got real with a new dynamic scanner, welcome aboard, now get to work!
~~~~ Habeas Data
Showing posts with label Security Testing. Show all posts
Showing posts with label Security Testing. Show all posts
Monday, November 7, 2011
Friday, February 11, 2011
What about QAInspect?
Indeed, what about HP QAInspect? I am amazed this product has not taken the Quality Center installation market by storm, or at least as much of the market as QTP has. QAInspect finds most of the same things WebInspect does, has the same report options, most of the same tools, can schedule or run tests from remote QAInspect-enabled hosts, better/richer real-time scan UI than previous QAInspect releases, and has the ability to control or throttle the findings prior to delivery into QC. What's not to love?
Let's look at the QAInspect line. This product was created in 2003/2004 by SPI Dynamics. Their customers came to them because security teams had acquired the shiny new WebInspect scanner, and suddenly all their projects were being held up prior to release due to unforeseen security defects found during pre-production security scans. So the customers wanted something to find these defects themselves, earlier, where they can be fixed more cheaply and without the security team acting so superior. But they had two caveats. One, they did not want to become security experts or ethical hackers themselves. Two, they did not want to be forced to learn and integrate yet another tool. With Mercury's Test Director owning the testing market, SPI Dynamics naturally built "QAInspect for Test Director". They even built a "QAInspect for IBM ClearQuest", but that market was substantially smaller and eventually that product was EOL. In 2007 HP Software acquired Mercury, and then SPI Dynamics, and this same tool became known as "HP QAInspect for HP Quality Center" although it works for either Quality Center (QC) or the new HP Application Lifecycle Management (ALM) product.
Yet when was the last time anyone saw a demonstration on Quality Center or ALM and the presentation even discussed or included security testing? They currently show many other plug-ins that fit the QA auditing mindset (and HP has a lot of great ones in the stable), but security testing still seems to be held at arm's length. It seems that the QA audience still is reluctant to look into security testing, even to this date, and the vendors are not leading them there much either.
The fact is, security testing needs to be done by many more teams than the security office. Who better to know the application under test than the QA group? Who has more manpower and equipment at their disposal? Who already performs or attempts to perform 100% functional code coverage with automated testing? So if that same (overworked) team be augmented with a solution that works inside their current environment and processes and that allows them to fulfill their mandate to produce good software, why has it not been snapped up? By finding defects earlier with an automated scanner, they should see savings in rework time, as well as an improvement to departmental reputations. By testing all of the application for the simpler things, the security team will be able to focus on the tougher application logic issues and serve as an advisory role to the QA group performing security testing.
I will follow this posting up with some entries specifically on working with QAInspect and HP ALM, the latest "version" of Quality Center.
~~ Habeas Data
Let's look at the QAInspect line. This product was created in 2003/2004 by SPI Dynamics. Their customers came to them because security teams had acquired the shiny new WebInspect scanner, and suddenly all their projects were being held up prior to release due to unforeseen security defects found during pre-production security scans. So the customers wanted something to find these defects themselves, earlier, where they can be fixed more cheaply and without the security team acting so superior. But they had two caveats. One, they did not want to become security experts or ethical hackers themselves. Two, they did not want to be forced to learn and integrate yet another tool. With Mercury's Test Director owning the testing market, SPI Dynamics naturally built "QAInspect for Test Director". They even built a "QAInspect for IBM ClearQuest", but that market was substantially smaller and eventually that product was EOL. In 2007 HP Software acquired Mercury, and then SPI Dynamics, and this same tool became known as "HP QAInspect for HP Quality Center" although it works for either Quality Center (QC) or the new HP Application Lifecycle Management (ALM) product.
Yet when was the last time anyone saw a demonstration on Quality Center or ALM and the presentation even discussed or included security testing? They currently show many other plug-ins that fit the QA auditing mindset (and HP has a lot of great ones in the stable), but security testing still seems to be held at arm's length. It seems that the QA audience still is reluctant to look into security testing, even to this date, and the vendors are not leading them there much either.
The fact is, security testing needs to be done by many more teams than the security office. Who better to know the application under test than the QA group? Who has more manpower and equipment at their disposal? Who already performs or attempts to perform 100% functional code coverage with automated testing? So if that same (overworked) team be augmented with a solution that works inside their current environment and processes and that allows them to fulfill their mandate to produce good software, why has it not been snapped up? By finding defects earlier with an automated scanner, they should see savings in rework time, as well as an improvement to departmental reputations. By testing all of the application for the simpler things, the security team will be able to focus on the tougher application logic issues and serve as an advisory role to the QA group performing security testing.
I will follow this posting up with some entries specifically on working with QAInspect and HP ALM, the latest "version" of Quality Center.
~~ Habeas Data
Friday, February 4, 2011
Fog Security
For full disclosure, this humorous term was "invented" at my local ISSA chapter meeting last night.
If you pay attention to the computing world, you are already aware of Cloud Computing. This is the nebulous term (pun intended) referring to the practice of storing and using data on-line outside of one's normal network, out in some service provider's network. The beauty of this process is that you can reach your data from any Internet-connected system, typically from any browser. The horror of this process is securing it.
Integrity: Is your cloud data being backed-up? Probably, as your provider would lose a lot of face if they failed to keep the data intact.
Confidentiality: Is it inside your hardened network perimeter? No, attacks against your Cloud data never trip any of your firewalls, IDS, or anything.
Availability: Can you halt all communication to the data if needed in an emergency? Probably not.
While the cloud concept provides great value for business, it fails two of the three commonly accepted tenants for security. Is it secure? Outlook is foggy. Will business continue to move towards the cloud? Yes. And as with all business advancements, security trails (but is working hard to keep up!).
Don't talk to me about Cloud Security, it is Fog Security for the foreseeable future.
~~ Habeas Data
If you pay attention to the computing world, you are already aware of Cloud Computing. This is the nebulous term (pun intended) referring to the practice of storing and using data on-line outside of one's normal network, out in some service provider's network. The beauty of this process is that you can reach your data from any Internet-connected system, typically from any browser. The horror of this process is securing it.
Integrity: Is your cloud data being backed-up? Probably, as your provider would lose a lot of face if they failed to keep the data intact.
Confidentiality: Is it inside your hardened network perimeter? No, attacks against your Cloud data never trip any of your firewalls, IDS, or anything.
Availability: Can you halt all communication to the data if needed in an emergency? Probably not.
While the cloud concept provides great value for business, it fails two of the three commonly accepted tenants for security. Is it secure? Outlook is foggy. Will business continue to move towards the cloud? Yes. And as with all business advancements, security trails (but is working hard to keep up!).
Don't talk to me about Cloud Security, it is Fog Security for the foreseeable future.
~~ Habeas Data
Subscribe to:
Posts (Atom)
