You very simply can't fix what you can't see. This is something that nearly everyone in the IT field struggles with at some point. This is largely due to the lack of proper tools being used to manage the network (see part 1 about consistency). This is also usually the fault of network structure.

Data flows around a network can be difficult to observe and control except on the edges, where there are devices like firewalls and routers which are made for this exact purpose. Monolithic (or flat) networks are particularly bad in this case because of the lack of borders between parts of the network which should be separate. When dealing with such a network, you only have a few options if you are interested in watching the traffic flowing internally. The first is to have a large number of span/monitor/mirror ports which copy the traffic from the ports to which your network devices are connected. Unfortunately, this breaks down rather quickly when the number of used ports and the bandwidth used gets to be too high. The second option is to use Cisco's NetFlow (or similar). Of the networks I've seen, many do run Cisco switches, so this is a viable option. For those running lesser switches, you're pretty much stuck with mirroring ports, or with nothing. Of course, there is always the option of installing a physical tap for every single port, but that's pretty well unreasonable for the average organization.

In my opinion, the best way to increase security and visibility simultaneously is to separate your monolithic networks into smaller, more manageable subnets. Generally, these subnest should be cut along the lines of security, physical, and logical lines. Which mix of these will work best for your organization is something you'll need to consult a security professional to find out. In any case, once the network has been divided, the only way data should flow between any two subnets is through a firewall. Most modern firewall appliances come with the tools necessary to watch and manage the data flowing through them. Some of the better ones will provide tools for visualization and reporting to make understanding these flows easier and more efficient. Honestly, I can't get enough when it comes to tools which crunch otherwise boring data into neat little pictures, so long as detail is available when I want it.

Another incredibly helpful pile of data that your network generates is log data. The problem is that logs are tedious and boring. That's why there are log analyzers like Splunk which give you a nice web interface and search/index functionality which helps turn your log data into something useful. One of the best uses I've heard of for a log analyzer is anomaly reporting. Basically, you run your network for a while and let the analyzer collect log entries. After enough has been accumulated, you go through and mark all the normal data as being so. Once you have tagged the data which you expect to see, you can very easily filter for what you don't expect. This effectively sifts out errors and other unexpected messages from a sea of information.

Of course, doing any of the above assumes that you have time in the day to make it happen. Unfortunately, it seems to be incompatible with IT departments which work behind the curve of break/fix. 

Most organizations don't start out with the resources or immediate need to properly roll out imaged workstations or manage their networks using high-level tools. What happens more often than not is that the network is a collection of very different PCs, all of which have been built and configured individually. As a result, there are as many variations in loadout as there are workstations. As the organization grows, this practice is scaled to meet the need, and results in an IT department which works mainly in fire-extinguishing mode.

There is a certain point at which more consistent control over the network is an absolute must. The problem is that, in my experience, many medium-sized networks are being run without the proper tools. Management tools, strict domain policy, and imaging are all incredibly useful when combatting sprawl and growing pains.

Consistent network management not only makes IT staff more productive, but also allows for self-auditing and quick response to security events. Patching becomes easier (and can be more comprehensive than just WSUS or Windows Update), which allows the very common issue of third-party software vulnerabilities to be addressed in a more elegant and effective way.

Let's take a look at the basic functions that these tools need to help accomplish in order to be useful. The first is enumeration, cataloging, and inventory control. Basically, you need to know what each device is, does, and has on it. By the same token, you need to know what is on your network that shouldn't be. In addition to a simple understanding of the devices on your network, a good management system will keep track of when devices were purchased, what kind of warranty/service plan they have, and what their serial numbers are. Having all of this information in one place is the first step towards getting your network under control to the point where securing it becomes an easy task.

The second tool in your arsenal should be a package/file management tool. In order to properly manage software updates, it's important to know the loadout of each machine, to be able to verify that ONLY the software you approve is installed, to be able to perform updates to your software, and to be able to remove unauthorized installs. Many of the issues I see in security assessments come down to good patch management. I'd estimate that at least half of the vulnerabilities are a result of old software which has updates available. For those thinking that Windows Update or WSUS will cover all of these issues, you are sorely mistaken. Many of the vulnerabilities I find in assessments aren't in Microsoft products, simply because they do get automatically updated. More often than not, it's old antivirus or backup software which runs at system privileges that provides a way in. 

Overall, being consistent usually comes down to putting a bit of initial effort in to a structure, then being disciplined enough to follow it. Automation of the boring, repetitive tasks makes this worlds easier. Manually going to every device in your organization and checking for updates is very tedious and gets frustrating rather quickly for the high-IQ types who usually make up an IT department. This leads to mistakes being made and eventually to the practice being missed or avoided.

Find some good tools, become intimately familiar with their innerworkings and behavior, then use them as an extension of yourself in confidently controlling your network. Get things to be consistent across the organization, then you can begin to manage one set of common machines instead of many individuals.

I'll use, as a base, the definition that the FFIEC publishes:

More often than not, we (White Badger Group, specifically our sales people) end up having to reeducate potential clients as to what a "penetration test" is. Why is this? Well, the problem is twofold.

Firstly, we deal mainly with financial institutions. These organizations are governed and audited by the FDIC, NCUA, OCC, and other agencies at the federal and state level. If you press any of these agencies for details on what kind of security assessment they look for, and the details on what such an assessment should include, they all refer to the FFIEC. The FFIEC publishes a handy series of booklets which details the process of auditing banks and credit unions. As a matter of fact, I often refer to their IT Information Security Examination booklet (p. 89) when asked to define the different kinds of assessments. The problem comes in when the FDIC and NCUA request banks and credit unions to have an assessment performed. Here's an example of one of the NCUA's documents telling a credit union to get a "comprehensive attack and penetration audit":

I looked through what documentation the NCUA and FFIEC make available publicly, and found that term nowhere. If anyone from the NCUA is reading this, I'd be very interested in why this term was chosen over the ones which are clearly defined by the FFIEC. From talking to many banks and credit unions, it seems that the issue is very consistently inconsistent across the industry. One auditor will ask for a "penetration test," while another will send out a document like the one above.

The other issue is that the vendors offering security services are generally unqualified, and use the incorrect terminology. We have come across many IT hardware/software/service companies offering "penetration tests" in a bundle of 4 for $1200. What they're really selling is a vulnerability scan, with zero human interaction (except for printing the report and putting it in the mailbox). This ends up being a great disservice to organizations in need of real security help, and muddies the waters for those of us out there who are trying to do things correctly.

When it comes down to it, the only people who should be performing a security assessment are:

All too often, we come in behind other IT firms who do general IT work (install servers, set up networks, etc.) who had performed a security assessment. Absolutely every time, we have found major issues which should have been found by the other firm. Some of these have been really, really bad; the kind of bad that puts the organization out of business if it had been exploited.

Know what you're buying. A penetration test is a very involved and expensive process when done properly. You can't get one done for $500, no matter how hard you try. If someone claims to be able to do so, then it isn't a penetration test.