Doveryai no proveryai. (Trust, but verify.)
—Russian proverb used by President Ronald Regan during arms control negotiations with Russian President Mikhail Gorbachev in the 1980s.
Every organization is dependent on other organizations outside of itself. It’s unlikely that your organization writes all of its own software, builds its own hardware, owns the buildings it occupies, and is an internet service provider. Your security is dependent on many of these things but if they are produced outside of your organization, your control is limited. Previous chapters touched on risk and controls for third parties, but what happens when those third parties are critical to your scoped environment and audit? You need to manage the security where the third party touches your scoped environments. Before you manage, you need to measure. To measure the security of an outside organization, you need to use everything you’ve learned about being audited and apply it to someone else. Even if you pay someone else to audit the third party, you still need to define the scope, requirements, and testing, and interpret the results.
Which Third Parties Are Relevant?
The third parties we’re concerned about are the ones where their actions or inactions can affect the security of your scoped environment. You probably won’t include the company that supplies the water cooler bottles, unless they have their own keys to a secure facility. A good indicator is the criticality of dependence. If you are relying on the services from an outside organization, they fall into scope. The following are some of the third parties that IT security programs often have to deal with:
Building management and janitorial
Co-location facility
Cloud-services providers
Contracted IT workers
Internet Service Providers
Off-site backup services
Shredding services
Software packages and vendors that touch scoped systems
Managed security service providers
In large, dispersed organizations, even other divisions of the same company could be treated like third parties. It all depends on the level of control that you can wield over the entity. If a company department is outside the authority of the security program but still has connections into the scoped environment, then you need to treat them as a third party. For example, if your scoped environment resides within the e-commerce division of a large manufacturer. All of the activity and management of e-commerce are run within the e-commerce division except human resources. A parent company in a city far away handles all HR activity, even for your division. The VP running the e-commerce division has no direct authority over HR back at headquarters. Since hiring and background checks is in scope, you need to set up some kind of third-party arrangement to ensure that HR does things according to the standards required by the e-commerce security program. Another good example is a government entity, where some critical functions are provided from another government entity outside its realm of authority.
Customers and business partners can also qualify as third parties. Depending on your business model, there are instances where a customer may need network access to an internal scoped environment. This creates a touchy situation where you need to measure and apply controls to a customer that you don’t want to irritate. In some cases, you have scope by association. If you share information with a business partner, you need to consider who they share that information and how.
Analysis of Third Parties
As with everything in security, you need to understand what risk to what assets before you apply controls. The challenge with a third party is that you do not have direct access to all the information you may need to assess risk accurately. The depth of your assessment should be based on the potential impact from a third-party security failure. Whatever process, service, or asset can be affected by the third party needs to be investigated. Third parties with direct access to scoped systems and data is a high priority and requires very thorough analysis and testing to ensure that you’re seeing a satisfactory representation. These analyses should be done upon first contracting/connecting with the third party and repeated and at least annually, depending on changes to their environment.
Risk Analysis
The question of what to test at a third-party provider is probably the easiest thing to answer. It should flow directly from your current control objectives and audit requirements. Since your controls and requirements come from a risk analysis, it makes sense that the third parties should mirror your control objectives as well. One of the things you can request is a risk analysis related to the contracted services done by the third party. A good sign of a healthy security program is relevant and complete risk analysis, so this in and of itself would be a good indicator of their maturity.
In the absence of a risk analysis from a third party, you need to do one yourself. All things being equal, there are probably a handful of relevant general risk scenarios to consider with the third party. Not all of these may be applicable with all of your third parties, and there may be additional scenarios, but here is a good starting list of risks to consider:
Rogue insider at the third party steals or leaks your data
Outage of contracted service
Malware in third-party network leading to leakage or outage of your data
Lost media or portable device containing your data
Internet-facing service at third party hacked leading to leakage or outage of your data
Unauthorized physical access to third-party facilities leading to leakage or outage of your data
Any of these risks occurring at another third party being used by your third party (fourth party)
You can present this list of risk scenarios to the third party and ask them how they manage these risks. This is can be a time-intensive approach that requires more interpretation and analysis, but it yields far more useful information about their security and trustworthiness.
Control Gap Analysis Approach
The more common approach in third-party analysis is skip the risk analysis and jump right into a gap analysis against the controls that should be in place. This approach is simpler but makes assumptions about the typical risks and appropriate defenses required. You could use your current control set as a master list to check against. To save time and energy, especially if you have many third parties to investigate, you could boil things down to key controls that you feel might be important. Here is a simple list of likely key controls to check:
Data encryption on portable media and computers
Change control on contracted services/applications
Security policy and security planning
Regular vulnerability assessments
Background checks on personnel
Application security analysis if providing or developing apps for you
Anti-malware strategy (beyond just antivirus software)
Access controls
Instead of general controls covering large risks to services, you could also do control gap analysis on the specific services being offered by the third party. Table 23-1 is a list of controls broken out by service.
Table 23-1. Third Parties and Controls to Examine
Third Party | Controls to Investigate |
|---|---|
Building management and janitorial | People controls especially background checks |
Co-location facility | Physical controls, operational controls, people controls |
Cloud-services providers | Pretty much all controls except application controls |
Contracted IT workers | HR controls especially background checks, security training |
Internet service providers | Response controls, especially business continuity |
Off-site backup services | Physical controls, operational controls, people controls |
Shredding services | Physical controls, operational controls, people controls |
Major software vendors | Software development controls, vulnerability testing |
Managed security service providers | All controls |
You could trim some of the specific controls back but only after conferring with the third party and hearing their explanation as to why that particular control would be not applicable. It’s better to ask for more and then drop what you don’t think is important. It is a waste of everyone’s time if you are going to delve into detailed examinations of controls and processes that are wholly irrelevant to your scoped requirements. For example, I’m not going to investigate the software development controls of my shredding service provider.
Getting Answers
Now that you have an idea about what to ask, how do you go about getting answers from the third party? The simplest and most common way is to send the question list to the third party and give them a deadline to respond. This is called a self-assessment, which relies on the third party attesting to the truth of their answers. To bind them tighter to truthful answers, you can include a formal attestation statement at the end of the questionnaire for an executive to sign. You can deliver these questions electronically via e-mailed spreadsheet or document. Some organizations use web-based survey tools and have third parties login and answer.
The next level of assurance is to require the third party to submit documentation along with their answers. Just like your auditors, you can ask them to provide screen-shots and administrative control documentation as proof of existing controls. Along with this, it is not unheard of to ask for actual output from scans and completed checklists.
The highest level of third-party review is to send a team on-site to their offices and conduct a direct assessment of their security program. This should be planned just like an audit, with an agenda, a pull-list of requested information, and interviews with selected roles. It is the most informative, since you can directly examine the risks and controls at the third party. It is also the most resource intensive, especially if the third party is distant from your organization. Many financial institutions use this kind of assessment for their key vendors because of the high risk involved in banking and bank transactions. Some organizations also hire consultants or auditors to go on-site for them and perform assessments.
Reading Their Audit Reports
Because many IT service providers have customers who are under compliance requirements, they obtain their own independent audits of the relevant parts of their service. As discussed in Chapter 1, a report from a reputable auditor is a good indicator about the confidence an organization places in their IT security program. External audits are expensive and force an organization to have a formal security program.
If the audit report is scoped correctly and covers the right services, then your risk assessment work is much easier. In fact, since many IT service providers are under intense scrutiny from their customers, they often end up covering many different compliance requirements with comprehensive audits. Providers can also leverage economies of scale and have superior security programs than what your organization could afford. Don’t discount a third party as being insecure by default.
When receiving third-party audit reports, be sure to read them carefully. Remember which parts of the audit report to examine. You need to look at the scope to make sure that what was audited matches the services relevant to your organization’s usage. You cannot make any assumptions about the state of things out of scope; they are unknown and must be tested to be validated.
You should also look at the date of testing. All audit reports, by definition, are out of date the second they are published. Audit reports only point backward in time. So you still have to use your judgment to determine if all the audited controls they have in place remain in place in the future. For this reason, audit reports are perishable with a shelf life of less than a year. Any report older than that should not be considered viable for risk analysis. For dynamic organizations, such as fast-growing startups, the report’s shelf life would be shorter.
Analyzing It All
Once you’ve gathered data about the third party, you need to analyze it and render an opinion to management on the risk of using the third party. Based on this analysis, the organization can choose to stop using the third party (eliminate the risk), continue as before (accept the risk), or manage the risk (apply additional controls). Keep that in mind when doing the analysis. It’s likely that your organization needs to manage the risk either directly or indirectly (by requiring the third party to add controls), so management’s next questions after receiving your analysis will be about controls and scope changes.
In addition to the maturity and the effectiveness of their controls, you can also get sense of the overall strength of their security program. You can learn this not only from the answers, but also by how they answered you. Are they responsive, complete, and transparent in their answers? Or do you get the sense they are reactive and struggling to fit inappropriate controls to meet risks? Do their security personnel understand security concepts like least privilege and assume breach? Or are they attempting to meet the letter of the compliance law? When challenged, are they open to your questions or do they react defensively with statements like, “Everyone else accepts this. You should too.” Evasion, defensiveness, preparedness, speed, and reluctance to answer are all warning flags that their program may not meet your needs. The question to consider is this: How is the third party answering the questions? A prepared organization may pull answers from a frequently asked question list. An unprepared organization may generate new material—perhaps not even based on the truth and awareness, but on aspiration and what they think you want to hear.
Concerning the controls and risks as a whole, if you find many problems , you should consider if there is evidence that the problems are any of the following:
A matter of maturity. They know where they’re going; they’re just not there yet.
Design problems. They know where they’re going, but it’s the wrong place.
Organizational problems. They are completely reactive to security problems and have no consistent plan.
As you might guess, some of these problems are more manageable than others. Sometimes these kinds of conclusions are difficult to make, especially if you’re new to audit and third-party review. I mention them as considerations so you have some idea of the analysis techniques of seasoned security professionals.
Controlling Third-Party Risk
Like controlling all other risk, when we talk about controlling the risk for third parties, we focus our controls on reducing the likelihood or the impact of possible undesired actions. You can reduce the likelihood by requiring the third parties to have their own security controls in place. This is probably both the most effective in terms of outcome and the most difficult to do since you do not exert direct control over their security. Sometimes a third party asks you to incur some of the costs of additional controls that you are requiring of them
If adding controls at the third party isn’t feasible, you can also apply your own controls directly upon certain kinds of third parties. For example, you could require all on site contractors to be background checked by your HR department and attend your organization’s security training.
Another type of control to apply is to limit damage from a third party. You can do this by reducing the scope of their access. You can look at limiting their time exposure and/or asset exposure to your organization. For example, contractors can only access our VPN during business hours and can only connect to these three machines. Sometimes this is difficult, depending on the nature of the work that the third party is doing. That leaves trying to contain an impact with internal barriers and rapid detection controls. If building janitorial personnel need full access to your office, then lock the server cages and put up surveillance cameras. As we move into looking at controls, let’s start with some policy.
Sample Policy for Third-Party Management
To ensure that all contractors and vendors who have access to critical systems and data will support ORGANIZATION security objectives, ORGANIZATION will maintain a formal Third PartyManagement Processthat will:
Contractually require these third parties comply with ORGANIZATION security policies and documented processes. These contractual requirements will include provisions for the third party to:
Acknowledge their responsibility for the security of ORGANIZATION data they possess
Acknowledge their duty to quickly notify ORGANIZATION in the event of a breach of privacy or IT security
Provide proof of the third-party security controls with either an independent audit report such as SSAE-16 SOC 2 or ISO 27001 or agreement to be audited by ORGANIZATION or its representative at leastannually
Furthermore, ORGANIZATION will perform a risk analysis of all third parties with access or influence oncritical systems.
This risk analysis will be the responsibility of the Security department and will be completed before the third party is granted access to critical systems.
Based on this risk analysis, the security department will propose controls and changes to ORGANIZATION management reduce the risk to acceptable levels.
This risk assessment and controls review process will be repeated annually for all third parties with access to critical systems.
TheIT and Security departmentwill work together on a software security standard that will be used to evaluate acquisitions ofCommercial Off The Shelf software (COTS)as well as custom software used for collection, processing, and storage of sensitive data.
Documentation regarding the third-party risk analysis and the specific process controls and checks that are used to ensure compliance with the third-party security requirements, including preferences for independent audit such as SSAE 16 SOC 2 or ISO 27001
Be cautious requiring employees of a third-party organization to sign your security policies. With individual contractors directly hired by your organization, requiring individuals to sign carries some enforceable obligation, such as terminating their individual contract. With an organization, your policy statements should be agreed upon between organizations. It is then the responsibility of the third party to ensure that their representatives fulfill the policy objectives. Often in most organizations, only a select set of individuals are empowered to legally agree to terms on behalf of the organization. You could be creating a false sense of security and a potential legal hassle by trying to get the guy who empties your trash can to sign your acceptable usage agreement.
Software Procurement
The third-party security policy defines the need for a security standard for software acquisitions. What should be in this standard? The first thing is to make sure that any software you use on scoped systems can support your existing controls. That last thing you want is building compensating controls for a new piece of software that won’t pass audit. If you require two-factor access into the scoped environment (and in many cases you should), then any systems you install should be able to either do or integrate two-factor authentication. Similarly, look at your requirements for authorization, hardening, encryption, backup, and logging.
If it’s a large and important application, then your standard can call out a requirement to perform a vulnerability scan against a demo or proof-of-concept version. This should be done before software acquisition. When deployed, the application is subject to the normal vulnerability scanning you do already. Similarly, your standard can include requirements around support, vulnerability notification, and timely delivery of patches. You should test web-based applications against the OWASP top ten vulnerabilities,1 especially if they are Internet facing.
For custom software, application security testing and/or secure code scanning should be a requirement. If serious vulnerabilities are found, the third party should be obligated to fix them in a reasonable time. You can put these requirements into a software development contract, which is described in the next section.
Acquired systems that fall into scope for PCI DSS need to meet the Payment Application Data Security Standard (PA-DSS )2 for software and the PIN Transaction Security (PTS) Standard 3 for point of sale devices.
Security Service Agreements
The problem with outsourcing is that you’re giving up control to the third party. You have no direct levers or methods to ensure that security practices are being followed. If you can’t apply technical controls on a third party, then you can use legal controls like a security service agreement. These agreements can include outsourcing contracts, IT service agreements, and Memorandums of Understanding (MOU ). In general, all of these agreements are legal documents, which are tied to technology and third-party services performed for your organization.
These agreements can stipulate what security controls you require to have in place with the third party with some kind of penalty for non-conformance. Ultimately, the agreement is leverage for future legal action if something goes wrong. The agreement itself spells out what is expected, and therefore, what is considered negligent.
MOUs are agreements for other divisions of a large dispersed organization. It may not make sense to have an actual legal agreement between the divisions, but an internal formal agreement between departments can help clarify responsibilities and expectations for both sides. In some ways, the MOU acts like an acceptable usage agreement between departments in an organization. The MOU can also spell out service level agreements regarding security, which you can use to assign responsibility if something goes wrong.
You are likely not an attorney, which means you wouldn’t be ultimately responsible for writing the final version of a security service agreement. However, in most cases of using a third party, there is already a legal agreement being developed. If the third party is providing IT services, then there is probably a section of the agreement spelling out the technical specifications. Your need to work with your legal team to ensure that there are adequate security provisions in the agreement, either in their own section or within the technical specification, or both. The review of those contracts should be considered a required administrative control that you could put into policy.
Contents of the Agreement
What should be in this agreement ? The goal is to make sure that all of your relevant identified security objectives and risks are covered. You can go down your list and make a list of how it applies to the third party. From there, you can consider how you want the third party to cover that risk and what you want to happen if the risk occurred. Here are some ideas of what can go in there:
Data classification. Begin at the beginning and define the data types that should be protected by the third party. This can include credit card account numbers, personally identifiable information, and documents labeled “confidential.”
Non-disclosure. Not just restrictions on sharing your data (which should be there), but what the third party can talk about outside the relationship. Can they share information about your organization and its internal processes? Are they allowed to talk about what they do for your organization?
Data locale. Where can your data be moved within the third party? Can it be moved outside the country? Can they use a cloud service provider to store your data? Make sure that they get your organization’s permission before doing any of these things.
Required controls. Define exactly what controls you want the third party to use to protect your stuff. This is often a long list, so it’s better to include it as an attachment to the agreement describing your security requirements. The goal is to be detailed enough to ensure that things are done to your requirements. For example, saying you want background checks isn’t enough. For the third party, that may be interpreted as just calling their previous employer. Describe your background check criteria in detail.
Right to audit. Hold them to the same standard you need to meet for the relevant services. This means that the third party needs to provide an annual independent audit report for a specified compliance requirement or agree to be audited by you or your representative. Who pays for the audit is often another negotiating point in these kinds of discussions.
Data ownership. Make sure that your organization retains ownership of all data provided to the third party and that you can get access to that data even if there are financial or contractual disputes. The third party should not be using your data for anything other than what is required to perform the agreed upon services. Is meta-data being collected about your organization’s usage of services? How is being used and shared? Is there a privacy policy?
Data handling in the event of legal action. If the third party is sold or in bankruptcy, ownership and access to your data should still clearly belong to your organization. If a government authority requests access to your data while at the third party, you should be notified promptly.
Data handling upon termination. When you are done working with this third party, all of your data should be returned or destroyed.
Remote access and interconnections. Define which systems will be connected, who will be using them, what data will be moving in each direction, which security controls need to be set up on the connection (authentication, authorization, logging), and what the acceptable usage of the connection (no vulnerability scanning into your network without permission, no malware transfers). There should also be least privilege applied, no traffic allowed over the connection except what is part of the contracted obligation.
Code protection. If code is being developed by the third party for your organization, it should be protected from malware, loss, bankruptcy (with source code escrow), leakage, and malicious insider back doors. As the one most able to control these things, the third party should guarantee the code is protected from these threats.
Vulnerabilities. If severe bugs and security vulnerabilities are discovered in developed software, the third party should provide patches and mitigations in a timely manner (30 days). There should be a defined vulnerability reporting and support resolution process.
Breach and incident notification. Define breach (unauthorized access or alteration of your data) and the notification and remediation requirements for the third party. Who is going to pay for the damages both to your organization and your organization’s customers? How quickly should you be notified if the third party confirms an incident?
Penalties. What happens if any of these provisions are violated? One common response is the entitlement to injunctive relief, which means your organization can take this agreement to court and force the third party to stop whatever they’re doing (like sharing your data with marketers). Another response is financial penalties like the refund of payment for services or payment for damages. Lastly, there is termination of the entire agreement and therefore, relationship with the third party.
Technical Controls
Where third parties have access to your environments, technical controls can be very powerful in managing that risk. Technical controls are very useful when third parties are electronically connecting to your organization. This connection can be ad hoc, such as occasional remote access to perform contracted services, or it could be continuous via a network-to-network link. Technical controls can provide the verification of the access agreement.
Authentication and Authorization
Any users coming into your network should be authenticated and their access limited based on least privilege. This is even more important for users who don’t belong to your organization. If feasible, two-factor authentication should be used for third-party access. If this is access is infrequent or limited to a few occasions, then third-party users can be electronically escorted. This means having a system administrator use screen-sharing remote control tools to relinquish keyboard/mouse control. This way all of the third-party actions can be tracked in real time by a knowledgeable person. This is ideal for vendors and consultants who need quick temporary access for remote technical support. For even tighter control, the remote third party could be in read-only screen-share and instruct your people what buttons to press.
All authentication access attempts and failures should be logged and those logs reviewed along with everything else on a regular basis.
Network Controls
Chapter 17, which discussed network security, had a security policy that stated, “Network connections from customers and other third parties will terminate in a DMZ.” These are sometimes called extranet connections and should be firewalled and managed. These connections usually originate from a dedicated leased-line or a site-to-site VPN. Regardless, access control rules should be applied to the incoming connection to limit the connections from specified source addresses to specified destination addresses on specified network ports.
There are some situations where a vendor needs to put equipment directly onto your network. These are devices inside your perimeter that you do not have administrative control over. You can segregate these devices onto their own subnets or VLANs and manage access in both directions via a network access control list.
If you are allowing third-party network traffic into your network, you should monitor it. All of your network security monitoring tools can apply, including intrusion detection/prevention, network antivirus scanning, and digital leak prevention sniffing.
Vulnerability and Risk Monitoring
For third parties that have possession of sensitive data or direct links into your organization’s networks, you should ensure that vulnerability scanning of their network is done on a regular basis. You should require that the third party not be the one doing the scanning. Either they can contract with an independent scanning vendor and provide you with a report, or you can do the scanning yourself. These scans should be done at least quarterly and include an annual independent penetration test.
In addition to scanning for technical vulnerabilities, there are services that monitor third parties’ risk footprint on the Internet. They scan for the third party’s IP addresses and domains on various reputation lists as well as perform periodic configuration hygiene tests against the third party’s perimeter. Based on that information, they issue a rating on the estimated security strength of the third party. Here are three such companies who do this:
MarkIt
BitSight
Security Scorecard
Document Your Work
Like everything else, you should document this work. The standards, scheduling of testing, and the records of the third-party risk analysis are all part of your due diligence in keeping your organization safe. Roles and responsibilities for third-party tasks such as onsite reviews and reviewing scan results should also be documented. Third-party network connections should be diagramed with data-flows and controls noted. Lastly, a master registry of all relevant third parties with their services and risks defined should be kept and updated. All of these documents are important to external auditors.