The Meraki MV camera eliminates many of the underlying costs and complexity of owning and operating video surveillance systems. The elimination of all physical components, other than the camera, is highly attractive to a wide range of organizations. This broad appeal leads to users with a diverse set of problems, often beyond the scope of the products current feature set.
Beyond the cross-product APIs available for the Meraki dashboard, there are currently no APIs or raw video feeds available for Meraki MV users. Camera configuration, video streaming, and analytics data are only available inside the Meraki dashboard.
By having a closed end-to-end system, we can ensure an exceptionally easy, enjoyable, and secure user experience. At its core, Meraki provides ease of use and simplicity. This is underpinned with a focus on solving customer problems first and building features second.
With these principles in mind, we need to work out what customers want to do with APIs. Collating these problems into categories we end up with the following:
Off camera storage, providing:
The first category covers the need for bulk storage or off-camera recording. We see two important uses for this type of functionality: The desire to retain video longer than is possible with edge storage, and instances where an off-camera or off-site backup is a mandatory requirement for compliance purposes.
MV’s architecture is designed for distributed storage and compute at the edge of the network, with centralized management and control in the cloud. Allowing customers to use an API to store video outside of this architecture eliminates the simplicity and cost reduction at the heart of the product. Once video leaves the platform, it is no longer associated with its metadata. This dissociation of context would leave customers with petabytes of unsorted raw video and a significant problem.
Meraki is already evaluating how to solve these two problems. Although the functionality is not yet available, its eventual design will ensure customers are not forced to become data scientists in order to manage their video. It will keep video within the Meraki ecosystem to ensure associated metadata is not lost.
The other category of problem that drives MV API requests is systems integration: integration with business systems such as Electronic Point of Sale (EPOS), physical security access control systems such as badge readers, and 3rd party video analytics.
By blending data sources together, further context can be provided to an event. When that can of soda from the EPOS transaction turns out to be a high value bottle of wine in the video footage, you know there is a problem. We are actively working with customers to define how we integrate with these systems and what a future API should look like.
Finally, it’s a simple reality that Meraki will not provide every variation of video analytics customers would want. Niche but high value problems are an area where third party analytics could be of great value. As with presence analytics on the Meraki MR wireless platform, in the future, we will offer out-the-box functionality beneficial to a wide range of customers, and when this is not sufficient, accesses for third party analytics such as with the location analytics API.
Meraki’s MV camera portfolio is still young, and as with our other products, we will release API access as it matures. This approach ensures we solve for simplicity first, and do not offload the hard work of feature development to our customers.
This week, the hardware team behind the MC74 were recognized in Essen, Germany, at the 2017 Red Dot Gala. The Red Dot Design Award is an international award for the best product designs, design firms, and design concepts around the world. This was the first time Meraki products were entered, and we were honored to be awarded in the Product Design category.
The MC74 was chosen as a winner out of more than 5,500 products from 54 countries. The winners were chosen by a jury of 39 experts, and they had high praise for the MC74, saying, “The remarkably discreet desk telephone has a timeless design, offers high user-friendliness and is laid out for years of service.”
As part of the award, the MC74 will be featured in the Red Dot Design Museum Essen until 2018.
The Red Dot helps remind us that here at Meraki, it is important to keep building products with the end user in mind. Good design enables people to do work with less overhead, and that is the standard we strive towards in every product.
At Cisco Meraki, our fundamental goal is to bring simplicity to IT management. It has always been important to us that we extend that simplicity to the firmware management process, so over the years we’ve tried to strike the right balance of automation and control so that our customers know that their devices are always up to date with the latest bug fixes, security patches, and features. While our approach has worked well for many of our customers and partners, it has also created challenges for some who felt they would benefit from a greater degree of visibility and flexibility when it comes to firmware. Today we are excited to announce some significant advances in the firmware management capabilities of the Cisco Meraki dashboard. These new tools and processes add deeper visibility and empower administrators to be more self-sufficient when it comes to our firmware without sacrificing our consistent, reliable update model. These new capabilities come in the form of an update to the Firmware Upgrades page in the Cisco Meraki dashboard. The new page starts users out on the Overview tab, which includes a variety of information: a list of recent upgrades within the dashboard organization, a list of any currently scheduled upgrades that are pending, and a list of the current approved stable versions of code for each hardware product line in our portfolio. This list of stable firmware versions is one of three major changes represented by this new tool, as it includes not only firmware version numbers but also detailed patch notes for each version. The second major change is that any upgrade performed in the last 14 days can be rolled back directly from the recent upgrades list, which will return the network and its devices to the firmware version that was in place before the upgrade. This allows administrators to react faster and more freely to any issues encountered after a new firmware is applied – even if those issues are with other devices in the deployment.
Clicking over to the “All networks” tab presents administrators with a searchable list of all dashboard networks in the organization and their firmware status. Based on the current status of each network, certain upgrade options will be available to put networks on the latest stable firmware, a release candidate firmware (which is a version that is currently undergoing final testing before becoming the new stable version), or the latest beta. The statuses a network can have are as follows:
Upgrade available – This network is not running the latest stable version, and can be upgraded to stable, beta, or release candidate firmwares assuming that a release candidate version exists.
Up to date (stable release candidate available) – This network is running the latest stable version, but can be upgraded either to a release candidate or the current recommended beta firmware.
Up to date (beta available) – This network is running the latest stable version, but can be upgraded to the current recommended beta firmware.
On Beta (beta available) – This network is running a beta version, but not the most recent one. It can be upgraded to the current recommended beta firmware.
Up to date – This network is running the latest beta code and cannot be upgraded.
This represents the third and final major change included in this new tool: administrators can now upgrade to beta firmware themselves, without the need to contact Cisco Meraki Support or their Sales representative. This makes it easier for customers to access new features and bug fixes as quickly as possible. In addition, when upgrading a network to a new firmware version administrators will be able to view patch notes not only for the new firmware, but any versions in between the current and upgrade firmwares, to get a clear picture of exactly what is changing in the code. To perform an upgrade, simply select one or more networks from the list and click the “Bulk upgrade” button at the top right of the page. These new capabilities are a big step forward in firmware visibility and control for our customers, and we hope they will make it easier for all Meraki users worldwide to get access to new features, resolve issues, and keep their networks secure. This new page will be available today for all Cisco Meraki dashboard organizations via the Organization>Firmware upgrades menu option, so take a look for yourself and, as always, let us know what you think!
Have you ever attended a trade show as a visitor and wondered what goes on behind the scenes? CiscoLive! US, which ran from June 26-29 in Sin City, Nevada (otherwise known as Las Vegas) is one of the largest events Meraki attends each year and is a great opportunity for us to mingle face-to-face with current and future customers, answer any questions Meraki users might have, and spread the word about Meraki products.
The event requires months of planning, orchestrated by our fearless Events Marketing and Design teams. All told, 56+ Merakians trekked out to the desert, braving the 110 degree weather, working long shifts, and having some fun along the way. Check out the recap below, featuring Merakians eating pizza, fidget spinners, and a presentation by our SVP Todd Nightingale. (Find a full list of the events and presentations Meraki hosted here.)
Just over two years ago, in March of 2015, I signed my offer letter to join Meraki. I was overjoyed to join the company; it felt like a great fit from the moment I’d set foot in the office, and I was chomping at the bit to get started. Little did I know, I was about to walk right into a grand experiment that would demonstrate our leadership’s trust in the team.
Meraki was going through a major transition. The company had recently been acquired by Cisco and our founders had moved on, leaving us wondering: if we were no longer a startup, what were we? Would different leadership lead to different values? The new leads taking over for the founders were working hard to identify and resolve problems brought about by this transition.
Around this time, several of our new engineering leaders read Creativity Inc: a book on management by Ed Catmull, the founder of Pixar. One section of the book resonated: the chapter describing an event called Notes Day. The book recounted that after a few successful movies, Pixar leadership realized there were a number of problems at the company they didn’t know how to solve. Rather than having managers develop and announce changes, Pixar’s leaders decided to open the floor, allowing those closer to the problems to offer up solutions.
Inspired by Pixar’s approach, Meraki’s leadership decided that the engineering team itself was better positioned to understand and solve many of the problems related to the acquisition and changes in team membership and structure. So, like Pixar’s leaders, Meraki’s engineering leaders made the nerve-wracking decision to put their trust in the team, step back, and let us run with it. Everyone in the engineering department was tasked with figuring out what we wanted to fix and how to fix it. Ideas would succeed because other people on the engineering team bought in, not because a manager approved it.
Designing the first Notes Day
The decision to create a Meraki Notes Day created a new set of challenges. How would we make sure that Notes Day would be a good use of engineers’ time and effort? Meraki’s leaders needed to figure out how to empower the team to tackle challenges outside of their regular job description. The team needed to feel ownership of the problems facing the company, and they needed to feel like they had the means and authority to propose and execute solutions.
With these goals in mind, engineering leaders went about designing Meraki’s first Notes Day. Leaders made it clear that while they would help by organizing the event, they would not actually participate. Any member of the engineering team could propose problems for the team to tackle. An inspired engineer consolidated the list of topics and spun up an internal Reddit-style forum to post them on so that people could begin drilling down to root cause of each problem.
Since anyone on the team could suggest a topic, the compiled list of topics was quite broad. Some issues were highly technical, like challenges with our deployment process. Others addressed broad cultural issues, like how to best integrate new hires. Some issues came up time and time again. For instance, many people noted that we need to address problems with our interviewing process. Many people also brought up the importance of managing our technical debt. The bottom-up topic proposal process also brought some issues that hadn’t been obvious to leadership to light. For example, a number of people pointed out that our work from home policy was unclear, yet the Engineering leads had been unaware of that until Notes Day.
After a few weeks of discussion, Notes Day arrived, and the engineering team headed off site. Each engineer signed up for three sessions: my sessions were Mentorship, Mission, and Culture. In each session, 10-15 people discussed a specific problem. Each group analyzed the problem, came up with actionable solutions, and then decided who would take responsibility to move the solutions forward. Before we started with our sessions, one of the engineering leads addressed the team, reiterating the importance of thinking critically and building toward solutions. He then instructed us to power down our laptops and phones and get to work.
As I walked toward my first breakout session, I was nervous. I had only been at Meraki for about six weeks, so I was uncertain about my ability to contribute. But as our moderator asked us to think about our experience with mentorship, I realized that I didn’t need to worry. The room was filled with people who had been successful mentors, but far fewer had been mentored recently. I was mere weeks into being onboarded, so I had direct insight into what it felt like to be mentored. Our discussion was more fruitful because of the diversity of perspectives, and we ended up exploring some important gaps in our mentorship story. For example, as a new hire, I had a lot of questions, but I didn’t want to prevent my mentor from getting his own work done. I had no idea that mentors were instructed to spend at least 50% of their time early on getting their mentee comfortable working on their own. We realized that mentors needed to do a better job of communicating expectations to mentees so that they would feel more comfortable asking for help.
Within a few months, plans from Notes Day began to come to fruition. From the mentorship discussion, a few people ended up writing documentation that clarified the process for team leads to help train first-time mentors. Other discussion groups proposed broader changes. For instance, the discussion group on geographic diversity discussion resulted in a rotation program in which engineers from the SF office work with the infrastructure team in our London office for 6-8 week stints.
Iterating on Notes Day
Since that first Notes Day, we’ve continued to experiment with the structure of the off-site. This year, our UX team helped to introduce design thinking methods into the process. The UX team partnered with engineering leadership to help rebuild the process around our stated goal of solving hard, not-strictly-engineering problems. As they examined the past two Notes Days, they noticed that while some groups successfully narrowed down the topic to a specific problem, many groups got stuck discussing the problem, or discussing the first idea proposed, and didn’t get to exploring ideas or developing actionable items. The goal for this year was to use design thinking methods to help groups get to the core of a problem and prototype solutions.
The first major change was that instead of having a single discussion about each topic with everyone in the room, each session broke up into groups of three or four. The second major change was that discussions were structured into time-boxed steps. Each group spent predefined periods of time analyzing the underlying causes of a problem, choosing a root cause to address, generating solution ideas, choosing an idea, and determining how to test that idea out on a small scale.
These strategies helped us uncover problems that were not visible at surface level. My first session of the day was supposed to tackle whether or not Meraki needed a web focused testing team. Following the design process, we dove deeper into the issue and asked ourselves why we might need a testing team. We reasoned that people didn’t have a lot of confidence in our current testing environment, so we focused on figuring out ways we could build confidence that our tests catch bugs and prevent regression. Our primary takeaway was that we were missing integration tests, so developers had to manually test whether systems worked together. We decided to spin up an integration testing environment and start writing integration tests. Instead of merely answering the original question posed to us and then leaving it for management to figure out, our group came away with an actionable plan we could start to follow through on as soon as we returned from the off-site.
Results from the new process were immediately noticeable. In smaller groups, people who might have been hesitant to speak up became active participants. The added structure prevented groups from getting stuck on analyzing the problem, or bike-shedding the first idea someone proposed without considering others. Moreover, Notes Day overall produced far more ideas to try out, and far more people excited to invest in those ideas.
Though we only recently completed our last Notes Day, the organizers are already considering possible improvements for next year. Is yearly the proper interval for Notes Day? How should we group people who work together on a problem? Should we reevaluate the amount of time we spend on each topic? These are open questions that we will attempt to answer over the coming months. To figure this out, the organizers are following up one-on-one with people who participated to understand their experiences of Notes Day. We want to build on what worked well, iron out areas of confusion, and try new things.
Notes Day and Meraki culture
Notes Day exemplifies a key aspect of Meraki culture: trust. Our leadership team trusts the engineering team to find the best solutions to technical and organizational problems. We trust our coworkers to put ego aside, engage in tough conversations, and listen when say we think something could be better. Trust is at the core of Meraki culture, and each Notes Day is a reminder of how truly powerful that trust is.
Four times a year the Product Marketing team assembles in our webinar room to share what the Meraki team has been up to over the past 3 months. We all live fast-paced lives in the world of technology. We recognize this and so created this webinar series specifically to give our customers and partners an excuse to take an hour out of their day, sit back and ensure their Meraki knowledge is as up to date as possible.
The format is simple. We go through each of the six product families and provide an update on any new hardware or features we’ve introduced on each platform. The smaller tweaks we’re continuously making are easily missed, but each and every one has been carefully thought through with the aim of simplifying the lives of our customers. Simpler IT means more time to focus on what really matters.
The Quarterly is also an opportunity to learn about any interesting features which have made it to public beta. We are eternally grateful to our beta customers, who help us ensure exciting new capabilities are thoroughly tested before being included in our stable releases.
We’ve been delighted about the success of the Meraki Quarterly and always strive to make this a good use of our audience’s time. Quarterlies are always recorded and posted on our YouTube channel, but attending live is always more fun. Sign-up to join us on July 6th here.
A new and potent variant of ransomware is making headlines in a cyber attack that shares many similarities with last month’s record-breaking WannaCry outbreak. Hackers targeted out-of-date systems in Ukraine, but the threat quickly spread to Europe and North America, impacting several major global organizations. Although both variants share a lot of the same characteristics, several key differences to the anatomy of Nyetya1suggest hackers are not making some of the same mistakes that led to WannaCry’s rapid demise.
Example of a system infected with Nyetya ransomware
Talos, Cisco’s industry-leading threat intelligence team, quickly got to work and produced a preliminary evaluation of the threat, confirming that Meraki MX customers are fully protected by Advanced Security features including Advanced Malware Protection (AMP) and IDS/IPS. Newly released support for AMP Threat Grid also helps identify malicious binaries and build protection into all Cisco Security products.
Since Nyetya uses the same EternalBlue exploit used by WannaCry to spread, it is imperative that inbound firewall rules protect against remote SMBv1 execution (Meraki’s security appliance firewall will defend against all inbound connection requests by default). It is also highly recommended that all Windows-based systems are fully updated to defend against further spreading of the threat.
Example of Meraki MX with Intrusion Prevention blocking Nyetya Eternal Blue exploit
We will continue to monitor and provide updates on the Nyetya outbreak. To learn more about the Meraki MX, please visit our website or sign up for an upcoming webinar.
1Originally identified as ‘Petya’, the current outbreak is a Petya clone with additional enhancements including stronger encryption. The new offshoot is being described as “Not Petya” or Nyetya and also “GoldenEye”.
Apple CEO Tim Cook and Cisco CEO Chuck Robbins took the stage at Cisco Live! this week to talk about the next phase of the Apple Cisco partnership. Part of this next phase will be the Cisco Security Connector, which will completely change the story when talking security on iOS. It can be deployed on enterprise supervised iOS devices using Systems Manager, Cisco’s enterprise mobility management (EMM) solution. See below for an excerpt from David Ulevitch’s Cisco Blog.
“Expected to be released in the fall of 2017, the Cisco Security Connector is designed to deliver the deepest visibility, control, and privacy for iOS devices. The Cisco Security Connector offers organizations the most granular view of what is happening on enterprise-owned mobile devices and provides the best protection for users, anywhere they travel. With the Cisco Security Connector, businesses will now have the ability to meet risk and compliance requirements from auditors and ultimately expand iOS adoption in new ways.”
With the Cisco Security Connector, organizations gain the following:
Visibility: Ensure compliance of mobile users and their enterprise-owned iOS devices during incident investigations by rapidly identifying what happened, whom it affected, and the risk exposure.
Control: Protect users of iOS devices from connecting to malicious sites, whether on the corporate network, public Wi-Fi, or cellular networks.
Privacy: Safeguard corporate data and users by encrypting internet (DNS) requests.
With the mammoth growth of mobile device availability and capabilities, virtually all industries have been affected. This includes the creation of new IT processes, new teams, and new categories of solutions like mobile device management (MDM) and enterprise mobility management (EMM). Mobile devices offer leaps in productivity and automation, but there are not many products that truly make it manageable or scalable for an administrator and end user. That is where Systems Manager comes in. Last month, we went over some of the overall benefits of using Systems Manager in EDU. Today, we will talk about some practical examples of mobility with app management.
Mobility – Apps are one of the major ways end users interact with devices. They are also one of the ways businesses provide their products to customers. Imagine everything from mobile websites and Gmail to the SalesForce or even a calculator app. There are three main considerations when venturing into mobile application management. How to push apps, how to manage app licensing, and how to implement containerization. In the following three sections we will show more about each of these contemplations.
Pushing Apps – Nothing makes it as straightforward as Systems Manager in regard to pushing apps. If it is a public app from the Apple App Store or Google Play Store, then search for the desired app and push it to managed devices. If it’s an installer or private application, then upload it to the Meraki cloud or point to where it is hosted. With the steps being 1) pick an app, 2) select a group that needs the app, and 3) push the app, it is literally as easy as 1-2-3. See below for an example of some of the top apps customers are pushing to their devices today.
Manage App Licenses – App licensing and software inventory are critical in managing a successful app deployment, but they can be tedious without the right solution. The right solution is something that greatly increases visibility while streamlining the entire process. To accomplish this, Systems Manager not only removes complexities by combining inventory over many devices and device types (e.g. Windows, iOS, Android, etc.) but it also integrates with Apple’s Volume Purchase Program (VPP) and Google’s G Suite in order to simplify bulk licensing and distribution. In addition, Systems Manager alongside these solutions provides the ability to silently push apps to iOS and Android devices. This means easier management for administrators and less disruption for end users.
Containerization –Finally, there is a great need to decide on a strategy for containerization. This may sound complicated, but it comes down to one simple question: should managed apps and data be allowed to talk to unmanaged apps and data? In the Systems Manager world, if you don’t want private apps like an unmanaged Dropbox application or personal file storage to communicate with managed apps like a managed Box app or even a managed email account, then you want containerization. For an example of how simple something this powerful can be, see the configuration options for containerization in iOS below. It only takes deciding on checking or unchecking two boxes.
Hopefully this provided some insight into the simplicity Systems Manager brings to mobile application management (MAM).
To start an instant 30-day trial and see things first hand, click here.
Whenever a file is downloaded through a Meraki MX with Cisco Advanced Malware Protection (AMP) enabled, that file’s signature will be looked up against AMP’s extensive cloud database; however, the file’s evaluation may return as “unknown”. AMP is capable of retrospectively alerting administrators if such a file is later determined to in fact be malicious with the help of the global AMP cloud. This provides security teams with the necessary insight to take action to quarantine a threat before it spreads.
With our newly released support for Threat Grid, administrators now have the powerful option to send these unknown file types directly to the Threat Grid cloud for immediate analysis. Once received, Cisco Threat Grid will execute the file in a virtual environment and will then analyze the file for over 825 behavioral indicators that may suggest whether or not the file is malicious. If a file is in fact determined to be malicious, Threat Grid will immediately alert all network administrators, and armed with a new signature, AMP will also block any new attempts of the threat from being downloaded. What’s more, if the file is malicious, Threat Grid’s analysis results will also be distributed via the global AMP cloud so that all other subscribers around the world receive the new threat signatures. With record-breaking threats like the recent WannaCry outbreak, this is an important, powerful tool to have in any organization’s arsenal, and instrumental in contributing to the prevention of zero-day exploits around the world.
Example of a downloaded file that was initially permitted, but later determined by Threat Grid to be malicious
Example of a downloaded file that was initially permitted, but later determined by Threat Grid to be malicious
We’re incredibly excited to announce the availability of Threat Grid on the Meraki MX as it provides the absolute latest in dynamic malware analysis and a deep, beneficial integration with Cisco’s broader security services. Threat Grid for MX is available as an additional subscription to any Meraki MX* with Advanced Security license. To find out more, please contact your Meraki sales representative and ask about Threat Grid sample packs.
To learn more about this exciting new capability please visit our website or view our product video.
*Threat Grid is not currently available on MX400 and MX600 models.