[Oisf-wg-ruleslanguage] On encrypting rule files (xml example)

[Scott MacGregor]

No matter how you do this.. the end user /engineer will be able to
decrypt the rule off the box. Its not ok to run a "black box" on my
network, and it will never be ok.. That being said, I would recommend
digital signing as an authorship verification.. much later in
development.

NDA will be required for the certificate issuance in any manner if we
end up down this route.

Just an Idea(tm).. If we came up with our own way of distributing
rules.. requiring certs (X509), a SSL server, common NDA template, a
common web retrieval API with front end example app (rubyrails app/php
app/py egg) etc.. open source and document the exchange process so
that $soft, redhat, my own company could all be rule "sources"
..maybe... oinkmaster++ .. NDA with each rule source server etc...

If OSIF wanted to continue down the encryption in the rule file: = >
It would take a significant effort to a accomplish rule distributions
that are signed by each individuals public key for rule issuance. This
could cause bursting high volume requests that require a lot of
encryption processing on the OSIF servers on "new rule days/pre-patch
Mondays".

Reminder: A significant problem not faced with other applications is
that IDS are often place out-of-band and are not capable of
communicating back to a online website for bi-directional
communications during operation.



On Mon, Sep 21, 2009 at 2:28 AM, Brian Rectanus <brectanu at gmail.com> wrote:
> I agree we should not do it.  What does it give us, really?  The end
> user that gets these rules can still decrypt it and send it to
> whomever they wish, so the rules are not "protected" other than from
> someone that should not have had access to download them in the first
> place and that should just be protected in another manner (ie do not
> let unauthorized users download them).  The same could be handled (and
> better, I think) through a legal document/NDA.
>
> -B
>
> On Sun, Sep 20, 2009 at 5:02 PM, Scott MacGregor <shadowbq at gmail.com> wrote:
>> My personal opinion :=> "lets please not do this.." (sniffle)
>>
>> ---
>> FYI: There are some decent articles on encrypting xml data..
>>
>> http://dotnetslackers.com/articles/xml/XMLEncryption.aspx
>>
>> ---
>>
>> IDEAS:
>>
>> If the organization as whole wants to encrypt some of the rules so
>> that we can get "pre-release patches" this would be my route:
>>
>> Create an CA and X.509 certificate chain for the root signing of
>> Asymmetric encryption of the rules.
>>
>> Have anyone/company who wants to have access to utilize encrypted
>> rules register for a certificate with the OSIF organization
>> Certificate Authority.
>>
>> Anyone without a certificate can utilize the /rule file/ without
>> error, but the system just skips the encrypted rules.
>>
>> Allow multiple X.509 chains for rule decryption, such that an
>> organization can create its own encryption cert and have "propriety
>> rules" mixed with "org subscription rules" and "org community rules".
>>
>> This is never going to be trivial....
>>
>> Having something like this.. rough sketch of an xml encrypted rule file...
>>
>> The below uses RSA to decode off a keychain named OSIF
>>
>> Reference: http://www.w3.org/TR/xmlenc-core/
>>
>> <?xml version="1.0" standalone="no"?>
>> <rules>
>>  <rule>
>>    <title>OSIF Pre-Release $soft GDI overflow </title>
>>    <vulnerability>
>>      <title>$soft GDI overflow </title>
>>      <para>This space can have a more detailed description.</para>
>>      <para>This space can have additional description.</para>
>>      <releasedate>01-01-2039</releasedate>
>>      <url>https://www.osif.org/rules/reference/[$sid]</url>
>>      <author>OSIF blah....</author>
>>          <status>Limited Public Release</status>
>>    </vulnerability>
>>    <tracking>
>>      <version>1.0</version>
>>      <classtype>bad-unknown</classtype>
>>      <priority>1</priority>
>>          <id>112273645111111</id>
>>    </tracking>
>>    <EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element"
>> xmlns="http://www.w3.org/2001/04/xmlenc#">
>>          <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5" />
>>          <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
>>                <KeyName>osif</KeyName>
>>          </KeyInfo>
>>          <CipherData>
>>                <CipherValue>
>>                <![CDATA[
>>                1892379812730981273091287301298731290837019283709
>>                1238712098379182736897126398761293876192876912876
>>                ahsfiouy23978r7ry98ef79237rhi7r9287ry23478rh98472
>>                98u2h9r7h946rt92783987ghf9478f82h978f2978fg78429f
>>                ]]>
>>                </CipherValue>
>>          </CipherData>
>>    </EncryptedData>
>>  </rule>
>> </rules>
>>
>> ~~~~ shadowbq
>> _______________________________________________
>> Oisf-wg-ruleslanguage mailing list
>> Oisf-wg-ruleslanguage at openinfosecfoundation.org
>> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-wg-ruleslanguage
>>
> _______________________________________________
> Oisf-wg-ruleslanguage mailing list
> Oisf-wg-ruleslanguage at openinfosecfoundation.org
> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-wg-ruleslanguage
>