Throwback to the roots of Cisco Meraki: Connecting the next billion people

    A quiz in the Meraki Insiders program triggered my Sherlock Holmes sense to deep dive into the early days of Cisco Meraki. The origins of Meraki can be traced back to a project called Roofnet at MIT. About 1 billion people were connected to the internet back in 2007, while 5 billion more still needed connectivity. So how do we connect the next billion? The challenge lies on the last mile, where they needed to connect the end customer to the nearby towers or centrals. The rest of this post will explain the Meraki solution to solve this global challenge. 

Fig.1 Meraki solutions in 2007

The existing solutions

    Let's look at the existing solutions from back then. The most common approach in the US was using Wi-Fi distributed by access points installed in streetlight towers by the municipality. The cost to cover every area with Wi-Fi by this approach was proving to be ineffective, and the actual performance in the last mile was not acceptable without some kind of indoor repeater. Each AP cost $3500, not including installation. In terms of performance, some employees of Google had reported that they needed to keep the laptop by the window, if they were to have some acceptable signal. 

    Another alternative was subscribing to a dedicated DSL line, which provided better performance but at a considerably high monthly cost, more than $100 for each single installation. This solution required extensive infrastructure, making scaling problematic. This approach has had its share of success, as even today we see it implemented on the last mile towards the customer in many places in the world, including Denmark. However, the speed of deployment has been a challenge, similar to the one we face today with distribution of fiber. 

The MIT Roofnet

    One of the very first concepts of a mesh network came from the MIT Roofnet project. It aimed to create a community wireless network that was self-configuring and easy to scale, using omnidirectional antennas for simplicity and fault tolerance. As you might guess from the name, the antennas would potentially be installed on the roofs. 

    In terms of technical challenges, it addressed the ones of unstable links and self-interference through a routing protocol (SRCR) that optimizes routes based on real-time link quality. This approach allowed Roofnet to offer internet performance comparable to traditional infrastructures, through a user-friendly installation process, indicating that community-operated networks can be effectively deployed and maintained. This ingenious idea is the very start of the Cisco Meraki we know today. Some of the most important design decisions of Roofnet are:

- Unconstrained node placement, so you just use an ad-hoc concept, without needing to design all node placements beforehand. 

- The use of omnidirectional antennas, eliminating the need to know in advance who you will connect to.

- Assuming networks consist of slowly-changing, intermediate-quality links.

Here is a picture of the Roofnet and the performance measured on the individual links. 

Fig.1 MIT Roofnet as seen on 22 july 2003

    You can find a link to the full publication at the end of this post, if you are interested in more technical details. But now let's focus on how this could solve our previous issue. 

The Meraki Mesh

    Roofnet became the start to what we know as Cisco Meraki today. They came up with several solutions which were supposed to help with the adoption of the internet at an acceptable cost and performance. 

    The first AP that was produced was called Meraki Mini, and there are still today 191 that are online, almost 20 years later. Can you believe that? You can see a list of the first products in the following photo.

Fig.2 Meraki gear in 2007

    Meraki was working on different solutions that were more cost-effective than the DSL and more reliable than the municipality Wi-Fi. Rather than using expensive APs on light towers, the solution involved installing repeaters in each home, following the concept used by Roofnet. These repeaters would connect to each other by building a mesh network, one of the very first of its kind. The cost of a repeater was only $49, and it could be shared by several homes. By using this mesh concept, Meraki managed to create communities of 300–500 people that shared a couple of DSL lines.  They even introduced solar-powered Wi-Fi to keep costs down, at $99 per repeater, and in some areas provided free AP's for the sake of the expansion. 

    Operators had the freedom to set their prices. Meraki provided the software for managing the solution and processing payments, taking a 20% share of the providers' profits. As their CEO back then said: "You probably have a better idea of what you should charge in Zimbabwe than I do."

    I found the following product description of the Meraki Mesh solution on their website from 11 October 2007 that you can see here below:

Fig.2 Meraki mesh product description. 

    In terms of expansion, Meraki has grown from a few thousand networks in 2007 to over 100 000 in 2012, when it was acquired by Cisco and recently to an incredible number of over 4.75 million, thanks to the Cisco magic. 

Conclusion

    This post describes some of the first steps that turned Meraki into one of the leader of cloud controller Wi-Fi, routing and security. The small Roofnet project became the start of the journey towards solving one of the biggest challenges of the early internet, bringing the next 5 billion people online after the first one. The post is also providing some useful links at the bottom, if you share the same curiosity as I do about such an exciting journey. 

References

Roofnet Abstract

New York Times Article: Wireless Internet for All, Without the Towers

Cisco Meraki website in 2007

Read More

My own path to CISSP: Embracing a Management Mindset

    During the last 10 months, I’ve been working on getting CISSP certified. It started as a natural first step after passing the CCIE and the Microsoft Cybersecurity Architect exams. I wanted to go after a management certification, which was not tied to a specific vendor. Initially, I considered the Certified Ethical Hacker (CEH) certification, but given my current management role, CISSP sounded like a better choice.

Fig.1 The CISSP confirmation mail

How I got here?

    CISSP is considered to be one of the most respected security certifications in the industry. The first time I heard about it was while working on a project at Societe Generale in Albania about 12 years ago, where the CISO had these thick books on his table, similar to the ones I was used to from the Cisco world. Back then I was 100% Cisco minded, so that wasn’t tempting for me. As mentioned it was 10 months ago I really got into track.

Fig.2 My first LinkedIn Post about CISSP

    Right after making my mind that this was the right way to go, I purchased the official certification guide along with several Udemy courses taught by Thor Pedersen. This was a no-brainer as everyone suggested those resources to start with.

    In addition, I’ve spent a lot of time on developing our own Compliance Services, focusing on NIS-2, to assist customers of Critical Infrastructure in Denmark in protecting from cyberthreats. 

    Whenever I’ve found something interesting on the book, I’ve shared posts on my own blog or LinkedIn. You can find some of them at the end of this post.

    Since CCIE took a lot of my free time, which I would otherwise have dedicated to my family, I decided to follow a different approach this time. I utilized any “spare” time, where I wasn’t doing anything with them. This was mainly watching Udemy videos while preparing dinner, and reading the certification guide before bed, instead of browsing 9gag. There have also been a lot of deviations from the standard, like using the time at the hospital, while we were expecting our second child, to read about 300 pages from the official certification guide, or reading several pages while sitting on the VIP lounge at home. 😉

Which resources did I use?

The primary resources for my preparation were:

• Udemy CISSP videos from Thor Pedersen. He is the go-to trainer, when we talk about CISSP. He has the largest pool of students and the highest rating. 
• (ISC)2 Certified Information Systems Security Professional (CISSP) Official Study Guide, 9th Edition
• There are many different standards you can read, but I focused mainly on CIS v.8, NIST, IEC62443 and the upcoming NIS-2.

    Besides these resources, I have a lot of background info from the previous Microsoft Cybersecurity Architect Exam as well as all kind of different Cisco certifications I’ve been through over the years, which proved to be very beneficial on the exam.

How was the exam?

    If I had to say it with one word, I would say confusing. Nothing compared to CCIE in terms of difficulty, but it still required a lot of focus when reading the questions. Many of them had several correct answers, requiring the selection of the most appropriate one. What worked for me was to “Think like a Manager”. This is one of the main reasons why I wanted to do CISSP in the first place, to shift my mindset from the technical solutions, to the strategy, design, governance. So, moving towards a helicopter view and focusing on what would benefit the business, instead of picking the right technical solution.

    There was a ridiculous amount of questions which I went through in 3 hours, with very few of them where I was 100% certain to have provided the correct answer. I was kinda surprised when I saw the mentor smiling, after those mixed feelings while going through the exam. Then I looked at the paper, and it said “Congratulations”…

Why should you take the CISSP exam?

Here are some of the most important benefits according to me:

• Changing your mindset from a technician to a manager
•  Absorbing a large amount of security topics in a short amount of time
• Linking the technical solutions to the risk they address
• Learning about physical security

Conclusions

    CISSP has been a great training that has helped me in changing my mindset from technician to manager, as well as building our own compliance services. Going through such a large pool of subjects makes you understand how bread the security field is. CISSP may not be suitable as a first cybersecurity certification due to its high-level content and the requirement for at least five years of documented experience. You can find more relevant trainings from Cisco and Microsoft in the references below. 

References:

My own posts related to CISSP:

Shared Responsibility Model: #cissp and pizza ~ Ibrahim Ramku - Blog

The evolution of switches ~ Ibrahim Ramku - Blog

Cryptography Post

CISSP Training materials:

Thor Pedersen - Udemy

CISSP Official Study Guide - 9th edition

Start your career in CyberSecurity with these trainings:

Cisco - Intro to CyberSecurity

MS - Cybersecurity Fundamentals

Different standards:

CIS v8

NIST

NIS-2

ISA/IEC 62443

Read More

CCIE Coffee Blogs: #3268 Kujtim Tali

 This is the very first blog post of a series of posts about Albanians that have achieved the much wanted CCIE status. It's meant to provide some background info for the CCIE Hall of Fame for Albania and Kosovo. I've decided to call the series CCIE Coffee Blogs, as most content here will be non-technical. The goal is to inspire young Albanians to pursue similar paths like our much respected guests. Dall-E helped med turn my idea into the following logo. 

Fig.1 CCIE Coffee Blogs

Meet Our First Guest: Kujtim Tali

Our first guest is Kujtim Tali. Kujtim is the first Albanian that reached the CCIE status already in 1997. You can tell by his number 3268, that there were only a couple of thousand people that had passed the exam back then, while now we have over 70 000 people that have. I've had the honor to direct some questions to him about his background as well as current insights. 

Fig.2 Kujtim Tali CCIE #3268

1. How did you start your career in networking? What is your educational background?

- I began my career in networking after completing my undergraduate degree in Electrical Engineering at the University of Prishtina. Following this, I pursued a Master's degree in Computer Engineering at the Illinois Institute of Technology.

2. What inspired you to pursue the CCIE certification? What were the biggest challenges you faced?

- My inspiration to pursue the CCIE certification came during the era when IP was becoming a dominant force in networking. I started with Novell NetWare and was among the first to earn the Certified Novell Engineer (CNE) and Master CNE certifications. Transitioning to IP networks, X.25, Frame Relay, ATM...... and Cisco products was a natural step for me. The biggest challenges I faced were the scarcities of materials and equipment. I was fortunate to work with major Telecom operators and Equipment Vendors like ATT, Juniper, Tellabs, and Cisco.  

3. What is your current job role? How does your CCIE certification contribute to your daily work?

- Currently I am founder and chairman of the board of the Telecom Infrastructure Services Company, 3CIS, I attribute a percentage of our success to the experience I gained after getting my CCIE certification. This certification extended my roles at major telecom companies, laying a solid foundation for my professional journey. These roles were important in building an extensive network of contacts and expertise, which later became crucial for 3CIS. In essence, the CCIE certification was not just a personal achievement; it was one of the cornerstones that enabled me to establish and grow 3CIS into what it is today. The relationships and experiences I gained as a result of this certification played a central role in acquiring the clientele that continue to be fundamental to 3CIS.

4. What advice would you give to those aspiring to achieve the CCIE certification? 

- My advice to aspiring CCIEs or really anyone would be to pursue your dreams and not to lose focus on what you want to build for yourself, no matter the obstacles. 

5. What are your professional goals for the future? How do you plan to advance in your career?

- My goal in the future is to conitnue mentoring and supporting upcoming engineers in achieving their goals. It is a commitment of mine to contribute to the growth and success in the field. 

6.  Can you share an interesting fact about yourself or a hobby you enjoy outside of work?

- Throughout my career, I've had commitments all over the world, leading to over four million miles of travel. This has made me miss a lot of valuable family time. So my current hobby is simply my family.

In talking with Kujtim, it's clear that combining the CCIE with dedication to building a professional network is the way forward. Through the 'CCIE Coffee Blogs', I look forward to bringing you more inspiring stories from the CCIE Hall of Fame, focusing on the achievements of Albanian professionals in this challenging field of networking.

Read More

Shared Responsibility Model: #cissp and pizza

This blog post focuses on the shared responsibility model with focus on cloud. There is nothing better than explaining a complex topic by using an analogy to something we all love, the pizza. 

What is the Shared Responsibility Model?

The shared responsibility model is used by service providers, primarily in cloud, to define who is responsible for the services and resources. It's very important to understand it, as there is some misconception amongst customers on who has the responsibility for information, data, network, operating system and the physical elements when their workload is shifted towards cloud. The following diagram illustrates the areas of responsibility between Microsoft and customers when deploying resources on the cloud or onprem. 

Fig.1 Shared Responsibility Model

The key thing to understand in this model is that any workload you move to the cloud doesn't move your responsibility fully to the cloud provider. In the diagram on Fig.1 you can see that the model with less responsibility on your side is SaaS, while the one where you are fully responsible is once your resources are 100% on-prem. I meet customers almost on a daily basis who don't understand this model. Some of them think that moving workload to the cloud means automatically that you have backup, security, redundancy built in. Even though the cloud does facilitate these services, it is your responsibility to activate and maintain them. The worst scenario I've personally experienced was a relatively big company in Europe having some workload in a datacenter in UK, without any backup or security, who ended up deleting the whole workload with one click. This was possible as that datacenter had a "red button" that would decommission everything at once. You can imagine how hard it was to restore the services afterward. 

Despite the simplified diagram in the picture above, the reality is that a lot of companies still don't fully understand the model and have problems with translating it to their own services. In order to simplify this, we will be using another well known shared responsibility model, based on pizza. 

An analogy we all love

Let's imagine that we have built Pizza as a Service. You can get it delivered (fully managed service), pick up a pizza that is ready to bake at the closest supermarket (partially managed), or just go all in and make one from scratch at home (unmanaged service). This is similar to the choices you have with IT services:

Fig.2 Pizza as a Service

Fully Managed : Here, the service provider handles everything. In the pizza world, this is like ordering a pizza via phone and getting it delivered, hot and ready to eat. In IT Services, this is the same as fully managed services where the provider takes care of the infrastructure, security, and maintenance. This is similar to the SaaS service in the diagram above. 

Partially Managed : This is us going to the closest supermarket and buying a ready to bake pizza. We are responsible for baking it at home, but the pizza is ready, we don't need to make the dough, the topping etc. In IT Service terms, this means the service provider manages the infrastructure, but you're responsible for some aspects of the configuration and security. This would Infrastructure as a Service and Platform as a Service.

Unmanaged: This is us making a pizza from scratch at home. We need all the ingredients, oven, and the skills. Similarly, in an unmanaged IT service, you're responsible for all aspects. This would be us bying a server for our private datacenter, installing OS, preparing networking, installing applications and so on. We have full responsibility to maintain and update it, and we need the skills in-house. 

How does all this tie to CISSP?

As you might already know, CISSP is built on different domains. Even though the shared responsibility model is not directly tied to the specific domains, it can easily be translated to some elements that can be tied to them.

Security and Risk Management domain focuses on understanding and managing risks. In our analogy from before, we need to know what risks we have on each level of service, whether it's fully managed, partially managed or unmanaged. It's very important to evaluate the security measures that are taken by the provider and the ones that we as a customer need to implement.

Asset Security domain on the other end focuses primarily on protecting the assets, which could be translated to data, applications and infrastructure. We need to ensure security measures have been taken on each asset either by us, or the provider.

Security Architecture and Engineering is mostly focused on design and implementation of security architectures. We need to understand each model, from SaaS, IaaS, PaaS, on-prem so that we can evaluate the impact each one of them has on the security responsibilities. This will help us design secure architectures wherever our workload resides. 

Communication and Network Security is also very critical in Cloud Services. It's critical to make sure that we have secure networking and transmissions in the cloud and from cloud to on-prem. We need to make sure that the pizza we get delivered (data transmission) doesn't get messed up on the way to our door. We need to understand how much of the network security is the provider's responsibility and how much is ours. 

We could go on and provide further considerations from the rest of the chapters, but as long as you understand the model it should be possible to make informed decisions, ensuring that both you as a customer and your provider play the part in maintaining and securing the environment. 

Conclusion

In conclusion, the Shared Responsibility Model in cloud computing, much like our pizza analogy, reveals the importance of understanding the various layers of responsibility, whether you're choosing a cloud service or deciding what kind of pizza you are eating for dinner. Just as you would decide between ordering a fully prepared pizza or baking one from scratch, in the cloud environment, you need to make sure your choices take into consideration the security aspects that you will manage and the ones that your provider will. 

References

Shared Responsibility Model - Amazon Web Services (AWS)

Shared responsibility in the cloud - Microsoft Azure | Microsoft Learn

(ISC)2 CISSP Certified Information Systems Security Professional Official Study Guide

Read More

The evolution of switches

The evolution of switches: #cissp insight

Did you know that switches were already introduced in the 19th century? Voice switches, also known as circuit switches, were the backbone of communication networks. Invented in the late 19th century, these switches established a dedicated circuit between two points for the duration of a call. While effective, this method was resource-intensive, limiting the number of simultaneous calls that could be handled. Early switches required also significant human intervention for line establishment, posing security and reliability challenges. In the next sections, we will deep dive into the most important elements of switches and the security concerns we have today. 

Fig.1 The transition from voice switching to packet switching

When did it all start?

The 1970s and 1980s marked the beginning of a new era with the introduction of packet switching, a concept which initially began with the invention of ARPANET, the predecessor of the modern internet. Unlike circuit switching, packet switching sends data in smaller packets through various routes before reassembling at the destination. This approach optimizes network efficiency and resource utilization. 

Our office museum has a telephone switchboard, which you can see at the following picture:

Fig.2 Office museum telephone switchboard

Why packet switching?

1. Improvement of efficiency: Packet switching allows multiple communications to share the same network bandwidth, significantly enhancing network efficiency compared to the dedicated paths of voice switching. If you were to compare it to a transition that is happening today, it would be the switch over from dark fiber to MPLS and later on to SD-WAN. 
2. Scalability: As the demand for data services grew, packet-switched networks proved to be highly scalable, accommodating more users and diverse data types without the need for expansion of the underlying infrastructure. 
3. Cost Optimization: The shared network approach of packet switching reduces operational costs. It eliminates the need for dedicated circuits for each communication, lowering both capital and maintenance expenses. This is also similar to the transition to SD-WAN. 
4. Additional capabilities: The switchover meant that the traditional circuits would also open up for other kinds of traffic than voice, which is basically what happened in the next few years.
5. Resilience and Flexibility: Together with opening for other kinds of traffic, new capabilities were also introduces, like the ability of packet-switched networks to reroute data through multiple pathways, which enhances network resilience against failures and congestion.

What has changed?

Since then a lot of things have changed. Today we have an unthinkable transmission speed, from a few bps to gigabit or terabitps speeds. The initial packet switches didn't have any modern protocols supported, like MPLS, QoS etc. Their main purpose was to do basic data routing. Today we can see switches that also do dynamic routing, switching, have firewall capabilities and even VPN or IDS features. With the recent developments of AI we expect more machine learning and predictive analytics functionality, as well as possibility to automate troubleshooting and optimize networks. It will also help with securing that these systems are configured in alignment with the organization security policies. 

What are some of the most common attacks against switches?

As this is a CISSP focused post, it's normal to discuss the security aspect. Historically the focus was in external threats to the company, but now we need to implement zero-trust principles as internal threats are equally important.

Fig 3. Switch Security

 Some of the security concerns we face today are:

1. MAC flooding, which basically is going to fill the MAC address table of the switch, causing it to become a hub and broadcasting packets to all ports. A hacker could sit on one of the ports and mirror the traffic to his PC. 
2. ARP poisoning. In this case, the hacker would send a fake ARP response over a local area network to behave as if they were one of the legitimate hosts. Years ago I experimented with an old rooted android phone. By using an app to poison ARP, I was able to hijack sessions and change all pictures on all websites that my colleagues visited at the office. Fun times...
3. VLAN hopping. The hacker would add some extra VLAN tag to the packet, so that when the actual vlan tag was removed, the switch would see this hacker tag and send the traffic to a different VLAN than the original one. 
4. STP manipulation. Knowing how Spanning Tree does the root bridge election, the hacker would install a switch in the network and make it the root bridge, which would then send all traffic through it. This can be a devastating attack and can happen also due to a mistake. I've experienced shortage on multiple cities many years ago, because some misconfigured switch was connected by some end customer to the ISP network. Then the traffic for all those cities would tend to go through this single location and get black holed. This would come handy to a potential attacker, as all traffic would go through their switch, and they would have the possibility to perform Man in the Middle attacks. 
5. DoS and Vulnerabilities. The attacker could either overload the switch with traffic, or exploit some vulnerability. Vulnerabilities have more and more focus nowadays, considering the increasing threat landscape.

How do we mitigate them?

There are several mechanisms we can use to protect our switches. Here come some of the most important ones:

1. Port Security. This is one of the first things that should be implemented in a modern network. Unauthorized devices should be prevented to connect to a network and the amount of MAC addresses learned through the ports should be limited, to avoid MAC flooding. 
2. Dynamic ARP inspection. To prevent poisoning of ARP and the possibility to hijack sessions like explained on point 2 above, ARP packets should be inspected, and the invalid ones should be blocked.
3. Secure VLANs. There are several things to consider, but default and native VLANs should not be used, and access lists should be implemented to isolate traffic between networks. 
4. STP Root Guard and BPDU Guard. These mechanisms would prevent an unknown switch from connecting to our network and making devastating changes, like the ones explained on point 4 above.
5. Regular updates. The only way to protect from vulnerabilities is to keep the software updated and reduce our exposure. Back in the old days, it was normal to brag about how many years a Cisco device had been on for. This is no longer an option today, and in the best case it should be mentioned as something to avoid. We still face gaps in this area when we analyze customer networks. The best option would be to implement switches that can be updated automatically. 
6. Network Segmentation. The network should be divided to smaller subsets, like VLAN's and private VLANs. Furthermore, the traffic between these subsets should be limited by access lists. Ideally, the network should filter by TCP/UDP port and IP. 

There are many more mechanisms that can be implemented to increase security, which we will not address on this post, but having most of what is mentioned here in place is a good first step towards securing the internal domain. 

Conclusion

The modern day switches come from an invention that started back in the 19th century. Since then a lot has happened, which testifies the human effort and desire to improve. It also reflects an adaptation to the growing demands of a digitally connected world, offering improved efficiency, scalability, and expansion of communication capabilities. The introduction of AI is going to push further into the simplification and increase of capabilities towards a more digitized world, as well as simplify the secure implementation of them in accordance to the company policies. It will also pose new security risks, which we need to address. It's important to implement security with zero trust principles and take extra steps to secure the internal domain. 

References

(ISC)2 CISSP Certified Information Systems Security Professional Official Study Guide: CISSP Domain 4: Communication and Network Security

General MS Best Practices - Cisco Meraki

Image courtesy: DALL-E

Read More