No matter what you might think about the environment in which
your systems are running, you cannot take security for granted.
Even standalone systems not connected to the Internet may be at
risk (although obviously the risks will be different from a system
that has connections to the outside world).
Therefore, it is extremely important to consider the security
implications of everything you do. The following list illustrates
the different kinds of issues you should consider:
While you are thinking about security, do not make the mistake
of assuming that possible intruders will only attack your systems
from outside of your company. Many times the perpetrator is someone
within the company. So the next time you walk around the office,
look at the people around you and ask yourself this question:
While most system administrators' first reactions when they
think about security is to concentrate on the technological
aspects, it is important to maintain perspective. Quite often,
security breaches do not have their origins in technology, but in
People interested in breaching security often use human nature
to entirely bypass technological access controls. This is known as
social engineering. Here is an
The second shift operator receives an outside phone call. The
caller claims to be your organization's CFO (the CFO's name and
background information was obtained from your organization's
website, on the "Management Team" page).
The caller claims to be calling from some place halfway around
the world (maybe this part of the story is a complete fabrication,
or perhaps your organization's website has a recent press release
that makes mention of the CFO attending a tradeshow).
The caller tells a tale of woe; his laptop was stolen at the
airport, and he is with an important customer and needs access to
the corporate intranet to check on the customer's account status.
Would the operator be so kind as to give him the necessary access
Do you know what would your operator do? Unless your operator
has guidance (in the form of policies and procedures), you very
likely do not know for sure.
Like traffic lights, the goal of policies and procedures is to
provide unambiguous guidance as to what is and is not appropriate
behavior. However, just as with traffic lights, policies and
procedures only work if everyone follows them. And there is the
crux of the problem — it is unlikely that everyone will
adhere to your policies and procedures. In fact, depending on the
nature of your organization, it is possible that you do not even
have sufficient authority to define policies, much less enforce
them. What then?
Unfortunately, there are no easy answers. User education can
help; do everything you can to help make your user community aware
of security and social engineering. Give lunchtime presentations
about security. Post pointers to security-related news articles on
your organization's mailing lists. Make yourself available as a
sounding board for users' questions about things that do not seem
In short, get the message out to your users any way you can.