Re: Vulnerability vs. Risk Assessments

[Gary Dobbins <dobbins () ND EDU>]

Good point.  I have always implicitly considered exposure to be part of vulnerability, but it's good to see it called 
out.  Each factor can be composed of sub-factors.  E.g. An unpatched server that's off-net is not vulnerable (to 
certain threats).



> -----Original Message-----
> From: John Ladwig [mailto:John.Ladwig () csu mnscu edu]
> Sent: Thursday, November 05, 2009 12:10 AM
> To: SECURITY () LISTSERV EDUCAUSE EDU; Gary Dobbins
> Subject: RE: [SECURITY] Vulnerability vs. Risk Assessments
>
> We add Exposure to the calculation.  If you've not patched a vulnerability in a
> service, and the service isn't exposed, that means the threat can't (directly)
> exploit the vuln; a mitigating control is in place.
>
> The part that's subtle is that the vulnerability is still there, for exploit via hopping
> strategies, for example.
>
> Those that believe Firewalls Give You Security seem to think that firewalls erase
> vulnerabilities, and I assert that's not true.  They do buy you some time, in the
> best case.  And they provide another detective control, assuming that you log
> appropriately from them and can use their logs to give you timely information.
>
> Asset value (>0) is a good explicit add to the calculation; we generally tie that to
> vulnerability, to prioritize patching activities, among other controls.
>
>     -jml
>
>
> -----Original Message-----
> From: Gary Dobbins
> Sent: 2009-11-04 21:22:01
> To: Gary Dobbins;The EDUCAUSE Security Constituent Group Listserv
> Cc:
> Subject: Re: [SECURITY] Vulnerability vs. Risk Assessments
>
>
> While I definitely agree with the other responses, I also find this variant on the
> formula helpful when explaining to non-IT's or non-tech's:
>
> Risk = Asset * Threat * Vulnerability
>
> Asset represents what other formulae sometimes call "impact".  I just feel it's a
> bit more intuitive to call it "asset" since execs think of assets easily, so do
> accountants.
>
> Drive any one of those three factors toward zero, and you affect risk directly.
>
> e's.g.
> Remove the asset, no risk.  Keep sensitive data out of harm's way.
> Reduce threats, lower risk.   Block unnecessary traffic, encrypt laptops.
> Reduce vulnerabilities, reduce risk.  Patch systems.
>
> Nice thing about having Vulnerabilities in the formula is they are one of the
> factors you can sometimes directly control through system management.
>
> Asset reduction can be done with data handling/access controls.
>
> Threat reduction can be done with technical measures, but not always.
>
>
>
>
> From: The EDUCAUSE Security Constituent Group Listserv
> [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Mike Waller
> Sent: Wednesday, November 04, 2009 9:32 PM
> To: SECURITY () LISTSERV EDUCAUSE EDU
> Subject: Re: [SECURITY] Vulnerability vs. Risk Assessments
>
> The below is a pretty good explanation. From my experience, a vulnerability
> assessment is a look at a system/site/application/firewall/whatever with an eye
> towards all of the vulnerable points. Once you identify the vulnerabilities, you
> would then move to a risk assessment by determining what the threat, potential
> impact and likelihoods are.
> On Wed, Nov 4, 2009 at 9:13 PM, St Clair, Jim
> <Jim.StClair () gt com<mailto:Jim.StClair () gt com>> wrote:
> Hi Chris,
>
> Yes they are often used interchangeably, causing confusion. If you think of the
> risk formula (threat X impact X likelihood = risk) then a vulnerability assessment
> focuses on more technical issues (either a port is closed or not) while a risk
> assessment should be more specific to a business/ process (this open port
> creates high risk in web services supporting health records).
>
> Both are useful, and should be conducted periodically. It's only unfortunate when
> a service provider calls it the latter but can only deliver the former.
>
> James A. St.Clair, CISM, PMP
> Senior Manager
> Global Public Sector
> Grant Thornton LLP
> T  703-637-3078
> F  703-637-4455
> C  703-727-6332
> E  jim.stclair () gt com<mailto:jim.stclair () gt com>
>
>
>
> The people in the independent firms of Grant Thornton International Ltd provide
> personalized attention and the highest quality service to public and private clients
> in more than 100 countries. Grant Thornton LLP is the U.S. member firm of Grant
> Thornton International Ltd, one of the six global audit, tax and advisory
> organizations. Grant Thornton International Ltd and its member firms are not a
> worldwide partnership, as each member firm is a separate and distinct legal
> entity.
> In the U.S., visit Grant Thornton LLP at http://www.grantthornton.com/.
> -----Original Message-----
>
> From: The EDUCAUSE Security Constituent Group Listserv
> [mailto:SECURITY () LISTSERV EDUCAUSE EDU<mailto:SECURITY () LISTSERV EDU
> CAUSE.EDU>] On Behalf Of Chris Kidd
> Sent: Wednesday, November 04, 2009 9:03 PM
> To:
> SECURITY () LISTSERV EDUCAUSE EDU<mailto:SECURITY@LISTSERV.EDUCAUSE.E
> DU>
> Subject: Vulnerability vs. Risk Assessments
>
> I'm having a hard time articulating the difference between these two types of
> assessments, so I'm hoping someone can clearly define them. Any thoughts are
> appreciated.
>
> Thanks,
> Chris
>
> Chris Kidd
> Chief Information Security and Privacy Officer
> The University of Utah
> 650 Komas Drive, Suite 102
> Salt Lake City, UT 84108
> Office: 801.587.9241
> Cell: 801.747.9028
> chris.kidd () utah edu<mailto:chris.kidd () utah edu>
>
> http://www.secureit.utah.edu
>
>
> In accordance with applicable professional regulations, please understand that,
> unless expressly stated otherwise, any written advice contained in, forwarded
> with, or attached to this e-mail is not intended or written by Grant Thornton LLP
> to be used, and cannot be used, by any person for the purpose of avoiding any
> penalties that may be imposed under the Internal Revenue Code.
> --------------------------------------------------------------------------
> This e-mail is intended solely for the person or entity to which it is addressed and
> may contain confidential and/or privileged information. Any review,
> dissemination, copying, printing or other use of this e-mail by persons or entities
> other than the addressee is prohibited. If you have received this e-mail in error,
> please contact the sender immediately and delete the material from any
> computer.