Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Cloud Security

Study: 15 Per Cent of Business Cloud Users Have Been Hacked 72

An anonymous reader writes Recent research has identified that only one in ten cloud apps are secure enough for enterprise use. According to a report from cloud experts Netskope, organizations are employing an average of over 600 business cloud apps, despite the majority of software posing a high risk of data leak. The company showed that 15% of logins for business apps used by organizations had been breached by hackers. Over 20% of businesses in the Netskope cloud actively used more than 1,000 cloud apps, and over 8% of files in corporate-sanctioned cloud storage apps were in violation of DLP policies, source code, and other policies surrounding confidential and sensitive data. Google Drive, Facebook, Youtube, Twitter and Gmail were among the apps investigated in the Netskope research.
This discussion has been archived. No new comments can be posted.

Study: 15 Per Cent of Business Cloud Users Have Been Hacked

Comments Filter:
  • It's a lie! (Score:5, Funny)

    by Runaway1956 ( 1322357 ) on Thursday January 08, 2015 @11:18PM (#48771691) Homepage Journal

    The vendors have assured us that their servers are secure!

    • by Anonymous Coward

      Nah! The servers are secure, it's just the customer's data that isn't!

    • Re:It's a lie! (Score:5, Insightful)

      by MrBigInThePants ( 624986 ) on Friday January 09, 2015 @02:16AM (#48772455)
      I am sure it was those dastardly cloud people!

      In unrelated news....15% of passwords were set to "password" or similar....

      80% of the data was of little use.

      100% of the data was irrelevant to the well being and/or advancement of humanity.
      • I am sure it was those dastardly cloud people!

        In unrelated news....15% of passwords were set to "password" or similar....

        80% of the data was of little use.

        100% of the data was irrelevant to the well being and/or advancement of humanity.

        You have no idea how this works. "Passwords" are not going to be the problem in a hacking event on the scale of an enterprise cloud service. Even with your admin passwords there should be no way for an attacker to get in.

        • lol.

          I do know how it works. And you are waving a VERY broad brush there from a very short high horse.

          And have no sense of humour.

          I will bite my thumb at them, which is disgrace to them if they bear it.
    • by Charliemopps ( 1157495 ) on Friday January 09, 2015 @08:23AM (#48773745)

      The vendors have assured us that their servers are secure!

      You got modded funny, but that's exactly the point. The customers data is stored in my database. So I don't technically care if that data is stolen... other than the legal liability that would put me under. So I go to the Cloud service and they "assure" me that's secure and sign a contract stating as such. I'm done! It doesn't really matter if it really is secure or not. If the data's lost and the customer sues we point at the vendor.

      • Re:It's a lie! (Score:4, Insightful)

        by h4ck7h3p14n37 ( 926070 ) on Friday January 09, 2015 @11:31AM (#48774881) Homepage

        It sounds like you're using a crappy vendor. We have a bunch of gear at Rackspace and I have to sign legal waivers when I access certain features of their portal such as the firewall management section. They have never assured me that our systems are secure given I have enough access to make things incredibly insecure.

        Due to the nature of the data that we're working with we are legally obligated (PCI, HIPAA, etc.) to care about it being secure. If something does happen we are required to report a breach and can be fined by the government. We can't simply point to the vendor. Rackspace partners with companies such as Alert Logic (threat/vulnerability management), Imperva (traffic analysis, dynamic ip blocking, etc.) and Vormetric (data-at-rest encryption) in order to help us secure our environment.

        • Right, but you're talking about physical rackspace and not "the cloud" so you're entirely off topic. Why would they ever guarantee the security of a rack slot?

          We're talking about "The cloud" here, which is entirely different. You don't even know where the data is stored. Is it in New York? Chicago? India? All 3 places at once? To the laws of the country its stored in make the data available to local authorities without a warent? Is the vendor hiring temp workers from a country that has poor privacy laws and

    • Remember the literal definition of the cloud: "Someone else's server."

    • by tlhIngan ( 30335 )

      The vendors have assured us that their servers are secure!

      You joke, but it's perfectly possible that's the case.

      The servers weren't hacked - the user credentials were. After all, you won't believe some of the phishes that get out there, and once they steal credentials, well, it doesn't matter how well the vendor protects the data - the vulnerability will always be stolen credentials.

      Short of having cloud vendors mandate 2-factor security (imagine having to carry around an RSA key just to log into dropbox!),

  • It's 2015. . . who the hell puts anything on " The Cloud " without first heavily encrypting it ?
    • by Shados ( 741919 ) on Friday January 09, 2015 @12:47AM (#48772111)

      If a big part of the service is actually manipulating your data (email, database, charts, data analysis, etc...), then it needs to get decrypted somewhere at some point. The data can be intercepted then.

      • You can do some computational things on encrypted data, like create a database, which obviously adds some overhead. For example cryptdb:
        http://css.csail.mit.edu/crypt... [mit.edu]

        And built an application which then decrypts the data on the client when the user needs access to it, for example there is Mylar from the same research group as the database above:
        https://css.csail.mit.edu/myla... [mit.edu]

        • You can do some computational things on encrypted data, like create a database, which obviously adds some overhead. For example cryptdb:
          http://css.csail.mit.edu/crypt... [mit.edu]

          And built an application which then decrypts the data on the client when the user needs access to it, for example there is Mylar from the same research group as the database above:
          https://css.csail.mit.edu/myla... [mit.edu]

          I don't think you've ever used Cloud software. The entire point of it is to move development and maintenance outside your organization. Yes, I could upload encrypted data to "The cloud" and then write my own database and front end for it. But would defeat the entire point of putting it in the cloud in the first place. What you're describing is basically just an online data backup. No-one really needs that.

          Lets say you're a small non-profit and you want to create a ticketing system to track donations. Buying

          • by Lennie ( 16154 )

            There are so many definitions of cloud.

            The above mentioned solution could be based on open source software (the research project is open source).

            In a similar fashion to how Wordpress is currently hosted, your get updates from the vendor (WordPress) not from the hoster, but in the case above with encrypted data.

            Yes, SaaS providers will pretty much never go for it, because dealing with encryption means extra work for them.

            I was just pointing out it isn't completely impossible. Because that is what most people

    • by dbIII ( 701233 ) on Friday January 09, 2015 @01:22AM (#48772265)

      It's 2015. . . who the hell puts anything on " The Cloud " without first heavily encrypting it ?

      Your HR department and your payroll staff.

    • by Charliemopps ( 1157495 ) on Friday January 09, 2015 @08:37AM (#48773797)

      It's 2015. . . who the hell puts anything on " The Cloud " without first heavily encrypting it ?

      That's not going to help. I've administer a lot of these cloud products in my time. The main point is, you don't get to encrypt it yourself.

      You go to the vendor and say: "Encrypt it!"
      Vendor: "Ok! It's done!"
      You: "That was awfully fast, is it really encrypted?"
      Vendor: "Yes!"

      Demand an audit: We audited it and it meets our contract!
      Give us detailed information about XYZ: That's proprietary and/or security related, we can't release it!
      We want to put X in the contract: No, this is our standard contract and the only one we'll sign. Don't like it? Take a hike. By the way, we already have all your data and a migration would cost millions!
      Go to a different service: Here's the same contract that other place had and no we wont alter it.
      Find out its not encrypted when they said it was: Oh that was a bug or the fault of some admin we fired months ago. It's fixed now, trust us!

      It's virtually impossible to "Secure" a cloud service. I had so many problems with it I finally resigned myself to assuming cloud services have at best barely passable security. So nothing goes in that I'm afraid to lose. Even in the best cases, you have their entire support staff sitting there, probably hundreds or thousands of people, with the ability to reset all your admin passwords and even more direct DB access you have. Even if it's encrypted, they'll have all the keys. Whats worse, they control the firewall and gateways so an attack could be ongoing for weeks or months and you'll have no idea.

  • by Anonymous Coward

    A study produced by a company that sells cloud security solutions, how convenient their finds everyone needs their product.

    Really /. these posts are just getting sad.

    • by raymorris ( 2726007 ) on Thursday January 08, 2015 @11:54PM (#48771883) Journal

      You make a good point. Also, every other day we see another story of "XXX million lost in hack".

          It's become so frequent we almost get completely numb to it. A week ago, someone posted here that Microsoft hadn't had any significant issues in a while - 48 hours after their Xbox network was taken down for several days. Having the whole network down for a several days is so common that we forget all about it a couple of days later. That's how common major security issues are right now. We need to make some significant changes in how we develop systems.

      • Yes but how? Wasn't the microsoft outage the result of a co-ordinated DDoS? It doesn't matter if you make the world's most secure system it won't deal with that kind of assault. Do we re-design the internet to prevent them?

        Very few of the hacks in the past x number of years were actual hacks using exploits. The majority were the result of lax user passwords, social engineering, or internal access to systems. Any design around these issues has a direct result of reducing functionality.

        • by raymorris ( 2726007 ) on Friday January 09, 2015 @04:56AM (#48773045) Journal

          > The majority were the result of lax user passwords, social engineering, or internal access to systems. Any design around these issues has a direct result of reducing functionality.

          I don't know that most of the major incidents were, but let's just assume that's true for a moment. Those are all security. Security is more than just the firewall.

          A complete answer would run 600 pages, but here are some solutions in summary.

          Lax user pass words - pass words are so 1980. Use pass phrases and keys. Just doing a search and replace to say "pass phrase" or "secret sentence" every where we've written "password" would largely solve that problem.

          Internal access - has normally been COMPLETELY UNNECESSARY internal access. Snowden didn't need access to all of those documents to do his job, and that's the NSA, an organization that should have good security. Right now at work we're auditing internal access. Everyone should, because in most organizations some people have far, far more access than what makes sense.

          Social engineering - test and reward. Call up a few employees at random maybe once per year with a social engineering pen test. Employees who properly refuse to give out sensitive information get a gift card for dinner or some other recognition for doing a good job. Tell employees ahead of time that you plan to do that this year. When the attacker calls, employees will think "maybe this is security calling, here's my chance to show I know better and win".

          Those are a few examples. For technical vulnerabilities, it requires changing the mindset from "does the system give good output when fed good input?" to also include "what happens if a bad guy feeds it unexpected input?". My coworkers are slowly starting to realize that if they announce "the new system works, you type your password and it logs you in", I'm going to ask "what happens if I type in SQL code instead of my password?".

          Not just what happens when everything goes right, but what happens when things go wrong? This has the side effect of producing far more reliable systems. For example, ALL providers in a certain blind of business had the same bug in their software - it would all empty the data file if the disk was full. That's because they all wrote the new version of the data on top of the old. We made patched copies of all their software that gracefully handles disk full. What happens when things aren't as you expect. At work, we had lots of intermittent errors that were hard to track down, so they were just tolerated for years, with people cleaning up the mess they made every week. Asking "what happens if things don't go as expected?" revealed these were concurrency issues that were easily solved. So these security threats are not only solvable, but the changed perspective results in better, more reliable systems, and therefore less time-consuming and error-prone manual handling of errors.

          • Is that you, Bobby Tables?
          • So we're talking about the same thing, designing better systems meaning the entire security ecosystem within a company.

            Unfortunately the social engineering aspect is hard. Very hard. Extremely hard. I work for a major in the oil and gas industry and we have monthly internal phishing emails which are staged by IT&S and education campaigns etc and they send around the stats that some 3% of employees STILL fall for the "The manager has awarded you an iPad, click on this website and enter your login details

      • by Lennie ( 16154 )

        Also as a foreigner I'm now a 100% sure I can't put my data in a US cloud:

        http://media.ccc.de/browse/con... [media.ccc.de]

  • Shit (Score:3, Funny)

    by Anonymous Coward on Thursday January 08, 2015 @11:40PM (#48771807)

    What if I simply 3D print all my data and use Amazon drones to deliver it to other people? Is that still good? I don't want to be a Luddite!

  • by erp_consultant ( 2614861 ) on Thursday January 08, 2015 @11:49PM (#48771851)

    I've been around long enough to see things comes and go. The current flavor of the month is "cloud". Cloud this, cloud that. Even the behemoths of the ERP world - Oracle and SAP - are making an aggressive push to "the cloud". Companies like Workday and Salesforce are growing at a tremendous rate.

    It all seems very appealing. Say goodbye to multi year implementations and increasingly difficult and costly upgrades. Rent it by the seat rather than making large capital outlays. Fully object oriented design. Open standards vs. proprietary tools. Lots of great benefits.

    But.....

    As Willie Sutton once famously stated when asked why he robbed banks..."because that's where the money is". The data of your company, and other companies in the typical "multi-tenant" configuration is all in the one place. The bad guys know this. They will target these data centers to be sure.

    You are essentially taking your data from an environment you can control (largely) to one you cannot. That is a huge leap of faith.

    I expect that it is only a matter time before there will be a massive data breach for hosted cloud apps. We're not talking about someone's email account or twitter account. We're talking about an entire database full of SSN's and other personal information getting stolen. Everyone in your company and possibly customer and partner data as well. I don't want to be the one holding that press conference.

    • "As Willie Sutton once famously stated when asked why he robbed banks..."because that's where the money is"." ...AND?

      AND the people who listened to famous Willie Sutton put their money under their mattresses? Was the money in the mattress more secure than the bank? Were they robbed by locals and it was never reported in the "study"? Is locally stored data more secure than the Cloud? Willie Sutton is a great spokesperson for PRNewswire.com promotion of their cloud security.. "AND?"

    • by afidel ( 530433 ) on Friday January 09, 2015 @12:44AM (#48772099)

      Control is an illusion, if the folks at RSA can be spearfished and have their most valuable assets stolen basically anyone can. People are fallible and the bad guys only need one successful attack while the good guys need to defend perfectly. We run a relatively tight shop, no local admin, patches up to date, AV/Antispam on the email gateways, AV and Antimalware on the desktop, IDS/IPS in the firewall with additional IDS by spanning the vlans going to our firewall and the server vlan. What we've found is that we still end up with ~1% of our clients managing to get some kind of infection or infection attempt per month (the attempts are generally where an exploit of some kind succeeded but the payload was stopped by one of the defense layers from actually becoming persistent on the client).

      As far as the point from the article, we're moving to have as many of our cloud apps as possible use our SAML repository for authentication so that we can treat it as much as possible like an extension of our general security stance with password attempt monitoring, rate throttling and attack blocking, user lockout, etc. It doesn't help if the service itself is breached, but it at least stops the more casual authorized user leaks that seem to be one of the more common failures identified.

      • by dave562 ( 969951 )

        SAML repository for authentication so that we can treat it as much as possible like an extension of our general security stance with password attempt monitoring, rate throttling and attack blocking, user lockout, etc.

        You sir, sound like you know what you are doing.

        Do you ever have attempts coming back from any of your vendors?

        Or is the vendor simply passing data back to you about when accounts from your site are used in failed logon attempts to the cloud apps, via whatever their presentation layer is?

        • by Lennie ( 16154 )

          SAML ? Don't make me laugh:

          "In this paper we describe an in-depth analysis of 14 major SAML frameworks and show that 11 of them ... have critical XML Signature wrapping (XSW) vulnerabilities"

          " In order to protect integrity and authenticity of the exchanged SAML assertions, the XML Signature standard is applied. However, the signature verification algorithm is much more complex than in traditional signature formats like PKCS#7. The integrity protection can thus be successfully circumvented by application of

          • by afidel ( 530433 )

            That's cool, and I appreciate the security researchers and their work to strengthen both protocols and implementations, but in the real world the entire conversation happens inside a TLS stream so it's not that easy, not only do you have to insert yourself into the communications path between the user and the resource, but you have to break TLS in realtime. It does increase the scope of attacks like BEAST/CRIME/POODLE a bit, but since that paper is almost 3 years old you would hope that at least the major p

            • by Lennie ( 16154 )

              You might not be aware of what the attack is.

              The attack is about sending specially crafted XML requests/responses to circumvent the checks of the authentication system. Which allow you to login as a user of your choice.

              This has nothing to do with breaking TLS, what you do need is: the username and to know which application (URL) they are allowed to login into.

              • by afidel ( 530433 )

                Uh, no from the paper they are hijacking an existing challenge/response session with a valid signed SAML assertion but exploiting a weakness where the code that validates the assertion and the code that reads the claim token are not necessarily checking the same part of the response and so they can insert a bogus claim ticket with a valid assertion. This would require intercepting the assertion response and modifying it, and since the whole conversation is within a TLS session it requires some kind of MitM

                • by Lennie ( 16154 )

                  Sorry, my mistake. You are closer to the prerequisites than I was.

                  You need a signed assertion:

                  https://www.youtube.com/watch?... [youtube.com]

                  But getting a signed assertion is pretty easy, if it's a cloud service.

                  Just sign up.

                  Anyway, most implementations have been fixed. I hope. ;-)

                  Unless they upgrade or downgrade the XML-parser and break it by accident.

        • by afidel ( 530433 )

          SAML has all authentication happen at the IDP (user organization side), not at the relying party/service provider so any login attempts are at your SAML endpoint. In theory you could even not allow passwords at the SAML point at all (if you have all your machines Kerberos joined you could use the Kerberos claim ticket to generate the SAML assertion and not have an alternate fallback authentication method, but for convenience and interoperability that isn't usually the case and there's generally a forms base

    • Also, often the cost savings are a myth, especially for larger organisations.
      I ran the numbers for one of my customers recently - an Exec had suddenly decided that since "everyone" else had Salesforce, they must have it too.
      Replacing their existing well-crafted and nicely integrated CRM with SF would have cost a bomb in transition costs, with higher annual maintenance, for LESS functionality.

      Needless to say the boss killed that "good idea" pretty quick.

    • by Junta ( 36770 )

      Open standards vs. proprietary tools

      Actually, if anything the typical cloud experience doubles down on proprietary tools. Sure the vendor may be availing themselves of open technologies on the backend, but the vast majority of them use proprietary interfaces to interact with their customers.

  • by retroworks ( 652802 ) on Friday January 09, 2015 @12:24AM (#48772007) Homepage Journal
    Read the Summary, followed the links, ran the numbers. The firm that posted the PRNewswire.com press release obviously offered the Slashdot summary, and there is no solid data or info except "BE AFRAID! (And by the way, we are in the be-less-afraid-,-security-business). Perhaps there's plenty of discussion to be had on the premise, but the premise arrived via BINSPAM.
  • by Dan667 ( 564390 ) on Friday January 09, 2015 @01:05AM (#48772189)
    I am surprised people were naive to think "cloud" vendors could be trusted with their data.
    • by MobyDisk ( 75490 )

      I am surprised people were naive to think "cloud" vendors could be trusted with their data.

      You are assuming that the cloud vendors are at fault, but the article doesn't really pin the blame on anyone. Everyone's knee-jerk reaction is to blame the vendor, but who really is at fault here?

      The article talks about business users sharing files inappropriately, like opening them up publicly or storing files like source code on the cloud which is often in violation of the policies. It says that 15% of business users' accounts have been compromised, but it doesn't say why or how. So we don't know if th

  • That's completely and utterly ridic^~ %`4& --FREE V1AGRA! @ wanker7.com

  • A typical SaaS vendor has numerous clients, all with varying levels of sophistication in their password and identity management procedures.

    As if the need to ensure tenant isolation does not put enough pressure on the architects, they also have to worry about how well their customers are securing their own staff. The smart ones are doing Federation for predictable data transfers, and two-factor to secure the application layer. Even then, the legal people still make them sign disclaimers that ultimately, da

  • So, we're using UK English now? In the US, that's spelled "percent". Are we going to start seeing per centage and per centile too? The 1700's just called and said they want Slashdot to stop using their archaic spellings.
    • Maybe Anonymous User is British? I consider SlashDot an international news site, not an American one. If you want to complain about language start with all jerks mixing up then and than.
  • The level of network hacking against servers and internet systems is somewhat astonishing, and not widely known outside the industry.

    I did a small project where a small company wanted to monitor our equipment on a very small fleet of cars. One day, I discovered we were getting telemetry data from our cars. This created much excitement and surprise in the office, as no one was supposed to be driving any of our cars. After a bit more work, I discovered the car in question was in China. Now that was a sur

The use of money is all the advantage there is to having money. -- B. Franklin

Working...