Showing posts with label logs. Show all posts
Showing posts with label logs. Show all posts

Monday, July 22, 2019

Digital Transformation Makes the Case for Log Retention in Cloud SIEMs

As organizations pursue their digital transformation dreams, they’ll migrate from on-premises SIEM to cloud-based SIEM. In the process of doing so, CISOs are taking a closer look at their previous security incident and event log retention policies, and revisiting past assumptions and processes.

For organizations needing to maintain a smorgasbord of industry compliance and regulatory requirements, overall event log retention will range from one year through to seven. Many organizations find that a minimum of one year meets most mandated requirements but err on the side of retaining between three to four years – depending on what their legal counsel advises.

With public cloud, data retention spans many different options, services, and price points. Backups, blob storage, “hot” access, “cold” access, etc. – there are endless ways to store and access security events and logs. With cloud storage dropping in price year-on-year, it’s cheap and easy to just store everything forever – assuming there’s no rush or requirement to inspect the stored data. But hot data, more expensive than the cold option, gives defenders the quick access they need for real-time threat hunting. Keeping data hot for SIEM use is inevitably one of the more expensive data storage options. A balance needs to be struck between having instant access to SIEM for queries and active threat hunting, and long-term regulatory-driven storage of event and log data. Can an optimal storage balance be achieved?


Widely available public threat reports for the last couple of years provide a “mean-time” to breach discovery ranging from 190 to 220 days and a breach containment window of between 60 to 100 days. Therefore, keeping 220 days of security event logs “hot” and available in a cloud SIEM would statistically only help with identifying half of an organization’s breaches. Obviously, a higher retention period makes sense – especially for organizations with less mature or less established security operations capabilities.

However, a sizable majority of SIEM-discoverable threats and correlated events are detectable in a much shorter timeframe – and rapidly detecting these breaches naturally makes it considerably more difficult for an adversary to maintain long-time persistence. For example, automatically piecing together the kill chain for an email phishing attack that led to a malware installation, that phoned home to a malicious C&C, which had then brute-forced the administrative access to a high value server is almost trivial for cloud SIEM (assuming appropriate logging was enabled). Nowadays, such a scenario (or permutation of that scenario) likely accounts for near half of all enterprise network breaches.

My advice to organizations new to cloud SIEM is to begin with a rolling window of one year’s worth of event logs while measuring both the frequency of breaches and time to mitigate. All older event logs can be stored using cheaper cloud storage options and needn’t be immediately available for threat hunting.

Depending on the security operations teams’ capacity for mitigating the events raised by cloud SIEM, it may be financially beneficial to reduce the rolling window if the team is overwhelmed with unresolvable events. I’d be hesitant to reduce that rolling window. Instead, I would recommend CISOs with under-resourced teams find and engage a managed security services provider to fill that skills gap.

A question then arises as to the value of retaining multiple years of event logs. Is multi-year log retainment purely a compliance tick-box?

While day-to-day cloud SIEM operations may focus on a one-year rolling window, it can be beneficial to organize a twice-annual threat hunt against several years of event logs using the latest available threat intelligence and indicator of compromise (IoC) information as seeds for investigation. These periodic events have two objectives: reduce your average monthly cloud SIEM operating costs (by temporarily loading and unloading the historic data) and allow teams to change mode and “deep dive” into a broader set of data while looking for “low and slow” compromises. If an older breach is detected, incrementally older event logs could be included in the quest to uncover the origin point of an intruder’s penetration or full spectrum of records accessed.

Caution over infinite event log retention may be warranted, however. If the breached organization only has a couple years of logs, versus being able to trace breach inception to, say, four years earlier, their public disclosure to customers may sound worse to some ears (including regulators). For example, disclosing “we can confirm customers over the last two years are affected” is a weaker disclosure than “customers since July 4th 2015 are affected”. Finding the sweet-spot in log retention needs to be a board-level decision.

Having moved to cloud SIEM, CISOs also need to decide what logs should be included and what log settings should be used.

Ideally, all event logs should be passed to the cloud SIEM. That is because the AI and log analytics systems powering threat detection and automated response thrive on data. Additionally, inclusion of logs from the broadest spectrum of enterprise devices and applications will help reduce detection times and remove potential false positives, which increase overall confidence in the system’s recommendations.

Most applications and networked appliances allow for different levels of logging, including scaling from error messages to alerts and error messages through to errors, warnings, status messages, and debugging information. In general, the greater the detail in the event logs, the greater the value they bring to cloud SIEM. In this way, upgrading from “normal” to “verbose” log settings can offer several threat response advantages – particularly when it comes to handling misconfigurations and criticality determination.

The symbiotic development of cloud SIEM and cloud AI innovation continues at an astounding pace. While cloud SIEM may be new for most organizations, its ability to harness the innate capabilities of public cloud are transforming security operations. Not only are threats being uncovered quicker and responses managed more efficiently, but continual advancements in the core AI makes the technology more valuable while costs of operating SIEM and storing data in the cloud continue to drop. This makes it possible for companies to make pragmatic use of the intelligent cloud by operating on a one-year window of hot data while getting value out of older data, stored cold, on twice a year threat hunts.

-- Gunter Ollmann

First Published: SecurityWeek - July 22, 2019

Sunday, December 17, 2017

Deception Technologies: Deceiving the Attacker or the Buyer?

Deception technologies, over the last three-ish years, have come into vogue; with more than a dozen commercial vendors and close to a hundred open source products available to choose from. Solutions range from local host canary file monitoring, through to autonomous self-replicating and dynamic copies of the defenders network operating like an endless hall of mirrors.


The technologies employed for deception purposes are increasingly broad - but the ultimate goal is for an attacker to be deceived into tripping over or touching a specially deposited file, user account, or networked service and, in doing so, sounding an alarm so that the defenders can start to... umm... well..., often it's not clear what the defender is supposed to do. And that's part of the problem with the deception approach to defense.

I'm interested, but deeply cautious about the claims of deception technology vendors, and so should you be. It's incredibly difficult to justify their expense and understand their overall value when incorporated in to a defense in depth strategy.

There have been many times over the last couple of decades I have recommended to my clients and businesses a quick and dirty canary solution. For example, adding unique user accounts that appear at the start and end of your LDAP, Active Directory, or email contacts list - such that if anyone ever emails those addresses, you know you've been compromised. And similar canary files or shares for detecting the presence of worm outbreaks. But, and I must stress the "but", those solutions only apply to organizations that have not invested in the basics of network hygiene and defense in depth.

Honeypots, Honeynets, canaries, and deception products are HIGHLY prone to false positives. Vendors love to say otherwise, but the practical reality is that there's a near infinite number of everyday things that'll set them off - on hole or in part. For example:

  • Regular vulnerability scanning,
  • Data backups and file recovery,
  • System patching and updates,
  • Changes in firewall or VPN policies,
  • Curious employees,
  • Anti-virus scanners and suite updates,
  • On-premise enterprise search systems,
  • Cloud file repository configuration changes and synchronization,
The net result being either you ignore or turn off the system after a short period of time, or you swell your security teams ranks and add headcount to continually manage and tune the system(s).

If you want my honest opinion though, I'd have to say that the time for deception-based products has already past. 

If you're smart, you've already turned on most of the logging features of your desktop computers, laptops, servers, and infrastructure devices, and you're capturing all file, service, user, and application access attempts. You're therefore already capturing more of the raw information necessary to detect any threat your favorite deception technology is proposing to identify for you. Obviously, the trick is being able to process those logs for anomalies and responding to the threat.

This year alone the number of automated log analytics platforms and standalone products that employ AI and machine learning that are capable of real-time (or, worst case, "warm") detection of threats, has grown to outnumber all the tools in the Deception solution category - and they do it cheaper, more efficiently, and with less human involvement. 

Deception vendors were too slow. The log analytics vendors incorporated more advanced detection systems, user behavioral analytics, and were better able to mitigate the false positive problems - and didn't require additional investment in host agents and network appliances to collect the data that the deception technologies needed.

As an enterprise security buyer, I think you can forget about employing deception technologies and instead invest in automated log analytics. Not only will you cover the same threats, but the log analytics platforms will continue to innovate faster and cover a broader spectrum of threats and SecOps without the propensity of false positives.

-- Gunter Ollman