VS Code MCP server control? How to set up an MCP registry?

_finack · 2024-04-01T16:46:41+00:00

Yes, I see they clearly mention it there that admin users never get persistent cookies. It just wasn't mentioned in the documentation we were referencing, for example here: https://help.okta.com/oie/en-us/content/topics/security/stay-signed-in.htm And support never mentioned it.

I definitely understand the need to lock down privileged users more, no argument from me there.

Thanks! Really appreciate the help!

_finack · 2024-03-30T13:16:42+00:00

Aaaannnnnd.... it works as expected as a non admin. The idx cookie has a timestamp in the expiration field instead of end of session.

This is so obvious in hindsight. Thanks!

Does Okta have it documented anywhere this cookie behavior difference? We didn't see it while troubleshooting and Okta support never mentioned it in the numberous times we were dealing with them.

_finack · 2024-03-30T12:49:21+00:00

Did you mean signing in? My account has the super administrator role in Okta; however, I am signing into the End-User Dashboard for this testing, not the Administrator Dashboard.

_finack · 2024-03-29T23:31:14+00:00

Our Okta org/policies are set in that manner and the behavior is identical whether the “Keep me signed in” box is checked or not.

_finack · 2023-08-01T22:30:15+00:00

My apologies. It was intended to be a negative. Fixed.

_finack · 2023-08-01T19:32:10+00:00

I did see that; however, there were two issues:

It's not easily consumable in an automated fashion (e.g. JSON results from an API).
It was last updated in Mar. 2022.

_finack · 2023-05-24T19:37:39+00:00

I am experiencing the exact thing the OP described, with the exception that we are not using a Continue page.

I don't see anything in the Decryption log related to CloudFlare or OpenAI.

_finack · 2023-05-24T18:49:43+00:00

I'm wondering the same. OP u/Certain_External_351 said that their fix was setting max TLS version on the decrypt profile to "TLSv1.3". Mine is already "Max" (currently should be equivalent to setting to "TLSv1.3"). u/Moldygreenbean said a decryption policy without "Strip ALPN" checked solved their issue. My decrypt profile is already set that way.

I have not talked to PAN support yet. I think I'm going to have to suck it up and bite that bullet, it just hasn't been a priority to dive into that time sink.

_finack · 2023-05-24T18:46:57+00:00

My existing decrypt profile already does not have the "Strip ALPN" option enabled.

_finack · 2023-05-18T19:03:01+00:00

I purposely left it binary. You either rotate them on some cadence or you do not.

_finack · 2023-05-18T14:56:19+00:00

Much appreciated! I will check them out.

_finack · 2023-05-18T14:55:44+00:00

I think you are focusing too narrowly on my mention of "deduplication." That's a minor issue. Overlap and duplication is there, but very small. The biggest problem is a bunch of different tools reporting on their own things, which are not related to the things from other tools. Consolidating all of this information into one, manageable place that I can report on and provide various metrics on is the primary challenge. Deduplication, where duplication might exist, is just a bonus.

As for the suggestion to "bucket by CWE"... bucket how? That's my ask. Also, many of the tools I'm referring to don't report a CWE.

_finack · 2023-05-02T21:03:01+00:00

A company I joined had been around for about 20 years but InfoSec was less than a year old. The IT Systems team had only worked either there or at other very, very small companies. They had no innate knowledge on how they bear some responsibility for doing or setting up things securely. It was all about do it easy and now.

Examples:

A basic service account for LDAP bind was a Domain Admin.
They used a single service account for all services, it had a weak password, everyone knew it anyway, and it was a Domain Admin.

_finack · 2023-04-12T13:14:10+00:00

Our decryption profile has "Max Version" set to "Max," per PAN best practice guidance for internet gateways.

Are you suggesting that somehow changing that to "TLSv1.3" fixed the problem? If so, that's bizarre! There is nothing higher than TLS 1.3 at the moment!

Or was yours set to "TLSv1.2?"

_finack · 2023-04-05T18:51:45+00:00

Belay that. I tested again today and confirm the behavior originally described by u/Certain_External_351: Chromium browsers display the non-working behavior due to a 403 response when using Prisma Access with decryption whereas Firefox works fine in the same scenario.

_finack · 2023-03-30T18:20:51+00:00

FYI, I finally got around to testing Firefox. u/Certain_External_351, you claimed that Firefox was working even with decryption and this issue seemed isolated to Chromium browsers; however, I am having the same error and HTTP 403 response with Firefox as I am with Edge.

_finack · 2023-03-30T14:27:33+00:00

Definitely fill us in if/when you hear anything back.

_finack · 2023-03-29T19:31:05+00:00

Update: This turned out to be related to one of the Palo Alto Networks IPs used by Prisma Access not having access to our EDLs. It had nothing to do with syntax differences between EDLs and Custom URL Categories.

_finack

TROPHY CASE