Balkanization Working Group Presentation Notes

Presented by Adam Shostack

Introduction

We presented first the reasons we see for Balkanization. We feel that it is important to understand these reasons, so that we can address the concerns that exist. The presentation was organized into 'Why Balkanize,' 'Mitigators,' and 'Next Steps.'

Why Balkanize

1. Fear of publicity
   This is the worry that a reporter will call and say 'Why is Acme giving this information to hackers?' (One of the working group members admitted to providing feedback to hacker web sites, as one of the only accessible sources of data around, and later demonstrated exactly this fear by asking to remain anonymous in the minutes of the group.)
2. The data is classified.
3. Liability Issues
4. Copyright Issues: Is the source data copyrighted?
5. Increased Accuracy
   There is a perception that private databases, under the control of the organization, contain information that has been more rigorously vetted.
6. Investment (sunk costs)
7. Control
   Issues of availability, retention, and bureaucratic concerns all fall under control.
8. Ability to Tailor
   Local databases are designed and modified to handle local requirements. Local databases can also evolve more quickly than shared ones, as schema can change for organizational need.
9. Unwanted disclosure
   The issue of information leaking before an advisory or patch as well as the interesting information that can be gleaned from query analysis.
10. No easy mechanism to share
11. The perception of 'my database is my advantage'
12. Use of a database to control production processes requires a database under my control, contains much business process information which is not going to be shared.

Mitigators

1. Fear of publicity
   • Respected Sponsor such as NIST, CERIAS, or NCSC can allow organization to point to standard practices
   • A common practice, even without a sponsor, can gain recognition. (A la Linux?)
   • Industry Organizations such as CARO can provide cover
   • This is a gradual change process
2. The data is classified.
   We felt that this is unlikely to change, but a Freedom of Information Act Request might mitigate it somewhat.
3. Liability Issues
   We need the meeting minutes to help expand here. Also, I've added new laws, clarification of duty and precedent from Eric's? presentation, which I believe was an oversight, but I may be wrong. --Adam.
   • Review contents of the database
   • License for End User
   • Multiple Use
   • Restricted Access
   • $ to defend self
   • Indemnification for submitter or repository
   • Anonymous or pseudononymous posting
   • New laws
   • Clarification of Duty to vendors/creators of OS
   • Precedent may allow database holder to lower costs of defense
4. Copyright Issues: Is the source data copyrighted?
   • Fair Use
   • Permission
   • Standard Licenses, such as a GNU or BSD release of rights in an announcement
   • $ to purchase permissions, license
   • NIST model of pointers, not copies of data
5. Increased Accuracy
   • Moderation
   • Peer Review
   • Reputation System
   • Right of rebuttal, a la credit databases
   • spend $ to verify
   • Research contributions
6. Investment (sunk costs)
   • Share costs
   • a demonstrated business case would be great
   • Sponsorship by contribution. Recognition for those who provide first data
7. Control
   • Mirrors, backups, cds of databases alleviate concerns about availability
   • increased perceived value of having a database which many experts contribute to
   • opportunity to expand sphere of control and range of infighting
8. Ability to Tailor
   • Make database simple
   • use a common enumeration or terminology
   • flexible import/export mechanisms make it easier to get data into my format
9. Unwanted disclosure
   • Partial Disclosure (control, limit contributions)
   • Distribute copies of DB to allow queries to be local
10. No easy mechanism to share We left this to other groups.
11. The perception of 'my database is my advantage'
    • flexibility
    • response time
    • no requirement for complete sharing
    • Change area of competition (eg, virus market, other "mature markets")
12. Use of a database to control production processes requires a database under my control, contains much business process information which is not going to be shared.

    Next Steps

    • Organization(s)
    • Schema
      
      • Full schema, or
      • CVE
        • Russ Cooper to handle
        • Netect to adopt in db
        • CVE-10001 is the (term to follow) of a trojan horse TCP wrappers being made available.
        For time reasons we didn't mention that CVE-1 has been reserved for "Moth in vaccuum tube" and that we left 10,000 to handle the space between then and now.
        Russ was going to do this from a web page, but it occurs to me that we may allocate CVE-10002 for 'script kiddie depletes integer space with 2 lines of perl' and consider a quencher of some type. Sure, its not a real killer, but I'll have trouble working with CVE-87072844398248392432, or even CVE-870728. --Adam

    ---

    Adam Shostack
    Last modified: Sat Jan 23 15:57:11 EST 1999