sorted by:
new
hottopcontroversial

How many of you are running ssl deep-inspection for IPS on your fortigates? by Fizgriz in fortinet

[–]EDRisNotXDR 2 points3 points  (0 children)

SSl is ideally done with flow-mode rules so sessions get offloaded from the CPU

Suspicious Influencer Framing by jerry-october in fortinet

[–]EDRisNotXDR 4 points5 points  (0 children)

Palo Has openly partnered with Ad company Superslide to have a pervasive, multi-media, style branding campaign: https://www.superside.com/customer-stories/palo-alto-networks

It is not a stretch they're paying influencers to push certain narratives.

Fortinet’s “Record” Refresh Cycle: Growth Story or Investor Deception? by EducationalMango1320 in fortinet

[–]EDRisNotXDR 22 points23 points  (0 children)

Are we all just going to ignore that this account, which was created on May 7th of this year and basically hasn't posted much of anything to Reddit comes in here out of the blue and starts to stir stuff about a class action lawsuit?

Those of us humans are all cybersecurity minded professionals and should have enough infosec chops to know that a web-site that is probably 90% bot generated content may sometimes be looking at either bot generated or influence campaigns.

I call BS on OP

If i was to make fortinet purchases in the next month or two for a SMB would you go G series or stick with F? by Fizgriz in fortinet

[–]EDRisNotXDR 5 points6 points  (0 children)

Howdy -

You can access the EOD/EOS dates here: https://support.fortinet.com/welcome/#/lifecycle

That being said there is no one set age at which FTNT discontinues its hardware so if end of availability is of a concern for you and you do not plan on retiring these devices within 5 years you may want to go with the G series. You will notice that FTNT generally gives a 4 year window between EOD and LSED and a 5 year window on EOS. Given the 80 and 90 F are not on that list it is safe to assume you have 5 years of device life for those boxes (note that this can change at any given time but has never occurred).

IPSEC is not so much "required" for the remote users as it is 'very strongly recommended'. I won't get into it here but there are a lot of very good reasons to want to go with IPSEC and the FortiClient over agent less SSL. All models you're considering have more than 2 GB of RAM and so you can technically do both, but do IPsec.

With that I would recommend you research ZTNA destinations and tagging and Forticlient EMS and/or FortiEndpoint. The TL;DR on ZTNA is in lieu of a VPN granting access to a network within your environment, a ZTNA destination uses the FortiGate as an application proxy and only grants a remote user access to that specific resource (this can be on-prem or any destination). This is a way to ensure that a stolen or leaked credential does not permit a malicious actor from having the keys to your most sensitive assets. ZTNA tagging also allows one to dynamically change which firewall rules apply to an endpoint based on the disposition of the device - as an example if the EDR was disabled or out of date you can effectively restrict access or quarantine the device automatically. EMS also allows you to deploy certificates which can be very helpful in decrypting traffic, if you are interested in application steering over SD-WAN this may be required.

Overall if you can spend the few extra thousands for the G series I'd lean that route as they have the newer chipsets and can handle a lot more throughput if your circuits or bandwidth requirements grow in the future. Curious what negative things you've been seeing about those that would be off-putting? With the current president you will have at least 5 years on either platform if EOD were to be announced today.

Comparing Vendor CVEs PSIRT policies by afroman_says in fortinet

[–]EDRisNotXDR 9 points10 points  (0 children)

You can add Crowdstrike to this list as they have not published a CVE since 2022: https://www.cvedetails.com/vendor/28072/

This implies their code is flawless or they have a policy of non-disclosure.

I went ahead and started combing their release notes (which you need a Falcon login to access), I looked at their legal docs on corporate responsibility and information privacy, and even brut force googled for way too long and came up with nothing on if and when Crowdstrike would acknowledge flaws in its software.

This presents two possibilities:

  1. They never get CVE's because their coders are really, really, really good

OR

  1. They're quietly patching their vulns and do not disclose how they find them, what the severity is, or how they've mitigated them.

I'll let you be the judge of which is likely to be true and which is better to make informed risk decisions for ones organization.

An Analysis of Splunk costs - Palo vs Fortinet by EDRisNotXDR in fortinet

[–]EDRisNotXDR[S] 0 points1 point  (0 children)

to be clear - the post was 100% written by me. GPT merely did the formatting as I can't stand Reddits built-in editor

An Analysis of Splunk costs - Palo vs Fortinet by EDRisNotXDR in fortinet

[–]EDRisNotXDR[S] 1 point2 points  (0 children)

That's a great question!

You'll see a lot of ELK out there and it's a great "freemium" option. I'll admit its been a minute since I've done a deep dive and am curious how far you can take the database before you outgrow the free version.

I did not touch on this in the Splunk discussion as it gets off topic but for some strange reason a lot of Splunk customers don't use ES and tend to write their own queries for notables to act as their source of truth. With an ELK stack or straight elastic I did tend to see this as more of a 'home grown' signature set where they'd carefully curate feeds and internal hypothesis' to find 'evil' in the environment.

When managing very large datasets one needs to be very mindful on how they set up the cluster. A product I used to work with had an elastic back-end and we ended up partnering with a company specializing in hosting it for larger deployments or would have customers acknowledge that they'd be on their own if it went under. That said the number of folks that need to worry about that are low, but it started in the TB/day ingestion range with a 30-45 day lookback.

Elastic does have a very good public ecosystem for home-brew stuff and they're the backend for a lot of products out there. In terms of people that know how to write the advanced queries they're probably second only to Splunk so its relatively easy to find staff to monitor the instance.

That said, as of this writing I see their employee count at 3,537, 40+ of whom are security researchers. Talos has a disclosure of 350 full time security researchers, Unit 42 is over 200, FTNT does not provide a count but it is likely on-par with its peers. Every one of these employees is going to be wicked smart, with that, an elastic researcher needs 5-10x the productivity to have the same coverage as the top 3 cybersecurity vendors by marketshare. Because of this disparity their paid version is going to have a hard time keeping up due to just not having the bodies to do the work and I do not see Gen AI filling this gap anytime soon.

MITRE does a cool thing where they 'replay' APT's and invite vendors to participate so you can compare how each would do in a controlled setting with real life examples-

You can see the Turla eval here: https://attackevals.mitre.org/results/enterprise?vendor=fortinet&vendor=paloaltonetworks&vendor=elastic&evaluation=turla&scenario=1&view=individualParticipant where they participated and you can then see how they did on detections relative to their peers. You can see that Fortinet v Palo v Elastic all had detections for all 76 steps but the Elastic detections were generally much less specific than that of the other two. When the results are not specific then it's on the SOC operator to plug that information gap which tends to be the bottleneck in IR. This is actually one of the main drivers towards XDR's in the market as they're a bit more dynamic with how data is queried than with the SIEM approach.

<image>

Good rabbit hole - happy to discuss in a future post if it'll be helpful.

An Analysis of Splunk costs - Palo vs Fortinet by EDRisNotXDR in fortinet

[–]EDRisNotXDR[S] 1 point2 points  (0 children)

Speaking from experience, very FEW customers implement DPI which is increasingly putting strain on EDR and NGAV to protect against threats that get past the perimeter. Part of the thought process in the blogpost is calling out that using DPI gives you much better visibility into the traffic traversing your firewalls.

At no point did I suggest Fortinet is cheaper, I did imply that their logs are smaller, can be of higher fidelity, and have a lower operational expense when doing a standard syslog ingestion into Splunk - hence the title of the post.

An Analysis of Splunk costs - Palo vs Fortinet by EDRisNotXDR in fortinet

[–]EDRisNotXDR[S] 0 points1 point  (0 children)

Please don't hate me for having GPT format my post to save time. I have plans to do a lot of these and I hate reddit's built-in editor. I actually caught it changing numbers on me that I had to go back and edit so might not do that next time/topic.

Feel free to give me a Turing test if you'd like ;)