Re: [ISN] "Increased Cyber Awareness"

From: InfoSec News (isnat_private)
Date: Wed Sep 19 2001 - 11:45:36 PDT

  • Next message: InfoSec News: "[ISN] Worm not linked to attacks"

    Forwarded from: JohnE37179at_private
    
    Is it Time to Rethink the Fortress Paradigm for Security?
    
    Building fortresses and redoubts as secure enclaves in a dangerous
    territory have been a part of the security culture since before
    gunpowder. The strategy has as its central tenet the building of
    strong walls with very limited access as means of keeping the enemy
    outside and the good guys inside.  Whether as a walled city, a castle
    on the Rhine, the Alamo, or a fort on the American frontier, all
    utilized the same strategy. In more modern times this strategy was
    expressed in the Maginot Line and can be found in the employment of
    computer firewalls and the use of encryption.
    
    The core element to this strategy is keeping the bad guys on the
    outside and the good guys on the inside. What happens when the bad
    guys are already on the inside? We see this happen time and time
    again. We see it when the bad guy enters the inside through the use of
    identity fraud, social engineering or otherwise disguised as a
    customer, employee or authorized user. We saw it in the attack on
    America on September 11, 2001.
    
    The failure of security was that all of the weapons were turned
    outward when the enemy was already inside. This enemy not only was
    already inside, but utilized our own resources against us. The weapons
    were of domestic manufacture and use, the targets were inside, the
    perpetrators were inside and well integrated into our infrastructure.
    Nothing but motive came from outside.
    
    We know that 80% of our losses to fraud come from inside. We operate
    in a culture and an economy that depends on open doors for citizens
    and customers.  As the digital age morphed us from a face-to-face
    economy to one of digital anonymity we failed to adjust our underlying
    security strategy to deal with the enemy within. We perpetuated the
    myth that the enemy would attack from outside the system.
    
    We give great lip service to the concept of trust, but we try to
    create trust by directing our strategies to defining those who are
    trustworthy as being those inside and those untrustworthy are defined
    by being outside. By doing this we are perpetuating a myth. If we are
    to design and implement effective security strategies, we must
    concentrate on recognizing the enemy within our walls. It may be that
    we don’t need walls at all. We talk about building trusted systems,
    but systems cannot be trusted. The concept is really meaningless.
    Trust is a concept that applies to users not systems.
    
    Trust is earned, not conferred by fiat. Trust belongs to individuals,
    not systems. Individual users come and individual users go. Systems do
    not exist in vacuums, they include users. If the trusted user is not
    part of the system, the system by definition cannot be trusted.
    
    Building trust for users cannot be finessed by simply accepting all
    customers or employees as trusted ab initio. It is not enough to
    accept an employer’s word or the use of wallet information. This is
    giving the keys to the kingdom to the bad guy and then throwing open
    the doors.
    
    Trust must be established not once, but every time a user is
    encountered.  Giving any applicant a token, private key or certificate
    without first establishing beyond a doubt that the user may be trusted
    only perpetuates the illusion of trust were no trust really exists.
    
    It is time to move away from the fortress, which has become obsolete
    and fashion a new paradigm that builds security around the trusted
    individual user instead of the fortress system.
    
    John Ellingson
    CEO
    Edentification, Inc.
    
    
    
    -
    ISN is currently hosted by Attrition.org
    
    To unsubscribe email majordomoat_private with 'unsubscribe isn' in the BODY
    of the mail.
    



    This archive was generated by hypermail 2b30 : Wed Sep 19 2001 - 18:21:22 PDT