Assessing the Top 5 Cloud Security Threats with Mark Russinovich

Play Assessing the Top 5 Cloud Security Threats with Mark Russinovich
Sign in to queue

Description

In this week's show Jeremy Chapman is joined by cyber security expert and author, Mark Russinovich, to assess the most frequently heard cloud security threats. Mark describes each threat with its threat level and shares how Microsoft architects its cloud services to maximize data security and protect against data loss. Jeremy and Mark also give pro tips to protect against credential loss and contain the risk of user-driven shadow IT.

Stay up to date with the latest shows at office.com/mechanics

Download the Windows Phone app or the Windows 8 app

Follow @OfficeMechanics on twitter

Embed

Download

Download this episode

The Discussion

  • User profile image
    Gilbert Baron

    i would feel a lot better if the data were encrypted while stored on your servers and the encryption were done on my system and only I had the key.
    Any thing else is not truly secure and is ken go government snooping.

  • User profile image
    lsjames

    Good high-level overview.  I do feel the Azure SQL Database service falls short for a couple of these threats.

    - The SQL Server Data tools in Visual Studio and (I think) SQL Management Studio are NOT set up to encrypt connections by default.  It's too easy for someone to connect directly to an Azure-hosted database (e.g. for dev, QA, or support) and forget to encrypt.  Whenever we find out about that we immediately make them change their password, but it just shouldn't be so easy.  Encryption should be turned on by default.  In fact, I would also suggest the tools should throw up scary warnings if things aren't encrypted.

    - Azure SQL databases should support Organizational (O365) accounts alongside local logins.  It makes it tough to centralize security when you have to create separate logins with separate passwords on each logical server.

  • User profile image
    androidi

    @Gilbert Baron: It could be argued that  if it's the government you're worried about, then you should implement as much of the encryption/protection etc as possible yourself because the company you're relying on to do it for you could be compelled to backdoor the OS/mitm network/change environment etc by the government. If the stuff was implemented inside your app, they'd have to hack the app itself and if you have top notch intrusion detection, that could be hard. So half of any security system is really about detecting attacks and layering the encryptions so that compromise of first layer doesn't allow getting to the 2nd layer.

  • User profile image
    Misha Nossik

    @Gilbert Barton: Of course data shall be encrypted with customer-controlled keys, but there is more. The OS, its apps and all of anti-malware, IDS and encryption software usually stored on the boot drive is vulnerable to attacks, particularly when the VM is shut down or paused. Boot volume encryption with pre-boot integrity check goes a long way to protect VM software (and some other stuff that ends up on the c: drive in cleartext unintentionally). Search for "VM encryption" on Azure marketplace for solutions.

    @androidi: one way to mitigate against the cryptopackage faults is to use "well known" encryption software native to the OS. Bitlocker on Windows, ecryptfs or dm-crypt on Linux for example. Own software may end up having more security problems than these options while certainly costing much more.

Add Your 2 Cents