How To Do DevSecOps for Kubernetes

In this article, we’ll provide an overview of security concerns related to Kubernetes, looking at the built-in security capabilities that Kubernetes brings to the table.

Kubernetes at the center of cloud-native software

Since Docker popularized containers, most non-legacy large-scale systems use containers as their unit of deployment, in both the cloud and private data centers. When dealing with more than a few containers, you need an orchestration platform for them. For now, Kubernetes is winning the container orchestration wars. Kubernetes runs anywhere and on any device—cloud, bare metal, edge, locally on your laptop or Raspberry Pi. Kubernetes boasts a huge and thriving community and ecosystem. If you’re responsible for managing systems with lots of containers, you’re probably using Kubernetes.

The Kubernetes security model

When running an application on Kubernetes, you need to ensure your environment is secure. The Kubernetes security model embraces a defense in depth approach and is structured in four layers, known as the 4Cs of Cloud-Native Security:

Read More: 350-801: Implementing Cisco Collaboration Core Technologies (CLCOR)

1. Cloud (or co-located servers or the corporate datacenter)

2. Container

3. Cluster

4. Code

Security at outer layers establishes a base for protecting inner layers. The Kubernetes documentation reminds us that “You cannot safeguard against poor security standards in the base layers by addressing security at the Code level.”

At the Cloud layer, security best practices are expected of cloud providers and their infrastructure. Working inward to the Cluster layer, cluster components need to be properly secured, as do applications running in the cluster.

At the Container level, security involves vulnerability scanning and image signing, as well as establishing proper container user permissions.

Finally, at the innermost layer, application code needs to be designed and built with security in mind. This is true whether the application runs in Kubernetes or not.

In addition to the 4 C’s, there are the 3 A’s: authentication, authorization, and admission. These measures apply at the Cluster layer. Secure systems provide resource access to authenticated entities that are authorized to perform certain actions.

Authentication

Kubernetes supports two types of entities: users (human users) and service accounts (machine users, software agents). Entities can authenticate against the API server in various ways that fit different use cases:

◉ X509 client certificates

◉ Static tokens

◉ Bearer tokens

◉ Bootstrap tokens

◉ Service account tokens

◉ OpenID Connect tokens

You can even extend the authentication process with custom workflows via webhook authentication.

Authorization

Once a request is authenticated, it goes through an authorization workflow which decides if the request should be granted.

The main authorization mechanism is role-based access control (RBAC). Each authenticated request has an HTTP verb like GET, POST, or DELETE, and authenticated entities have a role that allows or denies the request. Other authorization mechanisms include attribute-based access control (ABAC), node authorization, and webhook mode.

Admission

Admission control is a security measure that sets Kubernetes apart from other systems. When a request is authorized, it still needs to go through another set of filters. For example, an authorized request may be rejected by an admission controller due to quotas or due to other requests at a higher priority. In addition to validation, admission webhooks can also mutate incoming requests as a way of processing request objects for use before reaching the Kubernetes API server.

In the context of security, pod security admission might add an audit notation or prevent the scheduling of a pod.

Secrets management

Secrets are an important part of secure systems. Kubernetes provides a full-fledged abstraction and robust implementation for secrets management. Secrets are stored in etcd—Kubernetes’ state store—which can store credentials, tokens, SSH keys, and any other sensitive data. It is recommended to store small, sensitive data only as Kubernetes Secrets.

Data encryption

When you want to store a large amount of data, consider using dedicated data stores like relational databases, graph databases, persistent queues, and key-value stores. From the vantage point of security, It’s important to keep your data encrypted both at rest (when it is simply sitting in storage) as well as in transit (when it is sent across the wire). While data encryption is not unique to Kubernetes, the concept must be applied when configuring storage volumes for Kubernetes.

Encryption at rest

There are two approaches to encryption at rest. The first approach uses a data store that encrypts the data for you transparently. The other approach makes the application responsible for encryption, then storing the already-encrypted data in any data store.

Encryption in transit

Eventually, you’ll need to send your data for processing. Because the data is often (necessarily) decrypted at this point, it should be sent over a secure channel. Using  HTTPS, STCP, or SFTP for secure transit of data is best practice.

Kubernetes services can be configured with specific ports like 443 for HTTPS.

Managing container images securely

Kubernetes orchestrates your containers. These containers are deployed as images. Many Kubernetes-based systems take advantage of third-party images from the rich Kubernetes ecosystem. If an image contains vulnerabilities, your system is at risk.

There are two primary measures to safeguard your system. First, use trusted image registries, such as Google Container Registry, AWS Elastic Container Registry, or Azure Container Registry. Alternatively, you may run your own image registry using an open-source project like Harbor and curate exactly which trusted images you allow.

The other measure is to frequently scan images for vulnerabilities as part of the CI/CD process.

Defining security policies

Kubernetes and its ecosystem provide several ways to define security policies to protect your systems. Note that the built-in Kubernetes PodSecurityPolicy resource is deprecated and will be removed in Kubernetes 1.25. At the time of this writing, the Kubernetes community is working on a lightweight replacement. However, the current recommendation is to use a robust third-party project—for example, Gatekeeper, Kyverno, or K-Rail—as a policy controller.

Policies can be used for auditing purposes, to reject pod creation, or to mutate the pod and limit what it can do. By default, pods can receive traffic from any source and send traffic to any destination. Network policies allow you to define the ingress and egress of your pods. The network policy typically translates to firewall rules.

Resource quotas are another type of policy, and they’re particularly useful when multiple teams share the same cluster using different namespaces. You can define a resource quota per namespace and ensure that teams don’t try to provision too many resources. This is also important for security purposes, such as if an attacker gains access to a namespace and tries to provision resources (to perform crypto mining, for example).

Monitoring, alerting, and auditing

We have mostly discussed preventative measures thus far. However, a crucial part of security operations is detecting and responding to security issues. Unusual activity could be a sign that an attack is in progress or that a service is experiencing degraded performance. Note that security issues often overlap with operational issues. For example, an attacker downloading large amounts of sensitive data can cause other legitimate queries to time out or be throttled.

You should monitor your system using standard observability mechanisms like logging, metrics, and tracing. Kubernetes provides built-in logging and metrics for its own components. Once a serious problem is discovered, alerts should be raised to the relevant stakeholders. Prometheus can provide metrics monitoring and alerting, while Grafana provides dashboards and visualizations for those metrics. These tools, along with AppDynamics or countless others, can serve as effective Kubernetes monitoring solutions.

When investigating an incident, you can use the Kubernetes audit logs to check who performed what action at a particular time.

Source: cisco.com

Continue reading

How Well-integrated Tech Can Boost Your Organization’s Security

What Did We Find?

There was one main question we sought to answer around this key practice: Why would an organization want to integrate its security technologies with the rest of its IT architecture? Unsurprisingly, the main reason was to improve the efficiency of monitoring and auditing.

So with the help of our research partner, Cyentia, we sought to understand more about what types of integrations were most common, how those integrations were achieved, and how those factors played in to varying security outcomes.

Buy vs. Build

More than three quarters of respondents would rather buy security technology than build it themselves, especially when it comes to cloud-based solutions. When evaluating technology, the most successful companies prioritize integration with their current tech stack ahead of base product capabilities.

Figure 1: Common approaches to security tech integration among all organizations

Furthermore, if companies stick with a platform of products rather than point solutions, they are more than twice as likely to see successfully integrated security technologies. Yes, as we mentioned in the report, we’re fully aware that this bodes well for Cisco, who offers a well-integrated platform of security products. But, don’t forget, this was a double-blind study – the respondents didn’t know who was asking the questions, and Cisco didn’t know who was being surveyed.

Interestingly, we were surprised to learn there’s virtually no difference in security outcomes between those that buy products with out-of-the-box integrations and those that build integrations on their own. Just under half (~49%) of organizations using either of these approaches report strong integration levels.

It would seem for most organizations in most industries that there would be a greater benefit to out-of-box purchasing of products versus building their own. But, as it turns out, this is not the case. As noted above, the real differentiator was doubling down on a cloud-and platform-based solution, probably with a preferred vendor.

Improving Automation

We also wanted to know if having integrated solutions helped with desired outcomes, such as improved automation. Companies with well-integrated security technologies were seven times more likely to achieve high levels of automation for event monitoring, incident analysis, and incident response processes (4.1% vs. 28.5%).

Figure 2: Effect of tech integration on extent of security process automation

Of course, it’s not just about automation. If you have a well-integrated security stack, you can optimize the work your security and IT teams do, leading to other preferred outcomes including increased efficiency and employee engagement.

Narrowing Your Focus

If you’re looking to integrate your security stack, where should you initially focus?

We asked this question focusing on the five National Institute of Standards and Technology (NIST) functional areas (Identify, Protect, Detect, Respond, Recover). While integrating any of these five functions had positive outcomes, the Identify function had the biggest boost.  

Figure 3: Effect of integrating the NIST CSF Identity function on threat detection capabilities

So, What Do We Recommend?

With security teams stretched thin and ever-evolving threats looming, having a well-integrated security tech stack is a critical step for increasing efficiency and accuracy. But where does your journey towards integration begin?

Based on our survey results, I’d suggest that security teams should:

◉ Investigate automation opportunities: Increased automation is one of the key benefits of an integrated security tech stack. Look for opportunities to automate starting with functions that help identify assets and consider prioritizing those functions when determining where integration can be improved.

◉ Consider buying security technologies, rather than building them yourself: Companies are twice as likely to have a successful security program when they partner with preferred vendors to deliver integrated security solutions. Consider which vendors you regard as “preferred” and include them closely in your security strategy.

◉ Ensure purchasing requirements include security tech integration capabilities: Review your technology RFP requirements to ensure integration with your security stack is included as a core requirement in the new technology selection process. Ability to integrate should be weighted slightly higher than base product capabilities alone.

◉ Look for cloud-based security solutions: The data shows that it’s easier to achieve strong tech integration with cloud-based security products. Where possible, look for cloud security solutions to incorporate into your security stack.

Bottom line: integrated security technology is the best security technology. And I hope our continued research and corresponding recommendations put you on the path to better security outcomes.  

Source: cisco.com

Continue reading

Security Resilience in EMEA

What makes a successful cybersecurity program and how can organizations improve their resilience in a world that seems increasingly unpredictable? How do we know what actually works and what doesn’t in order to maximize success?

These are the types of burning questions guiding Cisco’s Security Outcomes Study series. In the second edition of the study, Cisco conducted an independent, double-blind survey of over 5,100 IT professionals in 27 countries. This article highlights data from the latest volume to focus on security resilience in the region spanning Europe, Middle East and Africa (EMEA).

The study focuses on a dozen outcomes that contribute to overall security program success. Four of them in particular are crucial for building resilience:

◉ Keeping up with the business (Security should enable, not impede)

◉ Avoiding major incidents (…And their business impacts)

◉ Maintaining business continuity (…Even when disaster strikes)

◉ Retaining talented personnel (You can’t stay on top when top staff won’t stay)

Assessing Security Resilience in EMEA

We calculated an overall resilience score for each surveyed organization based on their ratings for the outcomes listed above. The chart below compares that score across the three global regions. Organizations in the Americas scored a scant 1.7% better than the global average, while EMEA organizations landed about 2% below that mark. And the width of the gray error bars further diminishes those differences. Overall, we simply don’t see huge discrepancies in security resilience at the regional level.

Regional comparison of mean security resilience score

When examining resilience at the country level, however, differences begin to emerge. The next chart shows the proportion of organizations in each country reportedly “excelling” in each of the four outcomes related to security resilience. In other words, about 48% of firms in Saudi Arabia say their security program is doing a great job keeping up with the business. About 37% excel at maintaining business continuity, and so on. So, pick your country of interest and trace its success level across each outcome.

Country-level comparison of reported success levels for security resilience outcomes

Interested in comparing countries in the EMEA region across all 12 security outcomes beyond those shown here for resilience? Download the EMEA spinoff of the Security Outcomes Study, Volume 1.

Perhaps the most interesting aspect of this chart is the comparison it provides among countries. The reported success rates by security professionals in the countries at the top are roughly twice that of those on the bottom. And for the most part, each country maintains its relative position across all outcomes.

The obvious question here is what lies behind these apparent differences in security resilience among countries? Is Saudi Arabia really that much more resilient than Germany? Might German organizations have a more realistic grasp of what it means to be resilient and know there’s a lot of work left to do? Perhaps it’s somewhere between those possibilities or something else altogether.

Whatever the reason, the key takeaway here is that success rates for all countries indicate that organizations aren’t as successful as they’d like to be in the area of security resilience.

Improving Security Resilience in EMEA

How can organizations in the EMEA region improve those outcomes, thereby making their firms more resilient? That’s an excellent question and one we were eager to explore in the Security Outcomes Study. The study revealed five security practices—affectionately referred to as the Fab Five—that boost security program success more than any others. If you’d like a lot more information about the Fab Five and how to maximize their effectiveness, the latest edition of the Security Outcomes Study is the place to go.

The Fab Five: Highly effective practices for achieving security program outcomes

Before we examine how these practices improve resilience, let’s first check how well each country has implemented each of the Fab Five. The chart below mimics the one above for outcomes and is interpreted similarly. Once again, we see Saudi Arabia reporting the strongest implementation of these practices and Germany reporting the lowest. Countries shift around quite a bit beyond that.

Country-level comparison of reported success levels for five leading security practices

As with the outcomes chart, reasons behind these country-level differences are difficult to pinpoint. We suspect there’s a mix of maturity, cultural, and organizational factors at play. But hey, if you have thoughts, we’d love to hear them. Use #SecurityOutcomes on LinkedIn or Twitter to get our attention.

Remember that security resilience score we shared above for the regions? Great, because it’s coming back into play in this next chart. We wanted to test whether practicing the Fab Five actually improved resilience among EMEA organizations participating in our study. As seen in the chart below, that’s a definitive “Yes!”

Organizations that don’t do any of these practices well ranked in the bottom 25% for resilience, whereas those strong in all five reversed that standing and rose into the top 25%!

Effect of implementing five leading security practices on overall resilience score

Resilience has always been critical for cybersecurity. However, the last several years have really driven home the point that organizational defenders must be ready for anything. We hope this analysis demonstrates two things: 1) Organizations in the EMEA region have room for improving security resilience, and 2) It is actually possible to do so.

Source: cisco.com

Continue reading

Cisco Extends Service Discovery to WAN Using Bonjour and Adds App on Cisco DNA Center

Bring Your Own Device (BYOD) is now common in enterprises, especially in vertical industries like education and healthcare. So service discovery―the ability to automatically detect devices and services on networks and to set policies to safeguard networks―has become vital.  

There are many service-discovery protocols and techniques available that have been used for various use cases. Bonjour uses Multicast Domain Name System (mDNS) as its underlying mechanism to discover the services nearby. Apple developed Bonjour in 2002 to replace AppleTalk. Due to its open standards design and wide adoption, Bonjour/mDNS was integrated with Microsoft Windows 10, Google Android devices, and with Cisco Webex, making it a de facto standard. 

Bonjour was designed for use in a single network (with a single subnet or a single VLAN), such as a home network, where consumer devices like Apple TVs and printers could be discovered by Macbook, iPhones, and iPads. 

With many devices making their way into enterprises, Cisco has extended Bonjour functionality beyond single Layer 2 broadcast domains, to scale and avoid bottlenecks across services-rich enterprise networks and to optimize network bandwidth in the core and access layers. Additionally, Cisco Digital Network Architecture (DNA) Service for Bonjour on Cisco DNA Center also introduces a new dashboard application that shows service discovery gateways connected to the controller and the service instances. It allows network administrators to control which services can be shared across specific network segments. 

Local Area Bonjour

Casting an image or a video stream from an iPhone to a TV requires an iPhone to discover the TV using mDNS so that it can send that file or data to be casted on the screen. This deployment is called Local Area Bonjour. As shown in Figure 1, a switch could have multiple virtual LANs (VLANs) and by design each of these VLANs map to a different subnet. In such a scenario, if a service querier (e.g., an iPhone) is present in VLAN A, and a service provider (e.g., Apple TV) is present in VLAN B―which is a typical enterprise scenario―it will be unable to discover the service as the multicast from the querier won’t reach the service provider.  

Figure 1. Local Area Bonjour

Cisco introduced the Service Discovery Gateway feature, which enables mDNS to operate across Layer 2 boundaries or different subnets. An mDNS gateway can provide transport for service discovery across Layer 2 boundaries by filtering, caching, and extending services from one Layer 2 domain (subnet) to another. Prior to implementation of this feature, mDNS was limited in scope to within a subnet due to the use of link-local scoped multicast addresses.   

Wide Area Bonjour 

Wide Area Bonjour extended the concept of service provider and service querier in different closets or service discovery gateways that need to discover each other (Figure 2). The mDNS gateways are connected to and synchronize services with Cisco DNA Center. The service is shared when another gateway requests it.  

Figure 2: Wide Area Bonjour

Cisco’s mDNS gateway solution helps cache services and respond to service queriers on request, enabling the network administrator to configure service policies to control the sharing of services across subnets.  

Using Wide Area Bonjour, network administrators don’t need to bridge these VLANs across network segments anymore, so no service flooding is necessary, thereby reducing the multicast traffic in the core network. This saves a lot of network bandwidth, both in the core and access layers, making the network bandwidth available for other types of traffic while still enabling it to handle service discovery.  

The Cisco Wide Area Bonjour solution eliminates the single Layer 2 domain constraint and expands the scope to enterprise-grade, traditional wired and wireless networks, including overlay networks such as Cisco Software-Defined Access (SD-Access) and industry-standard Border Gateway Protocol (BGP) Ethernet VPN (EVPN) with Virtual Extensible LAN (VXLAN). The Cisco Catalyst 9000 series LAN switches and wireless LAN controllers follow the industry standard, RFC 6762-based mDNS specification to support interoperability with various compatible wired and wireless consumer products in enterprise networks. 

The Cisco DNA Service for Bonjour  

Cisco has now integrated Bonjour service discovery features into Cisco DNA Center. The new Cisco DNA Service for Bonjour features a software-defined, controller-based solution that includes a dashboard that shows the service discovery gateways connected to the controller and the number of service instances in a Wide Area Bonjour topology (Figure 3). It allows network administrators to control which services can be shared across which network segment.

Figure 3. Wide Area Bonjour Application on Cisco DNA Center

The new Cisco DNA Service for Bonjour enables end-to-end service-oriented enterprise networks that augment all the key benefits to zero-configuration mDNS technology. With services and feature-rich user devices proliferating on enterprise networks, Cisco DNA Service for Bonjour can help improve the ability of IT and end-users to access, manage, share, print, and synchronize data regardless of their network boundaries. The seamless integration and security provided by the solution is compelling, providing IT organizations with complete control of access security, role and location-based discovery, and management of devices across the enterprise network.

Source: cisco.com

Continue reading

Cisco UCS Unified Fabric now 100Gb end-to-end for X-Series

Since 2009, Cisco UCS Unified Fabric has been one of the key differentiators between UCS servers and the rest of the industry. Unified Fabric is the combination of data, storage, and management traffic on a single cable. This greatly simplifies your server and networking infrastructure and provides both CapEx (adapters, cables, switches) and OpEx (warranty, power & cooling, management) savings. Cisco’s unified fabric is a single cable that connects the UCS X-Series chassis to the fabric Interconnects

Read More: 700-150: Introduction to Cisco Sales (ICS)

In a redundant deployment, you reduce the number of cables and switches 5:2 – two switches/cables for data and storage and one for management.

12+ years ago, Cisco UCS first shipped with 10Gb when the rest of the industry’s standard was 1Gb. In March, we announced we were leapfrogging the industry again by making 100Gb standard for UCS X-Series vs. 25Gb for other vendors.

The Cisco UCS X-Series Unified Fabric consists of three components: VICs, IFMs, and 6500 Series Fabric Interconnects.

Cisco UCS Virtual Interface Card (VIC) 15000 Series

VICs (Virtual Interface Cards) are more than a NIC or an ordinary converged network adapter (CNA – Ethernet + storage). Other vendors offer NICs or CNAs, but none offer the full functionality of a VIC. The two key differentiators are the inclusion of management traffic and the number of virtual adapter interfaces.

Cisco UCS servers are configured via policies and templates. The VIC receives the configuration from Cisco Intersight and is pushed to the server. This removes the need for a server management network.

Virtual adapter interfaces come in two flavors – data and storage. These virtual adapter interfaces extend the network fabric directly to both servers and virtual machines via end-to-end network virtualization so that a single connectivity mechanism can be used to connect both physical and virtual servers with the same level of visibility and control. Each can have their own quality service, guaranteeing bandwidth and QoS thus providing optimal user experience. Cisco VICs supports more virtual adapter interfaces than any other NIC or CNA giving you the ability to tune and shape traffic to every application.

I’ll leave it to the data sheet to call out all the hardware features like low latency and kernel bypass for performance optimizations among others.

Cisco UCS VIC 15231 mLOM, 2×100 Gbps

Cisco UCS 9108 100G Intelligent Fabric Module (IFM)

An IFM is the connection point between the X9508 Chassis (and servers) and the Fabric Interconnect – either the 6400 or 6500 series. Our 2nd gen IFM ups the speed from 25Gb to 100Gb. Like its predecessor, each IFM has eight ports, and they are always deployed in redundant pairs. The amount of bandwidth is determined by the number of ports used. If you are looking to future proof but don’t need the full 800Gb per IFM, you just use fewer ports. As your needs increase, just use the remaining ports. 

Cisco UCS 9108 100G Intelligent Fabric Module

Cisco UCS 6536 Fabric Interconnect

The 36 port Cisco UCS 6536 Fabric Interconnect supports Cisco UCS X-Series, UCS B-Series, and UCS C-Series servers. It offers line-rate, low-latency, lossless 1/10/25/40/100 Gigabit Ethernet, Fibre Channel, NVMe over Fabric (NVMe/FC, NVMe/TCP, NVMe over ROCEv2), and Fibre Channel over Ethernet (FCoE) functions. The total switching capacity is 7.42 Tbps.

Of the 36 ports, the FI has 32 40/100-Gb Ethernet and 4 unified ports that support 40/100-Gb Ethernet ports or 16 Fibre Channel ports after breakout at 8/16/32-Gb FC speeds. The switch also supports two ports at 1-Gb speed using QSA, and all 36 ports can breakout for 10- or 25-Gb Ethernet connectivity and support FCoE.

Cisco UCS 6536 Fabric Interconnect

Putting Unified Fabric all together

The adage is a picture is worth 1,000 words. To save you reading 1k words, here is a diagram showing Cisco Unified Fabric and the entire UCS portfolio.

Click on me to make full size!

What can 5th Gen Unified Fabric do for you?

Unified Fabric will simplify your infrastructure and save you money. The architecture means there are few components to procure, install, power, and maintain. Less money spent upfront and less time and money spent over their life. This will increase your business agility and allow you to focus on adding value to your business vs. keeping the lights on.

Then add in the performance benefits that 100Gb line rate, low latency end-to-end solution provides for your applications and user experience. You will have increased the reliability, efficiency, and scalability of the network.

Source: cisco.com

Continue reading

An always-on strategy to find extraordinary talent for CX Centers Americas

Cisco is widely recognized for helping companies transform. To give our customers a solid foundation to achieve their digital transformations, we have improved our workplace, services, supply chain and security. Ours is a journey to drive workforce innovation, as part of our own digital transformation.

Recruiting extraordinary talent is essential to fuel our constant evolution. Within Cisco’s CX Centers Americas, our highly specialized Technical Consulting Engineers (TCEs) are our competitive advantage. The TCEs in CX Centers solve our customer’s biggest challenges. We do this through our technical expertise, a customer experience to count on, and innovation that puts intelligence at our customer’s fingertips. And we are constantly looking for team members to join our team.

CX Centers Americas Approach to Hiring the Best

We partner with Cisco’s Emerging Talent Recruiting and CX Academy (CXA) to bring the best talent to CX Centers. Our vision is to deliver an extraordinary customer experience. Our TCEs make that happen. We provide them with the tools and knowledge to excel in their jobs. Our training builds a solid foundation that allows them to have both technical skills and be customer obsessed.

Since our TCEs come from all walks of life, we want to make the best of their talent journey. We have designed two streams of engagement based on the population of the person interested in joining us: emerging talent and professional hires.

Emerging Talent

TCE (Technical Consulting Engineer) Graduate Program: After being recruited from universities and undergoing an interview process, new employees go through a six-month onboarding training supported by CX Academy. The TCE Graduate program runs two times a year, following typical university graduation dates. During their first six months at Cisco, we train the new hires from the macro to the micro level. New TCEs rotate through four different teams within a technology group before being placed on one of the teams to begin their team-specific training. Candidates are also exposed to other experts and leaders through activities including Executive Fireside Chats, Living Cisco’s Principles, Coaching Sessions, and more. We accept around 80 new hires annually with this program.

“CXA provided a challenging and collaborative learning environment that allowed me to expand my soft skills and develop acquired technical skills in the field of networking. I learned how to be a successful TAC engineer thanks to the work that my mentors, my trainers and my cohort put in to develop training materials that allowed me to capture the relevant content.”

—Mariana, TAC (Technical Assistance Center) engineer, TAC Collaboration Team in Richardson, TX.

Co-Op / Intern Program: After undergoing interviews, students are welcomed to the Co-Op for six months on a full-time basis, 40 hours/week. The Co-Op program runs twice a year in US with ~20 co-ops per cohort. 70% convert to the full-time Technical Consulting Engineer role post-graduation. Students start by learning the fundamentals of the TCE role, spending the first three months of the program supporting simple cases, and slowly increasing in number of cases taken and difficulty. All of it under the supervision of a mentor. At the mid-point of the program, the Co-Ops join the Technical Assistance Center (TAC) teams to learn one of the teams’ technologies and begin to support cases in the queue. Pre-Covid, Co-Ops spent the beginning of their experience in CX Labs, learning the basics of the hardware used to recreate cases.

The internship is a three-month summer experience, currently for returning Co-Ops only, in which they will return to the Technical Assistance Center (TAC) team they had previously supported.

At the end of the experience and depending on performance, the Co-Op will receive an offer to return as a future Co-Op, Intern, or receive a full-time TCE offer.

“Being a TCE Co-op was the best professional experience I have ever had and prepared me for taking on the role of a full-time engineer. Everyone I talked to and learned from offered help and wanted to see me succeed in my role.”

—Anthony, TCE (Technical Consulting Engineer) Co-op

Pre-Apprenticeship and Apprenticeship: The Apprenticeship program is the same as the Co-Op program; the difference is the population we source from. These programs are especially designed for those coming from any walk of life. Candidates could be in the process of achieving their Associates degree, switching careers, or exiting the military. We have partnered with Wake Tech Community College in North Carolina and Collin College in Texas to source candidates who are currently enrolled in a Cisco Certified Network Associate (CCNA) certification course. If these institutions have students who are interested in a TCE Apprenticeship, they join the pre-Apprenticeship to receive professional development sessions hosted by Cisco. After attending at least 80% of the professional development sessions and achieving the CCNA certification, candidates are eligible to apply and interview for the TCE Apprenticeship. The end goal for pre-apprentices is to become TCE apprentices and ultimately TCEs.

The apprenticeship pilot started in the Fall of 2021 and is planning to run twice a year. We started with five apprentices, all officially registered as apprentices with the state of North Carolina. There are also currently 30 pre-apprentices, with plans to enter apprenticeships, which started in March.

PEX (Practical Experience Program): PEX is a rotational program that provides individual contributors with their first opportunity to manage people. The Program is designed to give aspiring leaders practical, hands-on people management experience. Managers are responsible for managing a cohort of 5-10 new hires for the first 6 months of the 12- month CX Academy program. Responsibilities include onboarding of new hires, mentoring/coaching throughout the program, performance management of new hires, collaborate effectively with local and global team members, build relationships with stakeholders, and own the planning/delivery of projects.

Professional Hire

This track is for experienced professionals. It was created to standardize the experience of the new employee and includes a diverse range of activities for the new employee, the hiring manager, and the mentor to make the best of all recruiting steps for the first 90 days (about 3 months).

Source: cisco.com

Continue reading

Transforming Customer Experience with Cisco AI Chatbots

Chatbots are a rising support model. With the advent of artificial intelligence and machine learning, chatbots can often provide resolutions to issues faster and more accurately than human support agents. According to Business Insider, 40% of internet users worldwide prefer interacting with chatbots instead of human agents virtually. By 2024, Insider Intelligence predicts that spending on chatbots worldwide for consumer retail alone will reach $142 billion—compared to $2.8 billion in 2019.  It is now common to find chatbots on retail, healthcare, and corporate websites and mobile apps. Chatbots can be designed to provide different types of expertise and functionality. When properly trained, they are very good at providing answers to specific queries. They automate common tasks, reduce time to service, and increase efficiency and customer satisfaction. 

If a person cannot tell whether a response is coming from a machine or a human, then a bot has passed the Turing Test. The biggest challenge for chatbots has been understanding the nuances of human language, especially technical jargon.  With advancements in machine learning and deep learning with transformative algorithms like Bidirectional Encoder Representations from Transformers (BERT), chatbots now sometimes perform better than many humans in understanding written intent.  It’s also easier than ever to create chatbots, with minimal programming necessary. Simply provide examples of interactions and a bot learns for itself how to respond.  

The Cisco Networking Chatbot   

The Cisco Enterprise Networking team foresaw a need for a chatbot to streamline support work and make it more efficient.  The Cisco Networking Bot (cnBOT)  is designed to empower internal support personnel, customers, guests, and partners by providing digitized Cisco product information in an intuitive way. cnBOT has experienced overwhelming growth, with thousands of users and 10s of thousands of queries.  

The cnBOT is available on the web, on product support pages, via the cnBOT Webex Team Space, and via the Cocoa Bot interface. cnBOT is also supported by analytical modules and helps generate leads for product sales and migration services.   

The cnBot (Figure 1) is a cloud-ready product that uses microservices built with scalability in mind. Its features can be prototyped quickly and independently, and its reliability is unmatched because of its distributed processing architecture. As a native cloud application, the cnBOT has built-in resiliency.

Figure 1. Cisco Networking BOT Features

 

For an example of the cnBOT in action, a request for information about Cisco Catalyst 9000 Series software compatibility generates a link to the matrix shown in Figure 2 and other related links. 

Figure 2. Cisco Networking Chatbot Use Case: Cisco Catalyst 9000 Compatibility

Another example of the cnBOT in action is in response to a query about migrating from the Cisco Prime Infrastructure (PI) to Cisco DNA Center. A high-level migration task list is displayed (Figure 3) with a prompt at the end to do a self-guided migration. 

Figure 3. Cisco Networking Chatbot Use Case: Migration from Cisco Prime to Cisco DNA Center

Future Development 

The cnBOT started as an idea to facilitate Tier 2 workflow automation, reduce time to get critical information and provide a tighter integration loop with stakeholders — although the opportunity and scope can be much broader. Diverse use cases and different audiences can be served by the cnBOT.  We are working with multiple groups at Cisco to integrate their workflows into the cnBOT and looking for ways the chatbot can provide services through other bots at Cisco, including the CX Cloud bot, so customers can be provided with seamless support experiences regardless of the questions they ask.    

The cnBOT can be used for other types of communications, including voice input and output, like Apple’s Siri. It can also provide collaborate services like push notifications. Further investment will enable research into how customers use the product and how to mitigate pain points in their interactions. Longer-term, we anticipate developing many additional services for the cnBOT, including offering a standardized platform for easy integration.  

Chatbots are here to stay and will get smarter.  Bots in gaming have beat some of the best human players in the world with just a few hours of training. Machines are getting much better at understanding human language (sometimes better and faster than humans). More interactions with bots await us all, for greater efficiency and faster service that improves customer confidence in Cisco products and services.

Source: cisco.com

Continue reading