The Official (ISC)2 SSCP CBK Reference. Mike Wills

Чтение книги онлайн.

СКАЧАТЬ “Reconnaissance by walking around” is a time-honored component of many an intrusion; it's even easier nowadays when smartphones can conduct full Wi-Fi surveys. Try it yourself, as part of an ethical penetration test.

      The Data Center

      As the focal point of the data assets of the organization, the data center is in particular need of protection within the property/facility. The data center also has some specific requirements that make it somewhat different than the rest of the production environment. In addition to the other access controls placed on secure areas within the workplace (discussed earlier in this chapter and in Chapter 5), security of the data center should include consideration of the following factors:

       Ambient temperature: IT components generally function better in relatively cold conditions; if the area is too hot, the machines will not function optimally. However, if the area is too cold, it will cause discomfort for personnel.

       Humidity: An interior atmosphere that is too dry will increase the potential for electrostatic discharge. An atmosphere that is too damp will increase the potential for development of mold, mildew, and insects.

      Standards for maintaining a desirable range of data center environmental conditions should be used to establish targets. One such reference is the ASHRAE Technical Committee 9.9 thermal guidelines for data centers; see http://ecoinfo.cnrs.fr/IMG/pdf/ashrae_2011_thermal_guidelines_data_center.pdf.

The data center should also be designed, constructed, and equipped for resiliency, such that it is resistant to unplanned outages from human error/attack, system/component failure, or natural effects. This is typically accomplished by including a great deal of redundancy within the data center. The use of design standards to achieve a significant level of robustness and resiliency is highly recommended.

      The Uptime Institute publishes a multitier standard for use by data center owners in determining and demonstrating their particular requirements and capabilities (“Data Center Site Infrastructure Tier Standard: Topology”; see https://uptimeinstitute.com/tiers). The tiers range in purpose and requirements from basic data centers that might be used for archiving or occasional data storage to facilities that support life-critical processes. The CISSP should have a cursory knowledge of the four-tier levels and their descriptions. (For more information, see https://journal.uptimeinstitute.com/explaining-uptime-institutes-tier-classification-system/.)

      The standard is free for review/guidance; certification against the standard is performed only by the Uptime Institute and requires payment.

      Organizations that receive Uptime Institute tier certification for their data centers can be listed in the Institute's online register: https://uptimeinstitute.com/TierCertification/allCertifications.php?page=1&ipp=All.

      Finally, fire poses a significant, common risk to data centers because of the high potential for occurrence and because of the disproportionately heavy impact a data center fire would have on the organization. The selection, design, implementation, maintenance, and use of fire protection and alarm systems can be quite complex, and in many jurisdictions must be undertaken by a properly licensed fire protection engineer. Municipal standards such as building codes also must be taken into account. Insurance providers may also levy strict inspection and compliance constraints on any and all fire protection systems and practices in order to maintain policy coverage. This all goes well beyond what the SSCP can or should attempt to take on.

      Service Level Agreements

      In the modern IT environment, there are many reasons (not the least of which is cost) for an organization to consider contracting with an external service provider to handle regular operational tasks and functions. To create a contract favorable for both parties in this sort of managed services arrangement, everyone involved must clearly understand what is being requested, what is being provided, what the cost is, and who is responsible for what. This is particularly important in what could be considered the most popular current form of managed services: cloud-managed services. In the majority of cloud-managed service contracts, the cloud provider and customer must determine the expected level of service, and the contract or service level agreement is the element that gives both parties the confidence to expect defined outcomes: assuring the provider that they will receive payment and assuring the customer that the service will meet the customer's needs.

In these cases, you need a formal agreement that defines the roles and responsibility of each party, explicit to the point where it can be easily understood and measured. The common name for this is the service level agreement. However, depending on the services provided, the agreement can go by other names, like network services agreement, interconnection security agreement, etc. The SLA is part of the overall contract but deals directly with the quantifiable, discrete elements of service delivery.

      These are scenarios where an organization might need an SLA:

       Third-party security servicesMonitoring/scanningSecurity operations center/response-type servicesMedia courier/media disposalPhysical security

       Hosted/cloudServersStorageServices

       Interconnecting information systems, especially with data feed/pull/push

       Supply chain scenarios

      The SLA portion of the contract vehicle is best limited to those elements of the managed service that are routinely provided as part of continual operational requirements; the SLA is not the optimum place for including contingency requirements (such as BCDR tasks) or for anything that cannot be distilled into a numeric value.

      Specific Terms and Metrics

      To be effective (and enforceable), an SLA must use clear and unambiguous language to specify its terms and conditions for all services that each party brings to the contract. Key performance indicators or other quality of service metrics should also be defined in the SLA, along with explanations as to how they are measured, computed, and reported. Without this, there is no basis for measuring or knowing whether a provider is providing the agreed level of service.

      Amazon Web Services (AWS), a well-known cloud service provider, uses a standard SLA for their Elastic Cloud Compute (EC2) services, which you can review at https://aws.amazon.com/ec2/sla/. Among other items, it specifies a server uptime metric:

       If your servers enjoy anything above 99.99 percent uptime, AWS has met its SLA.

       If your servers have anywhere between 99.00 and 99.99 percent uptime for the month, you will get a 10 percent discount on the service fee for that period.

       For anything less than 99.00 percent, you will get a 30 percent discount for your hosting for that month.

      This is a good example not only because the metrics and terms are clear but also because it is clear about what happens in the event of noncompliance with the SLA. The contracting manager (in conjunction with the organization's IT department) must determine whether the price reduction would realistically offset the loss in productivity a service outage would cause; if the cost of the outage outweighs the benefit of the rebate/discount, the SLA is insufficient for the customer's needs.

      Mechanism for Monitoring Service

      It is not enough, however, just to understand the terms of the СКАЧАТЬ