Login
The U.S. Department of Justice (DOJ) recently revised its policy on charging violations of the Computer Fraud and Abuse Act (CFAA), a 1986 law that remains the primary statute by which federal prosecutors pursue cybercrime cases. The new guidelines state that prosecutors should avoid charging security researchers who operate in “good faith” when finding and reporting vulnerabilities. But legal experts continue to advise researchers to proceed with caution, noting the new guidelines can’t be used as a defense in court, nor are they any kind of shield against civil prosecution.
In a statement about the changes, Deputy Attorney General Lisa O. Monaco said the DOJ “has never been interested in prosecuting good-faith computer security research as a crime,” and that the new guidelines “promote cybersecurity by providing clarity for good-faith security researchers who root out vulnerabilities for the common good.”
What constitutes “good faith security research?” The DOJ’s new policy (PDF) borrows language from a Library of Congress rulemaking (PDF) on the Digital Millennium Copyright Act (DMCA), a similarly controversial law that criminalizes production and dissemination of technologies or services designed to circumvent measures that control access to copyrighted works. According to the government, good faith security research means:
“…accessing a computer solely for purposes of good-faith testing, investigation, and/or correction of a security flaw or vulnerability, where such activity is carried out in a manner designed to avoid any harm to individuals or the public, and where the information derived from the activity is used primarily to promote the security or safety of the class of devices, machines, or online services to which the accessed computer belongs, or those who use such devices, machines, or online services.”
“Security research not conducted in good faith — for example, for the purpose of discovering security holes in devices, machines, or services in order to extort the owners of such devices, machines, or services — might be called ‘research,’ but is not in good faith.”
The new DOJ policy comes in response to a Supreme Court ruling last year in Van Buren v. United States (PDF), a case involving a former police sergeant in Florida who was convicted of CFAA violations after a friend paid him to use police resources to look up information on a private citizen.
But in an opinion authored by Justice Amy Coney Barrett, the Supreme Court held that the CFAA does not apply to a person who obtains electronic information that they are otherwise authorized to access and then misuses that information.
Orin Kerr, a law professor at University of California, Berkeley, said the DOJ’s updated policy was expected given the Supreme Court ruling in the Van Buren case. Kerr noted that while the new policy says one measure of “good faith” involves researchers taking steps to prevent harm to third parties, what exactly those steps might constitute is another matter.
“The DOJ is making clear they’re not going to prosecute good faith security researchers, but be really careful before you rely on that,” Kerr said. “First, because you could still get sued [civilly, by the party to whom the vulnerability is being reported], but also the line as to what is legitimate security research and what isn’t is still murky.”
Kerr said the new policy also gives CFAA defendants no additional cause for action.
“A lawyer for the defendant can make the pitch that something is good faith security research, but it’s not enforceable,” Kerr said. “Meaning, if the DOJ does bring a CFAA charge, the defendant can’t move to dismiss it on the grounds that it’s good faith security research.”
Kerr added that he can’t think of a CFAA case where this policy would have made a substantive difference.
“I don’t think the DOJ is giving up much, but there’s a lot of hacking that could be covered under good faith security research that they’re saying they won’t prosecute, and it will be interesting to see what happens there,” he said.
The new policy also clarifies other types of potential CFAA violations that are not to be charged. Most of these include violations of a technology provider’s terms of service, and here the DOJ says “violating an access restriction contained in a term of service are not themselves sufficient to warrant federal criminal charges.” Some examples include:
-Embellishing an online dating profile contrary to the terms of service of the dating website;
-Creating fictional accounts on hiring, housing, or rental websites;
-Using a pseudonym on a social networking site that prohibits them;
-Checking sports scores or paying bills at work.
Kerr’s warning about the dangers that security researchers face from civil prosecution is well-founded. KrebsOnSecurity regularly hears from security researchers seeking advice on how to handle reporting a security vulnerability or data exposure. In most of these cases, the researcher isn’t worried that the government is going to come after them: It’s that they’re going to get sued by the company responsible for the security vulnerability or data leak.
Often these conversations center around the researcher’s desire to weigh the rewards of gaining recognition for their discoveries with the risk of being targeted with costly civil lawsuits. And almost just as often, the source of the researcher’s unease is that they recognize they might have taken their discovery just a tad too far.
Here’s a common example: A researcher finds a vulnerability in a website that allows them to individually retrieve every customer record in a database. But instead of simply polling a few records that could be used as a proof-of-concept and shared with the vulnerable website, the researcher decides to download every single file on the server.
Not infrequently, there is also concern because at some point the researcher suspected that their automated activities might have actually caused stability or uptime issues with certain services they were testing. Here, the researcher is usually concerned about approaching the vulnerable website or vendor because they worry their activities may already have been identified internally as some sort of external cyberattack.
What do I take away from these conversations? Some of the most trusted and feared security researchers in the industry today gained that esteem not by constantly taking things to extremes and skirting the law, but rather by publicly exercising restraint in the use of their powers and knowledge — and by being effective at communicating their findings in a way that maximizes the help and minimizes the potential harm.
If you believe you’ve discovered a security vulnerability or data exposure, try to consider first how you might defend your actions to the vulnerable website or vendor before embarking on any automated or semi-automated activity that the organization might reasonably misconstrue as a cyberattack. In other words, try as best you can to minimize the potential harm to the vulnerable site or vendor in question, and don’t go further than you need to prove your point.
Netflix has a new documentary series airing next week — “Web of Make Believe: Death, Lies & the Internet” — in which Yours Truly apparently has a decent amount of screen time. The debut episode explores the far-too-common harassment tactic of “swatting” — wherein fake bomb threats or hostage situations are phoned in to police as part of a scheme to trick them into visiting potentially deadly force on a target’s address.
Image: Netflix.com
The producers of the Netflix show said footage from an interview I sat for in early 2020 on swatting and other threats should appear in the first episode. They didn’t specify what additional topics the series would scrutinize, but Netflix’s teaser for the show suggests it concerns cybercrimes that result in deadly, real-world kinetic attacks.
“Conspiracy. Fraud. Violence. Murder,” reads the Netflix short description for the series. “What starts out virtual can get real all too quickly — and when the web is worldwide, so are the consequences.”
Our family has been victimized by multiple swatting attacks over the past decade. Our first swatting, in March 2013, resulted in Fairfax County, Va. police surrounding our home and forcing me into handcuffs at gunpoint. For an excruciating two minutes, I had multiple police officers pointing rifles, shotguns and pistols directly at me.
More recently, our family was subjected to swatting attacks by a neo-Nazi group that targeted journalists, judges and corporate executives. We’ve been fortunate that none of our swatting events ended in physical harm, and that our assailants have all faced justice.
But these dangerous hoaxes can quickly turn deadly: In March 2019, 26-year-old serial swatter Tyler Barriss was sentenced to 20 years in prison for making a phony emergency call to police in late 2017 that resulted in the shooting death of an innocent Kansas resident.
In 2021, an 18-year-old Tennessee man who helped set in motion a fraudulent distress call to police that led to the death of a 60-year-old grandfather in was sentenced to five years in prison.
The first season of the new documentary series will be available on Netflix starting June 15. See you on TV!
It’s a busy month for cybersecurity, with the return of in-person RSAC in San Francisco, followed by Cisco Live in very lively Las Vegas! With so much happening, and so many announcements from every security vendor out there, it can be hard to keep track of everything going on. Let us help give you the highlights from a Cisco SecureX perspective!
We have been busy this past year, with our acquisition of Kenna Security and our recent innovations around device insights – all helping to expand and strengthen SecureX and our extended detection and response (XDR) capabilities.
Let’s start with device insights. We know that correlation of incidents and alerts is a vital capability for every good XDR offering, but what about correlating and aggregating information about the devices themselves? With the growing number of devices in many customer environments there is also a growing number of products with information about those devices. This can cause duplicate records and multiple alerts from the same device – which means more potentially false positive incidents to investigate, and more headaches trying to manually correlate and connect device information. With device insights organizations can discover, normalize, and consolidate information about all the devices in your environment – so you can avoid duplicate alerts, and discover devices that may be sneaking through gaps in your security. Device insights gives you a comprehensive view into each device’s security posture and management status.
Now, a more insightful view of all the devices across your infrastructure is a must-have, but so is the ability to view and manage vulnerabilities across these endpoints. With Cisco’s acquisition of Kenna Security last year, and our on-going integration of Kenna offerings into the Cisco Secure portfolio, we’re continuing to fortify SecureX and our XDR capabilities with industry leading risk-based vulnerability management. Kenna vulnerability management has already started integrations with Cisco Secure Endpoint, providing vulnerability scores on the OS version, as well as any available fixes. On the SecureX side, Kenna integrations are being leveraged to automatically enrich threat detections with vulnerability information, and automatically create ticketing workflows for Kenna.VM customers using ServiceNow.
With these integrations, and more innovations planned for the near future, risk-based vulnerability management will become a cornerstone for all endpoint and XDR deployments.
Check out our recent blog posts for more information about device insights and Kenna and SecureX orchestration!
Visit us at RSAC at booth 6045 for Cisco Secure, and booth 6362 for Kenna, and at Cisco Live in the World of Solutions to learn more.
At the outset of their federal criminal trial for hijacking vast swaths of Internet addresses for use in large-scale email spam campaigns, three current or former executives at online advertising firm Adconion Direct (now Amobee) have pleaded guilty to lesser misdemeanor charges of fraud and misrepresentation via email.
In October 2018, prosecutors in the Southern District of California named four Adconion employees — Jacob Bychak, Mark Manoogian, Petr Pacas, and Mohammed Abdul Qayyum — in a ten-count indictment (PDF) on felony charges of conspiracy, wire fraud, and electronic mail fraud.
The government alleged that between December 2010 and September 2014, the defendants engaged in a conspiracy to identify or pay to identify blocks of Internet Protocol (IP) addresses that were registered to others but which were otherwise inactive.
Prosecutors said the men also sent forged letters to an Internet hosting firm claiming they had been authorized by the registrants of the inactive IP addresses to use that space for their own purposes.
All four defendants pleaded not guilty when they were charged back in 2018, but this week Bychak, Manoogian and Qayyum each entered a plea deal.
“The defendants’ jobs with Adconion were to acquire fresh IP addresses and employ other measures to circumvent the spam filters,” reads a statement released today by the U.S. Attorney for the Southern District of California, which said the defendants would pay $100,000 in fines each and perform 100 hours of community service.
“To conceal Adconion’s ties to the stolen IP addresses and the spam sent from these IP addresses, the defendants used a host of DBAs, virtual addresses, and fake names provided by the company,” the statement continues. “While defendants touted ties to well-known name brands, the email marketing campaigns associated with the hijacked IP addresses included advertisements such as ‘BigBeautifulWomen,’ ‘iPhone4S Promos,’ and ‘LatinLove[Cost-per-Click].'”
None of the three plea agreements are currently available on PACER, the online federal court document clearinghouse. However, PACER does show that on June 7 — the same day the pleas were entered by the defendants — the government submitted to the court a superseding set of just two misdemeanor charges (PDF) of fraud in connection with email.
Another document filed in the case says the fourth defendant — Pacas — accepted a deferred prosecution deal, which includes a probationary period and a required $50,000 “donation” to a federal “crime victims fund.”
There are fewer than four billion so-called “Internet Protocol version 4” or IPv4 addresses available for use, but the vast majority of them have already been allocated. The global dearth of available IP addresses has turned them into a commodity wherein each IP can fetch between $15-$25 on the open market.
This has led to boom times for those engaged in the acquisition and sale of IP address blocks, but it has likewise emboldened those who specialize in absconding with and spamming from dormant IP address blocks without permission from the rightful owners.
In May, prosecutors published information about the source of some IP address ranges from which the Adconion employees allegedly spammed. For example, the government found the men leased some of their IP address ranges from a Dutch company that’s been tied to a scandal involving more than four million addresses siphoned from the African Network Information Centre (AFRINIC), the nonprofit responsible for overseeing IP address allocation for African organizations.
In 2019, AFRINIC fired a top employee after it emerged that in 2013 he quietly commandeered millions of IPs from defunct African entities or from those that were long ago acquired by other firms, and then conspired to sell an estimated $50 million worth of the IPs to marketers based outside Africa.
“Exhibit A” in a recent government court filing shows that in 2013 Adconion leased more than 65,000 IP addresses from Inspiring Networks, a Dutch network services company. In 2020, Inspiring Networks and its director Maikel Uerlings were named in a dogged, multi-part investigation by South African news outlet MyBroadband.co.za and researcher Ron Guilmette as one of two major beneficiaries of the four million IP addresses looted from AFRINIC by its former employee.
Exhibit A, from a May 2022 filing by U.S. federal prosecutors.
The address block in the above image — 196.246.0.0/16 — was reportedly later reclaimed by AFRINIC following an investigation. Inspiring Networks has not responded to requests for comment.
Prosecutors allege the Adconion employees also obtained hijacked IP address blocks from Daniel Dye, another man tied to this case who was charged separately. For many years, Dye was a system administrator for Optinrealbig, a Colorado company that relentlessly pimped all manner of junk email, from mortgage leads and adult-related services to counterfeit products and Viagra. In 2018, Dye pleaded guilty to violations of the CAN-SPAM Act.
Optinrealbig’s CEO was the spam king Scott Richter, who changed the name of the company to Media Breakaway after being successfully sued for spamming by AOL, Microsoft, MySpace, and the New York Attorney General Office, among others. In 2008, this author penned a column for The Washington Post detailing how Media Breakaway had hijacked tens of thousands of IP addresses from a defunct San Francisco company for use in its spamming operations.
The last-minute plea deals by the Adconion employees were reminiscent of another recent federal criminal prosecution for IP address sleight-of-hand. In November 2021, the CEO of South Carolina technology firm Micfo pleaded guilty just two days into his trial, admitting 20 counts of wire fraud in connection with an elaborate network of phony companies set up to obtain more than 700,000 IPs from the American Registry for Internet Numbers (ARIN) — AFRINIC’s counterpart in North America.
Adconion was acquired in June 2014 by Amobee, a Redwood City, Calif. online ad platform that has catered to some of the world’s biggest brands. Amobee’s parent firm — Singapore-based communications giant Singtel — bought Amobee for $321 million in March 2012.
But as Reuters reported in 2021, Amobee cost Singtel nearly twice as much in the last year alone — $589 million — in a “non-cash impairment charge” Singtel disclosed to investors. Marketing industry blog Digiday.com reported in February that Singtel was seeking to part ways with its ad tech subsidiary.
One final note about Amobee: In response to my 2019 story on the criminal charges against the Adconion executives, Amobee issued a statement saying “Amobee has fully cooperated with the government’s investigation of this 2017 matter which pertains to alleged activities that occurred years prior to Amobee’s acquisition of the company.”
Yet as the government’s indictment points out, the alleged hijacking activities took place up until September 2014, which was after Amobee’s acquisition of Adconion Direct in June 2014. Also, the IP address ranges that the Adconion executives were prosecuted for hijacking were all related to incidents in 2013 and 2014, which is hardly “years prior to Amobee’s acquisition of the company.”
Amobee has not yet responded to requests for comment.
This article is part of a series in which we will explore several features, principles, and the building blocks of a security detection engine within an extended detection and response (XDR) solution.
In this second installment, we will look at ways of structuring the presentation of machine-generated alerts, so that each alert offers a cohesive and compelling narrative, as if written by a human analyst, at scale and in realtime.
In cyber security, we are used to two types of stories.
The first story is common for reports written by humans. It contains sections such as “impact,” “reproduction,” and “remediation” to help us understand what is at stake and what we need to fix. For example:
IMPACT: An SSH server which supports password authentication is susceptible to brute-forcing attacks.
REPRODUCTION: Use the `ssh` command in verbose mode (`ssh -v`) to determine supported authentication methods. Look for “keyboard-interactive” and “password” methods.
REMEDIATION: Disable unneeded authentication methods.
The second story comes from machine detections. It is much terser in content and sometimes leaves us scratching our heads. “Malware,” the machine says with little explanation, followed by a horde of gibberish-looking data of network flows, executable traces, and so on.
The challenge is now to get the best of both worlds: to enhance machine-generated alerts with the richness of human-written reports. The following sections explain how this can be approached.
In our example of a report written by a human, the “reproduction” section would help us understand, from a factual perspective, how exactly the conclusions were derived.
On the other hand, the machine-generated horde of data provides evidence in a very nondescript way. We would need to be smart enough to spot or reverse-engineer what algorithm the machine was following on said data. Most security analysts do not wish to do this. Instead, they attempt to seek the first story type. “Surely, someone must have written a blog or something more descriptive about this already,” they would say. Then, they would copy-paste anything that looks like a searchable term – an IP address, domain, SHA checksum – and start searching it, either on a threat intelligence search site or even a general-purpose search engine.
Having such cryptic machine-generated alerts is leading us to our first two issues: first, when the story is incomplete or misunderstood, it may lead the analyst astray. For example, the security event might involve requests to communicate with an IP address, and the analyst would say, “This IP address belongs to my DNS server, so the traffic is legitimate.” However, the detection engine was really saying, “I suspect there is DNS tunnelling activity happening through your DNS server—just look at the volume.”
Second, when an analyst seeks explanations from elsewhere, the main function of an advanced detection engine — finding novel, localized, and targeted attacks — cannot work. Information on attacks is generally available only after they have been discovered and analyzed, not when they happen initially.
A common approach to remedy this situation is to include a short description of the algorithm. “This detector works by maintaining a baseline of when during the day a user is active and then reports any deviations,” a help dialog would say. “Okay, that’s clever,” an analyst would reply. But this is not enough. “Wait, what is the baseline, and how was it violated in this particular security event?” To find the answer, we need to go back to the horde of data.
To mimic the “reproduction” section of the human-written report, our security events are enriched with an annotation—a short summary of the behavior described by the event. Here are a few examples of such annotated events:
In the first and second cases, the story is relatively straightforward: in the horde of data, successful communication with said hostnames was observed. An inference through threat intelligence associates these hostnames to the Sality malware.
The third line informs us that, on a factual basis, only a communication with an IP address was observed. Further chain of inferences is that this IP address was associated by a passive DNS mechanism to a hostname which is in turn associated to the Sality malware.
In the fourth event, we have an observation of full HTTP URL requests, and inference through a pattern matcher associates this URL to the Sality malware. In this case, neither the hostname nor the IP address is important to the detector.
In all these annotated events, an analyst can easily grasp the factual circumstances and what the detection engine infers and thinks about the observations. Note that whether these events describe benign, malicious, relevant, or irrelevant behavior, or whether they lead to true or false positives, is not necessarily the concern. The concern is to be specific about the circumstances of the observed behavior and to be transparent about the inferences.
When we eventually succeed in explaining the security events, we might not be finished with the storytelling yet. The analyst would face another dilemma. They would ask: “What relevance does this event have in my environment? Is it part of an attack, an attack technique perhaps? What should I look for next?”
In the human-written report, the “impact” section provides a translation between the fact-based technical language of “how” and the business language of “what.” In this business language, we talk about threats, risks, attacker objectives, their progress, and so on.
This translation is an important part of the story. In our previous example about DNS tunnelling, we might want to express that “an anomaly in DNS traffic is a sign of an attacker communicating with their command-and-control infrastructure,” or that “it is a sign of exfiltration,” or perhaps both. The connotation is that both techniques are post-infection, and that there is probably already a foothold that the attacker has established. Perhaps other security events point to this, or perhaps it needs to be sought after by the analyst.
When it is not explicit, the analyst needs to mentally perform the translation. Again, an analyst might look up some intelligence in external sources and incorrectly interpret the detection engine’s message. Instead, they might conclude that “an anomaly in DNS traffic is a policy violation, user error, or reconnaissance activity,” leading them astray from pivoting and searching for the endpoint foothold that performs the command-and-control activity.
We take special attention not to mix these two different dictionaries. Rather, we express separately the factual observations versus the conclusions in the form of threats and risks. Inbetween, there are the various chains of inferences. Based on the complexity, the depth of the story varies, but the beginning and the end will always be there: facts versus conclusions.
This is very similar to how an analyst would set up their investigation board to organize what they know about the case. Here is an elaborate example:
In this case, from top to bottom:
In all points, the “what” and “how” languages are distinguished from each other. Finally, the whole story is stitched together into one alert by using the alert fusion algorithm described in the Intelligent alert management blog post.
Have we bridged the storytelling gap between machine-generated and human-generated reports?
Threat detections need to be narrated in sufficient detail, so that our users can understand them. Previously, we relied on the human aspect—we would need to document, provide support, and even reverse-engineer what the detection algorithms said.
The two solutions, distinguishing the “what/how” languages and the annotated events, provide the bandwidth to transmit the details and the expert knowledge directly from the detection algorithms. Our stories are now rich with detail and are built automatically in real time.
The result allows for quick orientation in complex detections and lowers the time to triage. It also helps to correctly convey the message, from our team, through the detection engine, and towards the analyst, lowering the possibility of misinterpretation.
This capability is part of Cisco Global Threat Alerts, currently available within Cisco Secure Network Analytics and Cisco Secure Endpoint, and has been continually improved based on customer feedback. In the future, it will also be available in Cisco SecureX XDR.
We’d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!
Cisco Secure Social Channels
Extended Detection and Response, or XDR, the cybersecurity topic that dominated the RSA conference 2022 show floor with multiple vendors, has been getting a lot of attention lately, and for good reason. A connected, unified approach to detection and response promises to give security professionals all the tools and capabilities they need to address the ever-growing attack surface.
At Cisco, we wanted to get an independent view of what XDR means to a security operations audience, so we partnered with ESG on a survey conducted in April 2022 of 376 IT cybersecurity professionals in North America, which explored some key questions and trends for security operations centers as it relates to XDR. This new eBook, SOC Modernization and the Role of XDR, provides insights into the survey. Unsurprisingly, 52 percent of organizations surveyed believe that security operations are more challenging than just two years ago, and it’s clear cybersecurity professionals are looking for the next architecture to solve these challenges.
The distributed nature of the network is resulting in more data from multiple control points. The survey showed that while 80 percent of organizations are already using more than 10 data sources as a part of their security operations, they want even more as they realize the value of being able to aggregate, normalize, correlate, and contextualize data so they can take better actions faster. At the same time, 81 percent say that they have been impacted by the cybersecurity skills shortage, and more data without the capabilities and skills in place to act will only diminish the ability to address threats.
To help fill those skills gaps, improved threat detection playbooks and incident prioritization will be critical aspects of the security operations strategy. Another key tool widely recognized as important in building a foundation is the MITRE ATT&CK framework that can help your teams focus and understand adversary tactics and techniques based on real-world observations.
While a common industry definition remains elusive, one thing is clear: XDR will play a critical role in the modernization of the security operations center. Determining how it will help your security operations team, and which partners to work with as you build out your XDR approach, will determine your level of success.
You need XDR to transform your infrastructure from a series of disjointed solutions into a fully integrated ecosystem that gets you to your outcome more effectively and efficiently. Cisco has built XDR capabilities into the broad portfolio of our security products and easily integrates with existing solutions in your environment using open APIs. After you’ve read the ESG SOC Modernization and the Role of XDR eBook, we invite you to take a look at the Cisco XDR Buyer’s Guide, which outlines five key elements of XDR done right and provides some questions to ask as you consider which vendors you want to work with in building out your security strategy. Don’t wait to start planning how XDR will help your security operations team.
Source: ESG Research Study, SOC Modernization and the Role of XDR, June 2022
See XDR done right:
Cisco XDR Buyer’s Guide
A deep dive into the latest updates from Secure Network and Cloud Analytics that show Cisco’s leadership in the Security Industry.
The year 2022 has been rather hectic for many reasons, and as the World undergoes its various challenges and opportunities, We At Cisco Security have buckled up and focused on improving the World in the way which we know best: by making it more Secure.
In an increasingly vulnerable Internet environment, where attackers rapidly develop new techniques to compromise organizations around the world, ensuring a robust security infrastructure becomes ever more imperative. Across the Cisco Security Portfolio, Secure Network Analytics (SNA) and Secure Cloud Analytics (SCA) have continued to add value for their customers since their inception by innovating their products and enhancing their capabilities.
In the latest SNA 7.4.1 release, four core features have been added to target important milestones in our roadmap. As a first addition, SNA has widely expanded on its Data Store deployment options by introducing the single node Data Store; supporting existing Flow Collector (FC) and new Data Store expansion by the Manager; and the capacity to mix and match virtual and physical appliances to build a Data Store deployment.
The SNA Data Store started as a simple concept, and while it maintained its simplicity, it became increasingly more robust and performant over the recent releases. In essence, it represents a new and improved database architecture design that can be made up of virtual or physical appliances to provide industry leading horizontal scaling for telemetry and event retention for over a year. Additionally, the Flow Ingest from the Flow Collectors is now separate from the data storage, which allows them to now scale to 500K + Flows Per Second (FPS). With this new database design, are now optimized for performance, which has improved across all metrics by a considerable amount.
For the second major addition, SNA now supports multi-telemetry collection within a single deployment. Such data encompasses network telemetry, firewall logging, and remote worker telemetry. Now, Firewall logs can be stored on premises with the Data Store, making data available to the Firepower Management Center (FMC) via APIs to support remote queries. From the FMC, users can pivot directly to the Data Store interface and look at detailed events that optimize SecOps workflows, such as automatically filtering on events of interest.
On the topic of interfaces, users can now benefit from an intelligent viewer which provides all Firewall data. This feature allows to select custom timeframes, apply unique filters on Security Events, create custom views based on relevant subsets of data, visualize trends from summary reports, and finally to export any such view as a CSV format for archiving or further forensic investigations.
With respect to VPN telemetry, the AnyConnect Secure Mobility Client can now store all network traffic even if users are not using their VPN in the given moment. Once a VPN connection is restored, the data is then sent to the Flow Collector, and, with a Data Store deployment, off-network flow updates can bypass FC flow caches which allow NVM historical data to be stored correctly.
Continuing down the Data Store journey (and, what a journey indeed), users can now monitor and evaluate its performance in a simple and intuitive way. This is achieved with charts and trends directly available in the Manager, which can now support traditional non-Data Store FCs and one singular Data Store. The division of Flow Collectors is made possible by SNA Domains, where a Data Store Domain can be created, and new FCs added to it when desired. This comes as part of a series of robust enhancements to the Flow Collector, where the FC can now be made up of a single image (NetFlow + sFlow) and its image can be switched between the two options. As yet another perk of the new database design, any FC can send its data to the Data Store.
As it can be seen, the Data Store has been the star of the latest SNA release, and for obvious good reasons. Before coming to an ending though, it has one more feature up its sleeve: Converged Analytics. This SNA feature brings a simplified, intuitive and clear analytics experience to Secure Network Analytics users. It comes with out- of-the-box detections mapped to MITRE with clearly defined tactics and techniques, self-taught baselining and graduated alerting, and the ability to quiet non-relevant alerts, leading to more relevant detections.
This new Analytics feature is a strong step forward to give users the confidence of network security awareness thanks to an intuitive workflow and 43 new alerts. It also gives them a deep understanding of each alert with observations and mappings related to the industry-standard MITRE tactics and techniques. When you think it couldn’t get any better, the Secure Network and Cloud Analytics teams have worked hard to add even more value to this release, and ensured the same workflows, functionality and user experience could be further available in the SCA portal. Yes, this is the first step towards a more cohesive experience across both SNA and SCA, where users of either platform will start to benefit from more consistent outcomes regardless of their deployment model. As some would say, it’s like a birthday coming early.
Pivoting to Secure Cloud Analytics, as per Network sibling, the product got several enhancements over the last months of development. The core additions revolve around additional detections and context, as well as usability and integration enhancements, including those in Secure Cloud Insights. In parallel with SNA’s Converged Analytics, SCA benefits from detections mapped to the MITRE ATT&CK framework. Additionally, several detections underwent algorithm improvements, while 4 new ones were added, such as Worm Propagation, which was native to SNA. Regarding the backbone of SCA’s alerts, a multitude of new roles and observations were added to the platform, to further optimize and tune the alerts for the users.
Additionally, alerts now offer a pivot directly to AWS’ load balancer and VPC, as well as direct access to Azure Security Groups, to allow for further investigation through streamlined workflows. The two Public Cloud Providers are now also included in coverage reports that provide a gap analysis to gain insight as to what logs may have potentially gone missing.
Focusing more on the detection workflows, the Alert Details view also got additional information pertaining to device context which gives insight into hostnames, subnets, and role metrics. The ingest mechanism has also gotten more robust thanks to data now coming from Talos intelligence feed and ISE, shown in the Event Viewer for expanded forensics and visibility use cases.
While dealing with integrations, the highly requested SecureX integration can now be enabled in 1 click, with no API keys needed and a workflow that is seamless across the two platforms. Among some of the other improvements around graphs and visualizations, the Encrypted Traffic widget now allows an hourly breakdown of the data, while the Event Viewer now displays bi-directional session traffic, to bring even greater context to SCA flows.
In the context of pivots, as a user is navigating through devices that, for example, have raised an alert, they will now also see the new functionality to pivot directly into the Secure Cloud Insights (SCI) Knowledge Graph, to learn more about how various sources are connected to one another. Another SCI integration is present within the Device Outline of an Alert, to gain more posture context, and as part of a configuration menu, it’s now possible to run cloud posture assessments on demand, for immediate results and recommendations.
With this all said, we from the Secure Analytics team are extremely excited about the adoption and usage of these features so that we can keep on improving the product and iterating to solve even more use cases. As we look ahead, the World has never needed more than now a comprehensive solution to solve one of the most pressing problems in our society: cyber threats in the continuously evolving Internet space. And Secure Analytics will be there, to pioneer and lead the effort for a safe World.
We’d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!
Cisco Secure Social Channels
FreshRSS 