Risk Assessments

This is great. Spot on. I was referring to a broader type of
risk 
assesemnt where if you haven't implemented formalized or
well 
defined controls, you could consider the entire entity to be

subject to risk. As you rightly point out its the impact of
that 
and the likelihood thats the key to the risk definition.Same

page.....great post.  

On Mon, 16 Oct 2006 19:53:48 -0400 Clint Laskowski 
<clintrobotic.com> wrote:
>mrsecmgrhushmail.com wrote:
>
>How about the COBIT or ITIL control objectives? It seems
to me 
>these are
>more in line with the rest of the industry (read non-
security).
>
>My reply:
>
>But they are not measurements of risk, per se. Anyone
who 
>addresses risk for
>a living understands risk is a function of likelihood
and impact 
>(regardless
>if you are an information security manager, an airline
pilot, or a 

>parent).
>Any 'risk assessment' methodology that does not link
risk to 
>likelihood and
>impact is flawed... unless you define risk differently
up-front. 
>If you
>assess an environment by comparing it to 17799, HIPAA,
COBIT, 
>ITIL, COSO,
>GLBA, etc., then you conducting a gap analysis, not a
risk 
>assessment. I AM
>NOT saying a gap analysis is not useful, or that a risk
assessment 

>is the
>be-all end-all. All I'm saying a gap analysis is not a
risk 
>assessment. In
>fact, I often question the value of a risk assessment
unless it is 

>done with
>very specific definitions up-front. Otherwise, the
results are 
>often so
>wide-ranging as to be useless. In most cases, a gap
analysis will 
>yield more
>actionable results. Unfortunately, it is a circle
because many of 
>the
>'standards' ask if a risk assessment is done on a
regular basis 
>(e.g., once
>per year, etc.). So, to close the gap analysis you have
to do a 
>risk
>assessment anyway.
>
>-- Clint
>
>---
>. CLINT LASKOWSKI, CISSP
>. Information Security Consultant
>. linkedin: http://www.link
edin.com/in/claskowski
>. email: clintrobotic.com
>. member: ' or 1=1--
>
>
>-----Original Message-----
>From: listbouncesecurityfocus.com 
>[mailto:listbouncesecurityfocus.com] On
>Behalf Of mrsecmgrhushmail.com
>Sent: Monday, October 16, 2006 5:39 PM
>To: markcurphey.com; clintrobotic.com; psrcsecurityfocus.com;
>jason.bevisfoundstone.com
>Subject: RE: Risk Assessments
>
>How about the COBIT or ITIL control objectives? It seems
to me 
>these are
>more in line with the rest of the industry (read non-
security).
>
>On Fri, 13 Oct 2006 13:34:17 -0400 Jason.BevisFoundstone.com
>wrote:
>>Like Clint I like using the NIST approach too,
however Mark 
>brings
>
>>up
>>some great questions some of which I usually address
by modifying 

>
>>the
>>methodology.
>>
>>The main item I don't like about the NIST 800-30 is
that the 
>>questions
>>are not comprehensive enough, so to remedy that I
use a 
>>combination of
>>the NIST and ISO 17799 models when gathering
information and 
>>performing
>>the assessment.
>>
>>How long does an RA take?  That varies greatly on
the scope, size 

>
>>of the
>>company, geography, etc.  However, I find its easier
to break it 
>>up into
>>two week projects whereas one week is spent doing
interviews and 
>>the 2nd
>>week is spent analyzing the data and reporting for
each project.  

>
>>
>>Depending on the detail and the scope a typical
private sector 
>>company
>>may do a RA globally once or twice a year and
sometimes they will 

>
>>also
>>pick a critical business component or application
and do a more 
>>complete
>>RA in those areas.  
>>
>>Its really a catch all question that you threw out
because many
>>companies have software or a quick RA method based
on excel 
>spread
>>sheets or an in house application.  Some of these
assessments can 

>
>>be
>>done in a couple of days, however, I find most of
these are 
>>inadequate
>>and missing substantial details.
>>
>>My suggestions for improvements are:
>>-Automate the scoring process
>>-Define a standard threat library that is reusable
>>-Create a standard and consistent library of
vulnerabilities that 

>
>>can be
>>reused
>>-Define a more metric drive approach to rating
assets, threats, 
>>and
>>vulnerabilities.
>>
>>Jason Bevis
>> 
>>
>>-----Original Message-----
>>From: listbouncesecurityfocus.com 
>>[mailto:listbouncesecurityfocus.com]
>>On Behalf Of Mark Curphey
>>Sent: Thursday, October 12, 2006 8:27 AM
>>To: clintrobotic.com; psrcsecurityfocus.com
>>Subject: RE: Risk Assessments
>>
>>Thanks great post. I am obviously fishing for more
info here as I 

>
>>am
>>trying to understand a consensus of what does and
doesn't work in 

>
>>the
>>real world
>>
>>How do you determine what requires a risk assessment
in the first 

>
>>place?
>>What do you and don't you like about NIST 800-30?
>>How long does it take on average (I know average is
relative) to 
>>conduct
>>an assessment (give me some ranges)?
>>How could it be improved?
>>
>>
>>
>>-----Original Message-----
>>From: Clint Laskowski [mailto:clintrobotic.com]
>>Sent: Thursday, October 12, 2006 7:30 AM
>>To: 'Mark Curphey'; psrcsecurityfocus.com
>>Subject: RE: Risk Assessments
>>
>>I use the 9-step NIST approach (see NIST sp800-30):
>>
>>1. System Characterization - understand what you are
assessing; 
>>this
>>includes development of rating systems and standard
definitions
>>
>>2. Threat Identification - what could happen
(source, 
>motivation)?
>>
>>3. Vulnerability Identification - how could it
happen?
>>
>>4. Control Analysis - what is preventing threats
from exploiting
>>vulnerabilities today? implicit risk less existing
controls is 
>>residual
>>risk
>>
>>
>>5. Likelihood Determination - how likely is it that
a threat will
>>exploit an uncontrolled vulnerability; a function of
threats and
>>vulnerabilities less existing controls
>>
>>6. Impact Analysis - what will be the
business/mission impact if 
>a
>>specific threat exploits a specific vulnerability; a
function of 
>>the
>>(asset) value of the system
>>
>>7. Risk Determination - a function of likelihood and
impact, 
>>usually
>>determined using a risk matrix
>>
>>8. Control Recommendations - what automated or
manual controls 
>can 
>
>>be
>>used to prevent, detect, eliminate, transfer or
reduce risks to 
>an
>>acceptable level? again, implicit risk less existing
and new 
>>controls
>>equals residual risk
>>
>>9. Documentation and presentation
>>
>>Risk is therefore a function of threats,
vulnerabilities and 
>>assets
>>(R=T*V*A)
>>
>>Calculating risks in a quantitative way can only be
done for the 
>>most
>>simplistic systems and is not realistic, IMHO. I
prefer 
>>qualitative
>>assessments.
>>
>>Example:
>>=======
>>
>>1. System Characterization - A critical server in a
computer 
>>closet with
>>an overhead water pipe running through it
(definitions and rating
>>schemes excluded in this example).
>>
>>2. Threat Identification (one example) - Water -
electronic 
>>hardware
>>such as a server is susceptible to damage and
destruction from 
>>water.
>>
>>3. Vulnerability Identification (related example) -
Spray or leak 

>
>>from
>>the overhead water pipe could come in contact with
the electronic
>>hardware resulting in damage or destruction
>>
>>4. Control Analysis - water pipe sleeve holds
moisture and very 
>>minor
>>leaks (preventive), server case (preventive),
existing moisture 
>>sensors
>>on floor of computer closet (detective), daily
visits to computer 

>
>>closet
>>means leaks may be seen (detective); so, some
controls exist, but 

>
>>they
>>would not provide enough time to react if the pipe
has a major 
>>leak or
>>bursts
>>
>>5. Likelihood Determination - no history of a leak
or spray; but
>>plumbing in building is 20 years old. temperature on
pipe in 
>>winter does
>>drop and freezing, expanding and bursting are
possible. 
>Likelihood
>>determination: low
>>
>>6. Impact Determination - worst case scenario -
critical server 
>>and data
>>are destroyed due to water; impact determination:
extremely high.
>>
>>7. Risk determination - low likelihood and extreme
impact result 
>>in a
>>medium-high risk determination; above this
organization's risk 
>>tolerance
>>
>>8. Controls recommendation - consider re-routing
water pipe; 
>>relocating
>>computer closet; protective (plastic) shrouds;
moisture sensors 
>>above
>>servers; etc.
>>
>>9. documentation - not applicable to this example.
>>
>>I hope this helps; feel free to expand, add,
critique, etc.
>>
>>-- Clint
>>
>>---
>>. CLINT LASKOWSKI, CISSP
>>. Information Security Consultant
>>. linkedin: http://www.link
edin.com/in/claskowski
>>. email: clintrobotic.com
>>. member: ' or 1=1--
>>
>>
>>-----Original Message-----
>>From: listbouncesecurityfocus.com 
>>[mailto:listbouncesecurityfocus.com]
>>On Behalf Of Mark Curphey
>>Sent: Wednesday, October 11, 2006 6:23 PM
>>To: psrcsecurityfocus.com
>>Subject: Risk Assessments
>>
>>A few of us folks from the list are working on an
open source 
>>community
>>project that will be released early next year. 
>>
>>One topic of current discussion is Risk Assessment. 
>>
>>What do you think are the current problems with RA
methodologies 
>>like
>>OCTAVE, TRIDENT OR CRAMM ?
>>
>>What is the basic process you use to do your RA's?
>>
>>Is it something like;
>>
>>-Define Target of Evaluation / Assumptions /
Requirements -Define 

>
>>System
>>Assets -Determine Threats -Determine Vulnerabilities
-Determine 
>>Business
>>Impacts -Determine Risk
>>
>>What do you use to determine risk; CIA or something
else?
>>
>>Is anyone quantifying risk is is everyonone using
qualitative
>>approaches?
>
>
>
>Concerned about your privacy? Instantly send FREE secure
email, no 

>account
>required
>http://www.hushmai
l.com/send?l=480
>
>Get the best prices on SSL certificates from Hushmail
>https://www.hushssl.com
?l=485



Concerned about your privacy? Instantly send FREE secure
email, no account required
http://www.hushmai
l.com/send?l=480

Get the best prices on SSL certificates from Hushmail
https://www.hushssl.com
?l=485