pixel_dreams - Fotolia
Anton Chuvakin, an analyst with Gartner, identified the initial incident detection and response processes an organization needs starting out. Above all, IT teams need to have a security incident response process and, ideally, at least a part-time incident detection and response coordinator. Teams that have any form of detection in place will receive alerts and must have an alert triage process.
Chuvakin said while automation can ease the burden, it doesn't do all the work. Likewise, even managed security service providers, which use a joint triage approach, still require customers to review and act upon many alerts.
According to Chuvakin, any list of first steps should include incident detection content tuning and a lightweight use case management process, which can include setting a baseline for certain users or blocking certain rules on a server.
Additionally, he said teams should plan for lightweight threat assessment, gaining insight on the nature of threats and conducting threat intelligence. Especially in less mature incident response efforts, good reporting and metrics are also needed to justify security measures to business leaders.
Read more of Chuvakin's advice about incident detection and response.
Adding security to packet capture
Drew Conry-Murray, writing in Packet Pushers, looked into ExtraHop's launch of Reveal(x), the vendor's first security release. The new anomaly detection software spots unusual behavior with the help of the company's cloud-based machine learning engine, Conry-Murray said, highlighting such activities as privilege escalation or potential data exfiltration efforts.
The software assembles metadata from different packets, analyzing Layer 2 to Layer 7. Reveal(x) also plots the relationship between clients and network devices to trace potentially troublesome activity.
Conry-Murray said ExtraHop anticipated many users might hesitate about sending their internal data to the cloud for processing. To overcome those fears, the company engineered Reveal(x) so only summary metrics are transmitted; no personally identifiable information or customer data is sent.
Additionally, he said transmissions undergo end-to-end encryption, and data is never comingled between customers, with each client receiving a dedicated stack.
Dig deeper into Conry-Murray's thoughts on ExtraHop's new security software.
How do EVPN and VPLS compare?
Ivan Pepelnjak, blogging in ipSpace, said he sees no similarity between Ethernet VPN (EVPN) and virtual private LAN service (VPLS), other than the fact that both systems focus on addressing the same problem.
VPLS, he said, did not evolve from a wire-focused service to an endpoint-focused system, such as MPLS VPN. By contrast, EVPN is more similar to MPLS VPN, using IP addresses, MAC addresses and IP prefixes to identify endpoints.
Pepelnjak said EVPN resolved a number of problems, such as localizing dynamic MAC learning, combining Layer 2 and Layer 3 forwarding information, and supporting host IP addresses and external prefixes.
In contrast to the complexities of using multihoming at the VPLS edge, EVPN has built-in support for edge multihoming using Ethernet Segment Identifiers (ESI). The standard also uses ESIs to enable load balancing, allowing vendors like Juniper to eliminate multichassis link aggregation clusters at the network edge.
Explore more of Pepelnjak's analysis of EVPN and VPLS.