<?xml version="1.0" encoding="iso-8859-1"?>
<!-- generator="FeedCreator 1.7.2" -->
<rdf:RDF
	xmlns="http://purl.org/rss/1.0/"
	xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	xmlns:dc="http://purl.org/dc/elements/1.1/">
	<channel rdf:about="http://www.cyberguardians.org">
		<title>Joomla! powered Site</title>
		<description>Joomla! site syndication</description>
		<link>http://www.cyberguardians.org</link>
		<image rdf:resource="http://www.cyberguardians.org/images/M_images/joomla_rss.png" />
	   <dc:date>2010-03-12T20:14:37+01:00</dc:date>
		<items>
			<rdf:Seq>
				<rdf:li rdf:resource="http://www.cyberguardians.org/content/view/87/"/>
				<rdf:li rdf:resource="http://www.cyberguardians.org/content/view/86/"/>
				<rdf:li rdf:resource="http://www.cyberguardians.org/content/view/85/"/>
				<rdf:li rdf:resource="http://www.cyberguardians.org/content/view/83/"/>
				<rdf:li rdf:resource="http://www.cyberguardians.org/content/view/82/"/>
			</rdf:Seq>
		</items>
	</channel>
	<image rdf:about="http://www.cyberguardians.org/images/M_images/joomla_rss.png">
		<title>Powered by Joomla!</title>
		<link>http://www.cyberguardians.org</link>
		<url>http://www.cyberguardians.org/images/M_images/joomla_rss.png</url>
	</image>
	<item rdf:about="http://www.cyberguardians.org/content/view/87/">
		<dc:format>text/html</dc:format>
		<dc:date>2009-10-14T18:41:53+01:00</dc:date>
		<dc:source>http://www.cyberguardians.org</dc:source>
		<title>Outsourcing strikes again!</title>
		<link>http://www.cyberguardians.org/content/view/87/</link>
		<description>Seriously people when are the decision makers going to get a clue and realize that outsourcing never saves money in the long term and typically leads to something like this.Source: MSFT/Danger&amp;#39;s Servers Were Sabotaged (http://www.tomshardware.com/news/Sidekick-Data-Danger-Server-Sabotage,8850.html)After reading this story how can you consider outsourcing your critical infrastructure? Just ask T-Mobile how this feels, if they even recover from the negative PR. Outsourcing never delivers what is promised, it&amp;#39;s strictly for executives to enrich themselves in the short term and leaves someone else holding the bag when it hits the fan. The only time outsourcing makes sense is when its for short term project-based activities, otherwise your waiting on a potential time bomb.Also, why is everybody hating on Microsoft? Hitachi was the  expert  vendor in this fiasco performing the upgrade. They should have made damn sure they had a working backup copy prior to this major upgrade. What is it amateur hour? Is that what platinum support buys you these days? Another interesting aspect to this case now, is the hint of insider sabotage. How are you going to stop a disgruntled privileged user. The answer is, 99 times out of 100 you won&amp;#39;t. It is more luck if anything if you are able to prevent it from happening. In cases where you have decent logging you should at least be able to prove what happened after the fact, but good luck stopping it. The only thing that would work prevention wise is dual-controls, which would be very cumbersome. I would be interested to know if any company is going the extra mile of routinely interviewing their system admins to ensure they are not disgruntled. I doubt it. Anybody have some realistic solutions to prevent insider sabotage by trusted administrators?  </description>
	</item>
	<item rdf:about="http://www.cyberguardians.org/content/view/86/">
		<dc:format>text/html</dc:format>
		<dc:date>2008-08-12T14:19:52+01:00</dc:date>
		<dc:source>http://www.cyberguardians.org</dc:source>
		<title>Black Hat USA 2008</title>
		<link>http://www.cyberguardians.org/content/view/86/</link>
		<description>   So my first Blackhat is in the books. I thoroughly enjoyed it and got to learn quite a bit and get some networking done as well. My only two complaints would be first, that it was completely overcrowded on the 4th floor and that made getting to a session very difficult. The second being that classic conference paradox. A lot of the great topics with new material were presented by people with poor public presentation skills, whereas alot of the great speakers presented either old stuff or no real useful content. That aside it was a hoot.     I started the week attending a Malware Analysis class by Mandiant which was excellent. They basically crammed a 4 day course into 2 days, so it moved very quick and had lots of content and labs. The teachers were extremely knowlegeable and were able to convey the material well. My only suggestion would be that they should have spent more time on Ollydbg, but with the labs I can do that on my own time. They did spend extensive time using IDAPro, which helped me understand assembly code structures much better. I would highly recommend this course.    The first keynote speech by Ian Angell was very funny, but essentially preached an anti technology message which I think is mostly pointless considered the techno-geek audience. He did have some really fascinating quotes though. My first presentation was Bad Sushi: Beating Phishers at Their Own Game. While presenting nothing new, they did provide much comedy and insight into how spammers routinely try to rip each other off.  They also showed an insane toolkit that traffics in the spam underground that basically contains knock off sites for every large bank in the world. Of course the next session was the highly anticipated DNS Goodness by Dan Kaminsky. This has already been covered to death, so I will only add that it was worth the wait and Dan is the man. Next I attended The Four Horsemen of the Virtualization Security Apocalypse by Chris Hoff. This was probably the most useful and timely presentation I attended. Chris is a good speaker and I enjoyed how he detailed the current shortcomings of virtualization, while also pointing out VM myths as well. In a nutshell, the HA functionality is not there to do anything more then server/desktop virtualization. Beyond that, you are rolling the dice with your availability and network capacity. </description>
	</item>
	<item rdf:about="http://www.cyberguardians.org/content/view/85/">
		<dc:format>text/html</dc:format>
		<dc:date>2008-08-01T09:54:11+01:00</dc:date>
		<dc:source>http://www.cyberguardians.org</dc:source>
		<title>Book Review: Real Digital Forensics</title>
		<link>http://www.cyberguardians.org/content/view/85/</link>
		<description>    In continuing my tradition of reviewing books that are 2 or 3 years old, I have recently finished reading Real Digital Forensics by Keith Jones, Richard Bejtlich, and Curtis Rose. Yeah, I hate paying full price for a new book, but mostly its because I buy so many books that by the time I get around to actually reading them, its been a few years . Now on to the review.     With this group of experienced authors, it hard to imagine the book not being a success. While not spectacular, this books is very solid and fairly easy to read. I would have to say for someone looking to attend the SANS hacking and forensic courses, this book could easily fill the gap and save you thousands of dollars. One thing I really liked was that they did not waste time on any fluff chapters about the history of whatever, they just jumped right into the material. They also made it a point to show the differences between incident response on *nix vs. windows. All the chapters that focused on analysis and response were dead on. They included great case data on the book DVD, which helps you work through the sample cases as well. That is a huge feature that needs to become standard in security books, where feasible. Probably the standout feature of the book for me though, was their chapters on analyzing unknown binaries. By following along step by step through the cases, its helps turn something that is considered more of an art, into a science. They also include good coverage of doing a forensic analysis of a palm device, and included the requisite chapters on email investigation, registry analysis, and browser forensics. One thing that I took note of during the book, was the chapter on building a response toolkit. They pointed out that you need to use filemon to ensure none of your trusted tools access the victims system for resources and instead are using libraries from your toolset. The authors also did a good job of showing both open source and commerical tools throughout the book.</description>
	</item>
	<item rdf:about="http://www.cyberguardians.org/content/view/83/">
		<dc:format>text/html</dc:format>
		<dc:date>2008-04-16T11:52:28+01:00</dc:date>
		<dc:source>http://www.cyberguardians.org</dc:source>
		<title>Book Review: Virus Research &amp; Defense</title>
		<link>http://www.cyberguardians.org/content/view/83/</link>
		<description>    I recently finished reading The Art of Computer Virus Research and Defense (http://www.amazon.com/Computer-Virus-Research-Defense-Symantec/dp/0321304543/ref=sr_1_1?ie=UTF8 s=books qid=1208360397 sr=1-1)  and believe me that was no small task. Its easily one of the more technical books you will read. Thats a tribute to the author, Peter Szor, who in my opinion is one of the founding fathers of malware analysis. His knowledge on this subject is immense. To get the most out of the book though, you would be advised to have at least a basic understanding of C++ code, IA32 Assembly, and Windows API&amp;#39;s. It would be even better if you had some debugging and malware profiling experience. The books aim is to provide a thorough understanding of viruses by type, infection strategy and payload strategy, while explaining antivirus techniques and mitigation options.    Before I delve into the content too much, I would like to touch on some of the shortfalls of the book. First off, its not written in a traditional manner that could be easily used as a reference. It very much reads like a wiki or personal notes, which it is in effect, however that doesn&amp;#39;t make for easy reading. I also felt the first 3 chapters took up way too much space, which could have been used for more productive topics. I particularly hated Chapter 3, where every virus type and dependecy is simply listed out in no cohesive manner. My only other complaint would have to have been to limit the discussion of older, non-relevant viruses to a concept only and focus more on a deeper undertanding of more current threats. I would like to have seen several in depth case studies in the appendix(CodeRed, Sasser, Blaster, Bagel, Slammer, etc). I also wish it came in hard cover, because my paperback binding is already in shambles from frequent page turning and rereading    </description>
	</item>
	<item rdf:about="http://www.cyberguardians.org/content/view/82/">
		<dc:format>text/html</dc:format>
		<dc:date>2007-12-03T11:39:21+01:00</dc:date>
		<dc:source>http://www.cyberguardians.org</dc:source>
		<title>Another nail in the coffin for MD5</title>
		<link>http://www.cyberguardians.org/content/view/82/</link>
		<description>While collisions in MD5 hashes are nothing new, this most recent study by Wegner, Stevens, Lenstra (Article Link (http://www.win.tue.nl/hashclash/SoftIntCodeSign/) ) adds even more concern to the trustworthiness of an MD5 hash. If you can&amp;#39;t trust a signed executable, what can you trust? I think nothing. Their technique however requires much premeditation. Its not as if you can create a collision on an existing executable. To be effective in a malicious way, it would require that you create two executables up front with the same hash. This is done by appending 832 bytes of useless data to the existing executables. As you can imagine, this would make it very easy for a criminal to create two versions of software, one with a backdoor, that have the exact same MD5 hash. Of course, it would be easy for them to get the good one signed and then create a download site with the malicious one. While this is somewhat sophisticated, i could definitely see this being utilized by the hack for money crews. It doesn&amp;#39;t take much to get your software posted on some shareware download site. Also, I could see elite crews even trying to get drivers signed in this method. So what are we supposed to do about it? The authors of the paper suggest that SHA-1 is much more resistant to collisions and is a better alternative. Despite that, I think a search for a better hashing and signing algorithm get underway if it already hasn&amp;#39;t. I don&amp;#39;t think the threat is imminent by any means, but we will need something stronger in place within the next 2-3 years.</description>
	</item>
</rdf:RDF>
