About Brandon_Wertz

@JasonFerris wrote: Hi Brandon, Example: traffic from source1 to say internet with specific app IDs like ms-update etc. What I'm after I guess is that when adding apps to the rule you see the depends on - ssl, websocket. But if you don't go and add those to the existing rule its possible that traffic or some of the traffic won't hit that rule for ssl or websocket correct? Hitting a more general rule afterwards or a deny all rule.  To make sure that ms-update application traffic works as expected "should" ssl and websocket be applied to that rule? I'm trying to be granular in our rules so only necessary traffic is allowed.  @JasonFerris -- let me clarify what I meant.  To account for the "depends-on" like you mentioned.  You have 3 options, but really only 2.  The 2 I previously mentioned.    1.  You can create a general rule that allows the "you should probably allow these applications so web pages can work" rule.  These would be App-IDs like web-browsing, stun, websocket, SSL...et al.  2. Or they could be only included in the specific rules associated to their "depends-on" App-ID.   Option 3 is the one you just mentioned is "do nothing with it" let it hit a default deny rule and hope for the best.  In some instances not allowing the depends-on App-ID  won't really impact the core App-IDs functionality.  That particular app may generally be ok with some one-off scenarios where the traffic behaves weird for the user with things not working right.  There are other App-IDs where not allowing the depends-on App-ID will me the primary application just won't work. ... View more

@OtakarKlier wrote: Hello @Brandon_Wertz , Would love to hear your thoughts on why and how to improve the design. Regards, @OtakarKlier -- I guess the title of the thread, to me, is mistitled.  It should be "A Zero-Trust Strategy incorporating Prisma xxxxxxx"  For me, given that we're starting off on the wrong foot you're not going to achieve the outcome you're looking for.   My interpretation of ZTNA's intention is to really segment and isolate the enterprise as a whole, while creating specific granularized (authorized) access consistently throughout your enterprise no matter where you are both logically and physically.  You want to create a consistent user experience that no matter where the user is, the user accesses resources the same way and the support and oversight of the technical components are consistent for the IT and SecOps support teams.     ZTNA, is the realization that cyber exploitation / compromise in a legacy network design is a foregone conclusion and networks/applications need to mirror to a degree the controls that exist in more secured networks like PCI or the military.   The above stated, if someone is going to leverage Prisma Access Mobile Users (VPN) that's one external component, are there others?  Is there a VDI solution?  What's that OEM?  What controls exist there?  What does access from the internal network look like?  What visibility is there?  What controls exist?  Are they the same as when a mobile user?  If as MU you're super locked down with great visibility, but internally you're wide open, with little control and near zero visibility with visibility just on what's happening externally then that's not really a ZTNA paradigm.  At all layers of your network you should have consistent application and use and user based controls, business application based access restrictions as well as some level of network access control (NAC) employment.   To do this you're going to want components that integrate with each other sharing data, visibility and functionality (if possible.)  A single pane of glass into your entire enterprise.  So if you block or allow something that action should  be executed in one location (view) with the action happening in maybe 4+ separate network segments/layers. ... View more

I would agree with @BPry  on implementation/timeline.  I don't know what your network looks like now, but depending on your organization and how large it is it might take 6 months to a year or longer just to get everyone into Prisma Access (RN/MU/PAB.)  This in itself will probably be a big lift, then adding other features like user (Authentication / Authorization) as well as going down the path of roles & locking down application access and network segmentation ZTNA will be a 3-7 year journey.   Like was mentioned before don't try to do too much too quickly, but your first step should be visibility.  The the steps that are least intrusive, but give the most visibility or ability to apply control. ... View more

@D.Maas -- You can start with DoD or NIST publications, but I think anything you get from someone here or another company is the wrong approach.  ZTNA is this overarching policy or process, but what that looks like to a particular organization will probably be different.   I think, if you were to take the original precepts of what ZTNA was and try to use Prisma Access Mobile Users (MU) or Remote Network (RN) and say that's a part of your ZTNA strategy you're already starting off incorrectly.  I think a Zscaler type model, if you can start out with it, makes it easier to follow a "ZTNA strategy."    The concept of ZTNA has evolved though, and so have the components of what "Prisma Access" is, now especially with Palo's acquisition of Talon and folding that into Prisma Access to become Prisma Access Browser.  I think as long as your organization is consistent and has answers to implement features to address the concepts of the various ZTNA pillars that's really what you should be building.     ... View more