Sorry. I am more of an outsider in this than a noob. I defer towards better experience in an effort to expand my appreciation of the field.

peace,

-=T=-

My question was supposed to be a bit of rhetorical . We are a decade away from secure code,(have millions of legacy bugs probably) and application firewalls are not up to snuff yet either.

“In light of this discussion, would it not be advantageous to look for something that prevented software vulnerabilities from be enacted on?”

I think it’s a matter of semantics at that point. An open port is a vulnerability, only, in most books, but I can see where it might be looked on as a threat. Throughout my limited education on business law, we were taught to repeatedly to protect ourselves from liabilities. So, I see both vulnerabilities and threats as liabilities. However, to simplify, to secure an open port, I would run a firewall app to secure against an (external) threat from exploiting the (internal) vulnerability.

And, this might lead to another segment of the discussion, a common tangent, OBSCURITY. We can view the actual access, availabilty and public knowledge of the client as an internal vulnerability that bridges to the external threat. Many businesses will identitfy their customer base to make access available, and limit that access to that range alone. Others will want to maintain a less rigid surface for other potential customers to establish relations and, therefore access. Others for reasons of system security cannot grant access to any but a few priviledged members, and even then, there might not be a reason to pirate access.

So, to answer your question, as I understand it, one can do both by maintaining obscurity and neglecting external threats. In extreme cases, it just might not be worth it to turn on your server, and just leave it unplugged.

As I like to see it, I go back the “vulnerability is a threat” model of liabilities. But, that isn’t so applicable when you understand that you can correct one vulnerability, but not stop the potentially limitless number of attackers willing to exploit the one vulnerability over and over. In that case, closing the door before stopping the hordes of zombies from coming in might be the best method.

And, yes, I agree that the best thing is to think about the attacker’s mindset. Profile him, if you will. Who are they? How/do they see me as a potential victim/will they gain access? What will they do? Remember to include less logical answers when addressing these primary clues to the pool of possible attackers. These clues can lead to exactly where your newest vulnerabilties lie, like bloodhounds.

Thoughts?

-=T=-