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.
Many Cisco customers with an interest in product security are aware of our security advisories and other publications issued by our Product Security Incident Response Team (PSIRT). That awareness is probably more acute than usual following the recent Cisco IOS Software Security Advisory Bundled Publication on September 25. But many may not be aware of the reasoning behind why, when, and how Cisco airs its “dirty laundry.”
Our primary reason for disclosing vulnerabilities is to ensure customers are able to accurately assess, mitigate, and remediate the risk our vulnerabilities may pose to the security of their networks.
In order to deliver on that promise, Cisco has has made some fundamental and formative decisions that we’ve carried forward since our first security advisory in June 1995.
Risk. It’s not just a strategic board game; in business it’s the analysis that determines the potential for loss.
In today’s organization, the consumerization of IT has led to groundbreaking developments in the mobility space. The broad deployment of BYOD, coupled with the availability of corporate data and applications, have challenged how we define security. And with recent news reports citing the rise of mobile hacking and network threats, the security of mobile technology and the data it carries seems to be at risk.
Fortunately, all is not lost.
Mobility gives employees and providers options for the workplace and creating a mobile experience that is efficient and innovative. It is also helping businesses save and make money. Today, employees in any place on any device can access any application across any network in any cloud. As a result, there are challenges associated with implementing a comprehensive BYOD policy that encompasses a proliferation of devices connecting to a network.
Even though mobility can cut costs and increase productivity, 60 percent of IT professionals recently surveyed believe mobile devices in 2013 present more of a risk to their organization than they did in 2012. And even with the growing concerns over mobile security, it still appears that only 60 percent of organizations require security technology for mobility plans. Why isn’t that number higher? After all Android Malware grew 2,577 percent in 2012 alone.
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.