Re: More on garbage

From: Anne & Lynn Wheeler (lynn_at_garlic.com)
Date: 06/14/05 

Date: 14 Jun 2005 09:01:39 -0600

daw@taverner.cs.berkeley.edu (David Wagner) writes:
> My real motivation was to get people to stop thinking of a
> one-size-fits-all view of security properties, and to recognize that
> the set of security properties needed for each application is
> application-dependent: there is no one answer that will fit all
> systems. The one-size-fits-all view leads to fallacies, such as
> thinking that anything that turns an integrity problem into an
> availability problem is useless (it isn't necessarily useless;
> whether it is useful or not depends on the application's security
> requirements). Trying to say things like "for this broad class of
> systems, availability is always critical" (an exaggeration for
> effect) strikes me as heading towards the border of dangerous
> thinking; even if it hasn't yet crossed that border, it might be
> more productive to focus on specific applications and understand
> their security requirements individually.

security proportional to risk
http://www.garlic.com/~lynn/2001h.html#61 Security Proportional To Risk

to some extent credit card limit is set proportional to risk
assesement.

some gov. stuff wants 30 years confidentiality ... and some commercial
stuff has talked about 50 years confidentiality. lot of that stuff may
have very low availability requirements ... say a lot less than the
1-800 system wanted or a 911 system ... around five-nines ... less
than 5 minutes per year outage.

when we were doing ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp

we talked to people doing 1-800 system. they had an implementation
that was claimed to be a hundred percent up when it was up ... but
periodically needed to be taken down for maint ... which could be
several hrs. they could blow a century worth of downtime (based on 5
minutes per year outage) in a single maintenance session.

some DUKPT ... minor refernece
http://www.garlic.com/~lynn/aadsm19.htm#36

can live with standard DES ... $100 or less transaction that might
have a subsecond lifetime. the risk (possibly $100) if the attacker
can brute force the DES key in less than the lifetime of the
transaction (possibly second or less). and there isn't necessarily a
confidentiality requirement ... purely an integrity requirement. The
issue is what is the probability that an attacker is going to try and
spend a couple million to brute force a derived DES key in less than
second for a $100 return ... and how many times might they try it.

basel talks about risk adjusted capital ...
http://www.bis.org/

the capital reserve amount (as security) set aside is related to the
calculated risk. one of the battles in the new basel-ii requirements
was whether or not to keep the *new* qualitative data section ...
http://www.bis.org/publ/bcbsca.htm#pgtop

when risk adjusted capital requirements up until then had been based
primarily on quantitative numbers. the qualitative data stuff
disappeared from basel-ii .. but quite a bit of what had been in the
qualitative data section now appears in sox.

the pain scenario for security

P ... privacy (or sometimes confidentiality)
A ... authentication
I ... integirty
N ... non-repudiation

can have different requirements for the individual components in
different environments ... aka short-lived transactions might have
little or no confidentiality requirement ... but higher integrity
requirements ... especially if the transaction carries very little
personally identifiable information (PII) ... slightly related recent
post
http://www.garlic.com/~lynn/aadsm19.htm#35

there was some reference recently to digital certificate based
infrastructures focusing heavily on whether 1024 bit or 2048 bit key
was needed ... and it was mostly meaningless; that the attackers are
finding it easier to exploit other parts of the infrastructure than
brute force attacks on the keys (various institutions worried about
30-50 year confidential lifetimes might be more worried about it).

i've written some about most infrastructures out there should be more
worried about the overall integrity of the authentication process than
possibly the difference between 1024 and 2048 bit keys used for
authentication purposes (again this key length distinction may make a
whole lot more difference to institutions worried about 50 year
confidentiality ... than institutions worried about much shorter
period authentication operations) ... or generalizing the "security
proportional to risk" phrase to "parameterized risk management".
"Parameterized risk management" could make authorization decisions
(analogous to the simple credit card limit) dynamically on a
transaction by transaction basis given a broad range of risk factors.

Rather than creating static set of security requirements ... allow the
various components of security to be relatively fluid ... and then
make dynamic decisions about approval or non-approval based on the
specific security component levels for a specific operation.

some of this may be the boyd influence
http://www.garlic.com/~lynn/subboyd.html#boyd
http://www.garlic.com/~lynn/subboyd.html#boyd2

who advocated rapid dynamic adjustment to fluid and changing
enviornment ... rather than trying to establish static, cast in
concrete operations. 

-- 
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

Relevant Pages

  • RE: Why Easy To Use Software Is Putting You At Risk
    ... I do agree that the additions and changes to Solarius will make it more secure and that this is good. ... Why Easy To Use Software Is Putting You At Risk ... instead I would say that the view that security is ... Four Construction Workers Died after Crane Collapse in Toledo, ...
    (Security-Basics)
  • RE: Why Easy To Use Software Is Putting You At Risk
    ... Why Easy To Use Software Is Putting You At Risk ... Four Construction Workers Died after Crane Collapse in Toledo, ... The first issue to address is yes you found a vulnerability and it was ... a Security Discussion board, that is what we do here. ...
    (Security-Basics)
  • More food for thought
    ... Basic Risk Analysis ... I have taken a position that the professional security community in general ... has and will continue to fail because they are operating under the same ... storing those backups safely offsite in a secure location on a daily basis. ...
    (comp.security.misc)
  • More food for thought
    ... Basic Risk Analysis ... I have taken a position that the professional security community in general ... has and will continue to fail because they are operating under the same ... storing those backups safely offsite in a secure location on a daily basis. ...
    (comp.os.ms-windows.nt.admin.security)
  • Re: Risk metrics
    ... security management life cycle. ... more objective snapshot of a company's risk posture. ... > traditional risk metrics in pen-tests cannot be ... >> vulnerability works, and if an exploit is in the ...
    (Pen-Test)
Quantcast