Feature Arian Eigen Heald, CISA, CGEIT, CEH, CISSP, GCFA, is leading BerryDunn’s government consulting information technology security practice, with more than 22 years in IT. She is the subject matter expert for information security at BerryDunn and a regular speaker on the topic at conferences. She has written a blog for TechTarget and is a frequent author on berrydunn.com. Do you have something to say about this article? Visit the Journal pages of the ISACA web site (www.isaca. org/journal), find the article and choose the Comments tab to share your thoughts. Go directly to the article: Vendor Governance in the Age of Information Security From businesses to government agencies, nearly every entity contracts some aspect of software development, system integration and hosting services—creating an emerging crisis in accountability. How does an organization that has an IT department with average skills implement a large, complex, far-from-average new technology, such as electronic health records or asset management systems? In this age of specialized skill sets, it seems perfectly sensible to outsource such a deployment. Managing how to secure the confidential data contained within the new technology—and the welter of regulatory requirements that must be met to do so—is one of the most important and underappreciated challenges of this decade. With hundreds of frequently overlapping security requirements, it can seem deceptively simple to contractually require that the vendor be compliant with all the appropriate regulations. What cannot be overlooked, however, is that the contracting organization must have sufficient resources to provide adequate oversight of vendor compliance activities. RESPONSIBILITY CANNOT BE OUTSOURCED Whether the vendor is developing and integrating new technology that the organization will maintain or the vendor is also hosting the new technology, the compliance requirements for securing confidential data are the same. In the US, for example, federal regulations require that even if a vendor agrees to provide security services, the owner of the data be responsible for ensuring that the vendor protects the data. Though a vendor may be the source of a data breach, in the court of public opinion, the negligent party is the entity that has contracted the services of an inadequate vendor. For example, in the case of the Target breach, the name of the third-party vendor that was the source of the breach was eventually identified, but the breach itself was publicized as, “Target has been hacked.” At Target’s highest management levels, heads rolled and the company’s bottom line took a major hit. The accountability and compliance crisis goes far beyond the retail world, touching all industries: commercial, not-for-profit and, perhaps most urgently, government. FEDERAL FUNDING TRIGGERS FEDERAL COMPLIANCE STANDARDS FAR AND WIDE Although US state, city and town agencies are not federal entities, by accepting federal funding, they must meet federal standards to connect to federal sources of information, such as the US Internal Revenue Service (IRS), the US Social Security Administration, and the US Department of Health and Human Services (HHS). The funding of these systems has fueled the implementation of these standards. Correspondingly, many business and nonprofit entities that provide services to cities and states based upon confidential information are finding that they are contractually required to become compliant with such standards in order to continue doing business with these government entities. Over the past five years, the US National Institute of Standards and Technology (NIST), Special Publication 800-53, Security and Privacy Controls for Federal Information Systems and Organizations,1 has emerged as an information security standard for compliance among US state and local government entities. Regulations such as the US Health Insurance Portability and Accountability Act (HIPAA), the US Affordable Care Act (ACA), and the US Federal Information Security Act (FISMA) have had additional impact on IT security controls for personal health information (PHI). IRS Publication 1075 is a complementary set of standards for federal tax information (FTI). In the rollout of the new health insurance exchanges across the US, the Center for Medicaid and Medicare Services (CMS) has mandated the ISACA JOURNAL VOLUME 4, 2015 1 use of NIST SP 800-53 for those state entities choosing to accept funding. The latest set of compliance requirements (the CMS Minimum Security Requirements, or MARS-E, Minimum Acceptable Risk Safeguards for Exchanges2) maps directly to NIST SP 800-53. These standards are now being attached to funding to update or implement new Medicaid management information systems (MMIS) and eligibility systems run by states across the country. Commercial and nonprofit support services for these new and updated health systems are feeling the trickle-down effect of these mandates when contracting entities require periodic inspection of their controls to determine if they are compliant. One of the requirements specifically called out by the CMS and the IRS has been for those entities to have periodic independent third-party security assessments. These and other assessments have revealed critical and persistent challenges involved in managing the complexity of third-party contracts for services. THIRD-PARTY ASSESSMENTS REVEAL GAPS IN THE GOVERNANCE PROCESS Governance problems become visible when mandated independent security assessments examine vendor practices. The most frequent findings appear in these NIST-designated areas: • Secure software development (SA) • Access controls (AC) • Configuration management (CM) • Logging and monitoring (AU) These areas map to the following gaps in governance activities by the contracting organization: • Lack of resource planning for sufficient technical oversight • Limited in-house knowledge of the security requirements for the new technology • Over-reliance on generic contract language for technical compliance requirements A new technology compounds existing problems. Layers of technology continue to increase, creating more layers of security risk. Virtual technologies, for instance, have added the ability to build out incredibly powerful operating systems in a far smaller physical space. These technologies make possible a security breach much bigger than the compromise of one server. Compromise of the hypervisor (the virtual machine host managing the virtual operating systems) can mean that the hacker has access to all the servers and data inside that virtual system. 2 ISACA JOURNAL VOLUME 4, 2015 As new products are deployed, there is more chance for documentation of security features to be minimal or rushed, and existing documentation can quickly become outdated. For example, service-oriented architecture (SOA), with its certificate architecture for authentication, can become a black hole for compliance analysis. For a contracting organization, lack of documentation can mean being held captive to a vendor and expensive consulting fees. Project risk assessments have not adequately captured many aspects of vendor oversight, including managing the development, test and production system rollouts. Vendors scramble to It is not uncommon for vendors to have unfettered get code to work on control over all aspects a deadline or to fix of the new development, emergencies, too often at test and production systems, often denying the the expense of security. contracting entity any access. This allows code to be created in undocumented systems that will be more likely to have problems in a secure production environment. Vendors scramble to get code to work on a deadline or to fix emergencies, too often at the expense of security. The risk brought about by this deeply engrained pattern in this outsourcing culture cannot be overestimated. “ ” MORE OUTSOURCING MAY HELP SOLVE OUTSOURCING PROBLEMS Contracting organizations often struggle with the question of how to better monitor their vendors. Many are not prepared to assign in-house engineers who already have significant duties to provide oversight of vendor activities. Often, the reason organizations turn to outsourcing in the first place is that their employees have insufficient expertise to understand all aspects of the technology. Even organizations trying to monitor their vendors may not be set up to handle the necessary level of reporting duties. Front-line technical personnel often do not have sufficient access to higher-level project managers to report problems. Ironically, the solution to outsourcing problems may be more outsourcing. In the same way an organization outsources for technology development and deployment expertise, it may need to consider whether to outsource technical compliance from an independent party that has no relationship with the vendor. • Read Configuration Management: Using COBIT® 5. www.isaca.org/ configuration-management • Learn more about, discuss and collaborate on governance of enterprise IT (GEIT) and information security in the Knowledge Center. www.isaca.org/knowledgecenter This establishes segregation of duties (SoD) so that the secure development and implementation of the systems and software underlying new technology are adequately protected. Rather than waiting for a security assessment just prior to, or just after, rollout into production, contracting organizations would be better served by implementing continuous monitoring throughout the project. IMPROVING VENDOR GOVERNANCE Improving vendor governance may require a shift in priorities or culture for the contracting organization. The security challenges discussed previously generally manifest themselves in five distinct areas where the contracting organization can take steps for better oversight: 1. Recalculate the risk and cost of secure software development. For many, especially cash-strapped government agencies, cost has been the limiting factor for providing sufficient vendor oversight. Today’s rising incident rates for data breaches, coupled with increased regulations, call for a fresh look at the cost-benefit analysis of putting more resources into vendor oversight. Both the NIST and the US National Aeronautics and Space Administration (NASA)3 have completed studies on the differences in cost for remediating code errors during the different phases of software development. The studies revealed that it can cost up to 30 times more to resolve code errors once the product is in production status. The Ponemon Institute’s ninth annual report, 2014 Cost of Data Breach Study: Global Analysis,4 highlights the fact that the average cost for each record lost or stolen increased from US $136 to $145 (9 percent) from the previous year. The longer the delay in implementing and overseeing secure software development, the higher the cost when the breach occurs. In addition to data breach record costs, there is significant compliance risk5 in not providing sufficient oversight of vendor activities, as is required in CMS’ MARS-E, FISMA and IRS 10756 regulatory documents. For example, one of the requirements from SP 800-53 is SA-10 Developer Configuration Management: The organization [meaning the contract holder] requires the developer of the information system, system component, or information system service to: a. Perform configuration management during system, component, or service development, implementation, and operation; b. Document, manage, and control the integrity of changes to configuration items under configuration management; c. Implement only organization-approved changes to the system, component, or service; d. Document approved changes to the system, component, or service and the potential security impacts of such changes; and e. Track security flaws and flaw resolution within the system, component, or service and report findings to defined personnel or roles (defined in the applicable security plan).7 2. Mandate secure software development. Security controls should be built into every phase of software development, regardless of which software development model the vendor uses. NIST provides an excellent template in its Special Publication 800-64, Security Considerations in the System Development Life Cycle.8 Although a system integrator may take on the task of building out the infrastructure (e.g., servers, databases, virtual hosts, routers) to support the new application, this type of vendor’s primary focus is to develop a software product that meets the requirements of the client in the most cost-effective way possible. ISACA JOURNAL VOLUME 4, 2015 3 Unfortunately, cost-effective does not necessarily translate into secure. In many third-party environments, security is a much-delayed add-on, and documentation is focused primarily on application development and meeting business requirements. One could say that it is an occupational hazard that IT vendors want to implement infrastructure in a way that is most conducive to software development. The fastest approach for software development is when the applications have complete access rights to all data. Fortunately, regulatory requirements mandate better controls, but if the contracting entity does not mandate secure development systems and detailed access control documentation of the systems, it risks a disaster. The application could break in a locked-down production environment or be hacked due to lack of controls in an open one. These requirements should be put into place upon commencement of the contract and not applied in the final deployment into production, where it is far more costly to resolve. How a software developer builds the development environment is critical to the delivery of a secure application and infrastructure. 3. Maintain access controls. With adequate resources, a contracting entity can better ensure that vendors implement compliant controls and develop secure software that meets business requirements. Vendors ought not to be allowed to develop in a security vacuum where use of generic administrator identifications (IDs) is the norm and password controls are minimal. When new systems are first booted up for the initial development environment, the vendor should have a documented server build ready for deployment. The contracting entity should provide oversight for the standard build to confirm that security engineering principles form the backbone of the development environment. For example, the NIST SP 800-53 Control SA-8 Security Engineering Principles offers the following guidance: 4 ISACA JOURNAL VOLUME 4, 2015 Security engineering principles include, for example: •D  eveloping layered protections; •E  stablishing sound security policy, architecture, and controls as the foundation for design; • I ncorporating security requirements into the system development life cycle; • Delineating physical and logical security boundaries; •E  nsuring that system developers are trained on how to build secure software; •T  ailoring security controls to meet organizational and operational needs; •P  erforming threat modeling to identify use cases, threat agents, attack vectors, and attack patterns as well as compensating controls and design patterns needed to mitigate risk; and •R  educing risk to acceptable levels, thus enabling informed risk management decisions.9 The contracting entity should require and maintain administrative access to all development, test and production systems. If the vendor has implemented proper logging and monitoring of access, any unauthorized changes should be easily tracked to the source of that activity. It cannot be overstated that the contracting entity, not the vendor, is the owner of those systems and must maintain control. The vendor must never control the systems to the exclusion of the data owner. The simplest way to achieve this is to always have administrative access to the systems from the very beginning of the project. Equally, the contracting entity must maintain ownership of the code that is being developed because it is a form of intellectual property for which the entity is paying. Therefore, consistent and complete access to the vendor’s code repository provides for continued possession and allows the entity to monitor the vendor’s controls over the code. Using PHI, personally identifiable information (PII) and federal tax information (FTI) data in development environments often helps to develop code that will eventually use these data. However, maintaining access controls over who sees the data is the responsibility of the data owner, not the software developer. Products in the marketplace can obfuscate confidential data for testing purposes, but many organizations find them cost-prohibitive. With adequate controls over access, waivers from federal entities (the IRS, in particular) can be obtained. SoD is often nonexistent in development environments and, quite frequently, in production environments. Software developers should not have any more than read-only access to production environments. Database administrators should not have server administrator rights and vice versa. Implementing these controls in the development environments means that systems are managed more securely from the beginning of the project. Some vendors resist this approach, claiming that it could create security problems when the code is moved into production, but the reverse is actually true if the development systems are configured securely. 4. Start configuration management from the beginning. In the eyes of NIST, the IRS and FISMA, “configuration management” has become an umbrella term that incorporates a range of activities, including: • Documented baseline configurations based on national standards • Implementation of least functionality • Change control management • Information systems component inventory • Testing of changes prior to deployment • Security impact analysis of changes • Access restrictions for changes • Software usage restrictions across the architecture. A patch may work perfectly on one Linux server and fail on the next because someone made a change to the server that was not documented. When this is replicated across more than 200 servers, the cost to managing updates can become prohibitive and lead to insecure systems. Monitoring changes on systems is much easier when a common standard is implemented. Small changes can also be the first alert of a data breach in progress. Monitoring system changes is a core element in meeting, for example, the NIST requirement in AU-2 Audit Events: Generate audit records for the following events in addition to those specified in other controls: a) All successful and unsuccessful authorization attempts. b) All changes to logical access control authorities (e.g., rights, permissions). c) All system changes with the potential to compromise the integrity of audit policy configurations, security policy configurations and audit record generation services. d) The audit trail shall capture the enabling or disabling of audit report generation services. e) The audit trail shall capture command line changes, batch file changes and queries made to the system (e.g., operating system, application, and database).10 5. Control logging and monitoring. Possibly the largest security gaps exist in the areas of logging and monitoring. In implementing security controls, contracting organizations often focus on product performance and delivery to the detriment of security controls. Generally, these requirements have not been addressed until much later in a project. As a result, undocumented changes, unpatched systems and a lack of standardization lead to the contracting organization not having firm control over the security architecture. It is common practice for the contracting organization to require the vendor to perform all monitoring of the new systems. Unfortunately, this usually means that the organization expects the vendor to monitor vendor administrative activities. This is an obvious conflict of interest for the vendor and is in direct conflict with security best practices. Patching and updating critical system components that work in layers can lead to expensive crashes and downtime when systems are not configured to a single standard Consider the NIST SP 800-53 Audit and Accountability (AU) control AU-9(4) Access by a Subset of Privileged Users: ISACA JOURNAL VOLUME 4, 2015 5 The organization [the contracting entity] authorizes access to management of audit functionality to only those individuals or roles who are not subject to audit by that system, and is defined in the applicable security plan.” Reasonably, the organization would want to retain control of audit logs that may contain confidential information, in order to determine whether the vendor is performing activities that are compliant with federal requirements. Logs can be stored at a vendor location without the vendor having access, beyond read only, or can be transferred to another location. Alternately, another third-party vendor could be engaged to perform monitoring activities as long as that party reports to the contracting organization, not to the vendor performing the administrative activities. This is not to say that the vendor should be exempt from monitoring application and performance logs. It is simply a matter of SoD, so that system administrators and database administrators are not in charge of monitoring their own actions. Should a contracting organization allow another group within the vendor organization to monitor their own administrative activities? There may not be sufficient SoD to be an effective practice. The vendor can overrule or delay security findings if kept to an internal group. Also, it is less likely that such decisions are transparent to the contracting organization. Audit logs, when implemented according to requirements, are the backbone of security prevention, detection and response. An Incident Response Plan11 provides a process for responding to security incidents that are found in logs. Whether malware, failed logins or distributed denial of service (DDoS) attacks, there should be a process for performing an initial analysis, documentation, prioritization and notification. The contracting organization should ensure that a formal, detailed plan is in place for preparation, detection and analysis, containment, eradication, and recovery that is compliant with federal requirements and details actions, as well as reporting activities, for the vendor to incorporate. Figure 1—Current Practices Related to Monitoring and Managing Third-party Risk In which of the following types of information do you see value in monitoring when it comes to third-party security? How often does your organization formally track the following third-party security information? (answers of “monthly or more”) Threat and vulnerability management Encryption policies and procedures 67% 16% Security incidence response processes 64% 23% Security roles and responsibilities within the organization 58% 16% 58% 13% Patch management 55% 37% Configuration standards for applications Organizational management practices of their own third parties 66% 33% Threat intelligence practices Configuration standards for infrastructure 68% 36% 50% 16% 10% 42% Base: 106 IT decision-makers at enterprises in the US, UK, France and Germany. Source: BitSight Technologies, a commissioned report conducted by Forrester Consulting, November 2014. Reprinted with permission. 6 ISACA JOURNAL VOLUME 4, 2015 CONCLUSION In October 2014, BitSight Technologies commissioned Forrester Consulting to examine the current practices of IT decision makers as they relate to How resources are applied monitoring and managing third-party during major technology resulting initiatives and improvements risk. The report,12 released can be the difference in January 2015, between a secure system and found that “there is one that is constantly subject significant appetite for monitoring various to problems. elements of thirdparty security, yet few firms have the resources to do so with adequate frequency or objectivity”13 (figure 1). The challenge of applying good security practices is greater than ever. How resources are applied during major technology initiatives and improvements can be the difference between a secure system and one that is constantly subject to problems. In addition to meeting security requirements, the core areas discussed in this article lead to reliable systems. Problems are more likely to appear when controls are not in place. They also become extremely difficult to track and resolve. Without solid security principles, undetected breaches are more likely to occur. The time and effort taken during the beginning of a project to use secure standards will result in significant savings—of money, time and trouble—throughout the life of the technology. “ ” ENDNOTES 1 National Institute of Standards and Technology (NIST), Security and Privacy Controls for Federal Information Systems and Organizations, USA, April 2013, http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-53r4.pdf 2 Centers for Medicare and Medicaid Services, CMS Information Security Acceptable Risk Safeguards, USA, 20 September 2013, www.cms.gov/ResearchStatistics-Data-and-Systems/CMS-InformationTechnology/InformationSecurity/Downloads/ARS.pdf 3 NASA Johnson Space Center, “Error Cost Escalation Through the Project Life Cycle,” National Aeronautics and Space Administration (NASA), http://ntrs.nasa.gov/ archive/nasa/casi.ntrs.nasa.gov/20100036670.pdf 4 IBM, “2014 Cost of Data Breach Study,” Ponemon Institute, www-935.ibm.com/services/us/en/it-services/ security-services/cost-of-data-breach/ 5 Compliance risk is the risk of legal sanctions, material financial loss or loss to reputation that the organization may suffer as a result of its failure to comply with laws and regulations. 6 Internal Revenue Service, Publication 1075, Tax Information Security Guidelines for Federal, State and Local Agencies, USA, October 2014, www.irs.gov/pub/irs-pdf/p1075.pdf 7  Op cit, NIST 2013 8 National Institute of Standards and Technology (NIST), Security Considerations in the System Security Life Cycle, USA, October 2008, http://csrc.nist.gov/publications/ nistpubs/800-64-Rev2/SP800-64-Revision2.pdf 9  Op cit, NIST 2013 10  Ibid. 11 See NIST SP 800-61, Revision 2, Computer Security Incident Handling Guide for an excellent template. 12 BitSight Technologies, Continuous Third-party Security Monitoring Powers Business Objectives and Vendor Accountability, January 2015, http://info. bitsighttech.com/continuous-third-party-securitymonitoring-powers-business-objectives 13 Ibid., p. 3 ISACA JOURNAL VOLUME 4, 2015 7
Purchase answer to see full attachment