ClearNet Security comments

"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.

"How not to build a server" by ian

Mon, 04 Feb 2008 13:20:12 -0700

You’ve brought up the aspect of the subject that I didn’t want to address. I’ve tried to refrain from revealing who it was or the company. I don’t believe it has or will cause anyone any harm. I also think there is some inherent value to the story as a whole. If you know who it is, the whole thing might be just that much more funny.

To be completely honest about the ethical side, I have grown up a bit since then and I most certainly wouldn’t behave the same way now. There are a lot of things about that particular situation that would have been very different today. I knew it was wrong when I did it, I guess I could kind of rationalize it as a response after a fairly abusive relationship with the company up to that point. The working nature of that company was sort of a hostility based competition culture, it was not uncommon for people to sort of tweak each other in different ways. (little stuff, “your code sucks, I found x bugs in it” and you wouldn’t believe that things that were said while playing foosball there) I had kind of wanted to sort of get my final “tweak” in when I left by letting him know but chose to leave on better terms. That’s just a rationalization though, it was completely unethical to do what I did.

Not to remove the ethical issues, I do regret what I did and recognize completely that it was not ethical, it’s a different story to describe to people to double check file permissions than it is to provide a very real example of them mattering. I didn’t “crack” anything or really do anything at all that was very exotic. In the spirit of full disclosure, that’s what happened, pretty much exactly as it happened, if it helps anyone to avoid making the same mistakes then at least a little good can come from it. I could tell you to check your file permissions and double check the logging on your servers but this describes the pound of flesh you can lose by not doing any of that.