ClearNet Security comments

""Don’t buy technology to detect" Come again?" by randy

Mon, 13 Oct 2008 06:46:59 -0600

“He cited examples of business consumers whom lack knowledgeable staff to understand the alerts detection systems produce”

That’s actually kind of scary. Either send current staff to training so that they understand the alerts, or hire someone that’s already competent. Incompetent staff shouldn’t be a reason to not use a useful technology.

"True penetration testing?" by LonerVamp

Tue, 06 May 2008 14:26:17 -0600

Just wait! They’re going to get into bed with some Certified Ethical Hacker cert and that’ll be the criteria!

"True penetration testing?" by Tate Hansen

Mon, 05 May 2008 10:44:12 -0600

@Andre: lol, my bad, you’re exactly right. I was so wrapped up in the skills thing I forgot about the money thing. Doh. Feel free to deliver a sensibility roundhouse kick to my head anytime! :)

"True penetration testing?" by Andre Gironda

Mon, 05 May 2008 04:15:14 -0600

One day in the not-so-distant-future, exploits will reveal their true nature to the public – that they are weapons of mass destruction.

However, in this case – I think it means ‘overflow with A’s’, instead of “Rapid Penetration Testing” (c) CoreSec. I’m sure the PCI SSC will correct me, and later specify that only Core Impact used by a monkey qualifies (probably something as close to a real monkey as possible).

“resources must be experienced penetration testers”

What does that mean?

Tate, my man, you should know what this means. The PCI SSC will specify the exact requirements for this once they figure out how to monetize it. In other words, they need to figure out which certification vendor to get into bed with so that they can take a cut of the money.

Also see: ASV + Qualys, Requirement 6.6 clarification + F5/Citrix, et al

"Test commercial web app scanners for free and without restrictions?" by Apneet Jolly

Wed, 26 Mar 2008 10:37:03 -0600

You may also find the Universal Hooker tools useful to redirect traffic.

http://oss.coresecurity.com/uhooker/doc/index.html

http://hexale.blogspot.com/2007/12/uhooker-videos-tcpnetpy-video.html

"Test commercial web app scanners for free and without restrictions?" by Andre Gironda

Tue, 25 Mar 2008 01:05:36 -0600

You forgot my method, “Test web applications for free and without restrictions by not using commercial web application security scanners”.

I’d honestly like to hear of the benefits of web application security scanners outside of being strictly awareness tools for organizations that are unwilling to listen to a three-minute speech about how “secure SDLC” approaches are better.

Somehow I doubt that RSnake and I are the only black-box web application security assessors that can find EIGHT TIMES the amount of vulnerabilities or more in the same amount of time that it takes a commercial web application security scanner (including time spent going to the bathroom, reading RSS feeds, and eating food). He said it best himself (with explanations) in this video presentation.

If anything, I’d suggest that someone unethically use your information above to further prove this point to clients in the “I want to believe” category. Or they can just watch that RSnake video.

"Us and them development" by Andre Gironda

Fri, 14 Mar 2008 13:47:59 -0600

A traditional model, which is often the result of a primarily waterfall-based SDLC (or other classic SDLC) usually splits software development and SQA.

In this modern era of programming, where developers utilize practices such as Continuous Integration, Refactoring, the Dependency Injection pattern, and TDD/BDD - this “traditional” approach often does not work.

First, SQA is thought to be the validation or “check” for software development. If software developers utilize Continuous Integration, this means that developers are likely to also be doing Fagan inspection (or peer review of some kind) on all code check-ins, or component check-ins. At this point, SQA becomes redundant.

Continuous Integration and TDD also assume that developers are doing unit testing in their daily/nightly builds. This turns some or all developers into “developer-testers” which replace the need for unit testing done by SQA. This comes even more into play if the developers are doing continuous-prevention development and/or refactoring.

Worst of all for an already marginalized SQA team, the developers could also be doing all of the functional testing using Continuous Integration. Not only are unit tests written by developers, but also all functional tests using an automated testing tool such as Canoo WebTest driven by something like an Ant task at build time.

What does this leave SQA to do? Well, there is regression testing (replaced by continuous-prevention development) and finally - acceptance testing. Would an organization want to keep a SQA or SQC team around just to perform acceptance testing? Maybe. It’s my opinion that developer-testers can also do acceptance testing and thus - full elimination of all SQE’s is possible (however, it could naturally be that many SQE’s fill the developer-tester roles). In some cases, where extensive or very user-driven testing is necessary (or where it just doesn’t fit the culture), SQA/SQC should be kept around to perform acceptance testing.

The best place to put all of your current SQE’s is into test case/charter roles. Test cases are created in the earliest phases of the life cycle: planning and requirements gathering. Using the V-Model, test cases that will apply to any software project should be started before the software engineers sit down to decide on the design decisions.

Test case development isn’t the only way to provide testing throughout the life cycle. The best SQE’s today use techniques such as exploratory testing - however I also feel that this is best done during the programming phase (or the integration phase!) and not during a separate, post-build phase. Exploratory testing creates and works from a test charter, which is often everything that the test cases and unit tests are missing and more.

Exploratory testing takes into factors that involve the application as it is built and how it works internally besides all of the boundary value analysis, input validation, and code metrics. Domain testing and combinatorial explosions (especially using all-pairs testing) make good candidates for exploratory testing.

In summary, quality testers need to redefine their roles in this new era of TDD. There are many places for current quality people in early development lifecycle work, and there are many places to put “newbie” people (i.e. people with no computer science degree, experience, or certification). It’s probably best to list the positions still as SQE (software quality engineer), but make the role as a developer-tester. This is what Google and others do. For those that have quality tester certifications, utilize these people where they can provide the most benefit - such as requirements gathering and exploratory testing.

Yes, this means that SQA/SQC will have to integrate and work well with developers (and vice-versa). A documented and clean Fagan inspection process is necessary in order to make this successful.

"Rogue modems are still plentiful?" by Tate Hansen

Wed, 27 Feb 2008 22:49:25 -0700

I don’t know the answers to your questions yet, but we are in the running to win the project. If we score it, I’ll be sure to share the numbers.

"Rogue modems are still plentiful?" by Anthony Williams

Mon, 25 Feb 2008 04:07:44 -0700

Tate,

That is an astonishing number indeed. Do you have any data that these are desktop modems or in computer modems (PCI winmodems or the built in laptop variety)?

Also are they run off the back of a PBX based phone or connected directly to a wall based jack?

I suppose now I don’t feel so silly keeping wardialing software on my laptop and toting around an RJ11 cable in my backpack!

"How not to build a server" by MikeP

Wed, 06 Feb 2008 20:53:04 -0700

That’s fair enough; nobody’s past is perfect. Thanks for the response, sorry for the delayed answer.