Harvesting Threat Intelligence with the SecureX Threat Response API

It is widely known that there are never enough resources to staff every Security Operation Center (SOC). Organizations are struggling to cope with the massive number of new attacks, which makes it ever more important to stay up to date with the vast number of threats that could be just around the corner. Enter Cisco Talos, Cisco’s threat intelligence research group and a well-respected source for threat intelligence information.

What is Threat Intelligence?

According to Wikipedia, “cyber threat intelligence is information about threats and threat actors that helps mitigate harmful events in cyberspace”. Wikipedia also points out that the “sources include open source intelligence, social media intelligence, human intelligence, technical intelligence, or intelligence from the deep and dark web”.

There are different forms of threat intelligence:

◉ Tactical: this type of intelligence can be used to identify the threat actor of a specific attack. Examples can be Indicators of Compromise (IoCs) like IP addresses, domains and file hashes.

◉ Operational: this type of intelligence focuses more on the Tools, Techniques and Procedures (TTPs) of the attacker.

◉ Strategic: this type of intelligence focuses more on high-level cyber risks and can be used to create a strategy for a company.

What is the SecureX Threat Response API?

The SecureX Threat Response platform is a tool that aggregates and correlates the capabilities of many Cisco and third-party security products (called “modules”). This tool can be leveraged for “threat hunting” in a customer’s environment to help keep their environments secure. It does this by connecting to the API’s of the various products, and by doing so is able to retrieve information. This process is called “enrichment.” Enrichment focuses both on internal sightings and external threat intelligence. At the same time, Threat Response can take actions in a subset of the connected products. This process is called “response”.

Some products can only provide enrichment, while others can do both enrichment and response. Cisco Security customers can use Threat Response to quickly identify a root cause of a cyber-attack, by using any text (containing IoCs) as an input. This text can then be enriched both from internal monitoring modules (“Do I have any infected hosts?”), and from threat intelligence modules (“Are these IoCs bad?”). And it enables customers to quickly take response actions to remediate the threat.

The SecureX Threat Response relation graph graphically shows how the observables in an investigation are connected.

If you’re a Cisco Security customer, guess what … You have access to Threat Response at no extra cost. The Threat Response APIs can be leveraged to automate a big chunk of the threat hunting process, and mainly the enrichment process.

How to harvest threat intelligence, and hunt the threats?

The internet contains many free sources of threat intelligence that can be used in addition to the Cisco Talos feeds. Using the SecureX Threat Response API, it is possible to harvest this and discover internal security events. This process is what was earlier described as “enrichment”, where both internal and external modules are checked for hits. There is a big community out there that shares new IoCs related to new cyber-attacks and malware campaigns.

So how can I harvest my threats?

Below are two examples that take a free source from the internet (blogs and Twitter) and parse them for IoCs. Both scripts then check for “target sightings” and automatically adds IoCs to SecureX Casebook. If there are any hits on internal targets, it will add a “HIGH PRIORITY” tag to the Case. The scripts will also send a Webex Teams alert to a configured Space (e.g. the Space used by a SOC). Check out the links below to find out more!

1. Searching threat intelligence blogs

The Cisco Talos blog is a perfect example of one of those free sources of threat intelligence that can be found on the internet. Their blog highlights threats and other information they find on a regular basis. However, who has the time to read all these blog posts, search through all their security tools for hits, and take action on them? Using the Threat Intelligence API, I was able to search the Talos blog (and others!) and pull out the exact information I needed to remediate my threat. Find out how on my DevNet Automation Exchange post:

2. Scouring Twitter Hashtags (e.g. #OPENDIR)

You can do a similar things with Twitter. The #opendir Twitter hashtag is used by many threat intelligence researchers to post their findings on new threats. This is a perfect example of one of those free sources of threat intelligence that can be found on the internet. Matching this information source with the connected Threat Response modules, gives you relevant hits to help protect your organization for unwanted threats.

Some example Tweets from the #opendir hashtag.

These are just two examples of what you can do with these awesome API’s.

Continue reading

Cisco and IBM Security Simplified: Mapping the Story

“The more things change, the more they stay the same” can be true even with security.

Although our security tools and workflows have certainly become much stronger over the years, some challenges haven’t changed:

◉ Businesses still worry about their intellectual property being compromised and/or leveraged for nefarious use.

◉ Deploying a secure defense is still complex; many companies can find themselves deploying 50 to 100 different tools from 50+ vendors in an attempt to protect their businesses.

◉ There is still a lack of qualified security personnel, which becomes even more problematic given the large number of vendors and tools that must be managed.

◉ It is still difficult to explain the toolsets and processes required to secure a modern enterprise.

Expanding on that last point, a year ago, we began working with IBM to find a way to explain joint Cisco and IBM security value propositions in a way that is easier for our customers and partners to understand.

We’ve been told by customers that if we can reduce their vendor count from 50+ vendors to “something you can count on your fingers and toes,” it would improve not only technical efficiency for their response teams, but also offer operational efficiency to legal and finance teams through contract simplification. In response, over time and through a number of integrations, Cisco and IBM have jointly developed a comprehensive security story, greatly simplifying your vendor and tools landscape. Now, while I can’t say in good conscience that Cisco and IBM can address all your security concerns, integrated Cisco and IBM tools and services can meet a majority of your security needs and our technology ecosystems can fill in the gaps.

The result of our efforts to better explain these Cisco and IBM security value propositions is what I call “subway map” journeys.

Mapping a customer’s security journey with integrated solutions

Initially, we began by looking at the top three areas of concern for our customers:

◉ Insider threats: threats living inside the network

◉ Ransomware: malicious software that blocks system access

◉ Compliance: the need to meet and maintain compliance requirements

When customers explore how to protect their businesses against these three use cases, they typically deploy a number of tools, which can be viewed as subway stops along the security journey (Figure 1).

Figure 1: Security journey subway map

The three colored lines in this subway map are aligned with each use case. In each journey, the light blue and dark blue stops represent Cisco and IBM products, respectively. Also notice the subway car moving through the stops. The shortage of security personnel means many of our customers rely on services from Cisco and IBM to help transport them to their destination, whether through consulting before an engagement, integration services during deployment, or managed services afterward.

You can look at the briefs for Ransomware, Compliance, and Insider Threats workflows on the IBM and Cisco Security Solutions page, but let’s take a quick look now at Insider Threat and discuss how it’s been impacted by the ongoing pandemic.

Insider threats

In the case of insider threats, the primary concern is that an employee or other insider has gained privileged access to the network and can obtain company secrets or customer data. In response, a security solution must:

◉ Block causes of a potential compromise

◉ Restrict access to limit the scope of loss if the network is compromised

◉ Quickly identify and prioritize threats

◉ Detail the response plan so operators can move quickly to mitigate damage

As shown in Figure 2, the integrated Cisco and IBM defense against insider threats includes the following tools:

◉ Cisco Identity Services Engine (ISE) orchestrates who is using the network and creates policies for where they are allowed to go.

◉ Cisco Firepower Threat Defense (FTD) provides enforcement points and detection through NGFW/NGIPS functionality.

◉ Cisco Stealthwatch provides visibility into traffic on the network—so we know policies are being observed—while also providing insight into what policies could/should be.

◉ Cisco Advanced Malware Protection (AMP) enables file inspection across endpoints, the intrusion prevention system (IPS), email, and the web (ESA/WSA) to reduce points of compromise.

◉ IBM QRadar combines alerts from multiple sources and analyzes user activity to detect malicious insiders.

◉ IBM Resilient helps companies understand and orchestrate a response plan across people, process, and technology.

◉ IBM Guardium activates data loss prevention (DLP) to further the solution through classification of sensitive assets and data protection.

Figure 2.  Insider threats subway journey

Going forward

Stay-at-home orders have created a new set of challenges for many businesses during the pandemic. While the tools mentioned in the previous section remain relevant to combating insider threats, the relative importance of technologies such as Cisco Duo for MFA, Cisco AnyConnect for VPN access, Cisco AMP4EP, and Cisco Umbrella in protecting remote and mobile workers has increased. The changes in the way our customers leverage our tools also impacts the way we focus integration surface between our companies. As you may have guessed, consumption of AMP4EP logs in QRadar has is an area we’ve seen increase and we’ve received great feedback on the recently published Cloud Security app for QRadar (Figure 3) as well.

Figure 3.  Cisco Cloud Security Dashboard in QRadar

In addition, as many of you have heard by now, Cisco has been focusing heavily on improving usability and workflow for customers leveraging our tools. That work has culminated in the recently launched Secure X tool. I’m happy to say that we have integrated Secure X into QRadar, so that customers can get hover-over information from Secure X directly in QRadar and also pivot into Secure X for additional drill-downs and investigation details.

Continue reading

Cisco Meeting Server 3.0 Feature Release

Premise-Based Conferencing Option with Cisco Meeting Server 3.0

“Going to the cloud” seems to be the talk of the town; however, the cloud is not everyone’s cup of tea. If that’s your case, we hear you, and we care about you. Cisco continues to offer a premise-based conferencing option just for you.

Let me tell you about our latest Cisco Meeting Server 3.0 feature release.

Just because you are not on the cloud, doesn’t mean your platform can’t be like the cloud. Cisco is working hard to align user experiences between Webex and CMS in order to simplify scenarios where customers use both. With this new release, we have a greater number of concurrent web app sessions, new web app in-meeting controls, and branding capabilities to give meetings your companies look and feel.

Better Meeting Experiences

The engineering team has been hard at work delivering agile feature releases every four months, with features you can use now while working remotely or from home. We are also continuously working to keep CMS a user friendly and intuitive platform.

Scalability – CMS extends its industry-leading scale with the web app. The web app scales to the same capacity as SIP calls on the CMS callbridge for internal calls and calls over a VPN.

Web App – Anyone can join a meeting quickly without installing anything by using the web app powered by WebRTC technology. With web app, users can create, join, and manage their meetings using their preferred browsers including Chrome, Firefox, Safari, Edge, or Yandex. New in-meeting features with the latest release include:

◉ Add/drop participants
◉ Mute others or all
◉ Branding
◉ Start a recording or streaming session
◉ Name labels
◉ Lock / unlock
◉ Making participants important

More Advanced Features with the 3.0 Release

The 3.0 release also brings more advanced features like separate windows for video and content to allow users to use two screens or just to optimize how they use their desktop. Below is an example of branding now available with the Meeting Server web app.

Self-management – Administrators can provision templates allowing users to create their own spaces based upon admin defined templates. Other options include setting PIN’s for hosts or guests and adding additional members to the space.

Smart licensing – This release also changes licensing, where Cisco Meeting Management (CMM) is required with all deployments for licensing usage reporting, plus integration with Cisco Smart Licensing.

Smart licensing is a new way of thinking about licensing. It can be applied to all Cisco products and is now available through CMM for CMS clusters. Smart licensing simplifies managing licensing for CMS, which means no more license files must be applied to servers. It provides key information about software entitlement and utilization in one centralized process. CMM will be mandatory for all new customers. Smart Licensing is required for new customers, optional for existing customers.

TMS - Cisco TMS provides centralized control for on-site and remote video systems and a deployment and scheduling system for your entire video network. TMS for scheduling now supports Oath authentication with O365 & Exchange hybrid deployments. TMS for higher education customers allows CMS recording to be configured when scheduling with the help desk.

In Conclusion

All of these new Cisco Meeting Server features gives your company the tools you need for getting business done, weather meeting in the office, from home or on the road. Existing customers with valid support contracts can find this new version on the software download center.

Cisco Meeting Server Web App – Feature List Comparison

Continue reading

Renown Health: Supporting patients during a global crisis

Last week you read about Reno, Nevada’s Renown Health’s recent upgrade to Cisco Catalyst products including switches, access points, and controllers. When I spoke with Dustin Metteer, IT Manager at Renown Health, he also explained that they’ve developed new safety protocols for COVID-19 and have built out tented testing centers and new field hospitals to support a potential influx of patients from across the state.

No visitors, no problem: filling the gap with technology

With strict protocols to ensure the safety of all in its facilities, no visitors are allowed at Renown Healthcare hospitals. Patients are often quarantined by themselves for extended periods of time and can get lonely. To help combat this loneliness, the hospital purchased hundreds of Apple iPads and handed them out to different departments to allow patients to communicate with their families.

Something I didn’t discuss with Dustin, as it didn’t make any difference in their decision to offer this gesture of kindness, is Cisco’s wireless partnership with Apple. Cisco and Apple have partnered to provide a better overall wireless experience to end users and IT managers, and this equates to better connectivity for users and improved troubleshooting data for engineers to solve issues faster. A win for all.

Standing up testing sites and field hospitals

For hospitals across the world, COVID-19 has meant preparing for a worst-case scenario should they move beyond capacity. To provide safe testing away from the main hospital building, Renown Health started with a single parking lot tent testing site. To connect the tent to the hospital network and its applications, Dustin and team ran a fiberoptic cable out to the tent, plugged in a Cisco Catalyst 9300 UPOE+ switch and instantaneously had connectivity and 90 watts of power per port for Cisco IP phones, Cisco access points, and a handful of desktop computers, with room to add more. This has now been replicated multiple times as needed across their other hospitals and urgent care facilities in the system.

The Big Ask

Following the initial rollout of tented testing centers, Dustin received a call about building out a temporary field hospital.  As Dustin explains, “We got a big ask, they wanted us to convert our parking garages into field hospitals.” This ask included designing a network for a facility that could house up to 2100 beds to care for those infected with COVID. If you’re familiar with a modern hospital room, you know they include lots of connected devices for monitoring, alerting, and communicating with staff. To support this need, the final design consisted of Cisco POE switches, Cisco access points and wireless controllers, and Cisco IP phones. The deadline: two weeks.

With not much time to make this happen, Dustin pulled together some spare equipment, mapped out and designed the network, and worked tirelessly to get the hardware deployed, software updated, and all his policies set. He had 14 days but completed the task in just 10. And while Dustin was working on the network side of things, he didn’t forget to give a shout out to the construction crew and electricians, and especially the Army Corps of Engineers. “They wrapped the entire garage, inflated it, brought in HVAC, all kinds of stuff, just great work.”

Repurposing old equipment gets the job done

The network that Dustin deployed in the parking garage includes five Cisco Catalyst 9300 UPOE+ switches and 30 Cisco Aironet 3702 access points. Giving a nod to his appreciation for the latest gear, Dustin says, “We had to use what was available quickly. I would’ve like to have used the Catalyst 9120 AP’s but we had to make do with what we had.”

Because Renown had recently gone through a refresh at several of their hospitals, they had equipment on hand that was already spun and ready to go. This made the job go a lot smoother and reduced network equipment expenses for the field hospital.

Renown is continuing to support COVID patients and as the disease ebbs and flows, the hospital will adjust its facilities and do its best to make space available to care for its patients across the state. This might include adding new field hospitals, testing sites, and other areas to support patients and staff during the pandemic.

Soapbox time

In closing, I’d like to say that I can’t wait for this horrible disease to be done and over with so we can all get back to our regular lives. That said, I find the work we do together as humans inspiring, especially when we work together for the betterment of mankind. Hearing Dustin’s story gives me hope: to hear what’s possible, to hear that a parking garage can be converted into a fully functioning hospital in less than two weeks, to know we will get past this pandemic and that technology will help play a major role. I’m an optimist, I’m also logical, and I know that it will take a lot of work, dedication, and an enduring effort to get us back to where we once were.

Source: cisco.com

Continue reading

The Transformation of Software Testing

Traditional development and testing cycles have been a limiting factor for increasing the speed of creating and releasing new functionality as well as improving the quality of final releases. When much of a development team’s time is taken up with the looping, iterative cycle of design-develop-test-debug, a lot of creativity gets squeezed out of processes and people. Longer development cycles prevent new features—especially those specifically requested by customers—from being released on a timely basis. When customers have limited insight into how those features are being designed and implemented, they can be reluctant to implement them without extensive and time-consuming testing.

A trickier legacy issue to address is that IT buyers have lost trust in existing software development processes to deliver high quality code in dot zero releases. Instead they wait by default for future point deliveries, expecting more acceptable quality before even considering testing a release. Resolving this trust issue is a root driver of the transformation of testing.

We discussed the necessary shift in mindset required to digitize software development by making every person a developer and democratizing the entire process. We also touched on the value of integrating testing developers into the early design and develop stages. In this second post, we will examine in more detail this shift in testing to understand how it transforms the entire development cycle to the benefit of customers as well as developers.

Our goal in the Cisco platform independent group, which provides routing and control plane protocols and DevOps tools to the XE, XR and NX software development teams, is to digitize and transform processes and skillsets to create a hyper-efficient development organization. In particular, we are integrating the development of unit, integration, feature, system, and solution tests into the early stages of the development cycle with real-world use cases based on diverse customer network hardware and software configurations and topologies. How do we capture this detailed customer information? We listen. We share. We communicate.

Bidirectional Communication with Customers Critical in Early Development Stage

We are engaging customers much earlier in the development lifecycle with a goal to build a bidirectional communications channel between Cisco development and customers. First, we listen to understand customer requirements, topologies, and traffic patterns and feed those parameters into our design documents. We request customers’ device configuration files so we can prepare test plans incorporating an appropriate mix of “live in the field” hardware and software environments. We then verify with customer IT teams our design specifications to ensure a mutual understanding of goals. By providing insights into feature functionality and sharing test plans, customers can better prepare for implementation before the final release. Customers can also share their proposed test plans with our teams so that special use cases can be incorporated into our test plans as well.

Cisco customers have been eager to participate in early engagement opportunities to provide real-time feedback on specific feature designs and implementations. A participating customer related to our teams that the recent collaboration with Cisco Engineering “…was fruitful as it ensured that Cisco’s implementation of a specific feature was matching our expectations. Early engagement helps us understand new features so we can create successful design documents as well as train our certification teams. This early collaborative process also helps our team avoid ‘working as designed’ surprises during our testing.”

These collaborations among Cisco development teams and customers result in a reimagining of test design and procedures that permeate the development lifecycle.

Reimagining Testing Throughout Development

As we’ve previously discussed, within our platform-independent teams, everyone is a developer—from solution architects and designers to coders and testers. Each role plays a hand in ensuring the solutions and tools we build meet our customers’ requirements—whether internal teams or external enterprise IT organizations.

One key method of transforming testing efficiency and completeness is to integrate developers into the process who have in-depth experience with customer implementations, configurations, and troubleshooting. They participate upfront in the design stage to ensure that new features will work in real-world brownfield as well as greenfield environments. This change makes it possible to evolve from thinking primarily in terms of individual features that are designed, developed, and tested in isolation, to a customer-oriented solution approach. While each feature is coded with specific functionality by design, each must also be implemented as part of a complete networking ecosystem. Applying this philosophy not only helps identify unintended feature interactions, but also moves defect discovery to much earlier in the development cycle, in effect flattening the curve of found defects throughout the development cycle—a primary goal of testing transformation.

New features are not the only testing points to emphasize during the design phase. Since the main “users” of networking software are highly-trained technical professionals, serviceability is key to keeping them productive. For example, interfaces providing data such as telemetry and error codes, as well as CLI formats, are designed from the technical users’ point of view. In design documents, we consider how to expose sufficient debug information to enable faster problem resolutions, but without overwhelming technicians with irrelevant details. Here we are applying machine reasoning to assist in triaging issues. Ease of configuration of network devices and Day 2 management are also critical considerations for testing usability and serviceability. Training and automated checklists ensure that developers are abiding by serviceability guidelines and applying serviceability measurement to code during development.

New software releases are also scrutinized to minimize any unexpected changes in default behaviors. From release to release, behavior testing ensures that:

◉ Software doesn’t consume more memory or processing capacity than in a previous release unless a new feature requires it and is thoroughly documented to prepare the customer.

◉ New releases are backward compatible with supported hardware and software.

◉ Scale and performance do not degrade but stay consistent or improve.

Ultimately our goal in reimagining testing is to build a lasting bridge to quality to ensure our customers have trust in each and every release. While we have always performed intensive feature testing to validate functionality, integration, scalability, and usability, we are emphasizing a significant focus on solution level testing to ensure high levels of performance, interoperability, reliability, security, and conformance. Combined, these layers of testing will provide greater assurance that releases will perform as expected in a multitude of customer environments. We are building this bridge to quality with a unified development infrastructure for testing.

Unified Development Infrastructure Increases Automation and Consistency

Software in the process of being coded is often tested in virtual testbeds that can be quickly modified. This usually works fine for unit and integration testing. However, the further along the development cycle, the more complex the testing and interactions with the environment. Virtualized testing may not uncover all the issues that will be discovered in real-world configurations.

To address this gap, we are building flexible testbeds based on real hardware—routers, switches, servers, access points and software—that mimic real network deployments and operations. Since testbeds are based on a common infrastructure and environment, they enable reuse, code sharing, and complimentary software testing. Unifying topologies and infrastructure in development and testing improves efficiency by uncovering issues earlier in the cycle.

The next phase, already in progress, is to create “topology on demand” testbeds that enable developers to design tests based on a variety of environments and have them automatically configured, based on network devices customers are actually using. We are also creating new tools to automate whole testing processes with reusable Test Blocks. These will enable developers to pick and choose from a library of pre-constructed tests. In turn, the tests are run with automation tools that perform the processing and recording of results. The testing process becomes more of an intellectual design exercise compared to manually assembling and running test after test with slight variations—a boon for developers working on tight timelines.

Transformation of Software Testing Benefits Developers and Customers

Reimagining and transforming the development testing cycle is paying off at Cisco in multiple ways. Internally, new tools for automating testing processes are making work more efficient and more engaging for developers at every stage of the software cycle. As we involve customer teams earlier in the development cycles, they are regaining trust in software release readiness and are willing to deploy new solutions sooner after release with more confidence.

Continue reading

Introducing the Cisco C240 SD M5 Server for the Performance Edge

Supporting applications at the edge with high-performance, easy to manage UCS C240 SD M5 Server

As more data and processing needs exist and are growing rapidly at the edge, providers and customers are exploring methods to avoid the bandwidth, latency, and overall costs of backhauling content to the traditional data center. Instead, the industry is moving towards enabling the more intense computational needs closer to where this data and content is gathered and presented.

According to IDC (1), 50% of new enterprise IT infrastructure deployed will be at the edge by 2023, and there will be an 800% increase in the number of apps at the edge by 2024. The industry is already looking for innovative methods to uniformly operate in this greatly scaled out environment.

We talked with many customers looking at these needs in areas such as service providers, hosting providers, enterprise branch, retail, defense, and many others, they have shared some common requirements:

◉ Solution optimized for a compact and tactical environment

◉ Simple on-boarding to management and orchestration tools by non-IT personnel

◉ Autonomous operations, with an ability for simple periodic updates

◉ Easy access and maintenance by non-IT personnel

◉ Performance that traditionally resides within today’s Data Center

◉ Enhanced security to operate within shared-use multi-access facilities

◉ Flexible options along with global 24×7 support

Cisco used these customer requirements to guide us as we developed a new UCS server platform for our customers. Our teams have been working hard on this problem and we are excited to announce the new Cisco C240 SD M5 server.

Introducing the Cisco UCS C240 SD M5

The Cisco UCS C240 SD M5 is available today and delivers a performance edge solution integrated with our Cisco Intersight offering to allow the same advantages in edge that existing Cisco customers consume in their data centers today.

The Cisco UCS C240 SD M5 delivers the following key capabilities for customers:

◉ Simplicity: Easy deployment and connection to network and power

◉ Turnkey: Simple onboarding into already defined policy

◉ Cloud or Virtual Appliance Managed: Simple Intersight claiming, Cloud or Connected/Private Virtual Appliance

◉ Economic: Match workload density needs to ratio’s only seen inside traditional DC with full performance – while fewer device touches and full Intersight management means reduced operational costs

◉ Future Proof: Standard peripherals and accelerators supported as rest of UCS line

◉ Agile: Intent based Intersight template definition of many edge sites from a single policy

◉ Complete Stack at Edge: When combined with HX and HXAP (both of which will be available late 2020 on the C240 SD M5) you have platform for full stack management to match storage, SD-WAN, servers, network all in a coordinated fashion

Optimized for a compact and tactical environment

The Cisco UCS C240 SD M5 is built for environments within and outside a traditional data center with some key points below. The C240SD M5 Server:

◉ Can be stacked up to 4 high without racking – or in 2 and 4 post racks

◉ Can be installed against rear wall with minimum 6” rear clearance

◉ Is just under 22” deep

◉ Can be powered by 120/240VAC or -48VDC

◉ Users can connect 2 nodes together directly with 10GE cable for workload live-migration

◉ Can be deployed with 1 or 2 Intel Xeon SP processors (configuration options will change)

◉ 24 DIMM slots supporting up to 256GB DDR4, or add 128/256/512GB PMEM modules to a maximum of 9TB

◉ 2-6 SAS/SATA/NVMe Drives, 2 M.2 Drives

◉ 2-6 PCIe slots (Gen3 with 2 x16, 4 x8)

◉ Will have future NEBS L3 qualification

◉ Unit has optional internal M.2 boot drives

◉ Has a tamper-evidence device that will raise alarms in multiple management systems

◉ FCS operation up to 10,000 ft, testing in progress to 13,000 ft

◉ FCS temp range from 10-40C, testing in progress to 50C (and peripheral options come into play)

◉ Shock in operation a 10g, and non-operational to 20g

Simple on-boarding to management and orchestration tools by non-IT personnel

In order to gain the advantage of remote installations without IT staff travel, Cisco has invested in methods to ease the onboarding of the C240 SD M5 both in situations where a pre-staging can be done, and also developing a low-touch deployment that will be allow direct shipments to remote sites. These methods will allow remote staff who have limited compute expertise to perform an installation of the Cisco edge solution. Some key elements include:

◉ Staging Intersight pre-claim today

◉ Intersight onboarding directly by non IT remote staff in near future

◉ Remote config setup, validation, and OS installation via policy

◉ Operational analytics

In summary the customer can stage at a partner today, units for global deployment, or in near future just deploy at these global locations with no staging required. All state to be installed on that server (config, options, OS/Hypervisor, Analytics, etc.) can be done not only remotely – but in the policy already defined within Intersight.

Autonomous operations, with an ability for simple periodic updates

In many of these types of edge deployments, having a model that is not connected to the cloud is a mandatory element. Cisco has many deployment models starting with simple stand-alone device management through our Cisco Integrated Management Controller that can be configured via multiple scripting and API methods. To take this further, based on our customer requirements we have developed the Intersight Connected Virtual Appliance which maintains a relationship with Cisco for real-time analytics and support, or the Private Virtual Appliance that has no connectivity back to Cisco. The latter provides isolation in the customer environment much like perpetual isolated software components common today.

To allow a capability of keeping updates for latest support and features ,the connected appliance can operate disconnected for up to 90 days – when the connection can be re-established, or in the case of the private appliance disconnected for same duration before customers are asked to update the appliance via a downloaded package.

Easy access and maintenance by non-IT personnel

The C240 SD M5 has a key advantage of all front access, where only rear components are the redundant fan modules. The components allow for easy replacement with easy access should maintenance be required.

Performance that traditionally resides within today’s Data Center

In many edge platforms today, the processing and peripheral/storage needs are much smaller for far edge points of the environment. Using those platforms to address the performance needs of hosting workloads, processing of data and video, transcoding, etc. are forcing higher processing and peripheral needs into the space between DC and edge. The Cisco UCS C240 SD M5 fits into that space and offers the performance of the full suite of most Intel Xeon SP models, Intel N3000 FPGA devices, nVidia T4 devices, up to 6 PCIe slots (2 x16), SAS/SATA or in combination with 6xNVMe.

As customers look to deploy SD-WAN solutions that include edge sites, methods to store large amounts of data where it is generated at the edge, process that data at the edge, our solution when combined with HyperFlex and HyperFlex Application Platform in the coming quarter will provide a full-stack solution to those locations with a single point of management and analytics.

Enhanced security to operate within shared-use multi-access facilities

As the data, business processing, and key Intellectual Property move outside the well-defended DC into these edge locations, the ability to secure these elements moves from an over the top add-in into a integrated strategy. Cisco UCS C240 SD M5 bases our security in our Cisco ACT2 technology that validates the hardware, the booting process, all firmware components up the stack. Cisco also supports Self Encrypting Drives in this solution, so that a unit will brick if removed. Cisco also includes tamper sensing within the solution that will allow central alarming.

Flexible options along with global 24×7 support

Customers we have talked with envision using the C240 SD M5 offering in combination of bare metal workloads, container workloads, standard virtual server hosting, Cisco HyperFlex solution, and more generally in a variety of storage heavy or PCIe dense deployments.

Cisco has multiple methods in the C240 SD M5 for sharing support information with Cisco TAC, including the fully connected TAC offering inside Intersight. All of the benefits of Cisco Intersight from an infrastructure automation and orchestration perspective are available to the C240 SD M5 at launch.

Customer Focused, Operate at Scale

Customers desire a platform for performance edge needs that is agile, simple, and economic. The new Cisco UCS C240 SD M5 delivers on that promise by providing a turn-key platform that is simple to deploy and operate and reduces the burden of IT staff. Future options for new acceleration technologies, driven by Intersight intent based policy and centrally managed will remove significant roadblocks to a modern performance edge. Operating at the scale of thousands or higher is much more straightforward with the UCS C240 SD M5 and Intersight together.

Continue reading

What happens to the Cisco Live Network Infrastructure when the conference goes virtual?

This is a question the Technology Experiences Team (TechX), Cisco’s dedicated team of infrastructure engineers and project managers, asked themselves this year. When our annual, in-person conference suddenly went virtual, it rendered our hardware a little redundant. So, what do we do with the technology we’d usually deploy for our customers at events?

TechX is chartered with the support of events and trade shows throughout the calendar year. It is our fun and often exhilarating task to implement Cisco’s technologies and sometimes our very latest solutions. Supporting our customers, event staff, and partners to host Cisco Live, and building an enterprise class network for 28,000+ people in just a few days is certainly an undertaking.

With no physical events this year, all that amazing Cisco technology is suddenly useless, right? Well, fortunately not. My job within the team is to build out and support the Data Center (DC) for our shows. The DC is home for all those applications that make the event and supporting it a success. Our applications portfolio includes: Cisco Identify Services Engine (ISE), Cisco Prime Network Registrar (CPNR – DNS/DHCP), Cisco DNA Center, virtual Wireless LAN controllers, FTP, Cisco Network Services Orchestrator (NSO), Data Center Network Manager (DCNM), vCenter, various flavors of Linux based on our Engineers preference, NTP, Active Directory, Remote Desktop Services, Application Delivery Controllers (ADC), Cisco Video Surveillance Manager, Grafana, NetApp Snap Center, Ansible hosts, Mazemap Lipi server, Find my Friends server, web hook servers, Database hosts, and the list goes on.

What did we do with a DC that supports all of those wonderful applications you may well ask? Well, we did two things. First we deployed Folding@home virtual machines, which as many of you well know is a distributed network of compute power using almost any machine to crunch numbers, helping scientists at Stanford University work toward cures for diseases. What better use of a large Data Center? Not only are we repurposing our infrastructure instead of retiring it, we’re doing our part to help with a healthcare crisis. In fact, Cisco as a whole is using its compute power across the company to contribute, and you can see our progress with the Folding@home project. Cisco’s team ID is 1115, and our group is called CiscoLive2016, as that’s the first time we deployed Folding@home during that very show.

Other important questions arise from this such as:

◉ What are we using to host Folding@home?
◉ How did we deploy the virtual machines?
◉ How are we monitoring our compute?
◉ How do we monitor our progress in terms of the Folding@home project?

What are we using to Host Folding@home?

We deploy two types of compute cluster at Cisco Live, one traditional data center solution with storage and blade servers (UCS B series), known as a Flexpod. The second, a hyperconverged cluster known as Cisco Hyperflex. The Flexpod is a collaborative solution that comprises VMware’s vSphere virtualization software, NetApp’s storage clusters, Cisco’s UCS Blade Servers, and Nexus Data Center switches. In this case we’re using UCS B200 M4 split over two chassis combined with a NetApp MetroCluster IP for a total of 16 Blades. The Metro cluster is a fully redundant storage system that replicates all data between two arrays. As such, if you lose one, the other will allow you to recover your lost data. Typically, these are installed at two different locations, which isn’t possible at Cisco Live due to space and cabling restrictions. You’ll see how we configure it below.

The MetroCluster actually ships with two Nexus 3232C switches to create the IP connectivity between both clusters. The UCS Chassis uses a boot from SAN method, to load their ESXi OS from the Metro Cluster IP. Due to UCS’s service profiles, if we were to lose a blade, we may simply replace the blade and boot the exact same operating system, used by the old host, without the need to re-install ESXi. A service profile is essentially a set of variables that make a host or server operable.  These variables include UUID, MAC address, WWPN’s and many other pieces of information. When we insert a new blade it would take on the appearance of the fold blade using the information created within the profile. This allows it to masquerade as the old host and permits a compute hotswap. Here’s a basic diagram of our design.

Flexpod Design Diagram

How are we monitoring our Compute?

The other awesome thing about Cisco’s compute platform is we have a cloud-based monitoring system called Cisco Intersight. We use this each year to ensure our servers are running without error. You may also access the servers’ management interfaces, UCS Manager, from Intersight, making it a consolidated GUI across multiple sites or deployments. Here’s a Dashboard screen capture of how that looks. We actually have an error on one host which I need to investigate further. It’s great to have a monitoring system, especially whilst we’re all working from home.

How did we deploy the Virtual Machines?

Being a busy guy, I didn’t want to manually deploy all 40 virtual machines (VMs), carrying out a lot of error prone typing of host names, IP addresses and VM specific parameters. Bearing in mind, there would be a great deal of repetition as each VM is essentially the same. Instead I decided to automate the deployment of all the VMs. The great news is, some of the work has already been done as VMware themselves have produced a Folding@home ‘ova’ image running their Photon OS. The image is optimized to run on ESXi and can be installed using ova/ovf parameters. These are basically settings, such as IP address, hostname and information specific to the Folding@home software install taken prior to installation. There are some installation posts regarding deployment and also in the download itself. Please see the link at the end of this post.

Using Python scripting and VMware’s ovftool, a command line tool for deploying ovf/ova files, I was able to take the image and pass all the ova parameters to the ovftool. The ovftool then actually builds a VM on a specified host taking all of your desired settings. Using Python, I can loop over all of these parameters x number of times, in my case forty, and execute the ovftool command forty times.  This was a joy to watch, as VM’s started to appear in my vCenter all of a sudden and I could sit back and drink my cappuccino.

After the installation I was able to monitor, using VMware’s vCenter how our hosts were running. Using Folding@home’s largest VM’s installation, which uses more processing power, I was able to push our cluster to around 75% CPU utilization on each host as can be seen below. Some hosts were spiking a little, so I needed to make some adjustments, but we continued to crunch numbers and use our otherwise idle compute for a greater good.

How do we monitor our progress in terms of the Folding@home project?

Digging into Folding@home, I was able to learn the project has an Application Programming Interface or API. The API allows access to the statistics programmatically. Again, using Python alongside InfluxDB and Grafana, I was able to create a dashboard that the team could view in order to monitor our progress. Here’s a sample that I’ve annotated with numbers so we can refer to each statistic individually.

1. Teams work units, the amount of data crunched over time

2. The score assigned to our team over time

3. Cisco System’s group position out of all companies contributing to the project

4. Within the Cisco Systems group, our own position within the project

5. TechX work units as a numerical value

6. TechX’s Score as a numerical value

I was going to go into what we used our Hyperflex for, but I may leave that to another article as this one is getting a little long!

Continue reading