Security Template Exception (part 2) – The Assessment

In “The Scenario” I laid out the scenario that we want to assess the risk for. Simply put, a rather routine Windows security template exception. Using the RMI FAIR Basic Risk Assessment Guide (BRAG) as our guide, let’s jump into this.

Note: In the interest of brevity, I will try to strike an appropriate balance between descriptiveness and conciseness when characterizing scenario components. When in doubt, error on the side of what may seem like too much documentation. Not only does it make the assessment more defensible now- it helps in the future if you have to revisit it or need to compare a similar scenario against it.

1.    Identify the Asset(s) at Risk: A non-redundant, non-highly available Windows 2003 Active directory member server that runs a sales tracking application that is infrequently used by CSRs to service customers for detailed sales order information. The most likely threat scenario is non-availability of the server to the business (CRSs) due to 3rdpartysalesapp.exe being leveraged to fill up the  hard disks on the server with useless data by the TCOMM below.

2.    Identify the “Threat Community” (TCOMM): This is always an interesting discussion since there can be multiple threats that can come into contact and attempt to take action against an asset. For this scenario – the first two that come to mind are malware and a malicious server administrator; I will only perform the assessment using one of them.

a.    Malware. Based off the given information, I am less inclined to stick with malware because the server is very isolated from the most likely attack vectors one would expect malware to be propagated by (email, Internet browsing, outbreak in lesser trusted network space, etc..). Now please understand, I am not stating that this server cannot be attacked by malware, I am stating that compared to my other threat community, a malware infection on this server has a lower probability of occurring then the other.

b.    Malicious Server Administrator (SA). I am choosing this TCOMM as the most likely for several reasons:

i.    The server is not accessible from the Internet; which reduces the chances of attack from the traditional “hacker” TCOMM.
ii.    It is reasonable to assume that most Initech Novelty, Inc. end users that interface with the application running on the server do not have privileged knowledge of the security configuration of the server.
iii.    Based on Initech company history there has been at least one incident of a malicious technical insider attack (Initech, Inc.).
iv.    I would characterize my TCOMM as “an internal, privileged, professional, technical server administrator”.

3.    Threat Event Frequency (TEF): TEF is the probable frequency, within a given timeframe, that a threat agent will act against an asset. For this step, I am going to select LOW or once every 10 years. Here is why:

a.    There was an incident in 1999 where a malicious internal employee was able to successfully take action against Initech. The circumstances then compared to this scenario are different but we have a starting point from an analysis perspective.

b.    In general, SA’s are pretty trustworthy individuals. Initech Novelty, Inc. is a small company with minimal IT staff. It is reasonable to assume that most of them would not have reason nor intent to intentionally attempt to bring down a production server. From a scenario perspective, there is nothing stated that should lead one to assume there is a reason for one of the existing SA’s  to take malicious actions.

c.    Initech Inc. has already been assessed by a 3rd party for ISO 27002 and given a CMM score of around 3.5 for the “human resource security management” section. An assessor could assume that Initech, Inc. is performing a good level of due diligence to ensure they are hiring trustworthy individuals as well as ensuring there are deterrents in place to hopefully minimize malicious behavior (could be a combination of both preventive and detective controls; policy, monitoring, training, etc..).

*NOTE – It may make more sense to skip to Step Five and then come back to Step Four.

4.    Threat Capability (TCAP): The probable level of force that a threat agent (within a threat community) is capable of applying against an asset. Now keep in mind that we are focused on the TCOMM in the context of a weakened security template that allows a non-Windows provided executable to write to “%systemroot%\system32” – not the threat population. For this step I am selecting MODERATE; between %16 and %84 of the threat community is capable of applying force against the server and vulnerability in focus for this scenario. Here is my reasoning:

a.    The TCOMM would have unfettered and privileged access to the server and be able to easily launch an attack.

b.    The TCOMM would most likely have privileged knowledge of the weakened security template.

c.    It would not take much effort for the TCOMM to find or quickly create a method to exploit the vulnerability.

5.    Control Resistance (CR; aka Control Strength): The expected effectiveness of controls, over a given timeframe, as measured against a baseline level of force. The baseline level of force in this case is going to be the greater threat population. This is important to understand. So, threat community is a subset of a greater threat population. So we can have internal employees as a threat population; but we have narrowed our focus in this scenario to a small subset of the population which is articulated in the Step 2. Pardon the redundancy, but Control Resistance is analyzed against the population – not the threat community. For this scenario, I am selecting a Control Resistance value of HIGH; or stated otherwise, the controls on the server are resistant to 84% of the threat population. Here is my reasoning:

a.    A very small percentage of the Initech Novelty, Inc. workforce would ever have privileged knowledge of the weakened security template.

b.    The skills required to remotely exploit the vulnerability are not trivial. It’s possible that someone may have the skills, and tools, but it is not probable that a large or even moderate percentage of the “threat population” does for this scenario.

6.    Vulnerability (VULN): The probability that an asset will be unable to resist the actions of a threat agent. The basic FAIR methodology determines vulnerability via a look-up table that takes into consideration “Threat Capability” and “Control Resistance” (this is on page seven of the BRAG).

a.    In step four – Threat Capability (TCAP) – we selected a value of MODERATE.

b.    In step five – Control Resistance (CR) – we selected a value of HIGH.

c.    Using the TCAP and CR inputs in the Vulnerability table, we are returned with a vulnerability value of LOW

7.    Loss Event Frequency (LEF): The probable frequency, within a given timeframe, that a threat agent will inflict harm upon an asset. The basic FAIR methodology determines LEF via a look-up table that takes into consideration “Threat Event Frequency” and “Vulnerability” (this is on page eight of the BRAG).

a.    In step three – Threat Event Frequency (TEF) – we selected a value of LOW; once every 10 years.

b.    The outcome of step 6 was a VULN value of LOW

c.    Using the TEF and VULN inputs in the Loss Event Frequency table, we are returned with a LEF value of VERY LOW

*Note: the loss magnitude table used in BRAG and the loss magnitude table for the Initech, Inc. scenarios are different. The Initech loss magnitude table can be viewed below as well as at the Initech, Inc. page of this blog.

Loss Magnitude Table (Initech Specific)

Loss Magnitude Table (Initech Specific)

8.    Estimate Worst-Case Loss (WCL): Now we want to start estimating loss values in terms of dollars. For the basic FAIR methodology there are two types of loss: worst case and probable (or expected) loss. The BRAG asks us to: determine the threat action that would most likely result in a worst-case outcome, estimate the magnitude for each loss form associated with that threat action, and sum the loss magnitude. For this step, I am going to select DENY ACCESS, in the RESPONSE loss form, with a WCL value of LOW. Here is why:

a.    The server going down results in it not being available- thus access to it is denied. The most likely loss form to Initech Novelty, Inc. is the cost (IT response) in bringing it back up.

b.    Since this is “worst case”, the longest I could see this server being down is five business days. Based off the given information, this would result in one call to the service center not being able to be properly serviced because the application is down. I estimate response loss from a customer service center perspective to be less then $100.

c.    The effort required by IT to rebuild the serve is 1-2 hours – easily under $1000 dollars.

d.    Even though the application is not considered “mission critical” to Initech Novelty, Inc. – a prolonged outage could impact other processes as well as increase the response impact.

9.    Estimate Probable Loss Magnitude (PLM): In step eight, we focused on worst-case loss – which in reality for this type of a scenario is probably not a practical step. Now we are going to focus on probable loss. Probable loss is for the most part always going to be lower then “worst case” loss. The BRAG asks us to: determine the threat action that would most likely result in a worst-case outcome, estimate the magnitude for each loss form associated with that threat action, and sum the loss magnitude. For this step, I am going to select DENY ACCESS, in the RESPONSE loss form, with a WCL value of VERY LOW. Here is why:
a.    The server going down results in it not being available- thus access to it is denied. The most likely loss form to Initech Novelty, Inc. is the cost (IT response) in bringing it back up.

b.    Since this is “probable loss”, the longest I could see this server being down is a few hours, not more then a day. Based off the given information, this could result in one call to the service center not being able to be properly serviced because the application is down. I estimate response loss from a customer service center perspective to be less then $100.

c.    The effort required by IT to rebuild the serve is 1-2 hours – easily under $1000 dollars.

10.     Derive and Articulate Risk: At this point in the basic FAIR methodology we can now derive a qualitative risk rating. Using the table on page 11 of the BRAG worksheet, we use the LEF value from step seven and the PROBABLE LOSS MAGNITUDE value from step nine to derive our overall qualitative risk label.

a.    LEF value from step seven was VERY LOW.

b.    PLM from step nine was VERY LOW.

c.    Overall risk using the BRAG table on page 11 is LOW.

So how would I articulate this to a decision maker or someone that is responsible for this exposure to the organization?

“A security template modification is necessary for this application to function properly. The modification somewhat weakens the security posture of that server. The most likely threat to the server would be a disgruntled server administrator that wants to bring the server down. Our assessment is that there is a very low likelihood of loss and even if it did occur there would be minimal impact in terms of response costs to Initech Novelty, Inc; (expected loss of less then $1000; worst case loss less then $5000).”

Final thoughts: Some of you that have read the scenario and assessment are probably thinking that this seems like a long process. As with anything new it takes a few iterations for one to become comfortable. Over time, a simple scenario like this could easily be done in a few minutes mentally – maybe five minutes if you have to document some of your justifications (which I suggest you always do).

I look forward to any feedback you might have! If anyone has any suggestions for a future scenario – please let me know.

Advertisements

4 Responses to Security Template Exception (part 2) – The Assessment

  1. Christian says:

    Awesome series of posts Chris! I’m a huge advocate of the FAIR methodology and have helped our internal info risk folk also start to leverage some of the methodology and language in to our existent, legacy processes.

    What is really interesting is the way you have documented out the process is very similar to how I’ve used the FAIR method to document and assess info risk scenarios here at work. As you highlight, walking through the BRAG is a very effective way to do a quick review of a particular scenario.

    Another thing that I really enjoyed about this series was bringing quite common scenarios out into the open. I’m all for the concept of ‘open’ RA, particularly because there are a number of scenarios out there that multiple companies are facing, and whilst some of the context is different per company, people can still accommodate for that.

    I’ll definitely be sharing these posts with some colleagues.

    Cheers!

  2. Chris Hayes says:

    @ Christian – Thank you so much for the kind feedback! If you have any suggestions on any specific types of scenarios in the future – let me know! Take care!

  3. […] you all had a great weekend.  I had meant to point you earlier to a FAIR analysis that Chris Hayes did over at his Blog.  But I’ve been a little busy, and before I could mention it, Stuart King put up a kind of […]

  4. […] King (whose risk management blog is at computerweekly.com)? It seems Stuart believes Chris’s strategies for risk assessment are impractical. Chris, in a response, takes a stab at explaining how he and […]

%d bloggers like this: