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.
Microsoft network access protection with NAP
and NAQC
Microsoft network endpoint security tips and tactics
Remote access security measures for Windows
users
VPN security testing and
maintenance
Microsoft Windows firewall
security
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.