The following information should be helpful when filling out the security assessment questionnaire.
1. Project Summary Section
Overall objective of the project along with information along with the contact information of subject matter expert.
2. Regulatory Compliance Section
Information as whether the application / software handle any regulatory compliance data as defined by Federal regulations.
Please note: If the answer is yes to any of the following regulatory questions, please attach the regulatory certificates / artifacts. Ex., SOC2/ TYPE 2 Reports, Attestation of Compliance / Report of Compliance for PCI-DSS data etc.,
- HIPAA - The Health Insurance Portability and Accountability Act of 1996 with the purpose of ensuring the privacy of a patient's medical records. Federal Health Insurance Portability and Accountability Act (HIPAA) regulations seek to protect the privacy and security of Protected Health Information (PHI). HIPAA establishes requirements for covered entities, such as health care providers, regarding the release of PHI to nonemployee business associates. PHI is individually identifiable health information that relates to 1) the past, present, or future physical or mental health, or condition of an individual; 2) the provision of health care to an individual; or 3) payment for the provision of health care to an individual.
- PCI-DSS - Payment and Credit Card Industry Data Security Standards is guidance developed by the major credit card companies to help organizations that process card payments prevent credit card fraud, hacking and various other security issues. A company processing card payments must be PCI compliant or risk losing the ability to process credit card payments. The PCI-DSS (Payment Card Industry Data Security Standard) requires the protection of payment/credit card data and related account information. Examples include information provided on an application for a credit card, payment history, account balance information, cardholder data, and sensitive authentication data.
- Personally Identifiable Information (PII) - Any piece of information contained in Protected Data which can potentially be used to uniquely identify, contact, or locate a single person. Examples of PII include Protected Health Information (PHI), Credit Card Numbers, Social Security Numbers (SSNs), etc.
- FERPA - The Family Educational Right and Privacy Act of 1974 with the purpose of protecting the privacy of student education records. Education records are defined as records, files, documents and other materials that contain any information directly related to a student, and are maintained by an education agency or institution, or by a person acting on behalf of an agency or institution. These include, but are not limited to: transcripts, grades, exam papers, test scores, evaluations, financial aid records and loan collection records. The law requires that student education records be shared only between the student and those who have a legitimate education-related interest.
- FDA Part 11 - Food and Drug administration (FDA) guidelines on electronic records and electronic signatures.
- FISMA - The Federal Information Security Management act of 2002 recognizes the importance of information security to the economic and national security interests of the United States and as a result sets forth information security requirements that federal agencies and any other parties collaborating with such agencies must follow in an effort to effectively safeguard IT systems and the data they contain.
- GLBA - The Gramm-Leach-Bliley Act, also known as the Financial Services Modernization Act of 1999, contains privacy provisions requiring the protection of a consumer's financial information. Pursuant to Federal laws, the University of Miami has a duty to protect all nonpublic, personally identifiable financial information. Examples of nonpublic personal information include Social Security number, financial account numbers, credit card numbers, date of birth, name, address, phone number when collected with financial data, details of financial transactions.
3. Auditing and Reporting Requirements
Whether the application / software supports logging mechanisms for auditing and reporting and a SIEM Solution can be integrated with the logging mechanism.
4. Solution Infrastructure
Provide a solution Infrastructure flow diagram, which includes the following information:
- Source and Destination IPs of all hosts involved in the solution
- Any web page URLs
- Ports involved with the solution
- Any encryption being used
- Any interfaces involved
- Any crash report/metadata
The goal of the Information System/Data Flow Diagram is to capture the main components of an Information System, how data moves within the system, user-interaction points, and the Authorization Boundary. Think of this diagram as conceptual rather than technical – multiple systems can be abstracted together, and there’s no need to detail every network connection. The Authorization Boundary describes the limits of the Information System – which pieces are currently being assessed. Information Systems often depend on other Information Systems, but those other Information Systems will be assessed independently, and their risk factored into the current Information System.
Sample of a Good System Flow Diagram:
The following tools help in creating system flow diagrams:
5. Data Points
List all the data points that are being stored / handled by the system. Data dictionaries should be attached for large systems and enterprise-wide implementations.
6. Data Encryption
Encryption mechanisms / algorithms used for encrypting the data while in transit, at Rest or when stored in the persistent storage. Ex. Database or File Systems.
7. Support Requirements
Does the system require special tools as part of support operations. How the support users are provisioned to login in case of any emergencies. Does the support users have individual access logins or they leverage a support group login. Vulnerability Scan: On-premise systems are subjected to periodical vulnerability scans. Timings that are suitable for performing a vulnerability scan.
8. Support Requirements
Can the system/application leverage Single-Sign On mechanisms either UMIT SAML based authentication for web applications or Active Directory Federation Services (ADFS) for on premise solutions.
9. Cloud Solutions
Information applicable for cloud based solutions such as, location of data center, handling of data in a multi-tenancy environment, compliance of cloud provider and relevant attestation reports, agreement with UM and vendor for data retention, archival, and purging policies etc.