Automaticlink Establishment

Save, Streamline and Spark collaboration.

This information is not meant to be an all-inclusive dialogue of Router configurations, the important thing to remember is that in a medical or hospital environment, the protection of patient information is the key function of Information Systems security. There is no know information at this time, about securing a Router that is specific to the healthcare industry. The information being secured for the most part is “protected health information”. There is no special Router configuration is required by HIPPA at this point in time. The actual assessment of Router security can be done by running penetration software such as “Nmap”, “Nessus”, “Enum”, “Netcat” or other such programs. It is advisable to get written permission from medical center or hospital administration before attempting to “hack” into any systems. President George W. Bush’s “Critical Infrastructure Protection Board” published a paper in September 2002 entitled “A National Strategy to Secure Cyberspace” which is found at: http://www.whitehouse.gov/pcipb/cyberstrategy-draft.html 2 In it, one of the Agenda items listed under Level 4, “National Priorities” stated: “R4-38 The appropriate Federal agencies should consider reviews of the IT security issues related to the implementation of … the Health Insurance Portability and Accountability Act.” So besides just HHS being involved implementing HIPPA, and the Office of Civil Rights being involved in enforcing HIPPA regulations and investigating complaints and violations, other “appropriate” Federal agencies will be involved in publishing guidelines on how HIPPA Security should be implemented. HHS’s best indication of what will be required in the final HIPPA Security regulations comes from a reference in an addendum to their “Notice of Proposed Rule Making for the Security and Electronic Signature Standards” (NPRM) published in the Federal Register in 1998. Under the section HIPPA SECURITY MATRIX- mapping, http://aspe.hhs.gov/admnsimp/nprm/sec16.htm, “Certification Requirements” 3, the mapped “Standard” for such requirements refers to footnote “47” - NIST “Generally Accepted Principles and Practices for Secure Information Technology Systems” at http://csrc.nist.gov/publications/nistpubs/800-14/800- 14.pdf 4 This NIST document is THE document which provides us the minimal acceptable standards for information security, and since the NPRM specifically refers to this document, the NIST Principles and Practices are the best indication of what the healthcare industry should be using health information until the final HIPPA regulations are published. HIPPA is a destination not a solution. SEC.01 Certification 45 CFR §142.308(a)(1) HIPPA Requirement "…The technical evaluation performed as part of, and in support of, the accreditation process that establishes the extent to which a particular computer system or network design and implementation meet a prespecified set of security requirements. This evaluation may be performed internally or by an external accrediting agency." AMC Explanation of HIPPA Regulation Certification is the process of determining whether technical security controls are implemented and comply with specified criteria. Each covered entity is required to establish a certification process that demonstrates and One type of Firewall not mentioned are software based. Well-known software-based Firewall applications such as “ZoneAlarm” or “Black Ice Defender” should not be used exclusively on individual servers or workstations in a medical center or hospital environment. Such software firewall on local servers should not take the place of network-based firewalls documents that its computer systems and networks meet these criteria.tected Health Information” until the final HIPPA regulations are published. The security assessment of a VPN can be done by running password cracking software such as “John the Ripper” or other such programs. Be sure to get written permission first. As always, enable audit logs and check for signs of attempted or successful intrusion. There is nothing about securing a VPN that is specific to the healthcare industry. InfoSec “best practices” are recommended, but no special VPN configuration is required by HIPPA. January 2003 issue of “Advance for Health Information Executives” author Robert N. Mitchell writes, quoting Jonathan Taylor, enterprise security engineer, at Sutter Health, Sacramento California 8: “A good security practice is to change the default configurations, change the Web folder location, change the scripts folder location and modify system permissions so that they are not set with default configurations.” A knowledgeable black-hat would know to probe a Windows web server for default user names and could then attempt unauthorized access. Therefore, additionally security measures should include: · Remove all default users, home directories and configuration, sample files, administration web sites, anonymous logins, null sessions · Disable all unused Services in Computer Management and install the O/S with minimum services · Configure “Live Update”, install all service packs, hot fixes, and patches · Install and automatically update anti-virus software · Use different hard drives or partitions for the O/S, HTML and FTP folders · Remove or rename guest account and rename administrator account · Enforce strong passwords complexity and force the password change often · Disable NetBIOS, remove OS/2 and Posix references from the Registry · Apply a high security web template and configure it As an assessment tool, consider testing the initial server configuration by applying a “scoring tool” to benchmark the current or “before” level of security, then apply the security template for an “after” score. Windows Vulnerabilities”, found at http://ww.sans.org 9 A free SANS/FBI Top 20 vulnerabilities scan is available at http://www.qualys.com 10 Because of its age, Windows NT Server should not be considered as a web server of choice. It is recommended that W2K Server or higher (.NET Server) be used, and that any WinNT systems be upgraded or replaced. As mentioned before, log various events and regularly check audit logs for signs of hacking or intrusion. Windows-based Mail Servers Microsoft Exchange Server are based on the same O/S as their web servers, the recommended security configurations are similar. In Healthcare Information Security, the March 2002 issue, Jahen Moreh lists the 4 most popular methods for securing Email 11: · Public Key encryption – such as PGP, which is not widely used, but is one of the most secure methods. Encryption should be easy to use or automatic · Password-based security– both sender & recipient use same password to encrypt and decrypt, but passwords must be complex and secure · Web-based security – there is no content in any Email message, only a link to a secure web-site where the recipient logs in to get messages · Key-server security – recipient gets an encrypted message, then retrieves a key from a server by password and decrypts the message ---------------------------------------- Federal Financial Institutions Examination Council's (FFIEC) Board of Governors of the Federal Reserve System (FRB) State member banks Bank holding companies Nonbank subsidiaries of bank holding companies Edge and agreement corporations Branches and agencies of foreign banking organizations operating in the United States and their parent banks Officers, directors, employees, and certain other categories of individuals associated with the above banks, companies, and organizations (referred to as "institution-affiliated parties") Federal Deposit Insurance Corporation (FDIC) State nonmember banks Insured branches of foreign banks National Credit Union Administration (NCUA) Credit unions Office of the Comptroller of the Currency (OCC) National banks Federally chartered branches Agencies of foreign banks Office of Thrift Supervision (OTS) Thrift associations >>>>> Before Process Foundation The process we developed very closely follows the Information Security Risk Assessment recommendations found in the FFIEC Information Technology Examination Handbook:2 · Obtain listings of information system assets (e.g., data, software, and hardware). Inventories on a device-by-device basis can be helpful in risk assessment as well as risk mitigation. Inventories should consider whether data resides in house or at a TSP. · Determine threats to those assets, resulting from people with malicious intent, employees and others who accidentally cause damage, and environmental problems that are outside the control of the organization (e.g., natural disasters, failures of interdependent infrastructures such as power, telecommunications, etc.). · Identify organizational vulnerabilities (e.g., weak senior management support, ineffective training, inadequate expertise or resource allocation, and inadequate policies, standards, or procedures). · Identify technical vulnerabilities (e.g., vulnerabilities in hardware and software, configurations of hosts, networks, workstations, and remote access). · Document current controls and security processes, including both information technology and physical security. · Identify security requirements and considerations (e.g., GLBA). · Maintain the risk assessment process requires institutions to review and update their risk assessment at least once a year, or more frequently in response to material changes in any of the six actions above. Process Steps and Implementation Considerations The process described below could be done manually for a small, simple network. However, the scope of the process makes it well worth the effort to automate. One way to automate is to store the data and perform the calculations in a relational database. A possible relational database schema is shown in Appendix B. Process Overview 1. Determine data classification categories 2. Inventory Systems 3. Classify Data 4. Determine Initial Risk of each system Vendor Services: Manage the vendor following a vendor management policy appropriate to their initial risk tier. Technologies: 5. Group Technologies 6. List vulnerabilities and threats for each system 7. List controls for each vulnerability or threat 8. Classify controls 9. Determine adequacy of controls 10. Determine Residual Risk 11. Generate reports 12. Report results to corporate leadership 13. Repeat annually During Step 1. Determine Data Classification Categories The type of data that a system stores, processes, or transmits determines how critical that system is. Developing classification factors for data helps to determine which © SANS Institute 2003, Author retains full rights Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2003, As part of the Information Security Reading Room. Author retains full rights. 5 systems Data Classification Factors 1 Contains non-public personal information about our customers as defined in the GLBA privacy regulations. 2 Contains bank, employee, or customer information that should be restricted to a limited number of our employees. 3 Contains bank, employee, or customer information that should be restricted from non- employees. 4 Contains information that is relied upon for risk management or decision making purposes 5 Contains information that could be altered or tampered with for fraudulent purposes 6 Contains information that could be altered or tampered with for financial gain 7 Contains information that is critical to the our internal operations 8 Contains information that is critical to our ability to service our customers. Step 2. Inventory Systems The next step is to generate a list of all systems in use that store, process, or transmit data. The systems list should include hardware, software, and vendor provided services. At this stage indicate whether the system is a technology or a vendor service. In this context, a technology is a system for which you have control over the security, integrity, or availability. This normally involves systems managed locally such as server hardware, backup tapes, local databases, and desktop applications. A vendor service is any system for which the vendor has access to the data, or for which you rely on the vendor for integrity or availability. Examples of vendor services include cellular phones, a news or stock feed, or a third party data mining service. It is important to note that some systems will be both a technology and a vendor service. For example, a Frame Relay line between two corporate sites would be considered a vendor service because we rely on the vendor to keep the line secure and available. However, we have some control over the security in that we can encrypt data before sending it through the line. 3. Classify Inventoried Systems At this time, indicate which classification categories each technology or vendor service. It may be possible to delegate this responsibility to the appropriate system administrators or vendor relationship managers. One way to make this step clearer for system administrators and relationship managers is to develop questions for people to ask to determine if a specific category is true for a system. Some example questions: · If an attacker gained control of this system, would he have access to customer information? If yes, then the system falls into category 1. · If this system were unavailable, would we still be able to complete our internal operations? If no, then the system falls into category 7. · If this system were unavailable, would we still be able to service our customers? If no, then the system falls into category 8. 1 “Interagency Guidelines Establishing Standards for Safeguarding Customer Information.” February 1, 2001. (March 6, 2003) 2 “Information Security Booklet”. FFIEC Information Technology Examination Handbook. February 2003 (March 6, 2003) 4. Determine Initial Risk of inventoried systems First create definitions for “Initial Risk”. These definitions should be based on which data classification categories the system falls into. Being a financial services company, reputation and compliance are among our highest priorities. We determined the attributes of our initial risk categories based on this: Highest Initial Risk Failure or compromise of this technology or vendor · Can cause disclosure of private customer information · Can cause us not to stay in compliance · Can cause significant impact on the reputation of the company Highest Initial Risk Failure or compromise of this technology or vendor · Can prevent us from doing business for an unacceptable period of time. · Can cause significant impact on the reputation of the company · Can cause significant financial loss for the company Medium Initial Risk Failure or compromise of this technology or vendor · Can cause degraded service to our customers · Can delay internal operations for a short period of time · Can minimally impact reputation · Can cause a small to medium financial loss for the company Low Initial Risk Failure or compromise of this technology or vendor will not cause the conditions indicated above. Correlating the data classification to the attributes above, we find that our Initial Risk definitions based on the data categories are as follows: Tier 1: Highest Risk Any system containing Category 1 data (GLBA protected customer information) Tier 2: High Risk Any system containing Category 7 data (critical to operations) or Category 8 data (critical to customer service). Tier 3: Medium Risk Any system containing data in Categories 2 through 6 Tier 4: Low Risk Any system that does not fulfill any of the classification categories Each institution will need to define its own initial risk tiers. · A research laboratory may rank restricting research data from competitors above customer service or customer privacy. · A news website, such as cnn.com, may rank customer service (uptime) or accuracy most highly Apply the definitions to the classified systems to develop the table below. 5. Group Technologies To reduce the effort of the risk assessment process by eliminating redundancies, group technologies that are similar in such a way that they will have the same vulnerabilities. For example, all databases on the private network will have basically the same vulnerabilities. Instead of specifying all those vulnerabilities for each database, we will group the database and then relate the vulnerabilities to the group. There is a trade-off here. A more generic group, such as “all databases on the private network” will include more systems, and result in less work when we list and relate vulnerabilities. More specific groups, such as “Oracle databases on the private network” and “MS SQL databases on the private network” will provide more accuracy, but will also result in more work. Grouping technologies provides large gains in terms of reducing the effort, but it also adds error to the system. As time and needs allow, you can “fine tune” the technology groups to make them more specific and increase the accuracy to an acceptable level. Sample Technology Groups ID System Group 1 Internet T-1 Internet Connections 2 Network Switches Network Infrastructure 9 Corporate Mail Server Mail Servers 10 Accounting File Server NT File Servers 11 Backup Server Backup Servers 12 Help Desk Application Server Application Servers 13 HR File Server NT File Servers 14 Maintenance File Server NT File Servers 16 Supplier Extranet - Frame Relay Extranet 18 Palm Pilots Handhelds Step 6. Identify Vulnerabilities and Threats List each vulnerability or threat, and indicate which technologies could be compromised. Sample vulnerability and threat assignment for the technology “NT File Servers” Vulnerability Affects NT File Servers? Capture and decryption of secured data transmissions DNS/Website spoofing Dormant user accounts X Downloading infected software from Internet Email viruses Hardware failure of desktops Hardware failure of servers X Incomplete/Non existent backups X Infected Software or Disks on Webservers Infected software or disks on Clients Infected software or disks on Servers X Internet Denial of Service Attack IP Spoofing Listening Services/Open ports on internal systems X Listening Services/Open ports on webservers Malicious employee X OS/Software installation and patches corrupting data or breaking functionality X Password Cracking X Password sniffing - Internet Password sniffing - Private network Physical access to un-secured logged in terminal X Power failure X Social Engineering Unpatched Operating Systems and software -desktops Unpatched Operating Systems and software -servers X Unprotected shares and trust relationships Vulnerable CGI Programs Weak passwords/Password Guessing X Website defacement of DMZ servers Website defacement of Internet Servers Wireless access compromise Worm or other self-propagating virus X Vulnerabilities of “hardware failure of desktops” and “hardware failure of servers” are shown separately above. Originally this was listed as just “hardware failure”, however when I went to relate controls, I found that we had controls in place for servers, such as redundant disks and power supplies, that we did not have for desktops. This is another area where error is added to the system, the best way to limit it is to make the vulnerabilities more specific. As you are entering vulnerabilities and controls, you can go back and fine tune (such as I did by splitting hardware failure into two separate vulnerabilities) until you are satisfied with the level of accuracy. 7. Identify Controls List all of the controls that are in place and indicate which vulnerabilities or threats they impact. 128 bit encryption on Internet communications Account and user rights management Authentication event logging X Authentication required on WAP Dial-up and VPN Awareness and appropriate configuration Backup generator Backup monitoring systems Backup policies and procedures Backup systems Border router access control lists Change default passwords Close port 80 into service network DNS Monitoring Desktop Antivirus Desktop Antivirus Consolidated Management Desktop software installation policy Disable or re-name default user accounts Disaster Recovery Contract Email Antivirus Email attachment filtering by file type Encryption required on WAP Enhanced DNS Monitoring Firewall HP Openview Monitoring Hardware redundancy Incident Response Process X Internet use policy Intrusion Detection System Locked/logged out servers Logfile Monitoring Modem pool to limit use of desktop modems Multiple locations NAT with non-routable addresses No Unattended/automatic patch installations No use of Remote Services utilities Off-site storage Periodic forced password changes X Physical access controls Policies against end users setting up WAPs Policies to install only necessary services Redundant Internet connection Redundant systems Risk/Testing/Migration/Recovery plan for system installs and upgrades Router ACLs SMTP Gateway in DMZ SSL with signed certificates for secure web services Security Patch Application Security considered when developing programs Server Antivirus Service Pack/Security Patch Tracking system Website content monitoring Strong password enforcement X Switched Network Terminated employee process Test lab Tier 1 ISP (UUNet) Integrity Checking software Trust relationships enforced by encrypted passwords UPS User account monitoring User training X WAN Provider agreements Web server NTFS permissions Web server application not running as admin 8. Indicate whether controls are preventative, detective, corrective, or directive To adequately control a threat or vulnerability, you need to have tools or processes in place to prevent a compromise from occurring, tools or processes in place to detect and alert you if a compromise has occurred, and tools or processes in place to allow you to recover from a compromise quickly and prevent future occurrences. Here are the definitions we use to determine which of these categories a control falls into:3 Preventative Control - system or technology whose purpose is to prevent an attack attempt or exploit from being successful. Also a system or technology whose purpose is to prevent a hardware failure from impacting service. Examples of preventative controls include: Strong passwords, firewalls, clustered servers, physical access restrictions, and encryption. Detective Control - system or technology whose purpose is to detect an attack, compromise, or hardware failure and alert an administrator in an appropriate time frame. Examples of detective controls include Intrusion Detection Systems, physical security systems, Centralized management tools, SNMP, automated logfile monitoring, content monitors, virus scanners, and integrity checkers. Corrective Control - system or technology that enables us to better respond to and recover from an incident, as well as prevent future occurrences. Corrective controls 3 “Control Types for Information Security”. Computer Operations Security. (April 6, 2003) include incident response programs and systems that record activity, events, or changes for future research. Directive - The control requires an end user or vendor to follow a policy or contract for it to be effective. We cannot control whether users or vendors follow policies, so policy controls are documented, but are not used in control adequacy calculations. If the policy only applies to IT personnel (such as a policy to disable default user accounts on servers) and I am confident and can verify that the IT personnel are following the policy, then I would not mark it as a policy control because it is effective in mitigating risk. Note that many controls will fall into more than one category. Sample of Categorizing Controls ID Control Prevention Detection Correction Direction 1 128 bit encryption on Internet communications X 2 Account and user rights management X 3 Authentication event logging X 4 Awareness and appropriate configuration X X 5 Backup generator X 6 Backup monitoring systems X X 7 Backup policies and procedures X X 8 Backup systems X 9 Border router access control lists X 10 Change default passwords X 11 Close port 80 into service network X 12 Desktop Antivirus X X 13 Desktop Antivirus Consolidated Management X X X 14 Desktop software installation policy 9. Determine Control Adequacy At this step determine definitions for “Control Adequacy” in terms of Strong, Adequate, or Weak. We developed different definitions based on the Initial Risk Tier. We found that what is an adequate level of control for medium or low risk systems may not be adequate for higher risk systems. To come up with our definitions, we first developed an abstract statement regarding what we believe constitutes a strong, adequate, or weak level of control. We then applied this abstract statement to the control categories of preventative, detective, and corrective, to produce “definitions” by which we can calculate the adequacy of the level of control. Sample Control Adequacy Definitions Higher Risk Systems (Tier 1 and Tier 2) Strong · In the abstract, assumes layered security, a reliable means for detecting and alerting to a compromise or failure, a means for tracking events and changes or researching past events, and a process to respond, recover, and prevent future occurrences. · For a given vulnerability, there exists · at least two layers of preventative controls which directly prevent exploit of this vulnerability · at least one detective control which will reliably detect an exploit of this vulnerability in a very short time · at least two corrective controls which will improve our ability to respond, recover, and prevent future occurrences Adequate · In the abstract, assumes there is a control in place preventing every threat or vulnerability from being successful, as well as a means for detecting and responding to compromise or failure. · For a given vulnerability, there exists · at least two preventative controls which directly prevent exploit of this vulnerability · at least two corrective controls which will improve our ability to respond, recover, and prevent future occurrences OR · at least one preventative control which directly prevents exploit of this vulnerability · at least one detective control which will reliably detect an exploit of this vulnerability · at least two corrective controls which will improve our ability to respond, recover, and prevent future occurrences Weak Does not meet the criteria above Medium-Low Risk Systems (Tier 3 and Tier 4) Strong · In the abstract, assumes layered security, a reliable means for detecting and alerting to a compromise or failure, a means for tracking events and changes or researching past events, and a process to respond, recover, and prevent future occurrences. · For a given vulnerability, there exists · at least two layers of preventative controls which directly prevent exploit of this vulnerability · at least one detective control which will reliably detect an exploit of this vulnerability · at least one corrective controls which will improve our ability to respond, recover, and prevent future occurrences OR · at least two layers of preventative controls which directly prevent exploit of this vulnerability · at least two corrective controls which will improve our ability to respond, recover, and prevent future occurrences Adequate · In the abstract, assumes there is a control in place preventing every threat or vulnerability from being successful, as well as a means for detecting or responding to and correcting compromise or failure. · For a given vulnerability, there exists · at least one preventative controls which directly prevents exploit of this vulnerability · at least one detective control which will reliably detect an exploit of this vulnerability · at least one corrective controls which will improve our ability to respond, recover, and prevent future occurrences OR · at least one preventative control which directly prevents exploit of this vulnerability · at least two corrective controls which will improve our ability to respond, recover, and prevent future occurrences Weak Does not meet the criteria above Here is the calculation for “Hardware Failure of Servers” as it affects the Accounting File Server. The accounting file server is a “Tier 1 - highest risk” system. For this vulnerability, there are: - two preventative controls (Hardware redundancy, and a third part Disaster Recovery contract) - one detective control (HP Openview will send an alert on hardware failure) - two corrective controls (Logfiles allow us to track and determine cause of failures, and documented recovery processes allow us to recover quickly) Applying the logic for control adequacy calculation, this results in a Strong Control Adequacy of our protection against server hardware failure. 10. Determine Residual Risk Create definitions for residual risk based on the Initial Risk Tiers and the Control Adequacy. The residual risk definitions are in terms of High residual risk, Moderate residual risk, and Low residual risk. We use a “weakest link” philosophy, if there is even one weakly controlled vulnerability for a technology, then that technology has weak controls overall. For a technology to have strong controls overall, every vulnerability must be strongly controlled. Residual Risk Rating Definitions High Residual Risk · Any system of Tier 1 (Highest) , Tier 2 (High), or Tier 3 (Medium) Initial Risk with Weak controls to threats and vulnerabilities Moderate Residual Risk · Any system of Tier 1 (Highest) or Tier 2 (High) Initial Risk with Adequate controls to threats and vulnerabilities · Any system of Tier 4 (Low) Initial Risk with Weak controls to threats and vulnerabilities Low Residual Risk · Any system (Tier 1 through 4) Initial Risk with Strong controls to threats and vulnerabilities · Any system of Tier 3 (Medium) or Tier 4 (Low) Initial Risk with Adequate controls to threats and vulnerabilities This may be more clearly understood in the following table. Residual Risk Matrix Tier 1 (Highest) Initial Risk Tier 2 (High) Initial Risk Tier 3 (Medium) Initial Risk Tier 4 (Low) Initial Risk Strong Controls Low Residual Risk Low Residual Risk Low Residual Risk Low Residual Risk Adequate Controls Moderate Residual Risk Moderate Residual Risk Low Residual Risk Low Residual Risk Weak Controls High Residual Risk High Residual Risk High Residual Risk Moderate Residual Risk After Step 11. Apply definitions and logic to the data and create reports Once your correlate all the data, you fill find that a great deal of information is generated. We created a web interface to display and navigate the data. Sample Technologies Summary Report System Initial Risk Control Adequacy Residual Risk Internet T-1 Tier 1 - Highest Strong Low Network Switches Tier 1 - Highest Adequate Moderate Corporate Mail Server Tier 1 - Highest Adequate Moderate Accounting File Server Tier 1 - Highest Adequate Moderate Backup Server Tier 1 - Highest Adequate Moderate Help Desk Application Server Tier 3 - Medium Weak High HR File Server Tier 2 - High Strong Low Maintenance File Server Tier 3 - Medium Strong Moderate Supplier Extranet - Frame Relay Tier 2 - High Weak High Palm Pilots Tier 3 - Medium Adequate Moderate This screen shows each system, its initial risk, overall control adequacy, and calculated residual risk. If you click on the technology name, you can drill down and get the detail report showing how the Initial Risk, Control Adequacy, and Residual Risk ratings were calculated. 12. Report results to corporate leadership GLBA requires annual reporting to corporate leadership of - status of information security program - compliance with Interagency Guidelines - risk assessment - risk management and control decisions - service provider arrangements - security violations and management response - recommendations for changes to the info security program4 4 “Interagency Guidelines Establishing Standards for Safeguarding Customer Information.” February 1, 2001. (March 6, 2003) 13. Review and update at least yearly The structure of this risk assessment process allows you to build on the previous years’ results rather than start over from scratch each year. The extra time saved by not repeating the effort can be used to “fine tune”, or make the groups and vulnerabilities more specific to obtain more accurate results. You can also add technologies, vulnerabilities, and controls throughout the year as changes are made within the corporation, and then regenerate the reports to determine how overall risk has been impacted. Enhancement Possibilities What-If Scenarios The system could be used to evaluate the impact of new technologies on overall risk. During vendor selection or a technology implementation for a new system or service, enter the system into the risk assessment process, categorize the data, relate the vulnerabilities and controls, and display how the overall risk has changed. It would also be beneficial to evaluate new security controls in this way. By putting a security control into the system, you can show which vulnerabilities or threats it impact, and which technologies or systems it impacts. You could also do what-if scenarios for new vulnerabilities. When a new vulnerability is identified, enter it into the system and relate it to the appropriate technologies and controls. Then view the reports to see how the Residual Risk Level has changed. One enhancement to the system that would make “what if” scenarios easier would be the ability to take a “snapshot” of the state of the system before applying changes such as new technologies, vulnerabilities, and controls. After the changes are made, the new state could be compared to the snapshot programmatically, generating a new report only showing those things that changed. Include Physical Security GLBA requires that your electronic data security program be coordinated with your physical data security program. It could be possible to extend the structure outlined above to include physical security. This will likely involve developing new control adequacy definitions to support physical security controls, but many other aspects would likely need to change very little.