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 defence. 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
   Viruses
   Worms
   Trojans
   Malicious code
   Buffer overflow
   Unauthorised access
   Misuse of resources
3. Three types of protection:
   Detect: Recognise 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.