Today, rapid changes in the world we live in, driven by technology trends, business model changes and market transitions, like the Internet of Everything, profoundly impact our networks and our data centers. With the advent of all of these new capabilities, we have created a new paradigm for security—it is what I refer to as the “Any to Any” Problem. That is, any user on any device increasingly going over any type of connection, to any application, that could be running in any data center and on any cloud. Regardless of how or where our users are connecting, we have to provide the right levels of inspection and protection against malicious actors.
Today, Cisco is announcing the new Application Centric Infrastructure (ACI) designed to seamlessly integrate layer 4 through layer 7—and security, in particular—into next generation Data Center environments. As part of this framework, we are announcing ACI Security Solutions, which support next generation Cisco ASA physical and virtual firewall technologies by stitching them directly into the ACI network fabric, and can be managed using the ACI Policy Infrastructure Controller management tool.
The Cisco ASA 5585-X Series Next-Generation Security Appliance has been updated and certified to interoperate with the new Nexus 9000 switches—whether they are deployed in traditional or ACI modes. The new Cisco ASA Virtual Firewall (ASAv) performs the same functions as any ASA appliance. However, unlike an ASA 1000v Cloud Firewall, the ASAv maintains its own data path. This allows it to work with any virtual switch and it will be available on multiple hypervisors. Read More »
It’s one thing to say that by 2020 the world will host 50 Billion Internet Protocol-connected devices. It’s even more amazing that the planet’s number of Internet-connected devices already exceeds the human population. So how do we secure tens of billions of devices when we know that the vast majority of them will not possess sufficient memory and processing power to accommodate conventional anti-malware or other security software? Two things are clear to me. We need to build security into Internet of Things solutions from the beginning, and that the network is the only option we have to bring security visibility and control to this new universe of connected devices.
The Internet of Things is going to transform the world, but unless we act to secure it now we will find ourselves asking at some future date whether it was worth doing in the first place. I don’t claim to have all the answers in the video post here, but we need to start asking the right questions about securing the Internet of Things now.
In the previous installment of the onePK series, you received a crash course on Cisco’s onePK. In this article, you’ll take the next step with a fun little exposé on onePK’s C API. You will learn how to write a simple program to reach out and connect to a network element. This is staple onePK functionality and is the foundation upon which most onePK applications are built.
The following short program “ophw” (onePK Hello World), is a fully functional onePK application that will connect to a network element, query its system description, and then disconnect. It doesn’t do anything beyond that, but it does highlight some lynchpin onePK code: network element connection and session handle instantiation. This is the foundational stuff every onePK application needs before useful work can get done. Read More »
During World War I, British artist and navy officer Norman Wilkinson proposed the use of “Dazzle Camouflage” on ships. The concept behind Dazzle Camouflage, as Wilkinson explained, was to “paint a ship with large patches of strong colour in a carefully thought out pattern and colour scheme …, which will so distort the form of the vessel that the chances of successful aim by attacking submarines will be greatly decreased.” The Dazzle Camouflage was not intended to hide the presence of the ships themselves, but instead was created to hide the ships size, shape, direction, and speed from would-be attackers.
Your network, servers, and a horde of laptops have been hacked. You might suspect it, or you might think it’s not possible, but it’s happened already. What’s your next move?
The dilemma of the “next move” is that you can only discover an attack either as it’s happening, or after it’s already happened. In most cases, it’s the latter, which justifies the need for a computer security incident response team (CSIRT). Brandon Enright, Matthew Valites, myself, and many other security professionals constitute Cisco’s CSIRT. We’re the team that gets called in to investigate security incidents for Cisco. We help architect monitoring solutions and strategies and enable the rest of our team to discover security incidents as soon as possible. We are responsible for monitoring the network and responding to incidents discovered both internally by our systems or reported to us externally via email@example.com.
Securing and monitoring a giant multinational high-speed network can be quite a challenge. Volume and diversity, not complexity, are our primary enemies when it comes to incident response. We index close to a terabyte of log data per day across Cisco, along with processing billions of NetFlow records, millions of intrusion detection alarms, and millions of host security log records. This doesn’t even include the much larger data store of authentication and authorization data for thousands of people. Naturally, like all large corporations, dedicated attackers, hacking collectives, hacktivists, and typical malware/crimeware affect Cisco. Combine these threats with internally sourced security issues, and we’ve got plenty of work cut out for us.