The right choice of SRI: from flyers to use case

    The bell rings recently:
    - Good afternoon! I would like to receive the specification for the Cisco ASA firewall. I already have specifications from the company <namerek> and I want to compare them and choose the right one. Can you help me with this?
    - Yes of course. Why do you need a Cisco ASA?
    - I need to block Tor.
    - Do you need the Cisco ASA for this?
    - Well, how? Here the company <namerek> says that its firewall blocks Tor. Therefore, I want to compare the cost of their screen with yours.
    - So you need to block Tor and you are looking for the solution you need for this?
    - Yes, yes (annoyed). So can you make me a specification? What source data do you need?
    - To solve this particular problem of yours, if others are not facing you, it is not necessary to use the Cisco ASA. You can block work with Tor using our various solutions - Cisco Web Security Applaince, Cisco Umbrella Security Internet Gateway, Cisco Cloud Web Security, Cisco Meraki MX, Cisco Firepower, Cisco AMP for Endpoints ... In the end, you can load addresses with a script Tor hosts on the Cisco ISR and block them using the ACL. In the latter case, you do not have to spend anything.
    - Yes? Darn. I need to think then ...
    - Let us together we will compile a list of tasks that you need to solve, and threats that need to be addressed, and then we will choose the best product in the best way?
    - Okay, let's do it. Will you be able to come to us tomorrow at 10 in the morning?
    - Of course.

    We receive quite similar calls in essence quite often and they reflect the established practice of not solving our problems, but of closing current problems with the help of the best-known products. It’s like building roads. You can initially build them correctly (even if the initial costs will be more expensive), or you can shift the damaged asphalt every year or put patches on the formed pits (which is more expensive in the end). At some point, there are too many such “pits” and a collapse ensues - everything has to be redone, and the person who started this “patchwork” story loses its place (or maybe he himself left his post long ago, anticipating possible problems). So with the construction of an information security system at the enterprise. We are too used to thinking in product categories. Here we will buy Cisco ASA (probably because we don’t know of other firewalls at Cisco), we’ll install the Cisco Web Security Appliance here (although Cisco Umbrella could be avoided), we need an antivirus <namerek> (although the customer has encountered file-free attacks), we’ll install a certified crypto-gateway (although you can get by the VPN functionality built into the router or the operating system) ... It all started a long time ago when there were players on the market with one product that solved a specific problem. So there was a substitution of concepts - “problem solving” was replaced by “product”. But time passed, the portfolio of manufacturers expanded, the functionality of the products, too, but the “I want a product” approach remained. name>> (although the customer was faced with file-free attacks), we’ll install a certified crypto gateway (although you can get by the VPN functionality built into the router or the operating system) ... It all started a long time ago when there were players on the market with one product that solved a specific problem . So there was a substitution of concepts - “problem solving” was replaced by “product”. But time passed, the portfolio of manufacturers expanded, the functionality of the products, too, but the “I want a product” approach remained. name>> (although the customer was faced with file-free attacks), we’ll install a certified crypto gateway (although you can get by the VPN functionality built into the router or the operating system) ... It all started a long time ago when there were players on the market with one product that solved a specific problem . So there was a substitution of concepts - “problem solving” was replaced by “product”. But time passed, the portfolio of manufacturers expanded, the functionality of the products, too, but the “I want a product” approach remained. So there was a substitution of concepts - “problem solving” was replaced by “product”. But time passed, the portfolio of manufacturers expanded, the functionality of the products, too, but the “I want a product” approach remained. So there was a substitution of concepts - “problem solving” was replaced by “product”. But time passed, the portfolio of manufacturers expanded, the functionality of the products, too, but the “I want a product” approach remained.

    I sometimes envy niche cybersecurity vendors. What is a good job with them? A small set of products that solve very specific problems. For example, a firewall is needed for a customer - here is a firewall. No discrepancies and disagreements - everything is extremely clear. The maximum why the dispute can come out is what model is needed - at 250 or 600 megabits per second? For example, the customer needs to block Skype on his network - again, here's a firewall with the corresponding function (if it exists in ITU, of course). Everyone is happy. A vendor who stamps commercial offers in batches (there’s only one product - you won’t get away with it). The customer, who at his request receives a ready-made offer with a specific price. A partner who does not need competence in various decisions.

    At Cisco, the situation is a little different. To begin with, we have the same seven firewalls:


    And this is if you do not consider discontinued 10 years ago, but still used by some customers, Cisco Pix, as well as various “applied” ITUs, for example, the Cisco Umbrella DNS filter , the Cisco Web Security Appliance HTTP filter , etc. ., which with some stretch, but also can carry the proud title of firewalls for certain tasks.

    And therefore, even for the usual request “let us have a normal firewall”, we simply cannot answer. And it’s not right. It is very important to choose the means of protection not from its name or type (for example, many manufacturers have NGFW, but here’s an understanding of what NGFW is, everyone has different ideas) or their idea of ​​the product, but from the problem being solved and a detailed study of the characteristics and functions of the available at the manufacturer of the portfolio. In the case of Cisco, our products use many cross-cutting or essentially similar technologies and it is better to discuss their correct choice with representatives of the manufacturer or a qualified partner. Moreover, we are always open for consultations and are ready to help our customers and partners.

    Therefore, when making calls similar to the one above, we begin to “get bored” and specify what task the customer needs a firewall to solve. Does he need a firewall to differentiate access at the network level? To protect virtualized environments? To control applications? With binding rules to user accounts or not? For installation on trunk channels or on a remote site? And all because our portfolio on cybersecurity is wide enough and we cannot give a banal answer “buy our firewall and you will be happy”. We are guided by the principle that the task to be solved determines the product used, and not vice versa. If other manufacturers have only one firewall or one attack detection system and therefore they convince customers that “drive all traffic, even internal traffic, through the perimeter ITU - this is normal ”or that“ put a perimeter IDS on each trunk or SPAN port and you will solve your problem ”, then we don’t work like that. First, the problem to be solved and (or) the threat model is determined, and then the appropriate solution is selected for them, which may differ from the originally intended by the customer.

    But let's try to go beyond just the firewall? After all, we have a wider range of cybersecurity solutions and far from everything can and should be solved only with the help of a firewall. Take, for example, the task of controlling access to Web resources. In the case of Cisco, it can be solved in different ways. At least 4 products allow us to control access to Internet resources:

    • hardware or virtual Cisco Web Security Appliance (WSA)
    • cloudy Cisco Cloud Web Security (CWS)
    • cloud-based Cisco Umbrella (formerly OpenDNS Umbrella) or Secure Internet Gateway (SIG)
    • Cisco Firepower hardware or virtual firewall (or Cisco ASA and Cisco Meraki MX) with URL Filtering.

    Each of these solutions allows us to record attempts to access certain sites and block them if necessary. But they do it differently. For example, Cisco Umbrella monitors all DNS queries from the corporate network or from a mobile device. And CWS (or its new reincarnation of Cisco Securu Internet Gateway) passes all HTTP / HTTPS requests through the nearest cloud, which is especially useful for mobile employees. WSA and Firepower operate on a technology similar to CWS (the base of categorized URLs), but must be installed on the perimeter of the protected network. However, the differences of the four named products are not limited to this. The same Firepower, in addition to URL filtering, can detect malicious files downloaded from the visited pages, and the WSA adds to this the functions of analyzing and parsing Web pages on the fly (if they are not in the URL database), as well as the ability to scan the page before giving the user access to it and cutting out malicious content or advertising. And if the task of controlling access to Web resources is transformed into the task of controlling access to cloud services (Amazon, Google.Doc, Azure, etc.) from personal devices of employees located outside the corporate network, then another solution comes into play Cisco -CloudLock Cloud Access Security Broker (CASB). In other words, Cisco Web access control solutions, in addition to their main function, also have advanced functionality that distinguishes them from each other. And it is precisely the whole range of solution functions and the task facing the customers that will influence its choice.

    Let's take another example - the fight against ransomware programs that try to connect to C2 command servers to load new functionality, receive commands, or organize a data leak. At Cisco, various solutions have such protective functionality:

    • The Cisco Stealthwatch network anomaly monitoring system , which analyzes NetFlow telemetry and can detect attempts to communicate with command servers that even go around the perimeter (via insecure Wi-Fi or 3G / 4G modems).
    • The already mentioned Cisco WSA solution, which monitors outgoing from the network and passing through the WSA communications on all 65,000-plus TCP ports in order to identify attempts to connect to well-known C2-servers.
    • Also, the already mentioned Firepower (or ASA, or Meraki MX) controls all network connections and, thanks to the built-in NGIPS intrusion prevention technology, as well as regularly updated lists of C2 servers, allows you to block connections to them.
    • The Cisco Umbrella cloud service, passing all the DNS traffic through itself, identifies connections with malicious nodes inside and outside the corporate network — from mobile devices or remote sites that are not equipped with any security features.
    • The Cisco Advanced Malware Protection (AMP) for Networks and for Endpoints anti-malware system monitors the abnormal behavior of files and their attempts to connect to strangers, including and malicious nodes.
    • The Cisco Cognitive Threat Analytics solution allows malware to be tracked by Web logs from proxies or firewalls.
    • Finally, the Cisco Email Security Appliance does not allow the ransomware to enter the user's computer through the mailbox (and this is still one of the main channels of infection for users, even despite the history of WannaCry ).

    Which of the seven solutions mentioned above should be chosen to block infection by ransomware and interact with malware management servers? Again, it all depends on what other tasks from the point of view of information security we want to solve. Do we only need a struggle with ransomware or do we need a solution to protect the perimeter “all in one” (Firepower is better here)? Or maybe we need mobile device protection? Then Cisco Umbrella will be the best choice. Finally, if we are not sure that all traffic goes only through the perimeter, then we can not do without Cisco Stealthwatch. And most likely one solution here is not enough and you will need a complex of several technologies.

    Let's take one more example, which we had to deal with some time ago. The customer purchased the Cisco Web Security Appliance to control access to the Internet, and then made a number of comments that very well demonstrated the above. The customer chose the product, not the solution to their problem. In the process of “debriefing,” it turned out that the customer needed the Skype blocking feature and Cisco WSA did not do very well with it. Let's try to figure out why the customer was unsatisfied?

    To begin with, at the time of the analysis of the situation Skype was built on the Peer-to-peer principle and did not use any central servers for its work (although Microsoft is moving in this direction). Therefore, blocking Skype as it is done when accessing regular Web sites (which WSA does perfectly) is necessary skillfully and with an understanding of the various communication methods in Skype:

    • using UDP connection with other subscribers on randomly selected port numbers
    • use of TCP connection with other subscribers on randomly selected port numbers
    • use of TCP connection with other subscribers on ports 80/443
    • tunneling packets through a Web proxy using the HTTP CONNECT method on port 443.

    So in 1-3 cases, the traffic usually does not go through the Cisco WSA and, as a result, cannot be blocked by it. And this is not a WSA flaw, but the particularities of its installation location on the corporate network. In the 4th scenario, there are also difficulties associated with the fact that Skype does not transmit any details about the client within the HTTP CONNECT (there is no HTTP User-Agent line). Therefore, it is difficult to distinguish Skype from another protocol using the HTTP CONNECT method. We can try to block such connections, but then all Skype users, as well as, possibly, other protocols that use similar communication methods, will fall under the distribution.

    What then to do? How do we solve the problem facing the customer? As I wrote above, it is necessary to build on the task, not the product, which “seems to be in the description” solves it. Based on the above communication methods used by Skype, we have three candidates for solving the task:

    • Cisco stealthwatch
    • Cisco firepower
    • Cisco ISR with NBAR2 Feature.

    NBAR2 (Network-based Application Recognition) is a feature of Cisco routers with the IOS operating system that allows you to recognize applications that pass through the router. With its help, you can easily identify various types of traffic, including those using peer-to-peer technologies with dynamic ports for connections (Skype also applies to them). In order to block Skype on a regular router, it is enough to enter the following commands (specifying the correct interface for traffic control instead of “GigabitEthernet 0/2”): You can verify the correct operation of the policy you enabled by using the show policy-map (or show class-map) command:

    (config)#class-map match-any blockskype
    (config-cmap)#match protocol skype
    (config)#policy-map blockskype
    (config-pmap)#class blockskype
    (config-pmap-c)#drop
    (config)#interface GigabitEthernet 0/2
    (config-if)#service-policy input blockskype
    (config-if)#service-policy output blockskype




    1#show policy-map interface g0/2 input
    GigabitEthernet0/2

    Service-policy input: blockskype

    Class-map: blockskype (match-any)
    994 packets, 327502 bytes
    30 second offered rate 43000 bps, drop rate 43000 bps
    Match: protocol skype
    994 packets, 327502 bytes
    30 second rate 43000 bps
    drop

    Class-map: class-default (match-any)
    195253 packets, 51828774 bytes
    30 second offered rate 7282000 bps, drop rate 0 bps
    Match: any


    This method, however, has only one, but a significant drawback - it blocks all Skype traffic indiscriminately. In practice, you may need to be more flexible. For example, you want to allow only certain users on your network to use Skype, and to ban all others. Or it is necessary to prohibit certain functions within Skype itself (chats, voice, video, file transfer) and also link these policies to specific user accounts. Neither Cisco WSA nor Cisco NBAR2 will be able to solve the problem in this formulation - only Cisco Firepower technologies (as an add-on on the Cisco ASA ITU, as a standalone hardware or virtual device, or as an add-on on the Cisco ISR router). It is this solution that allows the most flexible solution to the task of filtering Skype by various attributes - time, user, operation in Skype, direction, etc. But if you go even further, you can prevent the Skype application from starting on the user's computer, and you can try to do this with both group policies and independent information protection tools, for example, Cisco AMP for Endpoints.

    Take the last example, which often pops up in a conversation with customers and from which this note begins. Customers say, “We want to block Tor. Does your ITU know how to do this? ”Yes, it does. Only here Tor can be blocked not only with the help of ITU, although this is the most obvious option. Give the ITU a regularly updated list of output nodes of the Tor network or the addresses of directory servers, and that’s all, we can assume that the problem is solved. But ... Is this the only option? Of course not. You can block Tor using the Cisco ISR, giving it a list of matching addresses, which are then translated into the ACL. You can automate this task using a regular script - https://github.com/RealEnder/cisco-tor-block. And, for example, Cisco Stealthwatch can monitor the interaction not only with the output, but also with the input nodes of the Tor network. And on the Cisco AMP for Endpoints you can hang this task. There are a lot of options - you need to understand which of them will be better to satisfy the initial conditions.

    That is why we always urge both our partners and customers to clearly formulate their task and not talk about which Cisco product they need (although it also happens that the customer is well versed in our portfolio and knows perfectly well what he needs), but about what problem they want to fight. Otherwise, the customer / partner may experience dissatisfaction with Cisco solutions, which supposedly inefficiently solve the task. But no one set the task :-( It often happens that a company, based on its vision, acquires a solution, and then it turns out that it cannot cope with the task. Who is to blame in this case?

    In other words, one must build on what foreigners call the fashionable term “use case” (use case). I would single out four types of such scenarios that occur in cybersecurity:

    • neutralization of a specific threat (information leak, ransomware, DDoS attacks, phishing, etc.)
    • protection / blocking of a specific technology (for example, a virtualized data center or Skype or a cloud or perimeter)
    • implementation of the requirements of any normative act or standard, including requirements for cybersecurity (for example, the 31st order of the FSTEC or the new GOST of the Bank of Russia)
    • implementation of any process in information security (for example, incident response or security awareness or information security monitoring).

    In each of these four categories, there are many scenarios whose universal list does not exist (although there are the most popular scenarios).

    Approaching the end of the article, I would again like to return to where I started. In order to properly build an information security system at an enterprise, you don’t have to run to look for product A, B or C, but first make a list of the initial data - tasks to be solved (including protected processes, supported protocols and systems, performance, etc.), threats reflected, regulatory requirements, that is, build on usage scenarios. And only after understanding this, you can proceed to the process of choosing the appropriate solution (and again - not a product, but a solution). Good luck with your choice! And to expand the topic of use case a little wider, in the following articles we will consider several typical scenarios.

    Also popular now: