Chapter 8: Steps for Successful Implementation

describes the most important steps for scoping, designing, and
deploying a security intelligence and analytics platform.

1.Understand the preparatory and planning actions that are
crucial to success
2.Get insights into what’s involved in designing a security intelligence and analytics platform architecture
3.Learn tips and tricks for smoothly implementing and integrating a security intelligence and analytics platform
4.Review maintenance actions that must be performed on an
ongoing basis to keep the platform effective and efficient

Threat management is much more than selecting a best-ofbreed SIEM platform. It’s also about establishing policies,
making sure that systems log all the necessary security event
information, and implementing sound log management practices throughout the enterprise. Without all these other pieces
in place, threat management will have much less of a positive
impact on the organization.

1.Preparation and planning
2.Solution design
3. Production implementation
4. Maintenance

Preparation and Planning

In the preparation and planning phase, the organization is
performing actions that lay the foundation for designing and
implementing a security intelligence and analytics platform.

It’s only natural to want to jump in and start trying out
products, but this may be premature. Greater emphasis on
preparation and planning up front should help expedite and
smooth the rest of the phases.


Step 1: Define goals and requirements for threat management

1. Improve the accuracy and/or speed (MTTD) of
threat detection
2. Decrease threat response time (MTTR)
3. Expedite enterprise recovery processes
4. Document evidence of compliance with external
security requirements


Step 2: Create and validate policies supporting the requirements

1. Definitions of all threat management-related roles
and responsibilities throughout the enterprise
2.Operational, security, and privacy requirements
for each phase of the security event log management lifecycle, including log generation, collection,
transfer, normalization, archiving, and destruction
3. Requirements or guidelines for how often logs
should be analyzed through machine or manual
means
4. Lists of which general mitigation techniques are
preferred, permitted, and prohibited
5.Requirements and/or guidelines for the actions
to be taken under various circumstances, such as
when it’s okay to use fully automatic mitigation
and when management approval is required before
mitigation


Step 3: Prioritize the implementation of threat management
Solution Design

Threat management is complex, involving many technologies,
people, and processes. Implementation isn’t going to happen
overnight. Some organizations may take years to acquire and
implement all the components, particularly if there’s a need
to stagger technology purchases and address other major
security goals and requirements at the same time. Other organizations recognize an immediate need for improving threat
management and will implement a security intelligence and
analytics platform much more quickly.


Perhaps the most important part of planning threat management implementation is changing the common assumption
that security controls will stop all threats. People need to
understand that some threats will succeed no matter what
security controls are in place. You need to show all levels of
the organization that there’s a serious problem that’s getting
worse, and that threat management is the best weapon against
it. Make threat management a priority and people should be
more supportive of it.

Solution Design
After the preparation and planning phase is complete, solution design begins. In this phase, the organization designs the
threat management architecture, then evaluates products and
services needed to establish that architecture. At the end of
this phase, the organization should know exactly what hardware, software, services, etc. it will be acquiring and deploying
in support of threat management.


Step 4: Design a threat management architecture

In terms of the security intelligence and analytics platform
itself, important characteristics to consider include the
following:
1.Which solution form or combination of forms is
best (hardware appliance, virtual appliance, serverbased software, or cloud-based service)
2.Whether an all-in-one or distributed approach is
best
3.How well the platform can handle expected peak
logging volume, and how easily the platform can be
expanded as volume increases
4.What degree of fault tolerance and redundancy is
necessary for the platform
5.Whether log collection should be agent based
and/or agentless
6. How data retention and archiving should be
handled


Step 5: Evaluate products and services for the architecture
Production Implementation

We still need to highlight one critical part of the threat
management architecture: the intake of one or more threat
intelligence feeds. As the “Threat Intelligence Service Choices”
section in Chapter 7 explored, some threat management
platforms provide considerable flexibility as to which threat
intelligence feeds each organization can use.

If there’s a choice to be made, then by all means the organization should carefully evaluate each candidate threat intelligence service to see which feed or combination of feeds would best meet its needs. And if a platform provides no choice of feeds, the organization should still evaluate the feed
it supports to ensure that it’s of sufficiently high quality to
meet its needs. If it isn’t, consider that a showstopper and
evaluate other platforms instead.

Production Implementation
During the production implementation phase, the components of the architecture are acquired, deployed, integrated,
configured, and customized. Other important elements of this
phase include developing processes related to the solution and
training administrators and others to use the solution

Testing, testing, 1…2…3…

1.Testing updates and upgrades
before deploying them in
production
2.Developing and testing customizations before duplicating
them in the production environment (especially important
for automated mitigations)
3. Training new administrators,
analysts, and other users on
the solution itself and on threat
management principles and
techniques in general

The length of this phase may vary greatly based on the
strength and maturity of the organization’s existing security
technologies components and processes. The timing is dependent on many environment-specific factors, but one thing is
true for nearly every organization: implementation is best
performed gradually. Installing a security intelligence and
analytics platform and trying to get it to consume, analyze,
and report on 10,000 new logging sources all at once is almost
certainly going to cause chaos. It’s much more productive to
focus on achieving the most important use cases first, thus
getting real value from the platform quickly, and adding the
other use cases over time.


Step 6: Acquire, deploy, and integrate products and services

One of the most important parts of threat management implementation is enabling automated mitigation actions. When
you’re working with a new security intelligence and analytics
platform, you should definitely begin integrating it with the
enterprise security controls that it can manipulate through
mitigation actions.

However, it’s extremely unwise to enable automatic mitigation
until the platform has been in full production use for a bit.
Activity needs to be monitored for days or weeks (even a few
months in some environments) to identify false positives and
other conditions that could trigger automatic mitigations, causing denials of service to customers and other legitimate users.


Step 7: Gradually transition log sources to the solution

This step is generally the most labor intensive of all, because it
may necessitate changing the configuration of every enterprise
security control, operating system, database, and other critical
enterprise applications so that they all log the necessary security event information locally and participate in transferring it
to the centralized solution.

There are many options for getting log data from the log
sources to the security intelligence and analytics platform. For
example, some solutions pull data from the sources, while
others have the sources push their data to the platform. Most
platforms support the use of both agent-based and agentless
technologies. The primary disadvantage of agent-based technology is that software has to be installed on each system and
granted privileges to access the security logs. On the other
hand, this degree of access also enables the agent software to
gather additional information that the system’s built-in logging capabilities can’t record.


Step 8: Develop processes and train staff on the solution

Processes can be developed, documented, and refined in
accordance with how the solution actually behaves in the
production environment, such as what volume of logs the
platform itself generates on a daily basis.


Step 9: Customize dashboards, mitigations, alerting, etc.
Maintenance

Other customizations, such as those for mitigations, alerting,
and reporting, typically apply to the entire solution and don’t
provide customization capabilities for individual users. These
customizations should be tightly controlled by a small number
of authorized administrators using a formal change management process, because they can affect all users of the solution
and the organization as a whole. An example is accidentally
disabling the wrong alert, which allows serious attacks to go
undetected.

Maintenance
The final phase of threat management implementation is
maintenance. All sorts of maintenance actions are needed over
time, from testing and installing updates to replacing faulty
hardware and adding more storage for data archiving.
Instead of rehashing all the typical maintenance duties that
apply to any enterprise security control, let’s focus on one
particular to threat management: fine-tuning the solution.


Step 10: Refine the solution to improve its performance

Within the description of the production implementation
phase, there are several references to making adjustments
– changing what log sources record, supplementing built-in
operating system and application logging capabilities with
agent-provided logging, changing alert thresholds and
disabling unneeded alerts, etc.

One of the biggest mistakes organizations make time and time
again with enterprise security controls, and especially security
intelligence and analytics platforms, is underestimating how
much time they’ll need for ongoing maintenance. Threats and
vulnerabilities are changing all the time, but so are technologies. There’s always a new application being deployed, a new
operating system coming out soon, or a new form of malware
being detected by enterprise security controls.

———————————————Collected from Definitive Guide™ to Security Intelligence and Analytics————————————————————————–https://logrhythm.com/pdfs/3rd-party-whitepaper/lr-definitive-guide-to-security-intelligence-and-analytics.pdf————————————

Shajib Mahmud

Leave a Reply

Your email address will not be published. Required fields are marked *