Just boil the ocean.
—Will Rogers, American humorist,
A proposed solution to the threat of submarines (1917)
Scope, simply, is what you care about protecting based on what your compliance and risk analysis uncovers. The assets, processes, and personnel in the scope are where you focus your controls to reduce risk. Since it isn’t always feasible to defend all your assets from all the threats, scope answers the question about what must be protected. The following are some examples of scoped assets:
Cardholder data, financial transaction data, protected health information
IT systems storing, processing, or transmitting data under scope
Software running on those IT systems
Infrastructure supporting those IT systems
Facilities housing those IT systems
Personnel managing and operating those facilities and systems
Processes and procedures describing operations related to those facilities, systems, and personnel
Developing Scope
It is important that the scope developed accurately reflect the logical, physical, operational, and human factors of an organization. Furthermore, a scope with respect to audit has a time-dimensional component as well, referring to when things fall under scope. A good definition of the process comes from PCI DSS: “The process of identifying all system components, people, and processes to be included in a PCI DSS assessment to accurately determine the scope of assessment.”1
There are many factors that drive scope analysis within an organization. Certain industries, as discussed in Chapter 1, have specific compliance requirements they must obey that may mandate specific scope definitions. For example, a merchant accepting payment cards is required to have a PCI DSS scope. Sometimes scope encompasses an entire organization and sometimes it covers only a single business unit.
If your scope is not well defined and controlled, auditors can redefine the boundaries. You may have built a security program based on the assumption of a particular scope. If you missed something, an auditor could determine that your scope is incomplete— and that there are other things in scope that haven’t been protected. Worse, because of this oversight, you could be missing vital controls and oversight over those overlooked areas. For example, you limited your scope to a single set of servers that process and store payment cards, forgetting about the tape backup system that has copies of all the stored cardholder data. What if you didn’t set up proper access control or encryption on that backup system? Not only would you have an audit problem, but the cardholder data is at risk of exposure as well. A correctly defined scope can save you time and money because you can focus your efforts on the right things. An incomplete scope can turn an audit into a struggle if things that you didn’t expect to be audited suddenly did.
Scope is critical to the design of the IT security program because it shows where the work needs to happen. Scope also features prominently in most published audit reports. It is possible and sometimes desirable to have multiple scopes for different audits in the same organization. They can even overlap, as shown in Figure 6-1.
Figure 6-1. Overlapping scopes
The ultimate scope design depends heavily on the focus, boundaries, risks, and the compliance requirements of the organization. This necessitates a closer look at compliance requirements.
Compliance Requirement Gathering
If you don’t know the legal and regulatory compliance requirements that you are subject to, then it is very hard to define a scope. If you remember from the first chapter, there are a large number of possible requirements regarding IT security. I will not rehash them here, but instead focus on the three types of audits that this book covers.
The SSAE 16 SOC 1 covers the Sarbanes-Oxley legal requirements for publicly held companies. PCI DSS covers the payment card contractual requirements for organizations issuing, accepting, processing, or storing payment cards. Many compliance requirements can be satisfied with an SSAE 16 SOC 2/3 or an ISO 27001 scoped to the chosen services.
The products, services, locations, and processes in the scope can also be determined by customer requirements and contractual terms. For example, a Software-as-a-Service (SaaS ) company may be required to follow PCI DSS because one of its customers is using the hosted software to store cardholder data. The SAAS company did not set out to be PCI DSS compliant when it built its service offering, but a customer’s chosen usage model has brought their systems under scope.
Zero in on PII
After you’ve looked at your organizational, compliance, and customer obligations, then the next big thing to look at for scope is personally identifiable information (PII ). This is the private information that can be traced back to an individual. In many jurisdictions, PII usually originates with a full name plus some other confidential identifier. It can also include things like usernames and passwords. There are varying definitions of what is considered as private information, depending on standard, regulation, or law. In general, a single piece of information that distinguishes one individual from another can be considered an identifier. In some contexts, even things like telephone numbers, e-mail addresses, and facial photographs can qualify as confidential data that must be protected. When thinking about what to put in scope or not, consider how someone would feel if his or her information was published on your web site for all to see and index. If it would make a reasonable person angry and possibly litigious, you should consider putting that data into scope. The following are some examples to help figure this out.
Identifying information
Full name
Date of birth
Social Security number
Passport number
US state ID or driver’s license number
Personal information that when combined with identifying information can be considered PII
Date of birth
Personal identificat ion numbers (PIN)
Name of spouse or family members
Vehicle registrations
Bank account numbers
Payment card data
Spousal information
Children’s information
Military records
Religious preference
Gender
Race/ethnicity
Image of signature
Mother’s maiden name
Medical insurance number
Information that relates to an individual’s past, present, or future physical or mental health or condition, the provision of health care to the individual, or the past, present, or future payment for the provision of health care to the individual, and that identifies the individual or for which there is a reasonable basis to believe can be used to identify the individual.2 Any information an individual gives to related to a financial product or service, or related to a transaction involving financial products or services. Biometric data such as fingerprints, photographs, or voice recordings.
Things that might be considered in some jurisdictions as personal even though they are routinely shared openly or are available from public sources
Home telephone number
IP address
Home mailing address
E-mail address
Marital status
Employment history
Property ownership records
Place of birth
Educational history
Maiden name
Names of banks used
Things that would not be considered personal information
Work address
Work telephone number
PCI DSS scoping
The PCI DSS audit scope if focused primarily on payment card data and the systems and processes in place to protect it. This is pretty much everything associated with a payment card, both visible and invisible, which is referred to as the cardholder data environment (CDE ). Per PCI DSS, the data in scope encompasses cardholder data (CHD) and sensitive authentication data (SAD). Cardholder data includes the primary account number (PAN), which is the payment card number. Cardholder data can also include the PAN along with the cardholder name, expiration date, and/or service code.
Sensitive authentication data is defined by the PCI DSS as the “security-related information (including but not limited to card validation codes/values, full track data (from the magnetic stripe or equivalent on a chip), PINs, and PIN blocks) used to authenticate cardholders and/or authorize payment card transactions.”
In addition, PCI DSS requires you to protect the data scanned off the magnetic stripe. The tiny three- or four-digit code on the back of a card is used for authentication. Like a password, it must be kept so secure that it can never be saved in long-term storage (okay in memory, but never to disk).
Although not part of PCI DSS (since we are talking about payment cards), you should also be aware the printing the last four digits of the card number along with the card expiration date on a receipt is a violation of Fair and Accurate Credit Transaction Act (FACTA ).3
SSAE SOC 1 Scoping
Remember that the overarching goal is to curb fraud, misuse, and loss of financial transactions. Specifically, the SOC 1 report is intended to be an “evaluation of their internal controls over financial reporting for purposes of comply with laws and regulations such as the Sarbanes-Oxley Act and the user entities’ auditors as they plan and perform audits of the user entities’ financial statements.”4 This is why SSAE 16 SOC 1 audits are scoped for financial systems and the services that support them. Primarily, this scope covers products and services used by customers, and includes key systems, processes, and operations that affect those scoped products and services. Any messaging or workflow systems related to financials can also fall within scope, such as the system used for customer orders or the system used for purchase orders. Scope also includes any IT services pertaining to these applications, such as change control, backup, and software development. Any system that holds or processes significant financial reporting elements can cause a misstatement in financial reporting and is considered a material weakness.
Supporting Non-IT Departments
All of these types of audits pull the IT department into scope, but don’t forget the other departments. Departments that support key processes and controls may also be in scope. For example, since human resources is typically responsible for hiring and background checks, their processes need to be in scope. Call centers can easily fall into a PCI DSS scope if they are involved in taking, recording (both digitally and on audio), or looking up customer payment card numbers.
Double Check
One thing about making decisions on scope is that you should never proceed alone. Your legal department can also help. You may need to explain how the technology works and draw some diagrams, but working with legal can give you a better picture. Scope is also something that you should run by management and system owners before you finalize it. There may be specific business requirements that management will want to move in to (or move out of) scope that you didn’t know about.
Writing Scope Statements
The scope definition must be absolute and exact, as audits are built upon the scope statement. Since organizations can have complex and intertwined processes, the boundaries of the scope need to define exactly where the audit should stop, with the assumption that controls are in place to enforce boundaries. SSAE 16 and ISO 27001 auditors review the scope statement in meticulous detail. There should be no ambiguity in interpretation that could lead to audit or control gaps. Scope statements must be easily understood for ISO 27001, SSAE 16 audits, and PCI DSS Report on Compliance (PCI DSS ROC), since they are featured on the front page of the reports. The statement should include the business process or organizational units as well as the locations involved. Here are a few examples:
The information security management system for the protection of client information held in the file server systems operated by the Wichita office (ISO 27001)
The information security management system that supports and protects the confidential information related to the clients of Dewey Fleecem & Howe Attorneys at Law, stored at its domestic and international offices and business continuity sites (ISO 27001)
The global services for customer service centers located in Honolulu, Hong Kong, New York, Sao Paolo, Paris, and Mumbai (SSAE 16)
The hosted systems supporting the MYZER Financial System (SSAE 16) at all locations of Puget Regional Bank (SSAE 16)
The City of Gotham Department of Accounting Services and Computer Services’ IT environment (SSAE 16)
Control Inventory
The things that reduce risk to assets are controls. In an IT security program, controls are built to support control objectives, which are goals supporting the objectives. We’ll get more into control objectives later in the book. Right now, you need to know that controls are important in protecting scoped assets. It’s very helpful to understand the controls that you have already as you define scope.
There are a few ways to look at controls. There are administrative controls, which describe processes and policies; technical controls for IT systems; and physical controls. Another way to look at controls is their function: preventative controls try to stop a risk from occurring, detective controls alert when risk events occur, and corrective controls repair the impacts from risk events. You can map these all together, as shown in Table 6-1.
Table 6-1. Examples of Controls
Control Type | Administrative | Technical | Physical |
|---|---|---|---|
Preventative | Acceptable usage policy, change control policy, security awareness training | Antivirus software, firewalls, passwords | Door locks, security guards, fences |
Detective | Access rights review, unauthorized change reviews, audit log reviews | Intrusion detection systems, uptime monitoring, data leak detection | Burglar alarms, surveillance cameras, temperature monitors |
Corrective | Business continuity plan, incident response plan, NDA lawsuits | Back up tapes, failover ISP connections, laptop tracking software | Fire suppression, generators, exploding dye packs |
Control Effectiveness and Efficiency
Once you are satisfied that a control is operating consistently, another consideration is how efficient the control is. Efficiency is not a requirement for most audits, but it is a powerful concept for your security program. But what is good? A useful way to look at this is to examine control effectiveness and efficiency. Control effectiveness refers to both a control’s coverage (the amount of scoped assets that it covers) and its strength or stopping power. Some auditors think in terms of strong vs. weak controls. Usually, preventive controls are considered stronger than detective and corrective controls. Control efficiency is really control effectiveness divided by cost—or simply, the bang per buck.
How do you measure control effectiveness ? For technical controls, vulnerability testing and penetration testing can give you a good idea of what works and what isn’t working so well. Many of the resources in the last chapter can also provide hard data on control effectiveness. Here are a few organizations that publish analysis reports on the effectiveness of many technical controls and security tools.
Virus Bulletin ( https://www.virusbtn.com )
West Coast Labs ( http://www.westcoastlabs.com )
ICSA Labs ( https://www.icsalabs.com )
Your controls analysis is also important once you establish governance (explained in the next chapter) and you need to bolster or change controls to achieve your control objectives. You should document the results of your controls analysis, because it is an audit requirement for ISO 27001, as well as a good idea.
Scoping Adjacent Systems
Once you’ve defined on your scope, some systems and processes are clearly under scope while others may be harder to decide upon. For example, say you’re scoping a payment card–processing environment. Obviously, the servers and databases doing the actual card processing are in scope. However, is the storage area network providing the disk space for them in scope? Yes. Are the system administrator workstations? Yes, if they have direct access to the cardholder data environment. Is the corporate file server in scope? It could, if it is also on the same network as the storage area network in the CDE. Adjacent systems can fall into scope if they have unbounded access to systems in scope. An indirect path to the scoped systems is just as important as a direct path. The key is how you manage access to the scoped systems. If the pathway to scoped systems is access controlled, perhaps by a fingerprint-scanning gateway, then the scope can end at that gateway. Figure 6-2 is a diagram that illustrates this concept.
Figure 6-2. Scoping adjacent systems
Trace a line from a system; if it can touch the systems in scope unimpeded or with a key to the lock, then it’s in scope. If it’s not (shaded systems), then it’s out of scope. Notice how the system controlling the access and its supporting infrastructure are also in scope. This is a nuance that eludes some people, so remember that. If an unauthorized person can affect the access control system, then they could get access to the rest of the scoped environment. This is why access control systems must be controlled a s well.
Scope Barriers
Once you define a scope, you need to build a barrier around it and manage access. If you can’t erect a strong barrier, then detailed monitoring and logging can be used as compensating controls. If everything within the scope is so important that it needs to be protected, this implies that everything outside the scope is less important and not as well protected. Any unauthorized access or changes that happen outside scope should not be allowed to contaminate the scoped assets. This can get tricky when you look at how porous the scope barrier might need to be. Personnel, data, and requests for service could all pass back and forth through a scope boundary as needed. Controls need to be placed on all of these flows.
Technical Barriers
As we are dealing with IT systems, let’s look closely at the technical controls that you can use as choke points in a scope boundary.
Networ k Barriers
The most common scope boundary tools are network security devices. The ideal is air gap separation, where there is no connectivity at all between scoped systems and the other systems. Often this is infeasible. The most useful device here is a firewall, though this can get expensive when you need to segregate large numbers of systems with a lot of data flow. Virtual LANs (VLANs) that run off managed switches are a useful compromise. However, remember the scoping rules around access control infrastructure; the switches themselves fall under scope.
Logical Access Barriers
Authentication systems should be segregated across scope barriers. It can be very challenging to properly secure the same Active Directory (AD) tree for both scoped and non-scoped users. Remember that infrastructure supporting access control into scoped areas is also under scope. You will find it easier to have separate domains or AD branches for each trust zone. It’s best for you to use strong authentication into scoped zones, such as two-factor authentication .
Application Barriers
Logical access within applications is highly variable in terms of form and function. Nevertheless, the general rule is that administrative access to scoped applications must be controlled. This can mean either restricting administrative access to scoped or trained individuals, and/or only allow administrative access from controlled subnets. You need to control the ability to modify data or logs within an application as well. For scoped applications, even normal user application access should be subject to reasonable access controls, such as username and password. Automated data integration and feeds from sources outside of scope also need to be controlled; not only for authentication but also for the quality of the data. It’s helpful if applications push their data feed out from secured scoped zones, rather than requiring that untrusted clients pull data.
Combined Technical Barriers
Figure 6-3 is a simple diagram pulling all the technical controls into a single scope perimeter. You may notice that there are many firewalls in this diagram. They need not be physical appliances, but could be virtual firewalls or subinterfaces. The administrative access is done through jump workstations in their own segregated zone. Administrators authenticate to the jump machine and then move through into the scoped secure zone.
Figure 6-3. Example of technical barriers supporting scoped environments
Physical Barriers
There should be physical controls to separate scoped equipment as well. Sometimes the scoped hardware is already secured in a dedicated collocation facility. Otherwise, locking the server room door and controlling access to the keys can be done. In the case of shared server rooms, locking cages and racks can be used. Buildings on lower floors with windows are also a consideration. Don’t forget supporting infrastructure, so cabling and power should also have some physical controls protecting them.
Process Barriers
Just like everything else, you should control business processes as they cross the scope barrier. In Figure 6-3, you can see how two common processes are supported. One is change control, where administrators can use the jump workstations to pull code changes from code repository and then push them to the e-commerce servers. I cover more of this change control process in Chapter 13. The second is how payment data can be pushed from an e-commerce database to the payment database, with a final push to the accounting server. In general, you should be pushing or reaching out from the scoped environment, as opposed to having unscoped (and less trusted) machines pulling or reaching in.
Third-Party Process Dependencies
The most difficult processes to manage with scoped systems are processes involving third parties. In some cases, third parties can even be different divisions of the same organization that are not directly under the control of the group being audited. A common third party is the collocation company used to house the scoped equipment. In all of these cases, the requirement is to segregate them as much as possible by using the previously mentioned controls. Additional processes for managing risk with third parties are discussed in Chapter 23.
Scoping Hints
Although we have introduced some controls here, later chapters get into more detail on their implementation and uses. One thing to remember with scopes (and all security) is that you do your best and refine later. Over time, as successive audits and business cycles are run, you may want to change scopes and move scope barriers. That is natural and a good way to evolve your IT security program. This is covered more in Chapter 7, which focuses on governance.
Start Small and Expand
If possible, start as small as possible. It’s not always feasible or easier, but you can reduce scope by centralizing assets and departments. Look for redundancies and dispersed systems and see if you can consolidate them. It may also be possible to scope to one facet, location, or division of the business, and then build upon that after things are working. To do this, you may need to merge and split departments and personnel, which can be messy and complicated. However, some organizations realize some efficiency gains by restructuring to support dedicated departmental functions.
But Not Too Small
A scope that is too small can be more trouble than it’s worth, especially if you’re dividing an organization with firewalls and segregated processes. Sometimes it’s just easier to put an entire company in scope, wrap the barriers around the external perimeter, and go from there.
Simplification
You can reduce a scope by eliminating superfluous access. It sounds simple, but it can be difficult to take something away from someone that they’re used to having. For example, I have seen some organizations where the entire development team had full root access to all the servers. This put that entire team, and all their systems, in scope for audit. Removing that access immediately simplifies everything, if you can convince the development team they can still get their job done. If someone’s job doesn’t require them to have access, they should not have it. Even if they only require occasional access, perhaps some new process can replace the always-on access.
Sometimes after analysis, you may find some processes or systems that are too expensive to keep in scope. These could be systems with a wide surface area and are spread around everywhere. These could be fragile or immature functions that are difficult or expensive to secure and contain. These could be things that are distant and out of your direct control, yet you are still dependent on. There could also be things that are new or subject to rapid change, so they’re hard to pin down. The question to ask is whether you eliminate these processes all together. I have seen cases where companies ceased or modified a line of business when confronted with the high cost of securing them. Another way to eliminate a process is to outsource it, pushing the security and compliance requirements to someone else.
Footnotes
1 PCI DSS v3.2 Template for Report on Compliance,” Section 3, Description of Scope of Work and Approach Taken,
https://www.pcisecuritystandards.org/documents/PCI-DSS-v3_2-ROC-Reporting-Template.pdf
2 HIPAA Privacy Rule definition of protected health information.