Healthy Body Wellness Center
Business Requirements Document Template
Healthy Body Wellness Center/Initiative
Month 20YY
Version X.XX
Company Information
Tech Comm Template
BRD
1 Document Revisions (Not required for performance assessment)
Version
Number
Date
05/02/20xx
0.1
Document Changes
Initial Draft
2 Approvals (Not required for performance assessment)
Role
Name
Title
Signature
Date
Project Sponsor
Business Owner
Project Manager
System Architect
Development Lead
User Experience
Lead
Quality Lead
Content Lead
Template provided by TechWhirl.com
copyright INKtopia Limited | All Rights Reserved
1
Tech Comm Template
BRD
3 Introduction
3.1
Project Summary
3.1.1
Objectives
[These should describe the overall goal in developing the product, high-level descriptions of what the
product will do, how they are aligned to business objectives, and the requirements for interaction
with other systems.]
3.1.2
Background
[Provide a brief history of how the project came to be proposed and initiated, including the business
issues/problems identified, and expected benefit of implementing the project/developing the
product.]
3.1.2.1
Business Drivers
[List the business drivers that make development of this product important. These can be financial,
operational, market, or environmental.]
Template provided by TechWhirl.com
copyright INKtopia Limited | All Rights Reserved
2
Tech Comm Template
BRD
3.2 Project Scope
[Describe what work is in scope for the project and what work is specifically out of scope—beyond the
current budget, resources, and timeline as approved by the project stakeholders. This is designed
to prevent “scope creep” of additional features and functions not originally anticipated.]
3.2.1
In-Scope Functionality
3.2.2
Out-of-Scope Functionality
3.3 System Perspective
[Provide a complete description of the factors that could prevent successful implementation or accelerate
the projects, particularly factors related to legal and regulatory compliance, existing technical or
operational limitations in the environment, and budget/resource constraints.]
3.3.1
Assumptions
3.3.2
Constraints
3.3.3
Risks
3.3.4
Issues
Template provided by TechWhirl.com
copyright INKtopia Limited | All Rights Reserved
3
Tech Comm Template
BRD
4 Business Process Overview
[Describe how at least two of the current and proposed processes work, including the interactions
between systems and various business units. Include visual process flow diagrams to further
illustrate the processes the new product will replace or enhance.
Use case documentation and the accompanying activity. Alternatively, process flow diagrams can be
used to create the descriptions of the proposed or “To-Be” processes.]
4.1 Current Business Processes (As-Is) (At least 2)
4.2 Proposed Business Processes (To-Be) (At least 2)
Template provided by TechWhirl.com
copyright INKtopia Limited | All Rights Reserved
4
Tech Comm Template
BRD
5 Business Requirements
[The specific business requirements elicited from stakeholders should be listed and categorized by both priority and area of functionality to
smooth the process of reading and tracking them. Include links to use case documentation and other key reference material as needed to
make the requirements as complete and understandable as possible. You may wish to incorporate the functional and nonfunctional
requirements into a traceability matrix that can be followed throughout the project.]
The requirements in this document are prioritized as follows:
Value
Rating
Description
1
Critical
This requirement is critical to the success of the project. The project will not be
possible without this requirement.
2
High
This requirement is high priority, but the project can be implemented at a bare
minimum without this requirement.
3
Medium
This requirement is somewhat important, as it provides some value, but the
project can proceed without it.
4
Low
This is a low priority requirement, or a “nice to have” feature, if time and cost
allow it.
5
Future
This requirement is out of scope for this project and has been included here for a
possible future release.
5.1 Functional Requirements
Req#
Priority
Description
Use Case
Reference
Rationale
General / Base Functionality
Template provided by TechWhirl.com
copyright INKtopia Limited | All Rights Reserved
5
Impacted
Stakeholders
Tech Comm Template
BRD
Development
teams
Infrastructure
engineers
Security Requirements
Reporting Requirements
Usability Requirements
Audit Requirements
Template provided by TechWhirl.com
copyright INKtopia Limited | All Rights Reserved
6
Tech Comm Template
BRD
5.2 Nonfunctional Requirements
[Include technical and operational requirements that are not specific to a function. This typically includes requirements such as processing time,
concurrent users, availability, etc.]
ID
Template provided by TechWhirl.com
copyright INKtopia Limited | All Rights Reserved
Requirement
7
Tech Comm Template
BRD
6 Appendices (Not required for performance assessment)
6.1 List of Acronyms
[If needed, create a list of acronyms used throughout the BRD document to aid in comprehension.]
6.2 Glossary of Terms
[If needed, identify and define any terms that may be unfamiliar to readers, including terms that are
unique to the organization, the technology to be employed, or the standards in use.]
6.3 Related Documents
[Provide a list of documents or web pages, including links, which are referenced in the BRD.]
Template provided by TechWhirl.com
copyright INKtopia Limited | All Rights Reserved
8
C726: Case Study
Healthy Body Wellness Center
Case Study
PAGE 1
C726: Case Study
HBWC Case Study
Healthy Body Wellness Center (HBWC) Mission and Vision
The Healthy Body Wellness Center’s mission is to help patients take responsibility for their
overall wellbeing and educate members of the local community in the practice of wellness.
The HBWC includes an Office of Grants Giveaway (OGG), responsible for the business
process of distributing a variety of medical grants designed to investigate multiple facets of
community wellness, with the majority of grants disbursed to small hospitals, defined as
having 250 beds or less. HBWC has a business process for collecting and storing the
associated research data.
HBWC is planning to modernize the employee payroll and benefits management business
process across the company through the use of an outsourced provider, such as Workday,
ADP, or Peoplesoft. HBWC is also planning to upgrade its research database and develop a
cloud-based grant tracking system. The company wants an analysis of the feasibility and
planning for conversion to be added for consideration to the overall design for HBWC’s
future infrastructure and services.
Office of Grants Giveaway (OGG) Mission and Vision
The mission of the HBWC’s OGG is to promote improvements in the quality and usefulness
of medical grants through federally supported National Institutes of Health (NIH) research,
evaluation, and sharing of information. The Small Hospital Grant Tracking System (SHGTS)
is the primary application used to manage this data. Although the SHGTS contains hospitalspecific banking data, grant funding is released via paper checks.
The SHGTS assists in the assignment and tracking of small hospital grants and is a singleuser system running on a desktop computer. The OGG assigns a grant to one hospital for
one month and then any unused grant funds are rotated to another hospital for the next
month. The SHGTS tracks the initial delivery of the grant funds, stores pertinent
information, and then follows the grant through the next five hospital facilities.
Only executive OGG staff can assign grant funds, but all principal investigators must
complete their grant evaluations in the application. With the Paper Reduction Act, the
federal government is moving their application from paper-based to an online submission
system. Each week the OGG executive officer receives a grant status report. Each month,
each principal investigator is briefed on the status of their current grants via reports
generated by the SHGTS.
The OGG is expecting to receive more medical grants from the NIH and needs a way to
grow the office’s staff while upgrading the infrastructure to support the current workforce,
which consists of part-time workers, work-from-home employees, and contractors. As the
OGG expands granting and resources for grant seekers, the creation of remote office
branches to meet those needs is also being considered.
OGG is also collecting the requirements for a new, web-based portal for use by recipients of
grants and researchers. This portal will contain patient-sensitive and other nonpublic
information (NPI) that must be adequately protected during processing, storage, and
transmission. Access to this resource will be managed by OGG staff with the appropriate
privileged access.
PAGE 2
C726: Case Study
HBWC Case Study
HBWC’s current LAN administrator and security manager, who is responsible for most of the
technology that is presently in place at OGG, is retiring next month. You have been
promoted to assume this role upon the manager’s departure. Endothon Security Consulting
completed a security assessment report (SAR) on behalf of the HBWC, therefore in your
new position, you will be responsible for the following tasks
•
•
•
•
•
conducting a thorough analysis of what’s in place technology—and applications-wise
finding out which elements already in place are no longer able to support the
operations
synthesizing business, technical, security, and regulatory requirements for fitness in
ongoing operations
conducting a threat analysis of the applications and infrastructure to understand
network and application security needs
designing a replacement network to the existing LAN to support secure employee
remote access, secure ACH data transmissions, secure NPI and patient data to the
required levels and to support third-party extranet connections to cloud-based SaaS
providers of services to OGG
HBWC is primarily Microsoft-based and wishes to preserve their relationship with Microsoft
to ease migration from older-MS products to the newer suites of tools they offer (e.g., Office
365, SQL Server, ASP.NET). HBWC has a small staff of programmers needed to maintain
existing applications and is fluent in C# and VB.NET. HBWC’s internet service provider (ISP)
is Pogtech Communications, which provides broadband access for internal and planned
external users of their resources and services.
System Overview
The SHGTS is a Microsoft Access 2010 database that resides on the Windows 2008 R2
application server. The SHGTS application and its data are protected by built-in security
mechanisms supported by the hardened Windows 2008 R2 platform. Microsoft will stop
supporting Windows 2008 in January 2020 and then Access 2010 in October 2020. This
means that Microsoft will no longer supply patches for the software after 2020. MS Access is
unsuitable for use by multiple simultaneous users and will need to be migrated to a MS SQL
server with a new infrastructure. New access via the internet will also be required for
sharing data among NIH, HBWC, and the hospitals they serve. A persistent link to NIH may
be required to exchange data among multiple users and potentially multiple sites that might
be needed for processing grants.
To segregate functions in support of SHGTS, three technical support personnel (members of
the administrator group) have administrative rights to manage the Windows 2008 R2
server. The SHGTS database administrator (DBA) does not have administrative privileges to
the Windows 2008 R2 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:
PAGE 3
C726: Case Study
•
•
•
HBWC Case Study
Administrative: full control of the application, including the ability to alter code and
modify database objects
Executive: access to all reports and the ability to update key fields dealing with the
assignment of grants
Basic: access to most forms and the ability to update key fields relating to
information about assigned grants
A virtual private network (VPN) firewall appliance is in place for users that require remote
access to the SHGTS. Knowledge of the VPN is limited to users with a mission-essential
need. Users access the VPN via Pulse Secure software using a token or a personal identity
verification (PIV) badge.
Payroll is currently handled on HBWC’s premise using QuickBooks with paper checks. Direct
deposit has not been implemented. Grant money is also provided by paper checks. Checks
can be obtained from the office manager or sent through the mail.
HBWC’s patient information and other research data are kept in Excel spreadsheets.
Patients have a patient number assigned to them throughout the research period and a
conversion sheet between the patients and their associated numbers are also listed in Excel
to maintain patient confidentiality. Principal investigators at each hospital are allowed to
keep their data proprietary for one year while they are writing their research report. The
NIH then becomes proprietor of all data. A hard copy of the research report is then saved in
a file cabinet at the OGG and stored on the server. This makes it difficult for potential
principal investigators to mine the data for information that could be used in future
research.
System Interfaces
The SHGTS exchanges data with the NIH but does not give or receive any data to or from
any other major application (MA) or a group system support (GSS). The SHGTS resides on
Windows 2008 R2, but otherwise does not interface with any other system. It is accessed
from local application running on HBWC workstations connected to the LAN. HBWC staff
may access this database when they connect remotely through the VPN connection.
The HBWC uses a QuickBooks database for employee payroll, which is housed on the
Windows 2008 R2 server and is a standalone database that can be accessed from the client
workstations similar to the SHGTS.
The research raw data and reports are housed on the HBWC’s server in a fileshare.
Data
The SHGTS database contains private health information (PHI), other healthcare
information, and proprietary data in its tables. Data stored in the SHGTS includes specific
attributes about the grants such as control number, grant category, amount, distribution
schedule, and sunset date. Information detailing grant distribution particulars, such as
sponsoring staff, the directing official, and date assigned, is also stored in the system. The
research data is only attributable to an individual if the conversion table is viewed along
with the raw data.
PAGE 4
C726: Case Study
HBWC Case Study
QuickBooks contains personally identifiable information (PII) data on HBWC employees
including social security numbers, salaries, home addresses, emergency contacts, phone
numbers, and next of kin.
Criticality
The HBWC’s Information Systems Criticality Definition Process defines automated
information resources whose failure would not preclude 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 and efficiency of day-to-day operations being needed for
daily processing of grants. The SHGTS also includes the research data, and the failure of the
SHGTS would not preclude the HBWC from accomplishing core business operations in the
short to long term (a few hours to a few weeks), but loss of the research data would require
notification to NIH that the results of the research they funded is not available. However,
failure of the system would have not an impact on the effectiveness or efficiency of day-today operations. Consequently, the SHGTS database is considered mission supportive.
Failure of the QuickBooks database could prevent employees from getting paid. A paper
backup is maintained in case the server goes down, but the data may be a day old at
minimum.
Sensitivity
The criteria used to measure a system’s sensitivity include confidentiality, integrity, and
availability. The sensitivity areas for the SHGTS and QuickBooks are described below:
Confidentiality
SHGTS: 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.
Research data: High
The research data contains medical information on research subjects and needs to be
compliant with HIPAA regulations and protected from employees that do not have a need to
know. The research data also needs to be protected so that only the principle investigator
can have access to it for the first year.
QuickBooks: Medium
There is Privacy Act data included in the QuickBooks database and the information should
not be shared outside the payroll office.
Integrity
SHGTS: Medium
PAGE 5
C726: Case Study
HBWC Case Study
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
$1,000,000. Anyone involved with such data manipulation would possibly be sued but not
sent to jail.
Research Data: High
The integrity of the research data must be paramount since the loss of data or any change
in the data may show incorrect results of the research.
QuickBooks: High
The integrity of the data for salaries and other information regarding employees needs to be
accurate to make sure that everyone receives the appropriate salary, based on job title and
length of service.
Availability
SHGTS: Low
The reports are much easier to prepare with the database and it would be inconvenient if
the database were unavailable to locate specific grants. However, manual inspection of
invoices (for receipt information) and filed hard copies (to locate grants) could be used. The
consequences of the database being unavailable would be viewed as an inconvenience but
does not require a robust business continuity plan for continued access. 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 less than that
amount.
Research Data: Medium
The research data does not need to be available 24 hours, but the information should be
available when the principal investigator is preparing the final research report. A servicelevel agreement (SLA) and uptime schedule will be provided to researchers upon gaining
approval to use the application.
QuickBooks: Medium
The information in the QuickBooks database needs to be available on paydays (every
Friday). Hard copies are made of the information and stored in a filing cabinet, but that
information may be dated.
PAGE 6
C726: Cybersecurity Architecture
Systems Assessment Report
Security Assessment Report
for
Healthy Body Wellness Center (HBWC)
Security Categorization: Low
Version 1.0
Prepared by
Endothon Security Consulting
PAGE 1
Source: National Institutes of Health (NIH)
C726: Cybersecurity Architecture
Systems Assessment Report
FOR OFFICIAL USE ONLY
Document Revision History
The Systems Assessment Report (SAR) is a living document that is changed as required to reflect system,
operational, or organizational changes. Modifications made to this document are recorded in the version
history matrix below.
At a minimum, this document will be reviewed and assessed annually. Reviews made as part of the
assessment process shall also be recorded below.
This document history shall be maintained throughout the life of the document and the associated system.
Date
Description
Version
Author
12/02/20XX
Document Publication
1.0
Program Office
PAGE 2
Source: National Institutes of Health (NIH)
C726: Cybersecurity Architecture
Systems Assessment Report
Security Assessment Report (SAR) Approval Signatures
I have reviewed the Healthy Body Wellness Center (HBWC) SAR and accept the analysis and findings
within.
_______________________________________
__________
Leilani Johnson
Date
Security Control Assessor
_______________________________________
__________
Kamal Thomas
Date
System Owner
_______________________________________
__________
Eva Johnson
Date
Information System Security Officer
_______________________________________
__________
Ren Phan
Date
Privacy Coordinator
PAGE 3
Source: National Institutes of Health (NIH)
C726: Cybersecurity Architecture
Systems Assessment Report
Table of Contents
1
Overview ......................................................................................................................................... 6
2
System Overview ............................................................................................................................ 9
3
2.1
System Name ................................................................................................................... 9
2.2
General System Description and Purpose ............................................................................. 9
2.3
System Interfaces ........................................................................................................... 10
2.4
Data .............................................................................................................................. 10
2.5
Criticality ....................................................................................................................... 10
2.6
Security Categorization .................................................................................................... 11
Assessment Methodology ............................................................................................................... 12
3.4 Overall Security Findings ..................................................................................................... 15
3.5 Overall Findings Across All Connected Systems ...................................................................... 16
4
Security Assessment Results .......................................................................................................... 23
5
Nonconforming Controls ................................................................................................................ 28
6
Authorization Recommendation ...................................................................................................... 29
PAGE 4
Source: National Institutes of Health (NIH)
C726: Cybersecurity Architecture
Systems Assessment Report
From: Dr. Michael Sousa, Head Consultant, Endothon Security Consulting
To: Board of Directors, Healthy Body Wellness Center
We would like to thank Healthy Body Wellness Center (HBWC) for having us conduct this security audit for
the company. Endothon Security Consulting is a multimillion-dollar company specializing in the security of
grants and the grant process for companies and the U.S. federal government, such as the National
Institutes of Health (NIH).
Our key findings indicate HBWC needs specialized support in updating and modernizing their network,
grant process, and internal controls to address the changing landscape of laws, regulations, and standards
that apply to the federal government grant process. Specifically, HBWC needs to address
1. Lack of controls and policy covering system administration, governance, training,
accountability, and other identified processes in this report.
2. Systems design is outdated, requiring immediate attention to rectify
3. Web server and web-based services lack of cryptographic controls, auditing, accountability, and
user accounts do not meet business or security objectives for HBWC.
a. There is no attached database. Rather, each grant is processed as a text file, saved on a
network share that is then delivered to NIH via inbuilt polling software looking for hard
drive changes. This is unsuited to the current grant process developed by the U.S.
federal government and must be updated.
4. Lack of cryptographic controls is impeding the growth of HBWC and its ability to compete in the
block grant process from NIH.
5. Environmental concerns must be addressed, including disaster recovery and data center and
backup concerns.
6. Conduct a thorough analysis of existing technology and applications.
7. Which elements already in place are no longer able to support the operations.
8. Synthesizing business, technical, security, and regulatory requirements for fitness in ongoing
operations.
9. Conducting a threat analysis of the applications and infrastructure to understand network- and
application-security needs.
10. Design a replacement network to the existing LAN to support
• Secure employee remote access
• Secure ACH data transmissions
• Secure NPI and Patient data to the required levels
• Third-party extranet connections to cloud-based SaaS providers of services to Office of
Grants Giveaway (OGG)
We appreciate the time HBWC employees spent with us to help us compile this report. If you have any
questions, please feel free to consult Endothon Security Consulting at any time.
Regards,
Dr. Michael Sousa
PAGE 5
Source: National Institutes of Health (NIH)
C726: Cybersecurity Architecture
1
Systems Assessment Report
Overview
This document represents the Security Assessment Report (SAR) for HBWC as required by NIH for security
authorization. This SAR contains the results of the comprehensive security test and evaluation of HBWC.
This assessment report, and the results documented herein, supports program goals, efforts, and
activities necessary to achieve compliance with organizational security requirements. The SAR describes
the risks associated with the vulnerabilities identified during HBWC’s security assessment and also serves
as the risk summary report as referenced in NIST SP 800-37 Revision 1, Guide for Applying the Risk
Management Framework to Federal Information Systems.
All assessment results have been analyzed to provide both the information system owner, institute/center
information system security officer (IC ISSO), and the authorizing officials, with an assessment of the
security controls as described in the HBWC System Security Plan.
Title III, Section 3544, of the E-Government Act of 2002, dated December 17, 2002, requires agencies to
conduct periodic assessments of the risk and magnitude of harm that could result from the unauthorized
access, use, disclosure, disruption, modification, or destruction of information and information systems
that support the operations and assets of the agency. Appendix III of Office of Management and Budget
(OMB) Circular A-130, Management of Federal Information Resources, requires federal agencies to:
•
•
•
•
Review the security controls in each system when significant modifications are made to the system,
but at least every three years. §3(a)(3)
Protect government information commensurate with the risk and magnitude of harm that could
result from the loss, misuse, or unauthorized access to or modification of such information.
§8(a)(1)(g); §8(a)(9)(a)
Demonstrate specific methods used to ensure that risks and the potential for loss are understood
and continually assessed, that steps are taken to maintain risk at an acceptable level, and that
procedures are in place to ensure that controls are implemented effectively and remain effective
over time. §8(b)(3)(b)(iv)
Ensure that a management official authorizes in writing use of the application by confirming that its
security plan as implemented adequately secures the application. Results of the most recent review
or audit of controls shall be a factor in management authorizations. The application must be
authorized prior to operating and re-authorized at least every three years thereafter. Management
authorization implies accepting the risk of each system used by the application. §(3)(b)(4)
1.1 Applicable Laws and Regulations
The following laws and regulations are applicable to NIH:
•
•
•
•
•
•
Computer Fraud and Abuse Act [PL 99-474, 18 USC 1030]
E-Authentication Guidance for Federal Agencies [OMB M-04-04]
Federal Information Security Modernization Act (FISMA) of 2014
Freedom of Information Act as Amended in 2016
Guidance on Inter-Agency Sharing of Personal Data, Protecting Personal Privacy [OMB Memo M-0105]
Homeland Security Presidential Directive-7, Critical Infrastructure Identification, Prioritization, and
Protection [HSPD-7]
PAGE 6
Source: National Institutes of Health (NIH)
C726: Cybersecurity Architecture
•
•
•
•
•
•
•
•
•
•
Systems Assessment Report
Homeland Security Presidential Directive-12, Policy for a Common Identification Standard for
Federal Employees and Contractors, August 2005
Implementation of Homeland Security Presidential Directive 12, Policy for a Common Identification
Standard for Federal Employees and Contractors [OMB Memo M-05-24]
Internal Control Systems [OMB Circular A-123]
Management of Federal Information Resources [OMB Circular A-130]
Management’s Responsibility for Internal Control [OMB Circular A-123, Revised 12/21/2004]
Privacy Act of 1974 as amended [5 USC 552a]
Protection of Sensitive Agency Information [OMB M-06-16]
Records Management by Federal Agencies [44 USC 31]
Responsibilities for the Maintenance of Records About Individuals by Federal Agencies [OMB Circular
A-108, as amended]
Security of Federal Automated Information Systems [OMB Circular A-130, Appendix III]
1.2 Applicable Standards and Guidance
The following standards and guidance are applicable to the HBWC organization:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
A NIST Definition of Cloud Computing [NIST SP 800-145]
Computer Security Incident Handling Guide [NIST SP 800—61, Revision 1]
Contingency Planning Guide for Federal Information Systems [NIST SP 800-34, Revision 1]
Engineering Principles for Information Technology Security (A Baseline for Achieving Security) [NIST
SP 800-27, Revision A]
Guide for Assessing the Security Controls in Federal Information Systems [NIST SP 800-53A]
Guide for Developing Security Plans for Federal Information Systems [NIST SP 800-18, Revision 1]
Guide for Developing the Risk Management Framework to Federal Information Systems: A Security
Life Cycle Approach [NIST SP 800-37, Revision 1]
Guide for Mapping Types of Information and Information Systems to Security Categories [NISP SP
800-60, Revision 1]
Guide for Security-Focused Configuration Management of Information Systems [NIST SP 800-128]
Information Security Continuous Monitoring for Federal Information Systems and Organizations
[NIST SP 800-137]
Managing Information Security Risk [NIST SP 800-39]
Minimum Security Requirements for Federal Information and Information Systems [FIPS Publication
200]
Personal Identity Verification (PIV) of Federal Employees and Contractors [FIPS Publication 201-1]
Recommended Security Controls for Federal Information Systems [NIST SP 800-53, Revision 4]
Risk Management Guide for Information Technology Systems [NIST SP 800-30]
Security Considerations in the System Development Life Cycle [NIST SP 800-64, Revision 2]
Security Requirements for Cryptographic Modules [FIPS Publication 140-2]
Standards for Security Categorization of Federal Information and Information Systems [FIPS
Publication 199]
Technical Guide to Information Security Testing and Assessment [NIST SP 800-115]
1.3 Purpose
The purpose of the SAR is to provide the system owner, ISSO, and security authorization officials with a
summary of the risks associated with the vulnerabilities identified during the security assessment for
HBWC. A security assessment has been performed on HBWC to evaluate the system’s implementation of,
PAGE 7
Source: National Institutes of Health (NIH)
C726: Cybersecurity Architecture
Systems Assessment Report
and compliance with, the organization's baseline security controls. The details of the implementation of
security controls are described in the System Security Plan and required by Health and Human Services
(HHS) to meet Federal Information Security Management Act (FISMA) compliance mandates.
The organization requires information systems to use internal and third-party assessment organizations to
perform independent security assessment testing and documentation of the SAR. Security testing for
HBWC was performed by the head consultant of Endothon Security Consulting, Dr. Michael Sousa, in
accordance with the HBWC’s Security Assessment Plan.
1.4 Scope
The mission of the HBWC’s Office of Grants Giveaway (OGG) is to promote improvements in the quality
and usefulness of medical grants through federally supported NIH research, evaluation, and sharing of
information. The OGG distributes a variety of medical grants, with the majority of grants disbursed to
small hospitals. The Small Hospital Grant Tracking System (SHGTS) is the primary application used to
manage this data. Grant funding takes place using Automated Clearing House (ACH) processing. SHGTS
contains the hospital-specific banking data needed to process ACH payments.
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. The system in use is a single-user
system running on a desktop computer.
Only executive office staff can assign grant funds, but all grant users must complete their grant
evaluations in the application. 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 by the application.
HBWC is expecting to be getting more grant money from the NIH, and it needs a way to grow the staff
while upgrading the infrastructure to support growth with today’s workforce, which consists of part-time
workers, work-at-home employees, contract employees, and employees potentially working from remote
branches of HBWC as it expands granting and resources for grant-seekers. HBWC is also planning on
modernizing employee payroll and benefits management through the use of an outsourced provider, such
as Workday, ADP, or Peoplesoft. Analysis of the feasibility and planning for conversion needs consideration
in the overall design for infrastructure and services.
HBWC is also collecting the requirements for a new, web-based portal for use by researchers who have
received grants. This new application will contain patient-sensitive and other nonpublic information (NPI)
that must be adequately protected during processing, storage, and transmission. Access to this resource
will be managed by HBWC staff with the appropriate privileged access.
HBWC is physically located at the facilities and location noted below:
Site Name
Address
Healthy Body Wellness Center (HBWC)
555 Donation Way, Atlanta, GA
PAGE 8
Source: National Institutes of Health (NIH)
C726: Cybersecurity Architecture
2
Systems Assessment Report
System Overview
2.1 System Name
Unique Identifier (UUID)
Information System Name
Information System
Abbreviation
f81d4fae-7dec-11d0-a36500a0c91e6bf8
HBWC
HBWC-OGG
2.2 General System Description and Purpose
The Small Hospital Grant Tracking System (SHGTS) is a grant disbursement system under the cognizance
of the NIH. The purpose of this system is to work within specific block grants to support small and
medium-sized research, development, and traditionally disadvantaged companies in low income areas to
grow and learn to work with the grant process at the NIH and its subcontractor, HBWC.
The Small Hospital Grant Tracking System (SHGTS) is a Microsoft Access 2010 database that resides on
the Windows 2008 R2 application server. The SHGTS application and its data are protected by the
following built-in security mechanisms supported by the hardened Windows 2008 R2 platform. Microsoft
will stop supporting Windows 2008 in January 2020 and Access 2010 in October 2020. This means that
Microsoft will no longer supply patches for the software after that date. MS Access is unsuitable for use by
multiple simultaneous users and will need to be migrated to MS SQL Server to a new infrastructure. New
access via the internet will also be required for sharing data among NIH, HBWC, and the hospitals they
serve. A persistent link to NIH may be required to exchange data among multiple users and potentially
multiple sites that could be needed for processing grants.
To segregate functions in support of SHGTS, three technical support personnel, who are members of the
administrator group, have administrative rights to manage the Windows 2008 R2 server. The SHGTS
database administrator (DBA) does not have administrative privileges to the Windows 2008 R2 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 VPN firewall appliance is in place for users that require remote access to the SHGTS. Knowledge of the
VPN is limited to those users with a mission-essential need. Users access the VPN using Pulse Secure
software using a token or personal identity verification (PIV) badge.
PAGE 9
Source: National Institutes of Health (NIH)
C726: Cybersecurity Architecture
Systems Assessment Report
Currently, payroll is handled on premise using QuickBooks with paper checks. Direct deposit has not been
implemented. Grant money is also provided by paper checks. Checks can be obtained from the office
manager or sent through the mail. HBWC prefers to give employee checks out in person to save on
postage.
Patient and other research raw data are kept in Excel spreadsheets. Patients have a patient number
assigned to them throughout the research period and a conversion sheet between the patients and their
associated numbers are also listed in Excel. Principal investigators at each hospital are allowed to keep
their data proprietary to themselves for one year while they are writing their research report. After the
year is up, the research data belongs to the NIH. The research report is saved in a file cabinet in hard
copy and stored on the server. This makes it difficult to mine the data for information that could be used
for future research.
2.3 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 Windows 2008 R2, but otherwise does not interface with any other system. It is
accessed from local HBWC workstations. HBWC staff may access this database when they connect
remotely through the VPN connection. The QuickBooks database is also housed on the Windows 2008 R2
server and is a standalone database that can be accessed from the client workstations similar to the
SHGTS. The research raw data and research reports are housed on the server in a fileshare.
2.4 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. QuickBooks contains
PII data on employees including social security numbers, salaries, home addresses, and home phone
numbers. Other information such as emergency contacts and next of kin are included in the database. The
research data is only attributable to an individual if the conversion table is viewed along with the raw data.
2.5 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 HBWC 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. Failure of the QuickBooks database could prevent employees from getting paid. A
paper backup is maintained in case the server goes down, but the data may be a day old at the minimum.
Loss of the research data would require notification to NIH that the results of the research they funded is
not available.
The criteria used to measure a system’s sensitivity include confidentiality, integrity, and availability. The
sensitivity areas for the SHGTS and QuickBooks are described in section 3.4.
PAGE 10
Source: National Institutes of Health (NIH)
C726: Cybersecurity Architecture
Systems Assessment Report
2.6 Security Categorization
The HBWC was evaluated against FIPS 199 and NIST SP 800-60 Revision 1, Guide for Mapping Types of
Information and Information Systems to Security Categories. The following FIPS 199 security impact
ratings are outlined in the HBWC Security Categorization.
Security Objective
Low, Moderate, or High
Confidentiality
Moderate
Integrity
High
Availability
Moderate
Overall
Moderate
PAGE 11
Source: National Institutes of Health (NIH)
C726: Cybersecurity Architecture
3
Systems Assessment Report
Assessment Methodology
The security assessment use as logical and prescriptive process for determining risk exposure for the
purpose of facilitating decisions as is aligned with the risk management framework (RMF) described in
NIST 800-37, Revision 1, Guide for Applying the Risk Management Framework to Federal Information
Systems. The RMF describes six steps that apply to the system development life cycle and assessing
security controls constitutes Step 4, as illustrated in the figure below:
Figure 3.1: Risk Management Framework
This methodology used to conduct the security assessment for HBWC’s systems is summarized in the
following steps:
1.
2.
3.
4.
5.
6.
Perform tests from the Security Assessment Plan (SAP) workbook and record the results.
Identify vulnerabilities on the platform.
Identify threats and determine which threats are associated with the cited vulnerabilities.
Analyze risks based on vulnerabilities and associated threats.
Recommend corrective actions.
Document the results.
3.1 Perform Tests
Security tests were performed on HBWC, and tests were concluded in advance of this report. The Security
Assessment Plan (SAP) separately documents the schedule of testing. The results of the tests are recorded
PAGE 12
Source: National Institutes of Health (NIH)
C726: Cybersecurity Architecture
Systems Assessment Report
in the Security Test Procedures workbooks, which are attached in the appendices. The findings of the
security tests serve as inputs to this SAR.
3.2 Identification of Vulnerabilities
Vulnerabilities have been identified for the HBWC through security control testing. The results of the
security control testing are recorded in the security test procedures workbooks and the Security
Assessment Plan (SAP).
Vulnerability is an inherent weakness in an information system that can be exploited by a threat or threat
agent, resulting in an undesirable impact in the protection of the confidentiality, integrity, or availability of
the system (application and associated data). A vulnerability may be due to a design flaw or an error in
configuration that makes your network, or a host on your network, susceptible to malicious attacks from
local or remote users. Vulnerabilities can exist in multiple areas of your system or facilities, such as in
your firewalls, application servers, web servers, operating systems, or fire suppression systems.
Whether or not a vulnerability has the potential to be exploited by a threat depends on a number of
variables including (but not limited to) the following:
•
•
•
the strength of the security controls in place
the ease at which a human actor could purposefully launch an attack
the probability of an environmental event or disruption in a given local area
An environmental disruption is usually unique to a geographic location. Depending on the level of the risk
exposure, the successful exploitation of a vulnerability can vary from disclosure of information about the
host to a complete compromise of the host. Risk exposure to organizational operations can affect the
business mission, functions, or the organizational reputation.
The vulnerabilities that were identified through security control testing (including penetration testing) for
the HBWC are identified in Table 4.1: “Security Assessment Results.”
3.3 Consideration of Threats
A threat is an adversarial force or phenomenon that could impact the availability, integrity, or
confidentiality of an information system and its networks including the facility that houses the hardware
and software. A threat agent is an element that provides the delivery mechanism for a threat. An entity
that initiates the launch of a threat agent is referred to as a threat actor.
A threat actor might purposefully launch a threat agent (e.g., a terrorist igniting a bomb). However, a
threat actor could be a trusted employee that acts as an agent by making an unintentional human error
(e.g., a trusted staff clicks on a phishing email that downloads malware). Threat agents may also be
environmental in nature with no purposeful intent (e.g., a hurricane). Threat agents working alone, or in
concert, exploit vulnerabilities to create incidents. NIH categorizes threats using a threat origination
taxonomy of P, U, or E type threats as described in Table 3.1: “Threat Categories and Origination.”
Table 3.1: Threat Categories and Origination
PAGE 13
Source: National Institutes of Health (NIH)
C726: Cybersecurity Architecture
Threat Origination Category
Systems Assessment Report
Origination
Identifier
Threats launched purposefully
P
Threats created by unintentional human or machine errors
U
Threats caused by environmental agents or disruptions
E
Purposeful threats are launched by threat actors for a variety of reasons and the reasons may never be
fully known. Threat actors could be motivated by curiosity, monetary gain, political gain, social activism,
revenge, or many other driving forces. It is possible that some threats could have more than one threat
origination category.
Some threat types are more likely to occur than others. NIH takes threat types into consideration to help
determine the likelihood that a vulnerability could be exploited. The threat table shown in Table 3.2:
“Potential Threats” is designed to offer typical threats to information systems and these threats have been
considered for HBWC.
3.4 Overall Security Findings
Sensitivity
The criteria used to measure a system’s sensitivity include confidentiality, integrity, and availability. The
sensitivity areas for the SHGTS and QuickBooks are described below:
Confidentiality
SHGTS: 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.
QuickBooks: Moderate
There is Privacy Act data included in the QuickBooks database, and the information should not be shared
outside the payroll office.
Research Data: High
The research data contains medical information on research subjects and needs to be compliant with
HIPAA regulations and protected from employees that do not have a need to know. The research data also
needs to be protected so that only the principle investigator can have access to it for the first year.
Integrity
PAGE 14
Source: National Institutes of Health (NIH)
C726: Cybersecurity Architecture
Systems Assessment Report
SHGTS: Moderate
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.
QuickBooks: High
The integrity of the data for salaries and other information regarding employees needs to be accurate to
make sure that everyone receives the salary that they are supposed to receive based on their job title and
length of service.
Research Data: High
The integrity of the research data must be paramount since the loss of data or any change in the data
may show incorrect results of the research.
Availability
The overall system sensitivity level is determined by the highest value in the SHGTS level column.
Therefore, the sensitivity level for the SHGTS is moderate.
SHGTS: 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.
QuickBooks: Moderate
The information in the QuickBooks database needs to be available on payday, which is every Friday. Hard
copies are made of the information and stored in a filing cabinet, but the information may be dated.
Research Data: Moderate
The research data does not need 24-hour access, but the information should be available when the
principal investigator is preparing his or her final research report.
3.5 Overall Findings across All Connected Systems
All connected systems at HBWC are aging and in need of review, prioritization, compliance, upgrade, and
the development of a maintenance plan. Table 3.2 contains all the information on all systems associated
with, and connected to, the primary grants database system in use.
PAGE 15
Source: National Institutes of Health (NIH)
C726: Cybersecurity Architecture
PAGE 16
Source: National Institutes of Health (NIH)
Systems Assessment Report
C726: Cybersecurity Architecture
Systems Assessment Report
Table 3.2: Potential Threats
Threat
Name
Origination
Identifier
Description
P-Improper
Controls for
Accounting
PICA-01
P-Improper
Controls
Typical Impact to Data or System
Confidentiality
Integrity
Availability
Impact
Level
Controls not in place for unique
identifier for each user of the system
H
H
H
H
High
High
PIC-01
No patch management system in place
M
M
M
M
Moderate
High
P-Not
Enforced
Controls
PNEC-01
Log retention system not evident
M
H
L
M
Moderate
Moderate
P-Not
Enforced
Controls
PNEC-02
Physical access to HBWC not monitored
H
H
H
H
High
High
P-Web
Controls
PWC-01
Web server not protected by application
firewall
H
H
H
H
High
Moderate
P-Web
Controls
PWC-02
Outdated server software
H
H
H
H
High
High
P-Web
Controls
PWC-03
Server Logic—no authentication
mechanism in place for users
H
H
H
H
High
Moderate
P-Data
Classification
P-DC01
No data classification controls
M
L
L
L
Low
Moderate
P-Patch
Management
P-PM01
No patch management controls
H
H
M
H
Moderate
Moderate
PAGE 17
Source: National Institutes of Health (NIH)
Likelihood
Risk
C726: Cybersecurity Architecture
Systems Assessment Report
Threat
Name
Origination
Identifier
Description
PConfiguration
Management
P-CM01
P-System
Admin
Typical Impact to Data or System
Confidentiality
Integrity
Availability
Impact
Level
No configuration management controls
M
M
M
M
Moderate
Low
P-SA01
System Administration accounts tied to
individuals
H
H
M
M
Moderate
Moderate
P-System
Admin
P-SA02
No user activity tracking controls or
process
M
M
M
M
Moderate
Low
P-Disaster
Recovery
P-DR-01
No disaster recovery controls in place
M
M
H
M
Moderate
Low
P-Disaster
Recovery
P-DR-02
No failover site
L
L
H
M
Moderate
Low
P-Disaster
Recovery
P-DR-03
No effective backups of critical systems
L
M
H
M
Moderate
Low
P-Disaster
Recovery
P-DR-04
No disaster communications plan
L
L
L
L
Moderate
Low
P-Sourcing
Controls
P-SC-01
No supply chain purchase or use policy
L
L
L
L
Low
Low
P-Sourcing
Controls
P-SC-02
Outdated partner agreements
L
L
L
L
Low
Moderate
P-Training
P-T-01
No training plans in company
M
M
M
M
Moderate
Low
H
H
H
H
High
High
PNo cryptographic controls in any system
P-Crypt-01
Cryptographic
at HBWC
PAGE 18
Source: National Institutes of Health (NIH)
Likelihood
Risk
C726: Cybersecurity Architecture
Systems Assessment Report
Threat
Name
Origination
Identifier
Description
U-ACL’s
UACL-01
U-ACL’s
Typical Impact to Data or System
Confidentiality
Integrity
Availability
Impact
Level
No ACLs on router or switch
M
M
M
M
Low
Low
UACL-02
No effective firewall rules to filter
inbound traffic
H
H
H
H
High
High
U-ACL’s
UACL-03
ARP cache not protected
M
M
M
M
Low
Low
U-Email
UE-01
Email systems not patched or updated
M
M
M
M
Moderate
Low
U-DNS
UDNS-01
DNS not secure
H
H
M
H
High
Moderate
U-System
Admin
U-SA-01
Improper administration controls
M
M
M
M
Moderate
High
U-System
Admin
U-SA-02
ERP system: no separation of duties, all
data available to everyone
H
H
H
H
High
Moderate
U-Security
U-IPS-01
No information security system in place
M
M
M
M
High
Low
U-Security
U-Sec-01
No DMZ infrastructure
H
H
H
H
High
High
E-Email
EE-01
Email systems not patched or updated
M
M
M
M
Moderate
Low
E-DNS
EDNS-01
DNS not secure
H
H
M
H
High
High
E-DNS
EDNS-02
Outdated system not patched
H
M
L
M
Moderate
Low
E-Datacenter
EDC-01
Data center: no physical security
H
M
M
M
Moderate
Moderate
E-Datacenter
EDC-02
Data center in basement: evidence of
water seepage
L
H
M
M
Moderate
Moderate
E-Datacenter
EDC-03
No tracking of environment controls
L
L
L
L
Low
Low
PAGE 19
Source: National Institutes of Health (NIH)
Likelihood
Risk
C726: Cybersecurity Architecture
Systems Assessment Report
Threat
Name
Origination
Identifier
Description
E-Datacenter
EDC-04
E-Datacenter
EDC-05
Typical Impact to Data or System
Confidentiality
Integrity
Availability
Impact
Level
HVAC is too small for the space.
L
L
L
L
Low
Low
Racks not locked or lockable.
M
M
M
M
Moderate
Low
PAGE 20
Source: National Institutes of Health (NIH)
Likelihood
Risk
C726: Cybersecurity Architecture
Systems Assessment Report
3.6 Perform Risk Analysis
The goal of determining risk exposure is to facilitate decision-making on how to respond to
real and perceived risks. The outcome of performing a risk analysis yields risk exposure
metrics that can be used to make risk-based decisions.
The NIH risk analysis process is based on qualitative risk analysis. In qualitative risk
analysis, the impact of exploiting a threat is measured in relative terms. When a system is
easy to exploit, it has a High likelihood that a threat could exploit the vulnerability.
Likelihood definitions for the exploitation of vulnerabilities are found in the table below:
Table 3.3: Likelihood Definitions
Likelihood
Description
Low
There is little to no chance that a threat could
exploit a vulnerability and cause loss to the
system or its data.
Moderate
There is a moderate chance that a threat could
exploit a vulnerability and cause loss to the
system or its data.
High
There is a high chance that a threat could exploit
a vulnerability and cause loss to the system or its
data.
Impact refers to the magnitude of potential harm that could be caused to the system (or its
data) by successful exploitation. Definitions for the impact resulting from the exploitation of
a vulnerability are described in Table 3.4: “Impact Definitions.”
Since exploitation has not yet occurred, these values are perceived values. If the
exploitation of a vulnerability can cause significant loss to a system (or its data), then the
impact of the exploit is considered High.
Table 3.4: Impact Definitions
Impact
Description
Low
If vulnerabilities are exploited by threats, little to
no loss to the system, networks, or data would
occur.
Moderate
If vulnerabilities are exploited by threats,
moderate loss to the system, networks, and data
would occur.
PAGE 21
Source: National Institutes of Health (NIH)
C726: Cybersecurity Architecture
Systems Assessment Report
Impact
Description
High
If vulnerabilities are exploited by threats,
significant loss to the system, networks, and data
would occur.
The combination of High likelihood and High impact creates the highest risk exposure. The
risk exposure matrix shown in Table 3.5: “Risk Exposure Ratings” presents the same
likelihood and impact severity ratings as those found in NIST SP 800-30 Risk Management
Guide for Information Technology Systems.
Table 3.5: Risk Exposure Ratings
Impact
Likelihood
Low
Moderate
High
High
Low
Moderate
High
Moderate
Low
Moderate
Moderate
Low
Low
Low
Low
3.7 Document Results
Documenting the results of security testing creates a record of the security posture for the
system at a given moment in time. The record can be reviewed for risk-based decision
making and to create plans of action to mitigate risks.
The Federal Information Security Management Act (FISMA) requires that a Plan of Action
and Milestones (POA&M) be developed and utilized as the primary mechanism for tracking
all system security weaknesses and issues. Security Control Assessors will leverage the SAR
to create a Plan of Action and Milestones (POA&M) for NED. The POA&M is a mitigation plan
designed to address specific residual security weaknesses and includes information on
costing, resources, and target dates.
PAGE 22
Source: National Institutes of Health (NIH)
C726: Cybersecurity Architecture
4
Systems Assessment Report
Security Assessment Results
This section describes all security weaknesses found during testing. The following elements
for each security weakness are reported:
•
•
•
•
•
•
•
•
•
•
Finding Number
Status
Source
Risk
Business Impact Statement
Recommended Corrective Action
Link to Control(s)/Test Case(s)
Likelihood
Impact
Risk Level
The reader of the SAR should anticipate that the security weakness elements are described
as indicated below.
•
Finding Number: The unique application-generated security finding number.
•
Status: The computed lifecycle status associated with the finding. If the finding is
linked to a weakness for remediation management, the finding status is computed
based on the completed status of the weakness. Finding status described below:
o
o
o
o
Unlinked: The finding is not linked to a weakness.
Active: The finding has been linked to a weakness that has an open status.
Completed: The finding has been linked to a weakness where remediation has
been completed successfully (i.e., the weakness is in completed status).
Rejected: The finding has been rejected either as a false positive or risk
accepted (i.e., risk-based decision). No remediation is required for the security
finding.
•
Source: The finding type (e.g., vulnerability assessment, security audit) and the
failed security control in which the finding was created.
•
Risk: The finding description. This is the description of the finding as defined from the
vulnerability assessment, security audit report, or from the results of an internal
security review.
•
Business Impact Statement: Impact of the finding to the organization if exploited.
•
Recommended Corrective Action: The recommended control(s) needed to
remediate the finding.
•
Link to Control(s)/Test Case(s): The control and/or test case associated with the
finding.
•
Likelihood: The likelihood that the finding will be exploited (High, Moderate, or Low).
•
Impact: The impact to the organization if the finding is exploited (High, Moderate, or
Low).
PAGE 23
Source: National Institutes of Health (NIH)
C726: Cybersecurity Architecture
•
Systems Assessment Report
Risk Level: The computed risk level associated with the finding based on the selected
likelihood and impact. Please refer to Table 3.5: “Risk Exposure Ratings” for details.
PAGE 24
Source: National Institutes of Health (NIH)
C726: Cybersecurity Architecture
Systems Assessment Report
Table 4.1: Security Assessment Results
ID
Weaknesses
PICA-01
Improper use of access for users
No policy for patch management, no effective
patch management system in place due to lack
of policy
No log retention system in place, logs not
maintained or reviewed
Physical access to HWCBWC not monitored, no
effective physical security in place, or a physical
security policy in place
Web application not secured, no effective
security controls in place
Outdated server software – ties to PIC-01, no
effective controls in place for server updates for
base, server, or server code/logic
No effective user login for accessing grant
information at the web server
No data classification controls allowing access to
any data within the organization
No patch management controls—see PIC-01 and
PWC-02
No configuration management controls
Named individuals with server administration
rights
Users not tracked for access or data rights
No disaster recovery controls in place; no
provision for disaster recovery
No failover site: cold, warm, or hot
No effective backups of systems or data. Backup
system in place, but never tested. No timetable
for backups or a backup testing plan.
PIC-01
PNEC-01
PNEC-02
PWC-01
PWC-02
PWC-03
P-DC01
P-PM01
P-CM01
P-SA01
P-SA02
P-DR-01
P-DR-02
P-DR-03
Remediation
Actions
PAGE 25
Source: National Institutes of Health (NIH)
POC
Scheduled
Completion
Date
Status
Risk
Level
C726: Cybersecurity Architecture
P-DR-04
P-SC-01
P-SC-02
P-T-01
P-Crypt-01
UACL-01
UACL-02
UACL-03
UE-01
UDNS-01
U-SA-01
U-SA-02
U-IPS-01
U-Sec-01
EE-01
EDNS-01
EDNS-02
EDC-01
EDC-02
EDC-03
Systems Assessment Report
No communications plan for disasters
No supply chain or purchase/use policy; no
central purchasing pool
Outdated partner agreements: partner
agreements with companies that have gone out
of business or changed business roles
No training plan. No training evident for
security, onboarding, administration, duties,
roles, or responsibilities.
No cryptographic controls or systems in place
No ACLs on routers or switches
Firewall rules do not effectively filter inbound
traffic.
ARP cache not protected, vulnerable to ARP
poisoning
Email system accounts of people who have left
the company, but email is not locked or
disabled.
SDNS protocols are not in place.
Improper Administration controls: local admin
rights in place
ERP: no separation of duties, all employees
have access to all data in the system
No ISMS system in place
No DMZ structure in place, exposing the internal
network
Email system not patched or updated
DNS not secure
DNS system outdated and not maintained
No physical security at data center; no control
for data center access
Data center: possible water seepage
Environmental controls are not tracked or
monitored.
PAGE 26
Source: National Institutes of Health (NIH)
C726: Cybersecurity Architecture
EDC-04
EDC-05
Systems Assessment Report
HVAC is too small for a data center space.
Server racks are not locked or lockable.
PAGE 27
Source: National Institutes of Health (NIH)
C726: Cybersecurity Architecture
5
Systems Assessment Report
Nonconforming Controls
In certain instances, the HBWC system may not have the technical capability to implement
a security control, or the system owner may have decided not to implement a control based
on the cost or feasibility of implementing the control relative to the risk exposure. The
status of such controls is designated "Not Implemented" or "Partially Implemented" or
"Alternative Implementation" in the System Security Plan. A summary of these controls are
listed in Table 5.1: “Nonconforming Controls” along with a justification statement that offers
an explanation for the nonconformance with NIH requirements. Control categories are
designated as either Management, Technical, or Operational as defined in NIST SP 800-53,
Revision 1.
Table 5.1: Nonconforming Controls
Control ID
Control Category
Description
Justification
Statement
SC-17
Technical
X.509 Certificate Subject These certificates are
CN Does Not Match the used for management
Entity Name.
access to Virtual
Manager. This traffic is
not allowed through the
perimeter firewalls and
is confined to only
internal network traffic
that has no public
access.
The CSP infrastructure
will use all government
trusted CAs for public
access to the cloud
storage services.
SI-2
Technical
IIS Vulnerabilities
CSP is waiting on the
vendor to release a
Multiple vulnerabilities in patch for the effected
affected versions of IIS software as the
can allow remote code
vulnerable service is
execution
bundled inside an
executable.
PAGE 28
Source: National Institutes of Health (NIH)
C726: Cybersecurity Architecture
6
Systems Assessment Report
Authorization Recommendation
The assessment indicates that the identified risks are deemed either a) to be acceptable, b)
higher than desired, or c) to be unacceptable. The authorizing official should consider the
risks presented herein in determining the authorization decision.
PAGE 29
Source: National Institutes of Health (NIH)
Purchase answer to see full
attachment