For over ten years Aspiration Software LLC has been a valued supplier of Cyber and Information Security service to the Intelligence Community and related Department of Defense clients.

3 | WHITE PAPER |

Source Tripwire

The number of security breaches of federal information sys-
tems and cases of improper access to these systems continues
to grow at an alarming rate. In fact, federal civilian agencies
reported three times more cyber security incidents in 2008 than
in 2006, according to the Department of Homeland Security
(DHS). And that’s just the number of reported incidents; an
official at the DHS believes the number may be higher.1
A quick Internet search reveals the continued pervasiveness
of security breaches of federal information systems. The fol-
lowing represents a fraction of the security incidents that have
been reported already this year:

• Three State Department contractors, out of “idle curiosity,”
viewed passport files of over 150 high-profile individuals,
including actors and politicians from 2002 to 2007.2 Access
to these files is only permissible when necessary to perform
official government duties.

• In mid-March of this year, a Romanian hacker was arrested
by Romanian police and potentially faces up to 12 years in
jail. The hacker, who called himself “Wolfenstein,” broke into
the U.S. Department of Defense in 2006 and compromised
servers and attempted to cover his tracks by deleting access
logs.3

• On February 11, 2009, unauthorized access to a computer
in the Federal Aviation Administration’s (FAA’s) network
may have exposed the personal information of over 45,000
employees and retirees of the FAA.4 The FAA claims the serv-
er was not connected to the operation of air traffic control.

• Sometime before February 11, 2009, Govtrip.com, the web-
based service that handles reservations for a dozen or more
U.S. federal agencies, was hacked and changed so that gov-
ernment employees visiting the site were redirected to a site
that installed malicious software on employees’ computers.
A spokesperson from the General Services Administration
believes that no user information was compromised.5

In response to this tremendous increase in detected and report-
ed incidents, the Obama administration has intensified its focus
on cyber security across all federal agencies. Evidence of this
heightened focus is President Obama’s mandate on February 9,
2009, for an immediate 60-day review of the “plan, programs,
and activities underway throughout the government dedicated
to cyber security.”

This brings up an enormous challenge and highlights an
uncomfortable truth: cyber security breaches and failures
continue to occur, despite federal organizations putting
tremendous time and money into cyber security. And compli-
ance activities often focus more on generating paperwork to
prove compliance than creating controls that prevent security
breaches and enable their quick detection and recovery, further
complicating the issue.

Clearly, there is concern about and a desire to improve the
security of federal information systems. So where and how do
we as information security professionals begin to address the
challenge faced not only by those responsible for ensuring the
security of federal information systems?

In this paper, we turn to Gene Kim, Tripwire CTO and found-
er, and co-author of Visible Ops Security: Achieving Common
Security and IT Operations Objectives in 4 Practical Steps, to
answer that question and provide seven practical steps any
information security organization can take to improve infor-
mation system security and achieve compliance with relevant
regulations, standards and internal security and operational
policy.

Before launching into the seven practical steps, we’ll take a
look at recent activities the U.S. Government has undertaken to
provide cyber security for its information systems.

The Federal Information
Security Management Act

The Federal Information Security Management Act of 2002,
(FISMA) is a prime example of a cyber security effort by the
United States Government that shows improved security on
paper, but has been found difficult to apply. When FISMA was
enacted, its purpose was to ensure that federal agencies secure
the information contained in the non-defense information sys-
tems of the Unites States government. FISMA not only applies
to federal agencies, but also to any contractors or organizations
responsible for these information systems.6 FISMA outlines con-
trols that are valuable and necessary for protecting information
systems.

GRADES FOR FISMA COMPLIANCE RISE, BUT SO DO
SECURITY BREACHES

Unfortunately, many see FISMA compliance as a bureaucratic
paperwork drill capable of generating a room full of documents
to provide evidence for an audit. Each year, the U.S. Office
of Management and Budget (OMB) produces a report card for
the FISMA compliance level of each federal agency subject to
the act and provides an overall grade for federal information
systems. These grades have trended slightly upward in recent
years, with the grades for 2005 through 2007 being D+, C- and
C, respectively, and a recent OMB report for fiscal year 2008
indicates that cyber security continues to improve.7 Yet with
costs for FISMA projected to balloon from $5.5 billion in fiscal
year 2006 to a total of $27.9 billion between 2008 and 2012,8
an uncomfortable question must be raised:

Why has the effectiveness of cyber security programs not increased given
FISMA scores and the cost for FISMA compliance have?

NEW APPROACHES TO CYBER SECURITY AND FISMA

As the frustration of understaffed agencies trying to meet and
prove compliance to FISMA continues to grow, a new initiative
has gained support. This initiative, the Consensus Auditing
Guidelines (CAG), identifies the high priority security holes to
protect from attacks. Rather than competing with FISMA, CAG
specifically addresses one of the calls to action of the in-prog-
ress update to FISMA 2008—to establish “a prioritized baseline
of information security measures and controls that can be con-
tinuously monitored through automated mechanisms.”

On top of the CAG initiative, FISMA has recently begun to
emphasize measuring security performance. This shift in focus
will require effective controls, especially around the correctness
of configurations and the enforcement of change control pro-
cesses. John Gilligan, former Air Force CIO, and the individual
driving CAG, reiterated the relevance of correct configurations
to cyber security and FISMA, citing that during the NSA vulner-
ability scanning of the Department of Energy, over 80 percent of
successful breaches took advantage of misconfigurations in soft-
ware.9

In a radio interview, Mr. Gilligan stated that this source of
security risk was a significant driver of some of his other initia-
tives and activities, which include development of the Federal
Desktop Security Standard and his efforts to reform FISMA.
The seven practical steps described in this paper reaffirm Mr.
Gilligan’s view of misconfigurations, emphasizing the need to
gain situational awareness and control over access, configura-
tions and change.

Characteristics of High- performing IT Organizations

The recommendations in the Visible Ops Security Handbook
are based upon the results of an almost 10-year study of IT
operations and information security organizations. The study
identified the characteristics of high-performing IT organiza-
tions—those organizations that consistently had the best
security, the best compliance posture and the highest ability
to maintain predictable and reliable IT operations.

These top performers had figured out how to build sustainable security
controls that integrated into daily IT operational processes and
delivered value to other organization stakeholders.

Studying these high performing IT organizations revealed
how to simultaneously maintain an effective security posture,
while complying with regulatory requirements. These high-
performing IT organizations were:

• Organizationally aligned—High performing information
security teams understand how security advances and pro-
tects organization goals. Low performing teams focus on
things the organization doesn’t care about, like the improb-
able or irrelevant and other technological minutia. Often
other groups in the organization consider these low perform-
ing teams hysterical.

• Plugged in—High performing information security teams
integrate into the right functional groups even though they
don’t have direct operational responsibility. Low perform-
ers aren’t present where the work is done and often expend
effort helping the wrong people, reinforcing the perception
that information security is irrelevant.

• Adding value—High performing information security teams
provide value to organization and IT process owners, and
they know what they need from these process owners in
return. Low performers don’t help advance the operational
objectives of their colleagues, nor do they clearly articulate
what they want people to do differently to meet information
security requirements. Consequently, these low performers
are often viewed as incompetent.

For these organizations, information security simultaneously
enabled the organization to respond more quickly to urgent
organization needs and helped provide stable, secure and pre-
dictable IT services.

The Seven Practical Steps

In the seven steps discussed in the remainder of this paper,
we’ll learn how to gain control over production and applica-
tion/service development processes at the relevant parts of the
lifecycle and we’ll start generating value for the relevant par-
ties. By doing this, we replicate the observed high-performing
characteristics. We’ll also be able to simultaneously achieve
cyber security objectives while simultaneously achieving and
maintaining FISMA compliance objectives.

STEP 1: GAIN SITUATIONAL AWARENESS

To determine the magnitude of the organizational and technol-
ogy risks so that we can better prioritize our efforts, we must
first identify what technologies are being used, what they are
being used for and who is responsible for their management.
We can do that by answering the following questions:

• What IT services are being provided to the organization
related to cyber security or FISMA compliance (e.g., exter-
nally facing Internet systems, systems that have personally
identifiable information (PII), etc.)?

• What are the organizational and IT units, and how are they
managed (e.g., the centralized IT services group, an IT out-
sourcer, etc.)?

• What are the other relevant regulatory and contractual
requirements for the organization process (e.g., HIPAA, NERC,
interagency agreements, contractual service level agreements,
the Freedom of Information Act (FOIA), etc.)?

• What technologies and IT processes are being used for an
in-scope asset (e.g., Microsoft Windows Server, Sun Solaris,
Oracle, Microsoft SQL Server, etc.)?

• Are there any high-level risk indicators from the past to be
aware of (e.g., repeat audit findings, frequent outages, etc.)?

STEP 2: REDUCE AND MONITOR PRIVILEGED ACCESS
Excessive access and privileges to all levels of the IT environ-
ment—application, database, operating systems, network and
firewall—can allow individuals to modify or disable security
configuration settings, shutdown or disable critical services
or alter critical application functionality. Such uncontrolled
change may disrupt service and create unnecessary security
vulnerabilities.

In this step, we take the following measures to ensure users
have appropriate access and privileges to critical systems:

• Document all administrators with privileged access and
ensure we can reconcile them with authorized staff. Disable
or delete any ghost accounts that cannot be reconciled to
authorized staff.

• Work with system managers to reduce the number of admin-
istrators to the practical minimum needed.

• Ensure that access is appropriately revoked or assigned in
response to personnel turnover or transfers.

To ensure the measures listed above reduce privileged access,
we must:

• Monitor privileged user account adds, removes and changes
wherever they are stored, including service accounts that do
system maintenance and tasks such as backing up accounts
and managing the enterprise batch scheduler.

• Reconcile each privileged user account add, remove and
change with an authorized change order from the relevant
manager. This reconciliation process may be manual (a signed
paper form) or automated (with a change ticket from a
change management system).

• Reconcile each privileged account with an authorized user.
For example, reconcile the account with an HR record.
Alternatively, reconcile each account with an authorized ser-
vice such as a backup program.

• Routinely re-accredit accounts—quarterly or yearly, depend-
ing on turnover—to ensure that management can reconcile
privileged accounts to reports from HR and payroll.

STEP 3: DEFINE AND ENFORCE CONFIGURATION
STANDARDS

All layers of the IT infrastructure have configuration and logi-
cal security settings designed to limit the risk of human error,
fraud and security incidents by ensuring that the technology
only performs as expected. Examples of these settings include
proper password settings, network configuration settings and
logical security settings for the database. Risk can be intro-
duced if these settings are improperly configured.

In this step, we use guidance from respected third parties
and vendors like the Center for Internet Security, the SANS
Institute and the National Institute of Science and Technology
(NIST) to ensure our configuration and logical security settings
are properly defined, implemented and verified.

To ensure adherence to configuration standards, we must:

• Work with IT management and relevant managers on a policy
that defines which security standard or standards should be
used.

• Mandate that all production technologies that pose a risk to
cyber security or FISMA related objectives use these secure
configuration settings, and create a plan for deploying tech-
nologies with these settings.

• Define a time limit for initial implementation, and set expec-
tations for how quickly corrective measures must be taken on
non-compliant configurations.

To ensure the above configuration controls are implemented
correctly, we must:

• Assess and continuously monitor configuration settings. For
example, we may need to assess and monitor settings stored
in Unix or Windows files or Windows registry settings.

• Test configuration settings against internal security policies,
external compliance requirements and industry best prac-
tices. Report on any variances.
• Verify that corrective actions to non-compliant configura-
tions are properly implemented in the required time frame.

STEP 4: INTEGRATE AND HELP ENFORCE CHANGE
MANAGEMENT PROCESSES

Once IT systems are in a known and trusted state, all changes
made to those systems should be authorized, scheduled and sub-
stantiated by change management. To do this, we will need to:

• Help assess the potential impact of changes on information
security and operations.

• Improve procedures for change authorization, scheduling,
implementation and substantiation.

• Ensure that change requests comply with information secu-
rity requirements, corporate policy and industry standards.
To accomplish these objectives, we’ll need to do the following:

• Get invited to Change Advisory Board (CAB) meetings.
CAB meetings are used to assess risks of proposed changes,
approve or deny change requests, review the status of
planned changes, agree on implementation schedules and
review the success of implemented changes. By attending, we
have a say in the review and approval of those changes sub-
ject to the change approval process.

• Build and electrify the fence. Implement a control that
assesses configuration settings against internal and external
standards, gives visibility to changes made to systems, helps
determine whether the change was authorized and compli-
ant, and in the advent of a security breach, provides foren-
sics data to support an investigation.

• Ensure “tone from the top” and help define the conse-
quences. Words and actions from agency management on
down set the tone for the behavior of everyone in the orga-
nization. We must convince top management to set the tone
regarding information security as: “The only acceptable num-
ber of unauthorized changes is zero.” Our CIO, for example,
may be able to accomplish this by simply sending an e-mail
to all organizational units expressing this policy, explaining
the potential damage unauthorized change can cause, and
specifying consequences for those who intentionally circum-
vent policy.

• Substantiate that the electric fence is working. To prove
compliance with change management processes, we must pre-
pare for audits in advance. We’ll need the following evidence:
change requests and their approvals, changes detected on all
relevant IT systems, reconciliations of detected changes to
approved changed requests and corrective actions taken for
unauthorized changes.

By taking these actions, we will have integrated information
security into the necessary preventive change management
processes. We also will have created detective controls to
ensure that those preventive controls are working. Finally, we
will have created evidence to prove to auditors that effective
change controls exist.

STEP 5: CREATE A LIBRARY OF TRUSTED SERVER
BUILDS

When information security is not integrated into release
management processes, IT systems may be deployed without
adequate controls, resulting in negative outcomes like security
breaches and compliance and audit findings.

In this step, we create a library of known, trusted, and
approved server builds that can be used to quickly and easily
deploy an authorized, secure configuration. These secure builds
combine mandatory and recommended configurations to reduce
the likelihood of operational and information security failures
that create vulnerabilities an intruder can exploit.

To create this library, we must document the standards we
will use, which requires us to:

• Develop standards that specify how to secure and harden the
builds we release into production or check into the definitive
software library (DSL). For guidance, we turn to configura-
tion standards for information security developed by trusted
external organizations such as CIS, the SANS Institute, and
IT system vendors. As these external standards evolve, we’ll
need to update our documentation.

• Work with the server provisioning and release management
teams to integrate independent configuration standards and
checklists. We’ll also need to take standard risk-reducing
measures, such as:

· Turnoff unnecessary features and modules that are enabled
by default

· Disable un-needed services (e.g., http, DNS, and SMB)

· Disable un-needed open network ports

· Delete or disable unnecessary user accounts

· Change default passwords

• Ensure that relevant passwords are changed before systems
move from development to production—for example, devel-
opers who know ODBC and application passwords for a new
order entry system no longer need these passwords when the
system enters production.

• Include standard configuration monitoring agents in each
trusted build.

Once we’ve defined the policies and standards that create the
library of approved builds, we need to ensure these controls are
working by:

• Assessing production configurations against known inter-
nal and external standards to ensure they are in a known,
approved and secure state.

• Monitoring the approved build library to ensure that all
adds, removes and changes conform to internal and external
standards.

• Reconciling all adds, removes, and changes to an authorized
change order. This task may be done manually or may be
automated.

STEP 6: INTEGRATE INTO RELEASE MANAGEMENT
TESTING AND ACCEPTANCE PROCEDURES

To protect the production environment, information security
requires standardization and documentation; implementation
controls like checklists; and continuous control of produc-
tion variance. Release management shares many of these key
objectives. And while Development tends to focus on specific
components, release management focuses on collections of
components and whether they work together. To be effective,
release management often relies on checklists and templates.
In this step, we must engage with release management to
ensure that information security requirements are added to
their lists. To do this, we must:

• Develop templates for release management and interface with
this team as well as quality assurance (QA) and project man-
agement to ensure that information security and regulatory
compliance requirements are methodically collected at the
start of each project.

• Establish an agreed-upon protocol for when and how release
management should engage information security. For exam-
ple, an agreed-upon protocol should be established regarding
releases that include code that involve authorization, encryp-
tion, financial transactions and compliance requirements.

• Integrate automated security testing tools into the release
testing process and run them against code, builds and
releases. Use vulnerability scanning and management testing
tools, even if they could potentially crash applications during
testing—it’s better to find vulnerabilities in pre-production
rather than in production. Use the same tools in the pre-
production and production environments to prepare IT opera-
tions for potential problems when these tools are used in the
production environment.

• Compare releases and approved builds being deployed against
known and trusted states to mitigate the risks introduced
by human error, missed steps, mis-configurations and other
sources.

In some situations, the security testing conducted by QA is
sufficient for us to approve a release. In other cases, we must
conduct independent security testing. Either way, arming QA
with the same tools information security uses reduces findings
for security testing—and typically at a lower cost, with less
stress, and with higher success rates for releases—because cor-
rections are made by QA.

The previous preventive controls are the release testing pro-
tocols, including checklists and test procedures. To ensure these
controls are working, we must:

• Verify that deployed image configurations match the
approved and tested builds by testing them against known
internal and external standards.

• Detect all changes made to the test environments.

• Reconcile changes to an authorized change order either man-
ually or automatically.

STEP 7: ENSURE THAT ALL PRODUCTION ACTIVITIES GO
THROUGH CHANGE MANAGEMENT

Production actions such as activating or deactivating an IT sys-
tem that supports the production environment must be defined
as a change. Not defining such actions as a change could result
in an unauthorized deactivation of a critical application, which
in turn could jeopardize power delivery and affect other critical
organization objectives. To do this, we will need to work with
change management and production service delivery managers
to ensure all production actions are authorized, scheduled and
audited by change management.

Information security, change management, and relevant man-
agers will need to answer the following questions and generally
agree on the answers:

• Under what conditions are activations, deactivations and
restarts changes that require approval? Consider, for example,
whether changes require approval if the change delivers a
new IT service, enables a service that has security or regula-
tory requirements, or introduces outage risk to a mission-
critical service.

• Who must approve standard and emergency changes?
Once we’ve created policies based on the answers to these ques-
tions, we must verify that these policies are followed. We can
do this by monitoring all activations and deactivations and
reconciling them with an authorized and scheduled change.
Such monitoring lets information security ensure that activity
that could introduce information security risks is adequately
reviewed and mitigated.

Steps for Secure, Compliant Federal Information Systems

Maintaining strong cyber security of federal information systems
is more than a checklist and paperwork exercise; it requires gen-
erating value for the relevant parties in the organization. Many of
the steps described in this paper require us to demonstrate that
the security measures we promote align with, advance and protect
the organization’s goals. In addition, to further gain support for
integrating security into everyday organization processes, we must
ensure we integrate with the right groups—even when we don’t
have direct operational responsibility for the work they do.

Configuration control solutions like Tripwire Enterprise offer us
the ability to demonstrate the value of critical security measures
with compliance policy management that ensures the correct-
ness of configurations, file integrity monitoring that detects all
change, and ChangeIQ™ capabilities that assess changes in real-
time to determine if they introduce risk or non-compliance, so
we can take immediate action to remediate any issues and main-
tain configurations in that “correct” state.

Tripwire Enterprise
also provides proof that these security measures are working—
even supporting INFOCON requirements. Such proof is invaluable
for both audit purposes and for further achieving buy-in from
other IT process owners.

Tripwire Log Center, a complete log and event management
solution further helps us in this endeavor, providing forensic
evidence through activity logs and, when combined with Tripwire
Enterprise, letting us correlate event data with change and com-
pliance data to identify and address the highest risk changes.
By taking these seven practical steps to build relationships,
institute preventive controls into IT production operations,
and verify the effectiveness of those preventive controls, we
can simultaneously meet IT operational and security goals and
achieve compliance with relevant regulations like FISMA.

1 Number of reported cyber incidents jumps. A February 17, 2009 article by Ben Bain in FederalComputer Week. http://fcw.com/articles/2009/02/17/cert-cyber-
incidents.aspx
2 Former State Department worker sentenced for passport snooping. A March 23, 2009 article in Computeworld by Grant Gross. http://www.computerworld.com/
action/article.do?command=viewArticleBasic&articleId=9130218&intsrc=hm_list
3 Romanian DoD hacker nabbed. A March 20, 2009 article by Greg Masters in SC Magazine. http://www.scmagazineus.com/Romanian-DoD-hacker-nabbed/
article/129193/
4 FAA Computers Hacked, Employee Data at Risk. February 11, 2009 article by Thomas Claburn in InformationWeek. http://www.informationweek.com/news/
security/attacks/showArticle.jhtml?articleID=213900025
5 Hackers break into government travel site, feed users attack code. February 18, 2009 article by Gregg Keizer in Computerworld. http://www.computerworld.
com/action/article.do?command=viewArticleBasic&articleId=9128173
6 The National Institute of Science and Technology (NIST), the organization charged with ensuring compliance with FISMA, developed a set of comprehensive
guidelines, the 800 series of special publications, entities subject to FISMA must follow to secure federal
7 Fiscal Year 2008 Report to Congress on Implementation of The Federal Information Security Management Act of 2002. A report from the U.S. Office of
Management and Budget
8 Ibid.
9 Federal News Radio, December 12, 2008, Interview with John Gilligan. http://www.federalnewsradio.com/?nid=56&sid=1571643