Ch6B.pdf Governance and Risk PDF

$PNQ5*"¡$MPVE&TTFOUJBMT 4UVEZ(VJEF 4FDPOE&EJUJPO By 2VFOUJO%PDUFSBOE$PSZ'VDIT $PQZSJHIU¥CZ+PIO8JMFZ4POT *OD Chapter 6 Governance and Risk ✓✓ 4.1 Recognize risk management concepts related to cloud services Risk assessment Asset Inventory Classification Ownership Risk Response Mitigation Acceptance Avoidance Transfer Documentation Findings Risk register Vendor lock-in Data portability ✓✓ 4.2 Explain policies and procedures Standard operating procedures Change management Resource management Security policies Incident response Access and control policies Department specific policies Communication policies Compliance is a word that can make people groan in annoyance or that they ignore with apathy. Most seasoned IT professionals view compliance requirements as busywork or just documentation. They feel it takes time away from real work. However, for large organizations and for any organization in certain fields (banking, healthcare, insurance, manufacturing, government, etc.), compliance is critical to operations. Being in compliance requires actions by individuals and/or organizations that are aligned with laws or regulations imposed by regulatory agencies. These actions can come in many different forms: documentation, policies, procedures, forms submissions, and board reviews, to name a few. We will be discussing several of these and giving examples in this chapter. Any cloud plan will require some compliance knowledge. Compliance helps protect organizations and individuals from civil and criminal liabilities. This isn’t something that can be ignored or done later. Compliance audits are time sensitive and must be performed annually. Payment Card Industry Data Security Standard (PCI DSS) PCI DSS is an example of a compliance requirement that is dictated not by law but by contractual obligation. It governs the security of credit card information and is enforced by agreements between businesses that accept credit cards and banks that process the transaction. PCI DSS is a requirement of all the major credit card vendors and administered by the Payment Card Industry Security Standards Council. So, any organization that wants to issue a credit card, process a transaction using a credit card, or accept credit cards as a form of payment must follow the 12 PCI DSS requirements: Install and maintain firewall configuration to protect cardholder data. Do not use vendor-supplied defaults for system passwords and other security parameters. Protect stored cardholder data. Encrypt transmission of cardholder data across open, public networks. Protect all systems against malware and regularly update anti-virus software or programs. Recognize Risk Management Concepts Related to Cloud Services Develop and maintain security systems and applications. Restrict access to cardholder data by business justification (i.e., “need to know”). Identify and authenticate access to system components. Restrict physical access to cardholder data. Track and monitor all access to network resources and cardholder data. Regularly test security systems and processes. Maintain a policy that addresses information security for all personnel. 217 You will not need to know the 12 requirements for the certification exam. They are listed to show an example of a compliance requirement for processing credit card information. You will need to know that PCI DSS stands for Payment Card Industry Data Security Standard and that it is required. You can read more about PCI DSS and get more details at https://www.pcisecuritystandards.org. Recognize Risk Management Concepts Related to Cloud Services The major underlying theme of this chapter will be risk. CompTIA offers another certification that is security focused: CASP+ (CompTIA Advanced Security Practitioner). Sybex has a Study Guide for the CASP+ certification where risk is defined as the probability or likelihood of the occurrence or realization of a threat. The key words are probability and threat. Probability is the chance or likelihood that something might occur. We will use the defi nition of threat from the same book: A threat is any agent, condition, or circumstance that could potentially cause harm, loss, damage, or compromise to an IT asset or data asset. The likelihood of the threat is the probability of occurrence or the odds that the event will actually occur. Agent, condition, or circumstance: these are either individual(s) or events. Harm, loss, damage, or compromise: these refer to any kind of loss of value. The last key term from this defi nition is asset. 218 Chapter 6 Governance and Risk Asset An asset is an item of value to an institution such as data, hardware, software, or physical property. An asset is an item or collection of items that has a quantitative or qualitative value to a company. Quantitative and qualitative will be covered in the section “Risk Assessment.” To put it another way, risk is the probability that some sort of harm or damage will occur to an asset. An asset is anything that is of value to a company or organization. In the most general sense, an asset does not have to just be an IT item. Employees are also an example of an asset. Additionally, harm or damage can be generalized to be a less than ideal state of the asset, e.g., service being inadvertently turned off. In this section, we are going to discuss strategies and methodologies to manage risk. Instead of talking about risk by definition or abstractly, let’s give a few examples of both IT-related risk (Table 6.1) and non-IT-related risk (Table 6.2). Ta b l e 6.1 IT-Related Risk Risk High probability of employees unintentionally interacting with malware in today’s connected workforce. Employees digitally interact with others via email, sharing of files, or web pages. Threat Immediate harm would be loss of company data and files. Secondary would be loss of employee time—both the employee who became infected and the IT employee’s time to recover the company’s data and the employee’s infected device. Asset Company data and employees Ta b l e 6. 2 Non-IT-Related Risk Risk High probability of car being stolen if parked in a busy parking lot with keys lying on the front seat Threat Immediate loss of vehicle and potential damage Asset Vehicle You most likely have dealt with these risks before and haven’t thought much about them. You already have a risk response in mind for either of these examples: install anti-malware and lock your car. Realize that you deal with risk every day and you already have built-in Recognize Risk Management Concepts Related to Cloud Services 219 responses. We want to expand on that and apply similar techniques to new risks that come with going to the cloud. We will be discussing risk response later in this chapter. Risk Assessment Now that we have an idea of what risk is, let’s talk about how to assess the risk. When we measure risk, we are talking about risk that can affect assets. So, we need to explore and understand assets more. Assets are any items that have value to a company. This value is measured through either a quantitative risk assessment or a qualitative risk assessment. Quantitative risk assessment deals with dollar amounts. It attempts to assign a monetary value to the elements of risk or the assets themselves. Qualitative risk assessment deals with the quality of risk or assets. It will rank the threats based on experience, intuition, or a specific scenario. Quantitative is the most intuitive because it has a dollar amount attached to it. For example, a laptop costs $1,200 new. If it is lost or stolen, it easy to do the risk assessment on the hardware. However, that $1,200 is not the complete picture of the asset’s value. What about the data that is on the laptop? Let’s say that laptop was used by the director of marketing for a company. On that laptop there were all the slides and marketing material for the go-to-market strategy for the coming year. Those materials took employees time to produce. Maybe that work was tracked, and we could place some quantitative assessment on the work. We could probably put a monetary value on replacement or redoing the work. So, the quantitative risk assessment for this laptop has now increased in value. We are not done with our risk assessment of our laptop. What if the laptop was stolen by a competitor of the company? What if the competitor learns the new go-to-market strategy and they get a jump on the strategy? The competitor could execute a similar strategy or a strategy that effectively renders your company’s strategy mute. What is the cost to the company now? This is where qualitative risk assessment comes into play. The only way to assess this risk is based on the experience and intuition of experienced people. Since the assessment is based on a person’s perception, we need to have a way of measurement, which is the difficult part. The best way and really the only way of measuring qualitative risk is comparison or ranking. Measuring the risk of a competitor learning your strategy is difficult, but we could compare it or rank it against other components of quantitative analysis. At the core of this risk analysis is the asset. Before we explore assets in depth, we need to define two topics that are critical to the assessment process: value and threat. We will be discussing these two topics throughout this chapter, and they are critical to understanding risk. Value is typically thought of as monetary or quantitative, but it is not limited to monetary value. An asset can have a higher value than other similar assets if it is critical to the functioning of a business. As an example, think of an ice cream truck. All the ice cream obviously is an asset and has a monetary value. However, the ice cream truck itself would be considered more critical than the ice cream because all the ice cream would melt and be ruined without a functioning ice cream truck. Additionally, the ice cream itself cannot be thought of just in terms of the monetary value of its purchase. Ice cream in this case also has revenue value. 220 Chapter 6 Governance and Risk We have defined threat previously, but we need to add a new term that is often confused with threat, vulnerability. Vulnerability is a threat, but not all threats are vulnerabilities. A vulnerability is attached to a specific asset. Vulnerabilities are threats to assets that have not been mitigated. We will be discussing mitigation and other risk responses later in this chapter. We need to know which assets we have. Asset Inventory Before we can secure or protect any asset, we need to know what we are going to secure or protect. This is where an asset inventory becomes essential. Many organizations lack an accurate and timely inventory of their assets. By timely we mean accurate inventory when timing is important. Think of a scenario where a fire broke out at a warehouse. Would the organization have an accurate head count and the names of the individuals in the building? This information is needed quickly and needs to be accurate. Broadly, assets can be broken into two categories: tangible or intangible assets. Tangible assets are assets that can be appraised with a monetary value. Intangible assets cannot be directly appraised with a monetary value. These have a close parallel to qualitative assessment and quantitative assessment. For the sake of brevity, we are going to keep our discussion of assets to hardware, software, and data. Hardware vs. Software and Physical vs. Virtual Typically, people think of hardware as being something physical, i.e., something you can touch. The cloud and virtualization have blurred this definition. Simply, is a virtual server that you spin up in the cloud or in your own data center considered hardware? Well, it isn’t physical and not as straightforward to define. The answer is a little muddied, but the short of it is this: Software has the properties of not being physical and performs a specific function. Software is created by a software developer. A VM emulates hardware even though it is not physical. It is not an application that is created by a software developer. The hypervisor that runs the VM is software, but the VM is considered hardware. It may sound counterintuitive to say that hardware has a dependency on software. However, hardware that you typically consider a physical hardware device still depends on software to run, e.g., a firewall or router. The majority of cloud resources that you create will be considered hardware even though they are not physical, i.e., VMs, networks, databases, etc. CSPs are making a push for managed services, i.e., database as a service, Docker as a service, etc. This blurs the line even more, and some instances are considered software. Additionally, SaaS applications like Office 365 or Google Suite are considered software packages. Recognize Risk Management Concepts Related to Cloud Services 221 Hardware Hardware on the surface should be easy to track. A hardware device can be seen or touched or can be scanned once it registers with the network or our cloud management console. Organizations will use databases or automated applications to perform inventories and track hardware through its life cycle. If you look at your company-provided machine or phone, there is probably an asset or property tag, as shown in Figure 6.1. This tag will have a unique number for the organization on it that identifies it within a database. F ig u r e 6.1 Example of a property tag In Chapter 3, we discussed reporting on virtual hardware. CSPs offer three categories of virtual services: compute, storage, and network. These virtual items cannot be seen, touched, or property tagged. We need to come up with some other mechanism to inventory these items. Fortunately, almost all CSPs provide some means of inventory. The larger CSPs will offer move advanced inventory mechanisms. Software Software by its nature is more difficult to inventory than hardware; it is not physical. Inventorying software is just as important, if not more important. An inaccurate software inventory can have significant financial impact and security risk. It is important that software inventory be accurate and up to date. Otherwise, unlicensed software can and will be used in an organization. Unlicensed software can have significant financial impact on an organization. Risk can come from multiple sources, but the most common are unpatched software and software audits. Modern software for patches and updates has to be online to download the patches. The software vendor will check for a valid license either before allowing the download or before the installation of the patch is allowed. An unpatched software package is inherently vulnerable to exploitation and attack. This vulnerability is a threat. We discussed vulnerabilities and threats previously. Remember our definition of risk; unpatched software increases the probability of harm or damage to an asset. Periodically major software vendors perform software audits. These audits typically start as voluntary but can become compulsory if ignored. In short, if a software vendor decides to perform a software audit, there will be a smaller risk if you perform it rather than ignore it. The software audit will come in one of two flavors or a combination of the two. First is self-reporting. The software vendor will ask how many installations 222 Chapter 6 Governance and Risk of software X you have. Second is some sort of licensing manager check. The software vendor will run a check against either an internal or external-based licensing manager; i.e., you purchased 100 installations of software X, but the licensing manager is reporting 150 installations. This gap in proper licensing is a risk that has monetary impact. The software vendor will require a true-up, a realignment of purchased software to actual. However, the software vendor may also require payment for software that was used in the past. Organizations need to have an accurate software inventory and have controls in place to either audit or prevent unapproved software installations. Software Editions Impact Licensing I worked for an organization that needed to purchase several hundred licenses of Microsoft Visio and Project. It was determined through use-case scenarios that Visio Standard edition was enough to the meet the use-case requirements. However, Project Professional edition would be required to meet the use case. The order was put through, but when it came back, the license editions got flipped. The license count was for Project Standard and Visio Professional. No one noticed, and the IT department installed the software based on user requirements, i.e., Visio Standard and Project Professional. This went on for several years, and the error was never recognized or corrected. Microsoft did a software audit several years after the original purchase. The organization reported correctly the hundreds of Visio Standard and Project Professional installations. Microsoft found the organization to be out of license compliance and issued a new bill for the use of Project Professional installations when only Project Standard was licensed. Unfortunately for the organization, because of the age of the original purchase, we could not prove that it was an error on Microsoft’s part or on the organization’s original order. We were able to negotiate with Microsoft and get some relief from paying the full price of the difference, but there was still a monetary impact. Data Data, when discussing assets and risk, is the broadest and most diverse topic. We need to make a distinction between data and information here, because they are often confused. Data is in raw format. Information is collated and categorized data. For example, the number of units sold of a particular product in the last quarter would be considered data. However, the comparison of units sold last quarter to those sold in the same quarter of the previous year would be considered information. We are going to discuss the inventorying and risk of both data and information. There will be overlap between the two, but we will call out the difference when necessary. Recognize Risk Management Concepts Related to Cloud Services 223 In general, information has a higher value placed on it than data due to its meaning. Information is processed data and has greater value. Another difference between data and information is use. Business processes is an example of information that is not derived directly from data. Business processes are based on data. Classification We have our assets inventoried with their values. We need to add the other part of the risk definition, which is threat. We will discuss the difference between threat and vulnerability later in this chapter. It is easier to understand risks and formulate the appropriate risk response if they can be grouped with similar risks. Once grouped, the risks can be ranked according to the likelihood of the realization of threat or the asset’s value. This ranking of risks becomes its own classification. Risk classification systems come in one of two flavors: grades (A, B, C, D, F) or a scale from 1 to 5. The systems are interchangeable and function the same way. The goal of the classification is to help determine the appropriate risk response or appropriate level of security to provide to an asset. One should never spend more on resources to protect an asset than the value of the asset itself. There are two parts of the classification: asset value and the probability of a threat occurring. These two parts will help produce the risk classification for the asset and threat. The higher the asset value and the higher the probability of a threat occurring, the higher the risk classification, e.g., level 5. Lower asset value and lower probability of a threat occurring will mean a lower risk classification, i.e., level 1. The balancing act and the middle ground is where you have an asset of high value but low probability of threat, or an asset of low value with a high probability of threat. Your organization will need to come up with policies on how to handle the middle classifications, but being able to compare one risk to another risk will assist greatly. Table 6.3 shows a few examples to help clarify how an organization might set up their classification system. Ta b l e 6. 3 Example Classifications of Risk Asset Threat Classification Level Data center Loss of network connectivity 5 Company vehicles Theft from parking garage 4 Office supplies Used for non-business-related projects 2 Laptops and mobile devices Loss or theft by or from remote employees 3 Office space Loss of power 1 224 Chapter 6 Governance and Risk Obviously, different organizations would give different classifications. Some might classify loss of a laptop at a higher level than the loss of a company vehicle because of the likelihood of recovery or not. A company vehicle is less likely to be stolen and more likely to be recovered than a laptop. A manufacturing company that produces its product at an office space would rate loss of power higher than an accounting firm might. The accounting firm could relocate required staff or have them work from home. The production would stop for the manufacturing firm and could not resume until power was restored. Each organization has to determine its own classification system and criteria. The ranking or grading, though, becomes important when determining appropriate risk response. This risk response will be determined by the risk and asset owners, our next topic. Ownership Ownership is a critical concept and role when it comes to risk management. There are two roles that need to be identified when discussing ownership: risk owner and asset owner. In smaller organizations, the same person can play both roles, but in larger organizations, they are often different people. Let’s take a deeper dive into each role. Risk Owner The person who takes on the role of risk owner needs to be in a management position. The risk owner is going to be the individual who will decide and assume the risk response for the risk they are owning. We will be discussing risk response in our next section. The importance of the risk owner being part of management cannot be overstated. Remember, risk is a function of management; it is not a function of IT or technical services. Risk must be managed as a whole from the organization top down, not the bottom up. The risk owner is often a department head or a director and is someone other employees report to. The risk owner will have a larger picture view of the organization and have management-level knowledge to make informed decisions when choosing an appropriate risk response. They report to upper management and in layman’s terms the “buck stops with them” when it comes to risk response and outcomes. An example of a risk owner for a larger organization would be VP of cloud services. As you can surmise from the title, they would be responsible for everything having to do with the cloud, including all IaaS, PaaS, and SaaS offerings. For a large organization, this individual would not be able to have the technical expertise or the background to be the asset owner for all the cloud offerings. However, the risk owner would have the managerial experience and expertise to rely on asset owners to make informed risk response decisions. Asset Owner An asset owner may be known by several different names, depending on the asset: product owner, data owner, or information owner. A product owner is someone who has extensive knowledge or background in the product or data they own. An asset owner is responsible for the execution and operation of the software or systems that control and manage assets. Recognize Risk Management Concepts Related to Cloud Services 225 An example could be someone who owns a cloud SaaS product like Office 365 for an organization. The product owner should have training, skills, and experience to provide guidance to the risk owner. The product owner provides advice and counsel to the risk owner in order for them to make an informed decision about risk response. In smaller organizations, the risk owner and asset owner are often the same individual, and a single person can be the risk and asset owner of multiple assets. A CTO or CIO of a small organization may own all the technology and risk assets. Risk Response Once assets have been inventoried and classified and ownership has been determined, the owners can use the risk assessment to determine their risk response. We need to bring up an important concept when it comes to risk response. We should never exert more effort or pay more or expend more resources than the value of the asset itself. This is where an asset’s value becomes important. For example, we should not spend the money and resources for 24-hour armed security guards and biometric scanners to secure a server that is worth only $5,000. The level of securing must be dependent on the value of the asset. This is where the quantitative and qualitative analyses we performed earlier become important. This also goes back to our classification of risks. In general, there are four responses to risk: mitigation, acceptance, avoidance, and transfer. We will be discussing them each individually. Mitigation Risk mitigation is the most common response to risk. In short, mitigation is the act of reducing risk through the expenditure of resources of the organization. An organization is going to invest in either technology or staffing to lower the probability of the realization of the threat against its assets. Firewall, anti-malware, proxies, and identity management are all examples of risk mitigation responses. They all require an investment from an organization, and their purpose is to lower the probability of threats against assets. This is by no means an exhaustive list, but you get the idea. Mitigation strategies are usually technological in nature in that they entail hardware or devices to implement. Simple locks on doors help prevent the theft of assets from your home or place of business. Do you lock your car when you park? What is the reason for locking your car? If you park your car farther away from the store where no other cars are parked because you don’t want your car to get dinged by other cars, that is an example of risk mitigation. The expenditure of resources is the longer walk and increased time. CSPs offer several mitigation responses, and most of these strategies are included or enabled by default. None of the CSPs allow network traffic from the Internet to resources by default. You must enable or allow traffic from outside your network or the CSP’s network inside. This is in the best interest of the CSP as well. Threats against your resources are 226 Chapter 6 Governance and Risk partial threats against their resources. CSPs have taken additional risk mitigation responses that you may not be aware of. They have specialized hypervisors that isolate resources and help prevent “runaway” use of their resources. The shared responsibility model that we discussed in Chapter 1 is the framework for risk response from both the CSP and you. Acceptance Risk acceptance is similar to mitigation in that the organization is going to handle the risk themselves. The critical difference is that the organization will not expend any resources on the risk. The organization is accepting the probability of the threats against the identified assets as is. Acceptance is the “do nothing” response to risk. Management has decided to self-insure. The reasons why the organization chooses acceptance over the other risk response falls into one of two categories: either value of the asset or probability of the threat. If the value of the asset is low enough that damage or loss is not significant, then cost of replacement is not significant. If the probably of a threat is very low, then it can be effectively ignored. A couple of examples will help clarify risk acceptance. A bank with pens in the lobby that anyone can use and take is an example of risk acceptance. The pens’ value is so low that the bank accepts the probability of occasional theft. Almost every occurrence of an asset being treated as a commodity or disposable is risk acceptance. An organization deciding to take no protective action on employees’ Internet usage is an example of risk acceptance. Internet filtering technologies can be expensive, and for smaller organizations, it may not be cost-effective to filter and/or monitor Internet usage. The organization is relying on reactive measures as responses to any risk that become realized from inappropriate Internet usage. Avoidance Risk avoidance would be the preferred risk response for every risk manager. The risk is nullified, and no damage or loss of an organization’s asset will occur. However, in the real world, risk avoidance is the rarest and hardest to attain. Risk avoidance is where the probability of a threat is eliminated or reduced to zero. The threat is removed or the chance of the occurrence no longer exists. Moving a data center from an area that is prone to natural disasters is one example of risk avoidance. If you look at the major CSPs and the regions discussed in Chapter 5, none of the regions is in a high natural disaster area. Amazon and Microsoft did not build their eastern data centers in the areas of high hurricane occurrence. AWS Data Centers AWS has an interactive web page that introduces the workings of its data centers. https://aws.amazon.com/compliance/data-center/data-centers/ It covers a lot of the topics discussed in this chapter. Recognize Risk Management Concepts Related to Cloud Services 227 The difference between risk mitigation and avoidance can be difficult, because resources are typically expended to avoid a risk entirely. The expenditure of the resources would typically indicate mitigation versus avoidance. The difference is that most mitigation responses only lower the probability and don’t eliminate it. Transfer Transfer is the last risk response we will discuss. When an organization transfers all the risk from itself to a third party, that is risk transfer. Insurance is the largest example of risk transference. Think of homeowner’s insurance; you pay a third party a monthly fee. In return, the insurance company will make a large payout to you if your home is damaged. Your average homeowner cannot self-insure (risk acceptance), because they already have a mortgage out on their home; i.e., they couldn’t replace their home if it was destroyed. Organizations utilize risk transfer all the time through purchase of third-party insurance: fire, flood, property, liability, etc. Insurance is not the only example of risk transfer. Organizations will often realize that they need third-party technical expertise to achieve their technical goals. They will often reach out to consultants and rely on their expertise. Organizations will hire these consultants on a temporary basis to complete a specific set of steps that are specified in a statement of work. Lastly, using CSP services is an example of risk transference. You are paying the CSP for services, and in turn they are accepting the risk of maintaining the infrastructure that you are “virtually” using. The shared responsibility model details which risks the organization is transferring to the CSP and which they still need to mitigate or accept. Documentation Documentation is a word that can strike fear and pain into IT professionals. It isn’t entirely their fault. Most IT professionals are tasked with building or creating something that hasn’t been done before. So, they spend a lot of time trying different things, with a lot of trial and error. When they finally come across the solution and are able to implement it, the question becomes what to document. Do they really need to document the 99 things they tried that failed or only the one that was successful? The answer is somewhere in between, but you can see how documentation in general is not something that is enjoyed. The first thing that needs to be documented is anything that is required by law or regulation. We discussed this previously in this chapter. Looking at the 12 requirements of PCI DSS, all of them will require some level of documentation to prove compliance. Any publicly traded company will have SEC documentation requirements that must be met. Next, the items that need to be documented are anything that is required by an organization’s policies and procedures. Any documentation that is required by law or regulation is most likely covered by policies and procedures. However, there will be documentation requirements spelled out in policies and procedures that go beyond laws and regulations. Policies and procedures written in response to risk realization events are a good example. We will be talking about risk realization events in the next section. For now, understand that when a risk event occurs or when damage occurs against an organization’s asset, we need to perform a findings documentation. 228 Chapter 6 Governance and Risk Findings Findings are the documentation of a risk event. When a risk event occurs, an investigation is typically warranted. This investigation may be brief or may take months, depending on the circumstances. Investigations may involve third parties and even law enforcement. Investigators are tasked with determining whether proper procedures were followed or whether there is a gap in procedures to handle the event(s) that occurred. Since findings are the product of an investigation, we will break down the four general investigation types in Table 6.4. Ta b l e 6. 4 General Investigation Types Type Details Criminal Investigations are typically conducted by law enforcement. The goal is to produce evidence that can be used by law enforcement or counsel. Proper chain of evidence (chain of custody) procedures most be followed. Criminal cases must meet the beyond a reasonable doubt standard. Civil Investigations typically do not involve law enforcement and are conducted internally by an organization. They may involve legal counsel, but the human resources (HR) department will be involved. Civil investigations have a lower standard than criminal, called weaker preponderance of evidence. Proper chain of evidence procedures should still be followed but are not a strict requirement. Regulatory Investigations are performed by either government officials or regulatory body personnel. Investigations are different from audits. Audits can occur at any time and are performed to meet compliance requirements. Investigations occur after a risk event occurs. Investigations will often perform the same steps as an audit but will also dig deeper into the procedures that relate to the risk event. Operational Operational investigations are the most common and the investigations you are most likely to run into as IT professionals. The goal is to resolve operational issues that occur from email phishing attempts, malware outbreaks, deleted files, etc. There are no evidentiary requirements unless spelled out in policy. A lot of your dayto-day tasks could fall under this type of investigation. Whatever type of investigation you are performing, the ultimate goal is to provide the findings of the investigation to management. Management takes these documented findings and will help direct policies and procedures or change the risk response in the future. If the findings uncover a new risk or if a previously known risk is changed, then the information needs to be entered into the risk register. Recognize Risk Management Concepts Related to Cloud Services 229 Risk Register A risk register is the documentation of every risk that has been identified by an organization. It lists all risks for management to evaluate and determine the best risk response. ISO 73:2009 defines risk register as a record of information about identified risks. The register allows management to look at all the risks that have been identified as a whole. This allows for a more holistic approach and response to risk. For example, firewalls are a standard risk mitigation response to the risk of having servers connected to the Internet. If management was siloed into individual departments, then each department may determine the need and purchase their own firewall. This response not only is a waste of resources but can lead to fragmented configurations across the organization. The auditing and management of several disjointed firewalls becomes harder and more timeconsuming. With every identified risk in one location, more informed risk responses can be implemented. Risk registers come in many different forms, and the form is determined by management preference and number of risks identified. If you search online for risk register examples or look at most risk management textbooks, the example given is a scatter plot. Each axis will have either probability or impact. However, these are hardly ever used in real life. If an organization is attempting to list all identified risks, then the scatter plot would be too large or the dots would become meaningless. Risk registers in the real world are often filled in using Excel. They resemble more of a log entry than a scatter plot. Each identified risk has its own row or multiple rows. The columns help categorize and group identified risks. With enough details, management can sort and filter on the information. The organization determines the individual columns, and they often change. However, almost all risk registers contain the information shown in Table 6.5. A lot of the terms should be familiar. Ta b l e 6. 5 Example of risk register entry Column Description ID Identifier that is unique to the risk Description Description of the risk at a high level, e.g., newspaper headline Threat Details the threat or the vulnerability of the asset(s) Impact Nature of the risk and harm or damage to assets Assets List of assets that are affected by the risk Likelihood Probability of the risk occurring Grade/Level Either numerical or alphabetical representation that allows comparison to other risks 230 Chapter 6 TA b l e 6. 5 Governance and Risk Example of Risk Register Entry (continued) Column Description Owner Names of the risk and asset owners Response Details of the chosen risk response Date Created Date of the original risk identification and addition to the risk register Change Log Any changes made to the identified risk and what those changes were Date Modified When changes were made to the risk register, the date the changes occurred for the risk Management may want to have more columns, but the 12 listed are in almost all registers in one form or another. Ideally you recognize the terms, and you can see we have been building on these ideas throughout the chapter. False Sense of Security with Risk Registers Risk registers have a downside once they become large, as they tend to in organizations. Management can become complacent and believe that all risks are in the register. This leads to tunnel vision where management only sees the risks that have been identified. Obviously, this becomes very dangerous. There will always be new risks, especially when working in the cloud. Vendor Lock-in Vendor lock-in is a risk that existed for organizations well before the cloud. The cloud has resurfaced this risk, and organizations need to choose the appropriate response that aligns with their strategies. Vendor lock-in is the difficulty of switching from one vendor to another because of proprietary hardware or software provided by the vendors. One can argue that we should just use open standards (hardware and software that any vendor can produce). However, the reality of the situation is that the leading vendors are leading because of their IP. This IP is what makes them leaders in the industry. Vendors cannot protect their IP unless they use proprietary hardware and software. Corporate America embracing Open Source It is not an absolute that organizations will ruthlessly protect their IP. In fact, in recent years there has been a trend, especially in the technology space, for organizations to embrace open source. Recognize Risk Management Concepts Related to Cloud Services 231 Microsoft, one of the largest technology firms, has started integrating Linux into its flagship OS. You can download and install Windows Subsystem Linux (WSL) on W indows 10 today. Microsoft has developed and released free-to-use implementations of the OpenSSH suite on modern Windows desktop and server editions. Microsoft recently purchased GitHub, which is a publicly available cloud-based implementation of Git. When it comes to CSPs, let’s be honest, vendor lock-in is a very real risk. There is little incentive for CSPs not to promote vendor lock-in. The cloud is a subscription-based pricing model. CSPs want continual revenue from their cloud offerings. If it was easy to switch between CSPs, then why wouldn’t end users hop from vendor to vendor as prices change? If I am spending $200 a month with AWS for two VMs and I find out that Microsoft Azure’s cost for the same VMs is only $175 a month, then I would have to evaluate the costs and impact of moving the VMs to Azure. After 12 months, I would have saved $300, which is more than a single month’s bill. The risk response to cloud vendor lock-in is either acceptance or mitigation. Acceptance is often the choice because it mirrors the history of the organization’s own infrastructure. Before moving to the cloud, an organization’s infrastructure is already vendor locked. Organizations standardized their infrastructure so their staff could support it. Cisco or Juniper ran the network. All the servers in the data center were made by Dell or HP. All the storage ran on EMC or NetApp arrays. Organizations didn’t have the resources or the technical expertise to avoid vendor lock-in. The cloud does offer an easier path to a different response, mitigation. Vendor lock-in can be mitigated by diversification. Instead of running all infrastructure in either AWS or Azure, run some applications in both. Looking at the different cloud models we have discussed such as IaaS, PaaS, and SaaS, ideally you can see where we have abstracted different components. For example, I don’t need to care or worry about what is running my Windows Server 2016 computer. I don’t need to care whether it is running in AWS or Azure. I just need some way of accessing it or for my clients to access it. Organizations will still need technical expertise with diversification. However, the similarities between the CSPs is converging. At a high level, the terms are the same between them, i.e., zones and regions. The specifics are different, but you can usually draw parallels. AWS calls its object storage offering Simple Storage Solution (S3). Azure calls its object storage offering Blob storage. They have different names and the underlying technologies are different, but the use cases and presentation to the end user are nearly identical. Data Portability Data portability is another risk when going to the cloud. It is similar to vendor lock-in in that it is difficult to port data from one vendor to another. However, the difference is in the difficulty of porting data from one information system to another. This goes back to our discussion about data versus information. Data that is raw and unchanged in general is not useful in itself to business operations. Information, on the other hand, is processed data 232 Chapter 6 Governance and Risk and what individuals typically use. Information is data that is processed in some manner that is typically software. For the most part, CSPs cannot hold your data hostage as long as you are in good standing with the CSP (no outstanding bills, no legal holds, etc.). Your data is your data, but that does not mean the CSPs are under any obligation to make the transfer of data easier beyond the bare minimum. Exam Note Risk was the major theme in this section. The main takeaways from this section for the exam are how to identify risk and what are possible responses to identified risks. Data Privacy You will need to be familiar with the concept of data privacy for the exam. You will not need to know the individual CSP’s particular data privacy policies, but the broad concepts they cover. Additionally, you will need to know about General Data Protection Regulation (GDPR). GDPR was passed by the European Union (EU) parliament in April 2016. It applies not only to any businesses that are located in the EU but also to any businesses that want to offer services to residents of the EU. Any business that wants to process or hold the personal data of individuals residing in the EU must comply with GDPR. Businesses must take steps to protect PII. Because of the global scale of the major CSPs and the size of the EU market share, GDPR is becoming the default even for non-EU residents. It is simpler and easier for CSPs to have only one set of rules for all users than separate rules for different regions. Getting your data out from the CSP will be determined by the type of data you want to extract. If it is raw data contained within a database, then you can just export the data as raw SQL. All major CSPs do charge egress bandwidth, i.e., data moving out of their network. Extracting an entire VM is more technical than just dumping a SQL database. There are tools and services that will assist with the extraction of the VM. However, extracting the VM is not enough; you need to have a place for the extracted VM to land. Where you want the VM to ultimately live will dictate the fi le format you need the VM to be in. You may have to extract the VM a couple of times to get it in the correct format. Virtual Machines Are Just Files One of the underrated or misunderstood advantages of virtualization is that VMs are just files that get “played” by a hypervisor. You can think of them as almost like a Explain Policies or Procedures 233 PowerPoint presentation, a very large PowerPoint presentation. The PowerPoint file can change and grow, but as long as you have the entire file and a “viewer” (compatible hypervisor), then the PowerPoint presentation can be run anywhere. The devil is in the details on the compatible hypervisor, but you get the point. Thankfully, there is an open source standard for VM file formats, Open Virtualization Format (OVF). All CSPs support this standard for importing. Few CSPs allow you to export into OVF format. Therefore, the trick is to get a VM into OVF format. There is a process called Physical 2 Virtual (P2V) that makes this process doable. There is freely available software that you install on a machine, and it goes through the process of converting the machine into an OVF file. Even though the process is called P2V, the software does not make a distinction between physical or virtual. In other words, you can install the P2V software on a VM and have it work the process and output an OVF. You can then take the OVF file to import into any CSP that supports the OVA file format, which most do. Explain Policies or Procedures The terms policies and procedures are often confused, not because they describe the same thing but because they are almost always used together in the same sentence. We are as guilty of this as anyone. Looking back through this chapter; almost every occurrence of the word policies is followed by procedures. So, what is the difference between the two? Policies are thoughts, ideas, or principles that give a direction for actions to be performed by individuals or organizations as a whole. Sexual harassment, anti-bullying, wellness, anti-smoking, etc., are all examples of policies that organizations will typically have. Policies also define what qualifies as certain actions, i.e., sexual harassment, bullying, etc. This definition is often the standard to determine what course of action is to be taken. This course of action is a procedure. Procedures are steps that should be taken once an event takes place or steps that need to be taken to follow a policy. If an individual believes they have been sexually harassed after reviewing the sexual harassment policy, then they are to follow the sexual harassment claim procedure. This procedure will have well-defined steps to be taken, including who they should report the sexual harassment to and which forms and/or evidence to present. We are going to be discussing policies for the most part, because we want to leave you with broad examples. In general, policies are typically dictated by laws, regulations, or industry standards. An organization may tweak the wording of a policy to fit their specific needs, but network security policies are pretty similar from one organization to another. Procedures are often specific to an organization, because they detail specific steps/actions to take. 234 Chapter 6 Governance and Risk Public Policies and Procedures If your head is spinning with the difference between policies and procedures, there is a great resource that you can tap into to understand them better. Your local public-school district (and certain private schools) will have publicly available policies and procedures. They are public because schools are required to follow open meeting laws in states. Additionally, policies and procedures cannot be added to or modified without school board approval. This means there are public meetings and readings of policies and procedures to make changes. Check your local school district’s website; in all likelihood, there is a section for policies and procedures where you can browse, download, and even search through their policies and procedures. Standard Operating Procedures Standard operating procedure (SOP, pronounced ess-oh-pee, not sops) are the documented and defined steps that an individual or an organization takes once an event occurs. These are critical when we get into security events and incident responses, which we discuss in a few sections of this chapter. SOPs are not just made for when a risk event occurs or if something unfortunate happens. SOPs are also appropriate for day-to-day, mundane matters. SOPs help explain when something out of the ordinary occurs. Generically speaking, Event A just occurred. What led up to the event occurring? An engineer made changes to System B. What changes did the engineer perform, and did they follow SOP? Let’s walk through two examples. Cindy recently got married and changed her name to Cindy Jones. Cindy initiated a name update with the HR department. The HR department updated the payroll and employee records. HR then created an IT ticket for the name change in all the IT systems. Tracy in user account management received the ticket and updated her name in Active Directory (AD). Tracy then forwarded the ticket to the messaging and collaboration team to update the email address. Alex made the appropriate name change in Microsoft Exchange and closed the ticket. When Cindy opens a ticket that she is unable to receive emails with her new email address from outside the organization, Holly on the messaging and collaboration team can review Alex’s step and easily determine that he did not follow SOP and forgot the last step. Holly needs to make the name change in their external SPAM filter so outside emails can be delivered. Kim is reviewing the monthly charges from her CSP when she notices a discrepancy between the bill and what her IT department reporting says should be provisioned. Kim opens a ticket with IT to check the bill and what is present in the CSP management tools. Bill takes the ticket and opens the CSP management console and quickly determines that there are two VMs in the management console that are not reporting to the IT cloud reporting tools. SOPs for provisioning VMs in the cloud require using a pre-approved template. The template has the agents pre-installed that will report into Explain Policies or Procedures 235 the IT cloud reporting tools. The template also has approved OS images and security patches. Bill reviews the cloud audit logs and determines that Kevin created the two VMs that are not reporting. Bill asks Kevin if he used the template when creating the two VMs in the cloud. Kevin responds that he did not because the new software he was trying to test was not supported on the template’s OS version. The first scenario is a real-world example that happens all the time in any large organization when an employee’s name changes. SOPs assist and shorten the amount of time needed for issue resolution. The second scenario actually highlighted two SOPs. First, Kim was following an SOP when she was reviewing the CSP monthly bill. That SOP led to the evidence of a breakdown in another SOP (Kevin). This breakdown in SOP is an indication of a gap in the SOP, not a fault on Kevin’s part. Kevin is trying to test new software and needs a requirement out of the SOP. Either the SOP needs to be updated or a different SOP needs to be created to account for testing new software outside of the SOP with the approved template. SOPs are critical for large organizations, especially where a change can have far-reaching implications. Changes are going to occur in the world of IT, and following SOPs can make management of those changes easier. Change Management Most IT professionals will groan or mutter under their breath when change management comes up. They see it as a waste of valuable time and just another process that slows down getting work done. If viewed strictly from the perspective of an IT professional who is trying to maximize the work done and issue resolution, then it can be understood. However, a properly functioning change management system for an organization is critical to business success. Change management is the process of approving and managing approved changes to an organization’s assets. These changes must have two properties: an accepted risk and an increased value to the organization. Any change is going to have an inherit risk to the organization because it is a change, but the accepted risk needs to be counterbalanced by an increased value to the organization. Never making changes in IT has several drawbacks: no security patches, no new features, no enhancements. Services become frozen and never change. Not only is this a huge security risk (because attackers are definitely changing), but it is a poor end-user experience. End users will not get access to tools that are designed to improve their efficiency. Therefore, change management is not going away, and ideally you will see that it is an essential part of going to the cloud. Change management in the era of the cloud actually causes frustration and headaches for change managers. The reason is that CSPs are going to make changes to their service offerings, and these changes can and will impact organizations. This is not to say that CSPs are negligent and do not communicate changes to their customers. On the contrary, CSPs have their own rigorous change management process, and they do communicate changes. However, the impact of a change is not fully understood by the clients. The other piece 236 Chapter 6 Governance and Risk that causes heartburn for change managers is an inability to either block or roll back a change in the cloud. For example, let’s say there is a business procedure spelled out that an individual is to check a certain web page and document the failed login events for the last 24 hours. Let’s ignore that unautomated and human requirement for this procedure for the time being. The CSP has developed a new and improved web interface to bring the most used reports to the central dashboard. The new interface could very well move the location of the last failed login events in 24 hours to a new area of the website. The individual tasked with the procedure would have to adapt and change their process to fulfill the requirement. Microsoft has recently made changes to its Office 365 admin center. Figure 6.2 shows the current version as of the writing of this book. F ig u r e 6. 2 Office 365 admin portal Figure 6.3 shows the new and improved change management interface. F ig u r e 6. 3 Office 365 admin portal preview Explain Policies or Procedures 237 As you can see, the navigation pane on the left has changed. The dashboard on the right has also changed. For the most part, all of the previous information is still present, but the location is changing. Organizations that are wanting to make the move to the cloud are going to have to embrace change. The cloud is inherently about change. That is the double-edged sword; you get the benefit of another organization’s innovation, but you are also beholden to their changes. Going to the cloud means you are going to experience change, change, change. Change Management History Many of the concepts of change management are derived from the Information Technology Infrastructure Library (ITIL). ITIL identifies best practices for an organization to increase availability. ITIL was created in the 1980s by the UK government as a framework for technology adoption. The most recent version is 4 and was released in February 2019. There are still five core volumes as in ITIL version 3. One volume has been present in all versions, Service Transition. Service Transition details and spells out the change management process. Organizations do not need to adopt ITIL to use change management, but the concepts and the framework come from ITIL. Resource Management Resource management in the cloud is going to touch on many subjects that we have already discussed: asset inventory, provisioning, continuous integration and continuous delivery (CICD), configuration management. At the heart of any resource management are the resources. In the cloud the resources we are going to manage are going to be storage, compute, and network. These three terms should be very familiar to you by this point. By management we are referring to the ability to create and/or destroy and make changes to resources we want to manage. The major CSPs have a concept of resource groups. Resource groups are a collection of resources that are “similar” in either their resources or their management of the resources. For example, an organization may create an “Internal-Testing” resource group. This resource group would be used for any internal IT projects that engineers or developers need to test ideas on. This should sound familiar; think back to when we were discussing CICD. This resource group can have security policies and access control policies applied to it as a whole (security and access control policies are coming up later in this chapter). Everything in a resource group is going to be an asset, and this is where an accurate asset inventory becomes critical. CSPs have recently made a push for resource management for noncloud resources. This typically starts with mobile device management (MDM); think of email on your phone or access to internal corporate web applications. Microsoft’s cloud offering is currently more robust than those of at other CSPs. This is due mainly to its cloud offering of Intune. Intune can manage both of the major mobile device platforms: Apple and Android. Additionally, Intune can be used to manage nonmobile device platforms such as Windows, macOS, and Linux. Chapter 6 238 Governance and Risk Security Policies A security policy is the top or even one of the first policies an organization decides to adopt. We will reference another Sybex book, CISSP (ISC)2 Certified Information Systems Security Professional Official Study Guide, Seventh Edition: A security policy is a document that defines the scope of security needed by the organization and discusses the assets that require protection and the extent to which security solutions should go to provide the necessary protection. Let’s dive into this definition a little more; a lot of the terms should already be familiar to you. The “assets that require protection”: this is where the assets inventory becomes essential. We need to know the assets that we need to protect. “Extent to which security solutions”: this is where the risk register becomes essential. “Provide the necessary protection”: this is where the policy becomes important. We have already discussed having an appropriate level of response to an identified risk, but this is where we define it. Security policies will also define the roles and assign responsibilities to individuals, i.e., asset owners and risk owners. Security policies will define audit requirements and compliance steps for both laws and regulations. Some security policies will define acceptable risk levels, though the risk levels are typically defined by risk management. Risk and security for large organizations are separate departments but work closely together. This is because most security events or functions are risk related, but not all risk is security related. For example, risk involving employee interactions, i.e., sexual harassment, is not security related. There are three basic categories of security policies, which are detailed in Table 6.6. Ta b l e 6. 6 Security Policy Categories Category Description Regulatory Security policy that is required by either law or regulation. Details the regulation or law that is to be followed and the procedure(s) that must be followed to be compliant. Advisory Security policy that defines behaviors and activities that are acceptable in the organization. Will also lay out the procedures and consequences for an individual who violates the security policy. A network usage policy or mobile usage policy are examples of advisory security policies. Informative Security policy that provides reasoning and/or information about goals and mission statements for the organization. Will provide the proper procedures for working with third parties. Explain Policies or Procedures 239 Incident Response All three categories of security policies have procedure in the description, and if you recall, a procedure spells out a set of actions for the policy. An incident response is going to be a procedure. Incident response is the set of actions or steps taken once a risk event has occurred. Most organizations have three steps in an incident response procedure. Step 1: Detection and Identification Identification here means to identify that a security event has occurred; it does not mean we have identified all involved parties. Detection is different than identification. Detection means just to recognize an anomaly or events that occurred outside of normal operating parameters. Identification is the recognition of events that are in violation of a security policy. The key to detection and identification is logs and/or access control policies. Additionally, you need to know what normal behavior and events are. You must know how your systems operate. The tools used for detection and identification should be familiar. Anti-malware, firewall logs, OS event logs, and physical security systems, to name a few. The last step in detection and identification is notification. You need to notify the appropriate parties once a security event has been identified. This notification starts the next step in the incident response. Step 2: Response and Reporting Once the appropriate parties have been notified, someone or something needs to form a response to the security event. The response should be spelled out in the security policies by a procedure. Additionally, parties that are responding to the event need to document any actions taken. Responding parties need to assume that all their actions will be reviewed. This would be part of the security policies. For example, an organization has a security system with monitored door access. Part of this monitoring is the alerting of any doors that remain open for longer than 60 seconds. The response to a door remaining open for longer than 60 seconds would be to dispatch a security guard to investigate. There are several outcomes once the security guard is at the door. Maybe it is 8 a.m. and lots of people are entering the building and the door was never shut. Maybe someone is having a long conversation at the door and is just holding it open. Maybe someone forgot their badge and propped the door open with a bag to run back out to get their badge. Whatever action is determined by the security guard to take must be logged. The initial response to a security event should be isolation and/or containment. You want to minimize the continuation and prevent further harm to an organization’s assets. However, the isolation should not destroy evidence of the security event itself. For example, if you believe a server has been compromised, then turning off the server will clear the memory of the server. There could be useful evidence in memory. However, if you can either take the server offline or move it to a different network or isolate it from everything else, that provides time for investigation without potentially destroying evidence. Gathering evidence is the next step in response and reporting. Evidence gathering when the equipment is owned by the organization is easier than when equipment is owned by a third party. If an organization owns a piece of equipment, then the user of said equipment doesn’t generally have a right to an expectation of privacy. This is one of the main reasons 240 Chapter 6 Governance and Risk why organizations issue laptops, desktops, cell phones, etc. Since they are owned by the organization, they can seize these devices and perform any actions they need without a user’s say in the matter. Evidence gathering on third-party equipment can get into the legal realm of warrants and subpoenas, which we will not cover in the book. The takeaway is that the gathering of evidence needs to preserve the evidence but also contain it; therefore, the seizure of equipment may be necessary. Analysis and reporting are the last step in response and reporting. We have the evidence gathered. We need to analyze the evidence and get rid of unneeded information or noise. We need to just focus on the pieces that are related to the security event. Summarize the appropriate evidence and relate it to the actionable security policy. Once summarized, provide a report to management. It is appropriate to theorize and make conjecture about causes and motives, but you should spell out which conclusions are based solely on fact and which are speculations, even if educated. Step 3: Recovery and Remediation The last step in the incident response can be the most difficult and time-consuming. You need to return your organization’s affected system to a normal operating state, which depending on the security event may not be possible or could take months. Think of a data breach, where all of your customer PII has been leaked. How do you return to a normal operating state? What does a normal operating state look like? Those decisions could take time and may not even be known. A security policy should state what a normal state is, but a security policy cannot handle every event. Lastly there needs to be a lessons learned step. This is where you and/or management takes a look at the incident response and the underlying security policies and find where there are any gaps. Gaps will be either in the security policy itself or in the technologies that support the security policy. It is important to note that this is not a “who can we blame” step. Some individuals will think this step is management looking for a fall guy. In some organizations that may be true. However, any member of management who makes the lessons learned step a blame game is not a good manager. Experienced and good managers know this. Access and Control Policies Access and control policies are a subset of security policies. They will be some of the most important and the bulk of security policies. At the heart of access and control policies is a three-letter acronym, CIA. We will be discussing CIA more in-depth in the next chapter, but for now it stands for confidentiality, integrity, and availability. Access and control policies are all about ensuring CIA. Access and control policies spell out how an organization’s assets can access and change other assets owned by the organization. You can think of who has access to what files on a file server, who has access to the server room, and who has access to change employee data. Access and control policies are between two or more assets. There are three primary types of control when it comes to access and control policies, which are explained in Table 6.7. Explain Policies or Procedures Ta b l e 6. 7 241 Access and Control Policies Control Type Description Preventive access controls Controls that actively attempt to block or prevent any security events from occurring. Think of doors, locks, data classification, penetration testing, etc. Detective access controls Controls that detect when a security event occurs. Some security events cannot be prevented, or an unknown security event occurs. Think of motion detectors, security cameras, logs, honeypots, audit trails. Corrective access controls Controls that return assets to a normal operating state after a security event occurs. Think of anti-malware, backup and restore, or active intrusion detection. The next piece of access and control policies is an access control list (ACL). An ACL should define which assets are involved and what rights one asset has over the other. Some OSs or control systems can have ACLs with hundreds of rights to assets. However, all rights can generally be broken into one of three categories: Read, Write, and Execute, as explained in Table 6.8. Ta b l e 6. 8 ACL Categories Right Description Read The ability of an asset to read or even access another asset. Sometimes referred to as read-only if this is the only right granted to an asset. This right does not grant the right to change or modify an asset. One thing to keep in mind that a lot of individuals forget is if I can read or have access to an asset, I can usually make a copy of the asset. Write The ability of an asset to be changed or modified in any way. Most people consider write access as having full access, but that is not the case. The reason is that if an asset has write access, then the underlying asset can usually be deleted. This is one area where more advanced ACLs have split deletion away from the ability to change the asset. However, if I can write to an asset, then I can write “nothing” to it, which effectively deletes the data. Execute The ability of an asset to execute or take action on another asset. This is the last right needed for full access to an asset. Some assets can perform an action that will affect other assets. This is an important distinction because if an asset has write rights to other assets, then the parent asset can make changes to assets it might not normally have rights to, if the parent can execute the middle asset. This is another area where advanced ACLs have broken the execute right into further rights. 242 Chapter 6 Governance and Risk Even though read, write, and execute ACLs appear to only apply to files or printers or databases, that is not the case; we said that read, write, and execute are the three generic types of rights granted by ACLs and apply to assets protected by ACLs. These rights can be interpreted in the case of physical security as well. Read access could be the ability to open a door and access a protected room. If an individual has only read access, then they may be required to be escorted by another individual, i.e., cannot be alone. Write access could be the ability to enter a protected room without being escorted. Additionally, write access could be the right to leave without having to be let out. Execute access could be the ability to leave with an item that was protected by the room. These are just examples, but ideally you can see how ACLs work for more than just technical items. Authentication vs. Authorization For the exam you will need to understand the difference between authentication and authorization. They are often confused, and many people think they are one and the same. Authentication is proof or validation of who or what an asset is. A password or a fingerprint is an authentication method. It is something used to confirm who an individual is. Authorization is the rights an asset has. An asset should be authenticated first to prove they are who they say they are. Then authorization determines which actions an asset can take. Department-Specific Policies Department policies are policies that may or may not fall under the umbrella of security policies. Department policies will definitely refer to security policies, but security policies should be applied at the organization level. Department policies can be security in nature, but they should apply only more restrictive policies rather than less restrictive policies. The organization’s security policies need to be the baseline, and any department-specific policies should only enhance the organizations. Departments can have policies that are not security related but are risk related. Human resources and legal departments are the two largest examples of departments that would need such policies. Their department policies are going to be centered around confidentiality, because of the type of information they have access to. Employee files, pay scales, depositions, testimonies, and evidence are some examples. These policies will lay out the conditions and procedures for sharing this information both inside and outside the organization. IT departments will also have department-specific policies. These policies stem from their ability to grant or remove access to and control of assets. Since most things live digitally in an IT infrastructure somewhere, IT is usually the department that can grant or take ownership of an asset. Taking ownership is one of the most important rights that can be granted to an individual. Usually only IT personnel have this right. If control of an asset is lost because of negligence or nefarious means, then someone needs to be able to assume Explain Policies or Procedures 243 control of the asset. Once control of the asset is regained, then access can be granted to the appropriate parties. Let’s talk through a few examples to help clarify some of the policies an IT department might have. When an employee’s employment needs to be terminated, what happens to the assets the employee had access to? In some cases, this employee may be the only individual with access to certain assets, i.e., files or emails. An IT department will have the rights to take control of this employee’s technical assets, but maybe IT shouldn’t have access to the employee’s assets. Who does IT grant access to? The employee’s manager? What if it is a manager who gets terminated? These are questions that should be answered in a policy and procedure for IT professionals to follow. Another example is a request for access to assets an individual doesn’t normally have. IT professionals get requests all the time along the lines of: “John is out for vacation for a couple weeks. He was working on an important proposal but forgot to email it to me. Can you give me access to his files or send a copy over to me?” What is the appropriate IT response to such a request? Does someone need to approve it? Does John need to be notified? All these questions should be answered or given a path of last resort in policies. Communication Policies Communication policies are the last kinds of policies we are going to discuss and one of the most important. When discussing communication policies, we are not referring to notifications as part of an incident response. We are referring to communications that happen after a security event occurs. Some communication policies may be required by law or regulation. The federal laws that mandate disclosure or reporting of events only involve financial records. These are not security-related in nature. The two laws that are most referred to when talking about mandatory reporting or communications are the Sarbanes-Oxley Act and the Dodd-Frank Wall Street Reform and Consumer Protection Act. Neither will need to be known for the exam. We wanted to point out that currently the only federally mandated communications involve financial records. Every state in the United States including the District of Columbia has enacted some sort of data breach notification laws. We obviously are not able to cover the individual laws in all 50 states. However, we wanted to point out that state laws mandate notifications when it comes to personal information in data breaches. Most organizations have adopted communication policies when it comes to security events. These policies may be internal only unless mandated by state law. One of the most critical aspects of communication policies is the right to privacy. Individuals have the right to certain aspects of privacy, and an organization cannot breach this without breaking other policies. The privacy rights that individuals typically enjoy fall into one of two categories: life events outside of work or disciplinary actions. In general, life events that take place outside of the workspace and don’t impact an organization or its other employees are considered private. An individual cannot be required to disclose them to an employer. 244 Chapter 6 Governance and Risk Disciplinary actions taken against an individual in general cannot be communicated to anyone other than the affected parties. This is to ensure that the perception of guilt does not impact the disciplined individual. This is the restriction that puts most organizations in a bind when it comes to communication policies. Other individuals believe they have the right to know about events that impact an organization, but in general right to privacy trumps right to know when it comes to the individual versus the organization. We have gotten the gotchas and required stuff out of the way. What should be in a communication policy? After a security event does occur, the communication policy should specify who should be notified and what should be communicated. The what will depend on the who. You should not communicate the technical details and findings of a server being taken offline to the sales staff. However, technical details may benefit members of the IT department. Communication policies must take larger risk events into consideration as well. For example, what if a fire broke out in a warehouse and the fire made the local news? How should an organization communicate the safety of staff members to their families? What if workplace violence occurs? What sort of communication should be relayed to the family but also to the press? It is important for an organization to have clear policies in place to handle such events to cut down on misinformation. It is important for organizations to have defined communication policies when utilizing the cloud. These policies need to describe who, what, when, and where should be communicated after a security event. Additionally, there should be a catchall communication policy to address unknown or unforeseen events when they occur. Summary We covered a lot in this chapter, not all of it technical in nature, but it is important and needed for the exam. We started the chapter with compliance and the importance it plays in any organization. We discussed what it requires to be compliant and gave the example of PCI DSS, which lists the requirements for processing credit cards. Risk was introduced and was the primary focus of this chapter. We defined risk at both an IT level and a non-IT level. We discussed how to assess risk both quantitatively and qualitatively, which you need to understand for the exam. At the core of any risk assessment is an asset. An asset is any object or material that has value to an organization. The next key aspect of risk is threat. Threat is any set of circumstances that may cause damage or harm to an asset. We discussed the need for an accurate and up-to-date asset inventory. We then moved on to asset classification and how classification will help determine the level of protection of an asset against a threat. Ownership was the next topic, and we defined the difference between a risk owner and an asset owner. Every identified risk needs to have a response. There are four standard risk responses: mitigation, acceptance, avoidance, and transfer. We discussed the importance and need for documentation to be compliant with laws and regulations. Findings is the documentation that is produced whenever a risk event occurs. Findings flow from an investigation and four types of investigations can occur. A risk register Exam Essentials 245 is the document that details all the identified risks to an organization. It is a tool that is used by management to help formulate the appropriate risk response to each identified risk. We briefly introduced vendor lock-in and data portability when working in the cloud. The cloud plays a significant role in both topics, and you need to be aware of its potential impact. We also introduced a few tools and concepts that will help mitigate the impact of both vendor lock-in and data portability. Data privacy was discussed and the need to know what GDPR is and the requirements. We introduced policies and procedures and the difference between the two. Change management plays a pivotal role in the management of risk and cannot be ignored. Change management will make the life of an IT professional easier. We also brought up the difference in change management when utilizing the cloud; i.e., change will happen, and it will be out of your control. Resource management was our next topic, and we touched on some of the tools CSPs offer. Policies were our next big topic, and we went through security, access and control, department-specific, and communication policies. With security policies we dived into incident response and the steps needed to be taken. Last, we introduced the concept of ACLs and how they control the access of one asset to another asset. Exam Essentials Know what compliance is. Compliance consists of the actions an organization takes to be compliant with laws and regulations that govern the industry the organization operates in or a state/country an organization operates in. Know what risk is and its three parts. Risk is the probability of the occurrence of a threat. Threat is any condition or circumstance that can cause harm, damage, or loss of an asset. An asset is an item or material that has value to an organization. Know the difference between quantitative and qualitative analysis. Quantitative analysis is the analysis of the value of an asset that is based on monetary value, also known as a tangible asset. Qualitative analysis is the analysis of the value of an asset based on its perceived qualities. This analysis is often done by experts who have experience with the assets and are able to compare assets to other assets to provide a perceived value. Know the importance of an asset inventory. Risk is all about protecting assets. An organization needs to have an accurate and timely asset inventory to protect against threats. Asset inventory examples are hardware, software, and data. Know what risk classification means and its importance to the level of protection. All identified risks should be classified and ranked against other risks. This ranking or grading will help determine the appropriate risk response and also work as a check mechanism with other risks. Know what ownership is and the difference between the risk owner and the asset owner. The risk owner will be a member of management who decides the risk response to an identified risk. The asset owner will be more technical and have the expertise to manage an asset. They can be the same person but don’t have to be. 246 Chapter 6 Governance and Risk Know the four risk responses. Mitigation is reducing risk through action(s) of expenditure of resources. Acceptance means that the organization chooses to not reduce risk. Avoidance is the removal of risk. Transfer means that a third party accepts the risk. Know the importance of documentation and be able to give examples. Documentation is a requirement to be in compliance with laws and regulations. Findings and a risk register are two examples of often-required documentation. Know the impact of vendor lock-in and data portability in the era of the cloud. Utilizing resources in the cloud has an inherent risk of vendor lock-in. CSPs will not make it easy for you to switch or move between different CSPs. CSPs cannot hold data hostage, but they don’t have to make it easy for you to port your data to another vendor either. Know the difference between policies and procedures. Policies give direction, guidance, and provide goals for an organization. Procedures provide specific steps to achieve or work toward a goal. Know the importance of standard operating procedures. SOPs can shorten the time involved in basic troubleshooting to come to issue resolution quickly. Know the importance of change and resource management. Change management is the process of managing change for an organization when consuming cloud resources. Changes must increase the value or benefit to an organization in some fashion when there is a corresponding level of risk. Resource management is managing cloud resources: compute, storage, and networking. Cloud offers additional resource management that was not possible with on-prem resources, e.g., Intune. Know the various policies discussed: security, access and control, department-specific, and communication policies. Each one of these policies plays a different role in risk management. Security is at the top and should be organization-wide. Each subsequent policy adds on another layer that helps manage risk. Know the steps for an incident response. The steps are detection and identification, response and reporting, and recovery and remediation. Understand how the workflow goes from one step to another step. Know the three basic rights of an ACL. Read, write, and execute are the rights that more advanced ACLs are built on. Understand how these can be generically applied to nontechnical assets as well. Written Lab Fill in the blanks for the questions provided in the written lab. You can find the answers to the written labs in Appendix A. 1. is the probability or likelihood of the occurrence or realization of a threat. 2. is any agent, condition, or circumstance that could potentially cause harm, loss, damage, or compromise to an IT asset or data asset. The likelihood of the threat is the probability of occurrence or the odds that the event will actually occur.

Ch6B.pdf Governance and Risk PDF

Document Details

Tags

Related

Summary

Full Transcript

Upgrade to continue