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.

Comments
Security vs. Speed: The Risk of Rushing to the Cloud
Threaded  |  Newest First  |  Oldest First
aumickmanuela
aumickmanuela,
User Rank: Strategist
2/7/2018 | 9:56:31 AM
Not safe
Yeah, i can tottaly agree with your tips, you are right) Cloud is not safe at all 
nosmo_king
nosmo_king,
User Rank: Strategist
2/7/2018 | 10:14:59 AM
Re: Not safe
I am sorry you feel that way, I know it can be overwhelming at times and I have felt that pain.

It is possible to use cloud services safely, when thought and care are woven into the decision-making process from the very start, not least of all determining what services and data are eligible to be shipped to the cloud and which must stay within the enterprise.

If the course of technology has taught us anything it is that over a shortish period of time the market will consolidate into fewer potential suppliers and the less than spectacular ones will go out of business relatively quickly.

Don't throw the metaphoric baby out with the bathwater just yet.
BrianN060
BrianN060,
User Rank: Ninja
2/7/2018 | 7:34:27 PM
Re: Not safe
As with all optimization choices, it depends on your priorities.  For many use-cases, the hybrid-cloud model provides the best balance of security vs. cost tradeoffs.  As other commenters have mentioned, the physical location of the public-cloud assets can have important security implications.  Most important is which of your organization's data assets you trust to the public-cloud, and which do you keep within your own perimeter.  Start there; then evaluate public-cloud vendors/services. 
Alsec
Alsec,
User Rank: Apprentice
2/9/2018 | 6:20:26 AM
Re: Not safe
Thumbs up. I totally agree.
REISEN1955
REISEN1955,
User Rank: Ninja
2/14/2018 | 1:37:11 PM
Re: Not safe
Woz - our great ancient savant from Apple - stated flat out that there is no security in the cloud.  That said, the cloud is - at most base - just a longer RJ-45 or optic cable from your endpooint to another server somewhere in the world hosted by god knows who.  The cloud has to reside on something somewhere and adding layers of exposure on top of your own protection increases risk many times over.   Not to add too that another set of human hands on a distant keyboard working with your data as an unknown too.

No safety in the cloud - it is a snake oil pitch worthy of W.C. Fields
nosmo_king
nosmo_king,
User Rank: Strategist
2/7/2018 | 10:06:26 AM
Understanding the kill chain is a key part of due diligence
When selecting a SaaS provider it amazes me how infrequently someone thinks to ask the provider who supplies their platform, their infrstructure and their support services.

It is not very often that a second-tier or lower SaaS provider houses their own servers, does their own maintenance and backups, or provides their own customer support.

These are usually spread out to multiple providers, and understanding who they are and who provides service to them must be a part of security due diligence. You have to know where your data is going to end up and who will have what level of access to it.

While the initial supplier may do and say all the right things in regard to security and privacy, it is necessary to go through the whole chain of suppliers to determine the complete truth.


Edge-DRsplash-10-edge-articles
I Smell a RAT! New Cybersecurity Threats for the Crypto Industry
David Trepp, Partner, IT Assurance with accounting and advisory firm BPM LLP,  7/9/2021
News
Attacks on Kaseya Servers Led to Ransomware in Less Than 2 Hours
Robert Lemos, Contributing Writer,  7/7/2021
Commentary
It's in the Game (but It Shouldn't Be)
Tal Memran, Cybersecurity Expert, CYE,  7/9/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
The 10 Most Impactful Types of Vulnerabilities for Enterprises Today
Managing system vulnerabilities is one of the old est - and most frustrating - security challenges that enterprise defenders face. Every software application and hardware device ships with intrinsic flaws - flaws that, if critical enough, attackers can exploit from anywhere in the world. It's crucial that defenders take stock of what areas of the tech stack have the most emerging, and critical, vulnerabilities they must manage. It's not just zero day vulnerabilities. Consider that CISA's Known Exploited Vulnerabilities (KEV) catalog lists vulnerabilitlies in widely used applications that are "actively exploited," and most of them are flaws that were discovered several years ago and have been fixed. There are also emerging vulnerabilities in 5G networks, cloud infrastructure, Edge applications, and firmwares to consider.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2023-1142
PUBLISHED: 2023-03-27
In Delta Electronics InfraSuite Device Master versions prior to 1.0.5, an attacker could use URL decoding to retrieve system files, credentials, and bypass authentication resulting in privilege escalation.
CVE-2023-1143
PUBLISHED: 2023-03-27
In Delta Electronics InfraSuite Device Master versions prior to 1.0.5, an attacker could use Lua scripts, which could allow an attacker to remotely execute arbitrary code.
CVE-2023-1144
PUBLISHED: 2023-03-27
Delta Electronics InfraSuite Device Master versions prior to 1.0.5 contains an improper access control vulnerability in which an attacker can use the Device-Gateway service and bypass authorization, which could result in privilege escalation.
CVE-2023-1145
PUBLISHED: 2023-03-27
Delta Electronics InfraSuite Device Master versions prior to 1.0.5 are affected by a deserialization vulnerability targeting the Device-DataCollect service, which could allow deserialization of requests prior to authentication, resulting in remote code execution.
CVE-2023-1655
PUBLISHED: 2023-03-27
Heap-based Buffer Overflow in GitHub repository gpac/gpac prior to 2.4.0.