C726 WGU Healthy Body Wellness Center Cybersecurity Architecture Case Paper

User Generated

fbybzba11905

Computer Science

Description

INTRODUCTION

As technology companies continue to move business services to the cloud, many companies are finding a need to upgrade the technological infrastructure. When implementing new architecture, IT companies will consult with IT security firms to identify current vulnerabilities in the system and plan how to avoid those vulnerabilities in the new information system.

For this task, you will use the attached “Healthy Body Wellness Center Case Study,” “Healthy Body Wellness Center Security Assessment Report,” and the “Business Requirements Document Template” to analyze, assess, and prioritize existing threats to the current architecture and design technical specifications to address identified threats.

SCENARIO

You are the newly hired LAN administration and security manager at Healthy Body Wellness Center (HBWC). The HBWC includes the Office of Grants Giveaway (OGG), a growing department responsible for distributing hospital research grants.

The HBWC currently relies on a local area network (LAN), but plans to expand their services and hire more employees this year. It is evident the current cybersecurity architecture is limited and unable to meet current needs. In addition, HBWC’s cybersecurity architecture will need to transition to a wide area network (WAN).

Using the attached “Healthy Body Wellness Center Case Study” and “Healthy Body Wellness Center Security Assessment Report,” conduct a security analysis of HBWC’s current technologies and applications and identify threats to the company’s existing architecture. You will use the findings from your analysis to complete the attached “Business Requirements Document Template.”

Requirements:

Analyze HBWC’s existing architecture using the attached “Healthy Body Wellness Center Case Study” and “Healthy Body Wellness Center Security Assessment Report.” Consider common security needs and functionalities necessary to meet the needs of the target network as part of your analysis. Record all responses in the appropriate section of the attached “Business Requirements Document Template.”

A.    Introduction - Summarize each aspect of the project summary, project scope, and system perspective based on the attached “Healthy Body Wellness Center Case Study” and “Healthy Body Wellness Company Security Assessment Report.” Use the "Introduction" of the attached “Business Requirements Document Template” to record your responses.

B.    Business Process Overview - Describe the current business processes at HBWC and the proposed processes, 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 the "Business Process Overview" section of the attached “Business Requirements Document Template” to record your responses for each aspect.

C.    Business Requirements - Record the business requirements for the project, categorized by both priority and area of functionality addressing the needs from the “Healthy Body Wellness Center Case Study” and “Healthy Body Wellness Center Security Assessment Report.” Provide functional and nonfunctional requirements that can be followed throughout the project for the recorded business requirements.

Unformatted Attachment Preview

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
Explanation & Answer:
19 pages
User generated content is uploaded by users for the purposes of learning and should be used following Studypool's honor code & terms of service.

Explanation & Answer

Attached.

3.0

Introduction

The report evaluates the security of HBWC's (Healthy Body Wellness Center) information systems
and highlights any risks or vulnerabilities that may exist. It also includes recommendations for
improving security, such as implementing security controls, conducting regular security
assessments, and complying with regulatory requirements related to federal government grants.
3.1

Project Summary

The project involves conducting a security audit for the Healthy Body Wellness Center (HBWC)
to identify areas of concern and recommend corrective actions to update and modernize their
network, grant process, and internal controls to comply with federal government grant process
regulations. The audit identified several areas of concern, including lack of controls and policy,
outdated systems design, lack of cryptographic controls, and environmental concerns. The report
recommends migrating from Microsoft Access to SQL Server and implementing internet access
for data sharing among NIH, HBWC, and hospitals. The Security Assessment Report (SAR)
outlines the security posture of the Health and Body Wellness Center's (HBWC) information
systems, identifies vulnerabilities, threats, and risk exposure, and provides
3.1.1 Objectives
The specific objectives of this study are to:
a) To improve efficiency and effectiveness of organization grant tracking and payroll system
b) Help patients take responsibility for their overall wellbeing
c) Educate local community members about the importance for the practice of wellness
d) To ensure integrity and confidentiality of data
3.1.2 Background
According to World Health organization (1948) WHO, health a state of complete physical, mental,
and social well-being, and not merely the absence of disease or infirmity. The proposed project for
the HBWC (Healthy Body Wellness Center) was initiated to address several business issues and
problems that were identified within the organization. One of the primary goals of the project was
to improve the efficiency and effectiveness of the organization's grant tracking and payroll
systems, as well as to ensure the integrity and confidentiality of sensitive data. The project was

proposed after it was determined that the current systems in place were outdated and inefficient,
leading to errors and delays in processing grants and payroll also not leaving out the fact that the
payroll is currently handled on HBWC’s premise using QuickBooks with paper checks. Typically,
the organization was also concerned about the security of sensitive data and other nonpublic
information (NPI), including private health information and personally identifiable information.
The expected benefits of implementing the project were numerous. By improving the grant
tracking and payroll systems, the organization would be able to process grants and pay employees
more efficiently and accurately, reducing errors and delays. This would also free up staff time to
focus on other important tasks.
Healthy Body Wellness Center (HBWC) project would ensure the integrity and confidentiality of
sensitive data, protecting the organization from potential legal and financial consequences. By
implementing new security measures and protocols, the organization would be able to safeguard
private health information and personally identifiable information, ensuring compliance with
HIPAA regulations and other privacy laws.
3.1.2.1 Business Drivers
The following are the business drivers that make development of this product important:
a) Accuracy of data for salaries and other employee information to ensure appropriate
compensation.
b) Availability of database for easier preparation of reports and inconvenience if the database
is unavailable.
c) Need for research data to be available when preparing final research reports.
d) Availability of QuickBooks database on paydays.
e) Access to all reports and ability to update key fields for Executive users.
f) Access to most forms and ability to update key fields for Basic users.
g) Protection of private health information, healthcare information, and proprietary data in the
SHGTS database.
h) Need for secure employee remote access, secure ACH data transmissions, and secure NPI
and patient data.
i) Migration from older Microsoft products to newer suites of tools.
j) Microsoft's discontinuation of support for Windows 2008 and Access 2010.

3.2 Project Scope
The project scope includes the development of a new network infrastructure that meets the security
requirements for remote access, data transmission, and protection of sensitive information.

3.2.1 In-Scope functionality
The need to 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, and
third-party extranet connections based on cloud-based Software-as-a-Service (SaaS) providers
offer services to the Office of Grants Giveaway (OGG).
3.2.2 Out-of-scope functionality
Based on the material provide there is no out of scope functionality or features requested
3.3 System Perspective
Several factors that could prevent successful implementation or accelerate the project, particularly
factors related to legal and regulatory compliance, existing technical or operational limitations in
the environment, and budget/resource constraints.
These factors include:
a. Legal and regulatory compliance: The project must comply with various legal and
regulatory requirements, such as the Privacy Act, HIPAA regulations, and FIPS 199 and
NIST SP 800-60, Revision 1. Failure to comply with these requirements could result in
legal and financial penalties, as well as damage to the organization's reputation.
b. Existing technical or operational limitations: The document notes that all connected
systems at HBWC are aging and in need of review, prioritization, compliance, upgrade,
and the development of a maintenance plan. This suggests that the existing technical and
operational limitations could pose a challenge to the successful implementation of the
project. Additionally, the document highlights the criticality of the information systems and
the potential impact of their failure on the effectiveness or efficiency of day-to-day
operations.

c. Budget/resource constraints: The document mentions that 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. This suggests that
budget/resource constraints could be a factor that could prevent successful implementation
or accelerate the project. Additionally, the document notes that the development of a new
network infrastructure that meets the security requirements for remote access, data
transmission, and protection of sensitive information would require significant resources.
3.3.1 Assumptions
a) The availability of a key resource, such as a team member or equipment, during the
project's timeline
b) The accuracy and completeness of the project's requirements or specifications
c) The level of support and cooperation from stakeholders or sponsors
d) The impact of external factors, such as market trends, regulatory changes, or economic
conditions, on the project's success
3.3.2 Constraints
a) Regulatory Requirements
b) Technical Limitations e.g., outdated systems
c) Resource Availability
3.3.3 Risks
The security audit report conducted by Endothon Security Consulting identifies several risks that
HBWC faces related to their current network and grant process. These risks include:
a. Outdated systems design: The report notes that HBWC's current system design is outdated
and requires immediate attention to rectify. This poses a risk to the organization as outdated
systems may be more vulnerable to security threats and may not meet current regulatory
requirements.
b. Lack of cryptographic controls: The report highlights that HBWC's web server and webbased services lack cryptographic controls, which poses a risk to the confidentiality,

integrity, and av...


Anonymous
This is great! Exactly what I wanted.

Studypool
4.7
Trustpilot
4.5
Sitejabber
4.4

Similar Content

Related Tags