By creating a single view of all network data, you can do things better like correlating threat information to identify real attacks or keep a log of packet statistics to better diagnose intermittent networking problems.\nHowever, to turn data into value with the limitations of traditional systems, we must be creative with the solution. We must find ways to integrate the different repositories in various appliances. It\u2019s not an easy task but an architectural shift that I\u2019ve written about in the past, SASE (Secure Access Service Edge), should help significantly.\nSASE is a new enterprise networking technology category introduced by Gartner in 2019. It represents a change in how we connect our sites, users, and cloud resources.\nThis can be of considerable support, especially when it comes to the challenges faced with SIEM (Security Information and Event Management).\nCreating a single view is challenging\nCreating a single view of the different types of data requires specialized skills, custom integration, and a significant budget. The SIEM is used to bring data from multiple products, apply rules and orchestrate a variety of platforms to act together. In reality, there is a lot of custom integration involved.\nThe questions that surface is; how do logs get into the SIEM when off the network? How do you normalize the data, write the rules to detect for suspicious activity and then investigate if there are legitimate alerts? Unfortunately, the results are terrible for the investment that people make. The SIEM can\u2019t be performed in a small organization. You will need the resources to pull it off.\nChallenges with the SIEM\nIn a previous consultancy role, I experienced first-hand the challenges of running a SIEM. Ultimately, the company had to improve its security monitoring. Like most, they came across the same problem and recognized there was a big gap when it came to detection.\nWhen I first came across the potentials of the SIEM, like most, I was thoroughly excited by its hype. Now, there was a tool that allowed me to take my ideas and run them against numerous rich data sets. From these sets, I could get immediately gain insight into threats on the network and act. However, this is far from reality - the SIEM is complex.\nDifferent data from different devices\nBoth security and networking store and expose data differently. Each of them carries out an individual role and have access to different data. Data can be abstracted from the management, control and data planes to build analytics that can be queried. This results in multiple levels of data available for analysis. Essentially, for this, you need to be an expert in each of these planes.\nPreparing all the data gathered from your entire infrastructure is complicated. Developing a timeline of events requires mastering a range of protocols and APIs just to retrieve the necessary data from networking and security appliances. Therefore, it can be a challenge to find the right data for your problem.\nFirst, you need to collect the right data\nFirstly, you need to collect the right data - the SIEM is only as good as the data you feed it with. This emerges the urge for the right data that needs to get loaded to the SIEM. Since the data available with SIEM rules is provided from logs and event data from other software products, the quality of the data comes down to what was first chosen to be logged. This is compounded by the accuracy\/availability of the SIEM vendor's connector.\nThe data may be fed into the SIEM with Syslog, which requires parsing, loss of data and context from the original source. Evidently, a lot of the times, the SIEM is loaded with useless data. Many often stumble with this first step.\nAggregate the data\nWhen new threats materialize, it\u2019s challenging to gather more data to support the new detection rules. There is also a long lead time associated with collecting new data and putting the brakes on agility. In short, the SIEM requires extensive data collection infrastructure and inter-team collaboration.\nNormalize the data\nThere will also be some kind of normalizing event where the data is cleaned up. Here, data interpretation and normalization technologies are needed to store the event data in a common format for analysis.\nA big claim-to-fame for the SIEM products is that they normalize data input. If you examine a windows security event, there is a big distinction between each of these events. Therefore, it\u2019s recommended not to count on the SIEM products to interpret the inputs they receive.\nNo investigation support\nThe SIEM has no investigation support. Hence, once the data is in your SIEM, you must be the one to tell the SIEM what to do with it. It\u2019s like buying an alarm clock without the batteries. Consider an intrusion detection system, we all know that a skilled analyst is required to translate the output into actionable intelligence; a SIEM is no different.\nTypically, the SIEM rules are targeted for detecting the activities of interest rather than investigating them. For example, an event can only tell you that a file was uploaded. However, it tells nothing about what type of site it was uploaded to, where it came from and what the file was.\nThis, predominantly, involves investigation between the security analyst and the operations team. Performing the querying and utilizing this information requires specialized skills and knowledge.\nDeployment\/resource-heavy\nA lot of resources are spent to manage SIEM. Time is needed for deploying agents, parsing logs, or performing the upgrade. Concisely, SIEM technology requires 24x7 monitoring and maintenance. By and large, the SIEM takes too long to deploy and some of these stages can even take years to complete. You really need a handful of full-time security analysts to do this. As it stands, there is a worldwide shortage of experienced security analysts.\nPoint solutions address one issue\nThe way networking and security have been geared up is that we are sold everything in pieces. We have point solutions that only address one issue. Then there are servers, routers, switches and a variety of security devices. When a device operates within its own domain, it will only see that domain. Therefore, these point solutions need to be integrated so the user can form a picture of what is happening on the network.\nConsider an IDS, it looks at individual packets and tries to ascertain whether there is a threat or not. Practically, it does not have a holistic overall view of what is truly happening in networking. So, when you actually identity there was a problem, you simply don\u2019t have the right information at hand to identify who the user is, what it does and what happened.\nFor threat investigation, the user will need to log on to other systems and glue the information. This will result in a high number of false positives in a world that already has alert-fatigue.\nHow SASE can help \u2013 a common datastore\nSignificantly, SASE converges the functions of both networking and security into a unified and global cloud-native service. Therefore, it pulls data from both the domains into a common data store. There are of course many benefits to this but one of the substantial benefits is troubleshooting.\nSASE vendors could make it very easy to drill deep into the networking and security events that should already be stored and normalized in a common data warehouse. SASE unlocks the potential for super-efficient troubleshooting without the pain of deploying a SIEM.\nA case in point is Cato network\u2019s recent announcement of Cato Instant*Insight. The new feature to its SASE platform provides a single tool for mining the security and networking event data generated across a customer\u2019s Cato instance. That\u2019s how SASE helps. Profoundly, everything becomes easier when your networking and security data is being gathered by one platform.\nWith data pulled together, investigation and analysis become easier. Cato Instant*Insight, for example, organizes the millions of networking and security events tracked by Cato into a single and queryable timeline. Here we have an automated aggregation, faceted search, and a built-in network analysis workbench.\nNetsurion, another SD-WAN vendor, provides a managed SIEM service. This is offered as SOC-as-a-Service. However, with this and other managed SIEMs, there may still be a strong separation between the network domain and a security domain. In the sense that they\u2019re only gathering security data and not network data. Therefore, both NOC and SOC teams have a fragmented view. And the common challenge for the enterprise will still remain.\nWith the SIEM, there is no such thing as delivering visibility out-of-the-box. Realistically, it requires extensive custom integration and development. For many companies, SIEMs wasn\u2019t feasible. The integration costs were just too high and too much time was needed to gather baseline data.\nBut that\u2019s all premised on a misconception that you continue to build your network from the appliances from different vendors. If you were to replace appliances with a converged cloud infrastructure, then you eliminate much of the challenge of the SIEM.