<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" media="screen" href="/~d/styles/rss2full.xsl"?><?xml-stylesheet type="text/css" media="screen" href="http://feeds.feedburner.com/~d/styles/itemcontent.css"?><rss xmlns:feedburner="http://rssnamespace.org/feedburner/ext/1.0" version="2.0">
<channel>
<title>Palisade Magazine : Application Security Intelligence</title>
<link>http://palisade.plynt.com/</link>
<description>A publication by Paladion Networks</description>
<copyright>Copyright 2008</copyright>
<lastBuildDate>October 15, 2008 10:57 AM</lastBuildDate>
<docs>http://blogs.law.harvard.edu/tech/rss</docs> 

<feedburner:info uri="palisade" /><atom10:link xmlns:atom10="http://www.w3.org/2005/Atom" rel="hub" href="http://pubsubhubbub.appspot.com/" /><atom10:link xmlns:atom10="http://www.w3.org/2005/Atom" rel="self" type="application/rss+xml" href="http://palisade.paladion.net/rss20.xml" /><feedburner:browserFriendly>This is an XML content feed. It is intended to be viewed in a newsreader or syndicated to another site.</feedburner:browserFriendly><item>
<title>Quiz: Specifying life time for a webpage</title>
<description>&lt;p&gt;We have often come across the message &amp;#8220;Webpage has expired&amp;#8221; when attempting to access a recently accessed page. This message comes as a result of the web server specifying an expiration time for the webpage when it is stored on the browser&amp;#8217;s cache. How does a web server specify the life time for a page to the browser&amp;#8217;s cache?&lt;/p&gt;
&lt;ol type='a'&gt;
&lt;li&gt;Using the Expires header&lt;/li&gt;
&lt;li&gt;Using the Max-age directive along with Expires header&lt;/li&gt;
&lt;li&gt;Setting the Must-Revalidate header in the response&lt;/li&gt;
&lt;li&gt;All of the above&lt;/li&gt;
&lt;/ol&gt;&lt;div class="feedflare"&gt;
&lt;a href="http://feeds.feedburner.com/~ff/palisade?a=MclhCYOM6A8:xiw7W227ZWA:yIl2AUoC8zA"&gt;&lt;img src="http://feeds.feedburner.com/~ff/palisade?d=yIl2AUoC8zA" border="0"&gt;&lt;/img&gt;&lt;/a&gt; &lt;a href="http://feeds.feedburner.com/~ff/palisade?a=MclhCYOM6A8:xiw7W227ZWA:7Q72WNTAKBA"&gt;&lt;img src="http://feeds.feedburner.com/~ff/palisade?d=7Q72WNTAKBA" border="0"&gt;&lt;/img&gt;&lt;/a&gt;
&lt;/div&gt;</description>
<link>http://feedproxy.google.com/~r/palisade/~3/MclhCYOM6A8/</link>
<guid isPermaLink="false">http://palisade.plynt.com/issues/2008Oct/quiz/</guid>
<category>Quiz</category>
<pubDate>October 15, 2008 10:57 AM</pubDate>
<feedburner:origLink>http://palisade.plynt.com/issues/2008Oct/quiz/</feedburner:origLink></item>
<item>
<title>SAP Baseline Security Audit</title>
<description>A SAP Baseline Security Audit tells enterprises how their SAP security posture stacks up against industry best practices. The Baseline Security Audit is the first step in a comprehensive security audit program and is ideal for generating a quick win early. This article outlines the areas covered under the SAP Baseline Security Audit we perform.&lt;div class="feedflare"&gt;
&lt;a href="http://feeds.feedburner.com/~ff/palisade?a=JSFEnr2FwbU:xNA0z5VPHws:yIl2AUoC8zA"&gt;&lt;img src="http://feeds.feedburner.com/~ff/palisade?d=yIl2AUoC8zA" border="0"&gt;&lt;/img&gt;&lt;/a&gt; &lt;a href="http://feeds.feedburner.com/~ff/palisade?a=JSFEnr2FwbU:xNA0z5VPHws:7Q72WNTAKBA"&gt;&lt;img src="http://feeds.feedburner.com/~ff/palisade?d=7Q72WNTAKBA" border="0"&gt;&lt;/img&gt;&lt;/a&gt;
&lt;/div&gt;</description>
<link>http://feedproxy.google.com/~r/palisade/~3/JSFEnr2FwbU/</link>
<guid isPermaLink="false">http://palisade.plynt.com/issues/2008Oct/sap-security-audit/</guid>
<category>Best Practices</category>
<pubDate>October 15, 2008 10:42 AM</pubDate>
<feedburner:origLink>http://palisade.plynt.com/issues/2008Oct/sap-security-audit/</feedburner:origLink></item>
<item>
<title>Defeating Encryption in Some Thick Clients</title>
<description>While testing thick client applications we sometimes encounter the client encrypting pieces of the request. At such times, many of our variable manipulation attacks are foiled. To overcome this barrier, there are several techniques. Here&amp;#8217;s one of the methods we tried for a recent thick client application test.&lt;div class="feedflare"&gt;
&lt;a href="http://feeds.feedburner.com/~ff/palisade?a=RaCIc031Ky8:BorvrvrfaMU:yIl2AUoC8zA"&gt;&lt;img src="http://feeds.feedburner.com/~ff/palisade?d=yIl2AUoC8zA" border="0"&gt;&lt;/img&gt;&lt;/a&gt; &lt;a href="http://feeds.feedburner.com/~ff/palisade?a=RaCIc031Ky8:BorvrvrfaMU:7Q72WNTAKBA"&gt;&lt;img src="http://feeds.feedburner.com/~ff/palisade?d=7Q72WNTAKBA" border="0"&gt;&lt;/img&gt;&lt;/a&gt;
&lt;/div&gt;</description>
<link>http://feedproxy.google.com/~r/palisade/~3/RaCIc031Ky8/</link>
<guid isPermaLink="false">http://palisade.plynt.com/issues/2008Oct/defeating-thick-client-encryption/</guid>
<category>Technical</category>
<pubDate>October 15, 2008 10:19 AM</pubDate>
<feedburner:origLink>http://palisade.plynt.com/issues/2008Oct/defeating-thick-client-encryption/</feedburner:origLink></item>
<item>
<title>Database Links Security</title>
<description>Database links (DBLinks in Oracle) are a technique for one database to connect to a remote database and execute queries. The originating database uses an account in the remote destination database to connect. This connection thus uses a username and password of an account in the destination database. The connection has the privileges of the account that&amp;#8217;s used in the destination database.&lt;div class="feedflare"&gt;
&lt;a href="http://feeds.feedburner.com/~ff/palisade?a=cWcgmq-TxSo:x97cP8MNBtY:yIl2AUoC8zA"&gt;&lt;img src="http://feeds.feedburner.com/~ff/palisade?d=yIl2AUoC8zA" border="0"&gt;&lt;/img&gt;&lt;/a&gt; &lt;a href="http://feeds.feedburner.com/~ff/palisade?a=cWcgmq-TxSo:x97cP8MNBtY:7Q72WNTAKBA"&gt;&lt;img src="http://feeds.feedburner.com/~ff/palisade?d=7Q72WNTAKBA" border="0"&gt;&lt;/img&gt;&lt;/a&gt;
&lt;/div&gt;</description>
<link>http://feedproxy.google.com/~r/palisade/~3/cWcgmq-TxSo/</link>
<guid isPermaLink="false">http://palisade.plynt.com/issues/2008Oct/dblinks-security/</guid>
<category>Features</category>
<pubDate>October 15, 2008 10:04 AM</pubDate>
<feedburner:origLink>http://palisade.plynt.com/issues/2008Oct/dblinks-security/</feedburner:origLink></item>
<item>
<title>Quiz: Proposal to amend Same Origin Policy</title>
<description>&lt;p&gt;Same origin policy of browser prevents scripts loaded in one domain to access resource from another domain. However, this policy imposes several limitations to Web 2.0 apps and restricts interactivity between sites. A new proposal has been formed by W3C, to incorporate Web 2.0 developer&amp;#8217;s demands, by allowing cross site requests. Which among the following is the said proposal? &lt;/p&gt;
&lt;ol type='a'&gt;
&lt;li&gt;Configuring Domain Authorization Rules on the application server side &lt;/li&gt;
&lt;li&gt;Access Control for Cross-site Requests &lt;/li&gt;
&lt;li&gt;Configuring Application level ACL &lt;/li&gt;
&lt;/ol&gt;&lt;div class="feedflare"&gt;
&lt;a href="http://feeds.feedburner.com/~ff/palisade?a=NjQP7rUYVEM:WSGCj2umTYw:yIl2AUoC8zA"&gt;&lt;img src="http://feeds.feedburner.com/~ff/palisade?d=yIl2AUoC8zA" border="0"&gt;&lt;/img&gt;&lt;/a&gt; &lt;a href="http://feeds.feedburner.com/~ff/palisade?a=NjQP7rUYVEM:WSGCj2umTYw:7Q72WNTAKBA"&gt;&lt;img src="http://feeds.feedburner.com/~ff/palisade?d=7Q72WNTAKBA" border="0"&gt;&lt;/img&gt;&lt;/a&gt;
&lt;/div&gt;</description>
<link>http://feedproxy.google.com/~r/palisade/~3/NjQP7rUYVEM/</link>
<guid isPermaLink="false">http://palisade.plynt.com/issues/2008Jul/quiz/</guid>
<category>Quiz</category>
<pubDate>July  9, 2008 08:46 PM</pubDate>
<feedburner:origLink>http://palisade.plynt.com/issues/2008Jul/quiz/</feedburner:origLink></item>
<item>
<title>Cache Control Directives Demystified</title>
<description>Many years ago, HTTP 1.1 introduced specialized Cache Control directives to control the behavior of browser caches and proxy caches. These were a refinement over the HTTP 1.0 headers that programmers were using to control the behavior of caches. Though these directives are several years old, we still see them being used incorrectly. In this article, we explain the meaning and relevance of the most important cache control directives.&lt;div class="feedflare"&gt;
&lt;a href="http://feeds.feedburner.com/~ff/palisade?a=mroz2Orx0BU:00ydA4jpMY8:yIl2AUoC8zA"&gt;&lt;img src="http://feeds.feedburner.com/~ff/palisade?d=yIl2AUoC8zA" border="0"&gt;&lt;/img&gt;&lt;/a&gt; &lt;a href="http://feeds.feedburner.com/~ff/palisade?a=mroz2Orx0BU:00ydA4jpMY8:7Q72WNTAKBA"&gt;&lt;img src="http://feeds.feedburner.com/~ff/palisade?d=7Q72WNTAKBA" border="0"&gt;&lt;/img&gt;&lt;/a&gt;
&lt;/div&gt;</description>
<link>http://feedproxy.google.com/~r/palisade/~3/mroz2Orx0BU/</link>
<guid isPermaLink="false">http://palisade.plynt.com/issues/2008Jul/cache-control-attributes/</guid>
<category>Technical</category>
<pubDate>July  9, 2008 02:43 PM</pubDate>
<feedburner:origLink>http://palisade.plynt.com/issues/2008Jul/cache-control-attributes/</feedburner:origLink></item>
<item>
<title>The Payment Application Data Security Standard (PA DSS)</title>
<description>PA DSS fills a gap in the more well known PCI DSS standard. Today, we&amp;#8217;ll discuss this lesser-known standard. Remember that the biggies of the credit card industry put their heads together and came up with Payment Card Industry Data Security Standard (PCI DSS). Their aim was to protect the &amp;#8220;Cardholder&amp;#8217;s&amp;#8221; data. PCI DSS was first released in 2005 and then revised in October 2006. PCI DSS has a few requirements that talk about securing web applications that deal with cardholder&amp;#8217;s data.&lt;div class="feedflare"&gt;
&lt;a href="http://feeds.feedburner.com/~ff/palisade?a=nBiUmacE1EQ:u0pqNG-G75s:yIl2AUoC8zA"&gt;&lt;img src="http://feeds.feedburner.com/~ff/palisade?d=yIl2AUoC8zA" border="0"&gt;&lt;/img&gt;&lt;/a&gt; &lt;a href="http://feeds.feedburner.com/~ff/palisade?a=nBiUmacE1EQ:u0pqNG-G75s:7Q72WNTAKBA"&gt;&lt;img src="http://feeds.feedburner.com/~ff/palisade?d=7Q72WNTAKBA" border="0"&gt;&lt;/img&gt;&lt;/a&gt;
&lt;/div&gt;</description>
<link>http://feedproxy.google.com/~r/palisade/~3/nBiUmacE1EQ/</link>
<guid isPermaLink="false">http://palisade.plynt.com/issues/2008Jul/padss/</guid>
<category>Best Practices</category>
<pubDate>July  9, 2008 02:38 PM</pubDate>
<feedburner:origLink>http://palisade.plynt.com/issues/2008Jul/padss/</feedburner:origLink></item>
<item>
<title>Defend against Reverse Engineering</title>
<description>Software reverse engineering is the technique of getting the original source code from the binary. Competitors might use reverse engineering to figure out how you implemented that cool feature. Crackers might use it to see how they can bypass your license policy. Game cheats use reverse engineering, well, to cheat.&lt;div class="feedflare"&gt;
&lt;a href="http://feeds.feedburner.com/~ff/palisade?a=sS-lWJzOd5Q:cU-xYyOaLks:yIl2AUoC8zA"&gt;&lt;img src="http://feeds.feedburner.com/~ff/palisade?d=yIl2AUoC8zA" border="0"&gt;&lt;/img&gt;&lt;/a&gt; &lt;a href="http://feeds.feedburner.com/~ff/palisade?a=sS-lWJzOd5Q:cU-xYyOaLks:7Q72WNTAKBA"&gt;&lt;img src="http://feeds.feedburner.com/~ff/palisade?d=7Q72WNTAKBA" border="0"&gt;&lt;/img&gt;&lt;/a&gt;
&lt;/div&gt;</description>
<link>http://feedproxy.google.com/~r/palisade/~3/sS-lWJzOd5Q/</link>
<guid isPermaLink="false">http://palisade.plynt.com/issues/2008Jul/defend-reverse-engineering/</guid>
<category>Features</category>
<pubDate>July  9, 2008 11:34 AM</pubDate>
<feedburner:origLink>http://palisade.plynt.com/issues/2008Jul/defend-reverse-engineering/</feedburner:origLink></item>
<item>
<title>Quiz: Cross Site Printing</title>
<description>&lt;p&gt;What is Cross Site Printing?&lt;/p&gt;
&lt;ol type="a"&gt;
  &lt;li&gt;A typo for Cross Site Scripting &lt;/li&gt;
  &lt;li&gt;A new Printing technology from Microsoft &lt;/li&gt;
  &lt;li&gt;A new attack that prints to your internal printers when you visit a website &lt;/li&gt;
  &lt;li&gt;None of these &lt;/li&gt;
&lt;/ol&gt;&lt;div class="feedflare"&gt;
&lt;a href="http://feeds.feedburner.com/~ff/palisade?a=4m9uaNEnpAs:obKHhXbi9WQ:yIl2AUoC8zA"&gt;&lt;img src="http://feeds.feedburner.com/~ff/palisade?d=yIl2AUoC8zA" border="0"&gt;&lt;/img&gt;&lt;/a&gt; &lt;a href="http://feeds.feedburner.com/~ff/palisade?a=4m9uaNEnpAs:obKHhXbi9WQ:7Q72WNTAKBA"&gt;&lt;img src="http://feeds.feedburner.com/~ff/palisade?d=7Q72WNTAKBA" border="0"&gt;&lt;/img&gt;&lt;/a&gt;
&lt;/div&gt;</description>
<link>http://feedproxy.google.com/~r/palisade/~3/4m9uaNEnpAs/</link>
<guid isPermaLink="false">http://palisade.plynt.com/issues/2008Jun/quiz/</guid>
<category>Quiz</category>
<pubDate>June 10, 2008 03:30 PM</pubDate>
<feedburner:origLink>http://palisade.plynt.com/issues/2008Jun/quiz/</feedburner:origLink></item>
<item>
<title>CSRF - The hidden menace</title>
<description>Cross Site Request Forgery (also known as XSRF, CSRF, Sea Surf, Session Riding, and Cross Site Reference Forgery) is an attack that tricks the victim into taking some action on the vulnerable application without the victim&amp;#8217;s knowledge. This can happen when the victim visits a webpage that contains a malicious request, which then performs the chosen action on behalf of the victim.&lt;div class="feedflare"&gt;
&lt;a href="http://feeds.feedburner.com/~ff/palisade?a=cTp4BuJHedM:MrZRs3v4Hpk:yIl2AUoC8zA"&gt;&lt;img src="http://feeds.feedburner.com/~ff/palisade?d=yIl2AUoC8zA" border="0"&gt;&lt;/img&gt;&lt;/a&gt; &lt;a href="http://feeds.feedburner.com/~ff/palisade?a=cTp4BuJHedM:MrZRs3v4Hpk:7Q72WNTAKBA"&gt;&lt;img src="http://feeds.feedburner.com/~ff/palisade?d=7Q72WNTAKBA" border="0"&gt;&lt;/img&gt;&lt;/a&gt;
&lt;/div&gt;</description>
<link>http://feedproxy.google.com/~r/palisade/~3/cTp4BuJHedM/</link>
<guid isPermaLink="false">http://palisade.plynt.com/issues/2008Jun/cross-site-request-forgery/</guid>
<category>Technical</category>
<pubDate>June 10, 2008 03:00 PM</pubDate>
<feedburner:origLink>http://palisade.plynt.com/issues/2008Jun/cross-site-request-forgery/</feedburner:origLink></item>
<item>
<title>Mobile Banking - Threats and Mitigation</title>
<description>In my previous article, I had explained the two common mobile banking architectures and exchange of information using one of the architectures. In this article, I&amp;#8217;ll be explaining the threats observed and an ideal process to overcome these threats. The explanation would be based on the information exchange for the architecture discussed in my previous article. Each phase has the threats mentioned and a secure process to ensure these threats are mitigated.&lt;div class="feedflare"&gt;
&lt;a href="http://feeds.feedburner.com/~ff/palisade?a=xi7_o1yAnoU:T_eb0wDGKy8:yIl2AUoC8zA"&gt;&lt;img src="http://feeds.feedburner.com/~ff/palisade?d=yIl2AUoC8zA" border="0"&gt;&lt;/img&gt;&lt;/a&gt; &lt;a href="http://feeds.feedburner.com/~ff/palisade?a=xi7_o1yAnoU:T_eb0wDGKy8:7Q72WNTAKBA"&gt;&lt;img src="http://feeds.feedburner.com/~ff/palisade?d=7Q72WNTAKBA" border="0"&gt;&lt;/img&gt;&lt;/a&gt;
&lt;/div&gt;</description>
<link>http://feedproxy.google.com/~r/palisade/~3/xi7_o1yAnoU/</link>
<guid isPermaLink="false">http://palisade.plynt.com/issues/2008Jun/mobile-banking-threats/</guid>
<category>Best Practices</category>
<pubDate>June 10, 2008 02:30 PM</pubDate>
<feedburner:origLink>http://palisade.plynt.com/issues/2008Jun/mobile-banking-threats/</feedburner:origLink></item>
<item>
<title>URL Redirection Flaw</title>
<description>Harry gets an email from his bank stating that he has received some promotion offers so he should click on the link below to avail those offers. Harry ensures that the site is authentic by checking the name of his bank in the URL as he is aware of phishing attacks. He finds it to be a genuine URL of the bank, so he clicks the link. On clicking the link the login page of his bank is displayed to him. He enters his username and password on the login page. He gets an error page saying &amp;#8220;The server is unable to process your request&amp;#8221;.&lt;div class="feedflare"&gt;
&lt;a href="http://feeds.feedburner.com/~ff/palisade?a=FusHAZRygyU:7uhU2KaZzx0:yIl2AUoC8zA"&gt;&lt;img src="http://feeds.feedburner.com/~ff/palisade?d=yIl2AUoC8zA" border="0"&gt;&lt;/img&gt;&lt;/a&gt; &lt;a href="http://feeds.feedburner.com/~ff/palisade?a=FusHAZRygyU:7uhU2KaZzx0:7Q72WNTAKBA"&gt;&lt;img src="http://feeds.feedburner.com/~ff/palisade?d=7Q72WNTAKBA" border="0"&gt;&lt;/img&gt;&lt;/a&gt;
&lt;/div&gt;</description>
<link>http://feedproxy.google.com/~r/palisade/~3/FusHAZRygyU/</link>
<guid isPermaLink="false">http://palisade.plynt.com/issues/2008Jun/url-redirection-flaw/</guid>
<category>Features</category>
<pubDate>June 10, 2008 02:00 PM</pubDate>
<feedburner:origLink>http://palisade.plynt.com/issues/2008Jun/url-redirection-flaw/</feedburner:origLink></item>
<item>
<title>Quiz: Safe Authentication Controls</title>
<description>&lt;p&gt;Which of the following is/are required as safe authentication  controls at login page?&lt;/p&gt;
&lt;ol&gt;
  &lt;li&gt;Enable SSL&lt;/li&gt;
  &lt;li&gt;Define acceptable Inputs&lt;/li&gt;
  &lt;li&gt;Use Salted Hash technique&lt;/li&gt;
  &lt;li&gt;Disable password save and AutoComplete/fill-in &lt;/li&gt;
  &lt;li&gt;All of them&lt;/li&gt;
&lt;/ol&gt;&lt;div class="feedflare"&gt;
&lt;a href="http://feeds.feedburner.com/~ff/palisade?a=aFktnGnro1A:njIMWC977AQ:yIl2AUoC8zA"&gt;&lt;img src="http://feeds.feedburner.com/~ff/palisade?d=yIl2AUoC8zA" border="0"&gt;&lt;/img&gt;&lt;/a&gt; &lt;a href="http://feeds.feedburner.com/~ff/palisade?a=aFktnGnro1A:njIMWC977AQ:7Q72WNTAKBA"&gt;&lt;img src="http://feeds.feedburner.com/~ff/palisade?d=7Q72WNTAKBA" border="0"&gt;&lt;/img&gt;&lt;/a&gt;
&lt;/div&gt;</description>
<link>http://feedproxy.google.com/~r/palisade/~3/aFktnGnro1A/</link>
<guid isPermaLink="false">http://palisade.plynt.com/issues/2007Jun/quiz/</guid>
<category>Quiz</category>
<pubDate>June 15, 2007 11:29 AM</pubDate>
<feedburner:origLink>http://palisade.plynt.com/issues/2007Jun/quiz/</feedburner:origLink></item>
<item>
<title>Common mistakes in two-tier applications</title>
<description>In previous articles, we have talked about  some of the &lt;a href="/issues/2006Mar/thick-client-attacks/"&gt;attack&lt;/a&gt; techniques and &lt;a href="/issues/2006May/thick-client-defenses/"&gt;defenses&lt;/a&gt; that are possible with two-tier  applications. An important thing to note in two-tier applications is that a thick-client application running on the user&amp;rsquo;s machine directly connects to the  database. This means that local machine can directly connect to the database. In  this article, we look at some of the common mistakes made in configuring and  developing two-tier applications which can render the database vulnerable to  attacks from users.&lt;div class="feedflare"&gt;
&lt;a href="http://feeds.feedburner.com/~ff/palisade?a=472t9b98lts:jEhoHtFzW_E:yIl2AUoC8zA"&gt;&lt;img src="http://feeds.feedburner.com/~ff/palisade?d=yIl2AUoC8zA" border="0"&gt;&lt;/img&gt;&lt;/a&gt; &lt;a href="http://feeds.feedburner.com/~ff/palisade?a=472t9b98lts:jEhoHtFzW_E:7Q72WNTAKBA"&gt;&lt;img src="http://feeds.feedburner.com/~ff/palisade?d=7Q72WNTAKBA" border="0"&gt;&lt;/img&gt;&lt;/a&gt;
&lt;/div&gt;</description>
<link>http://feedproxy.google.com/~r/palisade/~3/472t9b98lts/</link>
<guid isPermaLink="false">http://palisade.plynt.com/issues/2007Jun/two-tier-app-mistakes/</guid>
<category>Technical</category>
<pubDate>June 15, 2007 11:27 AM</pubDate>
<feedburner:origLink>http://palisade.plynt.com/issues/2007Jun/two-tier-app-mistakes/</feedburner:origLink></item>
<item>
<title><![CDATA[Virtualization &ndash; the promised land?]]></title>
<description>Someone somewhere is still getting compromised after investing a lot in  security. Now there&amp;#8217;s something called &amp;#8216;virtualization&amp;#8217; which seems to be some  kind of a promised land &amp;ndash; a &amp;#8216;solution&amp;#8217; to all these security problems. It&amp;rsquo;s  being adopted rapidly across multiple organizations just because its &amp;#8216;secure&amp;#8217;.  So what is virtualization? Why is it such a craze? Is it really that secure? Is  there no way to compromise it? Are we finally 100% safe? A lot of pertinent  questions there &amp;ndash; let&amp;#8217;s try and answer them, shall we?&lt;div class="feedflare"&gt;
&lt;a href="http://feeds.feedburner.com/~ff/palisade?a=TB1pF3SXI_Q:9MZHU8f4Jm4:yIl2AUoC8zA"&gt;&lt;img src="http://feeds.feedburner.com/~ff/palisade?d=yIl2AUoC8zA" border="0"&gt;&lt;/img&gt;&lt;/a&gt; &lt;a href="http://feeds.feedburner.com/~ff/palisade?a=TB1pF3SXI_Q:9MZHU8f4Jm4:7Q72WNTAKBA"&gt;&lt;img src="http://feeds.feedburner.com/~ff/palisade?d=7Q72WNTAKBA" border="0"&gt;&lt;/img&gt;&lt;/a&gt;
&lt;/div&gt;</description>
<link>http://feedproxy.google.com/~r/palisade/~3/TB1pF3SXI_Q/</link>
<guid isPermaLink="false">http://palisade.plynt.com/issues/2007Jun/virtualization/</guid>
<category>Features</category>
<pubDate>June 15, 2007 11:23 AM</pubDate>
<feedburner:origLink>http://palisade.plynt.com/issues/2007Jun/virtualization/</feedburner:origLink></item>



</channel>
</rss>

