This webinar examines the new generation of cybersecurity and the network automation tactics enterprises should be taking to ensure they are prepared to identify and mitigate cyberattacks.
Jason: Thank you for joining us today. We’re going to be talking about the role network automation can play to strengthen cybersecurity. My name is Jason Baudreau. I’m the director of product marketing here at NetBrain. I’m accompanied by Rick Larkin, one of our senior engineers, who’ll be running some live demos later on. We’re here live, and I want to encourage everyone in the call to engage with us throughout the presentation. If you have questions or comments, please type them into your WebEx chat window. We’ll even save some time at the end to answer some of those questions over the phone.
Let’s start by taking a look at the security landscape today. All networks remain vulnerable – that’s despite millions of dollars invested in security. John Chambers famously said, ” There are two types of companies, those that have been hacked and those who don’t know they’ve been hacked.” The question for most organizations isn’t if they’re going to be breached, but how quickly they can isolate and mitigate the threat. And organizations are struggling to react to threats. Intrusion detection systems are being overwhelmed with hits. And most of them are harmless, but it’s challenging to separate the real threats from the false positives.
When an attacker does permeate the network, they can wreak real havoc. That’s to the tune of at least $40,000 per hour. This figure marks the most conservative estimates I have found. Some of them are hundreds of thousands of dollars per hour. I’ll use DISA, the Defense Information System Agency as an extreme example. With 4.5 million users and 11 core data centers, DISA makes over 22,000 changes to its infrastructure every day. With so many changes, I’d imagine it gets pretty hard to maintain security compliance, probably impossible. And DISA’s infrastructure generates about 10 million alarms per day, 10 million. So only a small fraction of those become tickets but even just point 0.2% represents 2,000 tickets a day. Each may take hours or days to resolve. And with DISA’s network, a lost circuit could cause a battlefield surveillance drone to abort its mission or could cut off commanders in the field from their superiors. So this is serious stuff.
Okay. So since my topic today is “Network Automation,” I’d like to just start by putting in perspective the role the network plays in securing your organization’s information. So what’s the difference between InfoSec, cyber security and network security? Because I hear these terms used interchangeably often? Well, first, information security aims to ensure that all data, whether physical or digital, is protected from unauthorized access, and so that includes things like physical access control. Cyber security is a subdomain of InfoSec, which aims to protect only the digital data from unauthorized access. Then as a subdomain of cyber security, network security aims to protect any data that’s being sent through your network, ensuring that information isn’t intercepted or changed along the way. In other words, whereas cybersecurity includes protection of data at rest, network security focuses on data in motion, including things like encryption and remote access.
The role of network security is to protect an organization’s IT infrastructure from any type of cyber threat. That can be things like viruses, worms and Trojan horses, malicious software which targets and damages PCs and end systems. It could be denial of service attacks, which are methods to make a machine or network resource unavailable. Then there are zero-day vulnerabilities, holes and software, which are exploited by hackers before a vendor becomes aware and can hurry to fix them. And last spyware and adware, which is software, of course, that aims to gather information or assert control over device.
And so network security teams must implement hardware and software policies to protect their infrastructures and detect emerging threats before they can infiltrate the network or compromise the organization’s data. And, of course, teams are leveraging several components to do this. Those systems include things like firewalls – typically using state tables to block unauthorized traffic while, of course, permitting authorized communication – virtual private networks, which create a safe and encrypted connection over a less secured network like the internet, intrusion detection systems, which alert administrators when someone’s trying to break in or compromise a system and again, of course, antivirus software, which protects computers and end systems from viruses. And when the security of your network is compromised, the priority should be to isolate the attacker and mitigate the threat as quickly as possible, in other words to stop the bleeding.
And so to better address the dynamic risks of cybersecurity, President Obama issued an Executive Order for improving critical infrastructure security, and this resulted in this cybersecurity framework, which was produced by NIST. And it’s also endorsed by SANS. So it’s become a standard used by many organizations around the world. The framework provides a set of best practices to help organizations manage their cybersecurity risk, but how organizations implement this will vary. But the basic functions of the framework score are as follows.
First, identify means to understand the business context, including resources that support critical business functions in the related cybersecurity risks. So, outcomes of this function include asset management, risk management, and governance. Second, protect means to ensure delivery of critical infrastructure services. So this limits the impact of a cybersecurity event. So, outcomes include access control, awareness and training, and data security. Detect is the function to develop and implement activities to identify a cybersecurity event when it’s happening. So, outcomes include anomaly and event detection, continuous security monitoring and processes.
Fourth is respond. Respond is how teams take action regarding a detected threat. Outcomes include response planning, communications, and improvements. And last, of course, is recovery. It’s how organizations restore capabilities and services that were impaired during an attack, and outcomes include recovery planning and communications. So it’s worth noting that the functions outlined above are not intended to lead to a static end state but rather they should be performed concurrently and continuously to provide an operational culture that addresses this dynamic risk. And networks keep evolving and so do the demands on them.
Right now, there are a number of trends which are challenging network teams to maintain security, first, the Internet of Things. It has broad implications for consumer devices, but many IoT devices are permeating the enterprise as well. Today, medical devices, badge scanners, lab equipment, even coffee makers have an IP address. And that means that network teams need to identify, track, and secure those devices. And by the way, these devices are inherently insecure with manufacturers often looking at security as an afterthought. Next, in the middle, employees are connecting from anywhere, accessing services from iPads, Android phones, tablets, and laptops. Many of these devices are employee-owned. Even as organizations are starting to push back on BYOD, still there remains a large group of personal devices accessing corporate resources, and this is wreaking havoc on security teams.
And last, enterprises are adopting private, public or hybrid cloud services at increasing rates, and this trend presents a big challenge for network security as traffic can go around traditional points of inspection. To address this increasing complexity, we recommend three core principles for organizations to invest in.
They are: better visibility into their infrastructure, improved collaboration across network and security teams, and more automation for each phase of security.
Let’s start with principle number one, enable dynamic network visibility. First, what is manual network visibility? Well, organizations have many tools, but when it comes to network visibility, there are only a few options. Your intrusion detection system provides some visibility, letting you know when there’s potentially malicious traffic on the network, but these tools provide few insights into the impact of a threat.
Some network diagrams give a sense of how the network is connected and what the potential impact is, but the diagrams may be incomplete or outdated and they’re not contextualized to the attack. So then engineers turn to their primary tool, the command line interface. And this gives visibility into the configuration design level, but not the network level. So it’s a very limited lens still. And so when all else fails, engineers need to escalate to rely on the experience of tribal leaders who know best practices for security and how to mitigate threats. And this entire process is very time consuming, and it’s especially limiting when every second counts.
So then what does dynamic network visibility look like? Well, let me define that as having on-demand visibility into any part of the network, including the ability to map from any source to any destination. Next, it’s having visibility into the underlying configuration, whether that’s basic routing or advanced security design. Third, it means understanding the performance as it relates to a particular part of the network so teams can assess the impact of vulnerabilities and perceived threats. And last, this visibility must be flexible enough to adapt to hybrid networks, including SDN technologies. And so here’s a picture of an application across Cisco’s ACI technology.
Next up is principle number two, promote a culture of collaboration. As complex systems, enterprise networks are operated not by individuals but by teams – often distributed geographically with different technical skills and cultures. And the ability of teams to work together effectively therefore plays a vital role in network operations and security.
Teams should look to implement tools and processes, which enable frictionless collaboration across two key areas. One is knowledge sharing, and by this, I mean the network and security gurus must start to share their institutional knowledge with the broader team. This should be both from a domain knowledge, for example, things like security best practices, which might be found in textbooks, as well as tribal knowledge, like understanding the unique policies configured on the network. And this might be in the form of notes or custom scripts.
Then there’s data sharing. So this is particularly important during escalation of a ticket. A traditional escalation has Tier 1 performing a basic set of data collection and analysis before escalating with minimal data in the ticket. So when Tier 2 responds, they often have to start at square one, collecting the same data over again, and then the same thing happens again at Tier 3.
So to effectively share knowledge, network and security team should digitize their best practices into Executable Runbooks. These are processes which can be carried out by any member of the team. These may be best practices for securing network configurations or for responding to cyber threats.
And these same runbooks can then be used when teams need to escalate data. Since these runbooks are executable, any data collection and analysis which happens upon execution, is automatically saved to the runbook, which can then in turn be attached to the ticket before escalation. And so this minimizes the time Tier 2 and Tier 3 must spend repeating the same diagnosis that was already performed at Tier 1 because the data’s already attached to the ticket.
Which brings me to principle number three, implement network automation, particularly for critical tasks. So looking again at the NIST framework I introduced earlier, you’ll notice there are two fundamental functions, proactive network security, usually referred to as network hardening, and reactive security, which is namely threat response. Typically, these workflows are largely driven through the command line interface, one device at a time like I mentioned. So let’s first look at network hardening. This is typically performed through spot checks because it’s just not possible to verify compliance 365 days a year across every device. Networks are changing almost every day, and new threats are being released almost every week. So it’s just not a scalable solution.
So to introduce how automation can streamline network hardening workflows, I’d like to introduce Rick Larkin, our senior network engineer to run a demo. Rick?
Rick: Thanks, Jason. Many organizations must demonstrate compliance to network hardening best practices, but to do so requires a lot of manual effort. In this table, are 10 of the top 20 security controls as identified by SANS, the SANS Institute also known as the System Administration Audit Network and Security Institute. Some of the first ones you see in the list talk about inventory and secured configurations, but number 11 has the direct application to the network infrastructure for firewalls, routers, and switches. Basically, it says you need to make sure that all devices that are processing data are configured securely. Those policies are described in well-known industry standards like PCI, HIPAA, and NIST.
There’s also a second use case called compliance drift where you need to verify that the network is compliant, not just on day one or after securing out, but continuously. All networks change over time, and you need to periodically validate that the network is still in compliance. That means that the manual process of combing through network configurations has to be done over and over again. But with NetBrain, you can easily execute those compliance checklists for the latest industry or internal compliance standards.
Let’s go ahead and start the demo. Okay. We’re going to start here at the site manager view, and I’m going to open up the site for the overall network. So you can use NetBrain to validate if your entire network is compliant or if you want to drill into a particular area, you could do that. In this case, I’m going to drill into the Boston datacenter. Here’s the infrastructure for the Boston datacenter. And we have a number of runbooks that are available, and I’m going to be running a compliance runbook for the NIST compliance standards. So you see here, we have NIST, we have PCI, we have HIPPA compliance, and I’m going to go ahead and run this NIST compliant run book. And so you can also create your own run books as well if you want to add in your own internal standards and security requirements.
All right, we’ll go through a number of these things, essentially a runbook is a checklist of things that need to be verified to ensure compliance with this particular standard. First one I’m going to run here is going to check the ACL log configuration. What this is, is it’s checking first to see if any ACLs are configured, and if they are, are they, in fact, being logged? And you will see that shortly here on the map. So what you see here in yellow, we’re identifying what devices actually don’t have any ACLs configured and then in red, those devices that do have ACLs configured. And this is important. Why would you want to do this? You’d want to do this to see, and we’re seeing actually a number of those devices with ACLs aren’t logging.
You want to see that the policies that you have, are they, in fact, working? Are they actually having an impact on the traffic that flows by? And also if you have a particular policy that’s hitting quite a bit that might be indicative of some traffic that is problematic and you want to dig into that a little bit closer.
All right, this second example, we’re going to be checking for OSPF authentication. And If you have OSPF as an interior routing protocol, there’s a lot of communication that goes on between the routers, and this should be secure. The way you do that is with a hashing algorithm, and this is so that no rogue devices can influence the behavior of the OSPF networking. You see here we have a couple that show up both devices that don’t have authentication turned on or specific interfaces that don’t have authentication turned on. And this is important. This is very common. You’ll see this across all the various standards. And this is another common check that we want to run.
All right, great, let’s try one more. This is going to be checking that SSH is configured for all virtual and physical interfaces. Now, most organizations secure the management IP of a network device, but sometimes they forget to do it for those other interfaces like auxiliary and console ports. And we see here we have quite a bit of results on our map. So we see a number of instances where the passwords aren’t configured. And this first example here, we see that we actually have a V2I session that’s not configured. There is an example of an axillary port and here’s an example of a console port. And this is important. Why? If for whatever reason somebody had physical access to your network devices, they could potentially get in through that auxiliary and console port and certainly caused some damage to your environment. And that’s something that you wouldn’t want it to do. So keep in mind that all of these compliance checks are performed in real time on the production network. In addition, the CSV report could be created to summarize the results in a pass/fail manner. And this will help avoid compliance drift and these runbooks should be executed periodically and following every major network change.
In the last demo, we’re validating compliance at the device level. Next, suppose we need to validate security regarding connectivity across the entire network infrastructure. This is a PCI example, which requires segmentation of the credit card data environment or CDE from the rest of the infrastructure. The CDE consists of point of sale devices where credit cards are swiped and/or web-based transactions where credit card data is also required. Ideally, the CDE would be physically segmented, but quite often, there are other enterprise services that are required like directory services, patching of other systems, and it’s impractical to have it completely segmented. So you just need a very tight restrictive policy. And then, in addition, the rest of the network infrastructure needs to be completely segmented from the CDE. In fact, it’s best practice to minimize the attack surface of the CDE to the rest of the network environment and verify that security policy of denied by default permit by exception remains in place. Now, NetBrain can help with the traffic path analysis by analyzing the paths across the network between any two endpoints defined by an IP address or DNS name, but it’s also aware of ports and protocols.
Let’s go ahead and jump into the demo. Here we are back in NetBrain. First, I will define two endpoints for this traffic analysis, which is something we also call the A to B path. In this example, one of the end points is going to be a database server. And imagine this is in that enterprise services environment. And then the other end point is going to be a web server and imagine this web server is in the CDE. We’re going to do this in a round trip analysis, and we’re also going to do this on the live network. And this is initially going to be just for the IP layer, which is great. And once we have all this set up, we can go ahead and create this path. And again, just to summarize, this is an example of the database server being in the enterprise services providing services to that web server in the CDE and we just want to validate that connectivity is there. So let me go ahead and we’re going to path this out.
So what NetBrain is doing is we’re performing a real-time analysis of the path, looking at a number of criteria and all the network devices along the path, including any security policies and access control lists. And this is much more than a graphical traceroute. You can see a number of policies that are in place. You see here in the firewall, there’s both ingress and egress policies that are in place. And in this case, this is actually allowing the traffic through and permitting it to flow, which is great. You see another policy up there. Now, if you want to actually dig in a little bit more, we can go ahead and actually inspect the actual configuration of the firewall. So let’s go ahead and do that, and we’re going to analyze this configuration and validate that security policies are configured in a way that are expected to be configured. And we see here there’s the actual policy. So that’s great. So we’re verifying that the path is in place, and we’re also verifying that the policy is properly configured.
In this next example, we’re going to validate that a security policy is in place that’s actually going to deny traffic across the network. So in this case, I’m going to use two IP addresses. First is 10.103.20.50, and that’s going to be going to another endpoint. That’s 10.104.10.50. All right, I’ll do this in a one-way environment and in this case, so I’m defining IP. I’m also going to specify the ports and protocols. So this is going to be a TCP connection, and we see here that the ports are already predefined, but basically we’re going to be having a source port of, in this case, it looks like it’s a source port of 51237, their destination port of 8080. Let’s go ahead and path this out.
So you see here, in this case, we’re now doing this path analysis with the data, flows across the network, is allowed through that one firewall but is ultimately denied at this last network device. So again, this is an example where traffic is not allowed to flow. And this is important, right? I mean, you were validating that we have the proper security policies in place. And in this case imagine it’s again defending that CDE environment from the rest of network.
I can also go ahead and do additional analysis with NetFlow. And so what I’m doing here is I just type in NetFlow to see where I can get that data, drag and drop the NetFlow CLI command on the map. And we see here we have a couple instances of NetFlow between these two devices. Why are we doing that? We’re doing that so that we can understand, besides the traffic that was denied, what other kinds of traffic is flowing across the network by port, by protocol, by source and destination? Again, this is just to get a better understanding of the environment and the kind of data that is flying across the network.
One more scenario, here I’ll show how NetBrain can quickly analyze your environment and help create a remediation strategy when new network vulnerabilities are announced. These are increasing across all vendors, models, and technologies. Typically, when these vulnerabilities are made public by US-CERT or the vendor, it can be a very manual and time-consuming process to identify the impact to your production network. In this case, here’s a recent SNMP vulnerability identified for all Cisco IOS devices that we’ll demonstrate just how easy and how quickly NetBrain can assess where in the network these vulnerabilities are, and assist in developing that remediation strategy. So let’s go ahead and get into the demo.
So the first task is to figure out where across the entire network infrastructure these vulnerabilities exist. So I’m going to go ahead and create a device group. And this device group is going to be defined by all of the Cisco IOS switches. So in this case, this is a vulnerability for a Cisco IOS, and imagine in this particular environment I have IOS switches. So I’m going to create this device group, call it Cisco IOS switches, and I’ll cut and paste and make that part of the description as well. And then what’s nice about the device group is you can create these things dynamically and define a bunch of different selection criteria. And it could be any combination of device, module, interface, and configuration properties. So, we’ll go ahead and select device properties, specifically device type. And we’ll look for that Cisco IOS switch, and there it is. And then we’ll do a search across the entire domain to see how many devices we have. And here we go. Looks like it found them all.
You can also do more refined searches by adding in other things like hostname, if you want to look for a specific location or subnet or any combination. All right, great, so we’ve created this device group. And once it’s created, then we can actually go ahead and do some other things. So we see here there’s over 144 of these things in the environment. Now we’re going to go ahead and open up a map and map all of these things. So we’re quickly generating a dynamic map here, and this allows me to see, “Hey, where are these devices across my entire infrastructure?” So now what?
All right, so many times, when these vulnerabilities are announced, they’re associated with a particular firmware version and where a more recent version is required or perhaps if they need to even cut a new version. So what we’re going to do is we’re going to actually analyze what version of firmware is running across the network and then see if we’re running the right version that would not be susceptible to this vulnerability. And we can do this a number of different ways. The first thing I’ll do is we’ll just type in the show version command and see what options we have to get the output. So we see all the pieces of data that’s parsed from that command will actually just find that version data and literally drag and drop it across the map.
All right, great. So, essentially, what’s happening now is NetBrain in real time is now going to each these devices and basically running that command, parsing out that which says, “Hey, show me the version,” that’s going to hang that information underneath each of these devices, right? So and pretty quickly here, we’re going to see all the different versions of firmware associated with each of these devices. All right, so we can see we have the firmware identified and there’s a number of different versions. So let’s just imagine in this particular case that the fix is, any firmware that’s 15 and later is not susceptible to this issue. Anything previous to 15 is. So we’re going to create a quick alert, and what we’re going to do is this is going to be alerting based on the actual version of firmware. This is a very simple type of basic alert, but there’s other options for flapping in advance.
And I’m going to say any version that doesn’t contain “15.” in the actual description is more than likely not version 15. So it’s going to be beneath version 15. So we’re going to create this as an alert and alert on that. And so now what NetBrain is doing is it’s going to go back out and again get that version of firmware and do this check to say, “Hey, if it’s version 15 later, fine. It will stay blue.” If it’s something previous to version 15, we’re going to see it alert and it’s going to come up in in red. Okay, great. I can see some alerts that are actually being identified, here we go, both in the map and there’s also a log of all the alerts here. So that’s another way to kind of look and scroll through, but the nice thing here is it’s been clearly identified on the map. So now you can see, “All right, in San Jose, I definitely got some work to do.” So I have a number of these devices that have this issue then I’m going to go to have to start to deal with.
So there’s another way to actually also get this list of devices. So this is a map-based view visual to give you a sense for where in your environment that you have these issues. But I can also go ahead and create an inventory report. And so what I’m going to do here, and this is again another capability we have. And so all the devices that are in the domain are here, and I can filter them down a number of different ways. I can filter based on my network by site, by these device groups, which is what I’m going to do, or all these other device types. So let me go ahead and get all the Cisco IOS switches. I see I have of them here. And this is like an interactive spreadsheet. I can sort based on the version of software. And I can quickly get to, “All right. Where are those devices that are not 15, some of other versions?”
And then if I want, I can also export this to an Excel spreadsheet. And this just helps me to create that work plan. Ultimately, we have some work to do. We’ve got a plan for these firmware upgrades for the next maintenance window perhaps. So let’s just start with a list of the devices. And so being able to export this to Excel very quickly, I can go ahead and take advantage of this and perhaps highlight those devices, the ones that I need to worry about.
Just in summary, overall, these are just a few scenarios, which demonstrate how automation and visibility can improve your network security posture. Thank you so much. And, Jason, back to you.
Jason: Thanks, Rick. We believe automation is going to become even more important as networks grow larger and become more hybridized. Next, I want to talk about a more reactive workflow, what it looks like to respond to cyber threats. With the volume of perceived threats coming from an IDS, it may not be feasible to isolate and mitigate each one. I’ve been told by many engineers that they more likely have to wait out the attack and just hope the attacker will stop. Of course, this can be a very damaging proposition and sometimes even catastrophic. Take for example the recent Equifax data breach. Criminals had access to their network for weeks unmitigated. So again, to see how automation can be applied to cyber threat response, I’ll welcome back Rick for another demo. Rick?
Rick: Thanks, Jason. What are the challenges for both network operations and cyber operations teams as gathering data related to an event while it is occurring or soon thereafter? By the time the engineers are informed of the event and begin to assess the situation, the event can be over or the environment could be very different. In this example, NetBrain is integrated with a Splunk so that when a given alert is reserved, it will trigger NetBrain to gather data related to the event to help inform the situation. I imagine an attacker is sitting at 192.168.2.10, and the system under attack is at 192.168.11.117. The attacker is attempting to flood the network with ICMP echo requests to either impact the network or to impact the application running on the end system. An intrusion prevention system is going to detect the threat based on its own sensor rules and then generate alerts to Splunk.
Splunk is acting as a security information, an event manager will go ahead and use their search and alert mechanism to trigger an API call to NetBrain, and NetBrain will provide visibility into the attack between the attacker and the victim. And in this case, it will calculate the path between the two endpoints, create a detailed network map, and gather some performance data via a runbook to help diagnose the event. Let’s take a look at this in action.
Okay. Here’s Splunk, and here is that IPS detector component that’s part of Splunk. And what we’re going to show here is that Splunk has, in fact, picked up that alert from the IPS. So you see the alert log here. We see it was able to detect this event, and it is, in fact, related to those ICMP echo traffic. And it also picks up the source of the traffic the .10 in the destination of the traffic, which is the .117. And this is how Splunk is alerted to the situation.
Then what Splunk does is it uses the information from the alert to go ahead and trigger NetBrain via a RESTful API. You see here there’s a number of options within Splunk to go ahead and create this alert. There’s all kinds of conditions that you can set from the results section. In this case, we’re looking for so many ICMP requests over a certain period of time, and you can also define the actions that could be taken, lots of options here. In this case, we’re going to trigger that NetBrain API. And then similarly, once inside NetBrain, when that API call comes in, we need to set up what tasks are taken. So in our case, there’s a bunch of options. What we’re going to be doing is mapping a path between those two IP addresses, but you can also just map around a given device, open a site map or open existing maps and other things like that. In addition, you can then execute any of these runbooks based on those conditions. So you can see it’s actually very easy to do, and there are a number of options here. And these can be easily refined over time.
All right, here we are now actually looking at the API. This is what Splunk is doing. So we see here based on that alert, it goes ahead, calls the API. It then goes ahead and it’s aware that NetBrain is currently in the path. And then once NetBrain gathers all the data, it’s returned in the form of a URL. Let’s go ahead and copy and paste that URL and see what kind of information we have to inform the situation.
Okay. We see now NetBrain is opening up a map, and there is that path. This is a nice dynamic map again that is created as a result of the information that we got from Splunk. We see here it has that source, the .10 and the destination, that victim, at the .117. And this is very handy in particular for helping teams to isolate which part of the network is impacted, including every hop along the path between those two endpoints. I’m just going to zoom in a little bit here. I’m just going to kind of move some things around to sort of show some of the data a little bit more clearly. Something else to remember is that all this data was gathered at the instant the event was detected from Splunk.
All right, we also have over here this activity log showing that there’s been a number of tasks that have been run. And let’s go ahead, it looks like a runbook was run, and let’s explore the data that was gathered as a result of that runbook. So we see in this case, there’s several things that were collected. And let’s go ahead and take a look at these things. So one of the first things that it actually did, it runs this thing called the overall health monitor. And this is basically going to look at resource utilization along the path, and we can clearly see here that there is definitely some over utilization both from the CPU and memory and some of the devices and even on some of the links. We see there’s a high amount of errors and also some extremely high utilization. So this certainly seems to track that based on this ICMP event that there was a sort of a surge in both network bandwidth and resource allocation.
And then if I want to actually dig into the specific resources used in some of these network devices, we could do that as well. Here, so this particular device we’re going to look at the CPU, and this is actually showing us at this particular time what CPU resources were being utilized. So now you have a sense for, “Hey, what was really being used by that device?” And same thing from a memory perspective, what processes were running that were really consuming a lot of the memory at that time, which could sometimes give you clues as to what the nature of the traffic is.
All right, great. And then there’s other metrics that can be gathered as well, we see here it was getting information about quality of service, NetFlow like I’ve shown before, and even CLI information. So, in fact, you know what you can do, you can even start from here and then gather additional data in real time and then compare the results of that data to the triggered diagnosis to help make sense of the event. All right, great. So with this level of visibility into the network, teams are better prepared to mitigate the threat much faster. Back to you, Jason.
Jason: Thanks, Rick. I have one slide to summarize how network and security teams are responding to threats with automation. First, the threat analysis is API-triggered usually through an IDS or a seam console like you saw Rick do it just a moment ago with his demo. Next, security and network teams collaborate using a single map as a single URL as a shared analytics console. And last, senior engineers can fortify their networks and improve threat response with lessons learn from each event. And this can be in the form of Executable Runbooks.
I’d like to close out by proposing a future where human-to-human collaboration is largely supplanted by machine-to-machine automation to attain continuous cyber security. Suppose a network, which is continuously monitored for threats with a finely-tuned IDS or seam console, any alert generated by that system would trigger a threat response like the one Rick demonstrated via API. Based on a series of predefined conditions, your network automation platform could orchestrate a network change which mitigates the threat virtually instantaneously. And then network change would then trigger an event management system, which in turn would trigger a change validation request to the network automation platform, which would close the loop. The same principle can be applied to a network hardening or a more proactive workflow like the one Rick demonstrated earlier, whether triggered by a network change or by a new vulnerability announcement from a vendor bulletin board. And in each case, this may trigger an impact analysis and change request to close the vulnerability. So that wraps our presentation today.
I want to thank you all very much for joining us. I’d like to end with this slide for those of you who are new to NetBrain. We’re the creator of the world’s leading network automation platform. NetBrain has been around since 2004, and it’s used to power almost 2,000 of the world’s largest networks, including one-third of Fortune 100 companies. If you like what you saw in the demos Rick ran, you can request a custom demo live through our website at netbraintech.com/request-a-demo. Rick and I will remain on the line for the remainder of the hour to field your questions. So please keep those coming through the chat window. We’ll try to answer a number of those out loud over the phone as well, but if you hear us here silently, just know that we’re still here typing away. So please keep those questions coming. Once again, I want to thank you all very much for joining us.
This video will walk you through an example of how to isolate and mitigate a DOS attack in real-time.Watch Video
Network security teams have long been forced to rely on the same playbook for protecting the network: Wait for an…Learn More
Network security remains a challenge for enterprises: a cat and mouse game of trying to keep up with the technical…Learn More