The right choice of SrZI: from flyers to use case
The bell rings recently:
- Good day! I would like to get a specification on the Cisco ASA firewall. I already have the specifications from the company <name> and I want to compare them and choose the appropriate one. Can you help me with this?
- Yes of course. What do you need Cisco ASA for?
- I need to block Tor.
- Do you need exactly Cisco ASA for this?
- Well, how? Here the company <imenyrek> 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, if others are not in front of 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 using a script Tor network nodes to the Cisco ISR router and block them using ACLs. In the latter case, you do not have to spend anything.
- Yes? Darn. I need to think then ...
- Let us together draw up a list of tasks that you need to solve, and threats that must be dealt with, and then we will choose the best product in the best way possible?
- Ok, come on. Will you be able to drive up to us tomorrow at 10 am?
- Of course.
We receive similar in essence calls quite often and they reflect the current practice of not solving their problems, but 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), and you can shift the damaged asphalt every year or put patches on the holes that have been formed (which ultimately costs more). At some point, such “holes” become too much and collapse occurs - everything has to be redone, and the person who started this “patchwork” story loses its place (or maybe he himself left office long ago, anticipating possible problems). So with the construction of information security systems in the enterprise. We are too used to thinking in grocery categories. Here we will buy Cisco ASA (probably because we don’t know other firewalls from Cisco), then we will install the Cisco Web Security Appliance (although Cisco Umbrella could have been dispensed with), then I need an anti-virus <iRomer> (although the customer has encountered file-free attacks ), then we put certified crypto gateway (although you can do with the VPN functionality built into the router or the operating system) ... It all started a long time ago when there were players with a single product on the market that solved a specific task. So there was a substitution of concepts - “problem solving” was replaced by “product”. But as time went on, the portfolio of manufacturers expanded, the functionality of the products, too, but the “I want the product” approach remained.
I sometimes envy niche vendors for cybersecurity. What is good work for them? A small set of products that solve very specific problems. For example, a customer needs a firewall - here’s your firewall. No discrepancies and disagreements - everything is extremely clear. The maximum that a dispute can get out of is which model is needed - at 250 or 600 megabits per second? It is necessary for the customer, for example, to block Skype in his network - again, here's a firewall with the corresponding function (if it is in the ITU, of course). Everyone is happy. A vendor who stamps commercial offers in batches (there is only one product - you won’t clear up). A customer who, at his request, receives a finished offer with a specific price. A partner who does not need to be competent in various solutions.
In Cisco, the situation is slightly different. Let's start with the fact that we have seven of the same firewalls:
')
And this is if not considered discontinued 10 years ago, but still used by some customers, Cisco Pix, as well as various ITU “application”, for example, Cisco Umbrella DNS filter, Cisco Web Security Appliance HTTP filter, etc. ., which, with some stretch, but can also carry the proud title of firewalls for certain tasks.
And so even the usual request “yes, we would have a normal firewall”, we can’t just answer. Yes, and it is not correct. It is very important to choose the means of protection not from its name or type (for example, many manufacturers have NGFW, but understanding of what NGFW is, everyone has different) or their idea of ​​the product, but from the problem being solved and detailed study of the characteristics and functions of the existing from the manufacturer's portfolio. In the case of Cisco, our products use a lot of cross or similar technologies and it is better to discuss their right choice with representatives of the manufacturer or a qualified partner. Moreover, we are always open for consultations and ready to help our customers and partners.
Therefore, when making calls similar to the one above, we begin to “get bored” and clarify which customer needs a firewall to solve. Does he need a firewall to limit access at the network level? To protect virtualized environments? To control applications? With the binding of rules to user accounts or not? For installation on trunk lines or on a remote site? And all because our cybersecurity portfolio is quite broad and banal answer “buy our firewall and you will be happy” we cannot therefore give. We are guided by the principle that the problem being 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 “to drive all traffic, even internal, through the perimeter ITU is normal” or that “put a perimeter IDS on each trunk or SPAN port and you solve your problem ”, we do not work like that. First, the problem to be solved and (or) the threat model is determined, and then an appropriate solution is selected for them, which may differ from the originally intended one by the customer.
But let's try to go beyond the firewall only? After all, the range of cybersecurity solutions is much wider and not 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:
Each of these solutions allows us to record attempts to access certain sites, and block them as needed. But they do it in different ways. For example, Cisco Umbrella monitors all DNS requests from the corporate network or from a mobile device. And CWS (or its new reincarnation of Cisco Securu Internet Gateway) sends all HTTP / HTTPS requests through the nearest cloud, which is especially useful for mobile workers. WSA and Firepower operate along the same lines as CWS technology (categorized URL base), but must be installed on the perimeter of the protected network. However, the differences between these four products are not limited to this. The same Firepower, in addition to URL filtering, can detect malicious files downloaded from the visited pages, and WSA adds to this the analysis and analysis of Web pages on the fly (if they are not in the URL database), and the ability to scan the page before submitting to it user access 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, another solution comes into play Cisco - CloudLock , belonging to the class Cloud Access Security Broker (CASB). In other words, Cisco solutions for controlling Web-access, in addition to their main function, also have enhanced functionality, which distinguishes them from each other. And the whole range of solution functions and the challenge facing customers will influence its choice.
Let us take another example - the fight against extortionists who try to connect with command C2 servers in order to load new functionality, receive commands or organize data leakage. At Cisco, different solutions have this kind of security functionality:
Which of the following seven solutions should be chosen to block infection by cryptographers and interact with the management servers of malware? Again, it all depends on what other tasks from the point of view of information security we want to solve. Do we need only a fight against extortionists, or do we need a solution for protecting the “all in one” perimeter (Firepower is better suited here)? Or maybe we need the protection of mobile devices? Then the Cisco Umbrella will be the best choice. Finally, if we are not sure that all traffic goes only through the perimeter, then we cannot do without the Cisco Stealthwatch. But most likely one solution here and not at all to do and need a complex of several technologies.
Let's take another example that 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 course of the “debriefing”, it turned out that the customer needed the function of blocking Skype and Cisco WSA to cope with it not very well. Let's try to figure out why the customer was unsatisfied?
To begin with, at the time of the situation analysis, 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 well) should be done skillfully and with an understanding of the various methods of communication in Skype:
So in 1-3 cases, traffic usually does not go through the Cisco WSA and, as a result, cannot be blocked by it. And this is not a disadvantage of WSA, but especially the place of its installation in 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 HTTP CONNECT (there is no HTTP User-Agent string). Therefore, it is difficult to distinguish Skype from another protocol using the HTTP CONNECT method. We can try to block such connections, but then “under distribution” will get all Skype users, as well as, possibly, other protocols that use similar methods of communication.
What then to do? How do we solve the problem facing the customer? As I wrote above, it is necessary to make a start from the task, and not the product that “sort of as described” solves it. Based on the above-described communication methods used by Skype, we have three candidates for solving the task:
NBAR2 (Network-based Application Recognition) is a feature of Cisco routers with an IOS operating system that allows you to recognize applications running through a router. With it, you can easily identify various types of traffic, including those using peer-to-peer technologies with dynamic ports for connections (this includes Skype). In order to block Skype on a regular router, enter the following commands (specifying the correct interface for controlling traffic instead of “GigabitEthernet 0/2”):
To make sure that the policy you have enabled is working correctly, use the show policy-map (or show class-map) command:
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 forbid everything else. Or it is necessary to prohibit certain functions within Skype itself (chat, 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 over ITU Cisco ASA, as an independent hardware or virtual device, or as an add-on above Cisco ISR router). It is this solution that makes it possible to most flexibly solve the Skype filtering task by various attributes - time, user, operation in Skype, direction, etc. But if you go further, you can prevent the Skype application from running on the user's computer, and you can try to do this with both group policies and independent means of information protection, for example, Cisco AMP for Endpoints.
Take the last example, which often emerges in a conversation with customers and with which this note begins. Customers say, “We want to block Tor. Does your ITU do this? ”Yes, it does. Only here you can block Tor not only with the help of ITU, although this is the most obvious option. Writing to the ITU a regularly updated list of output nodes of the Tor network or addresses of directory servers and everything, we can assume that the problem has been solved. But ... Is this the only option? Of course not. You can block Tor using a Cisco ISR router by submitting to the input a list of matching addresses, which are then translated into a set of ACLs. 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 Cisco AMP for Endpoints, you can hang this task. There are plenty of options - you need to understand that of them it will be better to satisfy the initial conditions.
That is why we always call on 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 ineffectively solve the problem. But no one set the task :-( It often happens that a company, on the basis of its vision, acquires a solution, and then it turns out that it does not cope with the task. Who is to blame in this case?
In other words, it is necessary to build on what foreigners call the fashionable term “use case”. I would single out four types of such scenarios that take place in cybersecurity:
In each of these four categories there are many scenarios, a universal list of which does not exist (although there are the most popular scenarios).
Coming to the end of the note, I would like to go back to where I started. In order to properly build an information security system in an enterprise, it is necessary not to run to look for product A, B or C, but first to make a list of source data - tasks to be solved (including protected processes, supported protocols and systems, performance, etc.), threats reflected, requirements of regulations, that is, to build on usage scenarios. And only by understanding this, you can proceed to the process of choosing the appropriate solution (and again - not the product, but the decision). Good luck with your choice! And in order to cover the topic of use case a little wider, in the following articles we consider several typical scenarios.
- Good day! I would like to get a specification on the Cisco ASA firewall. I already have the specifications from the company <name> and I want to compare them and choose the appropriate one. Can you help me with this?
- Yes of course. What do you need Cisco ASA for?
- I need to block Tor.
- Do you need exactly Cisco ASA for this?
- Well, how? Here the company <imenyrek> 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, if others are not in front of 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 using a script Tor network nodes to the Cisco ISR router and block them using ACLs. In the latter case, you do not have to spend anything.
- Yes? Darn. I need to think then ...
- Let us together draw up a list of tasks that you need to solve, and threats that must be dealt with, and then we will choose the best product in the best way possible?
- Ok, come on. Will you be able to drive up to us tomorrow at 10 am?
- Of course.
We receive similar in essence calls quite often and they reflect the current practice of not solving their problems, but 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), and you can shift the damaged asphalt every year or put patches on the holes that have been formed (which ultimately costs more). At some point, such “holes” become too much and collapse occurs - everything has to be redone, and the person who started this “patchwork” story loses its place (or maybe he himself left office long ago, anticipating possible problems). So with the construction of information security systems in the enterprise. We are too used to thinking in grocery categories. Here we will buy Cisco ASA (probably because we don’t know other firewalls from Cisco), then we will install the Cisco Web Security Appliance (although Cisco Umbrella could have been dispensed with), then I need an anti-virus <iRomer> (although the customer has encountered file-free attacks ), then we put certified crypto gateway (although you can do with the VPN functionality built into the router or the operating system) ... It all started a long time ago when there were players with a single product on the market that solved a specific task. So there was a substitution of concepts - “problem solving” was replaced by “product”. But as time went on, the portfolio of manufacturers expanded, the functionality of the products, too, but the “I want the product” approach remained.
I sometimes envy niche vendors for cybersecurity. What is good work for them? A small set of products that solve very specific problems. For example, a customer needs a firewall - here’s your firewall. No discrepancies and disagreements - everything is extremely clear. The maximum that a dispute can get out of is which model is needed - at 250 or 600 megabits per second? It is necessary for the customer, for example, to block Skype in his network - again, here's a firewall with the corresponding function (if it is in the ITU, of course). Everyone is happy. A vendor who stamps commercial offers in batches (there is only one product - you won’t clear up). A customer who, at his request, receives a finished offer with a specific price. A partner who does not need to be competent in various solutions.
In Cisco, the situation is slightly different. Let's start with the fact that we have seven of the same firewalls:
')
- Cisco ASA 5500-X
- Cisco Firepower
- Cisco ASAv
- Cisco Virtual Security Gateway
- Cisco IOS Firewall
- Cisco Meraki MX
- Cisco ASA SM for Catalyst.
And this is if not considered discontinued 10 years ago, but still used by some customers, Cisco Pix, as well as various ITU “application”, for example, Cisco Umbrella DNS filter, Cisco Web Security Appliance HTTP filter, etc. ., which, with some stretch, but can also carry the proud title of firewalls for certain tasks.
And so even the usual request “yes, we would have a normal firewall”, we can’t just answer. Yes, and it is not correct. It is very important to choose the means of protection not from its name or type (for example, many manufacturers have NGFW, but understanding of what NGFW is, everyone has different) or their idea of ​​the product, but from the problem being solved and detailed study of the characteristics and functions of the existing from the manufacturer's portfolio. In the case of Cisco, our products use a lot of cross or similar technologies and it is better to discuss their right choice with representatives of the manufacturer or a qualified partner. Moreover, we are always open for consultations and ready to help our customers and partners.
Therefore, when making calls similar to the one above, we begin to “get bored” and clarify which customer needs a firewall to solve. Does he need a firewall to limit access at the network level? To protect virtualized environments? To control applications? With the binding of rules to user accounts or not? For installation on trunk lines or on a remote site? And all because our cybersecurity portfolio is quite broad and banal answer “buy our firewall and you will be happy” we cannot therefore give. We are guided by the principle that the problem being 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 “to drive all traffic, even internal, through the perimeter ITU is normal” or that “put a perimeter IDS on each trunk or SPAN port and you solve your problem ”, we do not work like that. First, the problem to be solved and (or) the threat model is determined, and then an appropriate solution is selected for them, which may differ from the originally intended one by the customer.
But let's try to go beyond the firewall only? After all, the range of cybersecurity solutions is much wider and not 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)
- Cisco Cloud Cloud Web Security (CWS)
- Cloud 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 as needed. But they do it in different ways. For example, Cisco Umbrella monitors all DNS requests from the corporate network or from a mobile device. And CWS (or its new reincarnation of Cisco Securu Internet Gateway) sends all HTTP / HTTPS requests through the nearest cloud, which is especially useful for mobile workers. WSA and Firepower operate along the same lines as CWS technology (categorized URL base), but must be installed on the perimeter of the protected network. However, the differences between these four products are not limited to this. The same Firepower, in addition to URL filtering, can detect malicious files downloaded from the visited pages, and WSA adds to this the analysis and analysis of Web pages on the fly (if they are not in the URL database), and the ability to scan the page before submitting to it user access 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, another solution comes into play Cisco - CloudLock , belonging to the class Cloud Access Security Broker (CASB). In other words, Cisco solutions for controlling Web-access, in addition to their main function, also have enhanced functionality, which distinguishes them from each other. And the whole range of solution functions and the challenge facing customers will influence its choice.
Let us take another example - the fight against extortionists who try to connect with command C2 servers in order to load new functionality, receive commands or organize data leakage. At Cisco, different solutions have this kind of security functionality:
- The Cisco Stealthwatch network anomaly monitoring system, which analyzes NetFlow telemetry and can detect communication attempts with command servers that even go around the perimeter (via unprotected Wi-Fi or 3G / 4G modems).
- The already mentioned Cisco WSA solution, which monitors the outgoing network and communications passing through WSA on all 65,000 or more TCP ports in order to identify attempts to connect to well-known C2 servers.
- Also, the already mentioned Firepower (or ASA, or Meraki MX) monitors all network connections and, using embedded NGIPS intrusion prevention technology, as well as regularly updated lists of C2 servers, allows you to block connections with them.
- The cloud service Cisco Umbrella, passing through all the DNS traffic, identifies connections with malicious nodes, both from inside the corporate network and beyond, from mobile devices or remote sites that are not equipped with any means of protection.
- The anti-malware system, Cisco Advanced Malware Protection (AMP) for Networks and for Endpoints, controls the anomalous behavior of files and their attempts to connect with outsiders, including and malicious nodes.
- Solution Cisco Cognitive Threat Analytics allows you to detect the work of malicious programs on the trail in the Web-logs with a proxy or firewall.
- Finally, the Cisco Email Security Appliance email security tool does not allow the encryptor to reach the user's computer through the mailbox (and this is still one of the main channels of infection for users, even despite the story of WannaCry ).
Which of the following seven solutions should be chosen to block infection by cryptographers and interact with the management servers of malware? Again, it all depends on what other tasks from the point of view of information security we want to solve. Do we need only a fight against extortionists, or do we need a solution for protecting the “all in one” perimeter (Firepower is better suited here)? Or maybe we need the protection of mobile devices? Then the Cisco Umbrella will be the best choice. Finally, if we are not sure that all traffic goes only through the perimeter, then we cannot do without the Cisco Stealthwatch. But most likely one solution here and not at all to do and need a complex of several technologies.
Let's take another example that 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 course of the “debriefing”, it turned out that the customer needed the function of blocking Skype and Cisco WSA to cope with it not very well. Let's try to figure out why the customer was unsatisfied?
To begin with, at the time of the situation analysis, 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 well) should be done skillfully and with an understanding of the various methods of communication in Skype:
- using UDP connections with other subscribers on randomly selected port numbers
- using TCP connections with other subscribers on randomly selected port numbers
- using TCP connections with other subscribers on ports 80/443
- packet tunneling through a Web proxy using HTTP CONNECT method on port 443.
So in 1-3 cases, traffic usually does not go through the Cisco WSA and, as a result, cannot be blocked by it. And this is not a disadvantage of WSA, but especially the place of its installation in 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 HTTP CONNECT (there is no HTTP User-Agent string). Therefore, it is difficult to distinguish Skype from another protocol using the HTTP CONNECT method. We can try to block such connections, but then “under distribution” will get all Skype users, as well as, possibly, other protocols that use similar methods of communication.
What then to do? How do we solve the problem facing the customer? As I wrote above, it is necessary to make a start from the task, and not the product that “sort of as described” solves it. Based on the above-described 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 an IOS operating system that allows you to recognize applications running through a router. With it, you can easily identify various types of traffic, including those using peer-to-peer technologies with dynamic ports for connections (this includes Skype). In order to block Skype on a regular router, enter the following commands (specifying the correct interface for controlling traffic instead of “GigabitEthernet 0/2”):
(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
To make sure that the policy you have enabled is working correctly, use the show policy-map (or show class-map) command:
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: anyThis 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 forbid everything else. Or it is necessary to prohibit certain functions within Skype itself (chat, 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 over ITU Cisco ASA, as an independent hardware or virtual device, or as an add-on above Cisco ISR router). It is this solution that makes it possible to most flexibly solve the Skype filtering task by various attributes - time, user, operation in Skype, direction, etc. But if you go further, you can prevent the Skype application from running on the user's computer, and you can try to do this with both group policies and independent means of information protection, for example, Cisco AMP for Endpoints.
Take the last example, which often emerges in a conversation with customers and with which this note begins. Customers say, “We want to block Tor. Does your ITU do this? ”Yes, it does. Only here you can block Tor not only with the help of ITU, although this is the most obvious option. Writing to the ITU a regularly updated list of output nodes of the Tor network or addresses of directory servers and everything, we can assume that the problem has been solved. But ... Is this the only option? Of course not. You can block Tor using a Cisco ISR router by submitting to the input a list of matching addresses, which are then translated into a set of ACLs. 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 Cisco AMP for Endpoints, you can hang this task. There are plenty of options - you need to understand that of them it will be better to satisfy the initial conditions.
That is why we always call on 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 ineffectively solve the problem. But no one set the task :-( It often happens that a company, on the basis of its vision, acquires a solution, and then it turns out that it does not cope with the task. Who is to blame in this case?
In other words, it is necessary to build on what foreigners call the fashionable term “use case”. I would single out four types of such scenarios that take place in cybersecurity:
- neutralization of a specific threat (information leakage, ransomware programs, DDoS attacks, phishing, etc.)
- protection / blocking of a certain technology (for example, virtualized data center or Skype or cloud or perimeter)
- implementation of the requirements of any regulation or standard, including requirements for cybersecurity (for example, 31st FSTEC order or a new GOST of the Bank of Russia)
- implementation of any process in IS (for example, incident response or security awareness or IS monitoring).
In each of these four categories there are many scenarios, a universal list of which does not exist (although there are the most popular scenarios).
Coming to the end of the note, I would like to go back to where I started. In order to properly build an information security system in an enterprise, it is necessary not to run to look for product A, B or C, but first to make a list of source data - tasks to be solved (including protected processes, supported protocols and systems, performance, etc.), threats reflected, requirements of regulations, that is, to build on usage scenarios. And only by understanding this, you can proceed to the process of choosing the appropriate solution (and again - not the product, but the decision). Good luck with your choice! And in order to cover the topic of use case a little wider, in the following articles we consider several typical scenarios.
Source: https://habr.com/ru/post/337900/
All Articles