Re: [Full-disclosure] Operation Bring Peace To Machines : New Info

[adam <adam@xxxxxxxxx>]

If by crazy, you mean a spammer: absolutely.

On Sat, Feb 18, 2012 at 4:45 PM, Jerome Athias <jerome@xxxxxxxxxxx> wrote:

>
> Sorry, I am just crazy
> \x90
>
>   Sujet: RE: Vulnerability conceptual map (UNCLASSIFIED)  Date : Sat, 18
> Feb 2012 16:37:45 -0500  De : WOLFKIEL, JOSEPH L CIV DISA PEO-MA
> <joseph.wolfkiel@xxxxxxxx> <joseph.wolfkiel@xxxxxxxx>  Répondre à :
> joseph.wolfkiel@xxxxxxxx  Pour : Multiple recipients of list
> <scap-dev@xxxxxxxx> <scap-dev@xxxxxxxx>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
> The NetD schemas were developed with that concept in mind.  We had hoped to 
> contribute the entire body of knowledge to the community and start building 
> automated communications based on the schemas and the relationships they 
> document.
>
> Using SCAP names and metadata tags was a key component and gave us some early 
> quick wins.
>
> I'd love to come to community consensus on ontological models for threat, 
> vulnerability, device, person, incident, event, workflow, etc that we could 
> start incorporating into SCAP standards (starting with ARF and ASR).
>
> Joseph L. Wolfkiel
> Engineering Group Lead
> DISA PEO MA/IA52(301) 225-8820Joseph.Wolfkiel@xxxxxxxx
>
>
> -----Original Message-----
> From: scap-dev@xxxxxxxx [mailto:scap-dev@xxxxxxxx <scap-dev@xxxxxxxx>] On 
> Behalf Of Davidson II, Mark S
> Sent: Friday, February 17, 2012 7:55 AM
> To: Multiple recipients of list
> Subject: RE: Vulnerability conceptual map
>
>
> I think the core of the topic is turning information into action. You might 
> have an ongoing attack, a vulnerability that needs to be patched, an 
> exploitable configuration, or one of many other security risks. You will have 
> varying degrees of information (as Kurt said) within each risk.
>
> Currently, an organization that can aggregate risk and threat information to 
> a single point  and have a human make a decision that is carried out in a 
> timely manner is among the more mature organizations. Many organizations do 
> not have all of their security information in a single place. Many 
> organizations, once they make a security decision, have a difficult time 
> implementing and communicating that decision.
>
> There's probably three areas of action:
> 1) Collect information and present it in a useful way
> 2) Make a decision based on that information
> 3) Carry out the decision
>
> #1 and #3 should be automated, and #2 should be where we spend most of our 
> effort. SCAP and CM are within the domain of Collect/Present, and I think 
> there have always been discussions about automating #3. Certain decisions in 
> #2 can be automated once you have #1 and #3, but that's a ways away (in my 
> opinion).
>
> Part of the difficulty of #3 is that networks will always be different. 
> Network management technologies will always be different. Let's say for the 
> sake of argument you want to block web traffic. How would you communicate 
> that? You'd have to, at a minimum, communicate the following: 
> inbound/outbound, applicable subnets/locations, & timeframe. Specifying a 
> port may not be enough. What about web traffic over non-standard ports? Then 
> you'd have to use an application aware firewall. Or, what if you are trying 
> to contain a segment of the network that has a router as it's only access?
>       You'd have to have a uniform language that could turn a thought "Block 
> web traffic for sales - they got ANOTHER virus" into a command that must be 
> usable by a variety of devices with functionality that may or may not 
> overlap, all in a network whose topography cannot be known when that language 
> is written. And you have to be able to 'remove' the block when you want.
>
> I guess that was just a long way of saying 'I agree'. There's a lot of work 
> to be done and much of it is unexplored (at least from a shared knowledge 
> perspective).
>
> -Mark
>
> -----Original Message-----
> From: scap-dev@xxxxxxxx [mailto:scap-dev@xxxxxxxx <scap-dev@xxxxxxxx>] On 
> Behalf Of Kurt Seifried
> Sent: Thursday, February 16, 2012 6:55 PM
> To: Multiple recipients of list
> Subject: Re: Vulnerability conceptual map
>
>
> On 02/16/2012 06:11 AM, Jerome Athias wrote:
> > For me,
> >
> > The problem:
> > we must quickly mitigate (and then remediate) vulnerabilities
> >
> > Existing scope:
> > we have actually (too much?) too complicated (and incomplete) standards
> > we have not-interoperable vulnerability tools
> >
> > My proposed solution:
> > we have to act quickly to deal with the problem
> > So the idea is to produce, and use an open, SIMPLIFIED, easy to
> > implement and use, standard
> > What i call IVIL v1.0
> >
> > And I would like to explain, demonstrate and validate my solution
>
> I find this discussion interesting. As I see it for a vulnerability
> (e.g. a technical issue that can be exploited to gain access or elevate
> privilege) we have several options:
>
> 1) fix it with a software update (which generally relies upon a
> vendor(s) shipping an update)
> 2) use a workaround (like change file permissions, disable the specific
> component that is affected, etc.)
> 3) disable the entire thing temporarily or permanently. For example by
> turning it off, restricting access to a limited subset of users,
> replacing it with something else, etc.
> 4) accept the risk and continue on (e.g. denial of service attacks, have
> a re-mediation routine to deal with it such as restarting it).
>
> actually if anyone else has other main options I'd love to hear from you.
>
> Now as I see it for option 1 you generally need your vendor to ship an
> update (or you need to have the source and patch it yourself, run it
> through testing/QE/QA/acceptance/etc.)
>
> For option 2 you need research, either done internally, by the vendor or
> a third party you use (e.g. iDefense, iSIGHT, etc.).
>
> For option 3 you need internal knowledge/support and/or support from
> option 2.
>
> For option 4 you need internal knowledge/support and/or support from
> option 2.
>
> So my concern has always been you either need a high degree of internal
> knowledge and/or external support in some form. All of this takes time
> if you want to minimize the impact (if you block web access every time a
> potential web browser vulnerability comes out you'd probably never have
> access to the web).
>
> What struck me as a best case scenario was having a limited/simplified
> protocol for immediate reaction and a more complete/slower protocol for
> long term reaction. I think it would be ideal if the protocol proposed
> could basically say which parts are required and which parts can be left
> for later.
>
> Food for thought.
>
> --
> Kurt Seifried Red Hat Security Response Team (SRT)
>
>
> ---------------------------------------------------------------
>
> To unsubscribe from this mailing list, please send an e-mail to 
> listproc@xxxxxxxx with the words "unsubscribe scap-dev" in the body. You
> will need to send this from the email account that you used to initially
> subscribe to scap-dev.
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
>
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/