Another Exfiltration Tool

January 30, 2018

It is a challenge to keep up with the free HTTPS-enabled data exfiltration tools available.  As security professionals in global Financial Services enterprise, we have obligations to exhibit risk-reasonable behaviors.  Resisting easy, “invisible” data theft is a core deliverable in our layered security services.

Google is offering a cool “Cloud Shell” that falls into the category I was thinking of when I wrote the paragraph above.  It is a highly-functional Linux shell that is available to anyone with https access to the Internet.  There are lots of good reasons for Google to offer this service.  And they require an active credit card for initial on-boarding — allowing some to argue that there are limits to the anonymity this service might deliver.  There are also lots of global Financial Services enterprise misuse cases.  Quick, easy, difficult-to-understand data exfiltration being the first that came to mind.  Hosting “trustworthy” command and control applications is another.  With Internet access, sudo, and persistent storage the only limitations seem to be the creativity of any given hostile party.

Financial Services brands managing trillions of dollars for others need to protect against the misuse of tooling like this.  The challenge is that some of us use Google Cloud services for one or another subset of our business activities. And in those approved contexts, that represents risk-reasonable behavior.

This situation is just another example of external forces driving our internal priorities in ways that will require a quick response, and will also induce ongoing risk management workload.

So it goes.


Google Cloud Shell:


Risk-Taking and Secure-Enough Software

January 24, 2018

Each of us involved in global Financial Services enterprises have risk management strategy and policy.  In action, those are supported and operationalized through a vast, dynamic, organic, many-dimensional web of risk management activities.

One facet of this activity involves the creation, acquisition, implementation, and use of risk-appropriate software. Sometimes this is abbreviated to simply “secure software.” In some forums I use the term “secure-enough software” to help highlight that there is some risk-related goal setting and goal achieving that needs to be architected, designed, and coded into software we create — or the same needs to be achieved by our vendors or partners when we acquire software.

As I have mentioned repeatedly in this blog, global financial services enterprises succeed through taking goal-aligned risks. Our attempts to live out that challenge are at best uneven.

Some software developers, architects, or some agile team member will zealously and enthusiastically take risks in their attempts to improve a given or a set of software quality characteristics. Others only reluctantly take risks.[1] In either case, the risks are only vaguely described (if at all) and the analysis of their appropriateness is opaque and un- or under-documented.

My experience is that too many personnel have little to no involvement, training and context on which to ground their risk analysis and risk acceptance decision making.  As a result of that gap, risk acceptance throughout any software development lifecycle is too often based on project momentum, emotion, short term self-promotion, fiction, or some version of risk management theater.

The magnitude of risk associated with this type of risk taking has only been enlarged by those attempting to extract value from one or another cloud thing or cloud service.

Those of us involved in secure software work need to clearly express the extent of our localized organization’s willingness to take risk in order to meet specific objectives, AND how the resulting behaviors align with published and carefully vetted enterprise strategic (risk management) objectives.

All of this leads me to the topic of risk appetite.

  • What needs to be included in a description of risk appetite that is intended for those involved in software development and acquisition?
  • Are there certain dimensions of software-centric risk management concern that need to be accounted for in that description of risk appetite?
  • Are there certain aspects of vocabulary that need to be more prescribed than others in order to efficiently train technical personnel about risk-taking in a global financial services enterprise?
  • Are there rules of thumb that seem to help when attempting to assess the appropriateness of given software-centric risks?

What do you think?


Risk Appetite and Tolerance Executive Summary.
A guidance paper from the Institute of Risk Management September 2011

[1] A similar phrase is found in the abstract of “Risk Appetite in Architectural Decision-Making.” by Andrzej Zalewski.


%d bloggers like this: