1 00:00:00,270 --> 00:00:01,950 Michael Novinson: Hello, this is Michael Novinson with 2 00:00:01,950 --> 00:00:05,220 Information Security Media Group. I'm joined today by Tom 3 00:00:05,220 --> 00:00:09,030 Gillis. He is the general manager of VMware's Advanced 4 00:00:09,060 --> 00:00:12,150 Networking and Security Business Group. Good morning, Tom. How 5 00:00:12,150 --> 00:00:12,570 are you? 6 00:00:12,869 --> 00:00:13,859 Tom Gillis: I'm good. How are you, Michael? 7 00:00:13,000 --> 00:00:15,459 Michael Novinson: I'm doing great. Thank you. I wanted to 8 00:00:15,522 --> 00:00:19,494 talk to you a little bit about the announcements made at VMware 9 00:00:19,557 --> 00:00:23,467 Explore last week. Let's start with the combinate. Some of the 10 00:00:23,530 --> 00:00:27,313 work you're doing to further tighten the integration between 11 00:00:27,376 --> 00:00:31,348 NSX and Carbon Black. I'd love to hear a little bit more around 12 00:00:31,412 --> 00:00:35,195 why you focused on bringing the NDR and the EDR together and 13 00:00:35,258 --> 00:00:37,150 what that means for customers. 14 00:00:37,360 --> 00:00:39,850 Tom Gillis: Yeah, sure. Thanks. So, there's kind of a series of 15 00:00:39,850 --> 00:00:42,850 logical steps, how this comes together. But it all ties to one 16 00:00:42,850 --> 00:00:46,660 conclusion, which is, as our customers start to begin their 17 00:00:46,660 --> 00:00:50,230 journey to really embracing the cloud operating model, which 18 00:00:50,230 --> 00:00:53,770 means having the ability to define a workload, plus all the 19 00:00:53,770 --> 00:00:56,800 infrastructure and all the security around it to find all 20 00:00:56,800 --> 00:01:00,070 that stuff in software, and then deploy it with a single click. 21 00:01:00,460 --> 00:01:02,680 So, no more tickets, no more waiting a month to deploy a 22 00:01:02,680 --> 00:01:06,070 workload. That's the hallmark of a cloud archive. That's what I 23 00:01:06,070 --> 00:01:09,610 use as my kind of litmus test to argue there. As we go into that 24 00:01:09,610 --> 00:01:12,610 journey, I think there's a really interesting and somewhat 25 00:01:12,610 --> 00:01:16,240 of an imperative for our customers to not just take the 26 00:01:16,240 --> 00:01:20,590 security controls that we know and use today, and try to cut 27 00:01:20,590 --> 00:01:23,860 and paste and transpose them into this cloud world, but 28 00:01:23,860 --> 00:01:26,800 rather to think differently about how we do security. And to 29 00:01:26,800 --> 00:01:31,510 help us stop these increasingly sophisticated attacks where the 30 00:01:31,510 --> 00:01:36,130 goal of an attacker is to avoid detection. So the attackers we 31 00:01:36,130 --> 00:01:39,940 see are penetrating a network, and they'll remain resident in 32 00:01:39,940 --> 00:01:45,070 the network for six, nine, even 12 months, very slowly and 33 00:01:45,070 --> 00:01:48,100 carefully moving laterally, oftentimes through legitimate 34 00:01:48,220 --> 00:01:53,110 application pathways. So stopping that type of attack 35 00:01:53,770 --> 00:01:56,410 requires very high fidelity data. And I think one of the 36 00:01:56,410 --> 00:01:59,020 things that's unique about VMware is that we have, with 37 00:01:59,020 --> 00:02:02,860 Carbon Black, deep insight into what's happening in the 38 00:02:02,890 --> 00:02:07,450 endpoint. With NSX, we have, you know, unusual and deep insight 39 00:02:07,450 --> 00:02:10,390 into what's happening on the network. We see network 40 00:02:10,390 --> 00:02:13,210 connections that a traditional network switch wouldn't see 41 00:02:13,780 --> 00:02:18,490 because those connections never leave virtualization world, 42 00:02:18,490 --> 00:02:21,070 which means they don't actually leave the box of a server. So 43 00:02:21,070 --> 00:02:22,630 when you put these two things together, it's a bit of a 44 00:02:22,630 --> 00:02:25,630 chocolate-meets-peanut-butter situation where we can see this 45 00:02:25,630 --> 00:02:30,310 lateral movement in a way that really no other solution can. 46 00:02:30,310 --> 00:02:32,050 And I think that's the name of the game of security. 47 00:02:33,630 --> 00:02:35,910 Michael Novinson: What is combining that NDR and the EDR 48 00:02:35,910 --> 00:02:37,620 help with seeing lateral movement? 49 00:02:38,080 --> 00:02:40,510 Tom Gillis: Yeah, let's look at an example. So, you know, with 50 00:02:40,510 --> 00:02:44,500 Carbon Black, we have an awareness of the components that 51 00:02:44,500 --> 00:02:48,280 make up an application. Let's talk about servers. So, we're 52 00:02:48,280 --> 00:02:52,690 looking at an Apache server, and we know what processes Apache 53 00:02:52,690 --> 00:02:56,170 should be running. Now, let's imagine that in your fleet of 54 00:02:56,260 --> 00:03:00,310 100 Apache servers, we see one Apache server that spawns a new 55 00:03:00,310 --> 00:03:03,610 process, maybe it's coming off a PowerShell script. That doesn't 56 00:03:03,610 --> 00:03:06,400 mean it's bad. Okay, that happens in the real world, that 57 00:03:06,400 --> 00:03:09,670 could be a sysadmin doing an update, or just somebody trying 58 00:03:09,670 --> 00:03:13,810 something new. It just means it's suspicious. So, Carbon 59 00:03:13,810 --> 00:03:17,680 Black has a notion of reputation for each process, like does this 60 00:03:17,680 --> 00:03:20,140 thing look real and recognized and trusted or resistance is 61 00:03:20,140 --> 00:03:24,040 behaving strangely? And we at Carbon Black, we'll share that 62 00:03:24,040 --> 00:03:29,140 information with NSX. So NSX not only sees every packet in every 63 00:03:29,140 --> 00:03:32,410 connection, it sees every process that initiated the 64 00:03:32,410 --> 00:03:34,300 connection. That's very unique. So, we're not just looking at 65 00:03:34,300 --> 00:03:36,820 like, "Oh! that's an Apache server." What's coming from the 66 00:03:36,820 --> 00:03:41,230 Apache server, we can see which process in the Apache server 67 00:03:41,260 --> 00:03:44,980 initiated. So what you find is if you have this level of 68 00:03:44,980 --> 00:03:49,210 visibility, where you can really see and understand the context 69 00:03:49,810 --> 00:03:55,030 of what's happening in your data center, the lateral movement of 70 00:03:55,030 --> 00:03:58,240 an attacker sticks out like a sore thumb. So, really, the 71 00:03:58,240 --> 00:04:00,940 magic here is not necessarily that we have invented some new 72 00:04:00,940 --> 00:04:03,610 security algorithm that some other mathematicians didn't 73 00:04:03,610 --> 00:04:07,660 think of. The magic is that we have access to data that our 74 00:04:07,690 --> 00:04:10,990 competitors don't. And that's what's going to drive efficacy. 75 00:04:10,990 --> 00:04:13,030 And that's what's got us so excited about this combination. 76 00:04:14,890 --> 00:04:18,280 Michael Novinson: I see. So, what's the plan to roll this out 77 00:04:18,280 --> 00:04:23,380 to customers? And for existing Carbon Black customers, what are 78 00:04:23,380 --> 00:04:26,440 the most significant changes you'll notice once NSX is fully 79 00:04:26,440 --> 00:04:27,010 embedded? 80 00:04:27,270 --> 00:04:29,520 Tom Gillis: Yeah, so the cool thing here is the way we're 81 00:04:29,520 --> 00:04:31,680 structuring is, you know, at VMware, we believe in the 82 00:04:31,680 --> 00:04:36,060 philosophy of better together. So when NSX and Carbon Black are 83 00:04:36,060 --> 00:04:38,580 both deployed in account - this stuff is super easy to deploy 84 00:04:38,580 --> 00:04:41,550 and use, but one is not contingent on the other. So, we 85 00:04:41,550 --> 00:04:46,140 were able to deploy this with Carbon Black, without NSX. So 86 00:04:46,140 --> 00:04:48,660 the way it's going to manifest itself in the first incarnation 87 00:04:48,660 --> 00:04:52,080 is that the Carbon Black customer has a console that is 88 00:04:52,080 --> 00:04:55,740 frequently used by threat hunters, incident responders and 89 00:04:55,740 --> 00:05:00,990 the security operations team to identify anomalies. And now with 90 00:05:00,990 --> 00:05:04,530 a simple software upgrade, that console is going to have an 91 00:05:04,530 --> 00:05:07,260 awareness of both the endpoint and the network. And so we have 92 00:05:07,260 --> 00:05:09,900 this notion of an attack sequence. And we can show you 93 00:05:10,620 --> 00:05:13,950 this weird narrative I just described, that weird Apache 94 00:05:13,950 --> 00:05:17,400 server, the process in the Apache server made this 95 00:05:17,400 --> 00:05:22,050 connection to a Windows Server, and the connection that that 96 00:05:22,050 --> 00:05:24,750 process terminated into in the Windows Server is just that one 97 00:05:24,750 --> 00:05:28,920 connection process suddenly goes from user space to root, that 98 00:05:28,920 --> 00:05:32,100 should never happen. And then that root process may have a DNS 99 00:05:32,100 --> 00:05:36,210 query with malformed headers and a giant payload. If you lay that 100 00:05:36,210 --> 00:05:41,280 stuff out, attack sequence, you know, that is clearly an attack 101 00:05:41,280 --> 00:05:44,370 happening, you can intercept it in real time before it occurs. 102 00:05:45,240 --> 00:05:50,580 So it gives you this level of visibility that can provide a 103 00:05:50,580 --> 00:05:54,210 response. But it also has very high levels of forensics. So you 104 00:05:54,210 --> 00:05:57,810 can look back and say, "If a ransomware attack did happen, we 105 00:05:57,810 --> 00:06:01,440 did initiate all from a single console." And,, you know, prior 106 00:06:01,440 --> 00:06:05,220 to this, administrators would have to go and look at multiple 107 00:06:05,220 --> 00:06:07,950 different consoles and try to piece it together, right? And 108 00:06:07,950 --> 00:06:10,560 oftentimes, you don't have sufficient resolution. For 109 00:06:10,560 --> 00:06:14,580 example, NetFlow will tell you - this Apache server, talk to this 110 00:06:15,150 --> 00:06:17,190 Window Server, it's not going to tell you which process initiated 111 00:06:17,190 --> 00:06:19,890 the connection. But we see all that, right? So that's what I 112 00:06:19,890 --> 00:06:23,700 mean by that high-level, high-fidelity data that lets us 113 00:06:23,700 --> 00:06:26,550 drive efficacy, because at the end of the day, that's all we 114 00:06:26,550 --> 00:06:28,440 care about is like is this system effective? 115 00:06:30,390 --> 00:06:31,830 Michael Novinson: Let's talk a little bit about Project 116 00:06:31,830 --> 00:06:35,340 Northstar. Two parter for you. What is it, first off? And then 117 00:06:35,340 --> 00:06:38,100 secondly, how does it help with securing multi-cloud 118 00:06:38,100 --> 00:06:38,880 environments? 119 00:06:39,080 --> 00:06:45,080 Tom Gillis: Yeah, sure. Thanks. So, you know, NSX is the fabric, 120 00:06:45,080 --> 00:06:48,680 the foundation of the multi-cloud infrastructures. NSX 121 00:06:48,680 --> 00:06:52,520 provides the automation and the connectivity to stitch together 122 00:06:52,520 --> 00:06:55,190 workloads that can run on your East Coast data center, your 123 00:06:55,190 --> 00:06:57,590 West Coast data center, but it can also run out on Amazon, 124 00:06:57,590 --> 00:07:00,890 Google, Microsoft. And it's one code base that makes that all 125 00:07:00,890 --> 00:07:06,230 possible. With NSX, there's a management plane that has 126 00:07:06,530 --> 00:07:10,040 security analytics, we call it NSX intelligence. It's akin to 127 00:07:10,700 --> 00:07:13,730 an advanced firewall console, and then a policy management 128 00:07:13,730 --> 00:07:17,150 console, we're delivering that as a true SAS multi-tenant 129 00:07:17,180 --> 00:07:22,190 service. So you think about your infrastructure in a multi-cloud 130 00:07:22,190 --> 00:07:24,860 world, most customers are going to have some combination of 131 00:07:24,860 --> 00:07:26,720 private and public, and more likely, you're going to have 132 00:07:26,720 --> 00:07:31,910 some combination of more than one public. I want to use Amazon 133 00:07:31,910 --> 00:07:35,480 for this particular workload. But then, the marketing team 134 00:07:35,480 --> 00:07:39,560 wants to use the analytics libraries at Google for that 135 00:07:39,560 --> 00:07:43,070 workload. Northstar is the hub that ties all that together. 136 00:07:43,820 --> 00:07:47,810 It's the one pane of glass that gives you a security profile for 137 00:07:47,810 --> 00:07:49,820 workload, wherever the workload's running, whether it's 138 00:07:49,820 --> 00:07:52,820 running, you know, private cloud, public cloud, east, west, 139 00:07:52,850 --> 00:07:55,640 it doesn't matter. Northstar ties all that together. So 140 00:07:55,640 --> 00:07:59,060 that's currently in tech preview, we can demo it. And 141 00:07:59,060 --> 00:08:00,350 we'll be shipping that later this year. 142 00:08:02,010 --> 00:08:03,840 Michael Novinson: So once that starts shipping, what are one of 143 00:08:03,840 --> 00:08:05,700 the biggest benefits customers will notice? 144 00:08:08,040 --> 00:08:10,800 Tom Gillis: It's the same interface the customers are 145 00:08:10,800 --> 00:08:13,290 familiar with, actually, right? So, it's a different way of 146 00:08:13,290 --> 00:08:16,680 delivering, at this point, I think a relatively 147 00:08:16,710 --> 00:08:19,770 well-understood and well-accepted set of 148 00:08:19,770 --> 00:08:24,960 capabilities. One of the biggest benefits is not so much from 149 00:08:24,960 --> 00:08:27,930 Northstar, but it's what this management and security 150 00:08:27,930 --> 00:08:32,460 capability can deliver and that is unprecedented ability to 151 00:08:32,460 --> 00:08:38,760 understand and control and protect East-West traffic. So, 152 00:08:38,790 --> 00:08:40,980 if we think about coming back to that security narrative, we 153 00:08:40,980 --> 00:08:45,780 talked about Carbon Black, the goal of attackers is to get in 154 00:08:45,780 --> 00:08:50,280 and stay in, right? Even if we play back the Log4j fiasco, 155 00:08:50,340 --> 00:08:52,890 right? We all went through this together like Log4j - a huge 156 00:08:52,890 --> 00:08:55,740 burden. Everyone running around patching and service. Whoever 157 00:08:55,740 --> 00:08:59,310 had access to that vulnerability, especially before 158 00:08:59,310 --> 00:09:03,480 it was announced, whoever had access had unprecedented access 159 00:09:03,510 --> 00:09:05,910 to virtually every network on the planet. I don't know of a 160 00:09:05,910 --> 00:09:09,180 customer that wasn't, in some way, impacted by the Log4j 161 00:09:09,180 --> 00:09:11,400 vulnerability. So, given the widespread nature of this 162 00:09:11,400 --> 00:09:16,200 vulnerability, what was the big breach? What was the big, like 163 00:09:16,200 --> 00:09:19,470 the movie script that was stolen? Or the plans for, you 164 00:09:19,470 --> 00:09:23,400 know, Coke, or the 250 million credit cards? There wasn't one, 165 00:09:23,760 --> 00:09:25,650 right? So, I think it's safe to assume - that was nine months 166 00:09:25,650 --> 00:09:28,380 ago. I think it's safe to assume that attackers used that 167 00:09:28,380 --> 00:09:30,540 vulnerability to get into network and they've been laying 168 00:09:30,540 --> 00:09:34,230 in wait for nine months. Nine months! So, think about that. In 169 00:09:34,260 --> 00:09:36,930 real-world terms, if someone broke into your data center and 170 00:09:36,930 --> 00:09:40,470 stayed for nine months, hanging up there, you know, sweat socks, 171 00:09:40,650 --> 00:09:43,440 brushing your teeth in the morning, it'd be insane. But in 172 00:09:43,440 --> 00:09:46,260 cyber, that's what we deal with - attackers getting insane. So, 173 00:09:46,260 --> 00:09:50,310 NSX is really the most powerful tool for identifying the lateral 174 00:09:50,310 --> 00:09:53,790 movement when those attackers are trying to survey and find 175 00:09:53,790 --> 00:09:56,790 the information they're looking for. NSX gives you the ability 176 00:09:56,790 --> 00:09:59,940 to understand a very high level of detail, that East-West 177 00:09:59,940 --> 00:10:04,350 traffic Northstar is the control panel that manages all that. So, 178 00:10:04,350 --> 00:10:07,140 it's allows you to run the analytics to see what's 179 00:10:07,140 --> 00:10:10,140 happening to build the policies and to respond to the network 180 00:10:10,140 --> 00:10:13,320 side of it. And then, as we talked about earlier, in the 181 00:10:13,320 --> 00:10:15,540 second half of this year, we'll be tying Carbon Black and that 182 00:10:15,540 --> 00:10:19,560 same infrastructure, and connecting, we call VMware's 183 00:10:19,590 --> 00:10:22,050 Contexa, which is our threat intelligence database so that we 184 00:10:22,050 --> 00:10:25,650 can correlate what we see in the endpoint and what we see on the 185 00:10:25,650 --> 00:10:29,970 wire. In my opinion, this is the highest impact thing that you 186 00:10:29,970 --> 00:10:32,850 can do to increase your security, right? Everybody has 187 00:10:32,850 --> 00:10:36,510 perimeter firewalls. Everyone has some form of endpoint, many 188 00:10:36,510 --> 00:10:40,440 people have EDR solutions already. It's that horizontal 189 00:10:40,470 --> 00:10:45,360 East-West lateral movement that is the problem. And VMware is 190 00:10:45,360 --> 00:10:47,010 uniquely suited to solve that problem. 191 00:10:47,940 --> 00:10:50,040 Michael Novinson: Are you seeing adversaries doing more around 192 00:10:50,040 --> 00:10:52,140 lateral movement today than maybe they were a year or two 193 00:10:52,140 --> 00:10:55,410 ago? And what are some of the new things we're seeing 194 00:10:55,440 --> 00:10:57,360 adversaries do when it comes to lateral movement? 195 00:10:57,390 --> 00:11:00,496 Tom Gillis: Yeah, what we see happening is there's like a, you 196 00:11:00,558 --> 00:11:03,852 know, more than doubling, even tripling of the use of 197 00:11:03,914 --> 00:11:07,704 legitimate protocols. And the number one protocol that we see 198 00:11:07,766 --> 00:11:11,370 being used is RDP (remote desktop protocol). So, attackers 199 00:11:11,432 --> 00:11:15,285 move very slowly, right? Their goal is to avoid detection. So, 200 00:11:15,347 --> 00:11:18,889 they're trying to hide in the noise of normal application 201 00:11:18,951 --> 00:11:22,803 behavior. So, RDP is a tool that all of your sysadmins use all 202 00:11:22,866 --> 00:11:26,594 the time, it's what you use to upgrade your Windows servers, 203 00:11:26,656 --> 00:11:30,260 right? So to make sure those Log4j vulnerabilities are all 204 00:11:30,322 --> 00:11:33,864 patched and clean. And so you can just block RDP. So, RDP 205 00:11:33,926 --> 00:11:37,343 connections are generally allowed. And so, with NSX, we 206 00:11:37,406 --> 00:11:41,382 have the ability to look at each connection. We look into it, we 207 00:11:41,444 --> 00:11:45,297 speak, you know, we speak Layer 7, right? So we speak RDP. And 208 00:11:45,359 --> 00:11:49,274 we can say, does that connection look like something a sysadmin 209 00:11:49,336 --> 00:11:53,313 would do? Or does that look like ransomware? And we do it in two 210 00:11:53,375 --> 00:11:57,289 ways. We have signatures so we run a distributed Suricata-based 211 00:11:57,351 --> 00:12:01,017 IDS/IPS. So we're like, "Look, if we know there's a malware 212 00:12:01,080 --> 00:12:05,056 chipping load or something that should never happen, let's catch 213 00:12:05,119 --> 00:12:08,474 that." But we also do distributed behavioral analytics 214 00:12:08,536 --> 00:12:12,202 and be like, "That just looks weird. You know, like, wait a 215 00:12:12,264 --> 00:12:15,992 minute!" So, this one server is doing, you know, a series of 216 00:12:16,055 --> 00:12:19,596 sequential reads on a big database. And then it downloads 217 00:12:19,658 --> 00:12:23,138 an encryption kit and it's encrypting that data. And now 218 00:12:23,200 --> 00:12:26,742 he's going to do a series of sequential writes that looks 219 00:12:26,804 --> 00:12:30,408 suspicious, and it's coming from an RDP connection, right? 220 00:12:30,470 --> 00:12:34,136 Shouldn't happen that way. So, I make it sound simple. It's 221 00:12:34,198 --> 00:12:37,989 almost like common sense. If you can see the data and that's, 222 00:12:38,051 --> 00:12:41,903 again, where VMware shines is that we can see that data and we 223 00:12:41,966 --> 00:12:45,570 can figure out legitimate RDP connections from ransomware. 224 00:12:47,220 --> 00:12:49,643 Michael Novinson: In terms of the Project Northstar, I know 225 00:12:49,702 --> 00:12:52,893 part of that is getting that hardware or that software 226 00:12:52,952 --> 00:12:56,557 capability at the application level, rather than in a central 227 00:12:56,616 --> 00:13:00,398 data center. What's the benefit to putting some of that security 228 00:13:00,457 --> 00:13:02,940 processing power at the application level? 229 00:13:03,330 --> 00:13:05,923 Tom Gillis: Yeah, so Northstar actually takes it, puts it in 230 00:13:05,977 --> 00:13:08,895 the cloud. And so, it's application-aware, as you were 231 00:13:08,950 --> 00:13:12,084 saying, so we have that Layer 7 context, we understand the 232 00:13:12,138 --> 00:13:15,542 protocol, we understand, "Hey, this is a web server, this is an 233 00:13:15,596 --> 00:13:18,568 app server, this is a database, this is how they should 234 00:13:18,622 --> 00:13:22,027 behaving." When you have all of that context, you can make very 235 00:13:22,081 --> 00:13:25,377 high fidelity decisions. NSX brings that context to the wire, 236 00:13:25,431 --> 00:13:28,403 to the network, Carbon Black brings that context to the 237 00:13:28,458 --> 00:13:31,700 endpoint. And then as we stitch those two together, we think 238 00:13:31,754 --> 00:13:35,050 we're going to have extremely high performance, high efficacy 239 00:13:35,104 --> 00:13:36,780 in the alerts that we generate. 240 00:13:37,920 --> 00:13:39,840 Michael Novinson: Let's talk a little bit about Project Watch 241 00:13:39,840 --> 00:13:44,190 here. What's the significance of that? And why is there a need 242 00:13:44,190 --> 00:13:46,080 for more app-to-app policy control? 243 00:13:46,170 --> 00:13:48,968 Tom Gillis: Yeah, it's a great question. So, let's think about 244 00:13:49,024 --> 00:13:52,605 a real-world example. I have, in my organization, you know, more 245 00:13:52,661 --> 00:13:55,851 than a thousand developers and we develop on every public 246 00:13:55,907 --> 00:13:59,489 cloud, as well as we have a huge private cloud infrastructure we 247 00:13:59,545 --> 00:14:02,958 use for build and test. And so, I've got, you know, more than 248 00:14:03,014 --> 00:14:06,540 150 VPCs in my organization, and my peers each have a couple of 249 00:14:06,596 --> 00:14:09,898 hundred VPCs. Security says, "you know what, I got to put a 250 00:14:09,954 --> 00:14:13,311 Layer 7 firewall between those VPCs and the apps that you're 251 00:14:13,367 --> 00:14:16,613 running on-premises, like your build farm and whatnot, for 252 00:14:16,669 --> 00:14:20,027 security reasons." That's kind of a fundamental requirement. 253 00:14:20,083 --> 00:14:23,385 All of a sudden, you've got this n * n matrix, where you're 254 00:14:23,440 --> 00:14:26,854 trying to connect hundreds of VPCs on one side to hundreds of 255 00:14:26,910 --> 00:14:30,436 apps and developers on the other side and that can balloon into 256 00:14:30,492 --> 00:14:33,849 tens of thousands of firewall rules. And things move, right? 257 00:14:33,905 --> 00:14:37,319 Like we're developers, so we're kind of constantly trying new 258 00:14:37,375 --> 00:14:40,397 ideas, changing things all around, and so it creates a 259 00:14:40,453 --> 00:14:43,643 level of burden on the part of traditional firewall, it's 260 00:14:43,699 --> 00:14:47,224 extremely cumbersome. And many customers I talked to were like, 261 00:14:47,280 --> 00:14:50,750 "I can't. This is not going to scale. It's not going to work." 262 00:14:50,806 --> 00:14:53,884 We were trying to use our next-gen firewalls, firewalls 263 00:14:53,940 --> 00:14:57,298 that we know and love and are good as perimeter. That's what 264 00:14:57,354 --> 00:15:00,823 they're built for. But they're not good at this deal with, you 265 00:15:00,879 --> 00:15:03,230 know, cloud to cloud, effectively internal 266 00:15:03,286 --> 00:15:06,196 communication, because they don't have the notion of 267 00:15:06,252 --> 00:15:09,833 identity, they don't know an app server from a web server from a 268 00:15:09,889 --> 00:15:12,967 database. So, with Project Watch, we throw away the old 269 00:15:13,023 --> 00:15:16,549 firewall constructs and we build a Layer 7, app-aware construct 270 00:15:16,605 --> 00:15:19,963 that says, "Look, if I've got a marketing analytics," and we 271 00:15:20,018 --> 00:15:22,929 talked about marketing, analytics and marketing team 272 00:15:22,984 --> 00:15:26,286 came up with this clever idea using Google, TensorFlow. And 273 00:15:26,342 --> 00:15:29,644 one of our earlier examples, well, let's say that analytics 274 00:15:29,700 --> 00:15:32,778 application needs to talk to a customer database that's 275 00:15:32,834 --> 00:15:36,024 residing on-prem., we use certificates to say this is the 276 00:15:36,080 --> 00:15:39,381 customer database. This is the analytics engine and Project 277 00:15:39,437 --> 00:15:42,459 Watch provides a secure, encrypted connection from one 278 00:15:42,515 --> 00:15:45,705 part of the app to the other part of the app, or from two 279 00:15:45,761 --> 00:15:49,119 separate apps that are just exchanging information and data, 280 00:15:49,175 --> 00:15:52,477 you know, independent of any network pathway. Don't care if 281 00:15:52,533 --> 00:15:55,667 you're running on direct connect, if you're running on a 282 00:15:55,722 --> 00:15:59,304 VPN, if you run on the plain old dirty Internet, doesn't matter. 283 00:15:59,360 --> 00:16:02,214 It's about app to app connectivity. And it can take 284 00:16:02,270 --> 00:16:05,740 tens of thousands of firewall rules and turn it into literally 285 00:16:05,796 --> 00:16:09,265 - I'm not exaggerating - two. This can talk to that. It's only 286 00:16:09,321 --> 00:16:12,791 trying to do right, and you can do it with encryption, you can 287 00:16:12,847 --> 00:16:16,205 do it very high performance. So that's what Project Watch is 288 00:16:16,261 --> 00:16:19,730 about. It's about simplifying the interchange of a multi-cloud 289 00:16:19,786 --> 00:16:22,920 infrastructure. And the other kind of clever thing about 290 00:16:22,976 --> 00:16:26,446 Project Watch is it has a notion of risk. So, like, we look at 291 00:16:26,502 --> 00:16:29,804 those apps, and we're like, what is this thing? Is this the 292 00:16:29,860 --> 00:16:33,497 company lunch menu, you know, or is this sensitive customer data, 293 00:16:33,553 --> 00:16:36,183 or PII? And so, we can automatically build risk 294 00:16:36,239 --> 00:16:38,981 profiles based on our observation of the app. And 295 00:16:39,037 --> 00:16:42,283 based on topology, and based on, you know, there's a whole 296 00:16:42,339 --> 00:16:45,865 variety of sources that we use to help formulate and streamline 297 00:16:45,921 --> 00:16:48,999 the connectivity policy, and just the observability of, 298 00:16:49,055 --> 00:16:52,301 "Where's all that data going?" Because sometimes, you'd be 299 00:16:52,356 --> 00:16:55,826 absolutely shocked, right? I'm running an application and it's 300 00:16:55,882 --> 00:16:59,240 using APIs from SAS services. Project Watch can discover all 301 00:16:59,296 --> 00:17:02,542 that and be like, "Oh! Do you realize you're talking to 20 302 00:17:02,598 --> 00:17:05,899 external SaaS services and pushing customer data up there?" 303 00:17:05,955 --> 00:17:09,201 So, having the ability to identify and then to protect app 304 00:17:09,257 --> 00:17:12,503 to app connectivity and have a notion of risk and building 305 00:17:12,559 --> 00:17:15,693 security policies that are dynamic, associated with that 306 00:17:15,749 --> 00:17:18,659 risk. We think that's the future. Nothing to do with 307 00:17:18,715 --> 00:17:22,184 infrastructure, right? Nothing to do with IP address protocol, 308 00:17:22,240 --> 00:17:25,598 we don't care. It's all Layer 7 constructs of that are built 309 00:17:25,654 --> 00:17:26,550 around identity. 310 00:17:27,710 --> 00:17:29,810 Michael Novinson: Let me ask you here, finally, what's the 311 00:17:29,810 --> 00:17:32,660 fastest growing area of the VMware security portfolio today? 312 00:17:32,660 --> 00:17:33,170 And why? 313 00:17:34,170 --> 00:17:36,519 Tom Gillis: Probably the number one area is our East-West 314 00:17:36,572 --> 00:17:39,809 security controls. Its explosive growth. And the reason why is 315 00:17:39,861 --> 00:17:42,994 what we talked about already is that everyone knows that the 316 00:17:43,047 --> 00:17:46,284 goal of attackers is to get in and stay in. In fact, the whole 317 00:17:46,336 --> 00:17:49,365 principle of zero trust says, "Guess what? It's already in 318 00:17:49,417 --> 00:17:52,759 there, already there." And it's a pretty good assumption, right? 319 00:17:52,811 --> 00:17:55,997 So assume that they're in. How do we make it hard for them to 320 00:17:56,049 --> 00:17:59,339 stay in? How do we make it hard for them to get to what they're 321 00:17:59,391 --> 00:18:02,733 trying to get to, which is your valuable assets, your data, your 322 00:18:02,785 --> 00:18:06,075 IP. And that East-West Advanced Threat Protection, it's so easy 323 00:18:06,127 --> 00:18:09,312 to deploy on top of NSX. You just literally, if you can find, 324 00:18:09,365 --> 00:18:12,759 you know, and watch the Sopranos on HBO, you can turn on advanced 325 00:18:12,811 --> 00:18:16,101 threat protection on NSX. It's that simple. And so, it has very 326 00:18:16,153 --> 00:18:19,182 high impact, solves really unique problem, stop ransomware 327 00:18:19,234 --> 00:18:22,524 better than anything else on the market. And it's super easy to 328 00:18:22,576 --> 00:18:25,552 deploy. And, you know, over the next 12 months, it's only 329 00:18:25,604 --> 00:18:28,320 getting better, faster and stronger as you bring the 330 00:18:28,372 --> 00:18:31,610 additional context of Carbon Black into that analytics engine. 331 00:18:32,820 --> 00:18:34,410 Michael Novinson: Tom, it's been a pleasure. Thank you. 332 00:18:34,470 --> 00:18:36,180 Tom Gillis: Yeah. Thanks very much, Michael. 333 00:18:36,689 --> 00:18:38,973 Michael Novinson: We've been speaking with Tom Gillis. He is 334 00:18:39,028 --> 00:18:42,128 the senior vice president and general manager of VMware's 335 00:18:42,182 --> 00:18:45,664 Networking and Advanced Security Business Group. For Information 336 00:18:45,718 --> 00:18:49,200 Security Media Group, this is Michael Novinson. Have a nice day.