Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Cloud Security //

Azure

5/4/2017
05:00 AM
Ashwin Krishnan
Ashwin Krishnan
News Analysis-Security Now
50%
50%

First AWS, Now Microsoft Cloud; Who's Next?

Outages are inevitable, but how can we deal with them better?

So, there we have it. Within a window of a few months, the top two public cloud providers on the planet -- Amazon Web Services LLC and Microsoft Cloud -- have had bodily seizures that have caused the rest of us (mere cells in their ecosystem) to go into crazy orbits. Enough of the drama, let's get to facts. In this age of information deluge it would not be presumptuous to assume that the reader may have forgotten the specifics, so let's recollect.

The Amazon Simple Storage Service (S3) had an outage on Tuesday, February 28. An authorized S3 team member who was using an established playbook executed a command which was intended to remove a small number of servers for one of the S3 subsystems that is used by the S3 billing process. However, one of the inputs to the command was entered incorrectly and a larger set of servers was removed than intended. And the rest, as they say, is history!

Now let's turn to the Microsoft episode. On Tuesday, March 21, Outlook, Hotmail, OneDrive, Skype and Xbox Live were all significantly impacted, and trouble ranged from being unable to log in to degraded services. True to form, the Microsoft response was to downplay the impact and provide little detail (by contrast, Amazon provided a much more detailed post mortem). A subset of Azure customers may have experienced intermittent login failures while authenticating with their Microsoft accounts. Engineers identified a recent deployment task as the potential root cause. Engineers rolled back the recent deployment task to mitigate the issue.

So, is this the death of public cloud? Nah. Far from it. And anyone who says otherwise should have their head examined. BUT, it should serve as a wake-up call to every IT, security and compliance professional across every industry. Why? Because this kind of "user error" or "deployment task snafu" can happen anywhere -- on-premises, on private cloud and on public cloud. And since every enterprise is deployed on one or more of the above, every enterprise is at risk. So enough of the fear mongering. What does someone do about it? Glad you asked.

There are really three vectors of control: scope, privileges and governance model.

Scope is really the number of "objects," a.k.a. the nuclear radius of what each admin (or script) is authorized to work on at any given time. Using the Microsoft Cloud example (I realize I am extrapolating since they have not provided any details), this may be the number of containers a deployment task can operate on at any given time.

Privileges calls for controlling what an administrator or task can do on the object. For instance, continuing with the container example from above, the privilege restriction could be that the container can be launched but not destroyed.

And finally, you need a governance model. This is really the implementation of best practices and a well-defined policy for enforcing the above two functions -- scope overview and control enforcement -- in a self-driven fashion. In this example, the policy could be to ensure that the number of containers an admin can operate remains under 100 (scope) and that any increase in that number automatically requires a pre-defined approval process (control). Further sophistication can easily be built in, where the human approver could easily be a bot that checks the type of container and the load on the system and approves (or denies) the request. Bottom-line -- checks and balances.

So there you have it. The two large public clouds have suffered embarrassing outages in the past month. They will recover, get stronger and most likely have future outages as well. The question for the rest of us is what we learn from their experience and how to make our environments in our own data centers and on private and public clouds better! If we don't, we may not be lucky enough to fight another day.

— Ashwin Krishnan, SVP, Products & Strategy, HyTrust

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/25/2020
Hacking Yourself: Marie Moe and Pacemaker Security
Gary McGraw Ph.D., Co-founder Berryville Institute of Machine Learning,  9/21/2020
Startup Aims to Map and Track All the IT and Security Things
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/22/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15208
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, when determining the common dimension size of two tensors, TFLite uses a `DCHECK` which is no-op outside of debug compilation modes. Since the function always returns the dimension of the first tensor, malicious attackers can ...
CVE-2020-15209
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, a crafted TFLite model can force a node to have as input a tensor backed by a `nullptr` buffer. This can be achieved by changing a buffer index in the flatbuffer serialization to convert a read-only tensor to a read-write one....
CVE-2020-15210
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, if a TFLite saved model uses the same tensor as both input and output of an operator, then, depending on the operator, we can observe a segmentation fault or just memory corruption. We have patched the issue in d58c96946b and ...
CVE-2020-15211
PUBLISHED: 2020-09-25
In TensorFlow Lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, saved models in the flatbuffer format use a double indexing scheme: a model has a set of subgraphs, each subgraph has a set of operators and each operator has a set of input/output tensors. The flatbuffer format uses indices f...
CVE-2020-15212
PUBLISHED: 2020-09-25
In TensorFlow Lite before versions 2.2.1 and 2.3.1, models using segment sum can trigger writes outside of bounds of heap allocated buffers by inserting negative elements in the segment ids tensor. Users having access to `segment_ids_data` can alter `output_index` and then write to outside of `outpu...