Implementing
an Effective IT Security Program
Abstract
The purpose of this paper is to take the wide variety of federal
government laws, regulations, and
guidance combined with industry best practices and define the essential
elements of an effective IT
security program. The following are five critical elements of a
security:
1. Periodically Assess Risk
2. Document an entity-wide security program plan
3. Establish a security management structure and clearly assign
security responsibilities
4. Implement effective security-related personnel policies
5. Monitor the security program’s effectiveness and make changes
as necessary
Periodically Assess Risk
Assessing your organization’s risk is one of two beginning
steps in developing a security program.
The other is establishing a security management structure and clearly
assigning security responsibilities. The latter is more difficult
in a large decentralized organization and takes much longer than
you would think. This will be discussed in further detail later
in this paper. As you are formalizing your structure, risk assessments
and mitigations strategies are still going to need to be accomplished.
Without having an understanding of your risk you are unable to determine
the proper security policies, procedures, guidelines, and standards
to put in place to ensure adequate security controls are implemented. A
risk assessment has three major components – threat assessment,
vulnerability assessment, and asset identification. Threats
can be grouped in many different ways. We will use 4 categories
– malicious insider (disgruntled employee, contractor, insider
theft), accidental insider (poorly trained, curious) malicious outsider
(hacker, industrial espionage) and natural (fire, flood). This is
not intended to be all-inclusive, but to get you thinking in the
right areas.
1. INFOSEC Documentation
a. Do you have a security plan, risk assessment report, contingency
plan, configuration management
plan, and security, test, and evaluation report?
b. If so, what are the dates, if not when are they planned?
2. INFOSEC Roles and Responsibilities
a. Does this system have an Information Systems Security Officer
(ISSO) assigned?
b. Do you know who your Designated Approving Authority (DAA) is?
(This is the executive
responsible for the security of the system)
3. Identification and Authentication
a. What password policy does your system enforce?
i. Number of Characters (minimum 7 or 8)
ii. Complexity (3 of following 4- upper and lowercase, numbers,
special characters)
iii. Aging (90 days – max)
iv. Account Lockout (5 attempts)
v. What method do you use to encrypt passwords in transit and in
storage? (key type, key length, etc)
b. Do you have a procedure for identifying users before resetting
passwords?
4. Account Management/Access Controls
a. Do you have a method of authorizing new accounts and getting
rid of old accounts?
b. Do you have a process to limit access based on job function and/or
roles?
c. Do you regularly review your access control lists, if so how
often?
d. Do you give individuals only enough access to do their jobs?
(i.e. Least privilege)
5. Session Controls
a. Do you enforce each user to be logged on with only one session?
b. Do you enforce password protected screen savers?
6. External Connectivity
a. Does this system have any external connectivity?
i. Wireless (describe controls)
ii. Internet (describe controls- e.g. VPN, FW, etc)
iii. Dial-in (describe controls- e.g. authentication method, encryption,
etc.)
7. Security Products
a. Do you use a firewall (briefly describe what is and is not allowed
to this box)
b. Do you use an intrusion detection system? (host, network, briefly
describe configuration)
c. Do you use a policy compliance tool or agent?
d. Do you use vulnerability scanning tools?
e. Do you use encryption? If so, describe (symmetric, asymmetric,
key lengths, etc.)
8. Auditing
a. Do you have auditing turned on?
b. What events are you auditing for?
c. How often do you review audit logs?
9. Virus Protection
a. Do you have virus protection installed?
b. How often is it updated and is it automatic?
10. Contingency Planning/Backups
a. How often do you do back-ups?
b. Do you have procedures to restore system?
c. How many people could restore system?
d. How long would it take to restore system?
e. Where do you keep your backups in relation to your system?
f. Do you have a contingency plan that includes continuity
of operations?
g. Have you tested your back-up procedures?
11. Maintenance
a. Have you hardened the system using NSA Hardening Guides or other
Industry hardening guides?
(explain)
b. Have you applied all applicable security patches?
c. Have you secured your systems using the SANS Top 20?
12. Configuration Management
a. How do you do change management?
b. Do you have a separate system to test changes?
c. Do you have a configuration management plan?
13. Media Sanitization/Disposal
a. Is your data sensitive, so that it should not be obtainable upon
disposal?
b. What method do you use to dispose of data?
i. Hard drive (Triple overwrite, degauss)
ii. Tapes (degauss)
iii. CDs (incinerate, chemically destroy)
iv. Paper (shred)
14. Physical Environment
a. Are your servers in a locked room with tight access controls?
b. What kind of access controls does your building have?
c. Are there any special considerations that need to be taken into
consideration based on building
location? (hurricanes, floods, etc)
d. Is your system protected from environmental threats? (heat, fire,
water, etc)
15. Personnel Security
a. Are your users trained on the security of this system or have
they taken security awareness
training?
b. Have your users read the rules of behavior for either this system
or organizational rules or policies?
c. Have employees and/or contractors who have privileged access
to this system undergone
background investigations?
d. Do you have separation of duties between programmers and administrators?
(If not, what do you use
to prevent abuses)
16. Incident Handling/Security Advisory Handling
a. Briefly describe your process to handle incidents
b. Briefly describe your process to handle security advisories
17. Security Awareness Training/Security Training
a. Have you provided security awareness training to all employees?
b. Is security awareness an ongoing activity throughout the year?
c. Are your security officers, system administrators, senior executives,
system program managers,
and business/functional managers trained
in their security responsibilities?
The answers to these questions along with some random sampling of
specific technical controls
will give you a basis for your vulnerabilities. Before you begin
the daunting task of asset analysis,
you can quickly identify and mitigate some of the highest risk items
that you discovered in your
vulnerability phase. I know the textbook solution is to analyze
likelihood of exploitation against
impact to asset and rank the risks accordingly, but certain hardening
and patching steps should
be taken immediately upon vulnerability discovery and cannot wait
for the completion of a
comprehensive report. This is where it is essential that common
sense be used. When you have
completed these three steps you can then compare the threats to
your systems (which house
your information) to the vulnerabilities you have found and balance
that against the need and cost
to protect the confidentiality, integrity, and availability of that
asset. There ends up being a lot of
professional judgment that goes into this analysis. Unfortunately
as we become more and more
connected with our internal systems as well as external systems,
it is becoming increasingly
important to put a fair amount of management, operational, and technical
controls on all of our
systems. For example, you may have an intranet web server that has
no access to the Internet
and does not carry any sensitive data. You do your CIA analysis
and determine that there is little
need for confidentiality, integrity, or availability. Management
may determine that if something
happens to that server it can be rebuilt and back on line in a few
days with no effect on business
operations. This may not be the right decision. A home user that
dials in can infect that server.
Analyzing connectivity becomes very important in this analysis.
You have defined your assets, looked at the threats against you,
and determined the vulnerabilities
you have. You know where your greatest risks reside. For those high
risks you will need to do short
term hardening, patching, etc. You will not be able to wait the
year or more it takes to develop sound
policies, procedures, and standards in a large decentralized organization.
The cyber-criminals are not
going to wait until you coordinate your new firewall policy through
three layers of management before
you cut-off some new dangerous threat. In spite of short-term tactical
necessity, sound policy,
procedures, standards, and guides are critical in ensuring the long-term
security of your assets.
In addition to an initial review of your security risks, risks should
be assessed on a continuing basis as
new threats and vulnerabilities manifest themselves and new assets
are put into operation.
You have now completed the first critical element of the security
program – the risk assessment.
Now it is time to develop the security program plan. Document an
entity-wide security program plan
There are many different opinions on what should go into an entity-wide
security program plan.
I have found these six general areas to be the most valuable.
1. Security management structure and security responsibilities
2. Security Policy, procedures, guides, and standards
3. Security Training and Awareness
4. Incident Handling and Security Advisory Handling
5. Compliance Reviews and Enforcement (including vulnerability scanning
and penetration
testing)
Security management structure and security responsibilities
This is a very
important step and needs management buy-in throughout the organization.
It is the first step in creating an entity-wide security program
plan, but it is also one of the critical
elements in the overall program.
System Administrator – Responsible for the day-day
care and feeding of the system to include
security hardening and patching, backups, etc.
Data Owner or Business/Functional Manager – Helps
set the requirements for the level of protection
needed for their process or data. Now that we see an example of
an ideal structure on paper, I would
like to describe where this structure has some challenges in actual
implementation. A couple of big challenges are related to the DAAs.
In organizations that have matrix management, coupled with both
centralized and decentralized processes and information technology,
it is a challenge to determine
exactly who the DAA is. Another challenge lies in the fact that
the DAAs sometimes take on more
risk than they really should be allowed to. Up until now, both corporate
America and government have
not held their senior executives accountable for security breaches
very often. Until some of them are
held liable for lacking due diligence, this trend will continue.
Another big area is the relationship
between the system administrator and the information systems security
officer. The ISSO is
responsible for ensuring the security of the system, but in many
cases they either do not have
management backing or they do not have the technical expertise to
ensure the systems are operating securely. They rely on the system
administrator who is primarily concerned with keeping the
system running. In some cases, the system administrator is the security
officer. This often increases
the technical security controls of the system, but this person is
generally very overworked and is not
able to create the plan and procedural documents that ensure the
long term security of the system
and keep the auditors happy. There is also the question of separation
of duty and the fact that many
system administrators are contract employees who may have less than
a vested interested in the
company. Until management takes security more seriously and some
of the reporting requirements
are reduced, I think we are heading down a dangerous path. Everyone
from auditors to budget
managers to customers are demanding more prove of how secure the
systems are, but the more
reporting you have to do the less time you have to secure the system.
I believe we need to move
toward a more minimalist approach to documentation and only document
the processes that are
absolutely necessary. I have seen too many hundred page security
documents sitting on shelves and
too much time wasted creating them. Finally, even though the security
responsibilities are defined,
individuals need to have their yearly performance reviews or in
the case of senior management their
bonuses incorporate security related incentives and/or disincentives.
Since few system administrators, system program managers, or senior
executives are rated on their security posture, things will be
slow to change.
Security Policy, procedures, guides, and standards
It is now time to document your security policy. All security documentation
to follow will be based of
your security policy. (Some more direct than others). Where do you
start? There are a number of good
places to help you formulate and document the requirements to go
into your policy including public law (especially if you are a government
agency), your risk assessment, OMB A-130, NIST 800-26, and
Charles Cresson Wood’s “Information Security Policies
Made Easy”. A combination of high level and
detailed policies are necessary to achieve your security goal. I
know there are a couple of different
camps on how detailed policies should be – ranging from “All
systems shall authenticate their users
before they are allowed access” to “All systems shall
employee a minimum of 8 character passwords,
using a combination of special characters, letters, and numbers
which are changed every 90 days and
not repeatable up to 10 iterations.” To keep your enterprise
consistent, I favor the latter, but being that
detailed may not work in some organizations.
Allowing flexibility in policy using risk-based decision-making
is also very important
Table 1
| Management
Controls |
Vulnerability
Assessment Mapping |
| 1. Risk Management |
Risk Assessment Itself |
| 2. Review of Security Controls |
InfoSec Documentation |
| 3. Lifecycle |
Configuration Management |
| 4. Certification and Accreditation |
InfoSec Documentation |
| 5. System Security Plan |
InfoSec Documentation |
| Operational
Controls |
|
| 6. Personnel Security |
Personnel Security |
| 7. Physical Security |
Physical Environment |
| 8. Production, Input/Output Controls |
Media Sanitization/Disposal |
| 9. Contingency Planning |
Contingency Planning/Backups |
| 10. HW/SW Maintenance |
Maintenance |
| 11. Data Integrity |
Virus Protection |
| 12. Documentation |
InfoSec Documentation |
| 13. Security Awareness and Training |
Security Awareness and Training |
| 14. Incident Response |
Incident Handling/Security Advisory Handling |
| Technical
Controls |
|
| 15. Identification and Authentication |
Identification and Authentication |
| 16. Logical Access Controls |
Account Management/Access Controls Session Controls |
| 17. Audit Trails |
Audit
Security Products External Connectivity
|
| |
|
Technical
Controls
15. Identification and Authentication Identification and Authentication
16. Logical Access Controls Account Management/Access Controls Session
Controls
17. Audit Trails Audit Security Products External Connectivity
Implement Effective Security Related Personnel Policies
This is also
a very challenging area because it forces you to coordinate and
get concurrence with
many different organizations to make it work. It involves labor
relations, human resources, legal,
and contracting people. The following control areas for personnel
security are outlined in GAO FISCAM.
1. Background checks
2. Reinvestigations
3. Nondisclosure agreements
4. Regular vacations and shift rotations
5. Termination and Transfer Procedures
a. Return of equipment, ID, keys, etc.
b. Termination of User IDs and Passwords
c. Identifying Non-disclosure period effectiveness
6. Skills needed are identified in job descriptions and employees
are rated against those skills
7. Employee has a training plan and training is documented and monitored
I have found that other than training which is covered in other
areas, that background checks and
termination and transfer procedures are critical in minimizing insider
risk. This is especially true with
the proliferation of contractor and temporary employees. Regular
vacations and shift rotations are a
great idea, but in this day of massive downsizing and doing more
with less it is not always practical
to have the only person that knows the job be gone at a critical
time. I realize that there should always
be backups for everything, but management does not always want to
budget for it.
Monitor the Security Program’s Effectiveness and Make Changes
as Necessary
Monitoring the
effectiveness of the security program can be one of the most challenging
aspects of
running a security program, but also one of the most important.
This is where the rubber meets the
road. You have assessed the overall risk, created a program plan
and security policies. You have given
out guidance and trained the individuals in implementing the policy.
Now it’s time to see if you have
actually increased the security posture of your organization. In
large organizations and limited
centralized IT Security staff you will have to rely on a combination
of self-reporting and hands on reviews.
These can include the following:
1. NIST 800-26 reviews with supporting documentation
2. Vulnerability and system scanning of technical controls and system
vulnerabilities
3. Random onsite checks of operational and technical controls
4. Specific security policy compliance reviews
5. Audit finding reviews
Although the entire version is very cumbersome, a tailored version
of the NIST 800-26
“Self Questionnaire” is a good place to start. It lets
individual major applications and general support
systems report back centrally on the status of their security controls.
It is broken down into the 17
control areas defined in table 1. It further asks you whether or
not you have created policies, created procedures; implemented,
tested, and fully integrated each of these control areas into the
security
of your system. As you implement each of the five levels - policy,
procedures, implementation, test,
and integration you move further up the maturity level. This is
very similar to the Software Engineering Institute’s Capability
Maturity Model (CMM) for software development.
It is critical
that you use a common sense approach when implementing this or you
can get very
bogged down in a lot of documentation that does not really increase
your security posture. Quickly
getting at the critical elements by having your system security
officers first perform a risk assessment
and create a security plan for their system will greatly enhance
the usability of this tool.
The other methods
listed above can also be implemented via a variety of actual hands-on
review
and/or tabletop review of documentation. Much of it depends on the
amount of resources you have
and how successful your experience is with self-reporting. In many
cases, self-reporting
does not uncover serious vulnerabilities.
We have now
completed a variety of program monitoring and have come up with
a variety of
weaknesses based on a lack of implementation. The next step is to
uncover why. Is it because the
policy and guidance is not clear? Is it a lack of resources, expertise,
or management support? Do
some people just not care about security?
The answer is
all of the above. That is why it is critical to get out and talk
to your system
administrators, security officers, business and system program managers
and upper level
executives. You have to work with them to come up with a viable
solution to their problems with implementation. You have to make
sure that your office becomes a central focal point and that
different divisions can leverage off your expertise as well as the
expertise of others in the organization.
You have to attack the most critical areas first and leave the rest
for another day. They will vary
somewhat for different systems, but the SANS “Top Twenty”
is a real good place to start. It is
critical to get buy-in from the top down and the bottom up to maintain
an effective security program.
If people do not believe in the process they will go through the
motions, but you will not be very
successful. On the other hand, you will always have individuals
who do not want to follow the rules no
matter what and you do need to be able to enforce the policies on
those individuals.
