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

[not here <zpamh0l3@xxxxxxxxx>]

Sort of confirmation Morocco is the motherland for spammers + phishers

On Sun, Feb 19, 2012 at 12:28 AM, adam <adam@xxxxxxxxx> wrote:

> 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/
>

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