Cisco Project, “An-API-For-An-API,” Wins Security Award

Enterprise software developers are increasingly using a variety of APIs in their day-to-day work. With this increase in use, however, it is becoming more difficult for organizations to have a full understanding of those APIs. Are the APIs secure? Do they adhere to the organization’s policies and standards?  It would be incredibly helpful to have a suite of solutions that provides insights to these questions and more. Fortunately, Cisco has introduced our An-API-For-An-API project to address these concerns.

Introducing

An-API-For-An-API (AAFAA) is a project that controls the end-to-end cycle for enterprise API services and helps developers, from code creation to deployment into a cloud, provisioning of API gateways, and live tracking of API use while the application is in production.  Leveraging APIx Manager, an open-source project from Cisco, it combines CI/CD pipelines where API interfaces are tested to enterprise (security) policies, automatic deployment of applications behind an API gateway in a cloud system, and dynamic assessment of the API service through.

Figure 1. provides an overview of how the various pieces of the AAFAA solution fit and work together. Let’s look at the pieces and what insights they each provide the developer.

Figure 1. AAFAA Suite

APIx Manager

The central piece of the AAFAA solution suite is an open-source solution, APIx Manager, which provides API insights to developers in the day-to-day developer workflow. APIx Manager creates a browser-based view that can be shared with the DevSecOps team for a single source of truth on the quality and consistency of the APIs – bridging a critical communication gap. All these features help to manage the API life cycle to provide a better understanding of changes to the APIs we use every day. These can be viewed either through the browser or through an IDE Extension for VS Code. APIx Manager can also optionally integrate with and leverage the power of APIClarity, which brings Cloud Native visibility for APIs.

By creating dashboards and reports that integrate with the CI/CD pipeline and bring insights into APIs, developers and operations teams can have a single view of APIs. This allows them to have a common frame of reference when discussing issues such as security, API completeness, REST guideline compliance, and even inclusive language.

APIClarity

APIClarity adds another level of insights into the AAFAA solution suite by providing a view into API traffic and Kubernetes clusters. By using a Service Mesh framework, APIClarity adds the ability to compare runtime specifications of your API to the OpenAPI specification. For applications that don’t yet have a defined specification, developers can compare an API specification against the OpenAPI or company specifications or reconstruct the Spec if it is not published.

Tracking the usage of Zombie or Shadow APIs in your applications is another critical security step. By implementing APIClarity with APIx Manager, Zombie and Shadow API usage is seen within the IDE extension for VS Code. Seeing when APIs drift out of sync with OpenAPI specifications or start to use Zombie and Shadow at runtime, especially in a Cloud Native application, is vital for the improvement of the security posture of your application.

Panoptica

Adding Panoptica to your AAFAA tool kit brings even more insights into your API usage and security posture. Panoptica provides visibility into possible threats, vulnerabilities, and policy enforcement points for your Cloud Native applications. Panoptica is an important solution as well for being a bridge between development and operations teams to bring security into the CI/CD cycle earlier in the process.

Let’s think about what this means from a practical, day-to-day standpoint.

AAFAA in Practice

As enterprise application developers, we are tasked with building and deploying secure applications. Many companies today have defined rules for applications, especially Cloud Native ones. These rules include things like using quality components, e.g., third-party APIs, and not deploy applications with known vulnerabilities. These vulnerabilities can come in the form of a wide variety of areas, from the cloud security posture, application build images, application configuration, the application itself, or the way APIs are implemented.

There isn’t anything new about this. How we achieve the goal of building and deploying secure applications has changed dramatically in the past several years, with the possibility of vulnerabilities ever increasing. This is where AAFAA comes into service.

AAFAA utilizes three main components in providing insights from the very beginning all the way until the end of an application development lifecycle:

- APIx Manager

- CI/CD pipelines & automatic deployment of applications, and

- dynamic assessments of the API service through APIClarity.

APIx Manager

With its built-in integration into development tools, such as VS Code, APIx Manager is the start of the journey into AAFAA for the developer. It allows developers to gain API security and compliance insights when they are needed the most. At the beginning of the development cycle. Bringing these topics to the attention of developers earlier in the development lifecycle, shifting them left, makes them a priority in the application design and coding process. There are many advantages to implementing a Shift-Left Security design practice for the development team. It is also a tremendous benefit for the Ops teams as they can now see, through APIx Manager’s Comparison functionality, when issues were addressed and if they were a developer, Ops, or joint problem that needed to be resolved or if there was something that still needs attention. From the beginning of the software development cycle to the end, APIx Manager is a key component of AAFAA.

CI/CD Pipeline & Automatic Deployment

With the speed at which applications are being produced and updates being rolled out as part of the Agile development cycle, CI/CD pipelines are how developers are used to working. When we thought about our API solutions, we wanted to bring insights into the workflow that developers already use and are comfortable with. Introducing another app that developers must check wasn’t a realistic option. By incorporating APIx Manager, for example, into the CI/CD pipeline, we allow developers to gain insights into API security, completeness, standard compliance, and language inclusivity in their already established work stream.

There continues to be tremendous growth in Cloud Native applications. Gartner estimates that by 2025, just a short three years away, more than 95% of new digital workloads will be deployed on cloud platforms. That’s an impressive number. However, as applications move to the cloud and away from platforms that are wholly controlled by internal teams, we lose a bit of insight and control over our applications. Don’t get me wrong, there are many great things about moving to the cloud, but as developers and operation professionals, we need to be vigilant about the applications and experiences we provide to our end users.

Dynamic Assessments

APIClarity is designed to provide observability into API traffic in Kubernetes clusters. As developers make the move to Cloud Native applications and rely more and more on APIs and clusters, the visibility of our application’s security posture becomes more obscured. Tools like APIClarity improve that visibility through a Service Mesh framework which captures and analyzes API traffic to identify potential risks.

When combined with APIx Manager, we bring the assessment level right to the developer’s workflow and into the CI/CD pipeline and the IDE, currently through a VS Code extension. By providing these insights into platforms, developers are already using, we are helping to shift security to the left in the development process and provide visibility directly to developers. In addition to security matters, APIx Manager provides valuable insights into other areas such as API completeness, adherence to API standards, as well as flagging company inclusive language policies.

As part of the An-API-For-An-API suite of tools, APIx Manager and APIClarity provide dynamic analysis and Cloud Native API environment visibility, respectively.

What Else?

Several teams here at Cisco have worked side-by-side to create AAFAA. It’s been great to see it all come together as a solution that will help developers and operations with visibility into the APIs they use. The AAFAA project has also been recognized with a prestigious CSO50 Award for “security projects or initiatives that demonstrate outstanding business value and thought leadership.” Please join me in congratulating the team for such a high honor for a job well done.

Source: cisco.com

Continue reading

Optimize and secure transit fleet management with visibility to connected devices and secure remote access

Children have been singing “The wheels on the bus go round and round” since 1939. What’s new today is the tech that keeps those wheels rolling safely and on schedule.

Transit fleet operators work towards achieving on-time performance and vehicle reliability in order to attain safety, cost, and ridership goals. That requires deploying new technologies to improve operational efficiency and predictability. Who doesn’t like a bus service that’s on-time, reliable, safe to ride and has other perks such as free WiFi?

Some ways transit fleet operators are increasing operational efficiency include leveraging vehicle telematics, remotely connected devices in the vehicle, real-time vehicle location, and Internet of Things (IoT) sensors. Together these devices and information provide critical data to the operations center via the Cisco Catalyst IR1800 Rugged Series cellular and Wi-Fi router.

Some of the connected devices on buses today include:

➣ Computer-aided dispatch and automatic vehicle location (CAD/AVL). These transmit route and real-time location information so dispatchers can see if the bus is on time, ahead or behind schedule.

➣ Vehicle telematics to monitor engine temperature, oil pressure, emissions, fuel economy, etc. in support of predictive maintenance.

➣ Fare collection systems for plastic card or mobile payment.

➣ Passenger counting, which is useful for route capacity planning and complying with pandemic-related occupancy restrictions.

➣ IP security cameras that capture video triggered by events like doors opening and closing or the driver pressing a distress button in the event of a disturbance.

➣ Voice communications between the driver and dispatch center.

Operational efficiency takes a hit whenever one of these connected devices, IoT sensors or the vehicle telematics system stops working because buses are often simply taken out of service when issues like these are reported. If the CAD/AVL system goes offline, for example, the fleet operator can’t provide accurate ETAs to passengers on digital signs and online schedules. Loss of the fare collection system results in revenue loss for the transit agency as passengers ride for free. Loss of a video camera feed might prevent the counting of passengers or visibility of a potential safety threat as passengers enter and exit the bus. And an outage on a vehicle telematics system might result in a breakdown that could have been detected and prevented—inconveniencing passengers and requiring the operator to assign an on-call driver and replacement vehicle to take over the route. That’s costly and inconvenient. As fleet operators grow and the number of vehicles that need to be supported increases, these issues are further magnified.

Visibility and secure equipment access boost operational efficiency

Now, fleet operators can quickly detect, assess, and fix problems with connected equipment using the Cisco IoT Operations Dashboard. It’s a modular cloud service with a simple user interface to help operations teams view important data about the health and operational status of connected equipment and sensors, using the IR1800 cellular Wi-Fi router (see Figure 1).

Figure 1 – IoT Operations Dashboard

In the figure above, each dot represents a transit bus. A red dot indicates that one of the connected devices on the bus is malfunctioning. One click shows which system has the problem—such as an offline fare payment system, security camera or passenger counting system. With one click, the operator can learn about the status of connected devices on the bus as well as the router.

With another click the operator can learn more about the failing device and open a remote session to the device, using one of several industry standard protocols, to diagnose the problem or view the device details – providing a fast solution to many problems.

Secure equipment access protects sensitive data from intruders

IoT security is top of mind for critical infrastructure like transportation systems, and we’ve designed IoT Operations Dashboard with Secure Equipment Access (SEA) to connected equipment on the bus. Using this SEA capability, transit Operator employees, or third-party service technicians log into the IoT Operations Dashboard with multi-factor authentication through their browser and use it for remote access to connected devices using common protocols such as SSH, RDP, VNC, HTTP, or serial terminal interfaces, and can even use a native desktop application. And all communication is encrypted over the cellular & Wi-Fi router, preventing unauthorized access (see figure below). This is the essence and power of secure remote access. Lastly, the IoT Operations Dashboard enables operations teams to securely meet the scale demands of today’s fleet operators.

Figure 4 – Secure Equipment Access (SEA) schematic

To sum up, the payoff for being able to securely view, monitor, and troubleshoot all bus connected devices, and IoT sensors from one interface is increased operational efficiency and lower costs. It’s simpler than ever to make sure “the doors on the bus go open and shut, all around the town.” On time, and safely.

Source: cisco.com

Continue reading

Networking Demystified: Why Wi-Fi 6E is Hot and Why You Should Care

Wi-Fi 6E is here and the worldwide Wi-Fi community is buzzing about it. But why is it a major change? What does it mean for people’s Wi-Fi experience and infrastructure vendors like Cisco? And why are Cisco engineers excited about the opportunities for innovation? Read on to learn about the details of 6E and how this technology transition can enhance your career too.

Wi-Fi 6E is More Than Just “A Bit More Spectrum”

At its heart, Wi-Fi 6E extends Wi-Fi to the 6 GHz band of the wireless spectrum. This may not sound very impressive if you know that Wi-Fi currently uses many other bands. Regulatory bodies, like the FCC in the US and ETSI in the European community, allocate to each radio technology the right to transmit in segments of the spectrum and specify the allowed transmission characteristics, such as maximum power or the shape and size of the signal. For example:

◉ In the 2.4 GHz band, Wi-Fi is allowed over a bit more of the 80 MHz of spectrum, with typically up to 3 channels, each 20 MHz-wide.

◉ In the 5 GHz band, Wi-Fi is allowed over up to 500 MHz of spectrum, which enables 25 20-MHz-wide channels. These channels can be configured to be larger, 40 or 80 MHz, at the cost of a lower count of possible non-overlapping channels—12 and 6 for 40 and 80 MHz respectively.

Larger channels are often preferred because they enable the concurrent transmission of more data—much like a larger water pipe carries more water by unit of time—resulting in higher capacity and a better experience for bandwidth-intensive applications like video and AR/VR.

However, even with these options, two neighboring Wi-Fi access points (APs) should not be on overlapping channels because their signals will collide unless one AP waits for the other to finish transmitting before commencing its own transmission. This issue reduces the performance of the overall system. In dense environments—like university lecture halls or enterprise conference rooms—there is always a difficult negotiation to be made between the need for more APs to accommodate more people and their devices by allocating them across many networking pipes, and the need to maximize the size of each AP channel which, in turn, limits the number of APs that can be in the range of each other.

In the US FCC domain, Wi-Fi 6E adds 1200 MHz of new spectrum, creating 59 20-MHz-wide channels, more than tripling the number of channels available. This is great news for any Wi-Fi-dense deployment.

Even in domains where the new allocation is narrower—for example, in Europe with the ETSI domain currently planning to allocate 500 MHz—the number of channels available to Wi-Fi doubles. This means that any place that had 40 MHz channels will soon be able to switch to 80 MHz channels, doubling the capacity and enabling a 1080P video to be upscaled to 4K while maintaining the same experience.

New Band, New Rules

The 6 GHz band was of course not waiting for someone to need it. The 6 GHz space is in fact composed of 4 sub-bands, defined as U-NII 5 to U-NII 8 in the US. All of them are already actively in use by fixed, outdoor devices such as ground-to-space satellite services and point-to-point microwave links. U-NII6 and U-NII 8 are also used by mobile devices—think cable television field trucks sending video back to the main station. Wi-Fi will need to share these spectrum spaces and avoid disrupting the incumbents. For this reason, the rules for Wi-Fi devices depend on the sub-band where they operate.

Figure 1. 6 GHz allocation in the US (FCC domain)

In all 4 sub-bands, APs and clients can operate at a low power mode when located inside buildings. Lower power means shorter transmission distances and thus smaller Wi-Fi cells, but also higher chances that one AP or Wi-Fi client will not hear another unit well enough, causing packet losses or retries.

In two of the 4 sub-bands, APs and clients can operate at higher power—called Standard Power, with a max power comparable to Wi-Fi in part of the 5 GHz band—only if the APs first make sure that they are not disrupting an incumbent transmitter. This verification is not possible in UNII-6 and UNII-8 because, for example, it is difficult to predict where TV trucks will be at any one time, so only indoor and low power are allowed in those cases. But in UNII-5 and UNII-7 bands, for any outdoor operation and any operation at standard power, the AP must verify at boot time, and confirm every 24 hours, that it is not broadcasting on a frequency used by a fixed incumbent. The AP runs this verification by providing its geographical location to a central server—the Automated Frequency Coordinator, or AFC—that returns the 6GHz frequencies allowed in the immediate area. The maximum power allowed for Low Power Indoor (LPI) APs is half the max power of Automated Frequency Coordination (AFC) APs. And since client devices must operate at half the power of the APs, this power puzzle creates interesting Wi-Fi cell design challenges.

Power Spectral Density You Say?

The 6 GHz rules bring another interesting twist. In 5 GHz and 2.4 GHz, the transmission rules are driven by the notion of maximum Effective Isotropic Radiated Power (EIRP), which is the maximum quantity of energy emitted by a client or an AP. As the max EIRP is fixed, a system that transmits over a 20-MHz channel transmits more energy per unit of frequency (per MHz) than a system that radiates the same total amount of energy, but over a wider channel, for example, 80 MHz.

The idea is the same as a water hose. If your hose delivers 1 liter per second, it will spray less water per unit of surface if you spread the jet as a flat 3-meter-wide mist than if you focus the water, power washer style, over just a half square centimeter target. A direct, and sometimes hidden consequence of this rule is that if you set your AP channel to a width of 80 MHz (instead of 20 MHz), your cell size is mechanically reduced because the amount of signal available over each MHz of the channel at a given distance is now lower. A common way to express this reduction is to say that the signal-to-noise ratio (SNR), over each MHz of frequency, reduces as the channel width increases.

The Wi-Fi community expressed this concern when the 6 GHz allocation was being discussed by worldwide regulatory bodies. The great news is that the community was heard, and the rules are different for 6 GHz band. In this new band, the max power is no longer a ‘total max’ EIRP but is defined as max Power Spectral Density (PSD) or the max power per MHz—in the hose analogy, that’s the water delivered per unit of surface. This limit is per MHz and does not change as the channel width changes. In practice, this means that a 6 GHz system can send the same amount of energy per MHz in an 80 MHz channel as it would in a 20 MHz channel, and therefore that the cell size stays the same, regardless of the channel width. It just sends more total energy as the channel size increases.

Figure 2. Power rule comparison between 5 GHz (left) and 6 GHz (right)

A New Golden Age for Wireless Engineering

Another exciting property of the new 6 GHz band is that…well, it is new. This may sound like a repeat, but what it really means is that the industry does not have to design compatibility rules for older devices.

In the 5 GHz band, for example, you may want the benefits of all the goodness of Wi-Fi 6, including efficient scheduling, extremely high throughput, and multi-user simultaneous transmissions, but your network may see older Wi-Fi 5 devices around or even older Wi-Fi 2 devices from the early 2000s. These were probably already obsolete 15 years ago, but the mere fact that they may be there forces all later versions of Wi-Fi, including Wi-Fi 6, to send frames that can be partially understood by older devices so they will detect transmissions and refrain from transmitting at the same time.

This problem does not exist in the new band, so it can be optimized for maximum performance. The clients still have to discover it, which again brings many interesting challenges. For example, scanning 25 channels in 5 GHz, then 59 more in 6 GHz, does not sound like a great idea for fast roaming between APs. So, the discovery mechanism has to have built-in intelligence. Similarly, you may want to keep 6 GHz for efficient traffic, such as your Augmented Reality applications, and send the less urgent traffic, like your background photo sync to the cloud, to the other bands. But this requires a clever exchange mechanism between the client and the AP on resources availability, traffic type, etc.

As you can see, there are a lot of opportunities to innovate and design wireless clients that can benefit from new 6E opportunities.

Join Cisco to Design the Future of Wi-Fi

At Cisco, we have been at the forefront of Wi-Fi innovation for more than two decades. Building the future of Wi-Fi starts by designing great access points, and smart engines to optimize the experience that wireless clients can gain from optimized networks. Engineers working at Cisco take pride in designing the smartest AI-driven Radio Resource Management engine on the market to dynamically assign channels and power levels to neighboring APs. This creates smooth continuous Wi-Fi coverage from small branch networks to large venues like Mobile World Congress, where 1500 APs and 75K+ simultaneous radio communication professionals expect nothing less than a perfect Wi-Fi experience. Other Cisco innovations include OpenRoaming to automate onboarding, and Fastlane+ to optimize the experience of your Apple iPhone and iPad in a Cisco Wi-Fi 6 network. The full list of Cisco wireless innovations would take a book to enumerate. And with a brand-new 6E band available on our new access points, the opportunities to innovate are bounded only by your imagination and talent.

Source: cisco.com

Continue reading

Are Cisco 300-430 ENWLSI Practice Tests Useful?

Like all IT certification exams, Cisco 300-430 ENWLSI has special traits and particularities that anyone aspiring to take this exam requires to take notice of, be it someone, anywhere in the world.

These involved peculiarities are not just essential in taking the final exam but evenly important to receiving a flying score on the first attempt and finally attaining the associated certifications.

Continue reading

First Code… Then Infrastructure as Code… Now Notes as Code!

First, let me say how we take notes and what tools we use are admittedly a personal preference and decision. Hopefully, we are doing it, however!

Most of us are creatures of habit and comfort – we want it simple and effective. When we put that developer hat on as part of our DevOps/SRE or AppDev roles it’s optimal when we can combine our code development environment, or IDE, with a tool that we take notes in. I’m sure most of us are using Microsoft’s Visual Studio Code app as we write Python or Go-based scripts and applications during our network programming and automation work. I probably knocked out 4,500 lines of Python in support of the CiscoLive Network Operations Center (NOC) automation earlier this summer and VS Code was integral to that.

Microsoft Visual Studio Code with a CiscoLive NOC Python Script

You’re probably familiar with VS Code’s strong integration with git from your local development environment and the ability to synchronize with remote GitHub repositories. It’s a great feature to ensure version control, provide code backup storage, and encourage collaboration with other developers.

GitHub with a CiscoLive NOC Software Repository

I was encouraged to find an extension to VS Code that follows the concept of ‘Docs as Code’. If you’re not familiar, I’d encourage you to follow my esteemed Developer Relations colleague, Anne Gentle, who is leading much innovation in this space. Anne describes this concept in her GitHub repo.

The extension I use is called Dendron. It is more officially known as an open-source document management system. It allows for hierarchical documentation and note-taking. It uses the same, familiar markdown concept for text formatting, document linking and image references, as you would use with GitHub,  Webex messaging app or Webex API. You can journal and have your thoughts organized in daily buckets. Document templates are supported. I find the supplied meeting notes template as pretty useful and extensible. As a proof of Dendron’s flexibility, I wrote this blog in Dendron before passing over to the publication team!

VS Code with Dendron Extension: Note Taking Panel with Preview

I appreciate the hierarchical model of taking notes. I have sections for my team notes, my projects, the partners and customers I’m working with, and one-on-one meeting notes. The hierarchy works down from there. For instance, this note is stored in the VS Code workspace for Dendron, and its vault, as ‘MyProjects.blogs.Notes as Code.md’.  I also have a ‘MyProjects.PiK8s.md’ for a Kubernetes environment on a cluster of Raspberry Pis – more on that soon!

Dendron is capable of efficiently and quickly searching and managing tens of thousands of notes. When I finish a project, I can refactor it into a different hierarchy for archive. The links within the original note are re-referenced, so I don’t lose continuity!

I’m not ready to do this refactor just yet, but here’s a screensnap of it confirming the movement of the note across hierarchies. I tend to put completed projects in a ‘zARCHIVE’ branch.

Dendron Extension Using Document Refactor Feature

Dendron also supports advanced diagramming with the mermaid visualization syntax. This next image is a linked screen-capture of the Dendron writing panel adjacent to the preview panel where I imagined a workflow to get this blog posted.

Dendron Markdown with Preview Showing mermaid Flow Chart

Network protocol and software inter-process communication can be documented as sequence diagrams also! Here’s my tongue-in-cheek representation of a DHCP process.

```mermaid

sequenceDiagram

participant Client

participant Router

participant DHCP Server

Client->>Router: I need my IP Address (as broadcast)

Router->>DHCP Server: (forwarded) Get next lease

DHCP Server-->>Router: Here's 192.168.1.100

Router-->>Client: You good with 192.168.1.100?

Client->>Router: Yes, thank you

Router->>DHCP Server: We're all set!

```

The markdown and preview behind the scenes looked like this…

Dendron Markdown with Preview Showing mermaid Sequence Diagram

So, How Can I Use This?

An effective way of using VS Code with Dendron would be in concert with the notetaking and documentation you do for your git repos. Since Dendron notes are effectively text, you can sync them with your git repo and remote GitHub publication as your README.md files, LICENSE.md and CONTRIBUTING.md, which should make up the foundation of your documented project on GitHub.

Source: cisco.com

Continue reading

FFIEC Cybersecurity Maturity Assessment Tool

Financial institutions have to be vigilant in the face of a continually evolving cybersecurity threat landscape. As these have attacks have evolved, regulatory bodies have updated their regulations to account for the increasing threat of cyber risk. In 2015, following a significant increase in nation state and hacktivist attacks on U.S. financial institutions, the FFIEC released new guidance and a Cybersecurity Assessment Tool for institutions to self assess their risks and determine their cybersecurity maturity. This was revised in 2017, and this consistent framework is intended to be able to help leadership and the board assess their preparedness and risk over time. This framework is especially relevant given the recent FFIEC Architecture and Operations update and the Executive Order on Cybersecurity from 2021.

The purpose of this blog is to assist our IT based customers and partners with a concise and high level understanding of the FFIEC Cybersecurity Assessment Tool and derivative impacts on their current and future day to day operations. It is part of a multipart blog series on financial regulations and how to manage them architecturally, geared towards IT leadership.

The Cybersecurity Assessment Tool is fairly intuitive to use and the exercise should not be arduous for an organization to complete. The assessment applies principles of the FFIEC IT Handbook and the NIST Cybersecurity Framework. The intention here was to be complimentary to existing frameworks and supportive of existing audit criteria. The FFIEC has released a mapping of the Cybersecurity Assessment Tool and the NIST Cybersecurity Framework to the FFIEC IT Handbook.

How the Assessment works:

The assessment itself involves two primary components: an institution first creates an inherent risk profile based upon the nature of their business, and determining cybersecurity maturity. The inherent risk profile is an institution’s analysis of its key technologies and operations. These are mapped into categories and include:

1. Technologies and Connection Types

2. Delivery Channels

3. Online Mobile Products and Technology Services

4. Organizational Characteristics

5. External Threats

The tool itself provides guidance on criteria to sell assess risk based on the different characteristics of an organization, which simplifies completion as well as consistency. By having explicit guidance on how to self assess into different risk categories, the leadership for the institution can ensure they have a consistent understanding of what the risk entails.

Below is a snippet of the inherent risk profile, of note is the intuitive and consistent guidance on how to classify risk within each domain.

The second aspect of the assessment is understanding cybersecurity maturity. This section can help leadership understand the risk and appropriate controls which have been put into place. It creates five levels of maturity, from baseline to innovative, and we use these to measure preparedness of the processes and controls for five risk domains:

1. Cyber Risk Management and Oversight

2. Threat Intelligence and Collaboration

3. Cybersecurity Controls

4. External Dependency Management

5. Cyber Incident Management and resilience.

The five domains include assessment factors and declarative statements to help management measure their level of controls in place. What this means is there are statements within each assessment factor that describe a state. If those descriptive statements matches a financial systems controls, then they can claim that level of cybersecurity maturity. Of important note however, as in the picture above, the levels are additive, like a hierarchy of needs. What this means is that if there is a statement in innovative that matches some of your organizations controls, but you haven’t satisfied the statements in the “advanced” guidance, you can not measure your institution as innovative in that domain. Likewise, an intermediate level of maturity assumes that all criteria in the evolving level, have been met.

The five domains each have various assessment factors. For example, in cybersecurity controls there are assessment factors for preventative, detective, and also corrective controls. Each of these assessment factors will have contributing components which are then measured. An example of this is within the preventative controls assessment factor, there is components such as “infrastructure management” and “access and data management”.

It becomes easier to envision when evaluating the assessment document and the corresponding components. As can be seen in the below cybersecurity guidance, there are a number of explicit statements that describe maturity at a particular level and mapping to regulatory requirements. Through satisfying these statements you can appropriately match your institution to its level of cybersecurity maturity.

The Next Step

Following completion of an inherent risk profile and cybersecurity maturity an organization can determine if they have the appropriate controls in place to address their inherent risk. As inherent risk increases, obviously a higher level of security controls should be positioned to provide a level of control around that risk. A conceptual guidance on how risk should map to maturity is outlined below. Where this becomes important is not only in determining a point in time deficiency, but understanding that as new projects, acquisitions, or the threat environment changes, leadership can understand whether increases in security controls need to be applied to adequately address a material change in risk level.

Derivative Impacts on Infrastructure and Security Teams

The Cybersecurity Assessment is a useful tool for financial institutions to consistently provide leadership a synopsis of the state of the institution. But how this translates downstream to day to day operations of architects may not be explicit. There are a number of areas in the Cybersecurity Maturity section where explicit guidance is given which we have seen undertaken as projects at our customers, as well as across the industry. Below are a few themes we have seen gain in prominence since the publishing of the assessment. These weren’t generated by the assessment itself, but are common themes across the industry. Through this blog, the intent is more to provide a high level synopsis of how these projects influence, and are influenced by, and measured through, the regulatory bodies.

1. Segmentation is explicitly called out with guidance given on how to measure. We have seen this translated across the industry as both Macro and Micro segmentation approaches, and both of these are complimentary. These have driven technologies such as SD-Wan, SD-Access, ACI, and VXLan based segmentation.

2. Managing infrastructure and lifecycle hardware and software versions are measured. This practice isn’t specific to just this assessment and it has become a common theme to be able to keep devices in patch management. It is a shift from some institutions “sweating their assets” to a proactive model for managing. What had been observed was “hackers love sweaty assets”, with most exploits targeting known vulnerabilities. This should translate into any new technology investment having a lifecycle that can ensure the full depreciation of the asset while maintaining patch management.

3. Analytics and telemetry have driven significant investments in cybersecurity operations team’s ability to understand and act upon emerging threats in real time. Leveraging existing assets as sensors or sources of meaningful telemetry is important as deploying dedicated appliances to the larger attack surfaces of campuses, branches, and wireless  nd can be prohibitively expensive plus operationally unsupportable.

The above is just a few of the many derivative impacts that affect our infrastructure and security teams. With increasing nation state guidance on security and privacy, to include the U.S. Executive order on Cybersecurity, additional tightening of conformance to address evolving security risks is happening. A lot of the increased focus aligns to areas which occur within existing domains that are included in existing frameworks. The FFIEC Cybersecurity Maturity Assessment is a simplified tool that can help a board member understand which security controls should be addressed first.

Source: cisco.com

Continue reading

Top Resources to Streamline Cisco 350-401 ENCOR Exam Preparation

The Implementing Cisco Enterprise Network Core Technologies exam, also known as the 350-401 ENCOR, is a significant challenge. It is a prerequisite for four distinct Cisco certification paths, i.e., CCNP Enterprise, Cisco Certified Specialist – Enterprise Core, CCIE Enterprise Infrastructure, and CCIE Enterprise Wireless.

Continue reading