We're going to start our next talk in just one minute. It's going to be by Russell, and it's going to be on effective log and event management. Thank you. All right, thanks, guys. This is great. The turnout here is amazing. Hope everybody sticks around the Blue Team Village. Check out the CTF and everything else that's going on. So I'm here today to talk about effective log and events management. I work for a small federal government contractor in the DC area. And we run systems that have to maintain FISMA ATO. And my department is actually responsible for IT ops and for security, because it's a small company, like I said. So for us, monitoring and log and events management, it's essential for IT ops to ensure availability, performance, and utilization, as well as for information security, and for compliance to detect malicious activity and show that we actively monitor our environment and review our logs to satisfy the audit and compliance requirements. So in the presentation today, I'm going to share with you the process that my team and I have developed to effectively manage logs and security events in our environment. Because we're not a large business, we had to develop a process rather than purchasing a big naming sim. And we prefer to manage everything almost entirely internally, rather than hiring vendors and outsourcing to retain knowledge. So there are going to be lots of examples in the presentation of tickets, actual tickets, output from our environment. So I was going to invite everyone to move forward to see, but we're pretty packed. But I'm actually happy here with the setup, with the slides and the wall, you'll be able to see pretty well what I'm talking about. So I'm going to do a quick kind of like overview of what we do and why, and then I'll get into lots of examples to show you. It's a lot of slides. I'm going to go pretty fast, because it's a short talk. And I'm probably not going to have any time for questions. If you want to chat, I'm going to hang around for a while. I'll just move to the back of the room. Please feel free, come up. We can talk about what I do, what you do, pros and cons. It's all good, all right? So briefly, why is monitoring important? Well, monitoring improves your IT operations and your knowledge and visibility into your environment. It improves your situational awareness and knowing what your baseline statistics are, i.e. what is normal. The more you monitor and review your IT ops, the better your situational awareness and knowledge of what's normal will be. Second, monitoring is important to information security in order to identify and detect malicious activity and breaches. And proper logging is critical to incident response. Third, monitoring, particularly documented daily review, is required for many compliance requirements. According to the latest Verizon DBIR, which the graphics came out like last week, you can find a link to it on Twitter, internal log review is the least used method for discovering breaches in 2017. I find that astounding. I don't know if you do, but I find that astounding. According to their data, the number one method for discovering breaches in 2017 was reported by an external customer, followed by employee, then fraud detection, then third parties, such as external monitoring services. So why aren't organizations identifying breaches from internal log review? I suspect it's because few are dedicating the resources it takes to adequately perform. But without it, you're exposing your business reputation and allowing breaches to go undetected. Recent fire hour reports said that it takes 146 days for breaches to be detected. Other reports have said anywhere from 99 to 500 or more days. Monitoring is critical for incident detection. You don't want to wait for a customer or Brian Krebs to notify you that you've had a breach. So daily manual review of log exceptions is a key to security operations and incident detection. So if this is new to you, you're asking, well, how do I go about daily log review? Well, first you have to decide what to log and monitor. So this is a diagram from a blog post by Jessica Payne called monitoring what matters. And this is what Microsoft's incident response team often finds when they're called in to do IR. Many organizations either log way too much without the proper context or not enough, nothing other than the system default logging capability. You need to decide what logs to gather and review based on your business needs and the resources you have to analyze them. And then you have to set up tools to manage and process your logs so you're not drinking from fire hose. So these are some of the log sources you should focus on. Your server logs, windows, event logs, and syslog, security tool and network device logs, maybe even web proxy logs, DNS request logs. There's lots of information in there. And logs from your applications, especially if you're hosting systems, tracking logins and user activity, looking for other anomalies, and logs from endpoint devices using tools like Windows Sysmon or mobile device management products. So in determining your monitoring strategy, you need to determine what's critical to the business. And that can vary depending on the type of business you are. A retail business is going to have really different needs and resources to spend on monitoring than a government contractor or an information security company. This may be determined for you, depending on compliance requirements. If you have to meet PCI, HIPAA, FSMA, GDPR, et cetera, the hard work is in tuning the monitoring system to your environment. This is where a log management system or a log correlator or SIM comes in. They allow you to centralize your log data, correlate, index, and ultimately do stuff with your logs, like writing searches to track activity from a specific user IP address, and turn the log data into actionable information. So at my company, we use Splunk. There are plenty of products in this market, including the Blue Team Village Sponsor Greylog. Splunk is free for indexing up to a gig a day. I believe Greylog is free for up to five gigs a day. So you don't have to buy a license to use these tools. It obviously depends on how large your environment is. But after that, they usually tend to charge you based on how much log data you ingest per day. So at its core, these tools are log aggregators and indexers. They give you the ability to search and correlate log data or just look for stuff. There are also lots of dashboards you can download or purchase to help you analyze the data from different vendors. And then you can write searches to produce the results that you need to review. You can save those searches, and then you can run them on a schedule, like a Cron or a scheduled task. So when you run those searches, you then send the results in an email to some type of ticket management system. You're going to write searches to look for things like daily VPN logins, admin logins, root logins, et cetera. Once you have a log management system and you've tuned the searches, you need to set up a process to review them. And this is where you need to use a ticketing system. So we use RT. Has anyone heard of RT? OK, great. A few people have. So RT, it's a web-based ticketing system or issue tracking system, as they call it. It's actually written in Perl, believe it or not, and it was first released in 96, but it's still actively maintained. It's a great, lightweight, free ticketing management system. These tickets have standard information, like you would see in most issue tracking systems, like when it was created, the owner or the priority, et cetera. And the search results screen, you can search based on most of the ticket fields. So our login events management process is pretty simple. You configure logging and send all of your logs to your indexer. Then you develop and automate the running of searches that produce output of data that you care about, like administrator logins. Then you email those results into a ticketing system, automated on some kind of schedule, and then you review them on a daily basis. Here's a workflow diagram. So I can't see it on my screen, so I'm going to look over here. Like I talked about, on the far left, you've got all your logs, servers, routers, switches, infrastructure, databases. You're feeding them into some type of correlator. We're just using Splunk. That's why that's there. So with the data that's there, we develop searches. We have some one to five minute or real time searches that look for high severity issues. When those come up, they actually send alerts to our team and will go look and figure out what's going on and resolve the issue. And then we have all of the daily tickets that we review on a daily basis. And so those are like IT ops things, like backup success and failure, security things, system access and authentication, even customer support tickets. Like can you throw everything in there? So we review these tickets, like I said, on a daily basis. If the ticket, your original search produces way too much data, like 18 screens of stuff, which isn't reasonable to review every day, or there's not enough, we'll go back and modify the search and output criteria to continually improve the results in the process. And then what's great, if you have to meet compliance requirements, like we do SSAE 16 or SOC audits, or if you have to meet FISMA compliance or anything else, when our auditors come out, they know about this process. So they ask me, Russell, what's changed in the last year? What are you doing that's new? And then they say, OK, give me all your tickets for these five weeks. And I simply create PDFs of everything and throw them at them. And they go through and review them and just ask me questions. So that's way easier than having to go through and explain all kinds of things, showing them how you review logs, having all the history documented that you close them every day, at least for us, satisfies our auditors. So we use this process to generate about 50 daily tickets. Here's a list of the subjects for some of those tickets. Next, I'm going to start reviewing some examples in detail until I run out of time. So this is our VPN users ticket. And the output here, it comes from our VPN endpoint. So in the left-hand column, you see that's VPN endpoint. And then you've got your username, the action, timestamp of course. And then on the far right, we've got the FQDN, rather than the IP address. And the reason that we did that is because we're a pretty small company in the DC area. And we know where most of our people live. So we review this every day. And if we see that Todd logged in from Mexico, and we didn't know he was in Mexico, then we're going to go ask and find out, is he on vacation? Or do we need to do IR with this? What's going on? Even more local than that. You can see in some of the FQDN's Baltimore, Maryland Fios. I think there's one that says DC. So people have actually become accustomed to this. They know we're looking now. And so when people are going on vacation, they come to us and they're like, hey guys, I'm going on vacation next week. So if you see an unusual login, don't go to my boss and ask them what I'm doing. They don't like you have to go to their boss and ask, what is Bob doing? All right, this is our RDP logins daily ticket. If you don't know what RDP is, that's remote desktop protocol for Windows. It's the way you remotely log in to a Windows machine. So here we get the timestamp again. And this one we have a source IP address. But I might have blocked this all out. The username, the server name, whether or not they successfully logged in. Again, this allows us to look for what's normal versus anomalous activity. Because we're a pretty small environment, we actually look at all the successes every day, not just the fails. Bigger companies can't do that. It's just way too much information. But as a smaller company, we look at the successes as well, and we tend to know when people are logging in. So if we see something in an unusual time, we might go ask them, why'd you log in to 3M last night? We never see you log in after like 7 o'clock. Again, you want to know what's normal in your environment to help you find anomalous activity. This is a system daily ticket that shows automated logins. This is a Linux box. You can see SSHD logins. But it's the same type of ticket. And we review these every day. This is our daily outbound attachments ticket. So these are email attachments from our organization going outbound. It's sort of a high level DLP, because we can scan the names of all the files leaving the building, and look for anomalies or things that look bad. For example, if it says something goes out that says salary in it from HR, maybe going to the HR person's personal email address, we would go inquire as to what's going on there. Or an executive emailing something called like transfer authorization that wouldn't be normal. You'd want to figure out what's going on. You can just watch out for unusual or potentially bad activity simply by reviewing this. Obviously, this isn't a DLP solution. They do way more than this. But it's a good place to start if you're on a budget. It's also maybe a good manual process if you do have automated DLP, but you're not really looking at what people are emailing out. Again, this is going to depend on the size of your environment if you can do this. This is a daily OWA connections ticket. So this is actually write your iPhone or your Android device. If you're running Exchange in your environment yourself, you can produce this output. And this is showing IP addresses people are connecting from and their device ID. So what would be interesting here? Maybe a large number of device IDs when we know the person has a phone and an iPhone and not more than that, or maybe the same IP or range of IPs trying to log in as lots of different users, especially ones that don't exist in our environment. This is an example of a proxy violations alert. So this isn't a daily. This is one of those real-time tickets. And this actually runs, I think, every 15 minutes. But we get this when a user attempts to browse somewhere to a site that's blocked by our proxy config. Something else we look at on a daily basis, this is our daily building access ticket. Because we're pretty small, again, it's not a huge amount of data. So we have a ticket I review every day that shows every swipe with every key card in our building. I look at it for unusual activity, like failed swipes into restricted areas, or people trying to access things after hours. We get the timestamp for the swipe, the key holder name, the building location, and the result, access granted or access denied. It's a quick way to look for unusual activity. And I've talked to other folks and they say, there's no way I can't look at that. It's too much. And maybe they'll look at fails, or they get automated alerts when someone tries to go into the data center and doesn't have access. But if your environment isn't that large, you might want to look at who does go in for successes. We've spotted things that are unusual. We've had to figure out what's going on. So in order to monitor file integrity on servers, we use Tripwire, as well as some other tools, and generate daily tickets to review the output from those. Like this is an example of a daily Tripwire ticket. We actually separate them. So we get a ticket every day for Linux servers, a ticket every day for Windows, and a ticket for Solaris. If anyone knows what Solaris is. It shows changes since the last baseline. So these are file changes and things like changes to Redge Keys. This is our daily DFS ticket. DFS, for the uninitiated, is the Windows Distributed File System. It's basically Windows File Shares, but it's distributed across multiple servers. And so here, we're looking at certain shares. We don't look at all of the changes to DFS, because even in a small company, that's huge. It's really noisy. But we look at the HR documents, or our proposals folder, things like that, and look for unusual activity. This is, again, maybe more for inside or threat type review, but it shows us if people are snooping around and trying to get access to things that they shouldn't. We monitor logs from our network security devices and tools, such as our firewalls, routers, intrusion prevention and detection, and web application firewalls, and from our vulnerability scanners. So this is an IPS daily ticket. It shows the number of IPS alerts per signature or control type. We use this to look for different patterns in the type of alerts our IPS is detecting. This is a real-time alert from an IDS. It matched the signature for an exploit kit. I think it was Angular. And so you see we get timestamped, the destination IP, the URI. And when we get these real-time alerts, we take a quick look at them and use them to determine if we need to dive into IR or do any more investigating. Obviously, you get a lot of false positives. So endpoints are arguably the most important assets to monitor, because that's where your users can do stuff. We use a standard commercial antivirus product for one layer of detection, and it automatically sends us texts and generates a ticket when an AV signature is hit. We also conduct a daily review of pattern file updates and the status of agents. But most valuable in our environment, we've deployed Sysmon across all of our workstations and Windows servers. And Sysmon has configured to alert us to potential malicious behavior on endpoints based on search queries that we've configured. This is an antivirus alert from one of our endpoints, notifying us of possible malware infection. For Sysmon, we use the Swift on Security config as a baseline, and we modified it for environment, mostly excluding the items that don't apply to us. Before Sysmon, our endpoint visibility was pretty limited, with no ability to monitor behavior and activity on endpoints. We deployed Sysmon and Splunk forwarders to the endpoints. It sends all the data from Sysmon into Splunk, and we run searches to generate alerts on malicious activity, and also for daily review. We're working on integrating the MITRE attack framework into this as well. So we have Sysmon alerts generated for all of these types of activities, unauthorized image activity. You can read them all there. I'm going to go through a few slides. This is an unauthorized image activity alert. So this was triggered by, I think this is an image launching command.exe. This is a Sysmon suspicious child process alert. This is looking for malicious processes coming out of office docs. This is an example of a Sysmon potential network outbreak. So this is triggered when one endpoint connects to more than four destination IPs in a five minute period. So we tuned this for our environment. This is more than the normal number of outbound connections, so that's the number we landed on for deciding we want to see those so we can go look and see if this is an indicator of compromise. This is an example of a Sysmon suspicious RedServer32 process. If you didn't know, RedServer32 can load remote malicious script files. This is right out of the MITRE attack matrix. We also monitor output data, including print jobs, rights to optical media, and USB storage device activity. This is a data windows print jobs ticket. This shows us all the windows print jobs, including the username, the source, PC, the note, pages, the print error, and the time of the job, and the document name. So most of our TNP, this is kind of like looking for anomalies, looking for insider threat, looking for people trying to print things and steal them, things that they shouldn't be. This is a Sysmon USB usage alert. So from Sysmon, we generate these whenever there's a USB storage device activity. In this case, it's a Kingston data traveler thumb drive. So we block USB mass storage devices, but before we set up these alerts with Sysmon, we're going to get lab data when use was attempted. So with Sysmon, we now can get that, and we can go in and review. Lastly, this is an example of a Sysmon attempted removal of media rights to DVD, notifying us of an ISO planning program being launched. Again, we block removal of media, but we still want to know about the attempts. So what we're also considering, we're a little bit splunk for AWS app, which ties directly into AM and pulls down AWS logs. So with these, we're looking for the same types of things just in the AWS cloud instead of on-prem. That's why every action with AWS is based on API call, like user additions, permission changes, et cetera. We provide rules to almost like an IDS, looking for abnormal behavior. And we're pulled from CloudWatch, CloudTrail, AWS Config, and VPT Flow Logs. So first of all, this is the AWS app in its block. It provides a dashboard giving you a nice high-level overview of user activity. This is a custom search rerun that reports on AWS console authentications, both failures and successes. To wrap up, again, this is all the slides showing our login events management process. So I'll leave this here for a couple of minutes. You know, implementing this process, as I've described, this will enable you to understand what normal IT ops look like, maximize your detection capabilities, and it'll help you perform instant response. Also very important, again, being compliance requirements for your auditors. You can implement this with the tools that I mentioned, CISL, Explunk, RT, or any other combination of log management and ticketing system. So that's it, and we'll leave that there for everyone if you want to take a look at it. And I'll be hanging around the back. Thank you.


Shipmates, we're Admiral Pete Garvin here with Force Mass Chief Matt Harris. This month, Naval Education and Training Command celebrates 50 years of rich history. Over the next several weeks, we will highlight five decades of Nazi transforming sailors into warfighters. Join us as we travel through time, reflecting on our many accomplishments.


What's up YouTube real is the gaming here and it is Friday, baby And we're back with some more Thomas because everybody loves Thomas around here and today We are here on the springman productions 2022 channel and we're gonna be reacting to his video the one and lonely It's been very Along-weighted and it's finally been released and I missed it. So here we are today and let's react to it. Oh Sotter father and I believe he's no longer gonna continue on the series, which is pretty sad One three four p.m. An hour before the blast. I like his style of animating pretty cool Yeah, we should get going we've got a good strain in 30 minutes Shout out to timid deep Thunderbolt the creator of this You'll need the energy for later. Yeah, I will Oh Someone's pulling up is it the top hem? This is bad controller Bob hey, who are you? Don't you know that your trespassing? Trust passing is the least of my concerns.   Why would he do such a thing? Yo Took his whistle Thomas you got this bro fight it. Don't let it overtake you And Thomas is pretty strong. He's don't he's like aware of what's going on even though he's been mutated It seems like he's in a deep state or something Where am I? You're in your mind This is a true nightmare Wow, that's pretty cool, and he actually says bad words now what that'll recall this but it's okay Ashes All the other trains are mutated as well any Would not trust her no, you're not her aren't you none of this is real This is mad 19th 145 p.m. Four days after the blast Yo Springman stars as Thomas slash Bob dude. That was crazy. That was like you took it like next level That was pretty nuts man. Shout out to springman productions for the awesome work and our final clip by big Phil animations Edward blows his whistle reanimated Oh Every whistle 1777 what this is a I'm trying to read bro. I'm trying to read this the date Okay, 1777 to 2019. Oh my god It seems like that might have been a shed 17 reference if I'm not mistaken poor Edward and his whistle man That was pretty bloody, but thank you all for watching and enjoy the rest of your Friday night, and I'll see you on the next one Peace


from Las Vegas, it's theCUBE. Cover EMC World 2016, brought to you by EMC. Now, here are your hosts, Stu Miniman and Brian Gracely. Welcome back to theCUBE here in Las Vegas at the Sands Convention Center for EMC World 2016. I'm Stu Miniman joined by Brian Gracely. Love when we can bring in some of the people that have been behind the scenes, making stuff work for many years and be able to tell their story on the program. Happy to have on for the first time, Bob Womback, who is Vice President of Marketing with VCE, which is now the EMC Converged Platform Division. Bob, welcome to the program. Thanks, Stu. Brian, thanks for having me. It's a pleasure to be here.  And it's because, well, you used to bring over Michael Capellis, Praveen, the former CEO. And now, we've kind of upped our game and we're bringing you on the program. For those that haven't met you, please introduce yourself to the audience. Give us a little bit about your background and your role inside EMC. Sure, so, Bob Womback, I've been with VCE since the beginning and had a variety of roles. I was a former EMC-er, and before EMC, about 20 years in high tech, primarily in system architecture on the design side. So, more recent in my career, moving over to the marketing side and wearing a lot of different hats, and it's been a great, great journey growing up with VCE. Yeah, so, right, Bob, I remember when I was back at EMC when the allocadia stuff started, talked to you about some of the architectures, because I knew the server side pretty well, and there's things that we've heard over and over over the years. So, it seems like not a week goes by. I'm sure you've heard VCE's dead, the relationship with Cisco, obviously is falling apart. The latest, of course, so bring us up to speed. Where are we with kind of VCE as a business and the Cisco relationship? So, first, I used to cut those out. We had a bulletin board, where we would actually post all of the rumors of our demise. Yeah, follow them like Bill Belichick, right? Right, and you know, I think what we always felt good about was nobody was ever criticizing what we were trying to do, what we were doing for customers, this journey we really were on together with our customers about how to do IT better. It was more about the longevity of Cisco, the relationship between EMC and Cisco, and those were pretty hard, you know, for customers to understand, a customer a bit like, well, tell me what is going on with Cisco and EMC? And from our perspective, it was always pretty easy. It was like, let's ask John Chambers, let's ask Joe Tucci. So, I think we've always felt we've had really strong backing from both of them. Chuck Robbins has been very committed, so we have, we've built up a very powerful franchise with the V-Block. Even though we've broadened our portfolio, V-Block remains central to a lot of our largest customers. It's our biggest business. And then if you look on the networking side, Cisco networking runs throughout all of our infrastructure. So, even as we build up, you know, the VXRAC business, which is off to a nice start, that's all Cisco networking as well. So it's, you know, it's been great for Cisco, great for EMC, great for us, and we're continuing to partner very closely with Cisco. Great. So, in the last earnings, I believe I heard that you guys are on a $3 billion run rate, so first of all, congratulations on that. Thank you. The product line and how you align to, you know, what you're selling, you know, it's changed a lot over the last few years. You can tell me, you know, what are the conversations you're having with customers? Why do they turn to your group and, you know, give us some insight into some of those customers? Yeah, I think that one thing customers are trying to do is they're trying to understand where is the industry going. Everybody has in common, we're being asked to be far more agile. That's kind of like the number one driver. At the same time, how do you be more agile when your budgets are about the same? So the theme of, I need to simplify things because what I know is my biggest expense is my people and my people are frequently doing things that don't really look like they're helping the business. They're trying to keep the lights on. So by simplification, a lot of that has to do with new technology advances using technology and more intelligent ways to increase productivity, but it's also changing the way we do things. There's this, you know, the customers now are really latching on to don't build what you can buy. And that I think has been propelling a lot of our growth because we offer the obvious simplification of why purchase separately servers, networking, storage, and then all the hassle of bringing that stuff together, integrating it, making it interoperable, and then curating that over the lifecycle when VC can do that for you. And as people look to move more to software-defined storage models and software-defined infrastructure based upon hyper-converged technologies, the same philosophy takes hold. Do you really want to take your servers, figure out what operating systems you're going to put on, and then build software-defined storage and hyper-converged on that, and then manage that separately, or do you want to have that done for you? And people increasingly want infrastructure as a service, and that's something we do very well today. And, you know, looking forward, I think we'll see more of the platform as a service as people look for. I don't want to deal with the management orchestration, you know, how I have to plan for mesos or Kubernetes or, you know, open stack, whatever it is I'm doing, I really want that stuff to just happen for me. Yeah, Michael Dell made a mention in the keynote. You know, the whole idea of simplifying a customer's buying process has always been super-passionate for him, was how his whole company was built. The EMC obviously shares a lot of those same philosophies, but it goes much beyond day one. You guys have had customers for a long time, repeat customers, give us a sense of, what is that ongoing relationship with VCE in terms of how you help maintain things for customers? How do you, you know, where are you taking friction out of the system for customers on an ongoing basis? It's a great question, and back to your Dell analogy, Dell has an incredible supply chain. I mean, they know how to make procurement incredibly simple down to, you know, knowing what country you're living, what day of the year it is, what color might be more appealing to you. They really understand the things that will make it easier for a customer to buy, compel customer to buy things, and then delivering a really high quality product. For us, we have that same level of intimacy in the data center, understanding what goes on in a data center. It's not so much, you know, predicated on the technology, but it's taking technology and understanding how these things go together. And when you find things that are complex, things that are error prone, things that are very, you know, manual, labor intensive, how do you standardize those? And then once you standardize those and take the variance out of it, how do you automate those to take the human error out of it? And that's really the journey that we've been on. So many of our best ideas have really come from our customers.  It's, if we're all doing the same thing in our data center, it means it's an opportunity for you to figure out how to put this in software to automate it for us. That's really where our vision software came from. It was largely driven by customers having this, this consistent information, but it's all, it lives in one system. How do I pull it out of here? And that's really where we get some of our, you know, best ideas is just listening to customers talk about what's challenging for them. We have a term we use at Wikibon. We call it true private cloud. We've done some forecasts. We really think that over a long period of time, the next six to eight, 10 years, we're going to see a lot of those, you know, sort of operational inefficiencies or just repeatability, get pushed back with vendors driving it into your products. You guys obviously sound like you're ahead of that curve. You're already seeing that trend and you're trying to build it in and make it something that every customer can take advantage of. Yeah, I think, you know, in hindsight, everything's 2020. I mean, I remember when, back in 2011 in Wikibon, we were plastering Wikibon all over because you guys were basically claiming that, you know, by 2020, most infrastructure was going to be delivered, converged, which sounded wild at the time, right? I mean, it sounded absolutely wild, but we're like, look, these guys, these guys believe in what we're doing. And we are seeing that come true. And more, as you look at customers now trying to set up environments, whether it's DevOps environments or application development environments, they're using new technologies, but there's not a lot of skills. So they bring in people and they build up a pilot and they get it to work. And then it doesn't, maybe it doesn't do something that, you know, quite the way they want it. And they're trying to, well, how do I rebuild it? And it wasn't built. It wasn't built to be sustained. It wasn't built to be augmented and evolved over time. The people that did it are in high demand, so they go off somewhere and the customers are finding that even using some of this new stuff that's supposed to be an easy way to develop is actually hard. So I think you're absolutely right. I really think this is a trend and this idea of convergence has to work up the stack. So Bob, I'm wondering if you can comment on what's holding customers back. I remember back in the early days, it was just like, I have a storage budget, I have a server budget, you know, I have a network budget and just aligning that to buy something was difficult. You talked about all these new technologies coming in. You know, what's stopping IT from, you know, going faster and being more agile? I think it's a combination of things. Change is always a hard thing. And I'll tell you what I've noticed is at a certain scale of a company size, you can always peel off a few people to go try something new, all right? And that's how we got our start in a lot of the big global enterprises. They're just like, okay, I'll buy a VBlock system and see how it works. And they weren't really committed to the idea. It was more to compare it to what else they were doing. And it's like, wow, this stuff is really great. And now they start moving other things on it. If you're a smaller company, it's really hard. You've got this year I buy servers, next year I buy networking, the next year I buy storage. So they've got financial barriers, they've got organizational barriers, maybe silos, maybe you need consensus from everybody. So there are a lot of reasons why it's difficult. I think that what is moving customers now to embrace it more aggressively is they are seeing a willingness on the part of the business to go around IT, shadow IT budgets, either moving off into the public cloud, where maybe they're getting some of the agility, but they're not getting the service levels they need, the data sovereignty and transparency. So this I think is encouraging a lot of IT people to say, I can't just do the status quo. Hyperconverged is, I also think, going to be very helpful for customers who need a lower starting entry price.  And the appliances are also for point projects. They're a great solution. So I think the early adopters, they were on early. The early mainstream, they were on fairly early. Once you start getting into the late mainstream and some of the laggards, change becomes very difficult for those people. And I think you can't ignore the fact that some customers are going to be faced with greater internal barriers than other customers. And then it's just how people feel about adopting new things. It's not new anymore, though. It's pretty much mainstream now. Yeah, so some of the early V-blocks, some of the feedback was, hey, we're not used to, like you said, we're not used to buying storage and compute in the same cycles or depreciation, things like that. You guys have worked through a lot of those issues. Your processes have gotten more flexible. I mean, if you went to a customer today, is there any reason you couldn't have an all VCE data center?  No, I think we have a lot of all VCE data centers already and by all VCE, it doesn't necessarily, they've all standardized on X86. There are a lot of customers that have, but we have customers where they'll run their mainframe, right? They have a mainframe and they're running the storage off of a VMAX that's on a V-block. So it's very common now for customers to say we're really all in on this because if you do a great job on part of your infrastructure, let's say you take half of your infrastructure and you make it three times as good, right? Well, any further improvements on that are really dwarfed by the mess that's in the 50% that you've had in touch. So it really becomes something where customers tend to more go all in. I mean, that's really what's driven our growth has been repeat business by customers. So Bob, we've seen great expansion in the portfolio. You've got the blocks, the racks, the appliances. You talked about some cool new technologies. We look forward, show us a little leg from a roadmap standpoint. What do we expect to see from the Converged Platform Division over the next year? I think what you're going to see and the challenge to do is really when you, the reason there's a portfolio is because different use cases are best served by different types of infrastructure. So blocks, very, very good for traditional workloads. If you think about some of the advanced business continuity, disaster recovery capabilities that have evolved in blocks over times, this is what really runs a lot of international commerce today, right? When you go swipe a credit card, a lot of things that you do are dependent upon blocks technologies. Racks are catching up in a lot of areas both for traditional workloads. And I think you'll see them be the mainstay of these new cloud native applications and workloads which are going to eventually overtake the traditional workloads. So the challenge for us is to simplify the story and then simplify operating a data center as the portfolio becomes more complex. So we're at today where we have a VX rack where you can have different node personas. One, the flex for multi-hypervisor heterogeneous environments, SDDC for VMware specific. Stay tuned tomorrow for a big announcement on cloud native but allowing customers to have a very flexible infrastructure where you can have all of these things and even maybe reconstitute things, reconfigure over time under single management. That's really a longer term journey but that's where we're headed because today, how you manage a cloud native environment is actually different and it's a good thing that is different from how we manage, say an enterprise hybrid cloud because there's really a lot of heavy lifting and brute force involved in managing an enterprise hybrid cloud that has a lot of different traditional applications and we can simplify things a lot in the native hybrid cloud. So it's again, it's this turn of the crank doing some, I would say revolutionary stuff up in the upper layers where people want to buy a platform as a service where it's not just a great developer experience but it's a phenomenal operations experience as well. All right, well Bob Lomback from VCE, the EMC Converge Platforms Vision. Appreciate you sharing with us kind of the updates and where things are going forward. We'll be back with lots more coverage here from EMC World 2016. You're watching theCUBE. It's always fun.