Soul Searching Before you shower your network with trendy tools, you should reflect on your internal processes...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Hi, my name is Scott, and I was in a bad security relationship. There, I said it. Whenever I felt insecure, I'd buy my beloved enterprise a sexy new piece of hardware. Things would seem better...for a while. Then, along would come another threat and out would come my checkbook.
I amassed a closet full of gizmos before learning an expensive lesson: Money can't buy you love, and, for us security practitioners, it doesn't always buy peace of mind. Until you get to the heart of a problem, all the bells and whistles in the world won't solve your woes.
For a while now I've been in recovery. No 12-step program for me--I ran a low-cost discovery scan.
Using Nmap and Nessus, I probed the enterprise, searching for weaknesses. While I wanted to know what was visible from the outside, I found something interesting as an insider looking out: The scan uncovered inconsistent configurations; servers from one department were configured differently from servers in another department--even when they were performing the same tasks. It turned out that everyone insisted on doing their own builds their own way.
I had spent plenty to compensate for my insecurity. Instead, I should have invested in a little group therapy. This wasn't a technical issue; it was political.
My team created a grass-roots unit of technical people representing different user groups. We devised a set of baseline build standards from several NIST checklists, and augmented the guidance with our collective experience. The result was a standard security requirement for public-facing servers.
All this was a good start, but when it's time to enforce these policies, those same political factions reared their ugly heads. Time once again for a little human intervention.
Though not always the best answer for every company, we're pushing to form a single group that specializes in building and hosting secure public-facing servers. Every department contributes a portion of its IT budget to this specialized group. It's a hard sell, but having a dedicated hosting group within the organization can do away with the problem of having sysadmins trying to build servers as they bite off all the other network problems on their plates. This method allows servers to be built to a common set of procedures, and then tended to by people with a direct line of authority over the boxes.
Now that we worked on our people problems, we turned our attention to technology. We ran vulnerability scans internally, which revealed we had issues managing our assets. With hardware being added and removed from the network across the enterprise, we only had a rough estimate of how many systems we had. Our scans indicated that systems could be added to the network without clearing policy requirement hurdles, such as being up to date on patches and antivirus software.
This got us thinking about port security, technology that would allow us to automate the process of checking hardware that is connecting to our corporate network. In its crudest form, if a box does not meet the minimum policy requirements it is not allowed onto the network. In its more sophisticated incarnations, port security gracefully pushes the offending hardware over to a limited-access virtual LAN where it can pick up the required security tools before being allowed join the corporate network.
Perhaps it's time to open up my wallet again. These days, though, I feel like my security relationship is worth the investment.
Dig Deeper on Open Source Security Tools and Applications