LITMIR.BIZ

Скачать книгу

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 SLA. You also need a mechanism with which to monitor and measure whether the service provided matches the level specified in the SLA.

      To continue with the previous example of AWS, visit https://status.aws.amazon.com/. You will initially see a dashboard similar to Figure 1.3. The horizontal rows represent the AWS regions. If you look at the corresponding region where your servers are hosted, you can see whether they are having, or have had, any degradation of service or outages.

       FIGURE 1.3 AWS dashboard

While this dashboard can be used to inform the customer as to the efficacy of the service overall, it might not provide, by itself, the level of assurance the customer desires; the information is necessarily coming from the provider, and the provider has a vested interest in the outcomes of the data (i.e., getting paid) and so is inherently biased. For such SLA elements, the customer may prefer some third-party validation of the service/data to feel confident that the reporting mechanism adequately reflects the actual level of service provided/received.

SUMMARY

      It's in the day-to-day details that you have the greatest opportunity to thwart an attacker from gaining meaningful insights about your information systems and then leveraging those insights to attempt an intrusion. It's in the day to day that you mentally, virtually, and physically patrol your perimeters, layer by layer, and stay in touch with the sensors and preventers that are working to keep things safe and secure. It's hard to keep a paranoid edge to your awareness; it's hard to avoid being lulled into a no-news-is-good-news complacency. One built-in advantage you have is that in a properly planned and executed security posture, the list of things you need to check up on is almost limitless: Boredom should never be your problem! Get curious, and stay curious, as you check with the badge readers and the other AAA elements of your access control technologies. Review what the security information logging and analysis systems are trying to tell you. Touch base with the help-desk people, with visitor control, and with all of the human elements that make your security strong—or break it, if left ignored and uncared for.

      Making information security into something that works effectively every day, every hour, is an operational and administrative task. It needs you to manage it by physically and virtually walking around. Think like a hacker; turn that thinking into ideas for ethical penetration testing, even if only on paper or sitting around a conference table with people from other functional areas in your organization. Hear what they say, and help them grow the security culture you all need to enjoy and be safe in.

CHAPTER 2 SSCP^® Access Controls

      IDENTITY MANAGEMENT AND ACCESS control are two sides of the same coin. Attacks on your systems happen because there are exploitable vulnerabilities in your systems that allow the attacker to bypass your identity authentication and access control processes. Once inside your systems, other access control failures (be they physical, logical, or administrative) allow the attacker to exfiltrate data, corrupt your systems, or use your systems as the launching pad for attacks on other parties' systems.

      Unfortunately, most intrusions are not discovered until months after attackers have already taken copies of your data and left your systems. If you've kept good records of all access and connection attempts, you may be able to identify what data has been lost or changed; if not, you'll probably not learn about the data breach until your lost data is found somewhere on the Dark Web.

This chapter provides you a detailed, operationalized guide to implementing and benefiting from an integrated identity management and access control system and process. In doing so, it makes extensive use of confidentiality, integrity, availability, nonrepudiation, authorization, privacy, and safety (CIANA+PS) as a way to focus our attention on the total set of an organization's information security needs. CIANA+PS starts, of course, with the CIA triad of confidentiality, integrity, and authentication, as is addressed in Chapter 1. This total set of attributes focuses our attention on the vital importance to business (and in law) of having highly reliable, auditable, and verifiable control of access to information assets and the systems that support them.

Скачать книгу