Heard of the Needlepoint virus? You probably haven’t, because it isn’t the typical virus you’re accustomed to hearing about in alerts or on your favorite news portal. It’s a term I coined to describe a virus that $3 million of security didn’t catch.

I was the division director of a $300 million consulting company that had nearly 50 offices throughout the United States. I had total profit and loss responsibility of a locally run office with a $10 million budget and more than 120 consultants.

One of my responsibilities was to work on an enterprise-wide security policy that could be implemented in each of our divisional offices. The outcome was what we considered to be a thorough security plan, which was eventually implemented.

A few months later, a virus hit our company. It first sent e-mail to everyone’s address book locally and then throughout the entire corporation. After our IT staff stopped it, its origin was traced back to my office. Of course, my office was the one with the best firewall, security procedures, and virus software. After all, I personally assisted in the writing of the company-wide procedures for security.

What I didn’t think about was what I call Needlepoint.

It begins with a user
My administrative assistant, who wrote and checked the security document I assisted in drafting, was aware of our security policy. But even though it was precluded in the policy, she often downloaded needlepoint patterns to her work PC because our Internet connection was faster than hers at home. When she downloaded a needlepoint pattern, she brought a virus into the network. She had software on her machine that was designed to halt viruses, but it hadn’t been updated.

So often, we spend so much of our time and budget worrying about and trying to prevent outside attacks that we forget that our system is most vulnerable to the person in the cube or office just a few feet away. Often, it’s a nonmalicious problem, like the one my administrator made. There was still, however, significant disruption. After being down for three business days, we estimated our loss from employee and consultant productivity was nearly $500,000. Imagine what could have happened if the attack was malicious.

How was this problem resolved?
Since I helped with the first security policy, I was tasked to reevaluate it to find any holes. Obviously, our inside staff, myself included, needed to be educated quickly on security issues. We decided that we needed both technical and nontechnical solutions.

The technical fix
For the technical solution, I brought in a top-notch security person who used to do software encryption work with the U.S. Department of Defense. He suggested a layered approach that was more technically detailed than what we had developed. It also gave me a short education on system security. Here’s what he suggested:

  1. Identify business risks and the potential financial damage if we had any of the following happen:
    Business interruption: We couldn’t bill customers or pay staff.
    Negative publicity: It could get out to the community that we were hacked.
    Theft of proprietary: Our custom software systems could be stolen.
    Theft of private information: This could include staff personnel files or payroll records.
    Legal liability: Someone could install illegal software.
    Shareholder liability: The SEC or the owners could be upset.
  2. Identify major threats and items first on my list of security issues. Our original security policy covered only a few of these:
    Denial of service
    Malicious code
    Buffer overflow
    Unauthorized access
    Misuse of resources
  3. Three types of protection:
    Detect: Recognize the threat is underway and let the appropriate people know.
    Prevent: Identify which servers, desktops, and personnel are the most at risk for a successful attack.
    Respond: Determine whether the threat is fixed automatically or whether someone should be notified.

Possible solutions
These are some of the solutions we came up with for our installation. We didn’t implement them all because of cost, but they were all very sound approaches.

  1. We started with network protection, focusing on the networks and gateways. We installed a software package that focused on the protection of the network access points.
  2. We installed desktop protection at individual workstations. The package we chose guarded remote and mobile corporate desktops against unauthorized access and a broad array of threats by combining intrusion detection and response with firewall capabilities.
  3. We installed a server logging system. We already had one, but it was geared toward the tech support guys, and it wasn’t user friendly for managers. We installed a third-party software package that generated a report with which I could view the access to our server. It even gave me a transaction log for a specific period by individual account. It allowed me to review the log for signs of unusual activity or high transaction activity that could point to problems.
  4. Managers attended a training class given by the security consultant, who explained what had been installed and why.
  5. We didn’t do a vulnerability assessment. This would require an outside consultant to evaluate our server, our Internet use, and our database use for a few weeks. The information from this would be used to give us the ultimate in protection. We passed on this because of the cost.
  6. We didn’t hire someone to remotely monitor our systems periodically for security problems. We decided not to implement this based on our success with the other procedures we implemented.

Nontechnical solution
We implemented our nontechnical solution next. We derived it from discussions with the consultant and the original policy we had implemented. I immediately had managers place system security on staff meeting agendas and review the firm’s policies.

For long-term change, I had managers mention security at least monthly during their staff meetings to keep it on everyone’s mind. The security consultant also suggested that we distribute written guidelines, which is the first step in preventing liability if a security problem occurs.

I call this my Needlepoint checklist. I distributed it to my entire staff.

  1. Don’t have anything on your computer you don’t want management to see.
  2. Don’t download anything that isn’t 100 percent work-related.
  3. Make sure the latest virus-check software is on your machine.
  4. Don’t load or bring in software from home to load.
  5. Let everyone know that you or someone you assigned is going to drop by and check the computer occasionally to see what has been loaded.
  6. Managers should mention security problems at least monthly during meetings. (When I did this in a later staff meeting, a staff member remembered she didn’t have virus software on her machine at home, which was the same machine that she used to access our system when she dialed in.)
  7. Ensure backups are made of critical machines and that those backups can be read by another computer.
  8. No one should be on a computer but the employee.
  9. A 90-day password change policy is in effect. Management has the option to do a password change if needed. The new password can’t be within three positions of the previous password. Passwords cannot be reused. For example: The password my1son can’t be changed to my2son.
  10. Never open e-mail from people you don’t know.
  11. Never play or load games on office computers.
  12. If someone is terminated, take his or her computer passwords away immediately.

I let everyone know, in person and writing, the ramifications if they violated these procedures. We’ll first give a verbal warning. If an employee violates these rules a second time, they’ll be warned in writing and a third warning could be cause for termination. Everyone now knows that management might be looking.