COMPONENT
I. The Security Organization
A single person should have overall responsibility for security
with a steering committee representing each site/division.
Designate primary and alternate Site Security Representatives
(SSRs) for each location. SSRs are the most critical component
of the security program. SSRs walk the walk (lead by example),
are security advocates (explain why security is important)
and fight the good fight (actively support the security
program).
Reach
out to senior management and gain their formal endorsement
of the security program. I recommend providing the CEO with
a letter template briefly stating that security is a priority,
introducing the security organization and providing a brief
overview of the framework in use.
COMPONENT II. Policies, Procedures and Documentation
Policies,
procedures and documentation must exist for the security
team, network operations, system administration, development,
and the rest of the organization. Continuity should be maintained
through detailed process documentation, procedures manuals,
configuration standards, build documentation, and change
logs. Track software licensing and tech/hardware support
contracts. Disaster recovery and business continuity plans
should ensure operations continue in the event of an emergency.
These documents are not created in a vacuum. I work with
the staff to devise methods that increase security and continuity
with minimal impact on their productivity. All documentation
must be kept current to remain effective.
COMPONENT III. Access Control
Use a role based
model to issue accesses by job function. Accesses should be formally
requested by a supervisor, approved by a data owner and implemented
by a system administrator. A process must also be in place to
systematically rescind accesses when roles change or when personnel
are terminated.
COMPONENT IV. Security Awareness
Reinforce
security policy and educate personnel about threats and
counter measures with a security awareness program. Create
a security web site to provide security contacts, an incident
report template and policies and procedures. All personnel
should attend a security briefing on their first day and
on an annual basis thereafter. Topics should address general
security policies (e.g. physical security practices, screen
lock workstations, clean desk policy, etc.). Document attendance
of awareness training sessions and include a testing component.
COMPONENT
V. Infrastructure Stability (Prevent)
If
infrastructure is solid, there will be less fire fighting.
The team can focus on new projects, threats and vulnerabilities.
The first step is to stabilize existing infrastructure.
Redundancy must be present throughout the networks, hosts,
power, and HVAC systems. High availability and monitoring
testing should be conducted against systems, networks, commercial
and custom applications. Critical systems must also be restored
from backup.
Systems and software should be hardened against attack.
Hardening must be accomplished throughout critical systems
and applications. Define the network perimeter and protect
with firewalls, application proxies and anti-virus software.
Establish granular inbound outbound firewall rule and block
services that allow unauthorized external access to the
network (e.g. GoToMyPC, pcAnywhere and Citrix Online).
New infrastructure should be constructed in accordance with
standards, with hardening and high availability components
built-in.
COMPONENT VI. Monitoring Program (Detect)
A layered monitoring program should immediately alert the
operations team when there is a systems issue. System monitoring
software should oversee hosts, networks, environmental conditions,
web sites, logs and commercial and custom applications.
Security monitoring should consist of: intrusion detection,
vulnerability assessment, anti-virus, content filtering
and authentication software. In addition to commercial software,
I recommend the use of custom scripts and freeware to monitor
disk space, processes, performance and applications. This
level of monitoring often prevents outages before they occur
(defense in depth). Monitoring software should be integrated
into the help desk ticketing system monitored by the Network
Operations Center. If possible, escalation should be configured
into the notification process.
Here is an example of how web sites should be monitored:
Monitor the root URL of the site and ask developers to build
servlets so that other site functional components can be
monitored (e.g. login, application pools, database logins,
etc.). Servlets should respond with text that states a service
is up or down. Monitor the root URL and servlets externally
from multiple sites around the world with a service like
http://www.dotcom-monitor.com.
Notification should be sent directly to pagers with no dependence
on internal mail infrastructure. Monitoring in this manner,
the operations team will know which layers are involved
when there is an outage (internet connection, web server,
app server or database server).
COMPONENT VII. Incident Response (Respond)
When an outage, attack or disaster occurs, operations personnel
need to respond decisively, in a coordinated manner. A formal
incident response process must exist and be properly documented.
Essential elements include response procedures, on-call
operations personnel, recall rosters, and incident reports.
Response teams should consist of system administrators,
network administrators, telecommunications personnel, database
administrators, backup administrators, and custom applications
support.
Incident
reports should include cause, notification process, technical
details, fix action and conclusion. In a follow up meeting,
discuss what could have been done to prevent the incident,
what prevents it from reoccurring and what additional actions
or research need to happen.
COMPONENT VIII. System Development
Custom applications must be developed with security controls
built-in rather than bolted on later. To help ensure stability,
build environments must separate development from production
(e.g. DEV, QA, UAT, stage and demo). Builds should be automated,
with software stored in a code repository. As builds are
pushed through development environments into production,
build-specific validation tests should be repeated and incorporated
into functionality monitoring.
COMPONENT
IX. Physical and Personnel Security
Physical security concerns include the perimeter, loading
docks, lobbies, computer rooms, office space, ID access
cards, access lists and escort procedures. Ensure that security
checkpoints are not overwhelmed during periods of peak traffic.
Thoroughly train receptionists on all security policies
and procedures with a focus on social engineering. Personnel
security must address background checks and systematic removal
of accesses. Document how employees, contractors and temps
are in-processed and out-processed. Systematic processes
must be in place so that when a person leaves or their role
changes, the appropriate accesses are rescinded. These procedures
should encompass physical accesses, logical/system accesses
and company property (e.g. laptops). Human resources should
also ensure that employees sign the appropriate policies
during in-processing (e.g. non-disclosure agreements and
security policies).
COMPONENT X. Disaster Recovery
Disaster recovery (DR) measures must be practical and targeted.
Start by conducting a business impact analysis and assign
each system a business criticality rating. Determine which
DR methods meet business requirements (e.g. hot site, cold
site or reciprocal). Critical paper records should be scanned
or copied and stored off-site. Ensure backups are secured
and transported off-site in a timely manner. Prepare for
short-term disruptions such as power outages. Start by documenting
how to stop and start the computer room with dependencies.
Next, establish data replication and failover capabilities
between sites. Test procedures upon creation and repeat
annually.
COMPONENT XI. Audit
Audits
provide a snapshot of a site's security posture. Use risk
assessment techniques to determine specific audit objectives
and scope. Internal protection is typically scarce. Audit
for appropriate compensating controls. Interviews of key
personnel should be supported by evidence
where possible (e.g. system configuration files or documentation).
Findings should be categorized and addressed according to
level of risk. Annual compliance audits are needed to ensure
that established procedures and configurations are still
in place and to discover new vulnerabilities (Trust,
but verify).
The overall objective of my program is to protect the organization
by managing risk in a cost-effective manner. The benefits
are stability and protection from fraud, waste and abuse.
The underlying IT governance component also conserves resources
through the efficiencies inherent in standards and oversight.
As a successful security advocate, I convince the staff
that the benefits far outweigh the cost.
Copyright © 2002 - 2008 Gideon T. Rasmussen All Rights Reserved.
Legal Notices
|
