Sometimes, it is more valuable to say the failure factors of a project than the success factors.

Last Modified @2017-11-21

Last week, in a group, we saw people discussing the topics of Siem, security management platform and SOC, as well as the topic of situational awareness, which is nothing more pessimistic and negative.

Why is that? Is it the reason of Party A (customer)? Or the problem of Party B (supplier, developer)? Or the problems of both parties in the process of project implementation? Is the customer's request unreasonable? Or is it not up to the technical level? Is party a fooling Party B? Or is Party B fooling Party A?

I made some replies in the group and posted some blog articles published earlier (for example, some articles about the planning and implementation of security management projects: Gartner: overcoming the common failure of Siem deployment, investment structure of information security, analysis of the market and technology status and development of domestic security management platform in 2013, value orientation and planning guide, hidden worries of Siem) Rethinking how to use Siem products and Anton chuvakin: Siem landing depends not only on technology;

As well as some articles on the selection of design and safety management technologies: seven criteria for evaluating Siem, Ponemon: challenges to optimize Siem, and a large number of Gartner Siem MQ, key capability analysis, technical evaluation reports, and various research and analysis reports of sans. All in all, there are a lot of such articles in my blog.

I want to say that, in fact, this is a long-standing topic, and I am sure that it will continue to be a topic. Why? Because the construction of Siem / safety management platform is a complex engineering problem, not a technical problem of yes or no.

As a well-known market analysis and consulting company, Gartner has invested most of its energy in the field of network and information security. In all the reports related to the security field, the articles related to Siem / security management platform / SOC occupy an important position, and their report proportion is far higher than that of Siem in the security market, although Siem market is also an important mainstream security market segment. Gartner has studied Siem for a long time, a wide range and a deep degree, which is far beyond other analysis and consulting companies.

Maybe we usually read Gartner's analysis report to understand how to do Siem better, to better enter and develop this market. And this is just Party B's thinking! In fact, a large number of Gartner's analysis reports on Siem are aimed at Party A, and most of them are told to customers / users.

Yes, many times, customers need to know more about Siem / security management platform than manufacturers. Gartner has long been aware of the high failure rate of Siem projects, and has long pointed out that this is not only a technical problem, but also an engineering problem.

To this end, Gartner proposed a Siem guidance framework for customers, covering five stages: planning, implementation (deployment), operation, evolution and expansion. Targeted guidance has been issued for each stage, such as Siem technology implementation plan, Siem project scope and requirements definition guide, Siem technology implementation guide, Siem project requirements proposal writing guide, Siem project POC test guide, Siem technology evaluation, Siem key technology evaluation index system, Siem market points Analysis and key capability analysis, Siem technology, market and supplier evaluation, Siem architecture and operation process guide, analysis of main reasons for Siem project implementation failure, etc. I dare say that in Gartner security, there is no other segment report that has more and more complete Siem! And it's basically updated every year! We can see the importance of Siem and the complexity of Siem (Nan)!

If you want to introduce the whole framework and specific content of each stage of Gartner here, you may have to write tens of thousands of words. Therefore, I will take Gartner's report "overcoming common causes for Siem solution deployment failures" updated in May this year as an introduction to talk about my analysis of the key reasons for the implementation of the Siem / security management platform project.

As in the previous edition, overcoming the common failings of Siem deployment points out six common failings: poor planning, unclear scope, high expectation, too much noise, insufficient situation and insufficient resources. The corresponding original text is: failure to plan before buying, failure to define scope, overall optimal scoring, monitoring noise, lack of sufficient context, insufficient resources.

This time, I will introduce a little: (Note: the following is not the translation, but my understanding of the original text and the summary of my experience in more than ten years)

1) Poor planning: it is to despise the planning and planning links. There is no special project team to use a set of systematic methodology to plan the construction of the whole safety management platform. In fact, many things in the implementation and operation and maintenance stages can be determined in the planning stage. If it is not determined now, it is not reliable to achieve the goals.

2) Ambiguities: if I don't know what I want, it's easy to become what I want. Gartner advocates the idea of "goal oriented", taking "output oriented" and "business output oriented". In addition, I need to adapt to my own reality and gradually improve my safety ability. I need to recognize my own safety status and do what I can to jump up. I don't want to be ambitious (except for budget). Technically speaking, there are two major goals in the construction of safety management platform: compliance goal and threat management goal. Under the two kinds of goal orientation, many construction ideas, deployment architecture, operation and maintenance processes and organizational settings are different.

3) High expectation: This Gartner is still aimed at the scope. A common sentence is "don't body the whole ocean". Even if we choose a clear goal and have a clear technical route, we should continue to iterate step by step when we realize it. Iteration what? There are many things that need to be iterated, but the most important is the iteration of the application case. Application scenarios can produce effects, in fact, they are effect oriented. First of all, some effects (several use cases and application scenarios) will be achieved, so as to be more clear about what to do next, enhance the confidence of all project participants, and enhance the confidence of the management. Then there will be better project management space and more financing.

4) Excessive noise: this topic has been discussed for many years. Often heard is "garbage in, garbage out". Gartner tells us not to collect logs aimlessly. The more, the better, even in the case of big data analysis. Big data also depends on data quality! What kind of logs are collected, and what kind of logs are not collected? What logs are collected first? What logs are collected after? One sentence is "output based design". It is still necessary to design the target requirements from the top down, and then collect the necessary logs according to the requirements. Then expand the requirements and use cases, and gradually collect more logs, or collect more logs along the * * * chain. If you really don't know what logs to collect, you can build a log lake first, and then do log history analysis, audit and log storage.

5) Insufficient context: it belongs to the implementation level, which means that it is not enough to only collect log events. Analysis requires a lot of log related context, that is, context, which is also called context. Situational information includes identity, geographic location, assets, vulnerabilities, threat intelligence, etc. But what scenarios are needed are related to goals and use case design.

6) Insufficient resources: it belongs to the operation and maintenance level, which mainly refers to the failure to consider and plan the resources in the operation and maintenance safety management platform. In order to operate, operate and maintain the safety management platform, Gartner believes that three kinds of personnel are needed: run, watch and tune. The operator is to guarantee the whole software and hardware resources of the security management platform, to ensure the availability and continuity of the system itself, including the management of storage space. The observer is the front line operation and maintenance. It needs to operate and observe the person on duty in front of the system screen for a long time. Tuning is a senior analyst and manager who is responsible for continuously optimizing the analysis ability of the system, issuing reports, carrying out (or coordinating) emergency response disposal, and solving the security problems found. All three are indispensable! If the resources are insufficient, we can consider using partial outsourcing, remote outsourcing and on-site outsourcing. But not blindly outsourcing!

===============My understanding===============

I think the most important of all is planning! The plan here also includes planning. If you regard Siem / SOC / security management platform as a technology, a product, you will not think that planning / planning is a very important thing, because it is basically a purchasing behavior. But if you take Siem / security management platform / SOC (too troublesome, please allow me to refer to three in any of the three words later, unless otherwise noted) as a project, which is a security construction project / project that allows customers to have certain security capabilities, you will find that the whole decision-making process and procurement process are quite different.

The security management platform is very complex, because it is an integrated technology, built on other security mechanisms, and needs to be matched by customers in all aspects. Now the so-called ngsoc and situation awareness are the same. Don't use situational awareness as a panacea or a gimmick.

More importantly, the planning here does not mean how to select and evaluate the supplier's safety management platform, but mainly to make clear what customers want, what goals they want to achieve and how to achieve them. Yes, planning refers to the customer's own safety construction planning! I've seen too many wrong plans. The wrong beginning is the beginning of the target lost, and all the work behind will become the great fortune.

I always tell my customers that you can invite all manufacturers to come and introduce their products and functions, but the key is to start from their own needs, listen to what they don't listen to, and distinguish what they don't listen to, and be determined. The clearer your goals and plans are, the more determined you are.

Nowadays, the functions of the security management platform are very complex, and there are many points to meet the needs of customers. If the customer doesn't think clearly about it, let the manufacturer come and give a speech. In just a few rounds, most of them will find that, well, this is very good, well, I also want to, well, we do have this problem, well, that problem is really important. Finally, based on these exchanges, the construction goals and needs you have summed up are likely to have problems. Typically, they are large and comprehensive.

Therefore, in the planning stage, self demand analysis is very important. At this time, even if external manufacturers are invited to come here, they can not talk about products, but help themselves to analyze and sort out needs. Customers can be vague about their own needs (very normal), but they must have a better understanding of the methodology of the construction of the safety management platform, otherwise it is easy to be over guided by the manufacturer. What is the methodology of safety management platform construction? This includes the Siem construction framework of Gartner, how to define their own security requirements, how to conduct POC testing, and how to build their own security management team. If you really know something about it, you should be careful. First, build a mini security management platform, or get started with Siem, or just outsource SOC.

In addition to the understanding of the safety management platform construction methodology, there is also a clear understanding of the current situation of the safety management platform industry, which is neither optimistic nor pessimistic. Don't be too technical and idealistic, suggest too high expectations, and over expect those emerging technologies (emerging is just emerging, but immature, not repeatedly proven). For example, it's easy to say that our security management platform project should realize security automation, apply AI technology, automatically discover unknown threats, and automatically deal with security issues. Don't just say that SOC is useless, Siem is useless, and log collection is useless. No one has done a good job of SOC at present. In fact, SOC projects that are not well done are more widely spread in the industry than SOC projects that are well done. Every case of failure should be deeply understood and analyzed, whether it is technical or non-technical. I think it's more non-technical. More and more in-depth understanding of the specific problems of customers helps to build their own correct understanding of the safety management project.

Well, with methodology and correct cognition, can we make a good plan? No! As Gartner stresses, customers also need a team! Yes, I agree with that, especially for large customers. This team should be established in the planning stage. The core strength of this team is the core strength of SOC operation and maintenance in the future. Or at least the operation and maintenance personnel should participate in the future. The client cannot make SOC into a simple construction / handover project. Because, when planning, we should take a lot of things of future operation and maintenance into consideration, think clearly, and even do a good sand table exercise.

OK, go to plan! In the planning stage, the core work is to determine the construction vision, route roadmap, current goal and scope, long-term goal and achieved path, selection of technical route, selection of operation mode, detailed requirements, list of qualified suppliers, etc.

I think there are several points to pay attention to when making specific plans:

1) We should organically combine SOC construction planning with our own overall information security construction planning.

As SoC / security management platform is a platform software and a system running through the whole security mechanism horizontally, it is closely related to the overall planning of information security construction. If it is not considered carefully, the impact on the overall construction of information security is not small. For example, I have encountered many SOC projects that are not well integrated with the overall safety construction goal of the customer, resulting in the failure of planning, and then continuous tailoring, and finally the success of the project is difficult to guarantee. For example:

● hardware resources required for SoC construction are not available, and there is no place for mass data storage;

● many SOC projects have not made their own plans for the systems to be accessed, and they do not have the right to participate in the "define interfaces in advance" thing, which can only stay on paper;

● the relationship with surrounding systems is not well defined, such as work order system, ITIL system, NOC, CMDB, etc;

● there is no clear plan for SoC operation Department and organization personnel. The three people who are currently involved in the project are the three people who will use SOC in the future, and their goals are still high. It is clear that they want to make these three people tired to death, which scares them to death.

Many times, people who do SOC project planning can't participate in the overall safety planning, so it's sad.

2) Platform use process and organization planning must have.

Many people talk to me about technology and implementation when planning, but they don't talk about the use process and personnel organization arrangement, or they can't reach the level, and they don't talk about it, or they despise the process, value technology, and expect automation and intelligence to solve problems. What's more, if someone reminds me in good faith, I will ask if you can't do it? I had to shut up. Ppt, I've talked about these three things n times, and Gartner has talked about them n times, but some people don't believe it. Gartner's suggestions are even better. They all suggest that customers define the process in advance and repeat it in advance. On a simulated platform (paper), they can run through it in advance, so that they can define their job responsibilities in advance.

3) At the tactical level, especially for the construction of the current security management platform, in terms of the current goal and scope, we should avoid the problems of "unclear scope" and "high expectation" mentioned by Gartner.

As mentioned earlier, there are two application scenarios for Siem: compliance and threat detection management. At the same time, I have listed six types of systyle for the safety management platform.

But in the actual work, many customers are not willing to choose only one type, often choose a variety, there are still choices to all. In addition to all that is required, we generally face the situation that customers need two or more mixed application scenarios. At this time, how to carry out the next planning and design?

I think it is still necessary to distinguish the primary and secondary, and the order. Too many goals, not a good thing. Designing application scenarios (use cases) is a great idea in the planning phase, which is highly advocated by Garner. There are many reports and related articles on how to write use cases. To say that this method is good is to set the future application occasions of the system, list the priority security problems to be solved in advance, and achieve the goals, and can be proved by formal methods. Through use cases, objectives and requirements can be well proved, and suppliers' capabilities can also be verified. Of course, in the specific practice process, this use case design is not a simple technical problem (if it is good), it needs a good overall project management ability, as well as the support and authorization from the management of Party A and Party B. I also have the honor to participate in the preliminary planning of the project in this way, with a little feeling.

4) Technical route selection, which is also a key consideration in the planning stage.

For example, is big data technology adopted? Do you need distributed deployment? How to deploy? How many events? How much storage? Cloud deployment or physical deployment? Which networks and departments are involved, what kind of authorization is needed, and what kind of transformation is needed for the existing network? These questions are not simply for the suppliers to answer. If they say so, they will say that we all support it. It depends on your needs. Therefore, this requires the planning team of the customer to do a good job, and the manufacturer can provide consultation. In this part, there is also a question about whether to use the technology of foreign manufacturers or that of domestic manufacturers, which is also an interesting topic. Let's talk about it later.

5) We will talk about supplier evaluation and POC test later.

Entering the implementation stage, the project manager's project management ability will be more tested, sometimes even the project group management. Especially as a platform project, it involves a lot of interaction with various security mechanisms and other systems, and the project pressure is very high. It is not easy for Party A's project manager and Party B's project manager to cooperate and make a reasonable project plan. Especially if the project involves customization development, there is also the content of R & D project management. Of course, if the homework in the planning / planning stage is done well enough, the technical pressure and delivery pressure in the implementation stage will be much smaller, but the progress and quality pressure, as well as the ability of emergency management and communication can never reduce any requirements, otherwise there will be a good plan, the implementation process will be distorted, and the goal will not be achieved.

Then there is the operational delivery and operation stage, as well as the stage of continuous evolution and expansion. I won't say much here, but I'll talk about it next time.

As I think above, the time is short and the writing is a little sketchy. If you have any objection, please put forward it. Please correct it. I will revise it from time to time.