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.
The CIANA+PS set of needs illustrates why information security and assurance is much more than just cybersecurity. Cybersecurity focuses intently upon the information technology aspects of keeping computers, networks, data centers, and endpoints safe, secure, and reliable. That focus on the technologies of the information infrastructure is important; it does not, however, provide much assistance in designing business processes for cross-organization collaboration that provide the appropriate assurance to each party that their knowledge, information, and data are safe and secure. Information assurance is about information risk management, which Chapter 3, “Risk Identification, Monitoring, and Analysis,” will address in more detail. Chapter 3 will also emphasize the use of physical, logical, and administrative means by which vulnerabilities are mitigated. Maintaining and operating those information assurance processes almost invariably requires a significant degree of attention to the human-facing procedural details, many of which are involved in how information systems and the IT they rely upon are managed; this is addressed in Chapter 1, “Security Operations and Administration,” as well as in Chapter 7, “Systems and Application Security.”
This chapter, however, deals almost exclusively with the logical means of implementing identity management and access control. These logical means will involve management making decisions that establish organizational and local policies and procedures, which will be addressed here in context, but I'll leave the physical restriction of access to computing and communications hardware to Chapter 7.
ACCESS CONTROL CONCEPTS
Access control is all about subjects and objects (see Figure 2.1). Simply put, subjects try to perform an action upon an object; that action can be reading it, changing it, executing it (if the object is a software program), or doing anything to the object. Subjects can be anything that is requesting access to or attempting to access anything in a system, whether data, metadata, or another process, for whatever purpose. Subjects can be people, software processes, devices, or services being provided by other web-based systems. Subjects are trying to do something to or with the object of their desire. Objects can be collections of information, or the processes, devices, or people who have that information and act as gatekeepers to it. This subject-object relationship is fundamental to your understanding of access control. It is a one-way relationship: objects do not “do anything” to a subject. Don't be fooled into thinking that two subjects, interacting with each other, is a special case of a bidirectional access control relationship. It is simpler, more accurate, and much more useful to see this as two one-way subject-object relationships. It's also critical to see that every task is a chain of these two-way access control relationships. It's clearer to see this as two one-way trust relationships as well.
FIGURE 2.1 Subjects and objects
As an example, consider the access control system itself as an object. It is a lucrative target for attackers who want to get past
