Ransomware and My Cloud

December 10, 2017

I just reviewed descriptions of sample incidents associated with ransomware outlined in the ‘Top 10″ review by TripWire.

Ransomware attacks — malware that encrypts your data followed by the attacker attempting to extort money from you for the decryption secrets — are a non-trivial threat to most of us as individuals and all financial services enterprises.

Unfortunately for some, their corporate culture tends to trust workforce users’ access to vast collections of structured and unstructured business information.  That ‘default to trust’ enlarges the potential impacts of a ransomware attack.

As global Financial Services security professionals, we need to resist the urge to share unnecessarily.

We need to quickly detect and respond to malware attacks in order to constrain their scope and impacts.  Because almost every global Financial Services enterprise represents a complex ecosystem of related and in some cases dependent operations, detection may involve many layers, technologies, and activities.  It is not just mature access/privilege management, patching, anti-virus, or security event monitoring, or threat intelligence alone.

All of us also need to ensure that we have a risk-relevant post-ransomware attack data recovery capability that is effective across all our various business operations.

So, does the cloud make me safe from ransomware attack?  No.  Simply trusting your cloud vendor (or their hype squad) on this score does not reach the level of global Financial Services due diligence.  It seems safe to assert that for any given business process, the countless hardware, software, process, and human components that make up any cloud just make it harder to resist and to recovery from ransomware attack.  And under many circumstances, the presence of cloud infrastructure — by definition, managed by some other workforce using non-Financial Services-grade endpoints — increases the probability of this family of malware attack.

 

REFERENCE:

“10 of the Most Significant Ransomware Attacks of 2017.” By David Bisson, 12-10-2017. https://www.tripwire.com/state-of-security/security-data-protection/cyber-security/10-significant-ransomware-attacks-2017/​

Advertisements

Innovation and Secure Software

November 15, 2017

​I sometimes get questions about the applicability of secure software standards and guidelines to work described as innovation or innovative.  Sometimes these interactions begin with an outright rejection of “legacy” risk management in the context of an emerging new “thing.”  I believe that under most circumstances, any conflict that begins here is voluntary and avoidable.  As global financial services organizations, our risk management obligations remain in force for mature & stable development projects as well as for innovation-oriented efforts.

In any discussion of innovation, I arrive with my own set of assumptions:

  • Innovation can occur at all levels of the human, business, operations, technology stack, and often requires concurrent change at multiple layers.
  • Innovation, in any context, does not invalidate our risk management obligations.
  • One of the most common and insidious innovation anti-patterns is constantly looking for the next hot tool that’s going to solve our/your problems.*

Software-centric innovation may generate new or help highlight existing gaps in your secure software standards/guidelines.

If there are gaps in your existing secure software guidance — so that the new “thing” seems to be out of phase and disconnected from that legacy, those gaps need to be closed.

Sometimes gaps like these appear because of changes in vocabulary.  This is generally an easy issue to deal with.  If all involved can agree on the trajectory of the innovative development, then you can begin with something as simple as a memo of understanding, with updates to secure software standards/guidelines to follow at a pace determined by the priority of that work (if there is a formal, fines & penalties regulatory compliance issue involved, it is a higher priority than if were only an exercise in keeping your documentation up-to-date).

Other times an organization is introducing a new business process, a new type of business, or a new technology that does not map well to the existing concepts and/or assumptions expressed in your secure software standards/guidance.  An example of this situation occurred as we all began to invest in native mobile apps.  At that time, mobile app ecosystems did not incorporate a lot of the common security mechanisms and capabilities that had been in place for server and desktop environments for a long time.  This type of change requires a mix of simple vocabulary and content change in corporate secure software standards/guidance.  Again, if those involved can agree on some fundamental assumptions about what the new software is doing and where it is executing, along with sharing an understanding of its external behaviors (passing data, resolving names, signaling, trusts, etc.), you can take a multi-step process to get secure software guidance synchronized with your business environment.  The first step being some sort of formal memo of understanding, followed by the research, collaboration, and writing required to get your secure software standards/guidelines and your business operations back into phase.

Is it possible that your enterprise could introduce something so alien and so disruptively new that there was just no connective tissue between that investment and your existing secure software guidance?  Sure.  What if financial services enterprises decided that they needed to begin building our own proprietary hardware (from the chips all the way up the stack to network I/O) to deal with the combination of gigantic data-sets, complex analyses, and extremely short timelines (throw in some ML & AI to add sex appeal).  Our current generation of secure software standards/guidelines would not likely be well aligned with the risk management challenges presented by microchip architecture, design, implementation and the likely tightly-coupled low level software development that would be required to use them.  I would not be surprised if much of what we have currently published in our organizations would be virtually unrelatable to what would be needed to address the scenario above.  I think that the only businesslike path to dealing with that secure software challenge would be to acquire highly-specialized, experienced human resource to guide us through that kind of dis-contiguous evolution.  That would be a material challenge, but one that our business will not often face.

Given the current state of our secure software training and guidance resources, it seems like most of us in global Financial Services enterprises should expect to find that most ​innovation efforts are aligned-enough with the existing secure software standards/guidelines, or (less frequently) only somewhat out of sync because of differences in vocabulary, or misaligned underlying assumptions or concepts.  Those are expected as part of our evolving software-driven businesses and the evolution of hostile forces that our businesses are exposed to.

So, innovate!  Any of our success in the global financial services marketplace is not guaranteed.  And, dive into working through decision-making about your architecture, design, and implementation risk management obligations.  And finally, use the existing technical and human resources available to you to deal with any new risk management challenges along the way.

* Rough quote from: “Practical Monitoring: Book Review and Q&A with Mike Julian.” By Daniel Bryant, Nov 07, 2017. https://www.infoq.com/articles/practical-monitoring-mike-julian.


Two Mobile Security Resources

October 16, 2017
Although it should not have taken this long, I just ran across two relatively new resources for those doing Financial Services business in an environment infested with mobile devices.

If you are a mobile developer or if your organization is investing in mobile apps, I believe that you should [at a minimum] carefully and thoughtfully review the Study on Mobile Device Security by the U.S. Department of Homeland Security and the Adversarial Tactics, Techniques & Common Knowledge Mobile Profile by Mitre.  Both seem like excellent, up-to-date overviews. The Mitre publication should be especially valuable for Architecture Risk Analysis and threat analysis in virtually any mobile context.

REFERENCES:
“Study on Mobile Device Security.” April 2017, by the US Dept. of Homeland Security (125 pages)https://www.dhs.gov/sites/default/files/publications/DHS%20Study%20on%20Mobile%20Device%20Security%20-%20April%202017-FINAL.pdf
“Adversarial Tactics, Techniques & Common Knowledge Mobile Profile.” October 2017, by The MITRE Corporation https://attack.mitre.org/mobile/index.php/Main_Page

 


Low Profile Office 365 Breach Reported

August 18, 2017

A couple years ago I wrote:

“I am told by many in my industry (and some vendors) that ‘if we put it in the cloud it will work better, cheaper, be safer, and always be available.’ Under most general financial services use cases (as opposed to niche functionality) that statement seems without foundation.”

Although many individuals have become more sophisticated in the ways they pitch ‘the cloud’ I still hear versions of this story on a fairly regular basis…

Today I learned about a recent Office 365 service outage that reminded me that issues concerning our use of ‘cloud’ technology and the commitments we in the Global Financial Services business make to our customers, prospects, marketers, investors, and regulators seem to remain very much unresolved.

What happened?

According to Microsoft, sometime before 11:30 PM (UTC) on August 3rd 2017, the company introduced an update to the Activity Reports service in the Office 365 admin center which resulted in customers usage reports of one tenant being displayed in another tenant’s administrative portal.

Some customer o365 administrators noticed that the reported email and SharePoint usage for their tenants had spiked. When they investigated, the o365 AdminPortal (https://portal.office.com/adminportal/) displayed activity for users from one or more AzureAD domains outside their tenant. In the most general terms, this was a breach. The breach displayed names and email addresses of those users along with some amount of service traffic detail, for example, user named X (having email address userNameX@domainY.com) sent 193 and received 467 messages, as well as uploaded 9 documents to SharePoint, and read 45 documents in the previous week.

Some subset of those 0365 customers reported the breach to Microsoft.

Microsoft reported that at they disabled the Activity Reports services at 11:40 PM UTC the same day, and that they had a fix in place by 3:35 AM UTC.

Why should I care?

As Global Financial Services Enterprises we make a lot of promises (in varying degrees of formality) to protect the assets for which we are responsible and we promote our ethical business practices. For any one or our companies, our risk profile is rapidly evolving in concert with expanded use of a range of cloud services. Those risks appear in many forms. All of us involved in Global Financial Services need our security story-telling to evolve in alignment with the specific risks we are taking when we choose to operate one or another portion of our operations in ‘the cloud.’ In addition, our processes for detecting and reporting candidate “breaches” also need to evolve in alignment with our use of all things cloud.

In this specific situation it is possible that each of our companies could have violated our commitments to comply with the European GDPR (General Data Protection Regulations: http://www.eugdpr.org/), had it happened in August 2018 rather than August 2017. We all have formal processes to report and assess potential breaches. Because of the highly-restricted access to Office 365 and Azure service outage details, is seems easy to believe that many of our existing breach detection and reporting processes are no longer fully functional.

Like all cloud stuff, o365 and Azure are architected, designed, coded, installed, hosted, maintained, and monitored by humans (as is their underlying infrastructure of many and varied types).
Humans make mistakes, they misunderstand, they miscommunicate, they obfuscate, they get distracted, they get tired, they get angry, they ‘need’ more money, they feel abused, they are overconfident, they believe their own faith-based assumptions, they fall in love with their own decisions & outputs, they make exceptions for their employer, they market their services using language disconnected from raw service-delivery facts, and more. That is not the whole human story, but this list attempts to poke at just some human characteristics that can negatively impact systems marketed as ‘cloud’ on which all of us perform one or another facet of our business operations.

I recommend factoring this human element into your thinking about the value proposition presented by any given ‘cloud’ opportunity. All of us will need to ensure that all of our security and compliance mandated services incorporate the spectrum of risks that come with those opportunities. If we let that risk management and compliance activity lapse for too long, it could put any or all of our brands in peril.

REFERENCES:
“Data Breach as Office 365 Admin Center Displays Usage Data from Other Tenants.”
By Tony Redmond, August 4, 2017
https://www.petri.com/data-breach-office-365-admin-center

European GDPR (General Data Protection Regulations)
http://www.eugdpr.org/


Workforce Mobility = More Shoulder Surfing Risk

July 20, 2017

An individual recently alerted me to an instance of sensitive information being displayed on an application screen in the context of limited or non-existent business value. There are a few key risk management issues here – if we ship data to a user’s screen there is a chance that:

  • it will be intercepted by unauthorized parties,
  • unauthorized parties will have stolen credentials and use them to access that data, and
  • unauthorized parties will view it on the authorized-user’s screen.

Today I am most interested in the last use case — where traditional and non-traditional “shoulder surfing” is used to harvest sensitive data from user’s screens.

In global financial services, most of us have been through periods of data display “elimination” from legacy applications. In the last third of the 20th century United States, individual’s ‘Social Security Numbers’ (SSN) evolved into an important component of customer identification. It was a handy key to help identify one John Smith from another, and to help identify individuals whose names were more likely than others to be misspelled. Informtation Technology teams incorporated SSN as a core component of individual identity across the U.S. across many industries. Over time, individual’s SSNs became relatively liquid commodities and helped support a broad range of criminal income streams. After the turn of the century regulations and customer privacy expectations evolved to make use of SSN for identification increasingly problematic. In response to that cultural change or to other trigger events (privacy breach being the most common), IT teams invested in large scale activities to reduce dependence on SSNs where practical, and to resist SSN theft by tightening access controls to bulk data stores and by removing or masking SSNs from application user interfaces (‘screens’).

For the most part, global financial services leaders, application architects, and risk management professionals have internalized the concept of performing our business operations in a way that protects non-public data from ‘leaking’ into unauthorized channels. As our business practices evolve, we are obligated to continuously re-visit our alignment with data protection obligations. In software development, this is sometimes called architecture risk analysis (an activity that is not limited to formal architects!).

Risk management decisions about displaying non-public data on our screens need to take into account the location of those screens and the assumptions that we can reliably make about those environments. When we could depend upon the overwhelming majority of our workforce being in front of monitors located within workplace environments, the risks associated with ‘screen’ data leakage to unauthorized parties were often managed via line-of-sight constraints, building access controls, and “privacy filters” that were added to some individual’s monitors. We designed and managed our application user interfaces in the context of our assumptions about those layers of protection against unauthorized visual access.

Some organizations are embarked on “mobilizing” their operations — responding to advice that individuals and teams perform better when they are unleashed from traditional workplace constraints (like a physical desk, office, or other employer-managed workspace) as well as traditional workday constraints (like a contiguous 8, 10, or 12-hour day). Working from anywhere and everywhere, and doing so at any time is pitched as an employee benefit as well as a business operations improvement play. These changes have many consequences. One important impact is the increasing frequency of unauthorized non-public data ‘leakage’ as workforce ‘screens’ are exposed in less controlled environments — environments where there are higher concentrations of non-workforce individuals as well as higher concentrations of high-power cameras. Inadvertently, enterprises evolving toward “anything, anywhere, anytime” operations must assume risks resulting from exposing sensitive information to bystanders through the screens used by their workforce, or they must take measures to effectively deal with those risks.

The ever more reliable assumption that our customers, partners, marketers, and vendors feel increasingly comfortable computing in public places such as coffee shops, lobbies, airports and other types of transportation hubs, drives up the threat of exposing sensitive information to unauthorized parties.

This is not your parent’s shoulder surfing…
With only modest computing power, sensitive information can be extracted from images delivered by high-power cameras. Inexpensive and increasingly ubiquitous multi-core machines, GPUs, and cloud computing makes computing cycles more accessible and affordable for criminals and seasoned hobbyists to extract sensitive information via off-the-shelf visual analysis tools

This information exposure increases the risks of identity theft and theft of other business secrets that may result in financial losses, espionage, as well as other forms of cyber crime.

The dangers are real…
A couple years ago Michael Mitchell and An-I Andy Wang (Florida State University), and Peter Reiher (University of California, Los Angeles) wrote in “Protecting the Input and Display of Sensitive Data:”

The threat of exposing sensitive information on screen
to bystanders is real. In a recent study of IT
professionals, 85% of those surveyed admitted seeing
unauthorized sensitive on-screen data, and 82%
admitted that their own sensitive on-screen data could
be viewed by unauthorized personnel at times. These
results are consistent with other surveys indicating that
76% of the respondents were concerned about people
observing their screens, while 80% admitted that
they have attempted to shoulder surf the screen of a
stranger .

The shoulder-surfing threat is worsening, as mobile
devices are replacing desktop computers. More devices
are mobile (over 73% of annual technical device
purchases) and the world’s mobile worker
population will reach 1.3 billion by 2015. More than
80% of U.S. employees continues working after leaving
the office, and 67% regularly access sensitive data at
unsafe locations. Forty-four percent of organizations
do not have any policy addressing these threats.
Advances in screen technology further increase the risk
of exposure, with many new tablets claiming near 180-
degree screen viewing angles.

What should we do first?
The most powerful approach to resisting data leakage via user’s screens is to stop sending that data to those at-risk application user interfaces.

Most of us learned that during our SSN cleanup efforts. In global financial services there were only the most limited use cases where an SSN was needed on a user’s screen. Eliminating SSNs from the data flowing out to those user’s endpoints was a meaningful risk reduction. Over time, the breaches that did not happen only because of SSN-elimination activities could represent material financial savings and advantage in a number of other forms (brand, good-will, etc.).

As we review non-public data used throughout our businesses, and begin the process of sending only that required for the immediate use case to user’s screens, it seems rational that we will find lots of candidates for simple elimination.

For some cases where sensitive data may be required on ‘unsafe’ screens Mitchell, Wang, and Reiher propose an interesting option (cashtags), but one beyond the scope of my discussion today.

REFERENCES:
“Cashtags: Protecting the Input and Display of Sensitive Data.”
By Michael Mitchell and An-I Andy Wang (Florida State University), and Peter Reiher (University of California, Los Angeles)
https://www.cs.fsu.edu/~awang/papers/usenix2015.pdf


Pirated Software and Network Segmentation

July 17, 2017

Global financial services enterprises face a complex web of risk management challenges.
Sometimes finding the right grain for security controls can be a difficult problem.
This can be especially problematic when there is a tendency to attribute specific risks to cultures or nations.

A couple months ago I read a short article on how wannacry ransomware impacted organizations in China. Recently, while responding to a question about data communications connectivity and segmenting enterprise networks, I used some of the factoids in this article. While some propose material “savings” and “agility” enabled by uninhibited workforce communications and sharing, the global financial services marketplace imposes the need for rational/rationalized risk management and some level of due diligence evidence. Paul Mozur provides a brief vignette about some of the risks associated with what seems like China’s dependence on pirated software. Mr. Mozur argues that unlicensed Windows software is not being patched, so the vulnerability ecosystem in China is much richer for attackers than is found in societies where software piracy is less pronounced. Because of the scale of the issue, this seems like it is a valid nation-specific risk — one that might add some context to some individual’s urges to enforce China-specific data communications controls.

Again, there is no perfect approach to identifying security controls at the right grain. Story-telling about risks works best with real and relevant fact-sets. This little article may help flesh out one facet of the risks associated with more-open, rather than more segmented data communications networks.

REFERENCES:
“China, Addicted to Bootleg Software, Reels From Ransomware Attack.”
https://mobile.nytimes.com/2017/05/15/business/china-ransomware-wannacry-hacking.html


‘Best Practices’ IT Should Avoid

June 20, 2017

12 ‘Best Practices’ IT Should Avoid At All Costs.

A colleague mentioned this title and I could not resist scanning the list.

They offer support to some of the funnier Dilbert cartoons, AND they should spark some reflection (maybe more) for some of us working in Global Financial Services.

1. Tell everyone they’re your customer
2. Establish SLAs and treat them like contracts
3. Tell dumb-user stories
4. Institute charge-backs
5. Insist on ROI
6. Charter IT projects
7. Assign project sponsors
8. Establish a cloud computing strategy
9. Go Agile. Go offshore. Do both at the same time
10. Interrupt interruptions with interruptions
11. Juggle lots of projects
12. Say no or yes no matter the request

If any of these ring local (or ring true), then I strongly recommend Bob Lewis’ review of these ‘best practices.’

If any of them make you wince, you might want to read an excellent response to Mr. Lewis by Dieder Pironet.

In any case, this seems like an important set of issues. Both these authors do a good job reminding us that we should avoid simply repeating any them without careful analysis & consideration.

REFERENCES:
12 ‘Best Practices’ IT Should Avoid At All Costs.
http://www.cio.com/article/3200445/it-strategy/12-best-practices-it-should-avoid-at-all-costs.html
By Bob Lewis, 06-13-2017

12 ‘best practices’ IT should avoid at all costs – My stance.
https://www.linkedin.com/pulse/12-best-practices-should-avoid-all-costs-my-stance-didier-pironet
By Didier Pironet, 06-19-2017


%d bloggers like this: