Chapter 7: Selecting the Right Solution

provides recommendations for evaluating security intelligence and
analytics platforms for use within your organization.

1.Understand important technical considerations to include in
your security intelligence and analytics platform evaluation
2.Learn what other operational attributes to look for during
solution evaluation

This chapter always refers to security intelligence and
analytics platforms, not SIEMs. While today’s best security
intelligence and analytics platforms are all SIEMs, many of
today’s SIEMs aren’t full-fledged security intelligence and
analytics platforms, so these terms aren’t interchangeable.
When you read “security intelligence and analytics platform”
in this chapter, think of the subset of SIEMs that have broad
and robust threat management capabilities.


Usability:

1.The learning curve:

The platform’s interface should be intuitive and easy for users in all roles to
learn. Options should include hands-on training and detailed, reader-friendly documentation

2.Day-to-day use:

Everyday use of the platform should involve minimal overhead; for example, users should be able to extensively customize
their interface with the platform to automatically conform to their preferences. It’s also important to consider each way in which people will use the platform, such as for search analytics and incident
management


Scalability and Flexibility

Consider both existing needs and likely future needs when
selecting a security intelligence and analytics platform.
Products are available in several forms, including hardware
appliances, virtual appliances, server-based software, and
cloud-based services

Cloud-based services offer the greatest scalability and flexibility, but they also involve significant latency if large volumes
of log data have to be transferred from the enterprise facilities
to the cloud provider. Many organizations also have serious
concerns about storing their sensitive log information in a
public cloud.


Logging Source Support

Every security intelligence and analytics platform should have
built-in support for logs from all major enterprise security
controls, operating systems (with the exception of mobile
device operating systems, which rarely support security
logging), and applications with significant security logging
capabilities (e.g., databases). This support will make solution
deployment faster, and in many cases it’ll also provide
superior log processing, in part because it’s been vetted by
many other organizations.

Other important aspects of a security intelligence and
analytics platform’s logging source support should also be
evaluated, including how accurately the product extracts and
normalizes the necessary information from log fields, and how
well it utilizes the fields from each logging source. For
example, does the product simply report that an error code
301 was observed, or does it have information regarding the
significance of that error code?


Supplemental Forensic Data Collection

To address this concern, some security intelligence and
analytics platforms can perform their own security monitoring
and logging on behalf of operating systems, applications, and
other log sources with insufficient capabilities. This may supplement existing logging or replace it. For example, a security
intelligence and analytics platform could monitor networks
to capture forensic data on connections and traffic over those
connections that wouldn’t otherwise be available

Some security intelligence and analytics platforms also provide built-in support for the use of forensic data collected by
an organization’s honeypots. A honeypot is a specialized
device that exists solely to attract threats and monitor their
actions. Honeypots provide an effective way of detecting
threats, but more importantly, they give an organization an
opportunity to observe a threat in action and study its
behavior.

Complying with compliance

When performing a security
intelligence and analytics platform
evaluation, determine whether the
product already supports reporting
for all the laws, regulations, and
security frameworks that currently
apply to your organization. It’s also
important to make sure that it
offers robust report customization
capabilities to meet possible future
needs. Your organization could
someday be subject to a regulation
that the security intelligence and
analytics platform vendor can’t
support.


Machine Analytics:

As Chapter 4, “Automating Discovery through Security
Analytics,” explained, machine analytics comprise the vast
majority of security analytics workloads because they’re highly
automated. However, even though they’re critically important
to threat detection, they’re also very difficult to evaluate.
That’s because every security intelligence and analytics platform needs time to establish baselines and needs tuning
to take into account the unique and unusual characteristics of
the environment.

If at all possible, conduct hands-on testing of machine
analytics capabilities in your environment before acquiring a
security intelligence and analytics platform. Although this
takes additional time, it’ll result in a better decision and will
also speed the official production deployment process.


Search Analytics

The dashboard is the core of the search analytics interface.
Any evaluation of a security intelligence and analytics platform should include hands-on testing of the dashboard by
some of the people who’ll actually be using it in production.
The dashboard should provide all the necessary up-to-date
information on demand, making a security administrator’s life
easier


Threat Intelligence Service Choices

Some platforms enable the use of nearly any commercial or
open source threat intelligence service feed. This flexibility
allows an organization to change or add threat intelligence service usage on demand, which is an incredibly valuable
capability that could be a game changer at any time.

Some organizations may benefit from using two or more
threat intelligence feeds simultaneously. This approach should
provide a somewhat more comprehensive snapshot of current
threats, especially if different feeds don’t provide exactly the
same types of metadata for each threat. Multiple feeds also
help with search analytics because security administrators can
see if the information on a particular threat is consistent from
one feed to another. Consistency increases confidence in the
nature of the threat.


Automated Investigation and Mitigation Capabilities

Chapter 6, “Streamlining Threat Response Processes,” listed
several examples of common mitigation techniques. All of
these can be automated through one mechanism or another.
For example, a security intelligence and analytics platform
might have built-in support for interactions with other enterprise security controls to initiate certain mitigations. Other
mitigations could be performed through automated means
by having the platform launch a custom script written by the
organization’s security or system administrators.


Customization

1.Dashboards: both the layout of each user’s dashboard and the parameters used to generate each
element
2.Alerting and prioritization: such as setting thresholds for alert generation, disabling generation of
unnecessary alerts, and specifying how to weigh
various factors when setting alert priorities
3.Mitigation: including defining what circumstances
should trigger automatic mitigation actions and
tailoring mitigation actions to take advantage of
other enterprise security controls

Don’t fall into the trap of perceiving extensive security
intelligence and analytics platform customization capabilities
as being more important than the platform’s out-of-the-box
capabilities. Some platforms rely on the organizations
adopting them to devote countless hours to customization
before they’re able to be of value. All evaluations should factor
in key out-of-the-box capabilities, such as built-in rules for log
normalization, analysis, and correlation; default searches,
queries, and reports supporting common scenarios; and
scripts for initiating automated mitigation actions.


Technical Support

In addition, it’s important to know how technical support
will function during emergencies. Questions to ask vendors
include the following:
1.Is support available at all times, even on holidays?
2.What is the guaranteed maximum response time
for technical support inquiries?
3. If the platform is hardware-based, how quickly will
hardware be replaced if there’s a serious defect or
malfunction during the warranty period?

———————————————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 *