Cisco – the Bridge to an API-first, Cloud Native World

The traditional development of applications is giving way to a new era of modern application development.

Modern apps are on a steep rise. Increasingly, the application experience is the new customer experience. Faster innovation velocity is needed to deliver on constantly changing customer requirements. The cloud native approach to modern application development can effectively address these needs:

◉ Connect, manage and observe across all physical, virtual, and cloud native API assets

◉ Secure and develop using distributed APIs, Applications and Data Objects

◉ Full-stack observability from API through bare metal and across multi-SaaS are table-stakes for globally distributed applications

“Shifting to an API-first application strategy is critical for enterprise organizations as they rearchitect their future portfolio,” said Michelle Bailey, Group Vice President, General Manager and Research Fellow at IDC.

Modern World of App Development

Modern applications are built using composable cloud native architectures. We see more modern apps being built and deployed because application components are disaggregated into reusable services from a single integrated image. These and other API’s are distributed across multiple SaaS, cloud or on-premises. Developers can use API’s from across all these properties to build their apps.

The benefits of this ideal API-first world in a native hybrid-cloud, multi-cloud future are:

◉ Greater uptime: only the components requiring an upgrade are taken offline as opposed to the entire application

◉ Choice: ability for developers to pick and choose APIs wherever they reside and matter most to their applications and businesses gives them flexibility

◉ Agile teams: small teams focused on a specialized component of the application means developers can work more autonomously, increasing velocity while enhancing collaboration with SRE and security teams

◉ Unleashing innovation: enables developers to specialize in their areas of expertise

Cisco — The Bridge to an API-first, Cloud Native World

We want a future where a developer can pick and choose any API’s (internal or 3rd party) needed to build their app, consume them and assign policies consistently across multiple providers. Connect, secure, observe and upgrade apps easily. Have confidence in the reputation and security of the apps, right from the time the IDE is fired and into production.

And do all of this with velocity and minimal friction between development and  cloud engineering/SRE teams.

Even as some sprint out ahead in the cloud native world, bringing everyone along – wherever they are on their journey – is a top priority. We still need to bridge back to where the data resides in data centers, SaaS vendors, and in some cases even mainframes.

Developers will need to discover and safely connect to where the data and APIs are – wherever they reside. And be able to see top/down in apps. Observability throughout the stack is needed.

For a seamless developer experience, it will need the following:

◉ API-layer connectivity will influence all networking. API discovery, policy, and inter-API data flows will drive all connectivity configuration and policies down the infrastructure stack

◉ APIs and Data Objects are the new security perimeter. The Internet is the runtime for all modern distributed applications, therefore the new security perimeters are now diffused and expanded

◉ Observability is key to API-first distributed cloud native apps. Observability at the API and cloud native layers with well defined Service Level Objectives (SLOs) and AI/ML driven insights to drive down Mean Time To Resolution (MTTR) to deliver of an exceptional application experience

Here’s how we’re solving for it:

◉ Portfolio of mesh and connectivity software services that allow for the discoverability, consumption, data flow connectivity and real-time observability of distributed modern applications built across cloud native services at any layer of the stack, and integrates with event-driven services that bridge the monolithic world to the new cloud native world

◉ Portfolio of security services that detect, scan, observe, score and secure APIs (internal or 3rd party), while simultaneously ensuring real-time compliance reporting and integrations with existing development, deployment and operating toolchains

Source: cisco.com

Continue reading

The Cloud can be Simple, Agile, and Secure for Broadcasters

At a time when production from anywhere is a must, those that create, distribute, and secure content needed to pivot overnight, adopting new tech and workflows. Back in the old days, the studio was the central repository for this content, but now that it needs to be securely shared online with teammates around the world who are working from their home offices, the challenges continue to mount.

Read More: 100-490: Supporting Cisco Routing and Switching Network Devices (RSTECH)

Now more than ever, high availability is needed for remote workers. This, along with fault tolerance and resiliency, are standards the media industry has long sought out when it comes to creating and managing content. The industry is faced with the need to transform and do it quickly, with content distribution using IP as the backbone and workloads like content creation and production in the cloud. The “new normal” will be a hybrid model that incorporates some work from anywhere combined with some on-premises activity. How do we accommodate this sudden shift in the way we do business?

The Umbrella multi-function security solution

Cloud infrastructure has plenty of capacity but faces hurdles

The term “cloud” has become a ubiquitous word used throughout multiple industries and businesses around the world. It shouldn’t be surprising that broadcast and media enterprises are trying to leverage this common infrastructure for multiple workflows within their environment. However, the cloud can have many unique challenges for the media industry that make this transition a little more difficult to undertake.

Just move it to the cloud – sounds simple right? Everything these days is connected to the Internet through core routers in the data center (which are traditionally over-provisioned). However, it isn’t that easy. Groups like the Video Services Forum (VSF) semi-working group standards body, and the Society of Motion Picture and Television Engineers (SMPTE) are looking at solving problems over WAN infrastructure. For example, SMPTE 2110 is an attempt to move production to IP by breaking apart video, audio, and ancillary data to enable more flexible workflows. Now the problem with cloud infrastructure isn’t capacity but rather loss, jitter, and latency.

With real-time production, even the smallest of the aforementioned issues can have a large impact on content. This makes it unsurprising that the industry is starting to provide re-transmission mechanisms in video transport to allow a guarantee of transmission through cloud infrastructure. This has come through mechanisms such as Reliable Internet Stream Transport (RIST), a video protocol, and Secure Reliable Transport (SRT). With the reduction in cost and improvement of technology, large-scale distribution, processing, and other workflows can now be moved entirely to the cloud.

This migration from on-prem to the cloud can address agility and economy of scale. The infrastructure cloud provides can be more cost-effective for fulfilling spike workloads in an on-demand way. In the cloud, we treat everything as a resource pool that can be changed and re-provisioned as needed. This means we could use the same resources for ingest, transcode, playout, and others on an ad-hoc basis.

Agility is key in the “new normal”

Next to capital cost savings, this agility of workflows is the main reason for using the cloud. Agility also provides the ability to enable remote work when the ability to access physical infrastructure may be limited. This has been especially important during the recent health crisis. Media entities who were ahead of the game with cloud workflows had a head start on this. Some of these agile workflows can include media supply chain, from Media Asset Management (MAM) services, and beyond. With distribution services for linear broadcast and Video on Demand (VOD), we’ve even seen production workflows start to penetrate the cloud.

Security, visibility, and analytics are more important than ever

With all these workflows moving ahead simultaneously, we need to start thinking about visibility, security, and analytics and how they affect business as usual. We need to talk about visibility in the cloud because most of the time cloud services are accessed from outside the corporate network. Chances are the devices accessing these services are not controlled by IT, and this leaves a huge security gap in engineering and IT from being unable to monitor users’ traffic and applications.

Wouldn’t it be great if you could pinpoint network issues before they happened? ThousandEyes is a digital experience monitoring platform that provides end-to-end visibility of an entire workflow. This holistic view allows end-users to see where they could be impacted by the path the workflow is taking. For example, with the click of a button your Internet Service Provider (ISP) can see your entire network to pinpoint challenges that are causing problems, like maybe an old tablet that’s slowing down all your other devices. This gives the ISP the ability to take immediate action from fast troubleshooting to an even faster resolution.

ThousandEyes Internet Insights™

Data control is another area that needs a closer look. Engineering and IT have less access to data when it’s stored in off-prem cloud services. Users can now access data from any location on any device, and this could include Bring Your Own Devices (BYODs). Along this line, Cisco Umbrella offers a single pane of glass encompassing the entire security portfolio, with a flexible portal that addresses the security of the cloud, connected devices, remote users, branch users, etc. This cloud-accessed security broker offers cloud firewalls, secure web gateways, and DNS layer security which can be done over SD-WAN, on-prem users, and most importantly remote users – having security orchestration over people’s houses and the links they might accidentally click.

There’s also the risk that cloud providers have privileged access to your data, making a chain of ownership controls imperative. This is especially true for our media customers. The media enterprise’s most valuable asset is content, and they need to know who’s accessing it. One interesting technology that can be leveraged here is blockchain.

Blockchain, the technology behind bitcoin, is a secure and encrypted digital database that can be shared between all parties in a distributed fashion. All transactions that occur with the data in question are recorded, verified, and stored in the database. This database is comprised of a distributed ledger technology, and in it, multiple copies of the data exist across the network instead of being centralized. This would be an ideal method to maintain a chain of ownership over media assets.

Source: cisco.com

Continue reading

F5 & Cisco ACI Essentials – Dynamic pool sizing using the F5 ACI ServiceCenter

APIC EndPoints and EndPoint Groups

When dealing with the Cisco ACI environment you may have wondered about using an Application-Centric Design or a Network-Centric Design. Both are valid designs. Regardless of the strategy, the ultimate goal is to have an accessible and secure application/workload in the ACI environment. An application is comprised of several servers; each one performing a function for the application (web server, DB server, app server etc.). Each of these servers may be physical or virtual and are treated as endpoints on the ACI fabric. Endpoints are devices connected to the network directly or indirectly. They have an address , attributes and can be physical or virtual. Endpoint examples include servers, virtual machines, network-attached storage, or clients on the Internet. An EPG (EndPoint Group) is an object that contains a collection of endpoints, which can be added to an EPG either dynamically or statically. Take a look at the relationship between different objects on the APIC.

ACI object relationship hierarchy

Relationship between Endpoints and Pool members

If an application is being served by web servers with IPs having address’s in the range 192.168.56.*, then these IP addresses will be present, as an endpoint in an endpoint group (EPG) on the APIC. From the perspective of BIG-IP these web servers are pool members on a particular pool.

Relationship between Endpoints and Pool members

The F5 ACI ServiceCenter is an application developed on the Cisco ACI App Center platform designed to run on the APIC controller. It has access to both APIC and BIG-IP and can correlate existing information on both to provide a mapping as follows.

BIG-IP                                                                APIC

VIP: Pool: Pool Members(s)               Tenant: Application Profile: End Point group

This gives an administrator a view of how the APIC workload is associated with the BIG-IP and what all applications and virtual IP’s are tied to a tenant. 

Dynamic EndPoint Attach and Detach

Lets think back to our application which is say being hosted on 100’s of servers, these servers could be added to an APIC EPG statically by a network admin or they could be added dynamically through a vCenter or openstack APIC integration. In either case there endpoints ALSO need to be added to the BIG-IP where the endpoints can be protected by malicious attacks and/or load-balanced. This can be a very tedious task for a APIC or a BIG-IP administrator.

Read More: 350-901: Developing Applications Using Cisco Core Platforms and APIs (DEVCOR)

Using the dynamic EndPoint attach and detach feature on the F5 ACI ServiceCenter this burden can be reduced. The application has the ability to adjust the pool members on the BIG-IP based on the server farm on the APIC. On APIC when an endpoint is attached, it is learned by the fabric and added to a particular tenant, application profile and EPG on the APIC. The F5 ACI ServiceCenter provides the capability to map an EPG on the APIC to a pool on the BIG-IP. The application relies on the attach/detach notifications from the APIC to add/delete the BIG-IP pool-members.

Mapping EPG to Pool members

There are different ways in which the dynamic mapping can be leveraged using the F5 ACI ServiceCenter based on the L4-L7 configuration. In all the scenarios described below the L4-L7 configuration is deployed on the BIG-IP using AS3 (flexible, low-overhead mechanism for managing application-specific configurations on a BIG-IP system).

Scenario 1: Declare L4-L7 configuration using F5 ServiceCenter

Scenario 2: L4-L7 configuration already exists on the BIG-IP

Scenario 3: Use dynamic mapping but do not declare the L4-L7 configuration using the F5 ServiceCenter

Scenario 4: Use the F5 ServiceCenter API’s to define the mapping along with the L4-L7 configuration

Let’s take a look at each one in detail:

Scenario 1: Declare L4-L7 configuration using F5 ServiceCenter

Let’s assume there is no existing configuration on the BIG-IP, a new application needs to be deployed which is front ended by a VIP/Pool/Pool members. The F5 ACI ServiceCenter provides a UI that can be used to deploy the L4-L7 configuration and create a mapping between Pool <-> EPG

Step 1: Define an application using one of the in-built templates

Defining an Application using built-in templates

Step 2: Click on the Manage Endpoint mappings button to create a mapping

Managing Endpoint mappings

Scenario 2: L4-L7 configuration already exists on the BIG-IP

If L4-L7 configuration using AS3 already exists on the BIG-IP, the F5 ACI ServiceCenter will detect all partitions and application that in compatible with AS3. Configuration for a particular partition/application on BIG-IP can then be updated to create a Pool <-> EPG mapping. However there is one condition that the pool can either have static or dynamic members so if the pool already has existing members those will have to be deleted before a dynamic mapping can be created. To maintain the dynamic mapping , any future changes to the L4-L7 configuration on the BIG-IP should be done via the ServiceCenter.

Scenario 3: Use dynamic mapping but do not declare the L4-L7 configuration using the F5 ServiceCenter

The F5 ACI ServiceCenter can be used just for the dynamic mapping and pool sizing and not for defining the L4-L7 configuration. For this method the entire AS3 declaration along with the mapping will be directly send to the BIG-IP using AS3.

Sample declaration (The members and constants section creates the mapping between Pool<->EPG)

Since the declaration is AS3, the F5 ACI ServiceCenter will automatically detect a Pool <-> EPG mapping which can be viewable from the inventory tab.

Scenario 4: Use the F5 ServiceCenter API’s to define the mapping along with the L4-L7 configuration

Finally if the UI is not appealing and automation all the way is the goal, then the F5 ServiceCenter has an API call where the mapping as well as the L4-L7 configuration which was done in Scenario 1 can be completely automated. Here the declaration is being passed to the F5 ACI ServiceCenter through the APIC controller and NOT directly to the BIG-IP.

URI:https://<apic_controller_ip>>/appcenter/F5Networks/F5ACIServiceCenter/updateas3data.json 

Body/declaration

Having knowledge on how AS3 works is essential since it is a declarative API and using it incorrectly can result in incorrect configuration. Either method mentioned above works, the decision on which method to use is influenced on the operational model that works the best in your environment.

Source: cisco.com

Continue reading

Securing the air with Cisco’s wireless security solution

With the proliferation of IoT and BYOD devices, wireless security is top-of-the-mind for network administrators and customers. Globally, there will be nearly 628 million public Wi-Fi hotspots by 2023, which is almost four-fold increase from 2018. This will increase the attack surface and hence the vulnerability for the network. The total number of DDoS attacks is predicted to reach 15.4 million by 2023, more than double the number from 2018. Due to inherent open nature of wireless communications, wireless LANs are exposed to multitude of security threats, including DoS flood attacks.

Number of DDoS attacks (Source: Cisco Annual Internet Report, 2018–2023)

Cisco Next Generation Advanced Wireless Intrusion Prevention System (aWIPS) is one of the solutions in Cisco’s multi-pronged approach to providing wireless security. aWIPS is a wireless intrusion threat detection and mitigation mechanism that secures the air. aWIPS along with currently offered Rogue management solution provides security against DoS attacks, management frame attacks, tool-based attacks and more. 

Solution Components

aWIPS and Rogue management solution comprises of Cisco access points, Wireless LAN controllers and Cisco DNA Center. This solution is supported on all 802.11ax/802.11ac wave2 Cisco access points and Cisco 9800 series controllers.

Access Points: Access points detect threats using signature-based techniques. Access points can operate in monitor, local, and flex-connect mode. In monitor mode, radios continuously scan all channels for any threats, but they don’t serve any clients. In local and flex-connect mode, access point radios serve clients and scan for threats on client serving channels. On non-serving channels they would do best-effort scanning for any possible threats.  With Cisco’s Catalyst 9130 and 9120 WiFi 6 access points, there is an additional custom RF ASIC radio that continuously monitors all channels for any threats, while the other radios serve the clients. With this dedicated radio, we significantly improve our threat detection capabilities.

Cisco 9800 series controllers: Cisco WLAN controllers configure the access points and receives alarms and rogue information received from access points. It sends the consolidated reports to Cisco DNA Center.

Cisco DNA Center: Cisco DNA Center provides simple workflows that allow users to customize aWIPS signatures and rogue rules. It constantly monitors, aggregates, corelates and classifies all the rogue events and alarms received from all the managed access. Using network intelligence as well as topology information, DNA Center accurately pinpoints the source of attack, and allow users to contain the attack before any actual damage or exposure occur.

Intuitive, Simple and Secure

Cisco aWIPS and Rogue management solution is intuitive and simple to configure, but has advanced signature-based techniques, network intelligence and analytics to detect threats. With Cisco aWIPS and Rogue management solution, the network is secure against all types of on-the-air wireless attacks.

Denial of Service:

Denial of service attacks aim to cause resource exhaustion and thus deny legitimate users access to the wireless service. Due to the nature of wireless communication, the DoS flood attacks are very prevalent in the network.

DoS flood attacks snapshot (3-month period) from a wireless network

With aWIPS, we detect, report and provide location of following DoS attacks:

◉ Targeted towards access points: Access points have limited resources and DoS flood attacks like authentication flood, association flood, EAPOL-start flood, PS Poll Flood, probe request flood, re-association flood can overwhelm access point.

◉ Targeted towards infrastructure: DoS flood attacks like RTS flood, CTS flood or beacon flood causes RF spectrum congestion and thus block legitimate clients from accessing wireless network.

◉ Targeted towards clients: Attacks like de-authentication flood, disassociation flood, broadcast de-authentication flood, broadcast disassociation flood, EAPOL logoff flood, authentication failure attack, probe response flood, block ack flood can cause valid clients to disconnect or can prevent them from joining the network, thus disrupting wireless service.

◉ Targeted to exploit known vulnerabilities/bugs: Attacks using fuzzed beacon, fuzzed probe request, fuzzed probe response, malformed association request, malformed authentication are targeted to exploit known vulnerabilities/bugs in wireless devices, thus causing crash, leading to denial of service.

aWIPS detects Airdrop session, which can present security risks as these peer-to-peer connections are unauthorized in the corporate settings. As part of aWIPS solution, we also alert user of any invalid MAC OUI use in the network.

Impersonation and Intrusion

Rogue management provides protection against AP impersonation, Honeypot AP and Rogue-on-wire. Using auto-containment/manual containment, any rogue attacks can be thwarted before actual damage occurs.

Not one size fits all

Every network is different, and what is deemed as acceptable and expected behavior on one network need not always be acceptable for another. With Cisco DNA Center, we provide following configuration knobs to allow our customers to fine-tune aWIPS signature and Rogue rules based on their network needs:

1. Flexibility to select signatures.

2. Configurable thresholds for signatures.

3. Configurable threat levels

These configuration knobs allow one to configure aWIPS signatures to fit their network characteristics.

Users can add Rogue rules to customize Rogue detection and management. The rules allow users to configure threat levels and conditions like SSID, RSSI, encryption and rogue client count.

aWIPS signature customization

Cisco DNA Center provides simple workflows that enable customers to customize aWIPS signatures and Rogue rules.

Rogue rule customization

Attack Forensics

Sometimes there is an overwhelming need for evidence and post-analysis to get deeper understanding of the attacks in the network. With Cisco aWIPS you have an option to enable forensic capture per signature. When forensic capture knob is enabled for a signature, access points would capture raw packets during the attack timeframe and send it to DNA Center where the customers can view these packet captures. These packet captures can be used to analyze what is triggering the attack.

Forensic Capture

Cisco DNA Center: The eye that sees them all

Using Cisco DNA Center, one can not only configure aWIPS and customize as per their needs, but can also view the alarms, along with location of threat, threat MAC details, all in single pane of glass. Gone are the days when the administrator had to go through each wireless LAN controller to get this level of detail. DNA Center aggregates, correlates and summarizes the attacks across the managed network on the unified security dashboard. In addition to current active alarms, DNA Center also stores historic data for users to view and analyze.

Rogue/aWIPS alarm dashboard

Threat 360: The who/what/when/where?

Cisco DNA Center Threat 360 view provides detailed view on each of the alarms:

1. Context of attack: Information on attacker, victim and detecting entities.

2. Threat level: Severity of the attack

3. Location and Time of the attack.

Threat 360

This kind of visualization of threats have gotten our customers excited about Cisco security solution package. Our customers love this unified dashboard with threat 360 view, and they are deploying DNA Center with Rogue package across multiple geographical locations.

Source: cisco.com

Continue reading

The Need for Continuous and Dynamic Threat Modeling

The trend towards accelerated application development, and regular updates to an architecture through an agile methodology, reduces the efficacy and effectiveness of point-in-time threat modeling. This recognition led us to explore and strategize ways to continuously, and dynamically, threat model an application architecture during runtime.

Today, thanks to a robust DevOps environment, developers can deploy a complex architecture within a public cloud such as Amazon Web Services (AWS) or Google Cloud Platform without requiring support from a network or database administrator. A single developer can develop code, deploy an infrastructure through code into a public cloud, construct security groups through code, and deploy an application on the resulting environment all through a continuous integration/continuous delivery (CI/CD) pipeline. While this enables deployment velocity, it also eliminates multiple checks and balances. At Cisco, we recognized the risks introduced by such practices and decided to explore strategies to continuously evaluate how an architecture evolves in production runtime to guard against architecture drift.

Dynamic threat modeling must begin with a solid baseline threat model that is done in real-time. This can in turn be monitored for architecture drift. Our approach to obtain such a real-time view is to use dynamic techniques to allow security and ops teams to threat model live environments instead of diagraming on paper or whiteboards alone.

How Does Dynamic Threat Modeling Work?

Threat modeling is the practice of identifying data flows through systems and various constructs within an architecture that exhibit a security gap or vulnerabilities. A crucial element that enables the practice of threat modeling is generating the right kind of visual representation of a given architecture in an accurate manner. This approach can differ based on context and from one team to another.  At Cisco, we instead focused on elements and features that need to exist to allow a team to dynamically perform a threat modeling exercise. These elements include the ability:

◉ To transform an operational view of an architecture to a threat model

◉ To contextualize a requirement

◉ To monitor the architecture for drift based on a requirement

From Operational View to Threat Model

Numerous tools exist that can render an operational view of an architecture. However, an operational view of an architecture is not the same as a threat model. Instead, an operational view must undergo a transformation to create a threat model view of an architecture. For this to occur, the solution should at a minimum provide a way to filter and group queries within an architecture so that only relevant data is visually rendered.

As an example, consider a case where an AWS hosted public cloud offer consists of two types of S3 buckets (Figure 1). One type of S3 buckets is deployed for customers for them to access directly. Each customer gets their own unique S3 bucket to access. Other types of S3 buckets are deployed for organization-specific internal administrative purposes. Both types of S3 buckets are identified through their AWS tags (“Customer” and “Admin” respectively). A filter-based query applied to an architecture of this type can answer questions such as “Are there S3 buckets with Tag: ‘Customer’ or ‘Admin’ in this architecture?”

Figure 1. Operational Views with and Without Filtering or Grouping Applied

Even though grouping is like filtering, it differs because it allows an administrator to query an architecture with the question: “Are there S3 buckets with the Customer or Admin tag in this architecture? If so, group these assets by their tags and logically represent them by their tags” (Figure 2).

Figure 2. Operational View with Grouping Applied by Admin or Customer Tags

What Does it Mean to Contextualize a Requirement?

With dynamic threat modeling, contextualizing a requirement allows a team to prescribe a contextualized remediation plan for a specific area of the architecture so that it can be monitored for architecture drift. This event is the next step towards securing an architecture from specific threats at a more granular level once the appropriate base line security guardrails have been applied towards an environment.

To build on the example from above, industry standard best practices towards securing a S3 bucket prescribes configuring S3 buckets as non-public. As mentioned above, the first type of S3 bucket is offered to customers for them to access (for read or write). Furthermore, each customer gets their own unique S3 bucket. The second type of S3 bucket is used by the organization’s internal administrative purposes. Once the standard guardrails have been implemented towards the two types of S3 buckets, the next step is to determine the type of access authorization that should be applied towards the two types of S3 buckets based on the purposes they serve (Figure 3).

Figure 3:

Ability to Monitor the Architecture for Drift Based on Requirements

As previously mentioned, the goal of dynamic threat modeling is to monitor the architecture that has been threat modeled in real-time for architecture drift. This should not be confused with the ability to monitor a network for vulnerabilities. To monitor for vulnerabilities, there are already numerous tools within the industry to help a DevSecOps team determine areas of risks. To monitor for architecture drift, a solution must be able to tie together a sequence of events to determine if the appropriate context exists for the events to be considered as drift. To continue our example from Figure 3, Figure 4 below outlines the areas within the S3 architecture that should be monitored for architecture drift once the contextualized requirement has been applied.

Figure 4. Monitoring Applied to Customer and Admin Buckets Grouped Based on Requirements

Challenges and What the Future Holds

By enabling dynamic threat modeling, DevSecOps can continuously monitor an environment in real-time for any architecture drift. However, the following challenges must be addressed by DevSecOps:

◉ Apply better conversion techniques to transform an operational view to a threat model

◉ Develop better strategies to codify human-based contextual requirements into actual rules

◉ Drive a consistent baseline security strategy that can be evaluated based on various architectures

Security is a journey that requires influencing and enabling teams to adopt and employ best practices and controls for their architectures. By continuing to enhance this strategy and addressing the challenges mentioned above, we anticipate wide adoption and acceptance of continuous and dynamic threat modeling of live environments to monitor for any architecture drift and proactively mitigate the risks in the fast-paced world of DevSecOps.

Figure 5 illustrates what we’ve accomplished at Cisco as we strive to raise the bar on security and the trust of our customers.

Figure 5. Cisco Security Automation for DevSecOps Features

Source: cisco.com

Continue reading

Building Trust in Your Access Network

How do you know for sure that a router in your network has not been altered since you deployed it? Wouldn’t it be great if you could cryptographically challenge your router to provide its unique identity? In addition, what if the underlying OS could provide a secure mechanism to detect if the software had been tampered with during boot time and runtime?

Networking equipment manufacturers are seeing an increase in supply chain attacks, which means communication service providers (CSP) need tools that can detect the replacement of critical components such as CPU/NPU. Software security features are insufficient in detecting and protecting against these attacks if the underlying hardware has been compromised. To completely trust the device, CSPs need a chain of trust that is preserved in hardware manufacture, software development and installation, procurement, and live deployment within their network.

With 5G deployments gaining traction, routers are now increasingly deployed in distributed architectures (read as remote locations) and depended on as critical infrastructure. Cisco’s trustworthy platforms ensure customers can validate the authenticity of their devices in both hardware and software to help eliminate malicious access to the network and significantly improve the CSP’s security posture.

To understand how we do this, let’s go over the basic security building blocks included in the NCS 500 platforms (as well as others) that enable us to deliver the following aspects of trustworthy platforms:

◉ Hardware integrity

◉ Boot integrity

◉ Runtime integrity

◉ Operational visibility of your trustworthy network

Root of Trust in Hardware

Incorporating the latest software security features is immaterial unless the underlying hardware itself is trustworthy. To provide this strong foundation of Trust, the Cisco NCS 540 and NCS 560 routers incorporate a tamper-resistant Trust Anchor module. This acts to protect the entire Secure boot process from components to operating system loading and establishing a chain of trust.

The hardware trust anchor module primarily provides the following set of features.

◉ Microloader needed for the secure boot process

◉ Secure Unique Device Identifier (SUDI) for device identification

◉ On-chip storage for encryption keys

◉ UEFI compliant DB for key management

◉ On-chip registers (PCRs) to record boot and runtime measurements

◉ On-chip DB to secure the hash of CPU for Chip Guard feature

Measuring & Verifying Trust

Trust, unlike security, is tangible. It can be measured and verified by an entity external to the device. The NCS 500 series routers come with Boot Integrity Visibility and Chip Guard features to ensure customers can validate the trustworthiness of the device and that it hasn’t been tampered with during boot time or subjected to supply-chain attacks. The Trust Anchor module captures measurements recorded during the secure boot process and these measurements can later be retrieved to validate that the boot process hasn’t been tampered.

With increasing supply-chain attacks, components like CPUs are being replaced with compromised chips that contain Trojan programs. At boot-up, the NCS 500 series can counter these types of attacks because the Chip Guard feature utilizes stored Known Good Values (KGV) within the TAm to validate all components. If a KGV value does not match, then the hardware boot will fail, and an alert can be sent to the network monitoring tools.

Lastly, the Secure Unique Device Identifier (SUDI) that gets programmed inside the Trust Anchor module during the manufacturing process ensures that the router can be cryptographically challenged at any time during its operational lifetime to validate its identity. This way customers can ensure that they are still talking to the same router that was deployed in their network months or even years ago.

In short, the features of SUDI, Chip Guard, and Cisco Secure Boot enable customers to verify the integrity of the router over its entire lifetime.

Trust at Runtime

Moving to runtime protections and establishing trust in software, NCS 500 routers come with the latest IOS XR Operating System that includes a host of security features. Starting with SELinux policies that provide mandatory access controls for accessing files, it also supports the Linux Integrity Measurement Architecture (IMA). With these features, customers can now establish trust in software by querying the runtime measurements from a router at any point in time. The router continuously gathers file hashes for all the files being loaded and executed. These measurements can be queried by an external entity to compare against the expected Known Good Values published by Cisco. To ensure the authenticity of these remotely attested measurements, they are signed with the device’s unique SUDI private key.

With these foundational blocks of trust being established in hardware, both during boot time and runtime, we are now able to provide additional features like a trusted path routing that can help extend trust further into the network. The trust status of a device, the trusted routing path, and the ability to validate software updates as genuine per the manufactures specifications are valuable assets included in the Crosswork Trust Insights tool that can provide proof of the network’s trustworthiness.

Source: cisco.com

Continue reading

Cisco DNA Center smooths network operations

As we plan for a safe return to Cisco offices around the world, we are experiencing a large increase in the types and numbers of devices connecting to our network. This means that our teams need to manage an increasingly complex ecosystem more efficiently than ever before.

Like many IT departments, we are scrambling to keep up with these new network demands. In fact, according to one recent study of various enterprises, 43 percent of surveyed IT and network professionals said they struggle to find time to work on strategic business initiatives, and 42 percent spend too much time troubleshooting the network.

Read More: 300-425: Designing Cisco Enterprise Wireless Networks (ENWLSD)

As a result, many IT teams lack the time needed both to grow their networks and take on new projects that could set their companies apart from the competition.

To help address these challenges, our Customer Zero team, a part of Cisco IT, deployed the Cisco DNA Center controller as part of a multi-site initiative to better automate and maintain our campus and branch networks.

Cisco DNA Center delivers centralized command and control

With the Cisco DNA Center, we can take charge of our network, optimize our network investments, and respond to changes and challenges faster and more intelligently than we could before.

Cisco DNA Center provides a real-time dashboard for managing and controlling our enterprise network. It also automates provisioning and change management, checks compliance against policies, and captures asset logs that can be analyzed for troubleshooting, problem resolution, and predictive maintenance.

Assuring optimal network performance

Cisco DNA Center’s Assurance capabilities allows us to quantify network availability and risk based on analytics. It accomplishes this by enabling every point on the network to become a sensor. Cisco DNA Center collects data from 17 different network sources – including NetFlow, SNMP, syslog, streaming telemetry, and more – so that we can view network issues from many different angles and contexts. It sends continuous streaming telemetry on application performance and user connectivity in real time, then uses artificial intelligence (AI) and machine learning to make sense of the data.

Cisco DNA Center’s clean, simple dashboards show overall network status and flag issues. In addition, guided remediation automates the process of issue resolution and performance enhancement, ensuring optimal network user experiences and less troubleshooting. It allows us to resolve network issues in minutes instead of hours — before they become problems. Cisco DNA Center even lets us go back in time to see the cause of a network issue, instead of trying to re-create the issue in a lab.

How Cisco DNA Assurance operates

Making an impact for Customer Zero

By implementing emerging technologies in Cisco’s IT production environments, Customer Zero provides an IT operator’s perspective as Cisco develops integrated solutions, best practices, and accompanying value cases to drive accelerated adoption.

As part of our mission to use Cisco products in our own real-world environment, the Customer Zero team has deployed Cisco DNA Center as part of a multi-site (six buildings) Cisco Software Defined Access (SD-Access) fabric on our San Jose campus. The solution has already yielded encouraging pilot-test results in four areas of the product: Network Health Dashboard, Client Health Dashboard, Network Insights & Trends (AI-driven), and Wireless Sensor Dashboard. Let’s take a closer look at how the last of these, Cisco DNA Center’s Wireless Sensor capability, is helping us improve the process of making network changes.

Real-world use case: network changes with software upgrades

For any required network changes, such as software upgrades, Cisco DNA Center collects information and insights from wireless sensors. The results are then displayed on a single dashboard, allowing our teams to monitor and detect issues more easily.

Wireless sensors behave as wireless clients. They connect to our SSIDs and run network tests, much like an on-site engineer would do. They have the added intelligence of reporting their findings back to Cisco DNA Center, where the data from all sensors is compiled into one dashboard. Sensors run their tests automatically and periodically – after initial configuration, there is no need to touch the sensors again.

Cisco DNA Center’s Wireless Sensor capability has provided five key benefits for Customer Zero:

1. Reduced time to complete change requests. After changes occur in the network, we check our sensors to ensure they – and, ultimately, end users – have no problem connecting to the SSIDs. Consequently, we can close the change window sooner.

2. Improved ease of use and productivity for IT teams monitoring the network. Instead of having to perform checks in multiple locations, we can monitor the health of the network in a single place. This is true both when following up after network changes (change requests) and also for daily monitoring of the infrastructure’s health.

3. Reduced risk and improved confidence. Our engineers use the sensor dashboard to systematically check wireless client health. We gain confidence in the success of our change windows and can assertively close them without worrying about lingering issues.

4. Reduced costs. Because wireless sensors tell us about the real-time health of our network, we feel more confident about conducting changes during business hours. With the ability to perform upgrades in production during business hours, we expect to reduce costs associated with outsourcing vendors who charge higher rates for off-hours activities.

5. Increased adoption of NetDevOps (agile) capabilities. The ability to make changes in production while leveraging critical data about end-user experience is helping to change our team members’ mindsets. They’ve become more assertive about embracing NetDevOps continuous improvement / continuous upgrade changes – which is also contributing to improved skillsets.

Our team’s implementation of Cisco DNA Center confirmed the solution’s ability to save time and costs, reduce risk, improve ease of use and confidence, and build stronger skillsets.

Source: cisco.com

Continue reading