Tag: dome9

  • DevOps Chat: Security in the Cloud with Dome9’s Zolar Alon

    DevOps Chat: Security in the Cloud with Dome9’s Zolar Alon

    Dome9 is in the business of cloud security, so it’s no wonder some of the world’s top companies rely in it to secure their sensitive data and applications in Amazon Web Services, Microsoft Azure and Google Cloud environments. And with last week’s announcement of Check Point’s aquisition of Dome9, an even greater number of users will be able to take advantage of its SaaS solution.

    In a recent DevOps Chat, Dome9 co-founder and CEO Zohar Alon spoke with me about what he sees in the cloud security space as many organizations embark on their second generation of public cloud expansion.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    Transcript

    Alan Shimel: Hello, everyone. It’s Alan Shimel, devopsy.kinsta.cloud, Security Boulevard, and we’re here for another DevOps Chat. Today’s DevOps Chat features and old friend of mine from the security world, Zohar Alon, CEO and co-founder of Dome9. Zohar, welcome to DevOps Chat.

    Zohar Alon: Alan, great to be here.

    Shimel: My pleasure to have you here, my friend. Zohar, let’s get this out of the way first. Some of our listeners are not necessarily from the security world. They’re from the DevOps world. They may not be familiar with Dome9. So let’s first let them know a little bit. You know, you live and breathe it, but tell them who Dome9 is.

    Alon: Sure. So Dome9 is a SaaS solution that helps security organizations and some DevOps and development organizations secure their public cloud environments as they grow and prosper from the single cloud to the multi-cloud focusing on AWS, Azure, and Google Cloud platform. A multitude of solutions.

    We’ve been in the market from the very beginning covering elements like network security in the cloud which is a bit different, governance and compliance, continuance compliance, and how our customers can tie continuance compliance to their development processes and their build processes and things like identity and access management protection for public cloud that prevent attackers from targeting the developers as the weak link as a vector of attack for compromising the credentials in real time by hacking into their laptops and pigging-backing on their authenticated and trusted sessions to create mayhem and havoc in the public cloud environment of the customer. Just celebrated joining our hundred employee and going strong in both our headquarters in Tel Aviv and Mountain View, California.

    Shimel: Absolutely. Very good. So Zohar, and I should mention, look, I know you and Dome9 pretty much from the year you started if not the day you started, right? I think it was an RSA event?

    Alon: Yes, yes, 2012, very early on.

    Shimel: I was going to say, you know, in a previous – you have a long history in the InfoSec world. Look, the topic for today is really have we seen, you know, the classic, you know, crossing the chasm model of early adopters, early mainstream, late mainstream, laggards, where are we with this in cloud adoption as it relates to cloud security? And at this point are we confident in saying that, look, it’s basically just the laggards at this point who haven’t already at least started their cloud migrations?

    Alon: I can say this for certain, that the level – at Dome9 we focus on the top segment of the enterprise customers, let’s say the global 5000 organizations and their cloud deployments; and there’s not a single industry, there’s not a single geography that we are not seeing a race to the cloud, in many cases, multi-cloud deployments very early on. What I’m sensing is that we have a lot of organizations that already completed their kind of version one of public cloud experience that was comprised of some lift and shift and some building of new systems in the cloud. They are now busy architecting their next generation, their second generation of public cloud expansion where elements of making not just the default but actively working to decommission the old infrastructure.

    And remember the motivation is you always have a software or a hardware refresh cycle happening somewhere, whether it’s for your switching fabric or for your compute fabric, in your various data centers or you need to upgrade those Windows 2008 and it’s all involves some interesting costs with it. So the drivers are already there. Once you already get the momentum and the velocity and the confidence, it’s something that is inevitable and it actually happens faster and is encouraged by kind of the known technical people, whether it’s the procurement or the finance people that realize that their support to this activity could save the organization actually a lot of money.

    We saw that AWS revenue run rate, just AWS is around $40 billion now, and we just saw that the big Cisco revenue run rate is $48 billion. So the reality that we have crossed the chasm and even kind of gotten to the late point. The late majority is already feeling it quite seriously. I can say this for certain with a lot of certainty.

    From our perspective at Dome9, we are also seeing organizations already architecting their second generation of what is to deliver continuous security and compliance and governance to their new architectures in the cloud. This is kind of it goes hand in hand. This is where we also see this kind of the maturity in the level of the people that we talk to and their requirements and their understanding that there’s not just a single or few parameters you need to take care of, but if you count them there are about 10 different areas of attention that you need to be very well covered with in order to provide to continue that trend and complete the migrations and sell those data centers as Intuit just did. I think they announced about two months ago that they sold their last data center. I believe we’re going to see a lot more of those announcements. We don’t need to worry. This real estate is not going away. Amazon buys it through Equinox and its partners on the other hand. So it’s not as if we need less compute. We just need a better, more resilient, more focused compute environment.

    Shimel: Understood. Couple of things you mentioned in there that I want to bring to up or I’d like to kind of dive a little bit. First of all, yes, I do agree with you, even the late majority has moved to the cloud; but I think one of the things we’ve discovered about cloud migration is no one up and picks their entire – or very few people but some do – up and pick the entire infrastructure en masse over to the cloud, right? It’s a phased sort of migration, if you will. Some faster than others. And I’m talking now for large enterprises. I’m not talking startups. Larger enterprises. How long a migration do you think that usually is?

    Alon: Look, so the key is the data. You know, when Amazon announced their Snowball device to lift and shift a couple of petabytes, I think it was three, four years ago at Korean event, people were in shock and like about the thinking of getting the data to AWS is, you know, FedEx is faster than the largest wipe you can find. And then they surprise last year with the full-blown semitrailer that has essentially storage on it that can take essentially any amount of data from your premises to the public cloud. So this is one thing.

    Once you get the sense of trust with some data, then trusting the public cloud with your entire dataset is not something that is inconceivable, right? Trust is very binary. If you have it and if it’s good for the backend of my mobile application with the replication of a lot of my banking stuff, for example, then it’s good for everything. Then it’s just the technicalities on how we get there.

    Now, I think one example I want to give is that other than data that can there are no barriers, sometimes the database can be a barrier and that’s why you’d see solutions like AWS will sell you migration services to move from your own – they’ll practically give it to you to move from your Oracle to their cloud-based RDS system whether it’s Aurora or whether it’s any of the other SQL versions that they offer as a service. You can say that probably what’s left is the big old mainframes.

    I was fortunate enough to see that in real time about a year ago where Vanguard – so essentially after we figured out how to migrate data and databases, the only thing you might say may prohibit us from flying at speeds to the cloud may be an old system of record that sits tucked in in a mainframe computers in some data center at an unknown location. We have been able to see, to experience, and to help also several financial institutions in the process of securing a lot of replication process where they showed how they create using serverless computing and the AWS DynamoDB, a replica of their system of record of their big old mainframe, in the public cloud to provide essentially zero latency backend to their entire application framework. And I’m certain that one of the examples is Vanguard. There’s a very famous video of their heard of architecture describing how they used I think seven steps to create that replica of their mainframe.

    It’s an amazing—and this was announced, this was shown a year ago, so you’d probably think that they’ve been working on it for two years before, and this is the reality, that when it started making sense, you know, the technological barriers to live in tandem until you are forced to make a decision about those old systems or those legacy systems is something that any organization should strive for.

    And, you know, you don’t need to work hard, you know? Just, your public cloud rep, whether you go with Google Cloud or Azure or AWS, they will help you with providing the perfect architecture and how you’re baking security into it and how you optimize it for cost—they will pull in the partners that will help you on those things to kind of tie them across the board. And the reality is that—and that’s why I can say that, unless there is real slowness and some legislative or some other reason that could prevent an organization from starting its exploration, most of them are already picking it.

    And sometimes it’s not advertised. I’m surprised to see, you know, industrial companies that come to us and, you know, I ask them how much is their public cloud spend, and they say, “We just crossed the $10 million-a-year mark.” And that’s a serious business. That means that the current way that things are going, they’re gonna get to ($50 million) or to ($100 million) in the next two years. And this means that you’re not investing in your on-prem systems any more. That’s what I’m seeing in the market.

    Shimel: You know, I’m not gonna argue with what you’re seeing. You’re out there talking to people doing it. Zohar, unfortunately, we’re way past our time, but you know what, I’d love to have you back on. I know we had a little bit of a technical glitch; hopefully, it’ll be ironed out where people are listening to.

    But let’s continue this discussion. I think it’s fascinating stuff, and I think people are interested to know. And we didn’t even—I really wanted to touch on what does this mean for cloud security? What does it mean for DevSecOps? Let’s do that in part two, if it’s okay with you.

    Alon: Absolutely. Looking forward.

    Shimel: Okay. Zohar Alon, Founder and CEO of Dome9—thanks for being our guest on DevOps Chat. This is Alan Shimel. You’ve just listened to another DevOps Chat.

    — Alan Shimel

  • It’s the Outbound Stupid!

    It’s the Outbound Stupid!

    As nice as the word “Egress” may sound, I like “Outbound” better. Outbound is hardcore firewalling for the traffic that was initiated on the “trusted” side of the firewall, and is destined OUT to the unknown. However, over the last 20 years network administrators have put much more emphasis on what can come IN to their networks, rather than to worry about what comes OUT of them. There are many reasons for that, but the key one is that if nothing can come in, then we need not worry about what comes out. Right? Yea, right…
    Fast Forward 2014 we have firewalls everywhere. On our smartphones, laptops and home broadband wifi routers. In the cloud, any typical IaaS setup has a firewall for every group of instances, usually called Security Group and every instance has its own, internal firewall that is controlled by the instance OS. We are starting to see more and more people that use them as a core building block, in a  network security architecture, and as a fundamental element of it. But as most of you (us) actually spend time, energy and concern about inbound firewall rules, only 15% of you (us) even bother with the Outbound. That’s true, and its about time we change that.

    Plan. Plan for Success.

    A well planned inbound firewall policy can give the bad guys a true challenge, but what happens when they do get in and there’s no outbound policy in place? Its an all-you-can-eat buffet. With a well planned Outbound policy, theres a strong chance they will go away, or be easily discovered – and that’s a great ROI for your time!
    It all starts with a written (English, not Erlang or Java) security policy that outlines the way groups of servers interact with each other and with the outside world. First for the inbound/ingress which should be pretty easy to formulate. Then comes the outbound/egress tricky part – lets take a closer look at an application server.
    Usually application servers sits in one of the middle tier, trusting traffic coming from the web-tier and initiating requests to the database tier before sending the replies back to the web servers.
    Inbound: Allow traffic from Web Servers, usually only for HTTP or HTTPS depending on the Web<>APP settings.
    Outbound: Allow DB traffic to the Databases on the specific DB port, for example, TCP3306 for MySQL.

    Don’t forget the monitoring

    Any monitoring solution you may be using, affects your security policy. An agent-based monitoring solution installed on the machine will have to be allowed to connect out, where an external monitoring service, that probes your servers from the outside, will have to be allowed in to do its job.
    Agent Based Monitoring: Allow Outbound on specific protocol to a specific IP or a list of IPs
    External Monitoring: Allow Inbound for specific protocol and from a specific IP or list of IPs

    What else on the Outbound? The Killer (No) Rules

    Our app server runs Ubuntu so it may needs access to the ubuntu update services and also needs DNS to live happily. Now the common theme would be to allow access to update services for outbound on https (TCP443) and to allow outbound DNS (UDP53). Right? WRONG. Why not limit only to the specific repository services that our OS needs? The hardline DevOps will kill updates altogether, stating that any part of your application should not update itself. You can always bake/launch a fresh updated one instead of messing with a working instance.
    Result: No Outbound HTTPS TCP443
    Now for DNS. If you are a security concerned it is recommended to stop using DNS altogether and use /etc/hosts instead. A less drastic approach would be to allow DNS access only to a DNS server that you trust (E.g. Google’s 8.8.8.8), this is done to make sure that data leaked using DNS queries could only reach Google, and they already know everything.
    Result: No Outbound DNS  UDP53 or Allow DNS (UDP53) to 8.8.8.8 if you must.

    Your Feedback Loop: The Network Logs

    After setting this strict Outbound policy, we can finally identify the services that were left hanging, as we just severed their lifeline. It could be a non-critical agent that we should uninstall, or, god forbid, a rogue piece of code some bad guy wrote and now can’t connect to its C&C server – more on that next time.

    Happy Firewalling,
    Zohar