🤦🏻 😽 🎪 How has Cisco been operating in remote access mode and an absent perimeter for 20 years? 👲🏽 👴🏻 👏🏿

For about 20 years, Cisco has been living without the usual perimeter, and its employees enjoy all the benefits of remote work. I remember when I came to Cisco in 2004, I got a corporate laptop with the installed Cisco VPN Client and got the right to work from ... but from anywhere. During this time, I worked from home and hotel, from the train and taxi, from the plane at an altitude of 10,000 meters and in the subway. In fact, we have implemented the principle of "work where I am," and not "I where work is." How did we manage to do this? How did we implement the concept of a “trusted enterprise”, which has been helping us for many years not to notice unpleasant events that make many of us feel homeless (of course, there are a number of processes that require physical presence, for example, the production of equipment)?

I will begin with the fact that the majority of Cisco employees live by the principle of “feeding the wolf’s legs”, that is, it is constantly in motion. Someone goes to customers, someone to partners, someone to contractors and suppliers, someone speaks at various conferences. Of course, there are those who work mainly in the office, but these employees have the opportunity to work outside the office. This approach, adopted many years ago, forced us to reconsider the traditional IT architecture, which implies the presence of a perimeter that encircles the company and its valuable IT assets, and one or two controlled crossing points of this border. Today, in Cisco data, you can navigate between any users, any devices, any applications located anywhere. Of course, we are talking about controlled movement.But in any case, we are no longer constrained by the concept of “perimeter”, abandoning it even when the term “deperimetrization” (you won’t pronounce it the first time, right?) Was not yet in use, and the concept of Zero Trust was not even born .

Then our IT service, together with the cybersecurity service, thought about how to make sure that, on the one hand, company employees could work, I won’t be constrained by the requirement that most of the time is inside the corporate perimeter, and, on the other hand, the company's data and applications were reliably protected from a wide range of threats. We tried many different options, but they all had certain flaws, since the weakest link in them was the laptop of a remotely working employee who was not in the shadow of corporate security tools and could become an entry point into our network for attackers. And attempts to force users to always work in a VPN in order to "wrap" all traffic on the perimeter, where to check it, did not give an effect, since when actively moving around the world and moving to a cloud-based work model,“Drive” all traffic even through VPN gateways installed in different regions was very inconvenient, as it introduced delays in the work of users and their applications. As a result, we came to the concept of “trusted device”, which later transformed into what we called a “trusted enterprise”. According to this concept, we live now.

The idea of a trusted enterprise is quite simple and is based on 4 pillars:

Trusted identity (sorry, the English-language Trust Identity is not easy to briefly translate into Russian), implying that before any access attempt, we identify and authenticate any user and device (and later applications) who want to access corporate resources hosted within the company or in external cloud providers.
Trusted infrastructure, including components such as a trusted device, a trusted server, and a trusted network. This pillar allows us to be sure that everything that connects (including Internet things) and everything that connects to it was not compromised by intruders.
, , , . ( ) Amazon AWS , .
, , , , , , .

The first table, trusted identity, is built by us, relying on three key technologies:

Microsoft Active Directory, an enterprise directory that is the entry point for identifying and authenticating users running Windows, macOS, Linux, and even mobile platforms.
802.1x, , , . , , , « » (, ..), .. Cisco ISE, , Cisco, , , Cisco, .

(MFA), , «-» , , , . 81% . , Cisco Duo, , — YubiKey, -, TouchID .. , SAML, , Cisco ( , 700 ). , Duo , , MFA ( , , Facebook, Dropbox, Google ).

Trusted infrastructure means that all its components, workstations, servers, mobile devices and even the network equipment itself comply with the requirements of security policies - they have the latest software installed, the software is patched and configured correctly, authentication is enabled, etc.

If, for obvious reasons, we don’t go into deep details, then we have the so-called trusted user device standard that applies to any laptop, smartphone or tablet that connects to our infrastructure. Regardless of whether this device is corporate or issued. In case of failure or impossibility to comply with this standard, the device simply does not connect to the corporate network, regardless of whether the user connects from the outside or tries to do this in the office, plugging into a free Ethernet socket. Compliance with our requirements can be monitored by Cisco ISE (the main tool), Cisco ASA (with remote access), Cisco Firepower (due to inventory on network traffic) and Cisco Duo (for mobile platforms).

For servers, physical or virtual, containers, in our data centers or in the clouds, its own standard is applied. About 80% of the requirements in it coincide with what is included in the standard for user devices, but there are, of course, differences. For example, for servers, virtual machines and containers that perform very specific tasks, the list of which is limited, we use a closed software environment that prevents the launch of any extraneous applications and services. Another mandatory requirement is the mandatory vulnerability management of application and system software, the order of which differs from what is done on workstations and mobile devices.

It is clear that the requirements for the same Windows or Linux servers are different from each other, as are the requirements for the information security of virtual machines located in Amazon AWS or Microsoft Azure, but the differences are more likely to relate to the configuration features than to the requirements themselves. At the same time, we took as a basis the ready-made Hardeining Guide from CIS and supplemented them with a number of inherent nuances. Therefore, anticipating the question “Where can I get your standards for trusted devices?”, I can simply redirect you to the CIS website , where you will find relevant manuals not only on operating systems, but also on various applications; unless in domestic software there are no such standards.

Finally, we also have our own standard for network equipment - switches, routers (including virtual ones), wireless access points and firewalls. Obviously, the vast majority of this list of our production, but in the case of companies acquired by us, there are some exceptions (how we control the absorbed assets can be read on Habré ). This standard of a trusted network device is based on our own recommendations for protecting equipment based on IOS, NX-OS, IOS XR, etc. They can be found not only on the CIS website, but also on our website (you will find links to them at the end of this material).

The third pillar of a trusted enterprise is trusted access, the implementation of which depends heavily on which access method and where we provide it. A device on the internal network may try to access the device also on the internal network. A user from a device on an external network may try to connect to the cloud without using a VPN. An application may try to access data located in a certain geographical location and which cannot leave it (for example, personal data of Russians). And there can be many such examples.

Therefore, the basis of trusted access is segmentation, which restricts any unauthorized attempts and, even if an attacker or malicious code nevertheless compromises one of the segments, the rest will remain safe. At the same time, speaking of segmentation, I mean not only and not so much network segmentation (by IP or MAC addresses). It can be a segmentation of applications or containers, it can be a segmentation of data, it can be a segmentation of users.

All of these options are implemented in our infrastructure using SD-Access technology., which unifies both wired and wireless access, including from a security point of view. In the case of combining different offices, we use SD-WAN, and in data centers and clouds a hybrid version is used, depending on what access and what we want to control.

An important point that is often forgotten when implementing segmentation and access control. We apply not statistical, but dynamic access rules, which depend not only on who is connecting and where, but also on the context of this access - how the connection is made, how the user, node or application behaves, what they exchange within the framework of the granted access, Are there any vulnerabilities in communicating subjects and objects, etc.? This is what allows us to get away from discrete IS policy rules, because of which many incidents often occur. The protection system simply does not know how to control what happens between checks. In our country, in fact, continuous verification of access is implemented, of every attempt, access, device, user or application.As the main solutions for such continuous verification, the previously mentioned Cisco ISE (for the internal network of the enterprise), Cisco Tetration (for data centers and clouds) and Cisco APIC (for data centers) are used, which are integrated among themselves and can exchange end-to-end security policies.

But it’s not enough to establish access rules, it is necessary to control their observance, for which we apply our own solutions - the Cisco Tetration (for data centers and clouds) mentioned above, as well as Cisco Stealthwatchh Enterprise (for the internal network) and Cisco Stealthwatch Cloud (for clouds). About how we monitor our infrastructure, I already wrote on Habré.

What about the clouds? If Cisco uses the services of 700 cloud providers, then how to ensure safe work with them? Especially in an environment where an employee can connect to the cloud, bypassing the corporate perimeter, and even from his personal device. In fact, there is nothing complicated in realizing this task, if you initially correctly think through the appropriate architecture and requirements for it. For this purpose, quite a long time ago, we developed an appropriate framework called CASPR (Cloud Assessment and Service Provider Remediation). It establishes over 100 different security requirements, divided into blocks that are presented to any cloud provider who wants to work with us. Of course, the CASPR requirements are not the same for all clouds, but depend on what information, what level of privacy,we want to process there. We have requirements of both a legal nature, for example, in terms of GDPR or FZ-152, and technical, for example, the ability to send us security events logs in automatic mode (I already wrote about this on Habré).

Depending on the type of cloud environment (IaaS, PaaS or SaaS), we “attach” our own tools to the protection mechanisms provided by the provider (for example, Cisco Tetration, Cisco ASAv, Cisco ISE, etc.) and monitor its use using the already mentioned Cisco Duo, Cisco Tetration. Cisco Stealthwatch Cloud, as well as with Cisco CloudLock, a CASB (Cloud Access Security Broker) class solution. About the key moments connected with monitoring of safety of clouds, I already wrote (and the second part ) on Habré.

The fourth table of the Cisco “trusted enterprise” concept is “trusted applications”, for which we also have our own standard, or rather a set of standards that differ greatly depending on whether the application is purchased or developed by us, whether it is hosted in the cloud or in our infrastructure, it processes personal data or not, etc. I did not plan to paint this pillar in detail in this note, but the key blocks of requirements are shown in the illustration below.

It is clear that we came to this concept not immediately and not at once. It was an iterative process that reflected the tasks that the IT and IS services set for the business, the incidents that we encountered with the feedback that we received from the employees. I think that I will not be mistaken if I say that, like all of us, we started with security policies based on IP / MAC addresses and user location (remote access was implemented at this stage). Then we expanded them by adding contextual information from Cisco ISE, as well as linking individual departments and projects of the company to the business goals. As the boundaries of our infrastructure opened to guests, contractors, contractors, partners, new tasks and their solutions in terms of access control arose. Active departure to the clouds led tothat we needed to develop and implement a unified concept of threat detection in the internal network, in the clouds and on user devices. Here, by the way, it turned out that we bought Lancope and Umbrella, which allowed us to begin to more effectively monitor the internal infrastructure and external users. Finally, the purchase of Duo allowed us to smoothly begin the transition to the last level of the conditional maturity model, which provides us with continuous verification at different levels.the purchase of Duo allowed us to smoothly begin the transition to the last level of the conditional maturity model, which provides us with continuous verification at different levels.the purchase of Duo allowed us to smoothly begin the transition to the last level of the conditional maturity model, which provides us with continuous verification at different levels.

It is clear that if you want to repeat our path, then the elephant must be eaten in parts. Not all of our customers are alike with us in scale and tasks. But many of our steps and ideas will be applicable to any company. Therefore, we can gradually begin to realize the idea of a “trusted enterprise” described above. The concept of small steps can help you do this. Start by identifying users and devices that connect to you, both internally and externally. Then add access control based on the state of the devices and its context. I didn’t mention at first that Cisco doesn’t have such a perimeter, and protection is built around each device, making it essentially independent of our infrastructure. Providing control of connected devices, including within the framework of remote access,You can smoothly switch to segmentation of the internal network and data center. This is not an easy task, but quite lifting. The key to its implementation is the automation of access policy management. The quarantine has become, and for some it will become, an impetus for returning to the BYOD topic, the possibility of employees using personal devices to access corporate or departmental resources. But having solved the first two tasks, you can easily translate them to personal laptops, smartphones and tablets of your employees. Having solved the problems with network access, you will need to begin to rise higher - to the application level, realizing segmentation, delimitation and access control for them, integrating them with network access policies. The final chord may be a policy of data access control. At this point, you will already know who and where you are connecting from,Which applications and which data need access. You just have to apply this knowledge to your infrastructure and automate the work with data. Here, by the way, you can already think about DLP. Then you can get into those 20% of DLP implementation projects that Gartner considers successful. Everything else is a failure, because companies often do not even know the boundaries of their infrastructure and the entry points to it, so that you can talk about their control, not to mention data control.so that you can talk about their control, not to mention data control.so that you can talk about their control, not to mention data control.

And having realized all this, you will realize that the beautiful concept of Zero Trust (zero trust), which many manufacturers and analysts talk about today, in your case has turned into a really working system. At least for us it was just that. As I wrote at the very beginning, we began to implement the concept of a trusted enterprise in Cisco in the early 2000s, when no one had heard such a term as “Zero Trust” (it was proposed by Forrester only in 2010). But now, relying on our own experience, we were able to implement this idea in our portfolio (we use it for our own security), calling it all a beautiful marketing phrase “Cisco Trusted Access”.

In conclusion, I would like to note that the implementation of remote access makes us look differently at how the security system should be built. Someone says that remote access leads to loss of perimeter. No, it is not. It’s just that the perimeter is blurring and its borders pass through each device, from which you access your data and applications located inside the infrastructure and outside it. And this, in turn, allows you to implement an architecture that responds very flexibly and efficiently to all the changes that business requires from IT and information security. Cisco faced this a long time ago when there was no problem with coronavirus yet and we had the opportunity to gradually, without hurry, implement the concept of a trusted enterprise. But this does not mean that our experience is not applicable in the current realities. On the contrary. You can rely on him,Fill fewer cones and make fewer mistakes.

Paraphrasing the famous Soviet film “17 Moments of Spring”: “Nobody, sometimes even oneself, can be trusted in our time. Cisco - you can! " Our approach, and the absence of major and serious incidents in our infrastructure (and we have several tens of thousands of employees and as many external partners and counterparties users have remote access inside), proved that it not only has the right to life, but also allows us to solve his business tasks in the most convenient way for him, the business, as well as reliable for IT and safe for information security.

Additional Information:

How does Cisco monitor the information security of absorbed companies and provide their access to their resources?
Cloud Security Monitoring (Part 1 and 2 )
How does Cisco monitor security on its internal network?
Cisco?
Cisco Security Ninja 20 ?
Cisco Cisco IOS, NX OS, IOS XR, Cisco UCS, Cisco TelePresence

PS. If you are interested in how remote access is technically arranged in Cisco itself, then on April 23 we will conduct a webinar on this topic. More precisely, we are already completing a series of remote access webinars that take place every Thursday. On the 2nd of the day the webinar was dedicated to the remote access threat model ( video recording and presentation ). On the 9th, we will talk about how to protect the workplace of a remote worker , and on the 16th, how to build a perimeter with remote access .

How has Cisco been operating in remote access mode and an absent perimeter for 20 years?

Additional Information:

More articles: