The Security Skeptic

A long time ago in Internet time I edited TISC Insight. While I don't have the bandwidth to continue that publishing endeavor, I do occasionally find something interesting to publish here. Today's guest column is by Manoj Patel, and considers the sticky subject of insider threats. - enjoy!

The risk of insider threat greatly increases during times when companies are laying off staff, cutting back on raises and bonuses, deferring promotions, consolidating operations, and outsourcing work to save money. During these turbulent times, security analysts are warning companies to be even more alert to potential insider threat. Not only are angry employees more likely to lash out against their employers, but stressed, worried employees also make easier targets for opportunistic rivals looking to uncover trade secrets. People who are worried about losing their jobs or worse - paying their mortgages - can become desperate and, therefore, are more easily enticed by rival companies to steal and hand over corporate data and intellectual property in exchange for what they perceive to be a more stable or lucrative job opportunity.

The attacks run the gamut - from fraud to stolen proprietary information to bits of code planted to cause system or network failure, and from financial institutions to retailers to technology companies. For example, last year in San Diego an IT specialist deliberately deleted patient and allied data from his former employer's computer systems. And, in November 2006, a DuPont scientist admitted to stealing corporate-given conditions valued around $400 million shortly before he left DuPont to work for a rival company.

Insider attacks occur across all organizational sectors, often causing significant damage to the affected organization. According to research from the Ponemon Institute, the average cost of a data breach was US$4.6 million in 2006. The largest case of identity theft to date was the result of an insider attack and ended in September 2004 when Philip J. Cummings, a former technical support representative at Telecommunications Data Inc., pled guilty to one count of wire fraud, one count of fraud related to ID documents and information, and one count of conspiracy for his involvement in a scheme to steal identities, which defrauded financial institutions of more than $11 million. Cummings allegedly stole the passwords and access codes of Ford Motor Credit and other financial companies to access credit report records and downloaded credit report information on 30,000 individuals. He allegedly sold the credit reports to a group of co-conspirators.

Organized crime rings are also coordinating attacks. In April 2005 in Hackensack, NJ, Orazio Lembo led an organized insider crime ring that stole more than 675,000 identities and earned Lembo as much as $4 million. Lembo allegedly set up a bogus collection agency called DRL Associates. He then hired seven bank employees - including branch managers from Wachovia, Bank of America, Commerce Bancorp, PNC Bank NA and a former NJ Dept. of Labor manager - to steal personal account data and social security numbers of bank customers. The group created a manual database of all the identities and sold the data to more than 40 other collection agencies. Lembo paid bank employees $10 for each record they delivered, and then he charged collection agencies up to $150 for the data.

The harsh reality is that insider threats exist for all organizations. If your organization has not taken a hard look at insider threat controls, then now is the time. Here's a short list of "must have" capabilities for insider threat solutions:

• Technology that permits 'as needed' access to critical assets and then monitors that access.
• Software that provides a video capture of employee movements inside the system, enabling corporate executives to see what IT workers with privileged access are actually doing while they are logged into the system.
• A solution that alerts organizations to unauthorized systems access so they can combat and prevent insider attacks.
• Technology that provides in-depth investigation and forensics for insider attacks.
• A solution that, in the event of legal proceedings, can produce digitally signed evidence.
• A modular and scalable product that allows for integration with other security solutions currently in use.

Special Note: Many of the insider theft crimes noted in this post we're found in the book "The Insider," by Dan Verton. Thanks, Dan, for your long-time research and reporting on the subject of Insider Threat.

About the Guest: Manoj Patel, CEO and founder of Unity Solutions, is an expert in insider threat identification and containment.

Archived at http://www.securityskeptic.com/arc20090401.htm#BlogID725 by Dave Piscitello  

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