IT Security - A Pragmatic Perspective

This is a short essay I cultivated in preparation for my Pragmatic Security presentation at the KanREN Annual Conference. It struck me that at this time, we are not reacting to security threats rationally, but rather, we are reacting to them emotionally. This short essay attempts to explore how, why and what we can do to start developing more reasonable responses to our security fears. It is obviously unfinished, but this is as far as I got before I had to quit and write a presentation. Maybe one of these days I will have time to polish it.

Introduction

Today, everyone is talking about security. National Security, Homeland
Security, Social Security, Microsoft Security…

What is this ethereal “Security”? Many companies and consultants have
made their fortunes selling it, but what is it?

Does buying an InternetProtector 3000 actually improve your chances of
defending a cyber-assault or does it purchase the feeling of security?

We are here to discuss how to apply pragmatic, common sense techniques
that will improve your IT security for little cost and maximally reward
your efforts.

We will not discuss compliance with regulations such as HIPAA,
Sarbanes-Oxley, Gramm-Leach-Bliley, CALEA, and others. Government
regulations rarely cost-effective and are rarely pragmatic. Your
organization may have obligations to comply with those regulations, but
it is outside the scope of this discussion.

These are common-sense steps that should be taken before even
considering buying the latest WonderWidget Security Compliance
Appliance. While these techniques will not put you in compliance with
governmental regulations, pursuing these common-sense objectives will
provide a framework within which your organization can make the move to
compliance quickly and easily.

Goals

• To increase understanding of enterprise security and develop practices that lead to a long-term improvement of the security of the organization’s IT assets.
• To take ownership of organizational security processes regardless of how hard or risky it is.
• To take steps that positively affect the organization’s IT security.

IT Security: What is it?

IT Security is a long-term process

In it’s most simple form, IT Security is a long-term process where an
organization attempts to gain a feeling of safety. More specifically,
IT Security at an organizational level is a set of processes that insure
organizational assets are not misused.

These processes should include:

• Education Processes
• Technology Processes
• Audit Processes

IT Security: What it isn’t

There is no magic bullet!

• Security is not a firewall.
• Security is not network intrusion detection / prevention.
• Security is not a honeypot or a honeynet.
• Security is not a VPN.
• Security is not strong password criteria.
• Security is not encryption.
• Security is not a budget line item.

IT Security is not Simple

There are many components to organizational IT Security, however a
collection of the parts does not make the whole.

Organizations must begin to understand that security cannot be bought.
This is not to say that good security is free, but rather that no amount
of money can secure your organization’s assets if you do not pursue
security as a long-term strategic process.

The feeling that, “We spent the entire security budget, so nothing else
can be done” is an attractive one. Vendors certainly like to promote
this mentality.

Areas of Focus

To begin building an security infrastructure to mirror their IT
infrastructure, organizations should begin minimally by focusing on the
following areas.

• Best Practices
• Risk Management
• Policy / Procedure
• Education

Best Practices

Perimeter Security

For many, IT security is synonymous with one word, “firewall”. At this
level, the perception is that inside = good and outside = bad. Most
organizations attempt to allow everything inside out and block all all
access into the network with a few well-known exceptions for servers and
the like.

Of course, perimeter security should extend beyond the standard,
“protect me from MSWorm 2007″ filter to only permit access to those
services which are permitted by the organization’s Acceptable Use
Policy. Many organizations are now filtering outbound SMTP from any
source (except their mail server) to prevent spam from being relayed by
a misconfigured email server (or some worm traffic). It is likely that
many other services can and should be blocked at the organization’s
perimeter.

Later, we will discuss policies and risk management, which will be vital
in helping determine which services to permit to travel across the
network boundary.

A note on DMZs

The demilitarized zone or DMZ is a small network commonly used to
prevent hosts inside the network from reaching outside the network
without passing through the firewall. In this configuration, the
firewall is the only host with an interface in both the LAN network and
the DMZ network.If possible, organizations will likely want to configure their Layer 2
Physical networks to mirror the logical architecture of the LAN / DMZ.
This would indicate at least one VLAN on the LAN side of the firewall
and one VLAN on the DMZ side of the firewall prevent hosts on the LAN
from simply re-addressing to move themselves out into the DMZ
(logically).

Network Intrusion Detection / Prevention

While having a firewall is a good step in the right direction, it is a
lot like locking the doors on your home. It is a good idea and it will
keep everyone out unless they are deteremined to get in. To continue
the analogy, Network Intrusion Detection is a lot like having a burgular
alarm (which will notices when a problem is detected) and Network
Intrusion Prevention is a lot like having ADT (which will take
corrective action when an aberration is detected).

Encryption / VPNs

A perfectly secure perimeter becomes useless the first time that a user
accesses the network from off-site. It is absolutely vital that
off-site traffic is encrypted either by using encrypted protocols or by
tunnelling through a VPN. As the move to single-sign-on completes and
users are forced to remember fewer and fewer passwords, it will become
even more vital that encrypted protocols are preferred and enforced
throughout all organizations. It is a good idea on-site and it is an
absolute requirement for remote access.

In many cases most expense can be avoided, simply by using the more
secure version of a protocol.

• Replace Telnet with SSH
• Replace POP3 with POP3/S
• Replace IMAP with IMAP/S
• Configure SMTP-AUTH and STARTLS for SMTP
• Handle logins using HTTPS rather than HTTP

If a secure version of the protocol does not exist, then it will become
necessary to use a VPN tunnel to access the service remotely.

People Hacking

Once the network becomes fully secured and all of the illegitimate
packets have been identified and blocked and all the legitimate packets
have been encrypted within an inch of their life, the attackers will not
stop. They will simply look to find easy ways into your network that do
not require access. They will attempt to exploit the most
uncontrollable aspect of your IT infrastructure, the people.

Phishing / Pharming attacks are attempts to use social engineering to
steal organizational or personal data, which will later be used for
nefarious purposes. Commonly sought-after information includes
credentials for accessing secure systems or remote access.

How can you defend against this threat? The only answer is education.
The more that user users are indoctrinated to the secure way, the more
likely they will be to resist the temptation to just give away
organizational information to the first charming person who calls on the
telephone or contacts them via email.

Scoped Access

To help limit the threat posed by users with lax security habits, it is
wise to consider limiting the scope of access for those users. Most
users spend 80% of the time in 20% of the functionality of any
organization’s IT assets. How can access be limited such that users are
still able to perform their duties quickly and efficiently while
protecting the integrity of the organization’s IT assets.

Traditional Methods

Traditionally, organizational assets have been protected from theft by
good old fashioned lock and key. Many organizations use an upgraded
version of this technique with key-cards and access codes, but for the
most part it still holds.

The best way to keep equipment from walking away or being destroyed is
to lock it up an only allow access to people who need access to it.
This is increasingly important as more people become “power users” and
have great confidence in their technical competency and lose their fear
of technology. Especially as users begin trying to “help”, it will
become increasingly dangerous for an organization’s IT assets.

Technical Methods

As much as the physical equipment needs protection from internal
threats, the logical systems that comprise the organization’s IT
infrastructure need protection too. However, this is more difficult.
Many of the computing systems that are used today derive from older
systems which were blissfully ignorant of today’s security problems.
Technical staff are nearly always facing a balancing act between the
usability of their IT systems and the security of these same systems.

The Scariest Example in the World:

• Mail Server -> LDAP
• Admin System (student data) -> LDAP
• File server (full read access) -> LDAP
• User authenticates from off-site with POP3 or http webmail
• User uses FTP to connect to File Server

Depending on the technical resource in question, these techniques may
vary, but a few commonalities remain across various layers of the OSI
model.

• Use VLANs to limit access to hosts if possible
• Once on the host, allow as little access as possible
• Use logging to your advantage (syslog, …)
• Use privilege escalation programs if possible (sudo)
• Multiple firewalls may be necessary
• Enforce policies technologically rather than on the honor system

Risk Management

Risk Management is a systematic, analytical process to consider the
likelihood of various threats to an organization’s assets. This process
is vital to the success of an organization’s IT security initiative. By
better understanding the risks to which the organization’s assets may be
vulnerable, the organization is better able to take pro-active steps to
mitigate the risk or be better positioned to respond to the threat when
it does materialize.

It is important for all involved to see the risk analysis phase of the
IT Security Initiative as one that should be pursued frankly and
honestly. Many organizations will feel pressure to mitigate all risks,
but that is simply not possible. Any organization which believes it has
mitigated all possible risks is either not being honest, or is spending
incredible amounts of money to mitigate risks that are unlikely to ever
occur.

Phase One: Risk Identification

During the first phase of risk management, it will be important to
brainstorm about potential risks. These potential risks should include
any and all risks that could affect the organization’s IT assets. This
includes risks that cannot be mitigated or are highly unlikely to
materialize. At this point in the process, nearly anything goes.

Many of these key threats may have been previously identified in other
risk assessment processes performed throughout the organization, but
many of them will be unique to IT security. IT security poses unique
risks for the organization due to the physical and logical components of
IT. Throughout the IT infrastructure, there will be physical threats
(to wires and cabling) and logical threats (to device functionality).
Both types of threats should be identified during the risk assessment
phase of the risk management process.

Phase Two: Risk Analysis / Assessment

During the risk analysis phase of the planning process, all risks
identified in the Risk Identification phase will be researched until
they are fully understood. To fully understand the threat, the analysis
must minimally yield the likelihood of realizing the risk and the impact
of the risk if realized.

Once a basic understanding of the risks threatening the organization has
been achieved, the organization can begin quantifying the risks
threatening the organization’s IT assets. This commonly done by
assigning a weight each risk, then multiplying the weight by the
estimated likelihood of realizing the risk. The resulting number it’s
risk factor.

Example:

Risk Severity   Risk Likelihood    Risk Factor
Administrator Error:  5               60%                1
Power Outage:         10              30%                3
Equipment Theft:      10              20%                2
Data Corruption:      3               10%                0.3

Phase Three: Risk Mitigation

Once risks have been identified and prioritized, the process of
mitigating the risks can begin. The risk mitigation phase of the risk
management process is where the fun begins! Technical solutions or
procedural modifications are decided upon to address the risks
identified in the previous steps.

For each risk identified in the previous steps, one or more corrective
actions are suggested. These actions should describe as specifically as
possible what action will be taken and any costs involved. Any one
action may fully or partially address the threat, so the scope of the
corrective action should also be documented with respect to the threat,
so that it may be fully understood how much of the threat has been
addressed and how.

It may be decided that the cost of mitigating the risk outweighs the
severity of the risk if it were to come to fruition. If this occurs, it
does not mean that the risk is removed from the final document, it
simply means that the risk remains an unmitigated threat. This threat
should remain documented to prevent losing the information gained during
the analysis phase of the risk management process. That information
will remain valuable to those who will be tasked with mitigating the
risk in the future, or to those who are dealing with the risk in the
unlikely event that it comes to fruition.

Example:

Administrator Error: - Implement change management system to fully document / monitor changes to managed devices.  Costs will be minimal, since the system is in place, however some user training will be required.  Power Outage: - Most power outages last less than 1 hour, purchase one hour of backup power for critical devices.  Costs will include $n.nn per rack for essential equipment.  Data Corruption: - Data corruption of our primary database is unlikely and would be noticed
quickly, so the current backup depth of 7 days is deemed sufficient.  If
the corruption goes unnoticed for 7 days, information can be re-created
from the annual backup and all quarterly reports.

Phase Four: Implementation

During the implementation phase, any modifications to business processes
or to the technical architecture will be made. Implementation will
commonly re-use existing project management processes and will follow
normal organizational procedures for technical change.

Phase Five: Maintenance / Monitoring

Once implementation has completed, it will be important to periodically
revisit the risks threatening the organization’s IT assets. As
technology is an evolving target, it is important that an organization’s
response to those threats evolve as well.

What Goes Wrong?

Many organizations skip immediately to the risk mitigation phase, rather
than having a holistic understanding of the threats facing the
organization, they are responding to risks have have already been
realized or perceived threats that have been encouraged by vendors.

Many organizations short-change this process by choosing to ignore very
real threats to their organization, while focusing on cases that are
less likely to materialize, but are easier to address.

Policies / Procedures / Guidelines

One of the unavoidable facts of life as organizations become more formal
is that some level of policies, procedures and guidelines must be
developed. Is is important, not only for the organization, but also for
the users of IT assets to understand what is and is not permitted.
Pursuing policies, procedures and guidelines in this spirit will help
provide documents that have increased acceptance and can help the
organization achieve it’s goals.

While policies are expected to be long-lasting and are commonly
technology independent, procedures and guidelines are less formal and
more likely to change as the technology does. Policies are likely to be
modified due to the changing legal landscape, rather than the changing
technological landscape.

It is important to understand the difference, so that the most
appropriate document is drafted. Keeping documents organized as follows
can ease the load on users and the security team by insuring that there
is (only one) reasonable place for the information which should be
communicated to reside. Adoption can be greatly increased by those who
are governed by these documents if they are clear and easily understood.

Policies

Policies define acceptable behavior. IT security policies should insure
that all national, regional, and international laws are not violated.
Additionally, any organization-specific regulatory compliance concerns
could be addressed as well. One further purpose of the IT security
policy is to provide a clarification between the organization and the
user community with regard to what protections should be expected by the
users and which responsibilities are expected of the users.

As the policy approaches implementation, the policy cannot be
over-communicated. The user community should understand why the
organization has deemed the policy necessary and that there is a
legitimate expectation that this policy will be valuable in efforts to
shield the organization from security threats. Of course, the policy
should reflect this. All too often, this is not the case.

Procedures

Define a process to be followed to complete a task. Procedures normally
mirror the functioning of a technical system or a business process. IT
procedures help insure that tasks are preformed in a uniform and
standardized way.

The real benefit of having high-quality security procedures is realized
when policies, procedures, or guidelines are modified. The knowledge of
how previous IT actions were performed can help form a plan of action
that will bring all IT assets into compliance with far less effort than
would be expended without this prior knowledge.

High quality IT procedures are not unique to the security world, they
should be pursued as a part of the quality improvement process.
However, one of the best ways to improve security is by having
high quality and defensible IT and business procedures.

Guidelines

Guidelines provide general guidance in a specific arena. Commonly,
guidelines are mirrors of industry best-practices or other “good ideas”.
These guidelines are not binding as a policy or a procedure may be. In
fact, they should remain the easiest to evolve as technology or business
processes change.

Common examples of a guideline may be recommended password criteria,
preferred file transfer techniques, or other informational guidelines
that may help users of IT assets avoid future policy or procedure
violations.

What Goes Wrong?

Many times users who are subject to these policies are frustrated by
policies and will fight even very lenient policies, simply because they
do not like authority.

Yes, this is a childish response.
No, you cannot ignore it.
Yes, there are things you can do to help increase adoption.

In the weeks and months leading into the policy implementation, notify
everyone that a new policy is in development and be sure to describe why
the policy is needed.

User Buy-In: Sample groups of users review policies, supplying comments

Implementor Buy-In: Technical staff must be able to manage the new
requirements

Management Buy-In: A few high-ranking individuals to affect monetary,
legal decisions throughout the organization

Education / Training

What do we do?

Almost anything is an improvement over nothing. Oftentimes, users are
being governed by policies they have never seen. They often sign
documents indicating that they understand documents that don’t exist or
have not been provided to them. Why do they do this? For good reason.
They sign forms agreeing to be bound by employee handbooks and other
documents that are meaningless in their day-to-day work, isn’t the
security policy just more of the same.

The goal, of course, is to integrate security into their day-to-day
activities, so that security permeates their work-flow. But how do we
start with security built in? How can we convince users to modify their
processes that have been in effect for years that they are insecure?

Not only do users need to be made aware of the need for security, but
they need to understand the danger involved if security is not pursued
as a goal. The legal ramifications for educational entities alone is
enough to warrant a more aggressive stance on security. Depending on
the organization, annual or semi-annual training sessions or seminars
covering the latest security threats may be necessary.

How to Do It

Make it relevant

Above all else, it must be relevant to the user’s daily work-flow. The
users do not want the organization to be endangered, but they are more
concerned with their annual performance review where they are rated on
efficiency, but not on security. If organizational users are not able
to incorporate the security into their daily activities without
decreasing productivity or requiring extra effort, they will likely
ignore any ramifications their actions may have with respect to this
ethereal “security” thing.

To help keep the training relevant, it is best performed in small
groups, departmental units are best during dedicated times when they
will be free to ask questions and play out “what-ifs”. Likewise, it
will be important to have administrative buy-in to the educational
process or it is likely that users will not attend any training
sessions.

Get Help

Increasingly, financial auditors are concerned with the technological
solutions organizations are using to store their information.
Interacting with the audit staff or organizational personnel who are
more versed in the regulatory compliance world and who may lend a
perspective that is easier to digest by the user community.

When do we do it?

Just like voting, education is best done early and often. One of the
best times to introduce staff to organizational security measures is
during the new employee orientation. This starts the users off with a
base understanding of why certain security measures are in place and how
they can help protect the organization from internal or external
threats.

It’s Hard!

Too bad! Your organization and your users are depending on you. You
have to make the information available in ways that they can understand
for them to have a fighting chance.

Don’t Forget Physical Security

Physical security has long been underestimated, however it remains one of
the most common causes of failures of servers and networks. When the
hardware is stolen, it cannot operate properly.

Most organizations have made great strides in these areas, protecting
their IT infrastructure from external threats, however many have
underestimated the possibility of internal threats.

Note: If you have not protected your equipment from external threats.
Stop reading this, go to the locksmith and start now.

I mean it. Get out of here. Go do it now.

Cyber Attacker Profile: Teh J4n1t0R

One of the most 1337 haxxors in any organization is Teh J4n1t0R (the
janitor). This notorious villain has been consistently wreaking havoc
since the dawn of computing.

We joke about Teh J4n1t0R. All staff have a role to play in the
organization, but Teh J4n1t0R is a great illustration of the danger
presented by internal staff. Teh J4n1t0R has unlimited physical access
to your IT infrastructure. Teh J4n1t0R is well meaning. Teh J4n1t0R
works hours when his work will not be noticed.

The difference between Teh J4n1t0R and an outside attacker may only be
in the intent. The end result is often the same. Luckily, the work of
Teh J4n1t0R is often easily repaired once his work has been discovered.
Errant unplugged or overplugged cables cause annoying outages, but
their damage is generally not permanent.

Tiered Physical Access: Defending Against Teh J4n1t0R

Physical security to your organization’s assets should be tiered, only
permitting those with appropriate credentials access to vulnerable
infrastructure. Such a tiered access model may be simple or complex.
For most small to medium organizations, it can be accomplished quickly
and effectively.

Since IT infrastructure extends to all corners of the organization, there
may be additional technical steps which should be taken to insure that
damage done on the edge of the network does not permeate throughout the
organization.

Example: Tiered Physical Access for a Building

Building 1A
- Public Areas
- Staff-only Areas
- Departmental-only Areas

One-Time Cost: $200.00 - $500.00 for locksmith fees

Cyber Attacker Profile: Teh 5t0Rm

Unlike Teh J4n1t0R, Teh 5t0Rm is truly menacing and is much more likely
to cause damage that cannot be repaired. Teh 5t0Rm can attack at any
time, sometimes right under the nose of trained IT staff.

Attacks from Teh 5t0Rm are often short in duration, but can be
devastating in their scope. Damage can range from simple power outages
to complete devastation of the organization’s IT infrastructure.