Sort of confirmation Morocco is the motherland for spammers + phishers On Sun, Feb 19, 2012 at 12:28 AM, adam <[email protected]> wrote:
> If by crazy, you mean a spammer: absolutely. > > On Sat, Feb 18, 2012 at 4:45 PM, Jerome Athias <[email protected]> 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 >> <[email protected]> <[email protected]> Répondre à : >> [email protected] Pour : Multiple recipients of list >> <[email protected]> <[email protected]> >> >> 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) [email protected] >> >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected] <[email protected]>] 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: [email protected] [mailto:[email protected] <[email protected]>] 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 >> [email protected] 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/
