Organizations need to strike a balance in permitting their staff to use so-called "shadow IT" that can help them be more productive while still exerting enough control over the technology to ensure that sensitive data is protected, says security expert Mac McMillan.

The controversy over Hillary Clinton's use of private servers for both her personal and sensitive government email while she served as secretary of the U.S. Department of State spotlights some important issues involving staff attempting to utilize unsanctioned "shadow IT" tools to perform their jobs, which is a common practice, McMillan says in an interview with Information Security Media Group.

"In the estimates I've seen ... 20 percent to 35 percent of the applications that organizations find in their environments is shadow IT, or applications that users have enabled for one business purpose or another," says McMillan, CEO of the security consulting firm CynergisTek and a former U.S. Department of Defense data security specialist.

"In most cases, they're not using it to get around something or to 'beat' something ... The most often given reason they turn to an application that's part of the shadow IT world is that they're literally trying to get their job done, and trying to find a better, more effective, more efficient way of doing it," he says.

Organizations in all sectors should expect that staff members will turn to shadow IT, so they need to address the risks involved.

"You need to strike a balance between giving your staff flexibility to be innovative and to use different tools that may make them more productive ... more efficient, and may produce a better product, while at the same time providing [the organization] with a level of control so that you don't go sideways in terms of a compliance requirement ... [safeguarding] financial information or protecting patient information," he says.

Critical Steps

Organizations need to communicate to their staff their policies regarding the use of "shadow IT" such as software-as-a-service, infrastructure-as-a-service, cloud storage and personal mobile devices connecting to their networks, he stresses.

To help address security, McMillan says, organizations should, for example, consider establishing "a secure way for people to access these different SaaS tools in an environment where it doesn't put the rest of the network at risk. Perhaps you create a part of your network that allows [users] to log into that."

Other mitigating controls, he says, include restricting the functionality of some applications that could put data at risk, forcing encryption before files can be stored and deploying data loss prevention tools.

"Most of these [shadow] apps are not the problem," he says. "If there are ways the user could acquire these applications in a safe manner, have them set up properly and use them in a smart fashion, then they're just like any other app."

In the interview, McMillan also discusses:

Common types of "shadow IT" found in healthcare entities and other organizations; When shadow IT is used with malicious intent; The use of shadow IT in other government agencies beyond the Department of State.

McMillan is co-founder and CEO of CynergisTek Inc. an Austin, Texas-based consultancy specializing in information security and regulatory compliance in healthcare, financial services and other industries. He has more than 30 years of security and risk management experience, including 20 years at the Department of Defense, most recently at the Defense Threat Reduction Agency. He is also chair of the Healthcare Information and Management Systems Society's privacy and security task force.

Anti-Malware , Forensics , Fraud

SWIFT to Banks: Who You Gonna Call? Hackbusters Team Will Battle Bank Hackers, SWIFT Promises Mathew J. Schwartz (euroinfosec) • July 11, 2016    

After banks get hacked, what's the best way to get them to come clean and share information about their attackers' tools and techniques, to help other financial firms avoid becoming the next victim? Start by making the hacked bank an offer of expert assistance that they can't afford to refuse.

See Also: From Authentication to Advanced Attack Vectors: Top Trends in Cybercrime in Q1 2016

At least, that seems to be part of the impetus behind interbank messaging network SWIFT creating an internal digital forensics and customer security intelligence team, as well as contracting with cybersecurity specialists BAE Systems and Fox-IT to assist. SWIFT says the group will help hacked banks investigate intrusions and fraudulent SWIFT transfers as well as share attack-related intelligence - anonymously - with other banks (see SWIFT Deduction: Assume You've Been Hacked).

The bank-owned, Brussels-based SWIFT cooperative, formally known as the Society for Worldwide Interbank Financial Telecommunication, announced the launch of the new team on July 11 as part of a customer security program unveiled by CEO Gottfried Leibbrandt in May. The program was a reaction to persistent security criticism leveled at SWIFT in the wake of the $81 million heist from Bangladesh Bank earlier this year - in which attackers used fraudulent SWIFT messages to drain funds from the bank's Federal Reserve of New York account - and several other, similar incidents involving other banks.

SWIFT says its new forensics and customer security intelligence team will gather and feed anonymized intelligence to SWIFT-using banks to help them spot and block attacks. The team will also offer assistance to any banks conducting internal investigations on attacks that appear to be related to SWIFT's products or services, in part, by conducting in-depth digital forensic investigations, backed by the two cybersecurity firms that have extensive experience in offering post-breach incident response services to hacked organizations.

The choice of BAE Systems is notable because that firm published pioneering research into the malware that was used against Bangladesh Bank. In May, digital forensic investigators at BAE Systems reported that the malware matched code used against Vietnam's TPBank in late 2015 (see 5 SWIFT Cyber Heist Investigations). Part of the malware's communication channel also matched attack infrastructure that hadn't been used - or seen - since the 2014 attack against Sony Pictures Entertainment, leading some security experts to conclude that the government of North Korea may be behind some recent SWIFT-related fraud incidents.

A SWIFT spokeswoman wasn't immediately able to confirm if SWIFT's help to its customers will come for free.

Promise: Better Intelligence

SWIFT has promised to share anonymized attack-related intelligence not just with its 11,000 bank customers, but also with relevant oversight bodies, information sharing and analysis centers as well as other digital forensic investigation firms (see Federal Reserve Watchdog Probes Banks' Cybersecurity).

To share attack intelligence, however, SWIFT first needs more hacked banks to come clean. To date, at least six banks that have confirmed or suspected SWIFT-related hack attacks have come forward, although anecdotal reports say that a dozen or more related investigations may now be ongoing. Yet some of these hack attacks have only been revealed months after the incident. That was the case for Ecuador's Banco del Austro, which lost $12.2 million after hackers accessed the bank's systems and issued fraudulent SWIFT messages. The attack occurred in January 2015 but only came to light after BDA filed a lawsuit against San Francisco-based Wells Fargo in January, accusing the bank of failing to spot the fraud or to return the full amount that was stolen. Wells Fargo, meanwhile, has fired back, saying it honored valid requests that it had received via the SWIFT messaging system (see Improving Fraud Prevention After SWIFT-Related Heists).

SWIFT has previously said that customers are responsible for securing their own IT environment and are required to report any SWIFT-related breaches to the cooperative (see Banks With Bad Cybersecurity Could Face SWIFT Justice).

But as the BDA hack demonstrates - SWIFT said it only learned of the attack in May, after Reuters first reported on the related lawsuit - not all financial services firms have been complying with those supposed requirements.

Will More Banks Come Clean?

Meanwhile, SWIFT has been continuing to urge targeted banks to come forward.

"Customer intelligence, including intelligence related to attacks that have ultimately failed, is crucial to helping us continue protecting our community. Information we have already received from impacted banks has allowed us to identify new malware and to publish related [indicators of compromise], which are helping to protect the wider community," says SWIFT CTO Craig Young in a statement. "We therefore continue to remind customers that they are obliged to inform SWIFT of such incidents as soon as possible, and to proactively share all relevant information with us so we can assist all SWIFT users."

Now SWIFT is sweetening that request with the offer of incident response assistance and information sharing. But will that be enough to entice more banks to share?

Compliance , Fraud , Payments Fraud

Can Banks Help Small Merchants with PCI? New Guide Aims to Simplify PCI Compliance, Mitigate Emerging Cyber Risks Tracy Kitten (FraudBlogger) • July 11, 2016    

Getting small merchants up to payment security par has been a struggle for years. And it's not that small merchants, like the mom-and-pop bakery on the corner, don't care about security; it's just that they don't understand it.

See Also: Unlocking Software Innovation with Secure Data as a Service

So the release this week by the PCI Security Standards Council of a new PCI compliance resource for small merchants is being lauded by the banking and payments community. But how effective will the resource actually be at convincing merchants to move forward with PCI compliance?

As PCI expert Anton Chuvakin, a payments security analyst at Gartner, points out, many small merchants still don't even understand what PCI is. "A lot of smaller merchants are still woefully behind in security; I met some in 2015 who just heard of this new thing called the PCI-DSS," he says.

And it's not just a problem in the U.S. "It's way worse overseas. I see more merchants who have not heard of PCI-DSS," Chuvakin adds.

Ongoing PCI Headache

For card issuers and merchant acquiring banks, security gaps at small merchants are an increasing worry, as these merchants are deemed to be the proverbial "low-hanging fruit" for fraudsters, says Julie Conroy, a fraud analyst at Aite.

"Smaller merchants have been a key target for cybercriminals, who love going after the weakest link in the chain," she says. "At the same time, too many SMBs [small and medium-sized businesses] believe that data breaches are somebody else's problem, namely the big merchants that are always landing in the headlines. Most SMBs have no idea that many cybercriminals actually prefer targeting the little guys, because the relatively small pool of compromised cards makes it much more difficult for issuers' CPP [common points of purchase] analytics to discover the point of compromise and put compensating controls around them."

Conroy says one of the biggest challenges for acquiring banks is convincing small businesses that compliance with PCI data security standards is really a "baseline" for fraud prevention, and not just some arbitrary rule or regulation.

Small Merchant Security: An Industry Responsibility

We've all accepted that smaller merchants rely heavily on their point-of-sale vendors and integrators to ensure cybersecurity. But, as many breaches over the last three years have taught us, that reliance has been misplaced (see 1,000 Businesses Hit By POS Malware).

Acquiring banks, issuers and the card brands are eager to see small merchants adopt EMV and comply with PCI. But EMV and PCI are expensive, especially for smaller merchants. And incentives, such as chargebacks for fraud, to get merchants invest more in security have not proved overly effective so far (see Visa Acknowledges EMV Rollout Pain).

Is New Resource the Answer?

The resource, Guide to Safe Payments, is a 26-page tutorial designed to help less-tech-savvy merchants gauge their risk to determine which PCI data security requirements make the most sense for them to invest in.

I went through the resource, which the PCI Council released July 7. It's not a complex list of requirements laden with technical jargon. Instead, this resource, served up as a .pdf, is more like an infographic, with easy-to-understand language that describes emerging attacks and the expense associated with compliance aimed at mitigating the risk of those attacks.

Jeremy King, international director of the council, says acquiring banks are encouraged to ensure small merchants are educated about this new resource. "We have narrowed everything down to 12 key areas, and in each of those areas, we've assigned a particular requirement, such as making your passwords more secure, and then provided a guide to show how expensive that requirement is to implement," he says. "They can see how big the payout is, and, thus, the advantage of complying."

Source: PCI Security Standards Council: Guide to Safe Payments

For example, the resource lists mitigation steps like changing default passwords for remote POS access and patching updates and denotes the relative cost, ease of deployment and risk-mitigation impact. Put together by the council's Small Merchant Task Force, which includes representation from the merchant and acquiring communities, Dave Matthews, general counsel for National Restaurant Association, says the resource truly represents small merchants' unique security needs and questions.

"By using graphics and diagrams, complex concepts have been simplified and formatted into documents that technology-challenged business people can relate to and understand," says Matthews, who also co-chairs the task force. "Identifying and understanding technology risk is the first step to mitigation and protection. These materials go far in providing that understanding."

And in a blog posted by the council to accompany the launch of the resource, council CTO Troy Leach answers commonly asked questions about PCI compliance.

"This is a great opportunity to empower small merchants to better protect themselves against increasing threats through awareness of how payments work and how to minimize risk of exposing their customers' cardholder data," Leach writes. "The payment diagrams can be walked through with small merchants so they can see the kind of payment setup they have and understand the risks and protections most relevant to them."

The onus now will be on acquirers, payment processors and retail associations to ensure small merchants are aware of this resource, and understand how it can be used. The resource and accompanying documents are available for free from the council's website, and can be co-branded for distribution to merchant customers.

Chuvakin says acquirers will likely play a major role in making this resource known to smaller merchants. But he adds that banks will have to be good teachers. "Merchants will need more than just, 'Here, read this,'" he says. "They will need help interpreting and operationalizing it."

Michael Christodoulides, vice president of payment security and global payment acceptance at Barclaycard in the U.K., says Barclaycard plans to make the resource an integral part of its communications with small merchant customers. "Our portfolio, like most acquirers, includes a majority of smaller merchants," he says.

And fraud striking those smaller merchants comprises most of Barclaycard's fraud-related expenses as an acquirer, Christodoulides says.

"It's helpful for all small merchants to understand that if they play their part in securing a payments ecosystem, they will prevent fraud at some point in the future," he adds. "We will be linking our website to the Security Standards Council's website to pass this along and include the resource in our products to merchants."

Most sources I pinged in advance of the resource's release told me they had heard about the resource but had not seen it. I'd encourage you to have a look, and then let me know your thoughts.

Do you think this resource will be the key the PCI Council has been searching for to unlock the security challenge its faced when it comes to PCI acceptance among the SMB community? Post your comments below.

Cybersecurity , Data Breach , Risk Management

New IG Audit Criticizes FDIC for Continued Lax InfoSec Practices Eric Chabrow (GovInfoSecurity) • July 13, 2016    

The Chinese government likely was responsible for the hacking of computers at the Federal Deposit Insurance Corp. in 2010, 2011 and 2013, according to a new congressional report.

See Also: Secure, Agile Mobile Banking: Keeping Pace with Last Best User Experience

Public disclosure of those breaches in the congressional report comes as the FDIC inspector general issued a new audit report that criticizes the agency for continued lax information security practices.

The interim report from the Republican staff of the House Science, Space and Technology Committee, dated July 12, says a foreign government - believed to be China - penetrated FDIC computers and the workstations of high-level FDIC officials, including the former chairman, former chief of staff and former general counsel. Hackers compromised 12 workstations and also penetrated 10 servers and infected them with a virus, the report notes.

The committee staff based its findings on a 2013 memo from the FDIC inspector general to the agency's chairman. "The OIG was particularly critical of the agency for violating its own policies and for failing to alert appropriate authorities," the interim report says.

China's Washington embassy did not immediately comment on the allegations, Reuters reports.

Panel Accuses CIO of Mismanagement

The congressional report outlines what staffers consider other slack cybersecurity efforts at the FDIC.

In a statement, the committee's chairman, Rep. Lamar Smith, R-Texas, says the panel's staff found FDIC CIO Larry Gross Jr. had engaged in mismanagement, misled Congress and retaliated against whistleblowers. "He has fostered a hostile work environment," Smith says. "It is also clear that the FDIC deliberately evaded congressional oversight. In addition, the committee found the FDIC has historically experienced deficiencies related to its cybersecurity posture, and those deficiencies continue to the present."

The FDIC, the U.S. agency that insures bank accounts, declined to comment on the interim report.

The agency's failure to follow its own security guidelines seems to persist. A new inspector general report says the FDIC had established various incident response policies, procedures, guidelines and processes, but these controls do not provide reasonable assurance that major incidents are identified and reported in a timely manner.

In its latest audit report issued July 8, the IG focused on a Florida incident involving a former FDIC employee who copied a large amount of sensitive agency information, including personally identifiable information, to removable media and took this information when the employee left the FDIC in October. The IG says the FDIC detected the incident through its data loss prevention tool.

Incident Response Policies Criticized

The IG criticized the FDIC's incident response policies, procedures and guidelines for not addressing major incidents. "The large volume of potential security violations identified by the DLP tool, together with limited resources devoted to reviewing these potential violations, hindered meaningful analysis of the information and the FDIC's ability to identify all security incidents, including major incidents," Mark Mulholland, assistant IG for audits, says in the report.

Based on its analysis of the Florida incident, the assistant IG concluded that the FDIC failed to properly apply the criteria in Office of Management and Budget guidance when it determined that the incident was not major. Specifically, Mulholland says the FDIC based its determination on various mitigation factors related to the "risk of harm" posed by the incident.

Defining Major Incidents

OMB guidance, Memorandum 16-03, issued last October, provides a complex definition of a major incident, which could include compromise of confidential and personally identifiable information, inability to recover or delay in recovering data, and damage to the functionality of systems. OMB says the definition is subject to change based upon incidents, risks, recovery activities or other relevant factors.

FDIC CIO Gross, in a written response to the IG audit, says the agency, in retrospect, should not have considered what it believed to be mitigating factors when applying Office of Management and Budget major incident guidelines. "We have since updated our internal procedures to refer FDIC employees and contractors directly to the OMB guidelines on what constitutes a major incident," he says. "We believe this will be effective in ensuring proper assessment of any future incidents."

(Watch for updates on this developing story.)