Unformatted Attachment Preview
Post Event Evaluation
Western Governers University
Brian Keegan
Post Event Evaluation
Nature of Incident
There as a disgruntled employee who felt the need for a pay raise without getting
approval. The employee hacked into the Human Resource Records System (HRRS) at
the employee’s place of business and changed the base salary to obtain an illegal pay
raise.
The break-in was accomplished by a method of intrusion called ‘Spoofing’ this is
done by emulating a known IP address and roaming free throughout the network. Once
the culprit had access to the network it was just a matter of time and know how to find
the secure location and modify the data.
The thief modified the base pay and received two paychecks before a watchful
auditor noticed the mischief. The auditor sent out an email to several people in the need
to know. The villainous hacker intercepted the emails, and again used spoofing but this
time he/she spoofed the emails of the intended recipients.
The thief was able to set up correspondence with the auditor. Eventually the
hacker was able to gain access to more accounts and more private data. Using this new
found information the culprit lowered the president’s and several others paycheck and
placed the difference in his/her paycheck.
Notification
According to the NIST Computer Security Incident Handling Guide (Cichonski,
Millar, Grance, & Scarfone, 2012) in the crisis handling appendix G: Notify the
appropriate people within the organization. This is hack of the highest level hence the
Chief technical Officer, Chief Security officer, and the president as it was his email and
the auditor who was involved from the beginning.
There is also a recommendation dealing with outside agencies such as USCERT (Department of Homeland Security , 2015) but use caution in communicating as
the email system has been compromised. The document does not states who exactly
was contacted, just several others.
Containment
NIST (Cichonski, Millar, Grance, & Scarfone, 2012) recommends having a
predefined containment strategy depending on the attack. Under the containment
section of this document there is a recommendation of a sandbox. Which is a form of
containment.
A sandbox is a secure location where the attacker is redirected to a sandbox to
contain the damage but allow monitoring. In this case there was no containment except
for the auditor emailing individuals within the organization.
The concept of “sandboxing “is to isolate an application, user, or process in a
restricted area and monitor the behavior in a safe environment.
Factor Removal
Section 3.3.4 Eradication and Recovery of the incident handling guide
(Cichonski, Millar, Grance, & Scarfone, 2012) mention “eradication may be necessary to
eliminate components of the incident “and “During eradication, it is important to identify
all affected hosts within the organization so that they can be remediated” .
The IP addresses was spoofed as well as the email addresses of the concerned
parties in the auditor’s incident response. During this venture the auditor issued access
permissions to other sensitive data.
File permissions need to be reset on the file server the email server needs to be
restored to a pre-incident state. The switch and router all need configuration overhauls
ad have their passwords and/or ID’s reset.
The root cause of the issue was lack of encryption and authentication. Installing
Public Key Infrastructure (PKI) will encrypt network traffic to and from the HSS and
prevent eavesdropping. It will also authenticate the host and prevent spoofing.
Restoration
Section 3.3.4 Eradication and Recovery of the incident handling guide
(Cichonski, Millar, Grance, & Scarfone, 2012) mention “In recovery, administrators
restore systems to normal operation, confirm that the systems are functioning normally,
and (if applicable) remediate vulnerabilities to prevent similar incidents” Further specific
recommendations for this incident include installing patches, changing passwords,
tighten network security .
The email and file server both need to be restored from a pre incident backup
file. The passwords on both servers need to be changed as well as the switch and outer
in question. Also the auditor’s PC needs to be scrubbed as the hacker gained much of
his post incident information from the auditor and the email account and PC could be
compromised.
I would also advise using NIST’s recommendation from the same subheading of
a phased approach. Do the passwords changes first. Restoring the file server is
somewhat easy but the email server can take some time as much of the evidence will
be lost of a restore is done without taking precautions. Scrubbing the PC and Email of
the auditor can take time as there is legal ramifications to consider.
Verification
The auditors and human resources will need to verify employee data to make
sure no other documents and Personal Identifiable Information (PII) weren’t altered.
Also the IT department needs to do an audit to make sure no ‘”backdoor” accounts and
Trojans were not left behind this should be done the week for month and once a week
for the rest of the year.
Lessons Learned
NIST recommends a follow up report, and a lessons learned meeting under
section 3.4.1 (Cichonski, Millar, Grance, & Scarfone, 2012). The idea behind it is to
learn from the mistakes, and catch anything that could have been missed. This is done
to improve the system and prevent further incidents of the same nature from happening
again.
To summarize the checklist in this section as it applies to this specific incident
what happened? How was it handled? Could it have been done better? Did the
company or people within I make the problem worse?
Unaddressed Areas
o IKE policy was set for any traffic to human resources what about the rest
of the company
o The system was hacked yet the Auditor still used email?
o Why would the auditor be able to grant permissions on a file server?
o Why there was no notification after two paychecks and still the hacker was
able to take pay from the president?
o There can be some legal actions was any cyber lay authority involved?
o The hacker used hacking tool from a company machine or his/her own
machine on the network
o Retention of data? Forensics?
Other Attacks
o The hacker was able to send emails as other people
o Modified permission on a fileserver containing PII and sensitive data
o Social Engineering attacks on the auditor to convince the auditor to
divulge information
Nature of Other Attacks
The nature of the “other attacks “was mostly social engineering on the auditor
and others to gain privileged information. The hacker could have spoofed other IP
packets to gain the login credentials of other users hence the ability to send emails as
other people or hacked the email server and sent emails from there as an administrator.
Prevention
NIST has a Security and Policy Control Publication (Task Force Transformation
Initiative, 2013). Appendix F SECURITY CONTROL CATALOG, lists many
recommendations I will also use their recommendation and a multi-tiered approach.
Policy
If the “Place of Business” had proper policy the hacker would have been stopped
much earlier and the authorities would have been alerted. An access control policy and
procedure recommends under the subheading
AC-1 Access Control:
“This control addresses the establishment of policy and procedures for the effective
implementation of selected security controls and control enhancements in the AC
family.” (Task Force Transformation Initiative, 2013).
The policy would have specifically separated the auditor from granted access to
PII and Sensitive date because it is not an auditor’s job and separation of duties based
on roles and need to know would have been key in stopping this issues after the second
paycheck. AC-3 and AC-3 further enforce this.
AC-4 Information Flow Enforcement:
“The information system enforces approved authorizations for controlling the flow
of information within the system and between interconnected systems” (Task Force
Transformation Initiative, 2013)
There should be a policy in place controlling the flow of information. In this case
the spoofing would only be allowed on the end users own local area network. The
spoofing would never have reached the human resources domain.
Critical Controls under flow control state:
“The information system prevents encrypted information from bypassing contentchecking mechanisms decrypting the information; blocking the flow of the encrypted
information; terminating communications sessions attempting to pass encrypted
information.” (Task Force Transformation Initiative, 2013)
CM-3 CONFIGURATION CHANGE CONTROL:
“Configuration change controls for organizational information systems involve the
systematic proposal, justification, implementation, testing, review, and disposition of
changes to the systems, including system upgrades and modifications”
With configuration change control the file permission would not have been modified
without security professionals notified. The file permission would not have been made
hence the hacker would not have been able to make the changes to the system in the
first place.
CM-11 USER-INSTALLED SOFTWARE:
“If provided the necessary privileges, users have the ability to install software in
organizational information systems. To maintain control over the types of software
installed, organizations identify permitted and prohibited actions regarding software
installation.”
The end user used pack sniffing software to spoof the IP address of user
accounts, account information and such this is obviously not normal software installed
on anyone’s company machine.
Training:
Training would assist with the social engineering aspect of the intrusion.
Inoculation training as well as instruction end user on the policies of the company. If the
auditor would have had these policies in place and been trained in them this would have
been stopped much sooner.
Recovery Recommendations:
NIST has three subheading under Recover From and Incident:
1. Return affected systems to an operationally ready state
2. Confirm that the affected systems are functioning normally
3. If necessary, implement additional monitoring to look for future related
activity (Cichonski, Millar, Grance, & Scarfone, 2012)
Using backups to restore Human Resources Records System, File and Mail
servers to a date prior to the attack. This should done after all relevant data has
been collected Double check file permissions, accounts with administrator
privileges, and pertinent human resources data.
After the system has been restored make sure everything is function properly
by using the network and polling the end users about functionally and speed of
the system.
Monitor the network for bandwidth spikes, accessing secure data, or from
user accounts that should not be in privileged areas.
References
Cichonski, P., Millar, T., Grance, T., & Scarfone, K. (2012). NIST Special Publication
800-61 Revision 2. Gaithersburg: National Institute of Standards and
Technology.
Department of Homeland Security . (2015, May 15). US-CERT. Retrieved from United
States Computer Emergency Readiness Team: http://www.uscert.gov/cas/signup.html
Task Force Transformation Initiative. (2013). NIST Special Publication 800-53 Security
and Privacy Controls for Federal Information Systems. Gaithersburg: National
Institute of Standards and Technology.
Evaluation Results
Author: Brian Keegan
Date Evaluated: 05/29/2015 03:26:54 PM (MDT)
DRF template: FXT2 Enterprise Continuity Planning (V2 GRADUATE0510)
Program: FXT2 Enterprise Continuity Plan (V2 GRADUATE0510)PA
Evaluation Method: Using Rubric
Evaluation Summary for Enterprise Continuity Planning: FXT Task 2
Final Score: Does not Meet
Overall comments: 05/29/2015: The work provides a solid foundation for the completion of this
assessment including discussion of the events leading to the spoofing of IP
addresses, interception of emails and the impersonation of an employee along with
the detailed steps to take for the prevention of similar breaches including access
controls, change management, separation of duties and more. The containment,
factor removal and other attacks requires additional detail, support and discussion
to meet the requirement and the verification and recommendation require a detailed
set of steps to verify the system and to restore the system to its prior state.
Detailed Results (Rubric used: FXT Task 2)
Articulation of Response (clarity, organization, mechanics)
(0) Unsatisfactory
(1) Needs Revision
(2) Satisfactory
The candidate provides unsatisfactory
articulation of response.
The candidate provides weak articulation
of response.
The candidate provides adequate
articulation of response.
(0) Unsatisfactory
(1) Needs Revision
(2) Satisfactory
The candidate does not provide an
appropriate description of the nature of
the incident.
The candidate provides an appropriate
description, with insufficient detail, of the
nature of the incident.
The candidate provides an appropriate
description, with sufficient detail, of the
nature of the incident.
Criterion Score: 2.00
A1. Nature of the Incident
Criterion Score: 2.00
Comments on this criterion: 05/29/2015: The work provides a discussion of the event including the spoofing of IP
addresses, interception of emails, impersonation of employee and more.
A2. Notification
(0) Unsatisfactory
(1) Needs Revision
(2) Satisfactory
The candidate does not identify who
needs to be notified based on the type
and severity of the incident.
Not applicable.
The candidate identifies who needs to be
notified based on the type and severity of
the incident.
Criterion Score: 2.00
A3. Containment
Printed on: 05/29/2015 11:32:26 PM (EST)
(0) Unsatisfactory
(1) Needs Revision
(2) Satisfactory
The candidate does not outline how the
incident could be contained.
The candidate outlines, with insufficient
detail, how the incident could be
contained.
The candidate outlines, with sufficient
detail, how the incident could be
contained.
Criterion Score: 1.00
Comments on this criterion: 05/29/2015: The work cites the NIST guidelines of using a sandbox containment
methodology. The level of detail describing the how the sandbox method could be used to contain the incident was not
sufficient for this aspect.
A4. Factor Removal
(0) Unsatisfactory
(1) Needs Revision
(2) Satisfactory
The candidate does not provide a logical
discussion of how the factor that caused
the incident could be removed.
The candidate provides a logical
discussion, with insufficient detail, of how
the factor that caused the incident could
be removed.
The candidate provides a logical
discussion, with sufficient detail, of how
the factor that caused the incident could
be removed.
Criterion Score: 1.00
Comments on this criterion: 05/29/2015: The work mentions the implementation of PKI as a means to remove the
factors that caused the incident. The response is not fully clear in how PKI should be implemented to address the issues.
Additional detail is needed to more clearly describe how PKI would be implemented in the overall system to address the
factors that allowed the breach to occur.
A5. System Restoration
(0) Unsatisfactory
(1) Needs Revision
(2) Satisfactory
The candidate does not provide an
appropriate description of how the system
could be restored to normal business
practice.
The candidate provides an appropriate
description, with insufficient detail, of how
the system could be restored to normal
business practice.
The candidate provides an appropriate
description, with sufficient detail, of how
the system could be restored to normal
business practice.
(0) Unsatisfactory
(1) Needs Revision
(2) Satisfactory
The candidate does not provide a logical
explanation of how the system could be
verified as operational.
The candidate provides a logical
explanation, with insufficient detail, of how
the system could be verified as
operational.
The candidate provides a logical
explanation, with sufficient detail, of how
the system could be verified as
operational.
Criterion Score: 2.00
A5a. System Verification
Criterion Score: 0.00
Comments on this criterion: 05/29/2015: The discussion mentions verification of the HR data and an IT check for trojans
and back doors. There are additional steps needed to provide a full explanation of how the system could be verified as
operational.
B1. Unaddressed Areas
(0) Unsatisfactory
(1) Needs Revision
(2) Satisfactory
The candidate does not identify areas that
were not addressed by the IT staff’s
response to the incident.
Not applicable.
The candidate identifies areas that were
not addressed by the IT staff’s response
to the incident.
(1) Needs Revision
(2) Satisfactory
Criterion Score: 2.00
B2. Other Attacks
(0) Unsatisfactory
Printed on: 05/29/2015 11:32:26 PM (EST)
The candidate does not outline the other
attacks mentioned in the scenario that
were not noticed by the organization.
The candidate outlines, with insufficient
detail, the other attacks mentioned in the
scenario that were not noticed by the
organization.
The candidate outlines, with sufficient
detail, the other attacks mentioned in the
scenario that were not noticed by the
organization.
Criterion Score: 1.00
Comments on this criterion: 05/29/2015: The work identifies several other attacks including breached email,
compromised permissions and social engineering. The outline includes an insufficient level of detail and support to explain
each attack as required for this prompt.
B2a. Nature of Other Attacks
(0) Unsatisfactory
(1) Needs Revision
(2) Satisfactory
The candidate does not provide an
appropriate description of the nature of
the attacks not noticed by the
organization.
The candidate provides an appropriate
description, with insufficient detail, of the
nature of the attacks not noticed by the
organization.
The candidate provides an appropriate
description, with sufficient detail, of the
nature of the attacks not noticed by the
organization.
Criterion Score: 1.00
Comments on this criterion: 05/29/2015: There is a limited discussion of the nature of the attacks of breached email,
compromised permissions and social engineering. The discussion provided lacks sufficient description and detail to fully
explain the nature of the attacks.
B2b. Prevention
(0) Unsatisfactory
(1) Needs Revision
(2) Satisfactory
The candidate does not provide an
appropriate description of how the
additional attacks can be prevented in the
future.
The candidate provides an appropriate
description, with insufficient detail, of how
the additional attacks can be prevented in
the future.
The candidate provides an appropriate
description, with sufficient detail, of how
the additional attacks can be prevented in
the future.
Criterion Score: 2.00
Comments on this criterion: 05/29/2015: There are detailed steps to take for the prevention of similar breaches
including access controls, change management, separation of duties and more.
B3. Recommendation
(0) Unsatisfactory
(1) Needs Revision
(2) Satisfactory
The candidate does not provide an
appropriate recommendation of a recovery
procedure to restore the computer
systems back to their original state prior
to the attacks.
The candidate provides an appropriate
recommendation, with insufficient support,
of a recovery procedure to restore the
computer systems back to their original
state prior to the attacks.
The candidate provides an appropriate
recommendation, with sufficient support,
of a recovery procedure to restore the
computer systems back to their original
state prior to the attacks.
Criterion Score: 0.00
Comments on this criterion: 05/29/2015: The work provides a limited recommendation including recovering, confirming
and implementing monitoring. This aspect requires the detailed set of steps required to restore the system to its prior
state with the controls in place to address the vulnerabilities that led to the incident, and this level of detail and
completeness of the recommendation was not present in the work.
C. Sources
(0) Unsatisfactory
(1) Needs Revision
(2) Satisfactory
When the candidate uses sources, the
candidate does not provide intext
citations and references for each source
used.
When the candidate uses sources, the
candidate provides appropriate intext
citations and references with major
deviations from APA style.
When the candidate uses sources, the
candidate provides appropriate intext
citations and references accurately or with
only minor deviations from APA style, OR
the candidate does not use sources.
Criterion Score: 2.00
Printed on: 05/29/2015 11:32:26 PM (EST)
Printed on: 05/29/2015 11:32:26 PM (EST)
Healthy Wellness Body Center
Information Security Management System (ISMS)
VLT2 Western Governors University
Brian Keegan
5-24-2015
Information Security Management System (ISMS)
ISMS Plan for Healthy Wellness Body Center
Outline the scope for the ISMS plan being developed in the case study
Business Objective of the HBWS
The business objective of Healthy Body Wellness Center (HBWS) Office of
Grants Giveaway (OGG) is improve the quality and usefulness of federally supported
medical grants through sharing of information, and federal supported research and
evaluating available data.
The majority of the grants of the medical grants are to small hospitals hence We
Automatic Anything (WAA) was contracted to implement the small hospital grant
tracking system (SHGS). The SHGS tracks the initial grant and redistributes the unused
finds to another of the five monitored hospitals though out the life cycle of the grants.
Scope
The OGG used the SHGS to track loans through the lifecycle of the initial loan
through five hospitals. The scope of the Information Security Management System
(ISMS) will predominantly deal with his aspect. As the governing boards Technical
Review Board (TRB) and Configuration Control Review Board (CCRB), did not exist
during the inception of the SHGTS.
A description of the guiding security principles of the organization
The guiding security principles we will use is what is called the confidentially,
integrity, and availability (CIA triad). Data has to be classified so only those who need to
know will be able to view the data this is confidentially. Integrity refers to the data
remaining in the state it was intended and not being altered. Availability refers to the
data being available to the people who need it when they need it.
A justification of the processes that should be included in the scope
The SHGS process information on a MS 97 Access database. The information is
processed on a grant basis. This is each grant is awarded to a hospital it is then tracked
over the course of the life of the grant.
Confidentially
The data must be on a need to know as it could affect the ability to grant money
to other hospitals if anyone could see the data.
Integrity
Obviously if the data is incorrect It will affect the flow of money from one hospital
to another. This will then make it difficult on the financial staff to keep accurate records
and the HBWC will soon be out of business.
Available
Data is directly related to the cash flow of the grant. The ability for the HBWCOGG will diminish to the point of nonexistence of the data is not available.
A justification of the information systems that should be included in the scope
The SHGTS is a Microsoft Access 97 database that resides on the Windows NT
application server JINX EOC3EOC3EOC3FPR02. The SHGTS application and its data
are protected by the following built-in security mechanisms supported by the hardened
Windows NT platform:
A RAS (Windows NT) is in place for users that requires remote access to the
SHGTS. Knowledge of the RAS phone number is limited to those users with a missionessential need. Users access the RAS via dial-up networking or using a VPN solution.
A description of the IT infrastructure that includes a description of information flow
The SHGTS resides in the JINX2 server but does not pass data or interface with
other systems. The access is through the local OGG workstation and the database can
be accessed through remotely connecting to the analog dial up. Data in SHGTS is
made up of specific attributes about grants which is used to control the flow of funds to
other grants.
Infrastructure
This risk assessment is limited to the SHGTS (a Microsoft Access 97 database),
its host general support system (GSS) (JINX server EOC3FPR02\Groups\SSR), and the
remote access server (RAS). The servers are housed in room 1234 at the HBWC’s
executive office facility
SHGTS
SHGTS
SHGTS
Windows NT
JINX
SHGTS
MS-Access
RAAS
SHGTS
GSS
The servers are housed in room 1234 at the HBWC’s executive office facility
Recommend additional steps that the organization would need to take to
implement the ISMS plan.
Compliance which is section 18 of ISO 27002 are not addressed. Under CIA the
confidentiality of data is directly affected by the compliance section. The availability part
is directly affected by information security reviews.
Compliance with legal and contractual requirements
Information Security reviews
Discuss what each recommended step entails
ISO 27002 18.1
Compliance with legal and contractual requirements this deals directly with the
CIA security principles. Confidentially or records and privacy statements and especially
cryptographic policy has never been discussed in the security assessment.
Protection of records Stored on a separate secure server with its own domain on a
separate network.
Privacy and protection of Personally Identifiable Information (PII): Is becoming
more important after recent breaking into company websites and leaked over the
internet.
The first part is actually identify what PII is and storing it on a secure server with a need
to know policy in place and non-disclosure document that must be signed and
maintained.
Technical Compliance Review Establish policy to review of the ISMS plan and ensure
it is compliant with current company and statutory policy.
.
Justify each recommended step
Under the compliance sections in ISO 27002 two sections are titled 18.1.2
Intellectual property rights18.1.3 Protection of records and under 18.2.3 there is a
section for a Technical compliance review.
Besides ISO standard controls we also have CIA. The confidentially of
information is directly effected by 18.1.2 and 18.1.3. The availability of information is
directly effected by 18.2.3 without a review the ISMS will soon be obsolete.
HEALTHY BODY WELLNESS CENTER, OFFICE OF GRANTS GIVEAWAY
HEALTHY BODY WELLNESS CENTER
OFFICE OF GRANTS GIVEAWAY
SMALL HOSPITAL GRANTS TRACKING SYSTEM
INITIAL RISK ASSESSMENT
PREPARED BY:
WE TEST EVERYTHING LLC
Jerry L. Davis, CISSP, Sr. Analyst
EXECUTIVE SUMMARY .......................................................................................................... 4
1. INTRODUCTION..................................................................................................................... 7
Background ............................................................................................................................................................... 7
Purpose .....................................................................................................................................................................7
Scope ........................................................................................................................................................................7
Report Organization..................................................................................................................................................8
2. RISK ASSESSMENT APPROACH ........................................................................................ 9
2.1
Step 1: Define System Boundary ....................................................................................................................9
2.2
Step 2: Gather Information .............................................................................................................................. 9
2.2.1
Interviews ............................................................................................................................................. 10
2.2.2
Site Visit ............................................................................................................................................... 10
2.2.3
Documentation ..................................................................................................................................... 10
2.2.4
Network Scanning ................................................................................................................................ 10
2.3
Step 3: Conduct Risk Assessment ................................................................................................................. 11
2.3.1
Impact .................................................................................................................................................. 11
2.3.2
Likelihood ............................................................................................................................................ 12
2.3.3
Risk ...................................................................................................................................................... 12
3. SYSTEM CHARACTERIZATION ...................................................................................... 14
System Overview .................................................................................................................................................... 14
System Interfaces .................................................................................................................................................... 14
Data ....................................................................................................................................................................... 14
System and Data Criticality and Sensitivity ........................................................................................................... 15
3.4.1
Criticality ............................................................................................................................................. 15
3.4.2
Sensitivity ............................................................................................................................................. 15
3.4.2.1 Confidentiality ..................................................................................................................................... 15
3.4.2.2 Integrity ............................................................................................................................................... 15
3.4.2.3 Availability ........................................................................................................................................... 15
Users ....................................................................................................................................................................... 16
4. THREAT STATEMENT ....................................................................................................... 17
Threat Sources ........................................................................................................................................................ 17
Threat Actions ........................................................................................................................................................ 17
5. FINDINGS ............................................................................................................................... 19
Management Security ............................................................................................................................................. 19
Operational Security ............................................................................................................................................... 20
2
Technical Security .................................................................................................................................................. 22
APPENDIX A.
RISK ASSESSMENT MATRIX................................................................ 25
APPENDIX B.
ACRONYMS ............................................................................................... 28
APPENDIX C.
SAMPLE BASELINE SECURITY REQUIREMENTS ......................... 29
3
Executive Summary
The mission of the Healthy Body Wellness Center’s (HBWC) Office of Grants Giveaway (OGG)
is to promote improvements in the quality and usefulness of medical grants through federally
supported research, evaluation, and sharing of information. The OGG distributes a variety of
medical grants, but the majority of grants are disbursed to small hospitals. As a result, the OGG
contracted We Automate Anything (WAA) to design and implement the Small Hospital Grant
Tracking System (SHGTS).
The SHGTS is used to assist in the assignment and tracking of small hospital grants. The OGG
assigns a particular grant to one hospital for one month and then the unused grant funds are
rotated to another hospital for another month. The database tracks the initial delivery of the grant
funds and its pertinent information, and then follows the grant through five hospital facilities.
Only executive office staff can assign grant funds, but all grant users must complete their grant
evaluations in the database. A weekly grant status report is prepared for the executive officer.
Each month, the grant assignor is briefed on the grant status with reports generated from the
database.
During the inception of the SHGTS, the Technical Review Board (TRB) and Configuration
Control Review Board (CCRB) did not review the SHGTS because these boards did not yet
exist. The SHGTS has never had a risk assessment or an OMB Circular No. A-130 review. As a
result, the OGG contracted We Test Everything (WTE) to perform a risk assessment of the
SHGTS.
To identify the potential threats and vulnerabilities associated with the SHGTS, WTE gathered
information through the following techniques:
Document review
Onsite visits to the SHGTS computer room
Interviews with designated OGG management and technical personnel
Network scanning using an automated tool
This report documents risk assessment activities in the following security domain areas:
Management Security
Operational Security
Technical Security
A total of eight observations were made in the areas of management, operational, and technical
security. Table ES-1 presents these observations, providing observation numbers and
descriptions, as well as associated risk levels. The risk associated with each observation is
described as high, medium, or low, as defined below. The risk level represents the degree or
level of risk to which the OGG assets and resources may be exposed.
High Risk: A threat is at least moderately likely to exploit the identified vulnerability,
and such exploitation is likely to severely and adversely affect SHGTS tangible and
4
intangible resources. This level of risk indicates a strong need for corrective measures
and actions, and a plan must be developed to incorporate these actions within a
reasonable period of time.
Medium Risk: The exploitation of the identified vulnerability by a threat is possible, and
such exploitation is likely to affect the OGG significantly. This exploitation would
include the loss of some tangible assets or resources, which could impede the SHGTS
mission, reputation, or interest. This level of risk indicates corrective actions are needed
and a plan must be developed to incorporate these actions within a reasonable period of
time.
Low Risk: The identified weaknesses may be subject to exploitation by a threat, but the
probability of exploitation is low, and the impact on the OGG would be minor. This level
of risk indicates that OGG management should be cautioned and corrective measures
applied where required.
The findings section of this report analyzes each observation in detail. Appendix A summarizes
the observations and presents the observation number and description as well as the potential
threats, potential impacts, associated level, and countermeasures for each observation.
Table ES-1
OBSERVATION
NUMBER
OBSERVATION DESCRIPTION
RISK
LEVEL
Management Security
M1
The accounts of SHGTS users who no longer require access
may not be deleted immediately from the system.
Operational Security
Medium
O1
A system security plan (SSP) has not been developed for the
SHGTS.
A disaster recovery plan (DRP) has not been developed for
the SHGTS.
There are no sign-in logs for visitors accessing the computer
room.
Technical Security
Medium
Passwords on the grants server are not required to be
changed at least every ninety days.
There is no limit to the number of invalid access attempts
that may occur for a given user.
Null session login may be possible.
Medium
O2
O3
T1
T2
T3
5
Medium
Low
Medium
Low
OBSERVATION
NUMBER
T4
OBSERVATION DESCRIPTION
Remote registry access is not restricted to administrators.
6
RISK
LEVEL
High
1. INTRODUCTION
Background
The mission of the Healthy Body Wellness Center’s (HBWC) Office of Grants Giveaway (OGG)
is to promote improvements in the quality and usefulness of hospital grants through federally
supported research, evaluation, and sharing of information. The OGG distributes a variety of
medical grants, but the majority of grants are disbursed to small hospitals. As a result, the OGG
contracted We Automate Anything (WAA) to design and implement the Small Hospital Grant
Tracking System (SHGTS).
The SHGTS is used to assist in the assignment and tracking of small hospital grants. The OGG
assigns a particular grant to one hospital for one month and then the unused grant funds are
rotated to another hospital for another month. The database tracks the initial delivery of the grant
funds and its pertinent information, and then follows the grant through five hospital facilities.
Only executive office staff can assign grant funds, but all grant users must complete their grant
evaluations in the database. A weekly grant status report is prepared for the executive officer.
Each month, the grant assignor is briefed on the grant status with reports generated from the
database.
During the inception of the SHGTS, the Technical Review Board (TRB) and Configuration
Control Review Board (CCRB) did not review the SHGTS because the boards did not exist. The
SHGTS has never had a risk assessment or an OMB Circular No. A-130 review. As a result, the
OGG contracted We Test Everything (WTE), under Contract No. ABCD12-34-E00567, Task
Order # TO111111, to perform a risk assessment of the SHGTS.
Purpose
The purpose of this report is to provide the HBWC and OGG management with an assessment of
the adequacy of the management, technical, and operational security controls used to protect the
confidentiality, integrity, availability, and accountability of the SHGTS. This risk assessment
report identifies threats and vulnerabilities applicable to the SHGTS; the impact associated with
these threats and vulnerabilities; the likelihood that a vulnerability will be exploited;
countermeasures in place to mitigate the risk; and the existence of any residual risk.
This report documents the risk assessment activities that WTE performed during a two-and-ahalf week period that will help OGG management understand the security posture of the SHGTS
and its risk exposure. The risk assessment is part of the OGG’s continuing effort to ensure
compliance with federal policies and guidance as well as the HBWC’s IT security policy.
Scope
This risk assessment is limited to the SHGTS (a Microsoft Access 97 database), its host general
support system (GSS) (JINX server EOC3FPR02\Groups\SSR), and the remote access server
(RAS). The servers are housed in room 1234 at the HBWC’s executive office facility. OGG staff
7
access the SHGTS from their workstations in room 5678. The risks were evaluated in the
following security domains:
Managerial
Technical
Operational
Site visits at HBWC headquarters were restricted to room 1234, where the JINX server and the
RAS are located, and OGG offices in 5678. To observe remote access capability, the homes of
two users were visited to review the dial-up networking and virtual private networking (VPN)
process.
Report Organization
This document is divided into five sections. Section 1 is the introduction. The remainder of the
document consists of the following sections:
Section 2 provides a description of the risk assessment methodology used by WTE.
Section 3 describes the characteristics of the SHGTS including the hardware, software,
connectivity, data, and system users.
Section 4 contains the threat statement including threat categories, threat agents, and actions.
Section 5 provides an analysis of the findings in the management, technical, and operation
security domains.
Additionally, the document contains three appendixes: Appendix A contains the Risk
Assessment Matrix BLSR checklist, Appendix B lists acronyms and abbreviations listed
throughout the report, and Appendix C provides the sample baseline security requirements
(BLSR).
8
2. RISK ASSESSMENT APPROACH
Risk was evaluated qualitatively, meaning that numerical values were not assigned. Instead a
rating of high, medium, or low was provided. The WTE risk assessment methodology involved
three major steps that are described below.
Step 1 – Determine System Boundary
Step 2 – Gather Information
Step 3 – Conduct Risk Assessment.
The methodology used to perform the risk assessment for the SHGTS was developed by WTE
with reference to the guidelines found in the following publications:
Federal Information Processing Standards (FIPS) Publication (PUB) 65: Guidelines for
Automated Data Processing Risk Analysis
National Institute of Standards and Technology (NIST) Special Publication 800-30: Risk
Management Guide for Information Technology Systems
The level of risk was assessed by evaluating all collected risk-related attributes regarding threats,
vulnerabilities, assets and resources, current controls, and the associated likelihood that a
vulnerability could be exploited by a potential threat as well as the impact (i.e., magnitude of
loss) resulting from such exploitation.
Figure 2-1: Risk Assessment Approach
Determine
System
Boundaries
Gather
Information
Conduct
Risk
Assessment
1.
2.
3.
4.
5.
6.
2.1
Identify Requirements
Identify Threats
Identify Vulnerabilities
Analyze Risk
Recommend
Countermeasures
Document Results
Step 1: Define System Boundary
The system boundaries, which determine the risk assessment scope, were restricted to the
SHGTS and its Windows NT host JINX server EOC3FPR02\Groups\SSR. Meetings with the
OGG system owner and the HBWC's information system security officer (ISSO) and chief
information officer (CIO) along with reviewing the current system diagrams led to a
determination of the boundaries.
2.2
Step 2: Gather Information
WTE assessed the SHGTS based on the risk assessment team’s understanding of the operational
environment and OGG and HBWC information technology (IT) policies and guidelines.
Information about the SHGTS was gathered through interviews, site visits, documentation
review, and the use of a network-scanning tool.
9
2.2.1 Interviews
To collect relevant information, WTE developed a questionnaire on IT system management and
operations of the SHGTS and support platform. The interviews were conducted on-site, via
telephone, and through e-mail with the following OGG management and technical personnel:
JINX server administrator
OGG ISSO
OGG CIO
SHGTS Users
2.2.2 Site Visit
The WTE team toured the computer room which houses the SHGTS hardware, software, and
data at rooms 1234 and 5678 at executive office complex in the course of a day to observe the
physical and environmental measures provided for the SHGTS. The visit also included a
demonstration of how the system is accessed and administered, including adding and removing
data. WTE also visited the homes of two OGG staff members to observe remote connections via
virtual private network and dial-up networking.
2.2.3 Documentation
The team reviewed all relevant information security (INFOSEC) documents in order to develop a
better understanding of the SHGTS. Listed below are all system and organizational documents
reviewed in support of the assessment:
OGG mission statement
OGG organization chart
SHGTS administrator’s guide
SHGTS user’s guide
SHGTS configuration management plan (CMP)
OGG request for proposal (RFP) for development of tracking database
WAA SHGTS documentation
Standard operating procedures (SOPs).
2.2.4 Network Scanning
The team used a scanning tool to discover additional vulnerabilities, or vulnerabilities missed by
another scanner, and to minimize the impact of false positives. The JINX host was scanned once
on two different days for a total of two scans.
10
2.3
Step 3: Conduct Risk Assessment
The risk assessment encompassed the following subtasks:
Determining the relative value of the SHGTS based on the criticality and sensitivity of the
data the SHGTS processes, stores, and transmits
Compiling the BLSR checklist
Identifying and assessing potential threats
Identifying and assessing potential vulnerabilities
Determining risks
Developing countermeasure recommendations.
The value of the SHGTS is measured in terms of system and data criticality and sensitivity,
which are described in Section 3. The BLSR checklist encompasses the security requirements,
policies, and guidelines applicable to the SHGTS. Appendix C provides a sample BLSR
checklist.
To assess risks to the SHGTS, the WTE risk assessment team identified a list of potential threats
that could exploit identified vulnerabilities of the SHGTS operational environment. Section 4
provides an analysis of the SHGTS threat environment.
Section 5 presents the findings and includes a discussion of the threat and vulnerability pair,
identification of existing mitigating security controls, impact analysis discussion, risk rating, and
recommended countermeasures. A summary of the findings is listed in Appendix B.
In order to determine risk, the team identified the impact an exploited vulnerability would have
on the system and the likelihood of the vulnerability being exploited. The following sections
provide descriptions of impact, likelihood, and an overall risk matrix.
2.3.1 Impact
Impact refers to the magnitude of potential harm that may be caused by threat exploitation. It is
determined by the value of the resource at risk, both in terms of the information’s sensitivity and
its importance to the HBWC’s mission (i.e., criticality). The criticality and sensitivity of both the
system and data are useful guides for assessing the potential impact of an exploited vulnerability.
11
Table 2.3.1–1: Impact Description
Description
Impact
High
Medium
Low
May result in the loss of significant or major tangible assets, information, or
information resources. May significantly disrupt or impede the SHGTS mission or
seriously harm its reputation or interest.
May result in the loss of some tangible assets, information, or information resources.
May disrupt or harm the SHGTS mission or harm its reputation or interest.
May result in the loss of minimal tangible assets, information, or information
resources. May adversely affect the SHGTS mission, reputation, or interest.
2.3.2 Likelihood
Likelihood is determined by considering threats and vulnerabilities. The likelihood that a
vulnerability will be exploited by a threat can be assessed and described as high, medium, or
low. Factors that govern the likelihood of threat exploitation include threat capability, the
frequency of threat occurrence, and effectiveness of current countermeasures.
Table 2.3.2–1: Likelihood Description
Likelihood
High
Medium
Low
Description
The capability of the threat is significant, and/or countermeasures to reduce the
probability of threat exploitation are insufficient.
The capability of the threat is moderate, and implemented countermeasures lessen
the probability of threat exploitation.
The capability of the threat is limited, and countermeasures are in place that
effectively reduce the probability of threat exploitation.
2.3.3 Risk
After evaluating likelihood and impact, the risk assessment team employed a risk scale matrix
with the ratings of high, medium, and low to determine the degree or level of risk to which a
system, facility, or procedure might be exposed if a vulnerability were exploited. The level of
risk equals the intersection of the likelihood and impact values. For example, suppose the
likelihood level is high and the impact level is low for the threat/vulnerability pair. Based on the
risk matrix found below, there would be a medium risk level.
12
Table 2.3.3-1: Risk Rating
Likelihood
Impact
High
Medium
Low
High
High
High
Medium
Medium
High
Medium
Low
13
Low
Medium
Low
Low
3. SYSTEM CHARACTERIZATION
System Overview
The SHGTS is a Microsoft Access 97 database that resides on the Windows NT application
server JINX EOC3EOC3EOC3FPR02. The SHGTS application and its data are protected by the
following built-in security mechanisms supported by the hardened Windows NT platform:
Identification and authentication (I&A)
Discretionary access control (DAC)
Auditing
To segregate functions in support of SHGTS, three technical support personnel, who are
members of the administrator group, have administrative rights to manage JINX
EOC3EOC3EOC3FPR02. The SHGTS database administrator (DBA) does not have
administrative privileges to the Windows NT operating system (OS).
The SHGTS database has been customized for group security to protect the application from
design changes such as altering the visual basic for applications (VBA) code or modifying
database objects. There are three categories of users for the SHGTS and they are described
below.
Administrative: Full control of the application including the ability to alter code and modify
database objects
Executive: Allows access to all reports and the ability to update key fields dealing with the
assignment of grants
Basic: Allows access to most, but not all forms, and the ability to update key fields relating
to information about already assigned grants
A RAS (Windows NT) is in place for users that requires remote access to the SHGTS.
Knowledge of the RAS phone number is limited to those users with a mission-essential need.
Users access the RAS via dial-up networking or using a VPN solution.
System Interfaces
The SHGTS does not give or receive any data to or from any other major application (MA) or
GSS. The SHGTS resides on JINX2 as its GSS, but otherwise does not interface with any other
system. It is accessed from local OGG workstations. OGG staff may access this database when
they connect remotely either through analog dialup to the RAS server or through the VPN
connection.
Data
The SHGTS does not contain any privacy act information or proprietary data in its tables. Data
stored in the SHGTS includes specific attributes about the grants such as distribution schedule,
amount, control number, grant category, and sunset date. Information detailing grant distribution
particulars including sponsoring staff, directing official, and date assigned, is also stored in the
system.
14
System and Data Criticality and Sensitivity
3.4.1 Criticality
The HBWC’s Information Systems Criticality Definition Process defines automated information
resources whose failure would not preclude the HBWC from accomplishing core business
operations in the short to long term (a few hours to a few weeks) but would have an impact on
the effectiveness or efficiency of day-to-day operations, as being mission supportive. The
SHGTS does not contain any sensitive data and the failure of the SHGTS would not preclude the
OGG from accomplishing core business operations in the short to long term (a few hours to a
few weeks). However, failure of the system would have an impact on the effectiveness or
efficiency of day-to-day operations. Consequently, the SHGTS database is considered mission
supportive.
3.4.2 Sensitivity
The criteria used to measure a system’s sensitivity include confidentiality, integrity, and
availability. The sensitivity areas for the SHGTS are described below.
3.4.2.1 Confidentiality
Low: There is no privacy act or proprietary data to protect. No awardee information is tracked on
the grants; the system only tracks grant specific data. If unauthorized personnel read data that
they are not authorized to see, administrative action (such as grant suspension or a letter of
reprimand) would be the most severe consequence. If competing grant candidates discovered the
grant rating system, the financial impact would be under $100,000.
3.4.2.2 Integrity
Medium: The data maintained on the grant ratings does affect recommendations for particular
grants. Since entire medical research establishments use these recommendations, the financial
impact of manipulated ratings could be between $150,000 and $300,000, but less than a million
dollars. Anyone involved with such data manipulation would possibly be sued but not sent to
jail.
3.4.2.3 Availability
Low: The reports are much easier to prepare with the database and it would be very inconvenient
if the database were unavailable to quickly locate a specific grant. However, manual inspection
of invoices (for receipt information) and office space (to locate grants) could be used. The
consequences of the database being unavailable would probably never be even administrative.
The extra manpower required to manually prepare the reports would be less than $100,000 since
at worst, a contractor could be hired to prepare the most important reports for $75,000.
The following table summarizes the sensitivity levels. The overall system sensitivity level is
determined by the highest value in the SHGTS level column. Therefore, the sensitivity level for
the SHGTS is medium.
15
Table 3.4.2.3-1: Sensitivity Rating
Sensitivity Class
Confidentiality
Integrity
Availability
SHGTS Level
Low
Medium
Low
Users
Only JINX2 users may gain access to the SHGTS since it is located on a JINX server. There is
an additional logon unique to the database. There are three types of access allowed:
Administrative, which provides total control
Executive, which allows access to all reports and the ability to update key fields dealing with
the disbursement of grants
Basic, which allows access to most but not all forms, and the ability to update the fields
relating to information about already disbursed grant funds
16
4. THREAT STATEMENT
Threat Sources
A threat is any instance that could disrupt the ability of the SHGTS to fulfill its purpose. The
three major categories of threats stem from nature, inadequate environmental controls, and acts
by individuals. Examples are categorized and listed in the table below.
Table 4.1-1: Threat Sources
Natural Disaster
Storm damage (e.g., flood, rain, snow,
tornado)
Fire
Lightning strikes
Earthquakes
Environmental Control Failures
Long-term power failure
Chemicals
Pollution
Liquid leakage
Biological/chemical terrorism
Acts by Individuals
Unauthorized network access
Arson
Blackmail
Unauthorized disclosure
Browsing of privacy and
proprietary information
Impersonation
Unauthorized physical access
Distributed denial of service
Economic exploitation
Theft
Fraud
Hacking
Sabotage/vandalism/civil disorder
Interception
Labor dispute/strike
Unauthorized action/alteration and
sensitive information
Negligence/human error
Packet-sniffing
Password-guessing (e.g., dictionary attack,
brute force attack)
Malicious code
Data diddling
Spoofing
System tampering
Falsified data input
Unintentional data destruction
Virus implant
Web deface
Threat Actions
The OGG believes human threat agents or individuals authorized and unauthorized to be the
biggest potential threats to the SHGTS system and its data. Humans could cause intentional or
unintentional damage to the SHGTS that could impair the ability of the SHGTS to operate
effectively. Possible human threat agents include the following:
Insiders, disgruntled employees, dishonest employees, malicious persons
17
Authorized users (e.g., privileged system users such as DBA, system administrator, and
computer operator; and unprivileged system users and application users)
Terminated employees, including retired, resigned, or fired employees
Contractors and subcontractors (e.g., cleaning crew, technical support personnel, developers,
and computer and telephone service repair staff)
Foreign grant disbursing organizations or foreign governments with an interest in the
information held in the SHGTS
Unauthorized users, who may use hacking or penetration techniques against the SHGTS
system or JINX2 with the malicious intent of disrupting normal operations and causing harm
to the SHGTS (e.g., computer criminals, terrorists, hackers, intruders, Internet users,
perpetrators)
18
5. FINDINGS
This section presents the results of the risk assessment performed for the SHGTS application. An
observation resulted when a vulnerability was identified with a threat that could exploit the
vulnerability. BLSRs were developed to test general security requirements and system-unique
security requirements. The BLSRs were derived from federal and HBWC policy, procedures and
guidelines, and industry best practices. BLSRs and existing technical and procedural
countermeasures that might mitigate the risks to the SHGTS environment were considered when
assigning the risk level to each observation. The presentation of each observation consists of the
following:
Statement of the observation
Description of the current environment in relation to the observation
An assessment of the likelihood that a vulnerability will be exploited by a threat and the
impact on the SHGTS of successful exploitation
An assessment of the level of risk to SHGTS based on the threat and vulnerability assessment
and any existing mitigating mechanisms or controls
A recommendation of countermeasures that would reduce or eliminate the risk.
Risk levels are rated as high, medium, or low, as defined in Table 2.3.3-1. Related or similar
observations are grouped together for discussion purposes.
During the risk assessment, a site visit to the SHGTS computer room located in room 1234 of
executive office complex of the OGG facility in Washington, DC indicated that adequate
environmental security was in place. The identified observations were grouped into the following
three primary security areas, which are discussed in Sections 5.1–5.3:
Management Security
Operational Security
Technical Security
Management Security
Management controls focus on the management of the IT security system and the management of
risk for a system. They are techniques and concerns that are normally addressed by management.
There was one finding in the area of management security.
Observation M1: The accounts of SHGTS users who no longer require access may not be
deleted immediately from the system.
Currently, the accounts of the users who no longer require access to the SHGTS application are
not required to be deleted immediately.
Threat and Vulnerability Assessment: Employees who no longer require access could
disclose or alter SHGTS data (e.g., amount, recipient, and SSNs). The likelihood that the
vulnerability would be exploited is estimated to be medium.
19
Potential Impact: Exploitation of this vulnerability could result in input of falsified data,
which could affect data integrity, which in turn could allow grants to not be properly
assigned. The potential impact is medium.
Risk Estimation: The likelihood of exploitation of this vulnerability is moderate and its
potential impact is estimated as medium. Therefore, the risk is estimated as medium.
Recommendation: Ensure that the ISSO receives communication from human resources
when a user terminates employment. Require the site security officer (SSO) to deactivate and
remove the SHGTS terminated user accounts from the system upon receipt of notification.
Operational Security
The operational controls address security methods focusing on mechanisms primarily
implemented and executed by people (as opposed to systems). These controls are put in place to
improve the security of a particular system (or group of systems). Often, they require technical or
specialized expertise and rely upon management activities as well as technical controls. There
were a total of three findings in the area of operational security.
Observation O1: A system security plan (SSP) has not been developed for the SHGTS.
A review of all available documentation revealed that SHGTS does not have its own SSP. An
SSP exists for the JINX GSS where the SHGTS resides, however, as an MA, the SHGTS is not
covered under the JINX2 SSP.
Threat and Vulnerability Assessment: Lack of documentation can lead to difficulty in
supporting and enhancing the SHGTS in the future. The lack of complete documentation
could also lead to incomplete security policy and procedure functionality being followed,
thus leaving the system vulnerable to threats.
Potential Impact: If security documentation is not available for access, users may
involuntarily compromise the SHGTS by leaving it unsecured and susceptible to various
vulnerabilities and threats, both internal and external. The impact of this vulnerability is
medium.
Risk Estimation: Based on the criticality of the SHGTS, the moderate likelihood of threat
exploitation and moderate impact of such exploitation, the risk associated with this
observation is estimated to be medium.
Recommendation: In order to document the security processes of the system and to comply
with the requirements of OMB Circular No. A-130, the OGG should develop an SSP for the
SHGTS. At a minimum, the SSP should address the following:
– Rules of the system
– Training
– Personnel controls
– Incident response capability
– Continuity of support
– Technical security
– System interconnection
20
OGG management should also refer to National Institute of Standards and Technology (NIST)
Special Publication 800-1: Guide for Developing Security Plans for Information Technology
Systems to assist them with the development of their SSP.
Observation O2: A DRP has not been developed for the SHGTS.
Backup capability is in place for the SHGTS via the JINX server. However, a DRP has not been
developed and documented specifically for the SHGTS.
Threat and Vulnerability Assessment: There is a reasonable probability that storms,
lightning strikes, fire, long-term power failure, and threat actions by unauthorized persons
(e.g., bomb threats) or authorized persons (e.g., inadvertent error) could destroy SHGTS
hardware, software, and data, resulting in a denial of system availability. The overall
likelihood of such an event is medium.
Potential Impact: Without a documented and well-tested DRP, adequate controls might not
be in place to mitigate a severe service interruption that might significantly affect the OGG’s
mission. Moreover, if controls are inadequate, even a minor interruption might result in lost
or incorrectly processed data. If a hot site or a cold site has not been defined to ensure
immediate service recovery and continuity of operations, a major system interruption
requiring extensive recovery efforts would halt operations of the SHGTS. Depending on the
level of disaster and the damage it caused, the potential impact of this threat could range
from medium to high.
Risk Estimation: Based on the criticality of the SHGTS, the moderate likelihood of threat
exploitation, and the moderate impact of such exploitation, the risk associated with this
observation is estimated to be medium.
Recommendation: To comply with the requirements of OMB Circular No. A-130, the OGG
should develop a DRP to ensure the ability to restore the SHGTS within a reasonable amount
of time and to minimize the impact of a disaster. A DRP should include the following:
– Identification of required support resources (e.g., deciding whether a hot site, a cold
site, or a warm site should be used)
– Documentation of detailed procedures for the transition to alternative backup resources
during an emergency
– Designation of DRP team members and definition of their roles and responsibilities
– Coordination of efforts with the HBWC disaster network recovery procedures to
minimize or eliminate conflicts
– Development of procedures for restoring the system at an off-site location.
Observation O3: There are no sign-in logs for visitors accessing the computer room.
Visitors are required to wear visitor stickers when accessing the computer room, but the visitor
stickers are not time-stamped and are available at the front door of the of the computer room
without a guard’s supervision. There was no sign-in log that documented visitors’ access to the
computer room.
21
Threat and Vulnerability Assessment: Without sign-in logs for visitors accessing the
computer room, the OGG may not adequately monitor visitors who enter and exit the
computer room that houses the JINX servers. However, the likelihood of this vulnerability’s
being exploited is low since the computer room is staffed 24 hours a day and OGG personnel
are trained to challenge visitors to the computer room.
Potential Impact: Unauthorized persons or disgruntled employees could damage the server
hardware, software, and data. Denial of server access could render the SHGTS application
inaccessible to the users. The potential impact is estimated as medium.
Risk Estimation: The estimated risk is low based on the likelihood of occurrence and the
moderate impact.
Recommendation: In order to minimize the vulnerabilities associated with this risk, the
following items should be implemented:
– Require visitors to sign an access log that details, at a minimum, their name,
organization, purpose, and the date and time they enter and exit the computer room
– Leave the temporary visitor stickers with the staff member responsible for computer
room access so that the visitor stickers are controlled.
Technical Security
Technical controls focus on security controls that the computer system executes. The controls
can provide automated protection for unauthorized access or misuse, facilitate detection of
security violations, and support security requirements for applications and data. There were a
total of four findings in the area of technical security.
Observation T1: Passwords on the JINX server are not required to be changed at least
every ninety days.
Observation T2: There is no limit to the number of invalid access attempts that may occur
for a given user.
These two observations were identified through interviews with the JINX Windows NT system
administrator. Because these observations address similar issues, they are discussed together.
Account policy of users directly affects the overall security of the computer system. Setting a
minimum password and enabling account lockout are effective measures in preventing
unauthorized people from accessing a system.
Threat and Vulnerability Assessment: Unauthorized users who have valid user
identifications (user IDs) may try and guess passwords in order to access the system. If they
are able to access the system, their next step may be to elevate their privileges, which could
affect the availability (denial of service) and/or integrity (manipulating data) of the system.
Enabling account lockout and minimum password age are effective measures in deterring
password guessing. The likelihood of threat exploitation is medium.
Potential Impact: The direct impact of this vulnerability on the SHGTS is estimated to be
medium because the entire Maryland medical community uses the OGG grants
22
recommendations. Data manipulated with malicious intent could cost the OGG between
$150,000 and $300,000.
Risk Estimation: Based on its medium likelihood and medium impact, the risk associated
with this scenario is estimated to be medium.
Recommendation: The Windows NT administrator should consult with OGG management
to determine what the minimum password age and account lockout settings should be. The
Windows NT administrator should then implement those changes on the system immediately.
Observation T3: Null session login may be possible.
This observation was identified by the network scan, which determined that the JINX server
allowed remote computers to establish a null session.
Threat and Vulnerability Assessment: For Windows NT networks with multiple domains,
NT provides a mechanism for remote computers to establish an anonymous session without
providing any credentials. This mechanism allows listing of users, groups, and share names
on the remote computer in native Windows NT tools, such as the server manager, user
manager, and access control list (ACL) editor. Allowing an attacker to obtain sensitive
system information can help the attacker launch attacks against the JINX server. Although
this is a known deficiency in the Windows NT operating system (OS) security and a number
of hacker tools are freely available in the public domain that facilitate such exploitation, the
OGG has firewalls and an intrusion detection system (IDS) in place. Therefore the likelihood
of threat exploitation is low.
Potential Impact: The direct impact of this vulnerability on the SHGTS is estimated to be
low, but an attacker could use this information in planning and launching future attacks
against the SHGTS. Unauthorized disclosure, alteration, and deletion of system and
application data could adversely affect system integrity, confidentiality, and availability. The
overall impact is medium.
Risk Estimation: Based on its low likelihood and medium impact, the risk associated with
this scenario is estimated to be low.
Recommendation: Windows NT service pack (SP) 3 and later SPs provide a new pseudo
group called Authenticated Users. This group is the same as the Everyone pseudo group
except that Authenticated Users does not contain Anonymous. It is recommended that the
Everyone group be replaced in all ACLs with the Authenticated Users group to disable
nonessential services.
Observation T4: Remote registry access is not restricted to administrators.
This observation was identified by the network scan, which determined that the JINX server with
IP address XXX.XXX.XXX.234 might allow unauthorized users to access the local registry from
a remote computer.
23
Threat and Vulnerability Assessment: The Windows NT registry is the repository for all
system configurations, including security-related settings. By default, a Windows NT server
allows only system administrators to access the system registry from a networked computer.
The remote registry access can be controlled by setting the permissions on the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winre
g so that only system and administrator accounts can access it. The network scan determined
that either this key does not exist (which allows access to the Everyone group) or its
permissions are set to allow some nonadministrators remote access to the registry.
In the past, Windows NT allowed anonymous access to the registry, a situation that was
corrected with the introduction of SP 3. However, many freely available hacking tools still
attempt to test this vulnerability. In addition, because null session log in may be possible
(Observation T3), the likelihood of threat exploitation is high.
Potential Impact: If this vulnerability were exploited, the JINX could be compromised.
Because the configurations of Windows NT member servers mirror one another,
compromising one server may allow the attacker to launch attacks against other connected
servers. Therefore, the potential impact of this scenario is high.
Risk Estimation: The likelihood and the adverse impact of exploitation are estimated as
high. Therefore, the risk associated with this scenario is estimated to be high.
Recommendation: The OGG should make mitigation of this vulnerability a top priority. The
corrective measures are as follows:
Launch the Registry Editor (Reged32.exe) and navigate to the registry key,
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winre
g. If the key does not exist, re-create it and set its permissions as follows:
– Administrator
Full Control
– System
Full Control
– Backup Operators
Read*
* If the backup operator role is separated from the administrator role, backup operators may
need to have read access to this key.
24
APPENDIX A. RISK ASSESSMENT MATRIX
No.
BLSR
Threats
Impact
Risk/Level
Priority
Countermeasure
Management Security
M1
Accounts of SHGTS users who no longer
require access are not deleted from the system
immediately
Disgruntled employees,
unauthorized users
Corrupted data, malicious
code
Medium
6
Require the supervisors of OGG terminated
employees to inform the system responsible
personnel (e.g., the OGG system manager) 5 days
before the employment termination or, at the latest,
immediately after the termination
Require the system responsible persons to deactivate
and remove the OGG terminated user accounts from
the system upon notification of employment
termination. Action should be taken immediately for
privileged application users who are granted a user
access code of 300 or above
Require the system responsible personnel to review
the list of application user accounts regularly to
ensure that no inactive accounts exist on the SHGTS
Operational Controls
O1
O2
A system security plan has not been developed
for the SHGTS
A continuity of operations plan (COOP) has
not been developed for the SHGTS
Disgruntled employees,
unauthorized users
Natural disaster,
environmental control
failures
Compromise of entire
system
Service interruption could
significantly affect ability
to perform work; loss of
25
Medium
Medium
2
3
Develop an SSP that, at minimum, addresses the
following:
Rules of the system
Training
Personnel controls
Incident response capability
Continuity of support
Technical security
System interconnection
In coordination with site facilities, develop and
document a COOP to ensure system continuity
during an emergency
No.
BLSR
Threats
Impact
Risk/Level
Priority
Countermeasure
data
O3
There are no sign-in logs for visitors accessing
the computer room
Disgruntled employees,
unauthorized users
Damage to SHGTS assets
(hardware, software, data).
Low
8
Require visitors to sign an access log that details, at
a minimum, their name, organization, purpose, and
the date and time they enter and exit the computer
room
Technical Security
T1
Passwords not required to be changed at least
every 90 days
Disgruntled employees,
unauthorized users
Impersonation
Medium
4
Require that the minimum password age be set to 90
days or fewer.
T2
There is no limit to the number of invalid
access attempts that may occur for a given use.
Disgruntled employees,
unauthorized users
Password guessing (e.g.
dictionary attack, brute
force attack), denial of
service, system
compromise
Medium
5
Require that the account be locked out after three
invalid login attempts
T3
Null session login may be possible
Disgruntled employees,
unauthorized users
Information obtained could
be used in planning and
launching future attacks
against the SHGTS
Low
7
Create and set the following registry entry:
Unauthorized disclosure,
alteration, and deletion of
system and application
data could adversely affect
SHGTS integrity,
confidentiality, and
availability
Run Registry Editor (Regedt32.exe) and select the
following key in the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentCon
trolSet\Control\LSA
On the Edit menu, click Add Value and use the
following entry:
Value Name: Restrict Anonymous
Data Type: REG_DWORD
Value: 1
(WARNING: Microsoft warns that using Registry
Editor incorrectly can cause serious, system-wide
problems that may require reinstallation of Windows
NT for their correction.)
26
No.
T4
BLSR
Remote registry access is not restricted to
administrators
Threats
Disgruntled employees,
unauthorized users, and
hackers
Impact
The JINX server could be
compromised
Compromising one server
may allow the attacker to
launch attacks against
other connected servers
Risk/Level
High
Priority
Countermeasure
1
Launch the Registry Editor (Reged32.exe) and
navigate to the Registry key,
HKEY_LOCAL_MACHINE\SYSTEM\CurrentCon
trolSet\Control\SecurePipeServers\winreg. If the key
does not exist, re-create it and set its permissions as
follows:
Administrator
Full Control
System
Full Control
Backup Operators
Read*
* If the backup operator role is separated from the
administrator role, backup operators may need to
have read access to this key
27
APPENDIX B. ACRONYMS
ACL
access control list
HBWC
Healthy Body Wellness Center
BLSR
baseline security requirement
C&A
certification and accreditation
COOP
continuity of operations plan
DAA
designated approving authority
DBA
database administrator
DRP
disaster recovery plan
FIPS
federal information processing standard
GSS
general support system
IDS
intrusion detection system
INFOSEC
information security
ISSO
information system security officer
IT
information technology
MA
major Application
NIST
National Institute of Standards and Technology
NT
new technology
OGG
Office of Grants Giveaway
OMB
Office of Management and Budget
OS
operating system
RAS
remote access server
RFP
request for proposal
SDLC
software development life cycle
SHGTS
Small Hospital Grants Tracking System
SOP
standard operating procedure
SP
Service Pack
SSO
system security officer
SSP
system security plan
VBA
visual basic for applications
VPN
virtual private network
WAA
We Automate Anything
WTE
We Test Everything
28
APPENDIX C. SAMPLE BASELINE SECURITY REQUIREMENTS
No.
Security Requirement
Compliance
Yes
No
Comments
Other
MANAGEMENT CONTROLS
Administration and Management Security
1.
2.
3.
4.
5.
Assignment of Responsibilities
Assign responsibility for security in writing to
an individual trained in the technology used in
the system and in providing security for such
technology (OMB Circular No. A-130,
Appendix III, Section B-a.1, b.1)
Assign responsibility for security in each
system to an individual knowledgeable in the
information technology used in the system and
in providing security for such technology
(OMB A-130, Appendix III, Section A-3, a.1)
Establish clear lines of authority and
responsibility within the HBWC for the
allocation of resources in securing critical
infrastructure assets (Clinton)
System/Application Security Plan
Require and develop system security plan
(SSP) for all federal computer systems that
contain sensitive information; update and
review the SSP every three years (OMB A130 Appendix III, Section A-3, a.2, b.2,
Section B-a.2, b.2; Computer Security Act of
1987, Section 6.b)
The security plan is implemented and
adequately secures the system or application
(OMB A-130 Appendix III, Section A-3, a.2,
b.2; A-130, 8a.2.c. (iv))
Rules of Behavior
29
No.
6.
7.
8.
9.
10.
11.
Security Requirement
Compliance
Yes
No
Comments
Other
Establish rules of behavior for system and
application use. The rules should clearly
delineate responsibilities of and expectations
for all individuals with access to the system
(OMB A-130 Appendix III, Section A-3,
a.2.a, b.2.a, Section B-a.2.a, b.2.a)
Training
Provide for the mandatory periodic training in
computer security awareness and accepted
computer security practice of all employees
who are involved with the management, use,
or operation of a federal computer system
within or under the supervision of the federal
agency (OMB A-130 Appendix III, Section
A-3, a.2.b, b.2.b, Section B-a.2.b, b.2.b;
Computer Security Act of 1987, Section 5.a)
OPM regulation requires training for new
employees within 60 days of hire (CIAO, 6)
Provide specialized training for all individuals
given access to the system/application (OMB
A-130 Appendix III, Section A-3, b.2.b,
Section B, b.2.b)
The Office of the CIO and CIAO shall
develop and promulgate training standards to
ensure that personnel staffed in key positions
within the HBWC's critical infrastructure are
proficient in their jobs (Clinton)
Computer security training should be
implemented into existing training programs
such as orientation programs for new
employees, and training courses involved with
information technology systems equipment
and software packages (NIST FIPS PUB 191,
Appendix A GP9)
30
No.
12.
13.
14.
15.
16.
17.
Security Requirement
Compliance
Yes
No
Comments
Other
Training shall be provided to all users on the
security features of the office automation
software resident on their respective systems.
They also need to understand the security
features of the local area network (LAN) to
which they are connected, as well as security
issues related to the Internet, intranet, and/or
extranet (CIAO, 6)
OPM regulation requires training when an
employee enters a new position that deals with
sensitive information (CIAO, p.6)
OPM regulation requires refresher courses
based on the sensitivity of the information the
employee handles (CIAO, 6)
Personnel Security
Controls include individual accountability,
least privilege, and separation of duties
enforced by access controls (OMB A-130
Appendix III, Section A-3, a.2.c, b.2.c,
Section B-a.2.c, b.2.c)
Segregation of duties within the IT function
should include the following: separation
between operations and programming, an
independent control group, implementation of
a librarian function, rotation of operators,
closed-shop operations, and required
vacations for all employees
(OMB A-130; CIAO, 18)
Require personnel controls to screen
individuals prior to being authorized for
system access and periodic screening
thereafter (OMB A-130 Appendix III, Section
A-3, a.2.c, b.2.c)
Incident Response Capability
31
No.
18.
19.
20.
21.
22.
23.
Security Requirement
Compliance
Yes
No
Comments
Other
Establish an incident response capability to
provide help to users when a security incident
occurs (OMB A-130 Appendix III, Section A3, a.2.d Section B-a.2.d; CIAO, 47; Clinton)
Continuity of Support
Establish continuity of support to periodically
test the capability to provide continual service
to users within a system (OMB A-130
Appendix III, Section A-3, a.2.e, Section Ba.2.e)
Areas of control will include continuity of
service operations (CIAO, 18)
Establish contingency planning to periodically
test the capability of the major application to
perform and function in event of failure of its
automated support (OMB A-130 Appendix
III, Section A-3, b.2.d)
Information Sharing
Limit the sharing of information that identifies
individuals or contains proprietary
information to that which is legally
authorized, and impose appropriate conditions
on use where a continuing obligation to ensure
the confidentiality of the information exists
(OMB A-130 A130-8.a.9.(c))
Assure that information which is shared with
federal organizations, state and local
governments, and the private sector is
appropriately protected comparable to the
protection provided when the information is
within the application (OMB A-130 Appendix
III, Section A-3, b.2.f, Section B-b.2.f)
Public Access Control
32
No.
24.
25.
26.
27.
28.
29.
Security Requirement
Compliance
Yes
No
Comments
Other
Implement appropriate public access control
where application promotes or permits public
access. Additional security controls shall be
added to protect the integrity of application
and the confidence the public has in the
application (OMB A-130 Appendix III,
Section A-3, b.2.g, Section B-b.2.g)
Review of Security Controls
Perform an independent review or audit of the
security controls in each system or application
at least every three years (OMB A-130
Appendix III, Section A-3, b.3, Section B-b.3)
Risk Assessment
A risk analysis shall be performed whenever
there is a significant change to the installation.
A significant modification made to an SBU
AIS or network shall require a review to
determine the impact on the security of the
processed SBU information (OMB A-130, III4, 3.c.2.b)
Vulnerabilities assessments (reviews to
identify existing weaknesses but not to
determine if all requirements are met) of all
assessable units (i.e., computer system or
application) shall be performed, at a
minimum, every three years (OMB Circular
No. A-123, 6, 8c)
A vulnerability audit will be performed to find
and document the vulnerabilities in critical
information assets (CIAO, p.17)
Perform risk assessment to include a
consideration of major factors in risk
management to determine adequate security
for the AIS (OMB A-130 Appendix III
Section B)
33
No.
30.
31.
32.
33.
34.
35.
Security Requirement
Compliance
Yes
No
Comments
Other
Authorize Processing
The system/application must be authorized
prior to operation and reauthorized at least
every three years thereafter (OMB A-130
Appendix III, Section A-3, a.4, b.4, Section Ba.4)
Security Management
Standards should include minimum expected
control guidance, including computer facilities
controls, computer operations controls,
input/output handling controls, network
management controls, and technical support
and user liaison policy (NIST SP 500-169)
Based on the results of the vulnerability
assessments, remedial action plans will be
developed to mitigate the impact of the threats
identified (Clinton)
Implement and maintain IT programs to
establish controls to assure adequate security
for all information processed, transmitted, or
stored in Federal AIS (OMB A-130 Appendix
III, Section A-3)
Establish a level of security for all HBWC
information systems that is commensurate
with the sensitivity of the information and the
risk and magnitude of loss or harm that could
result from improper operation of the
information system (OMB A-130, 8.1.g)
Data and File Protection
Establish procedures to ensure the proper
disposal of printed output based on the
sensitivity of the data (Good business
practices [GBP])
34
No.
Security Requirement
Compliance
Yes
No
36.
Establish procedures to ensure compliance
with The Privacy Act (OMB A-130, 7.g)
37.
Prohibit smoking and eating in magnetic
computer tape storage libraries that contain
permanent or unscheduled records (GBP)
The classification of sensitive data that
requires protection shall be determined.
Appropriate action will be taken to ensure that
proper labeling banners are attached on the
document (GBP)
Anti-Virus Protection
LAN servers should be scanned by the area
responsible for LAN management to assure no
virus becomes resident on the LAN server
(NIST FIPS PUB 191, Appendix A, 4.LA4)
Backup of Software and Data
Backup procedures shall be properly
documented, understood by IT personnel, and
be integrated/coordinated with the
organization’s disaster recovery plan (GBP)
Backup procedures shall provide for off-site
secured storage (GBP)
Off-site facilities should be sufficiently distant
from the operating facility to provide adequate
protection against major natural disasters (e.g.,
earthquakes and hurricanes) (GBP)
Weekly, monthly, and yearly backup of
magnetic media is rotated and transported to
an off-site storage facility (GBP)
38.
39.
40.
41.
42.
43.
Comments
Other
35
No.
44.
45.
46.
47.
48.
49.
50.
Security Requirement
Compliance
Yes
No
Comments
Other
External labels for diskettes or removable
disks used when processing or temporarily
storing permanent or unscheduled records
shall include the following information: name
of the organizational unit responsible for the
records, descriptive title of the contents, dates
of creation, data sensitivity, if applicable, and
identification of the software and hardware
used (GBP)
Configuration Management
Systems should be thoroughly tested
according to accepted standards and moved
into a secure production environment through
a controlled process (NIST SP 500-169)
Adequate documentation should be considered
an integral part of the information system and
be completed before the system can be
considered ready for use (NIST SP 500-169)
All program changes should be approved
before implementation to determine whether
they have been authorized, tested, and
documented (GBP)
Ensure that there is adequate and effective
deployment of hardware or software/firmware
changes across multiple sites (GBP)
Updates and changes in LAN communication
hardware and software should be tested
thoroughly to prevent unintentional access
exposures (GBP)
Data standards are established and
promulgated to ensure that consistent data
definitions, coding schemes, naming
conventions and formats are employed (GBP)
36
No.
Security Requirement
51.
All operating systems and applications are
patched with the latest vendor security patches
as applicable (GBP)
A configuration management process is in
place to test and install vendor security
patches (GBP)
All applications are tested for input boundary
conditions to prevent buffer overflows and
other privileged access (GBP)
Passwords shall be encrypted (GBP)
52.
53.
54.
Compliance
Yes
No
Comments
Other
TECHNICAL CONTROLS
Communications Security
55.
56.
57.
58.
59.
60.
Remote Access/ Dial-Up Access
Appropriate access controls should be in place
to support dial-up access to the organization’s
computer resources. Remote interfaces to the
network should provide the same security
available when connecting to the network
locally (GBP)
Controls should be established to ensure that
remote users are positively identified and
authenticated before connection to the
network is authorized (GBP)
Dial-up authority should only be granted to
the organization’s personnel who have a need
to access the network (GBP)
Request for dial-up access must be approved
by the requester’s LAN administrator (GBP)
Procedure should be developed to facilitate
the removal of dial-up capabilities when the
organization’s personnel are no longer
authorized to dial-in (GBP)
Dial-up ports should be protected from
unauthorized access (GBP)
37
No.
61.
62.
63.
64.
65.
66.
67.
Security Requirement
Compliance
Yes
No
Comments
Other
Do not leave personal computers containing
sensitive data which are connected to
answering modems unattended (GBP)
If the auto-answer mode for a system is only
used during normal working hours, disable
that mode after hours (GBP)
Dial-up to the organization’s computer
resources must only occur through approved
entry points (centrally managed) to ensure
integrity of network security (GBP)
Firewalls
Firewalls will be installed to control access to
the internal network (CIAO, 33)
Firewalls will be used for blocking
unauthorized incoming traffic (CIAO, 34)
Intrusion detection systems (IDS) will be used
to do the following:
Monitor and analyze user and system
activity
Assess the integrity of critical system
and data files
Recognize activity patterns involved
in known attacks
Perform statistical analyses to spot
abnormal activity patterns that may
indicate an attack
Manage the operating system audit
trail and alert system managers to
user behavior
(CIAO, 36)
Vulnerability scanners will be used to identify
weaknesses which could lead to security
violations and uncover possible breaches
(CIAO, 33)
38
No.
68.
69.
70.
71.
72.
73.
74.
75.
Security Requirement
Compliance
Yes
No
Comments
Other
Encryption
Sensitive data files should be protected during
transmission from one location to another
(GBP)
Encryption should be available for sensitive
information transmissions whenever needed
(GBP)
Interconnection
Require system interconnection to obtain
written management authorization, prior to
connecting with other systems (OMB A-130
Appendix III, Section A-3, a.2.g, Section Ba.2.g)
The area responsible for LAN management
should secure the LAN environment within
the site and interfaces to outside networks
(NIST FIPS PUB 191, Appendix A, 3. NM3)
Router
Screening routers shall have the capability to
filter based on TCP and UDP ports as well as
IP addresses and incoming network interfaces
(GBP)
A screening router shall not be used as the
sole segment of a firewall system; rather it
should form a portion of the security bastion
(GBP)
Inbound filtering will be performed to exclude
or reject all data packets that have an internal
host address (GBP)
Inventory of Network Hardware and Software
Accurate records of hardware/software
inventory, configurations, and locations
should be maintained (NIST SP 500-169)
39
Compliance
No.
Security Requirement
76.
Develop and maintain a comprehensive
inventory of IT equipment, hardware and
software configurations, and major
information systems/applications, identifying
those systems/applications which process
sensitive information (GBP)
An asset inventory shall be conducted to
determine what systems, data, and associated
assets (e.g., facilities, equipment, and
personnel) constitute the critical information
infrastructure (CIAO, 10)
77.
Yes
No
Comments
Other
Computer Security
78.
79.
80.
Interrelate technical, operational, and
management controls to assure adequate
security for all information processed,
transmitted, or stored in federal AIS; (e.g.,
password protection will only be effective if
both a strong technology is employed and it is
managed to ensure that it is used correctly)
(OMB A-130 Appendix III, Section B)
Establish technical controls to ensure
appropriate security controls are specified,
designed into, tested, and accepted in the
application in accordance with NIST guidance
(OMB A-130 Appendix III, Section A-3,
b.2.e)
The area responsible for LAN management
(or designated personnel) should rigorously
apply available security mechanisms to
enforce local security policies (NIST FIPS
PUB 191, Appendix A, 3.NM1)
Identification and Authentication
40
No.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
Security Requirement
Compliance
Yes
No
Comments
Other
If automatic-login scripts for LAN or server
access are utilized, the script cannot contain
the password (GBP)
Users should be able to initiate a change of
their password independently (GBP)
The system shall support a lock-out threshold
if excessive invalid access attempts are input
(GBP)
User IDs must be revoked if a password
attempt threshold of three failed login
attempts is exceeded (GBP)
All passwords that are included in a new
system when it is delivered transferred or
installed shall be immediately changed (FIPS
112, 3.4.2)
Passwords must be stored with one-way
encryption (GBP)
No one but the user ID owner can have the
ability to know or view passwords (GBP)
Users must be authenticated to the LAN
before accessing LAN resources (NIST FIPS
PUB 191, Appendix A, GP6)
LAN user IDs should not be permitted to
initiate multiple concurrent logins to the LAN
network (GBP)
Terminals, workstations, and networked
personal computers should never be left
unattended when user ID and password have
been logged in (GBP)
Access Control
41
No.
91.
92.
93.
94.
95.
96.
97.
98.
Security Requirement
Compliance
Yes
No
Comments
Other
Access control software and/or network
operating system security should be kept
current and controls limiting user access to
sensitive data, applications, and programs
should be in place (GBP)
Access controls should encompass systems
and programs that edit, update, and store
information. Controls should permit access
only when specific authorization has been
granted (GBP)
Users must be restricted to only those
resources required for the efficient completion
of their job responsibilities (GBP)
Where appropriate, terminals/ workstations
should automatically log out if inactive for a
specified period of time (GBP)
System Audit
The system shall be able to create, maintain,
and protect from modification, unauthorized
access, or destruction an audit trail of accesses
to the resources it protects (GBP)
For each recorded event, the audit record shall
identify the following: date and time of the
event, user, type of event, and the success or
failure of the event (GBP)
The area responsible for LAN management
should conduct timely audits of LAN server
logs (NIST FIPS PUB 191, Appendix A, 3.
NM6)
Unauthorized attempts to change, circumvent,
or otherwise violate security features shall be
detectable and reported within a known time
by the system (GBP)
42
No.
99.
100.
Security Requirement
Compliance
Yes
No
Comments
Other
The security administrator will review reports
to determine if there have been repeated
unsuccessful attempts to log in to the network
(GBP)
Object Reuse
When a storage object (e.g., core area, disk
file, etc.) is initially assigned, allocated, or
reallocated to a system user, the system shall
assure that it has been cleared (GBP)
OPERATIONAL CONTROLS
Physical Security
101.
102.
103.
104.
105.
106.
107.
Employee access to the data site shall be
controlled by an electronic access system
(GBP)
Logs shall be required for recording all
physical access to the facility by unauthorized
individuals (GBP)
Escorts shall be provided for unauthorized
individuals at all times. Escorts will have
authorization for access to all areas of the
facility (GBP)
The distribution of keys should be strictly
limited and an effective control system
established (GBP)
Tapes, disks, and other storage media shall be
kept in a secure access-controlled
environment when not being utilized by
computer operations (GBP)
Secure methods are employed to safeguard
PCs and related hardware that contain
information during relocation (GBP)
File servers shall be located in areas where
access is restricted (GBP)
43
No.
108.
Security Requirement
Compliance
Yes
No
Comments
Other
The list of persons with authorized access
should be reviewed and recertified annually
(GBP)
Environmental Security
109.
The primary and backup processing sites as
well as the tape storage areas shall be
equipped with fire detection and suppression
systems that detect and suppress fire in the
incipient stage (GBP)
44
References
Clinton, Bill. (1998). Presidential decision directive /NSC 63. Retrieved from http://www.fas.org/irp/offdocs/pdd/pdd-63.htm
Computer security act of 1987: Public law 100-235 (H.R. 145) (1988). Retrieved from http://epic.org/crypto/csa/csa.html
Critical Infrastructure Assurance Office (CIAO). (2000). Practices for securing critical information assets. Retrieved from
http://www.infragard.net/library/pdfs/securing_critical_assets.pdf
National Institute of Standards and Technology. (1994). Guideline for the analysis of local area network security (Federal information
processing standards [FIPS] publication 191). Retrieved from http://www.itl.nist.gov/fipspubs/fip191.htm
National Institute of Standards and Technology. (1989). Executive guide to the protection of information resources (NIST SP 500169).
Office of Management and Budget (OMB). OMB circular no. A-123. Retrieved from
http://www.whitehouse.gov/omb/rewrite/circulars/a123/a123.html
Office of Management and Budget (OMB.) OMB circular no. A-130. Retrieved from
http://www.whitehouse.gov/omb/circulars_a130_a130trans4/
45