Microsoft network endpoint security tips and tactics

Microsoft network endpoint security tips and tactics

Endpoint security is the security of physical devices which may literally fall into the hands of malicious users. Given the rapid growth of employees who use laptop computers, securing network endpoints has become of paramount concern for security administrators. Learn some endpoint security tactics, how to defend against network security breaches and how to guard your network at the desktop in this section of our network access control learning guide.

Traditional means of securing the endpoint are going by the wayside. A firewall alone is no longer enough to defend your network from the myriad threats that remote users, malicious hackers and the age of easy-access information have wrought. In the summer of 2006, a laptop containing personal data on nearly 30 million military veterans and active duty personnel was stolen from an employee of the U.S. Department of Veterans' Affairs. In April of 2007, a laptop containing information on 160,000 employees of Neiman Marcus was stolen. Follow the tips below to learn how to prevent such a disaster from befalling yourself and your users.

Keeping pace with emerging endpoint security technologies

The network endpoint as we know it is dead. A firewall alone can no longer protect the corporate network from potentially dangerous endpoints introduced by remote users, partners, contractors, even malicious intruders. Suppliers have responded to this de-perimeterisation of corporate networks with products designed to perform "health checks" of connecting devices, permitting access based on the security status of the endpoint. The challenge for security practitioners is to choose the correct endpoint security solution for their network environment.

Microsoft Network Access Protection

Network Access Protection (NAP) is the policy enforcement platform built into the Microsoft Windows Vista and Longhorn OSes. While NAC is built on a Cisco foundation, NAP is built on a Windows foundation and uses the Windows Quarantine Agent (QA). The QA gathers device information and passes it to the Microsoft Network Policy Server, which works with other devices (DHCP, IPsec, VPN, 802.1x and more) for policy compliance.

NAP allows you to create customised policies to validate computer health before allowing access or communication, automatically update compliant computers to ensure ongoing compliance and optionally isolate noncompliant computers to a restricted network until they become compliant.

Plan for a security breach, step by step

One of the most overlooked and underrated requirements of managing a good network is having a good computer security incident response plan in place in case of a computer security breach. It's a fundamental human struggle to admit just how vulnerable our networks really are and what there is to lose. Once an incident occurs, the breached information is gone; it's forever deleted or residing on someone's mind or computer who shouldn't have it. And there's no way of getting it back.

This type of long-term business impact is why I continually stress the importance of having a good response plan. It won't necessarily prevent an attack, but having a plan will help stop the bleeding if an attack occurs, reducing the amount of information in harm's way.

There are six things you must do in order to prepare yourself, your network and your business for the inevitable security breach:

Define what breach means to your business

First and foremost, you've got to clearly outline what types of issues define a security breach. For some organisations with low tolerance, a malware outbreak may constitute a breach. On the other hand, it may take something as serious as a losing a laptop or drive containing millions of social security numbers. Every organisation has a different level of tolerance based on accepted risk, government and industry regulations and so on. Determine whether or not you want to invoke your formal incident response plan or just keep the necessary response localised.

Here are some reasons to put your incident response plan in motion:

    Malware outbreak (virus, worm or Trojan) across multiple systems
    Social engineering or other verbal threat
    Pinpointed firewall, IDS/IPS or content filtering alerts regarding a breach
    Denial of service against the network or specific hosts and applications
    Account lockouts -- especially with regard to administrators' accounts or multiple users of the same system
    Unauthorised account access or use of system or network privileges
    Lost or stolen system

Don't overlook critical network infrastructure systems

Most network administrators and IT governance committees (if you're lucky enough to have support for one) include servers and applications within their response plans. That's fine and dandy, but you cannot overlook supporting network infrastructure systems and other critical systems that would cause just as many problems during and after a security breach. Be sure to consider the following systems for the scope of your incident response plan:



    Firewall(s)
    Router(s)
    T1 CSU/DSU systems
    DSL routers

Know who to contact and have that information available

When something bad happens, you don't want to have to scramble to find the relevant contact information for colleagues, management and others in order to notify them of the security breach. The same goes for cybercrime investigators at your local, state and federal law enforcement levels. You'll want to document contact information -- work, mobile and home phone numbers as well as personal email and IM addresses -- for all key players.

Develop a simple yet methodical set of response sets

Entire books can and have been written on incident response methodologies. I'll take the pain and agony out of all that information and condense it into a few bulleted response steps:

    Introduction outlining the purpose and scope of the plan
    A list of security incident response team members and full contact information mentioned above
    A list of the types of incidents that will cause you to invoke the plan mentioned above
    Technologies and operations in place to detect incidents
    Specific steps for containing incidents

In the end, make sure your plan addresses these six major areas:

    Who does what?
    What must be done?
    When must it be done?
    Where must it be done?
    How must it be done?
    What's done when all is said and done?

Get input from others affected by a security breach

It's easy to assume that you know everything that's needed for responding to security breaches; you probably do from a technical perspective. Just don't overlook the importance of input from other business managers, legal counsel and your marketing/PR folks. By involving the right people, you'll gain insight into business processes you probably weren't aware of, investigative steps you must follow based on the type of business your organisation is in and what to say or not say to curious people when they call after getting wind of the problem. Also, you won't want to re-create the wheel so never overlook the value of third-party guides on the subject of incident response planning such as NIST's Special Publication 800-61.

Keep your momentum going

Computer security textbooks recommend testing your incident response plan. It's a good idea on paper and does serve as a good way of validating that your plan is a good one. It's just not very practical in the real world. You may not be able to simulate an all-out breach, but do take a day or two every year for a sanity check by getting together with your colleagues and walking through things to see how everything would actually play out.

Once that inevitable breach does occur, turn the negative situation into a positive learning experience and rework your incident response plan. It'll undoubtedly need a refresh. Remove what wasn't needed, update what didn't work and add what you forgot about. An incident response plan, like your resume, is constantly changing and is an evolving work of art. Put extra effort toward updating and maintaining the former so you can better react to security breaches and not have to worry about working on the latter afterwards!

Endpoint security: Guard your network at the desktop

As the attacks and threats to computer networks have expanded -- now including phishing attacks and spyware among other things -- and the traditional definition of network perimeter security has disappeared, the rules have changed. Now, users carry PDAs and cell phones that are connected to the corporate network. They use laptops with wireless connections, transport data on USB flash drives and have all but negated the concept of outside or inside the network.

With these changes in how we use and transport data and the increasingly clever attacks designed to compromise and steal that data, the line of defense has moved from the perimeter to the desktop or other endpoint device. Securing the endpoint is the primary focus for most companies and security administrators now, and there is an ever-expanding selection of products aimed at helping them do just that.

It is common for desktop machines to be running antivirus software locally, and many organisations include other security software such as personal firewalls or antispyware at the desktop level as well. Organisations that employ a HIDS (host intrusion detection system) or HIPS (host intrusion prevention system) for additional monitoring and protection are becoming more common.

However, even with those tools installed, some administrators may not keep the systems up to date with the most current versions, and rogue systems that join the network still pose a risk. By taking advantage of some type of endpoint security verification, companies can make sure that insecure or unprotected systems are not allowed to connect to the network.

Share on FacebookPlus on Google+

SUBSCRIBE MORE CONTENTS