The Security Skeptic

Recently, Security Response Researcher Todd Woodward made a very interesting post to the Apple-Focus mailing list. Todd chimes in on the perennial debate of whether to make systems secure or easy to use, and offers that providing a combination of the two, coupled with *education* is simply good sense. With Todd's permission, I'm reproducing his post:

I think most users don't want to have to think about what they're doing and how they're doing it, which is why Mac OS X is a big plus in general terms. It's one reason why while developing security software (especially for consumers) you have to find a delicate balance between security and annoyance as well as security and functionality.

Thankfully in the business and enterprise arena that balanced is (supposedly) managed by someone else who has more education and (presumably) better sense.

And I think for Apple, when considering development plans that include security features, they have to balance between engineering and marketing as well as quality assurance. I can't comment on my experience with testing Leopard pre-release, but from past experience in other endeavors, some brilliant security features have to be left-out due to usability and marketing issues (also quality assurance) as well as to achieve that all important delivery deadline.

But still: Common sense rules. A little security education without having to buy anything new can make a big difference. Some potential things Apple could do towards this:

* If you don't want to complicate initial setup, then provide a security wizard for post-installation. In addition to educating users, you can walk them through all of the possible means and options for strengthening security.

* Make sure that there is a Security PDF included with the operating system or readily available online that discusses common sense practices as well as discusses the security features of Mac OS X.

* Appoint a chief security officer. (It's something that's been mentioned on this list before.) It would be great to have someone at the top thinking about security full-time.

Archived at http://www.securityskeptic.com/arc20071101.htm#BlogID659 by Dave Piscitello  

I subscribe to a number of security mailing lists. I receive hundreds of posts per day to some of these lists. Like any mail list, some posts are relevant and informative while others don't meet these criteria. To optimize my mail list time, I identify the practitioners whose posts almost always prove to be relevant and informative. Paul Melson is one of the handful of folks whose posts to the firewall-wizards mail list rarely disappoint. One recent post caught my attention because it was succinct, informative, and sound advice for anyone who was attempting to implement a host intrusion detection system on a server.

With Paul's permission, I've copied the body of his message here in my guest corner.

...here is my advice in rolling out HIPS, especially on servers.

1. Benchmark performance on the servers. For Windows, using System Monitor is fine. Use the following Perf Objects:
   • Processor / % Processor Time
   • Memory / Pages/sec
   • Memory / Available Mbytes
   • Physical Disk / % Disk Time

   Compare performance with and without HIPS. Note where servers need more hardware to accomidate HIPS. Also keep an eye out for performance conflicts. HIPS is invasive and can screw things up. This can be especially true of vendor A's HIPS product trying to cohabitate with vendor B's AV product.

2. Plan time for deployment and plan 4x that time for initial tuning. One thing Entercept did shortly before McAfee acquired them was to create a kind of step-up policy configuration. From deployment you can turn on their high level events and then medium, and low and so on. And you can do this in a way that keeps you from being deluged with events from the time you turn on the agent. Of course, I think this probably also leads to most deployments never stepping up to more detailed detection. Plan to step up and expect to spend lots of time tuning. If your HIPS vendor doesn't have a tiered protection/logging policy like Entercept does, well, make that 6x as much time.

3. When creating policy, logically group and deploy by application and function, not by OS version. A Win2K3 server running WebSphere is more like a Win2K server running Jboss than it is like a Win2K3 domain controller. Group them together because their policy and tuning should be similar. (Of course, a Solaris server running J2EE should not be tuned the same as a Win2K server running Jboss.)

If you like Paul's perspective and want to read more, visit his blog at blogspot.com. I will:-)

Archived at http://www.securityskeptic.com/arc20070701.htm#BlogID630 by Dave Piscitello  

When the question, "Can anyone point me to some good documentaion as why NEM is better then Standard IPSec VPNS?" was posed on the Firewall-Wizards mail list, colleague Tina Bird offered this insightful and vendor-agnostic answer.

Network Extension Mode is Cisco-specific terminology, so I'll assume you're talking about Cisco VPN gear. Cisco's site is the only place you'll find doc. They've got a white paper on enterprise VPN deployments which might help out.

One of the big problems for IPsec deployments is making sure that the VPN peers on both sides of the connection are configured with the same parameters for session negotiation and management. In The Beginning, we had to do that manually, which was annoying but feasible for site-to-site VPNs. For remote access VPNs, where you've typically got a single machine connecting from a random external IP address into a corporate environment, it was a complete pain in the, uh, ethernet jack, because a lot of the negotiations are managed based on things like IP address. Hence the need for certs and dynamic client management (but we'll ignore that tangent).

Despite IPsec's support for multi-vendor deployments, in *practice* now, the vast majority of organizations using IPsec for remote access have deployed single-vendor VPN servers and clients. The biggest reason for this IMO is because vendor have frequently deployed proprietary features that make managing IPsec for remote access *much* simpler. Cisco is the premier example of this. Their "EZvpn" technology (based on a proprietary mechanism of theirs called the Unity protocol) creates a mechanism for the server to control all aspects of session negotiation and traffic management, leaving a minimal amount of configuration required for the client itself.

As I said above, most remote access connections require a single client to connect into the enterprise network. Cisco IPsec assumes this in their "basic" VPN config. The VPN concentrator need only connect that single machine in -- the corporate network does not need to connect back into the remote environment. In this case, the VPN server assigns a local corporate IP address to the endpoint connection, and has no visibility into any other machines in the remote environment.

But there are some situations -- for instance, when the remote user is an engineer with a development LAN that needs access into the corp network -- where corporate machines have legitimate reasons to connect into the remote location. Cisco supports this using its "Network Extension Mode." In this mode, the VPN server provides a unique range of addresses for the machines in the remote subnet (usually via a DHCP server on the remote end), and manages traffic back and forth through the tunnel. This mode is more complicated, because you have to manage a larger set of network addresses and routes, but it works a charm for branch offices and telecommuters with lots of machines.

Neither one is better or worse, they fulfill different requirements.

--Tina Bird

Archived at http://www.securityskeptic.com/arc20070101.htm#BlogID585 by Dave Piscitello