{"id":1971,"date":"2010-03-04T00:00:00","date_gmt":"2010-03-04T00:00:00","guid":{"rendered":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/2010\/03\/04\/database-security-lacking-at-financial-services-firms\/"},"modified":"2021-12-30T11:40:23","modified_gmt":"2021-12-30T11:40:23","slug":"database-security-lacking-at-financial-services-firms","status":"publish","type":"post","link":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/2010\/03\/04\/database-security-lacking-at-financial-services-firms\/","title":{"rendered":"Database Security Lacking at Financial Services Firms"},"content":{"rendered":"<p>Sloppy operating practices across the financial services sector leave firms vulnerable to breaches that could expose sensitive data or put customers&#8217; and employees&#8217; privacy at risk, according to a new study from the Ponemon Institute.  The study, commissioned by enterprise software and consulting firm Compuware (NASDAQ: CPWR), identified several key areas where financial services companies could take a hit from loose data policies, including damage to the corporate brand and the erosion of consumer trust.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>&#8220;One of the most important things a company can do to assure their future success is to plug the holes in their security policies that were demonstrated in this study,&#8221; Larry Ponemon, head of the Ponemon Institute, said in a statement.<\/p>\n<p>For instance, the survey of top security officials at 80 large financial firms found that 83 percent use real data, such as credit card or account numbers, when developing and testing applications.<\/p>\n<p>For instance, 88 percent of the companies surveyed said they still use Social Security numbers as their primary identifier.<\/p>\n<p>http:\/\/www.esecurityplanet.com\/features\/article.php\/3868381\/Database-Security-Lacking-at-Financial-Services-Firms.htm<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[32],"tags":[],"class_list":["post-1971","post","type-post","status-publish","format-standard","hentry","category-statistics"],"_links":{"self":[{"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1971","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/comments?post=1971"}],"version-history":[{"count":1,"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1971\/revisions"}],"predecessor-version":[{"id":4458,"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1971\/revisions\/4458"}],"wp:attachment":[{"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=1971"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=1971"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.cybersecurityinstitute.com\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=1971"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}