Speaker
Description
Abstract
Long term CESNET NREN evolution that split overall network management into rather separate activities distributed among highly specialized teams (e.g. network administrators, service desk operators, CSIRT team) led us to an idea to develop a tool that would represent single source of knowledge and single unified interface (understandable to all involved teams) to apply directives for traffic regulations in dynamic manner. That tool - we call it ExaFS - represents abstract layer above network with appropriate traffic regulation services configured behind (RTBH based, BGP FlowSpec based, external traffic cleaning redirection, internal cleaning devices redirection and control, etc..). Configured IP address space is internally structured, so it can be used in AS wide scope as well as for single end user network and serve its administrators. System also started to offer API (in early development steps) to be potentially controlled by other systems.
Hand in hand with ExaFS development we started to extend our large scale flow-based monitoring system FTAS with functionality that enables to configure various technologically based detectors. Then we incorporated this new functionality into incident handling process where detectors sent notifications and security handlers and system administrators did verification (traffic analysis) and applied traffic regulations by hand when needed. Further detection optimization led to such number of notified traffic anomalies that could not be processed by hand in any case. That situation accelerated development of FTAS system to be able to cooperate with ExaFS API directly. Putting this into practice allowed us to react on many times higher number of detected traffic anomalies automatically and without delay. Dedicated FTAS detectors and large variety of ExaFS rule sets allows us (within major NREN installation) to serve and protect NREN itself as well as individual clients. Cloning this solution into dedicated networks within NREN (e.g. dedicated VRF) or into end user networks supports specific communities or end user networks independently. It can be also set up from end user perspective (in any architecture) as a service that helps to dynamically lower load of specific resources in their networks (firewalls, virtualization platforms, standalone servers).
Operational transport level security is not an isolated standalone process. It's a natural part of NREN fundamental service - reliable data transport. And it has to be kept in mind when thinking about network architecture aspects, incorporating services components (e.g. computing facilities, storage infrastructures), connecting end user networks or serving specific communities. We did it evolutionary in many steps over several network generations. It's not a "do-it-all" solution it's just another piece of chain on the way to stable data delivery service. We are convinced that systematic evolutionary development of suitable tools, their harmonization and detailed optimizations of the whole organism may bring at least the same value as a single "big-bang" bought tool. And brings beside others another positive aspect - motivates involved people to learn and increase their knowledge and expertise in a complex way.
