Re: [ekmi] Your Data and the P2P Peril - InformationWeek article

[Allen <netsecurity@sound-by-design.com>]

Hi Arshad,

While what you suggest is excellent, it is not sufficient because 
of human nature. Hardly anyone reads policy, or what's worse, 
remembers the gritty little details, enforcement is frequently 
spotty and can become very cumbersome - who will guard the 
guardians? - education has the same limitations as policy and 
must be renewed regularly, and application layer encryption by 
itself does not provide a defense in depth.

The first element that must be looked at is not the technical 
tools and processes, but rather what is it that is the absolute 
minimum that must be protected? Reducing the volume of the data 
protected will, to some degree, reduce the risk.

The second element that needs to be looked at, and is getting 
almost no attention, is what do we do to assist those whose data 
is leaked? A brief example will help you see what I mean. I'm 
sure that we'd all agree that a driver's license number is an 
example of a critical data element and must be protected. 
However, no protection scheme applied after the initial 
deployment of a document with a driver's license number in it 
will provide retroactive protection.

So what can we do? I believe that the first step is designing 
protections for people, not the abstract data, and it is this 
that is the real goal of policy, enforcement, education, and 
encryption.

To do this we need to make sure there are processes in place to 
monitor, as best we can, the use of the data element in the 
environment, much like the credit card companies do for 
suspicious activity with your credit cards.

The second step is to provide transparency to the system so that 
if your driver's license number is used in an abusive manner you 
can get the record set straight without having to jump through a 
ton of hoops like you currently do to get your credit record 
fixed when your identity is stolen.

If these are done, then the whole bundle with application layer 
encryption is much more likely to be effective at accomplishing 
what our goal is - protecting people.

Now, before people start jumping up and down about this, the 
reality is that a change to this way of looking at the goals is 
only a matter of orientation and alignment to the real goals, not 
any change to the basic idea of using technology to assist in 
achieving our goals. True, it might mean some changes in the way 
we create policy, enforce policy, educate people, and do 
application layer, or other, encryption in terms of the logging 
functions and providing signatures for actions, when they 
occurred, where they occurred, and who did them in such a way 
that they cannot be repudiated. This is not all that hard to do, 
it would seem to me, at least in the corporate environment.

Doing the planning and executing on it will take lots of 
coordination and effort, but would somewhat mitigate against the 
current seesaw between the good guys and the bad guys in finding 
weaknesses in any given piece of software or hardware.

The reason I suggest thinking this way is that I saw (sorry, 
don't recall where) an estimate that given the current rate of 
creation versus stamping out of software bugs, which is a 
negative ~300K+ per year and it appears it may be getting worse, 
we will never create anything close to even good enough 
protection for people if we focus on the technology end rather 
than the people end. Be real clear, I am not advocating that we 
not do the technology, just that we focus our efforts more on people.

Best to all,

Allen Schaaf - CISSP, C|EH, C|HFI, CEI
Information Security Analyst - Business Process Analyst
Training & Instructional Designer - Sr. Documentation Developer
Certified Network Security Analyst and Intrusion Forensics 
Investigator - Certified EC-Council Instructor

Security is lot like democracy - everyone's for it but
few understand that you have to work at it constantly.






Arshad Noor wrote:
> Probably, one of the scarier articles I have read.  Portends
> more danger for the business environment as an entire generation
> growing up using such software migrate into the corporate world
> over the years.
> 
> While the solutions recommended in the article will help, they
> address only part of the problem.  Even Full Disk Encryption (FDE)
> is not a solution, as P2P networks operate only when a legitimate
> user has booted up the machine (by which time the FDE software is
> already decrypting everything for applications).
> 
> The only long-term solution with the smallest attack-surface is:
> Policy + Enforcement + Education + Application-level encryption
> requiring the authentication of users before decrypting content.
> 
> Arshad Noor
> StrongAuth, Inc.
> 
> Link to the article:
> http://www.informationweek.com/news/showArticle.jhtml?articleID=206903416&pgno=1&queryText= 
> 
> 
> Don't miss this side-bar that documents what the writer found
> when trolling P2P networks:
> 
> http://www.informationweek.com/story/showArticle.jhtml?articleID=206903417
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in 
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>