Do you need to know how to attack to defend better?

In general, yes, you should know how the system works in order to subvert it, then you know a little better how to protect your systems and network.

If you approach your network with the mindset of "if I wanted to do XYZ, how would I do it?" you'll then be able to say, "If someone did ABC, how do I stop them?" and take it from there.

These are kind of satellite subjects to understanding how the system works in the first place.

Would you better defend yourself, if you learned how to fight?

I think that wihout actively trying to "break things", it is difficult to develop the right mindset - to be able to think as a hacker.

An interesting recently released book where a number of high profile security experts discuss "the security mindset" is Beautiful Security

Knowledge of your environment is the first step to protecting it: Knowing the systems, learning about the languages and OS version used, knowing how the servers interact, and protective controls already in place, understanding what kind of organization you're trying to protect.

Once you have that knowledge, attack techniques are key because they give you the ability to audit these systems both in production and before they get there, and help expose the assumptions about how your systems are run. Assumption: Our firewall is working fine. Reality: nmap just returned a list of systems that have vulnerable ports exposed to the internet, lets take a closer look at our firewall rules.

But there is a danger, once you've seen all the attacks that come out of BH/defcon every year, you can become over focused on the cool new attacks and totally miss other critical basics. eg. You run around and disabled BIOS based virtualization because you read all about Blue Pill rootkits, but the systems aren't patched or screened by a firewall and they still get owned by a drive by download.

I find that the my most important question is not "what could an attacker do against my system?" but instead "What are most attackers doing right now against people running systems like mine?"

Yes. I think so.

Often it is not until you actively attempt to work around a solution, especially when it comes to security, that you will begin to discover it's weaknesses beyond a pen-a-paper mindset.

If you're after a more in-depth answer then you may need to provide some subject specifics.

You will know how to defend them better when you gain a deep understanding on how they work, not necessarily how to attack them.

For example, if you spend a lot of time researching and studying the Apache code base, and all the options it provides you will be able to defend and harden it well. With this knowledge, you will also be able to attack it too (maybe you will even find bugs in there).

So, deep knowledge leads to a better defense (and attacking knowledge), not the other way around.

**don't fall prey to the thinking that just because you can run a few shell scripts or run Metasploit that you know how the system works...*

Security and countersecurity are just the same medal...just not the same side.

If you want to do passive security, as in protect yourself from what you know and if a problem comes, you fix it, you don't need the hacker mindset.

If you want to do active security, as in protection AND prevention, you want to be 2 steps ahead of hackers...in which case the dual mindset is necessary. However..in the industry, it isn't always easy to justify the time dedicated to security. It's up to the bosses to see if they want to invest or not in this prevention, but they have to understand the added value to properly analyze if it's worth it or not.

As for the specifics of your question, yes you will see your assets with another point of view, discovering consequences of previous decisions and configurations and their impact.

Most system probing tools are, essentially, attacks, probing for open ports and known vulnerabilities. So, if you know how to run the tool, and interpret the results, you know just about enough to secure your systems.

Almost.

The trouble with the "Almost" is that it can consume all of your time, and several other professionals, trying to bridge the gap between vulnerabilities your tools know about and what MIGHT be vulnerable in the future.

Instead of spending so much time trying to learn how to attack your own systems, the best approach is to use current best practices - Arrange your network for defense-in-depth, update strong passwords often, set up two factor authentication, use least privileges, shut down unneeded services, and patch often.

Inasmuch that to be able to be good at exploiting a system, you must first understand it, yes.

But script kiddies have long demonstrated that you don't need to know jack about a system in order to exploit it. You just need to know methods to exploit it. Typically, methods developed by someone else who does know.

Likewise, it is not necessary to know how to attack a system to know how to defend it. For example, I can tell you that to build a good firewall, you should block everything, then allow only certain ports to connect (the ones you want the public to access), as opposed to blocking "bad" ports. I can also tell you that when programming a PHP application, sanitizing all data (not just user data, but all data that comes from outside your program!) prevents security holes and cross-site scripting issues.

Sure, you can sit down and dream up new attacks, but it's the attacks the malicious attackers use that are a threat to your system, not the attacks you conceive of. At the same time, standing outside the perimeter for a moment and just asking "how can I get inside?" would probably have saved the guys in the movie "Aliens" a whole lotta grief. :)

I think it's important to know how anything you use works and know its weak points. It boggles my mind how many "security auditors" are out there who have never configured a server in their life, yet they are the ones coming into big companies and performing audits and telling people whats right and wrong, yet they have no experience hands on with anything.