<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Information Security Blog &#124; Perimeter E-Security &#187; Banking Compliance</title>
	<atom:link href="http://perimeterusa.com/blog/tag/banking-compliance/feed/" rel="self" type="application/rss+xml" />
	<link>http://perimeterusa.com/blog</link>
	<description>News, Notes, and Opinions from the World of Information, Network, and Data Security</description>
	<lastBuildDate>Tue, 28 Jun 2011 13:44:08 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.4</generator>
		<item>
		<title>Picking a Sensible Mobile Password Policy</title>
		<link>http://perimeterusa.com/blog/picking-a-sensible-mobile-password-policy/</link>
		<comments>http://perimeterusa.com/blog/picking-a-sensible-mobile-password-policy/#comments</comments>
		<pubDate>Thu, 17 Mar 2011 15:55:06 +0000</pubDate>
		<dc:creator>ajaquith</dc:creator>
				<category><![CDATA[Blog Post]]></category>
		<category><![CDATA[ActiveSync]]></category>
		<category><![CDATA[Apple iPad]]></category>
		<category><![CDATA[Banking Compliance]]></category>
		<category><![CDATA[Banking Information Security]]></category>
		<category><![CDATA[Data Breach]]></category>
		<category><![CDATA[FINRA]]></category>
		<category><![CDATA[iPad]]></category>
		<category><![CDATA[iphone]]></category>
		<category><![CDATA[IT Security]]></category>
		<category><![CDATA[mobile security]]></category>

		<guid isPermaLink="false">http://perimeterusa.com/blog/?p=1180</guid>
		<description><![CDATA[Defining an enterprise mobile device passcode policy can be surprisingly difficult. Security managers must attempt to reconcile two opposing goals. They must create a passcode policy that is strong enough to protect the data on the device if it is lost or stolen, while not annoying users with needless length or complexity. These goals are hard to reconcile because employees use their devices in places they wouldn't use a PC: in the car, during their kids' football game, and during (shall we say) otherwise unproductive periods of the day. It's tempting to simply duplicate existing network security policies, but that is the wrong attitude. In this post, I'm going to describe a policy that complies with NIST's e-authentication Level 1 standard as described in Special Publication 800-63, "Electronic Authentication Guidelines." To cut to the chase: use an 8-digit numeric PIN that allows 8 incorrect guesses before permanently locking, can be idle a maximum of 15 minutes before locking, and allows a 2-minute inactivity grace period before requiring a passcode. For details, read on. Warning: a tiny bit of binary math lies ahead.]]></description>
			<content:encoded><![CDATA[<p><em>By Andrew Jaquith, Chief Technology Officer, Perimeter E-Security</em></p>
<p>Defining an enterprise mobile device passcode policy can be surprisingly difficult. Security managers must attempt to reconcile two opposing goals. They must:</p>
<ul>
<li>Create a passcode policy that is strong enough to protect the device if it is lost or stolen, while:</li>
<li>Not annoying users with needless length or complexity</li>
</ul>
<p>These goals are hard to reconcile because mobile devices like smartphones and tablets are personal, portable and convenient. Employees use their devices in places they wouldn’t use a PC: in the car, during their kids’ football game, and during (shall we say) otherwise unproductive periods of the day. It’s tempting to simply duplicate existing network security policies. The rationale goes something like this: smartphones and tables are nothing more than small PCs with antennas, so the password policies should be the same as for PCs. It’s easy to think that, but it’s the wrong attitude.</p>
<p>This whitepaper will describe the passcode policy Andrew recommends for mobile devices that comply with NIST’s e-authentication Level 1 guidelines as described in <a href="http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf">Special Publication 800-63, “Electronic Authentication Guidelines”</a>. The policy is reasonable, employee-friendly and highly usable, but strong enough to protect your company’s data. To cut to the chase, here’s what it is:</p>
<ul>
<li>8-digit numeric PIN</li>
<li>Simple PINs disallowed</li>
<li>Automatic lock after 15 minutes</li>
<li>Grace period of 2 minutes</li>
<li>Automatic wipe/permanent lock after eight wrong tries</li>
<li>No expiration</li>
</ul>
<p><a href="http://www.perimeterusa.com/knowledge-center/whitepapers#191">Click here</a> to read the whitepaper.</p>
]]></content:encoded>
			<wfw:commentRss>http://perimeterusa.com/blog/picking-a-sensible-mobile-password-policy/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>5 Data Security Predictions for 2011, Part 1 of 3: The Year of Living Dangerously</title>
		<link>http://perimeterusa.com/blog/5-data-security-predictions-for-2011-part-1-of-3-the-year-of-living-dangerously/</link>
		<comments>http://perimeterusa.com/blog/5-data-security-predictions-for-2011-part-1-of-3-the-year-of-living-dangerously/#comments</comments>
		<pubDate>Mon, 13 Dec 2010 21:06:23 +0000</pubDate>
		<dc:creator>ajaquith</dc:creator>
				<category><![CDATA[Blog Post]]></category>
		<category><![CDATA[Apple iPad]]></category>
		<category><![CDATA[Banking Compliance]]></category>
		<category><![CDATA[cybersecurity]]></category>
		<category><![CDATA[FINRA]]></category>
		<category><![CDATA[HITECH]]></category>
		<category><![CDATA[IT Security]]></category>
		<category><![CDATA[PCI DSS compliance]]></category>
		<category><![CDATA[Web Content Filtering]]></category>

		<guid isPermaLink="false">http://perimeterusa.com/blog/?p=1074</guid>
		<description><![CDATA[Last week I hosted a webinar called “5 Data Security Predictions for 2011.” For those of you who couldn't make the webinar, you can click on this link to view the replay. But if you are allergic to multimedia, I thought I'd summarize the topics I covered in the webinar here. This post covers the first item on the agenda: looking back at 2010.]]></description>
			<content:encoded><![CDATA[<p><em>By Andrew Jaquith, CTO of Perimeter E-Security</em></p>
<p>Last week I hosted a webinar called “5 Data Security Predictions for 2011.” The webinar was my first of many for Perimeter. It was lots of fun. I received some excellent questions from the audience. And I was gratified to see that we had several hundred registered attendees, too!</p>
<p>For those of you who couldn&#8217;t make the webinar, you can <a title="Data Security Predictions for 2011" href="http://www.perimeterusa.com/knowledge-center/webinars/on-demand#162" target="_blank">click on this link to view the replay</a>. But if you are allergic to multimedia, I thought I&#8217;d summarize the topics I covered in the webinar here. Last week&#8217;s webinar had three goals:</p>
<ul>
<li>To take a look back at the key security trends from 2010</li>
<li>To summarize the three most interesting security events of the last year, and the lessons we learned from them</li>
<li>To predict five data security trends for 2011</li>
</ul>
<p>This post covers the first item on the agenda: looking back at 2010.</p>
<p><strong>2010: The Year of Living Dangerously</strong></p>
<p><img class="alignnone" style="margin-left: 15px; margin-right: 15px;" src="http://upload.wikimedia.org/wikipedia/en/0/0b/Year_of_living_dangerously.jpg" alt="The Year of Living Dangerously (c) MGM" width="266" height="400" /></p>
<p>With many apologies to the actor formerly known as Mel Gibson, 2010 extended and deepened four trends we&#8217;ve seen in previous years. These should seem familiar to you, but there are a few twists that make them worthy of comment. In 2010, we observed:</p>
<ul>
<li><strong>Multiplying threats</strong>. It should come as no surprise to astute security professionals that malware has continued to proliferate. As with previous years, the number of circulating malware samples increased, by some counts, by a factor of 10 over the previous year. McAfee, for example, <a href="http://www.h-online.com/security/news/item/McAfee-Malware-still-on-the-rise-1138340.html" target="_blank">estimates the the number of samples has exceeded 50 million</a>. Other AV vendors have reported similar figures. The reason for the increases is simple: attackers are creating malware in smaller “batch sizes” (but with a larger number of batches) to evade detection by anti-virus engines. We are getting close to what I call “designer malware”: one signature, one victim. It&#8217;s not hard to understand why that strategy would work for the bad guys: if you can create unique malware for each victim, you can slide under the radar screen of the AV labs because the prevalence is nearly zero.  The low-and-slow attack vector for modern malware is a difficult challenge for everyone in the industry. And it is clearly successful. From Perimeter&#8217;s perspective as an MSSP, we have been tracking nearly 25 botnets that we&#8217;ve observed in action inside our customers&#8217; networks. We expect to track more incursions in the future.</li>
<li><strong>Migration of malware to the web</strong>. Hand-in-hand with the explosion in malware samples is the change in attack tactics. Instead of mailing infected attachments to their intended victims, the bad guys are much more likely to send e-mails with hyperlinks in them, which they then induce the recipient to click on. When clicked on, the link leads to a site that dynamically generates “drive-by” malware that is custom-made for the victim. Again, this goes back to the “designer malware” comment in the previous bullet. Some of the vendors I&#8217;ve worked with in the past (like WebSense) have noted the movement of malware away from e-mail and towards the web. As an MSSP with content filtering services, we&#8217;ve noticed it too. What it means for our customers is that web content-filtering becomes a lot more important than it used to be. Keeping inbound web traffic free from malware becomes as critical for security (indeed, <em>more</em> so) than the outbound stuff. Never mind whether Johnny in Accounting is spending too much time on ESPN&#8217;s website — you should care just as much if he&#8217;s getting 0wned when he goes there.</li>
<li><strong>Mobile security fears</strong>. From the iPad to those newfangled Android devices, every enterprise I&#8217;ve spoken with is worried about what modern Post-PC devices will do to their security posture. The urgency stems from two sources. First, managers want to know how to apply security controls to consumer-grade gear being brought into the workplace by employees and executives. They want to know what kind of password and data protection policies they need, and how to apply them to gear that isn&#8217;t named BlackBerry. Second, companies have concerns about the iPad in particular, because of business initiatives outside IT. Both scenarios are equally important. You can read about my perspective on Apple devices in <a href="http://www.forrester.com/rb/Research/apples_iphone_and_ipad_secure_enough_for/q/id/57240/t/2" target="_blank">this Forrester report</a>, which I wrote last summer, and in press accounts of it <a href="http://www.infosecurity-us.com/view/11447/forrester-says-iphone-ipad-now-secure-enough-for-enterprise-deployments/" target="_blank">here</a> and <a href="http://www.garagesalepreview.com/how-to-secure-ipads-for-corporate-use/" target="_blank">here</a>.</li>
<li><strong>More compliance pressures</strong>. Compliance and security are often conflated, but it&#8217;s best to view the kinds of security activities enterprises do for compliance purposes as a kind of tax they have to pay to stay in business. And every year, the “tax rate” goes up. For example, with the passage of the HITECH provisions of the American Recovery and Reinvestment Act (ARRA) of 2009 (aka “the stimulus bill”), health care Covered Entities (hospitals and providers of medical care) and their Business Associates (insurers, and other partners) are subject to more stringent rules on what they must do to safeguard personal protected health information (PHI). For retailers, recent revisions to the Payment Card Industry&#8217;s Data Security Standard (PCI-DSS) means that businesses that accept and process credit cards must tighten up their wireless networks, manage their server log files better and audit their web-facing applications. And in the banking sector, new rules from FINRA around social media means that employers must monitor their employees&#8217; use of Facebook and other outside websites.</li>
</ul>
<p>All four of these trends are top-of-mind concerns for just about every security professional and CISO I speak with. What is most interesting for me, as an observer, student of security and CTO is the mix of concerns. Threats and compliance pressures are perennial concerns: they are always with us, and always need tending to. The attackers won&#8217;t stop brewing up increasingly lethal doses of malware for consumption by the unwitting, and the auditors won&#8217;t put down their clipboards. But the new evergreen issues on this list — mobile security, and the increased lethality of web content — could cause rapid shifts in company security postures very quickly if they aren&#8217;t dealt with. How we respond to these two issues is the key.</p>
<p>And on that note, we&#8217;re at a good breaking point for this post. The next posts will summarize what we learned from 2010&#8242;s three most interesting events, and offer predictions for  2011.</p>
]]></content:encoded>
			<wfw:commentRss>http://perimeterusa.com/blog/5-data-security-predictions-for-2011-part-1-of-3-the-year-of-living-dangerously/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>New Red Flags Compliance Date For Some</title>
		<link>http://perimeterusa.com/blog/new-red-flags-compliance-date-for-some/</link>
		<comments>http://perimeterusa.com/blog/new-red-flags-compliance-date-for-some/#comments</comments>
		<pubDate>Fri, 07 Aug 2009 16:53:01 +0000</pubDate>
		<dc:creator>Perimeter</dc:creator>
				<category><![CDATA[Blog Post]]></category>
		<category><![CDATA[Banking Compliance]]></category>
		<category><![CDATA[Red Flags Rule]]></category>

		<guid isPermaLink="false">http://perimeterusa.com/blog/?p=307</guid>
		<description><![CDATA[The FTC has extended the Red Flags compliance date to November 1st for some organizations.]]></description>
			<content:encoded><![CDATA[<p>The FTC <a href="http://www.ftc.gov/opa/2009/07/redflag.shtm" target="_new">recently announced another postmonement</a> of the Red Flags enforcement. The new date is November 1, 2009, exactaly one year and 3 delayed dates later than the original enforcement date. The FTC says that the reason for the postmonement is for additional awareness especially for small organizations that do not know or understand their new requirements.</p>
<p>Red Flags is relatively new legislation designed to prevent identity theft by having companies implement formal, written programs to identify the warning signs, or “Red Flags” of identity theft. Many organizations are pushing back on the FTC saying they should not be required to comply. To date, I have heard of no group or company being given an exception. The American Bar Association (ABA) has recently filed a protest to the FTC on behalf of lawyers stating that they should not have to comply. The regulation states that all “Creditors” which are essentially any company who defers payment must comply. Obviously that is most companies, large and small.</p>
<p>Financial institutions are also required to comply, but their date did not change from the original November 1, 2008 date. According to Gartner, most of these organizations were already close or had policies in place anyway. So this is of greater impact to non-financial institutions right now.</p>
<p>If you&#8217;d like to learn more, <a href="/resources/webinars/recorded-webinar-red-flags-rule/">click here to view a webinar I hosted in May</a> about ensuring Red Flags compliance.</p>
]]></content:encoded>
			<wfw:commentRss>http://perimeterusa.com/blog/new-red-flags-compliance-date-for-some/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>VISA removes Heartland and RBS Worldpay from compliant vendor list</title>
		<link>http://perimeterusa.com/blog/visa-removes-heartland-and-rbs-worldpay-from-compliant-vendor-list/</link>
		<comments>http://perimeterusa.com/blog/visa-removes-heartland-and-rbs-worldpay-from-compliant-vendor-list/#comments</comments>
		<pubDate>Mon, 16 Mar 2009 21:14:51 +0000</pubDate>
		<dc:creator>Perimeter</dc:creator>
				<category><![CDATA[Blog Post]]></category>
		<category><![CDATA[Banking Compliance]]></category>
		<category><![CDATA[PCI DSS compliance]]></category>

		<guid isPermaLink="false">http://perimeterusa.com/blog/?p=585</guid>
		<description><![CDATA[Post regarding the recent removal of Heartland and RBS WorldPay from the VISA compliant vendors list.  ]]></description>
			<content:encoded><![CDATA[<p>VISA has removed Heartland and RBS Worldpay from their list of PCI DSS compliant vendors.  This effectively puts these processors on probation while they recertify their PCI DSS compliance using a QSA (Qualified Security Assessor).  They are still able to process VISA transactions during this time.  See <a href="http://www.bankinfosecurity.com/articles.php?art_id=1277&amp;pg=1" target="_new">Article</a></p>
<p>Credit card issuers will also be able to get at least partial reimbursement for reissuing credit cards and fees associated with customer fraud and losses.  This is good news because over 600 banks have already reported losses associateed with the Heartland breach.</p>
<p>This is one of the first signs of real &#8220;teeth&#8221; in the PCI DSS.  Card brands are taking these breaches seriously and placing the blame and responsibility at the feet of those at fault.  I think this is a good move for VISA.  Until now, PCI was beginning to look like a way to hide from responsibility and fend off lawsuits.  With this move, it just may move in the direction of compelling merchants and processors to take data security seriously for the purpose of eliminating consumer fraud.  Lets hope anyway.</p>
]]></content:encoded>
			<wfw:commentRss>http://perimeterusa.com/blog/visa-removes-heartland-and-rbs-worldpay-from-compliant-vendor-list/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

