WIXLIB

1. A user logs into the network and his/her identity is established(authentication)2. The user is granted access to the payroll system because of his/herrole (course authorization)3. The user is granted access to specific tasks or data within theapplication, based on his/her role in the organization (fineauthorization based on segregation of duties)4. Once the user selects a specific task, he or she is only allowed toperform specific actions on the data (least privilege)5. Database limits what the user sees to only what is necessary toperform an assigned task (need-to-know)The final component of access control is accountability. Accountabilityensures you understand what subject accessed an object, what was done to theobject, and when the action happened. Collection of logs and log auditing is thefoundation of accountability.The strength of access control depends on the sensitivity of the resourceprotected: the resource’s classification. We classify data based on its value to theorganization and the negative impact on the organization if the CIA of that data iscompromised. For example, we might classify data as Public: anyone can access and see the information with no negativeimpact on the businessConfidential: moderate damage to the organization will occur if thedata’s confidentiality, integrity, or availability is compromisedRestricted: severe damage to the organization will occur if the data’sconfidentiality, integrity, or availability is compromisedAny device through which data passes, is stored, or is processed is given theclassification associated with the most sensitive classification of data involved. If,for example, a server contains restricted and public data (which is never a goodidea), the server is classified as restricted. You should consider strong accesscontrol (multifactor authentication and encryption) for critical resources.For a detailed discussion of access control, see Identity Management andAccess Control (http://bit.ly/2q0unas). Download the University System of Georgiasegregation of duties matrix template from http://bit.ly/2pXCeGF as sample tool forplanning roles.(d) Vulnerability IdentificationYou must know if you are open to attack. One of the best ways to do this iswith regular vulnerability scanning. Nessus, for example, is an up-to-date toolwidely used to scan networks for known vulnerabilities. A vulnerabilitymanagement program also includes penetration testing and third-party security

program reviews. All of this begins with a vulnerability management policy andassociated procedures (download policy template from http://bit.ly/2rjaikx).A valuable tool for knowing what vulnerabilities you potentially have inhouse is the National Vulnerability Database (https://nvd.nist.gov/).Section 1.04 Section SummaryThe purpose of incident management is to prepare for various types ofincidents and then to respond when they occur. Incident management has fourgoals:1. Development and management of an incident management policy andsupporting procedures2. Creation, training, and management of an incident response team3. Preparation4. Incident response to reduce or prevent business impactA security incident is an event, intentional or unintentional, that occursoutside what is expected in daily operations that can negatively affect businessprocesses, customers, investors, and employees. It is anything that can compromisethe confidentiality, integrity, or availability of data or systems that support businessprocesses

Section 2.Risk ManagementManaging risk is the first step in information assurance, and it is a criticalpiece of incident management. In both cases, risk assessments and subsequent riskacceptance, avoidance, transference, or mitigation are the foundation of preventingand responding to threats agents. If the incident response team does not run theorganization’s information risk management program, its members should at leastbe involved in every risk assessment. The formulaic risk model I use for ourdiscussion of incident management related to human attacks is shown in Figure 1.Figure 1: Risk ModelSection 1 explains threats and vulnerabilities. In Figure 1, the set ofvulnerabilities available to enable an attack are categorized as opportunity. Theprobability that a threat agent can or will successfully take advantage of anopportunity to reach its objective is a key component of risk. Means are the skillsnecessary to successfully reach the intended target. A human threat agent is usuallymotivated by the financial, political, or other value of the attack target. Naturaldisasters need no motivation.As the strength and tested effectiveness of controls increase, means andmotivation must also increase. This serves to shrink the number of possible threatagents; probability of occurrence for human attacks tends to decrease. Thisdecrease is caused by the increased effort (cost) to reach the target and the decreasein return on investment for the threat agent. Decrease in probability is also relatedto the difficulty something like a worm would have spreading across yourorganization and affecting availability, for example. If a threat agent’s motivation ishigh, and she is highly skilled, a lower but still present probability of successfulvulnerability exploits exists.Once a threat agent gains entry to your network or one of your systems,potential for negative business impact arises. According to Gartner (2017), businessimpact includes “ the potential effects (financial, life/safety, regulatory,legal/contractual, reputation and so forth) of natural and man-made events onbusiness operations” (para. 1)How quickly we detect, contain, and manage an attack affects the extent ofthe impact. This is the purpose of incident response. If your organization has adocumented incident response plan and a trained incident response team, you canprevent serious harm when the inevitable intrusion occurs.2-1

As with all security activities, risk management begins with a managementapproved and supported policy. Shon Harris provides a great article about whatgoes into a risk management policy at http://bit.ly/2q9BgHB.Section 2.01 Risk AssessmentsRisk management helps prevent and prepare for incidents. The mostvaluable tool in this process is the risk assessment. A risk assessment looks closelyat each system, the your network, and other organizations where your data is storedor processed. Perform risk assessments During the initiation and development/acquisition phases of the SDLC(http://bit.ly/2kxni2y)When deemed necessary by a Change Advisory Board(http://bit.ly/2f20um5)When new vulnerabilities are discovered in your systems or network,or when announced by a third-partyWhen threat intelligence reveals a new threat, threat agent, or toolsand techniquesAt least once per year for systems touching highly sensitive data orsupporting critical business processesAn assessment consists of 10 steps divided into two phases:Phase I: Assess1. System definition2. Threat identification3. Vulnerability identification4. Attack path controls assessment5. Business impact analysis6. Risk determination7. Controls RecommendationsPhase II: Manage8. Action plan and proposal creation and presentation9. Implement approved controls or transfer risk10. Measure to ensure steps taken work as expected and adjust wherenecessary(a) System DefinitionSystem definition begins with system decomposition. System decompositionbreaks down a system into the various components of its attack surface (Olzak,2011). A system is the collection of devices and media used to access, process, store,and move information for a related set of business processes. For example, theinfrastructure supporting payroll processes is the payroll system. In some cases,you might want to assess only parts of the system. However, you should assesscomplete systems at least annually.

A system’s attack surface is not a single piece. Instead, it is an aggregate ofmultiple attack surfaces. Figure 2 shows a very simple model. In this model, thenetwork attack surface can be further broken down into each network device(switches, routers, firewalls, etc.) and cabling. The device attack surface includesthe operating system and applications it hosts. I placed the device attack surfaceover the network attack surface because today’s most popular and destructiveattacks target users and their devices.Figure 2: Attack SurfaceWhen assessing attack surfaces, consider the following (Olzak, 2017) Entry points where the system receives information.Exit points where the system provides information to other systems:o Direct exit points exchange information with external systems.o Indirect exit points provide information to direct exit points.Data channels, protocol-enabled pathways over which informationtravels.Untrusted data items, persistent entities attackers use to controlsystems or extract data. Examples include cookies, files, maliciousdatabase records, and registry entries. Attackers cause exit points toread from untrusted data items or use entry points to write intountrusted data items (Manadhata, Karabulat, & Wing, n.d.). They areused by threat agents to own a device or system.Protecting information transit points and channels; and defending againstuntrusted data items requires strong access rights between subjects and objects.See Figure 3.

Figure 3: Access RightsAny access between an object and a subject should be controlled with consistentrights management. “Access rights identify subjects, the objects they can access, andwhat they can do after access is granted” (Olzak, 2017). This does not just apply tousers and the resources they access; it also applies to applications, services,protocols, and anything else that attempts to access an object for any reason.Information about the system or network assessed can come from severalsources: Existing documentationInterviewsQuestionnairesNetwork scans(b) Identify Existing ControlsIdentify existing controls and potential vulnerabilities by walking throughprobable attack paths using network and data flow diagrams to create attack trees.An attack tree helps visualize how a threat agent might gain access to an intendedtarget. Figure 4 shows an attack tree with a database server as the target. Thisexample does not show all possible attack paths. For a detailed description of howto use an attack tree, including addressing probability of successful attacks, see RiskManagement (http://bit.ly/2rCPNM7).

Figure 4: Attack TreeIn addition to attack trees, I recommend creating a controls matrix. Acontrols matrix lists all controls implemented, how they are configured, and whatthey protect. Figure 5 is a screen shot of a controls matrix template you candownload from http://bit.ly/2pVWAV3. See Use a security controls matrix to justifycontrols and reduce costs (http://tek.io/2pWwnFA) for a detailed explanation onhow to use the matrix.

Figure 5: Controls Matrix(c) Business Impact Analysis (BIA) and Calculating RiskUse a BIA to determine the severity of the negative impact on a business if anincident occurs. Many variables affect business impact, including (Olzak, 2012) Maximum tolerable downtime (http://tek.io/2rDmgC5)Impact on employeesImpact on investorsImpact on customersImpact on current and future earnings potentialSanctions due to non-compliance with regulatory requirementsA BIA can be qualitative or quantitative. How you approach the BIA affectshow you approach an overall risk assessment. A quantitative assessment usesactual dollar amounts to estimate business impact. A qualitative assessment usessome type of scale to estimate damage. Hybrid analysis is a combination of thequantitative and qualitative approaches. A qualitative risk calculator, downloadablefrom http://bit.ly/2pYNh6r, is shown in Figure 6. This calculator is just oneapproach to qualitative assessments, which are educated guesses based onexperience and collaboration. For a detailed discussion of risk assessments, see RiskManagement (http://bit.ly/2rCPNM7).If you choose to download the calculator, the System Sensitivity cells arelinked to a worksheet that calculates this value. The yellow column also contains aformula. Other worksheets provide guidelines for scoring the other columns.Change these to conform to your business operations, security framework, andmanagement’s appetite for risk. And remember, a threat agent usually must bypasstwo or more vulnerabilities to reach the target.

Figure 6: Qualitative Risk CalculatorApproaches to performing a BIA differ between organizations. However, wemust always focus on the same things regardless of how our procedures look.According to Ross (2010), avoid the following 10 BIA mistakes:1. Considering the impact of interrupted applications, not businessprocesses. Remember, the impact is to business operations if asystem is not available due to compromise or failure. Unavailabilityimpacts business processes that feed and use the failed system. If youtake your order entry system offline because of an attack, for example,no product ships. Customers are not happy, and revenue is lost.2. Considering applications in isolation. Again, few applicationsoperate in isolation. Most share information with other applicationsthat enable multiple business processes. When performing a BIA for asystem or a network device, look at all affected systems and relatedprocesses.3. Paying too little attention to financial impact. Financial impact is ameasure of how an incident affects your organization’s bottom line ona profit and loss statement. This includes all costs, includinga.b.c.d.e.f.Loss of short term revenueRegulatory finesCivil action by customers, shareholders, etc.Identity theft managementCost of recoveryetc.

Costs associated with an incident must be calculated with the help ofall affected areas of the business. This is necessary even if you use aqualitative or hybrid approach to your analysis.4. Paying too much attention to financial impact. In addition to harddollar costs, other costs affect the long-term health of a businessfollowing an incident, including loss of reputation and customerconfidence; and loss of competitive advantage, especially whenintellectual property is involved.5. Failing to distinguish enterprise applications. Applications thatserve the entire organization fall into this category. Examples includelegal and document management systems.6. Failing to recognize data center applications. Systems/solutionsonly used by IT are often ignored during risk assessments. Be sureyou include these in your assessments.7. Confusing a risk assessment with a BIA. A BIA is a subset of a riskassessment, but it can stand on its own. Even if you have no idea whatmight cause the unavailability of a system or business process, a BIAis something to consider: at least to establish value to theorganization.8. Confusing risk acceptance with a business impact analysis. Donot allow business managers to simply accept risk because they donot want to spend the time working with you to create a BIA. This isone more instance where support of C-level management for incidentmanagement is irreplaceable.9. Pre-determining BIA results. Ross writes that a business managercan correctly estimate loss without a formal BIA about 80 percent ofthe time. This is the same as saying that one in five businessprocesses or applications is inaccurately analyzed. Even whenpursuing a qualitative analysis, it is important to take time to walkthrough estimated costs.10. Backing into a BIA result. Sometimes, managers choose tounderstate the financial, reputational, and operational impact of anincident because the perceived impact is too high. This underminesthe ability to effectively prepare for and manage incidents.(d) Risk Management RecommendationsHow you manage risk is largely determined by management’s risk appetite:the level of risk managers are willing to assume to achieve business objectives. Partof creating an incident management program is meeting with the organization’sbusiness risk management team or senior management to understand acceptablelevels of risk. This helps provide workable recommendations at this point in therisk assessment.Once we know the risk, recommend one of the following:

Accept the risk. If the cost of the risk is lower than any mitigation ortransfer solutions available, we usually recommend risk acceptance.Mitigate the risk. If the cost of risk is higher than the cost ofmitigation solutions, we usually recommend mitigation.Recommending mitigation requires a detailed analysis of our existingcontrols to determine if they can be reconfigured to reduce risk. Italso requires analysis regarding how we might use fewer newcontrols by integrating them into the existing framework. In otherwords, never simply throw new controls at risk without a thoroughanalysis of what you have and what you need. Finally, any controls werecommend should be reasonable and appropriate for businessoperation.Transfer the risk. Transferring risk typically means purchasingincident loss insurance. Many insurance carriers now offer this.Purchasing insurance might be something done in addition tomitigation. For example, you might purchase insurance to cover costsassociated with customer identity theft protection in addition toimplementing additional technical controls. Together, transferenceand mitigation work to reduce risk to acceptable levels.Avoid the risk. Sometimes, risk is avoided by simply not doingsomething by removing existing procedures/technology or by notimplementing a new solution. In my years as a director of security,management chose to avoid risk only once. Never count onavoidance. Our job as security professionals is to find ways to safelyenable solutions that management deems necessary to reach theorganization’s objectives.(e) Results Documentation and PresentationProvide detailed documentation for how you conducted the assessment andyour results. The details help the risk mitigation team be more effective. The NISTRisk Management Guide for Information Technology Systems, SP 800-30(http://bit.ly/2rLdVfJ) provides an excellent template. However, details aresomething management usually does not care about. They only want to see therisks and what you believe needs to be done to manage the risks.In addition to a detailed assessment document and a technical presentation,create a presentation for management. This presentation provides a high-levelexplanation of what you did and the risks discovered. At the opening of thepresentation, let the attendees know you want them to decide on yourrecommendations. Be clear about how your recommendations are financially andoperationally reasonable and appropriate.The final document resulting from an assessment is the action plan. Theaction plan is the result of management’s approval of your recommendations. It

includes what is to be done, who is responsible, and status. You can download fromhttp://bit.ly/2rtKAtT the template I use.Section 2.02 Section SummaryIncident management is inseparable from risk management. In addition tocreating and practicing a response plan, the incident management team should beinvolved in every risk assessment. In my opinion, the team should manage theassessments as part of their day-to-day operations.Risk is assessed by first understanding the system or network analyzed andthen walking through all potential threat paths. This should occur when a newthreat emerges or when new vulnerabilities are discovered. In any case, riskassessments for critical systems and sensitive data should happen at least annually.Your risk management recommendations must be reasonable andappropriate for the organization’s budget and operations. Management must seethe short- and long-term financial and non-financial impact of simply accepting risk:or worse, doing nothing.

Section 3.Team Creation and PlanningIn this section, I walk through details of creating and managing an incidentresponse team and plan. The purpose of t

Incident response is a subset of an overall incident management program. The purpose of incident management is to prepare for various types of incidents and then respond when they occur. Incident management has four goals: 1. Development and management of an incident management policy and supporting procedures (details in Section 3) 2.