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 human nature.
People interested in breaching security often use human nature to
entirely bypass technological access controls. This is known as
social engineering. Here is an example:
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
information?
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 quite
right.
In short, get the message out to your users any way you
can.