Do you know what a Cisco network is? Here are some numbers showing the scale of the challenges facing our IT and IB services:
- 3 million IP addresses
- 40 thousand routers
- 215 thousand infrastructure devices
- 120 thousand users
- 275 thousand nodes, of which 135 thousand are laptops and desktops and 68 thousand are mobile devices on iOS, Android, BlackBerry, Windows and other platforms
- Offices in 170 countries
- 26 thousand home offices
- 1350 laboratories
- 300 business partners with access to our infrastructure (logistics, manufacturing, development, testing, etc.)
- Over 700 cloud service providers that we use in our daily activities.
Obviously, such a large-scale and distributed network, and even with a fuzzy perimeter, needs adequate protection and access control. If we had one point of access to the Internet, the lack of external connections, the prohibition of corporate and own mobile devices (BYOD), as well as the guarantee of the absence of accidental or intentional connections to extraneous Wi-Fi points or the use of 3G / 4G modems, we could concentrate on perimeter defense and live happily ever after. But alas ... Cisco has long gone from the perimeter approach and not only blurred its borders, giving employees mobile devices, transferring them to work with laptops and providing “home offices”, but also providing access to its infrastructure to its business partners who fill our warehouses , pick up finished products, develop individual components of our solutions, provide production, etc. But that's not all. In order to optimize the company's resources and IT services, we went to the clouds, signing contracts with more than 700 different cloud providers that provide us with a wide range of services - newsgroups, CRM, file storage, corporate social networks, personnel and accounting, BI, and so on. P. Finally, you shouldn’t forget about peripheral equipment such as printers, IP phones and personal TelePresence systems, as well as various Internet “things” - thermostats, lighting, fire alarms, physical access control systems, etc. All of this is Cisco’s
NETWORK , access to which needs to be controlled.
Trying to solve the problem of controlling such a diverse infrastructure in the forehead, prescribing rules on each infrastructure device (access point, switch or router) on the principle “node A to allow access to node B”, we can, but already on the 10th device we will realize that with the number of devices on the Cisco network described above). This will not only take time to write and check access control lists, but also reduce the performance of network devices, which will have to check every incoming frame or packet for ACL compliance. And if we recall the mobility of our employees, who may be located in different places of the corporate network or outside its borders (and all this in one day), then the task of static rules is not only ineffective, but also impossible. In the end, all the rules will turn into the classic “everyone is allowed everything and everywhere,” which is clearly not an example of what it is worth striving for.
')
Therefore, we began to solve the problem in parts and from top to bottom. First, the policy was determined “on a large scale”, using only two attributes, the
level of trust and
accessibility . The result was a high-level matrix, which made it possible to group all the above-mentioned types of devices and users in just 4 large blocks. This matrix allowed us to determine the answer to the question “
who / what to let into our network ”.

However, we did not restrict ourselves to the banal authentication of users or devices (although this is already quite a lot). Still, given the level of mobility of Cisco employees, a situation is possible when being a week or two (and there are monthly business trips) away from the corporate network, an employee can catch any infection on his laptop or tablet. Therefore, in addition to authentication, it was also necessary to check the status of the device - the presence of the necessary means of protection, antivirus, up-to-date anti-virus databases, patches, and for smartphones or tablets also the presence of jailbreak, enabled encryption, set PIN-code of a certain length, etc.

Choosing at the first stage as an attribute of the policy of trust, we decided for ourselves that, for example:
- the connection from the internal network is more trusted than from the external one,
- VPN connection is more secure than from the Internet
- Wi-Fi access should not be verified in the same way as a wired connection,
- guest mobile device is less trusted by employee’s mobile device,
- etc.
In other words, by answering the question “who connects and what”, we also included in our policy of network access the answer to the question “
how do you connect to the Cisco network? ".

Are the answers to these three questions enough to protect network access? For protection, it is possible and yes, but not to address all the issues facing various divisions of Cisco. Indeed, besides the IS service, other structures of our company are also interested in monitoring network access. For example, IT, which would like to know about what types of devices employees use most often? This would allow to optimize internal applications for working with the most actively used software. The security service would like to know by whom and at what time an access attempt was made and, if necessary, restrict it. For example, guests can not be in our offices outside working hours (that is, from 9.30 to 18.30 in Moscow or from 8.00 to 17.00 in the United States). This means that they do not need access to our guest wireless network at night (unlike employees who can work at night).

The development department has set requirements for using geographic attributes as an element of an access policy. It's not a secret that Cisco does not develop software at every office, but is concentrated in just a few points of the globe. Therefore, office workers in Brisbane, Australia, hardly need access to servers located in Indian Bangalore and storing the source codes of our software. Compliance-service, monitoring compliance with various regulatory requirements, has its own requirements for network access. For example, in order to fulfill certain contracts, it is necessary to attract a limited number of employees and only those who have a certain nationality (yes, this also happens). Or, for example, to fulfill the requirements of the domestic 242nd law on the localization of databases of personal data of Russian citizens.
Finally, each division has its own set of data used in the work, to which only employees of this division should have access and no one else. For example, the personnel department works with personal data of employees, accounting - with payroll records, IT - with Active Directory, security - with video surveillance, developers - with source version control systems and with dynamic or static analysis systems. That is, the policy should take into account the role of the subject of access in the organizational structure of the company.
In other words, Cisco's network access policy does not rely on one attribute (who / what), but takes into account many factors that answer the following questions:
- Who is connecting?
- WHAT is connected?
- How to connect?
- WHERE is the connected device or user?
- WHERE IS ACCESS ?
- WHEN carried access?
- WHAT CONDITIONS should be met to provide access?

I must say that we did not immediately implement such a policy. It would be slyness to say that. We went to her for a long time. The key success factor was not so much an understanding of the need to implement flexible access scenarios, depending on a combination of different attributes (and not just WHO + WHERE + WHEN), but the opportunity to answer each of the above questions. Without this, Cisco’s network access policy would have been impossible to implement. It was necessary to build to create lists of roles and available resources, compare them with specific employees, link IT services with HR services, and perform a number of other, so unloved and often called “paper security” actions. And, of course, a good help was the release of the Cisco ISE (Identity Service Engine) system, which helped automate the process of creating, implementing and monitoring network access policies in the Cisco network infrastructure. Without him (we already
wrote about him on Habré a couple of years ago), all our good intentions regarding the dynamic and flexible access of people and devices to our resources would have remained a beautiful idea that did not go beyond the board on which it was all drawn. ISE has helped us bring this all to life.

Now it has become fashionable to use the term “agile”. So I can say that we managed to implement network access in the style of agile. A dynamic environment with constantly changing access conditions - this is the Cisco network, in which access should be provided promptly (and without a lot of paperwork and applications) and automatically, without the constant involvement of employees of various services that give “good” access. This works on a network of one switch, one administrator and ten employees. When the number of controlled subjects and objects of access is measured in hundreds of thousands, then only agile or in other words dynamic control of network access can help solve the set task. And at Cisco we managed to do it.
Shl. Yes, anticipating the possible question of what equipment the Cisco network is built on, I answer - on Cisco equipment (oddly enough :-) However, the principles described do not depend on what lies at the heart of the network - they are universal. But a solution that implements policies based on these principles is already vendor-dependent. In the case of the Cisco ISE, it works with the network equipment of Cisco, HP, Ruckus, Aruba, Motorola, Brocade. Not sure, but the scheme should work on other vendors, for example, Chinese, if they support the same 802.1x and standard management mechanisms (SSH, Telnet, SNMP).