Cloud Concentration Brings Operational Risks

July 18, 2018

The sales job included a theme that the Internet is so decentralized that anything named cloud simply inherited all the good ‘ilities’ that massive decentralization might deliver. One of the core tenets of that Internet story-telling is about the resiliency that decentralization guarantees — as in: no single outage can cause problems for your cloud-delivered services.

The reality is that story is too often just nonsense. Google, Amazon, and Microsoft control enormous amounts of the infrastructure and operations upon which “cloud” services depend. When any of these three companies has an outage, broad swaths of “cloud-delivered” business services experience outages as well. If you are going to depend on cloud-enabled operations for your success, use care in how you define that success, and how your communicate about service levels with your customers. This is especially problematic for industries where customers have been trained to expect extremely high service levels — global financial services enterprises fall into this category.  Factor this risk into your business & technical plans.

Yesterday, Tuesday, July 17th, Google’s services that provide computing storage and data management tools for companies failed. The customers who depended upon those foundational services also failed. Snapchat and Spotify were two high profile examples, but the outages were far more widespread. Google services that also depend upon the storage and data management tools also failed. It appears that Google Cloud Networking was knocked down as the company reported “We are investigating a problem with Google Cloud Global Load balancers returning 502s for many services including AppEngine, Stackdriver, Dialogflow, as well as customer Global Load Balancers.” This has broad impact because all customers attempting to deliver high quality services depend on load balancers. It appears that this networking issue caused downstream outages like those experienced by Breitbart and Drudge Report.

This was the 5th non-trivial outage this year for Google’s AppEngine. Google’s ComputeEngine has had 7 outages this year, 12 for their Cloud Networking, 8 for their Stackdriver, 3 for Google Cloud Console, 3 for Cloud Pub/Sub, 4 for Google Kubernetes Engine, 2 for Cloud Storage, 4 for BigQuery, 2 for their DataStore, 2 for their Cloud Developer Tools, and 1 reported for their Identity & Security services.
To add insult, it appears that the Google Enterprise Support page may have also not working during the outage on the 17th…

Amazon also experienced service failures that were widely reported the day before (although they are not documented on the company’s service health dashboard).
Microsoft had “internal routing” failures that resulted in widespread service outages for over an hour on the 16th as well.

Plan this reality into your cloud-enabled strategies, architectures, designs, implementations, testing, monitoring, reporting, and contracts.

REFERENCES:
Google Cloud Status Dashboard
https://status.cloud.google.com/summary

Amazon Service Health Dashboard
https://status.aws.amazon.com/

Azure Status History
https://azure.microsoft.com/en-us/status/history/
Azure Status
https://azure.microsoft.com/en-us/status/
Office365 Health
https://portal.office.com/servicestatus

Google Cloud Has Disruption, Bringing Snapchat, Spotify Down
https://www.bloomberg.com/news/articles/2018-07-17/google-cloud-has-disruption-bringing-snapchat-spotify-down
By Mark Bergen, July 17, 2018

Spotify, Snapchat, and more are down following Google Cloud incident (update: fixed)
https://venturebeat.com/2018/07/17/discord-snapchat-and-more-are-down-following-google-cloud-incident/
Jeff Grubb, JULY 17, 2018

Google Cloud Platform fixes issues that took down Spotify, Snapchat and other popular sites
https://www.cnbc.com/2018/07/13/google-cloud-platform-reports-issues-snap-and-other-popular-apps-affe.html
Chloe Aiello, 07-17-2018

[Update: Resolved] Google Cloud has been experiencing an outage, resulting in widespread problems with several services
https://www.androidpolice.com/2018/07/17/google-cloud-experiencing-outage-resulting-widespread-problems-several-services/
By Ryne Hager, 07-17-2018

Google Enterprise Support page Outage Reference

Advertisements

Bias & Error In Security AI/ML

July 14, 2018

It is difficult to get through a few minutes today without the arrival of some sort of vendor spam including the use of artificial intelligence and machine learning (AI/ML) to analyze event/threat/vulnerability data and then provide actionable guidance, or to perform/trigger actions themselves.

Global financial services enterprises have extreme risk analysis needs in the face of enormous streams of threat, vulnerability, and event data. While it might seem attractive to hook up with one or more of these AI/ML hypsters, think hard before incorporating these types of systems into your risk analysis pipelines.  At some point they will be exposed to discovery — and at that point is there risk to your brand?

In a manner analogous to facial recognition technologies, AI/ML-driven security analysis technology is coded, configured, and trained by humans, and must incorporate the potential for material bias and unknown error.

Microsoft recently called for regulation of facial recognition technology and its application.  I don’t know if regulation is the appropriate path for AI/ML-driven security analysis technologies.  I think that we do, though, need to remain aware of the bias and error in our implementations — and protect our employers from unjustifiable liability risks on this front.  Demand transparency and strong evidence of due diligence from your vendors, and test, test, test.

References:

“Facial recognition technology: The need for public regulation and corporate responsibility.” Jul 13, 2018, by Brad Smith – President and Chief Legal Officer, Microsoft
https://blogs.microsoft.com/on-the-issues/2018/07/13/facial-recognition-technology-the-need-for-public-regulation-and-corporate-responsibility/

“The Future Computed – Artificial Intelligence and its role in society.”
By Microsoft.
https://blogs.microsoft.com/uploads/2018/02/The-Future-Computed_2.8.18.pdf


Cloud File Sync Requires New Data Theft Protections

June 28, 2018

Microsoft Azure File Sync has been slowly evolving since it was released last year.
https://azure.microsoft.com/en-us/blog/announcing-the-public-preview-for-azure-file-sync/ and
https://docs.microsoft.com/en-us/azure/storage/files/storage-sync-files-deployment-guide?tabs=portal and https://azure.microsoft.com/en-us/roadmap/azure-file-sync/

The company also added “Azure:” [Azure Drive] to PowerShell to support discovery and navigation of all Azure resources including filesystems.
https://blogs.msdn.microsoft.com/powershell/2017/10/19/navigate-azure-resources-just-like-a-file-system/

Azure File Sync helps users keep Azure File shares in sync with their Windows Servers. Microsoft promotes the happy-path, where these servers are on-premise in your enterprise, but supports syncing with endpoints of any trust relationship.

What are my concerns?

The combination makes it much easier to discover Azure-hosted data and data exfiltration paths and then to get them set up to automatically ship new data into or out of your intended environment(s).  In other words, helping hostile parties to introduce their data or their malware into your organization’s Azure-hosted file systems, or helping hostile parties to steal your data while leaving a minimum of evidence describing who did what.

Why would I say that?

Many roles across global Financial Services enterprises are engaging in architecture risk analysis (ARA) as part of their day to day activities.  If we approach this topic like we were engaged in ARA fact finding, we might discover the following:

Too easy to share with untrustworthy endpoints:
It appears that anyone with the appropriate key (a string) can access a given Azure File Share from any Azure VM on any subscription. What could go wrong?
Microsoft customers can use shared access signatures (SAS) to generate tokens that have specific permissions, and which are valid for a specified time interval. These shared access signature keys are supported by the Azure Files (and File Sync) REST API and the client libraries.
A financial services approach might permit Azure File drive Shares on a given private Virtual Network to be secured in a manner so it would be only available via the Virtual Network using a private IP address on that same network.
https://feedback.azure.com/forums/217298-storage/suggestions/5993281-azure-files-on-a-virtual-network

Weak audit trail:
If you need to mount the Azure file share over SMB, you currently must use the storage account keys assigned to the underlying Azure File Storage.
As a result, in the Azure logs and file properties the user name for connecting to a given Azure File share is the storage account name regardless of who is using the storage account keys. If multiple users connect, they have to share an account. This seems to make effective auditing problematic.  It also seems to violate a broad range of commitments we all make to regulators, customers, and other constituencies.
https://feedback.azure.com/forums/217298-storage/suggestions/33477253-keep-track-of-the-file-owner
This limitation may be changing. Last month Microsoft announced a preview of more identity and authorization options for interacting with Azure storage. Time will tell.
https://docs.microsoft.com/en-us/rest/api/storageservices/Authorization-for-the-Azure-Storage-Services and https://docs.microsoft.com/en-us/rest/api/storageservices/authenticate-with-azure-active-directory

Missing link(s) to Active Directory:
Azure Files does not support Active Directory directly, so those sync’d shares don’t enforce your AD ACLs.
Azure File Sync preserves and replicates all discretionary ACLs, or DACLs, (whether Active Directory-based or local) to all server endpoints to which it syncs. Because those Windows Server instances can already authenticate with Active Directory, Microsoft sells Azure File Sync as safe-enough (…to address that happy path).  Unfortunately, Azure File Sync will synchronize files with untrusted servers — where all those controls can be ignored or circumvented.
https://docs.microsoft.com/en-us/azure/storage/files/storage-files-faq#security-authentication-and-access-control

Requires weakening your hardened endpoints:
Azure File Sync requires that Windows servers host the AzureRM PowerShell module, which currently requires Internet Explorer to be installed. …Hardened server no more…
https://feedback.azure.com/forums/217298-storage/suggestions/31909372-add-support-for-server-core-installations-for-azur

Plans for public anonymous access:
Microsoft is planning to support public anonymous read access to files stored on Azure file storage via its REST interface.
https://feedback.azure.com/forums/217298-storage/suggestions/7188650-allow-anonymous-public-access-to-azure-file-storag and https://docs.microsoft.com/en-us/rest/api/storageservices/authenticate-with-azure-active-directory

Port 445 (again):
Azure file storage configuration is exposed via TCP port 445. Is it wise to begin opening up port 445 of your Microsoft cloud environment? Given the history of Microsoft vulnerabilities exposed on port 445, many will probably hesitate.
https://feedback.azure.com/forums/217298-storage/suggestions/15001032-allow-access-to-file-storage-configuration-to-use

Goal of hosting Windows File Server in Azure:
Microsoft intends to deliver Azure Files in a manner that ensures parity with Windows File Server.
https://feedback.azure.com/forums/217298-storage/suggestions/19693045-automatically-mount-an-azure-file-share-to-a-windo

What other potential issues or concerns should we investigate?

  • Does the Azure File Storage REST interface resist abuse well enough to support its use in specified use cases (since each use case will have given risks and opportunities)?
  • Can a given use case tolerate risks associated with proposed or planned Microsoft upgrades to Azure File Storage REST, Azure File Sync, or Azure:?
  • Are there impacts on or implications for the way we need to manage our Azure AD?
  • Others?

What do you think?

 


Increasingly Difficult to Conduct Sensitive Business

May 11, 2018

Craig S. Smith updates us on some of the latest misuses of Alexa and Siri — with attackers “exploiting the gap between human and machine speech recognition.”  Using only audio an attacker can mute your device, then begin issuing commands.  At a minimum, this is a data leakage challenge.  Depending on the configuration of your mobile device or your Apple/Amazon/Google table-top device, those commands may be coming from you — along with the authority that brings.  For some that translates into a risk worth considering.

Working on any type of truly confidential business around your voice-ready devices is increasingly risk-rich.  For global Financial Services enterprises, the scale of the risks seems to warrant keeping significant distance between all voice-aware devices and your key leaders, those with material finance approval authority, anyone working on core investing strategy or its hands-on execution — the list goes on.  Leaving all mobile devices outside Board of Directors meetings is common practice.  Maybe that practice needs to be expanded.

Read this short article and think about your exposures.

 

REFERENCES

“Alexa and Siri Can Hear This Hidden Command. You Can’t.” By Craig S. Smith https://www.nytimes.com/2018/05/10/technology/alexa-siri-hidden-command-audio-attacks.html

 


A Rant on Risk Readiness Worth Reading

May 6, 2018

I just read and then re-read a rant by Steve King about how our attack resistance is not keeping up with attacker’s capabilities.  It appears to be an emotion-rich rant, using illustrations of varying quality, but the high level argument is worth thinking about.

King maintains that our infrastructures & operations are evolving into larger & more complex attack surfaces while the threat landscape is populated by ever more capable hostile actors, and we appear to be less prepared and more exposed than we have ever been.

There may be lots of reasons to discount some of the content & structure of the essay, but for too many organizations the message seems like an important one.

What do you think?

 

REFERENCES:

“Intellectual Property? Why bother?”  https://www.linkedin.com/pulse/intellectual-property-why-bother-steve-king-cism/

Steve King: https://www.linkedin.com/in/steveking1145/


Deception Has a Place in Secure Software

April 1, 2018

Deception has been standard military practice for millennia.  Attackers and defenders employ deception for a variety of goals:

Deceive – Cause a person to believe what is not true
Degrade – Temporary reduction in effectiveness
Delay – Slow the time of arrival of forces or capabilities
Deny – Withhold information about capabilities
Destroy – Enemy capability cannot be restored
Disrupt – Interrupt or impede capabilities or systems
Divert – Force adversary to change course or direction
Exploit – Gain access to systems to collect or plant information
Neutralize – Render adversary incapable of interfering with activity
Suppress – Temporarily degrade adversary/tool below level to accomplish mission

The U.S. military uses what they call a “See, Think, Do” deception methodology.

The core idea is to manipulate the cognitive processes in the deception target’s mind that result in targeting decisions and in adversary actions that are advantageous to our operations, our tactical or strategic goals.  This methodology tends to result in looping through the following three questions:

(1) What does the target of our deceptive activities see when they observe our operations?
(2) What conclusions does that target draw from those observations?
(3) What action may the target take as a result of the conclusions based upon those observations?

Successful deception operations are those that do more than make the target “believe” or “think” that the deception is true.  Success also needs to result in action(s) or inaction that supports the our operational plan(s).

Deception tactics can target human attackers, their organizations, their code, or any set thereof.

It is standard practice across global financial services enterprise information security to implement layers of protections — never depending on only a single security device.  We are at a stage in the battle with global cybercrime that may demand we introduce deception as a new layer of defense.  When we architect, design, and implement our applications and systems, we may enhance our resistance to attack by employing tactics analogous to military deception to influence attackers and the hostile code they use.  This will not be quick or easy.

Who might you assign to this task?  Do not immediately regress to: “I wonder who is available.”  Like many security tasks, deception planning requires a relatively unique skillset.  We build and deploy our software in ways that expose a multitude of interfaces.  That practice results in complex and often numerous abuse cases.  Our worker will need to understand and analyze that matrix from a number of perspectives, and to project other’s thinking and actions into the future.  We might expect them to:

  1. Understand each component’s deception and other information operations/influence capabilities.
  2. Be intimately familiar with their organization’s missions and focus.
  3. Understand the concepts of centers of gravity, calculated risk, initiative, security, and surprise.
  4. Understand friendly and adversary intelligence systems and how they function.
  5. Possess technical understanding of intelligence sensors, the platforms on which they deploy, their reporting capabilities, and associated processing methodologies.
  6. Understand the psychological and cultural factors that might influence the adversary’s planning and decision making.
  7. Understand potential adversaries’ planning and decision-making processes (both formal and informal).
  8. Understand the assets that are available to support the deception.
It is more difficult than just that.  We live in a world of laws, regulations, contracts, and norms that will constrain our behaviors in ways that differ from what may be acceptable on other battlefields.  Our leaders and practitioners need to understand those limits and manage their activities in ways that align with our obligations.  This will require much more than technical and operational competence.  It requires a high level of maturity and a finely calibrated moral & ethical compass.  Superior deception campaigns will require careful planning, effective guard-rails, and serious management.
Darn!  Another difficult staffing challenge…
Get use to it if you want to deliver your applications to a user-base anywhere on the Internet, and/or if you want to run your business in the cloud — especially if your are a global financial services enterprise — you need to expand and enhance your threat resistance using deception.
What do you think?

REFERENCES:

“Influence Operations and the Internet: A 21st Century Issue Legal, Doctrinal, and Policy Challenges in the Cyber World.”
“JP 3-13.3, Operations Security.” 04 January 2012
http://www.dtic.mil/doctrine/concepts/concepts.htm

Recent US-CERT & FBI Alert A Good Read — Applicable to Us

March 19, 2018

The United States Computer Emergency Readiness Team (US-CERT) recently released an alert about sophisticated attacks against individuals and infrastructure that contained an excellent explanation of the series of attacker techniques that are applicable to all global Financial Services enterprises. Many of the techniques are possible and effective because of the availability of direct Internet connections. Absent direct Internet connectivity, many of the techniques detailed in the CERT alert would be ineffective.

Global Financial Services enterprises, responsible for protecting hundreds of billions, even trillions of dollars (other people’s money) are attractive cybercrime targets. We are also plagued by hucksters & hypesters who are attempting to transform our companies into what they claim will be disruptive, agile organizations using one or another technical pitch that simply translates into “anything, anywhere, anytime.”  The foundation of these pitches seems to be “Internet everywhere” or even “replace your inconvenient internal networks with the Internet” while eliminating those legacy security and constraining security practices.

We can all learn from the details in this Alert.

From the alert:

[The] alert provides information on Russian government actions targeting U.S. Government entities as well as organizations in the energy, nuclear, commercial facilities, water, aviation, and critical manufacturing sectors. It also contains indicators of compromise (IOCs) and technical details on the tactics, techniques, and procedures (TTPs) used by Russian government cyber actors on compromised victim networks. DHS and FBI produced this alert to educate network defenders to enhance their ability to identify and reduce exposure to malicious activity.

DHS and FBI characterize this activity as a multi-stage intrusion campaign by Russian government cyber actors who targeted small commercial facilities’ networks where they staged malware, conducted spear phishing, and gained remote access into energy sector networks. After obtaining access, the Russian government cyber actors conducted network reconnaissance, moved laterally, and collected information pertaining to Industrial Control Systems (ICS).

Take the time to review it. Replace “industrial control systems” with your most important systems as you read.

For many of us, the material may be useful in our outreach and educational communications.

The 20-some recommendations listed in the “General Best Practices Applicable to this Campaign” section also seem applicable to Financial Services.

REFERENCES
“Alert (TA18-074A) Russian Government Cyber Activity Targeting Energy and Other Critical Infrastructure Sectors.” Release date: March 15, 2018. https://www.us-cert.gov/ncas/alerts/TA18-074A

“Cyberattacks Put Russian Fingers on the Switch at Power Plants, U.S. Says.” By Nicole Perlroth and David E. Sanger,The New York Times. https://www.nytimes.com/2018/03/15/us/politics/russia-cyberattacks.html


%d bloggers like this: