Third-Party Security Assessments – We Need a Better Way

July 6, 2014

“According to a February 2013 Ponemon Institute survey, 65% of organizations transferring consumer data to third-party vendors reported a breach involving the loss or theft of their information. In addition, nearly half of organizations surveyed did not evaluate their partners before sharing sensitive data.” [DarkReading]

Assessing the risks associated with extending Financial Services operations into vendor/partner environments is a challenge.  It often results in less-than-crisp indicators of more or less risk.  Identifying, measuring, and dealing with these risks with a risk-relevant level of objectivity is generally not cheap and often takes time — and sometimes it is just not practical using our traditional approaches.  Some approaches also only attempt to deal with a single point-in-time, which ignores the velocity of business and technical change.

There are a number of talented security assessment companies that offer specialized talent, experience, and localized access virtually world-wide.  The challenge is less about available talent, but of time/delay, expense, and risks that are sometimes associated with revealing your interest in any given target(s).

There are also organizations which attempt to replace a repetitive, labor-intensive process with a non-repetitive, labor-saving approach that may reduce operational expenses and may also support some amount of staff redeployment.  The Financial Services Round Table/BITS has worked toward this goal for over a decade.  Their guidance is invaluable.  For those in the “sharing” club, it appears to work well when used applied to a range established vendor types.  It is also, though, a difficult fit for many situations where the candidate vendor/partners are all relatively new (some still living on venture capital) and are still undergoing rapid evolution.  Some types of niche, cloud-based specialty service providers fall easily into this category.  The incentive to invest in a “BITS compliant” assessment for these types of targets seems small, and any assessment’s lasting value seems equally small.

Some challenges are enhanced by increasing globalization – for example, how do we evaluate the risks associated with a candidate vendor that has technical and infrastructure administrative support personnel spread across Brazil, Costa Rica, U.S East & West coasts, Viet Nam, China, India, Georgia, Germany, and Ireland?  Culture still matters.  What a hassle…

None of that alters the fact that as global financial services organizations we have obligations to many of our stakeholders to effectively manage the risks associated with extending our operations into vendor’s environments and building business partnerships.

When the stakes are material – for example during merger or acquisition research – it is easy to understand the importance of investing in an understanding of existing and candidate third-party risks.  There are many other situations where it seems “easy” to understand that a third party security assessment is mandated.  Unfortunately, not all use cases seem so universally clear-cut.

When we are attempting to evaluate platform or vendor opportunities, especially when in the early stages of doing so, the time and expense associated with traditional approaches to full-bore third-party risk assessments are a mismatch.  Performing third-party risk assessments in-house can also reveal sensitive tactical or strategic planning which can negatively impact existing relationships, add unnecessary complexity to negotiations, or, in edge cases, even disrupt relationships with key regulators.  As an industry, we have got to get better at quick-turn-around third-party risk assessments that are “good-enough” for many types of financial services decision-making.

For years, “technicians” have been evaluating Internet-facing infrastructure for signals of effective technology-centric risk management practices – or for their absence.  Poorly configured or vulnerable email or DNS infrastructure, open SNMP services, “external” exposure of “internal” administrative interfaces, SSL configurations, public announcements of breaches, and more have been used by many in their attempts to read “signals” of stronger or weaker risk management practices.  A colleague just introduced me to a company that uses “externally-observable” data to infer how diligent a target organization is in mitigating technology-associated risks.  Based on a quick scan of their site, they tell a good story.*  I am interested in learning about anyone’s experience with this, or this type of service.

*I have no relationships with BitsightTech, financial or otherwise.



“BitSight Technologies Launches Information Security Risk Rating Service.” 9/10/2013

“Bits Framework For Managing Technology Risk For Service Provider Relationships.” November 2003 Revised In Part February 2010.

Shared Assessments.

The company a colleague mentioned to me…

Mobile Malware Hits Bank Customers with Classic Ransom Scam

June 14, 2014

There is something greater than 100 million individuals using mobile banking apps in North America.  Given their primitive security capabilities, that describes a material attack surface.

Mobile Trojan Svpeng was identified stealing mobile banking credentials almost a year ago by Kaspersky Labs.

The malware has continued to evolve since then and since the start of this month it has been circulating as classic ransomware attacking Android-based mobile devices.

Initially it looks for banking applications from USAA, Citigroup, American Express, Wells Fargo, Bank of America, TD Bank, JPMorgan Chase, BB&T and Regions Bank, and when it finds one or more, it forwards that information to a server under the cybercriminals’ control.

It imitates a scan of the phone and announces that it has found some prohibited content.

The malware then blocks the phone and demands a payment of $200 to unblock it.

It also displays a photo of the user taken by the phone’s front camera.

The creators of the Trojan finally provide detailed directions for paying the ransom payments using ‘Green Dot’ MoneyPak vouchers.

Expect this model to continue evolving.  The team behind it understands how to get their malware out onto individual’s mobile devices, how to collect user credentials, how to target mobile banking customers, and appears to be in the process of building a database of endpoints and individuals that use specific banking apps.  It does not require much creativity to picture a business model where this information is sold to other hostile parties in an on-line datamart — crime, theft, & harm to follow…

This is another reason to enhance and actively manage the quality of your anti-fraud processes, algorithms, and infrastructure.


“Latest version of Svpeng targets users in US.”
Roman Unuchek, June 11, 2014

“Kaspersky Lab detects mobile Trojan Svpeng: Financial malware with ransomware capabilities now targeting U.S. users”
June 11, 2014

“First Major Mobile Banking Security Threat Hits the U.S.”
By Penny Crosman , JUN 13, 2014

Exploits Violate OAuth 2.0 and OpenID Assumptions

May 14, 2014

Earlier this month, numerous outlets reported that Wang Jing, a PhD student in mathematics from Nanyang Technological University, uncovered serious security vulnerabilities in OAuth 2.0 and OpenID, the technologies used by many websites to authenticate users via third-party websites.

Almost all major providers of OAuth 2.0 and OpenID identity services are affected, such as Facebook, Google, Yahoo, LinkedIn, Microsoft, Paypal, GitHub, QQ, Taobao, Weibo, VK, Mail.Ru, Sohu, etc.

Remember, OAuth 2.0 and OpenID are ways that 3rd party applications can support user authentication without maintaining a robust identity directory and the identity life-cycle processes that come with it. It is commonplace today to bump into offers to use your Facebook, Google, Twitter, or github credentials on a 3rd party app or site.

That equation, an identity provider being used by a third-party client application requires a certain level of trust between all three parties involved: provider, 3rd party, and end user. The vulnerability uncovered by W.Jing shows how an attacker can exploit weaknesses in provider infrastructure and 3rd party applications to cause those 3rd party applications to untintentionally act as a bridge between the provider and the attacker.

Some days it seems like input validation is the solution to almost every software security issue…*
More effective validation of inputs by third party application developers and the providers could deliver significant resistance to attackers. White lists of trusted sources as well as more thorough verification procedures at the providers could materially tamp down the risks associated with this class of vulnerabilities. The white list approach would require a level of accuracy and maintenance that it seem (at least to this author) like it will not happen without external incentives being imposed.

This vulnerability is especially notable because:

  • It enables Open Redirect Attacks
  • It enables unauthorized access / identity fraud
  • It could lead to sensitive information leakage and/or customer information breaches
  • It has wide coverage: most of the major internet companies provide these types of authentication/authorization services — and some Financial Services organizations would like to offer these options as well, especially in (but not limited to) the moble device environment.
  • It is difficult to “patch”

Some in the security community are playing down the potential impacts of this class of vulnerabilities based on their assertion that “most of the websites using OAuth 2.0 and OpenID are social in nature,” or that the complexity of exploit means that the “majority of criminals won’t bother with it.” If you are in financial services and are using OAuth 2.0 and/or OpenID, think carefully through that logic in the context of your brand.

If you use any of those “sign in with my _____ ID” offerings, it seems rational for you to do some research to see if all the identity & authorization service providers involved are resistant to this new class of attack.

Some of the biggest identity-providers on earth are vulnerable to this new class of attack, including, but not limited to:,,,, (Microsoft),, (Tencent), (Sina),,, (Alibaba), (Sina),,,, (Alibaba), and more.

For those of you who need to see the technical details, W.Jing has blog entries and youtube videos detailing proof of concept attacks against each of the properties identified above on his blog at:

* But not everyday…

“Covert Redirect Vulnerability Related to OAuth 2.0 and OpenID.”
By WANG Jing, May 2014.

“OAuth and OpenID Vulnerable to Covert Redirect, But Have No Vulnerability.”
By Anthony M. Freed, 05-04-2014

“Security Flaw Found In OAuth 2.0 And OpenID; Third-Party Authentication At Risk.”
By Tim Wilson, 05-04-2014


Graphic of DDoS Evolution 2013-2014

April 20, 2014
We are all attempting to figure out the right investments in DDoS resistance and mitigation.  In the fog of hype and vendor pitches, it is difficult to get some perspective on what we need to be preparing for on this front.  Every hard data resource has exaggerated value in the current situation.
Incapsula recently released “2013-2014 DDoS Threat Landscape Report.”  Their findings outlined below are based on hundreds of attacks perpetrated against websites using Incapsula’s DDoS Mitigation service.  Using that data their report concludes (most quoted from their report):

Network (Layer 3 & 4) DDoS Attacks

  • Large SYN Floods account for 51.5% of all large-scale attacks
  • Almost one in every three attacks is above 20Gbps
  • 81% of attacks are multi-vector threats
  • Normal SYN flood & Large SYN flood combo is the most popular multi-vector attack (75%)
  • NTP reflection was the most common large-scale attack method in February 2014
2014: Emerging Trends
    • “Hit and Run” DDoS attacks: frequent short bursts of traffic, are specifically designed to exploit the weakness of services that were designed for manual triggering (e.g., GRE tunneling to DNS re-routing). Hit and Run attacks are now changing the face of anti-DDoS industry, pushing it towards “Always On” integrated solutions.
    • Multi-Vector Threats: 81% of all network attacks employed at least two different attack methods, with almost 39% using three or more different attack methods simultaneously.  Multi-vector tactics increase the attacker’s chance of success by targeting several different networking or infrastructure resources.  Combinations of different offensive techniques are also often used to create “smokescreen” effects, where one attack is used to create noise, diverting attention from another attack vector. Moreover, multi-vector methods enable attackers to exploit holes in a target’s security perimeter, causing conflicts in automated security rules and spreading confusion among human operators.
    • Attack Type Facilitates Growth: Today large scale DDoS attacks (20Gbps and above) already account for almost 33% of all network DDoS events. There is no doubt that the increasing adoption of these techniques will facilitate the growth of future volumetric network DDoS attacks, which could in turn drive an increase in investment in networking resources.  During January and February of 2014 a significant increase in the number of NTP Amplification attacks was noted. In fact, this reached the point where, in February, NTP Amplification attacks became the most commonly used attack vector for large scale network DDoS attacks.
    • Weapn of Choice: attackers’ most common “weapons of choice”: i.e., large SYN floods, NTP Amplification and DNS Amplification
    • NTP DDoS is on the Rise

Application (Layer 7) DDoS Attacks

In the second half of 2013 Incapsula began to encounter a much more complex breed of DDoS offenders, including browser-based bots which were immune to generic filtering methods and could only be stopped by a combination of customized security rules and reputation-based heuristics.  (High volume is not essential)…even a rate of 50-100 requests/second would be enough to cripple most mid-sized websites, exceeding typical capacity margins.
  • DDoS bot traffic is up by 240%:  On average, Incapsula recorded over 12 million unique DDoS bot sessions on a weekly basis, which represents a 240% increase over the same period in 2013.
  • More than 25% of all Botnets are located in India, China and Iran
  • USA is ranked number 5 in the list of “Top 10” attacking countries
  • 29% of Botnets attack more than 50 targets a month — 7% attach more than 100 per month.
  • 29.9% of DDoS bots can hold cookies.  In the fourth quarter of 2013, Incapsula reported the first encounter with browser-based DDoS bots that were able to bypass both JavaScript and Cookie challenges – the two most common methods of bot filtering.  This trend continues in 2014.
  • 46% of all spoofed user-agents are fake Baidu Bots (while 11.7% are fake Googlebots)
2014: Emerging Trends
    • Botnet Geo-Locations
    • “Shared Botnets”
    • Bots are Evolving
    • Common Spoofed User-Agents



2013-2014 DDoS Threat Landscape Report

The findings above are summarized in the graphic below from Incapsula
DDoS Graphic from Incapsula
DDoS Graphic from Incapsula

Keylogger Revealed in the Apple iOS Ecosystem

February 25, 2014

In the course of their daily grind, Financial Security professionals dealing with the current BYOD fever often refer to risks associated with use unmanaged endpoints in business operations — especially when this involves using consumer-oriented unmanaged tablets and/or phones running Android or iOS.  A special subset of that risk involves the theft of company credentials — generally still a username/password pair.  Once those credentials are ‘owned’ by hostile actors, a targeted organization is at elevated risk along any dimension associated with the ‘real’ worker’s role.  For example, a hostile who possesses credentials of the chief financial officer, treasury personnel, database administrator, server administrator, or other individual with elevated rights can (in theory) perform all the activities authorized for those individuals — which would result in material risk to your organization.  All risk management professionals and decision-makers at all levels need to keep these risks in mind as they evaluate the appropriateness of BYOD for their organization(s).

In the last month, two separate research teams (from Trustwave and FireEye) have produced proof-of-concept apps to exploit an iOS flaw that allows a hostile party to record every tap and keystroke made on an Apple iOS device — jailbroken or not.  This type of software has been around in the Android marketplace for some time.  But Apple and its ‘marketers’ have been adamant that various features of the iOS operating system architecture provide overlapping layers of protection to prevent this type of activity, and as a final backstop their (opaque) App Store app review practices effectively eliminate the risk of overtly hostile software successfully behaving in a hostile manner in the iOS ecosystem.  In other words, “just trust us…”  A recent example of ‘analysis’ of this type — stating that “there is essentially no iOS malware” — might include “Defending Data on iOS 7.”

Security researchers have identified a vulnerability which allows malicious actors to log your taps & keystrokes (X-Y coordinates) before sending that data to a remote server of their choice.

Mobile specialists on staff of security company FireEye have been collaborating with Apple after creating a proof-of-concept app, and deploying it through the production Apple App Store review process without detection, and then having it successfully exploit a non-jailbroken iOS 7 device after downloading and installing from Apple’s App Store.

In practice, the ‘keylogging’ would be an ‘added feature’ in an otherwise ‘reasonable’ app, and a hostile party would use phishing or other social engineering to mislead victims into installing their software.  Another route would be to exploit another remote vulnerability in iOS itself or in another app to begin the malicious app download process.

According to the authors, the exploit works on non-jailbroken modern iOS devices, including iOS 7.0.5, 7.0.6 and 6.1.x.

In the context of the recent iOS SSL vulnerability — something that any reputable static code security analysis product or service would have caught — it is difficult to support Apple’s opaque ‘trust us…” approach to security details.  I believe that Apple is going to have to be much more transparent to win over the Financial Services markets.

The exploit takes advantage of the way Apple’s exceptions to the iOS settings for “background app refresh.” Security-conscious users can use settings to ‘disable’ specific app’s background refreshing. App authors, though, are allowed to bypass the user’s wishes. One example is permitting an app to play music in the background without turning on its ‘background app refresh’ switch. It appears that in this case, the proof-of-concept app may have disguised itself as a music app to conduct background monitoring. MDM vendors also deploy apps that exhibit analogous behaviors to this ‘backgrounding exception.’ Even when an iOS device is set to deny all ‘Background App Refresh’ the MDM app will continue to run, examining the local device, and ‘calling home’ with results of that assessment.

As we have mentioned before on this blog, the Android app marketplace is still an ‘elevated security risk muddle,’* and there is no ‘Apple security magic.’ Apple has an excellent record of managing their image, but an uneven record at implementing real, or Financial Services-grade resistance to hostile actors.

Until Apple figures this one out, iOS users should avoid at least some of this risk by using the iOS task manager to stop unnecessary apps from running in the background. This will prevent a range of potential elevated risk monitoring that might be occurring.** iOS7 users can press the Home button twice to enter the task manager and see preview screens of apps opened, and then swipe an app up and out of preview to disable unnecessary or suspicious applications running on the background.

*Technical term.
**Remember, an MDM agent is a ‘trusted’ app and is used to qualify endpoints for some types of access to private infrastructure. If your company requires a given MDM agent, I recommend that you let it continue to run.
“Researcher Creates Malware to Captures Every Tap on Your Smartphone or Tablet.” By David Gilbert , January 31, 2014

“New iOS flaw makes devices susceptible to covert keylogging, researchers say — Proof-of-concept app in Apple’s App Store sent keystrokes to remote server.” By Dan Goodin – Feb 24 2014

“Background Monitoring on Non-Jailbroken iOS 7 Devices — and a Mitigation.” By Min Zheng, Hui Xue and Tao Wei, February 24, 2014

“Defending Data on iOS 7. Version 2.0″ by Rich Mogull, Securosis.

Open Source CMS in Financial Services?

January 11, 2014

I ran a a small personal blog on Drupal for a number of years. Drupal can dramatically simplify some categories of web content management compared to competing technology options.

A quick job search this evening for financial services openings involving Drupal in New York suggests a range of banking, finance, investments, and insurance organizations use this stack today.

Drupal is an open source content management platform powering millions of websites and applications. It is built, used, and supported by an active and diverse community of people around the world. It is written in PHP that uses a MySQL database, and supports a range of other emerging web technologies.

One reason I drifted off my Drupal platform involved the level of effort required to keep it updated and patched as new security vulnerabilities and exploits were published.

Drupal has a well-established record of moderately-critical and critical security vulnerabilities. This is not necessarily a bad thing. There is an active Drupal security team using relatively-well documented processes ( and in the context of an exemplary level of transparency.

In 2013 there were 3 major collections of remotely-exploitable critical & highly-critical vulnerabilities in the Drupal core, as well as 97 (mostly) remotely exploitable vulnerabilities in Drupal extensions.


  1. Running a Financial Services web site on Drupal with a range of typical features & integrations involves the same range of risk management obligations as with any other technology stack. As a result, security needs to be built into your software development lifecycle end-to-end — from requirements-gathering & architecture, through configuration, deployment & operations, and every step in between.
  2. We need to develop & document a set of core company-standard coding conventions & formal standards that attempt to incorporate exploit resistance and attack-awareness, along with security-centric logging/alerting/alarming/reporting practices throughout all Drupal-hosted application content (code, templates, configurations, CSS, etc.). If your organization does not support PHP development today, Drupal will drive you to PHP support. Building out a secure coding practice for a programming language without legacy support in your organization will require a non-trivial investment. The Drupal security team maintains code-level security guidance at:, which should help boot strap company-specific efforts which should be enthusiastically-integrated into all code/configuration activities.
  3. We need to use careful, thoughtful, skeptical and paranoid security code reviews of all ‘code’ & configuration changes prior to deployment.
    Organizations should also invest in a regular service of centralized security code analysis, along with security assessments in a deployed context, and ‘certification’ of Drupal modules — permitting only ‘certified’ or approved modules in production and pilot environments. This type of review does not guarantee risk-free operations, but would help to demonstrate Financial Services-grade due diligence and help to deliver a certain degree of safety in the module code. Some static security code analysis SaaS vendors support PHP to help your staffing challenges here.
  4. We need to have enough trained technical and leadership personnel on deck at all times in order to react efficiently & effectively to security advisories or exploit announcements that require relatively-immediate site and/or code changes.
  5. Finally, revisit the first recommendation above again and follow-through across your entire SDLC. That said we also need to invest in ongoing platform penetration testing & web application vulnerability assessments in order to ensure that we are not exposed to a known or not-yet-announced vulnerability. Again, SaaS support opportunities abound in the dynamic application testing. ‘App pen testing’ is not the solution to your web application needs, it is only one facet of a multi-dimensional full life-cycle approach that is critically-important.


Security Advisories – Drupal Core
Security Advisories – Contributed Projects
Security Advisories – Public Service Announcements

“Security Issues in Drupal Content Management System.” (2013)

The 10 most critical Drupal security risks. (2012)

CVE Drupal Vulnerability Statistics:
CVE Drupal Vulnerability Details:

Drupal Administration Guide — Securing your Site

Drupal Writing secure code. Last updated September 12, 2013

“Drupal Security Best Practices — A Guide for Governments and Nonprofits.”
By OpenConcept Consulting Inc. for Public Safety Canada
Principal Author: Mike Gifford, with a collection of contributors

Public Example: Drupal Security at University of Pennsylvania
Drupal Security Considerations
Drupal Secure Configuration
Drupal Approved Modules

“Mad Irish . net — Open source software security.”


Get every new post delivered to your Inbox.

%d bloggers like this: