Talk:Logical Security Zone Pattern

From The Secure Arc Wiki

Jump to: navigation, search

Traffic originating from the internally controlled zone, (staff intranet), should not be allowed to go directly to an uncontrolled zone, as the diagrams ZoneModel.png & PhysicalSecurityZoneModel.png (dated 25th Jan) suggest. This also applies to traffic originating from the Uncontrolled zone, destined for the internally controlled zone. All the above mentioned traffic must go via the controlled zone. Traffic destined for the secured zone must go via a restricted zone. The two diagrams need to show a flow into the restricted zone, from the internally controlled zone. Michael

Contents

Agreed...

I have updated the diagram, but I'm yet to upload it. Will be up soon...

Tristan Austin

Chat Session Transcript regarding Internally Controlled (Internal DMZ)

Tristan Austin 5:44
can you take a look at the zone model page
Logical_Security_Zone_Pattern#Collaboration
I'm just wondering whether I should remove all the little arrows from the main diagram and just refer to the Collaboration rules instead
just to clean it up


Michael James 8:14
Yes, you could remove the arrow, and use them in the collaboration rules instead. What's missing currently is an arrow between the internally controlled zone and the restricted zone.


Tristan Austin 8:14
there shouldn't be one of those
staff intranet access having direct connections to an application server?


Michael James 8:16
no, but it may be an internal app, which accesses data in the secured zone. Such as a payroll system..


Tristan Austin 8:16
then it should be proxied
that flow was never in any of the versions of the zone model i've seen before


Michael James 8:18
Realistically, where is the presentation tier going to be for an app in the internal network?


Tristan Austin 8:18
internal dmz


Michael James 8:18
I would say inside the internally controlled zone, along with a lot of other stuff.


Tristan Austin 8:18
i disagree


Michael James 8:18
Not ideally obviously.


Tristan Austin 8:19
we shouldn't be promoting an insecure model
putting anything in the staff intranet is relatively akin to putting it on the internet
if we're laying out a model that will result in a secure system if you drop things in the right boxes, we shouldn't allow something like that


Tristan Austin 8:25
here's a few more thoughts...


Michael James 8:25
then we need to be more specific about what other controls are in place in the controlled zone if it to contain systems which proxy internal apps and external apps. (if an app is exposed by a proxy in the controlled zone, it is going through infrastructure that is slightly less trusted than the internally controlled zone, therefore a compromise of some of that infrastructure (a DMZ is often seen as sacrificial), may introduce a larger threat to that application. By the modelling tool, we may infer a controlled zone, but in actuality it may require physically separate infrastructure..


Tristan Austin 8:25
ok let me read...


Michael James 8:25
sorry for the long message.
I'll put it another way....
Why would you have sensitive data traversing a proxy in a controlled zone, when you want to limit the path of that data to as deep as possible within the organisation. One solution to this is to place (for internal apps only) a proxy inside the restricted zone, alongside an application. There would be no direct access to the application from the internally controlled zone.


Tristan Austin 8:30
i don't agree with that, but i think i know a solution
We should add another box that is the equivalent of the Internet, but is the Staff Intranet. The Internally Controlled Zone would be the equivalent of an Internal DMZ.
Equivalent of the relationship between the Uncontrolled, Controlled and Restricted
But separate infrastructure and only for access from the Staff Intranet


Michael James 8:31
Can you please do a diagram of it?


Tristan Austin 8:31
yep give me a few minutes


Michael James 8:32
np Actually i'm glad you disagree with me. It's a no compomise solution, and it aknowledges that there are greater internal threats than external.


Tristan Austin 8:37
yea, I was going to copy and paste this...

An area of confusion with this model is always the Internally Controlled Zone. This maps one-to-one with the staff intranet. Physically, it often hangs off the back of the Secured Zone. Logically, it is only slightly more trusted than the internet.

Within the Global State of Information Security report for 2007, the following statement is made:

This year (2007) marks the first time “employees” beat out “hackers” as the most likely source of a security incident.

Many organisations consider the staff intranet to be sufficiently secured, but when you consider contractors, laptops moved between home and work, iPods and other mp3 players potentially infected with viruses plugged into work PCs and staff turnover, the chances of some form of compromise are very high. A google search for "disgruntled employee" network security returns around 10,000 results. Including some particularly serious scenarios.
this is from Logical_Security_Zone_Pattern#Level_of_Trust


Michael James 8:37
Yes, i saw it.


Tristan Austin 8:37
hang on, let me send the diagram first...
ok, it's in the mail
what i was going to say before was if the staff intranet desktop applications have direct access to a payroll system in the restricted tier, then so does all of the viruses and disgruntled employees
I think it was the slammer virus that went through the [Client 1] a few years ago and took down all internet access into and out of the bank
some developers had firewalls opened up to the production SQL Server database
boom


Michael James 8:40
i remember it.



Michael James 8:40
ouch


Tristan Austin 8:40
has that diagram arrived yet?


Michael James 8:40

downloading mail now
looking..
i see, but that's an awful lot of steps to get to the data. 3270 apps? Do we ignore those?


Tristan Austin 8:43
eh?


Michael James 8:44
3270 apps generally run a tcp client on the desktop directly to the mainframe. Based on where most people are putting them strategically, it's in the secured zone. Not [Client 1], i know..


Tristan Austin 8:44
ok, here's my view on that scenario
they put those into the model
a flow from Internal Uncontrolled directly to Secured Zone and they get a big fat red risk show up saying, "Main Frame at huge risk with this design"
even at [Client 2] i've put in flows that violate the rules, but there are infrastructure and budget constraints that say they have to be that way
they go in, but get highlighted as a risk


Michael James 8:46
ok, fair enough.
This diagram is ok, although my assumption previously was that from left of the controlled zone was 'external' to an organisation. (boundary). Having the Internally Uncontrolled zone out there looks a bit wrong,


Tristan Austin 8:49
yea, it did use to be that way, but the key thing is that left to right is level of trust, not physical location
making a small change...


Michael James 8:50
Yeah, but in this case, the internal network is trusted just as much as a business partner's network/ apps.


Tristan Austin 8:50
that's the small change i just made
let me just run a few other questions by you before i send this again
flows between Controlled and Internally Controlled
one way?


Michael James 8:54
No, what about email incoming?


Tristan Austin 8:54
yea i think the Uncontrolled to Internally Controlled should be bi-directional


Michael James 8:55
Or B2B apps, where a async app has a delayed response from a business partner.


Tristan Austin 8:55
the business partner has two types


Michael James 8:55
actually that one would go to the restricted zone anyway..


Tristan Austin 8:55
it shouldn't
externally controlled can have partner organisation users accessing internal apps
that could either go directly to the Internally Controlled Zone, or go via the Controlled Zone
such as outsourced HelpDesk
which [Client 2] has


Michael James 8:56
back to your comment about Uncontrolled to Internally controlled.... There shouldn't be any direct flow between these two. All through the Controlled, in and out.


Tristan Austin 8:57
ok, i agree with that
that solves my other question about partner helpdesk people


Michael James 8:58
For third party helpdesk, there might be a Terminal Server in the controlled zone, through which they authenticate and use various tools to manage internal systems. All audited of course.


Tristan Austin 8:58
concrete example of that


Michael James 8:58
Does that align with what you've seen?


Tristan Austin 8:59
At [Client 2] we had a HelpDesk app defined in a separate StovePipe that was only accessible from the Staff Intranet, but also accessible from 3rd Party apps
I hadn't defined an internal DMZ like this
but there was a VPN link terminated in the Controlled Zone, which now would be in the Internally Controlled zone
basically what they do is effectively give them access to the staff intranet
but it still goes through a DMZ
let me send you the updated version...


Michael James 9:02
The VPN should be terminated in the controlled zone.


Tristan Austin 9:02
problem is that they need access to web app (even if it's just WebSeal) in the Internally Controlled zone, which should only be accessible from the Internally Uncontrolled zone
wait
i've got a better one...
hee hee
the first one I accidentally sent just to myself


Michael James 9:05
no wonder i can't see it.


Tristan Austin 9:05
ok, it's in the ether
oh crap, imagine the blue box is bigger too


Michael James 9:05
ok
looking...
If you have email / internet services for internal staff residing in the controlled zone, the Internally Uncontrolled zone would need to the Controlled zone as well. (needs arrow)


Tristan Austin 9:10
I figured that was an extra hop through the Internally Controlled zone


Michael James 9:12
I think that stuff would end up being a stove pipe in the controlled zone and we could get rid of the Internally Controlled zone. I need to get visio to put some ideas together..


Tristan Austin 9:13
i think the last three places i've worked at have been planning on putting in an internal DMZ, which is what the Internally Controlled zone is
in this new diagram
I'm not clear on the Stove Pipe idea


Michael James 9:14
Yes, but in this diagram, the Internally Controlled zone we had before has been re labelled as 'Internally Uncontrolled'.


Tristan Austin 9:14
Stove Pipes go across those three tiers
yep


Michael James 9:15
hey, there are fireworks outside...
We need to split this diagram up at some point, with specific examples. This might actually make it clearer to put the whole together..


Tristan Austin 9:17
Examples would help
I'm gonna run out and see if I can find something to eat


Michael James 9:18
yep, np
i have to get some dinner too shortly.


Tristan Austin 9:19
will talk later
i'll put this discussion up on the wiki later
company names removed, of course


Michael James 9:23
ok. Could you please send me the visio file? I'll try out a couple of variations.
9:46You have disconnected
9:48You have connected


Tristan Austin 9:56
visio?
hee hee


Tristan Austin 05:52, 26 January 2008 (CST)

Color scheme

Just playing with the color scheme, putting it up for consideration.

Michael James 12:16
I think i prefer solid colours in the zones.

Tristan Austin 12:16
yea, i just made a quick change to see what that looks like too
with those colors from the 'Level of Trust' triangle at the bottom
12:16 i'll put that up too...

Closure of Internal DMZ in the Zone Model discussion

Tristan Austin 12:34
have you had any more thoughts on that discussion ( http://www.securearc.com.au/wiki/index.php/Talk:Logical_Security_Zone_Pattern ) we had about the zones?


Michael James 12:34
Yes, i have.


Tristan Austin 12:34
Craig Pearce has sent me his slidepack for his lectures and wants some feedback
he's included the zone model currently published
what are your thoughts?


Michael James 12:36
I think the original (as published) version is the better one.  I struggle with breaking up the Internal network any further.
What i have trouble with is actually what people put in their networks now (as in the internally controlled).  You will often see presentation, business and data tiers, all in the internally controlled zone.


Tristan Austin 12:37
yea but that's very very bad


Michael James 12:38
of course.  What we have to do is align the asset classification with the zone model (which is what we're doing anyway).  The harder task is to reshape people's mindsets around actually implementing it this way.


Tristan Austin 12:39
i'm not really following, how is the information asset classification related to whether we explicitly call out an internal DMZ in the zone model or not?


Michael James 12:41
If an information asset is worth very little to an organisation, what is stopping them from a risk perspective, deploying every component of an app in one zone?


Tristan Austin 12:41
only the risk management team performing a risk assessment and signing off on it


Michael James 12:42
At a certain point, as asset's value will dictate (with the security guidelines) that the app should be deployed in a certain way..


Tristan Austin 12:42
but they won't know it's a risk unless they can put it in the model and see that they're not following the security guidelines


Michael James 12:43
i see where you're coming from.


Tristan Austin 12:43
the alternative is to say, "let's not put in the security guidelines to allow for scenarios where the risk is so low those security guidelines wouldn't have applied"


Michael James 12:44
This is just a mindset i need to get used to.


Tristan Austin 12:44
ok, let me give you a scenario
We build this tool and take it into an organisation where they have presentation, business and data tiers, all in the internally controlled zone.
Without even building a new system, they put their current system into the model
They get big red audit flags raised because they've got nodes that shouldn't be in the internally controlled zone deployed there
Without even starting a new project or changing anything, they're shown the error of their ways
That was one of the things Richard was talking about in regard to value of the product of just doing audits


Michael James 12:47
ok, so the approach is to treat all assets the same in one respect and show indicators where the implementation is Very Bad, instead of 'Just a bit crap'.
This actually makes it a bit easier for the risk mgmt team.


Tristan Austin 12:48
I don't think I'm saying we should treat all assets the same
yea it does
Part of the Node and Flow stuff that I'm doing right now for the ref arc is tagging the Nodes and Flows with the Information Assets that pass through or are stored on them
Pretty much all information assets always end up in the Uncontrolled and Internally Controlled zones via the browser
but it's transient
and to get into the data stores where those things are held, you have to get through multiple levels of security


Michael James 12:50
ok


Tristan Austin 12:50
what I'm thinking is that we should indicate what information assets are transient and what are persistently stored on each node
if you identify a node as having a sensitive information asset persistently stored on it, it should be deep in the zone model


Michael James 12:51
yes, i agree.  And if it's transient, how long is it transient?


Tristan Austin 12:51
well in reality nothing is transient
i raised a point with some of the PCI guys at [client 2] about credit card data being in memory and implicitly stored on disk in virtual memory
which invokes the PCI compliance stuff about storage


Michael James 12:52
There's a big difference between milliseconds and many hours (in the case of session cookies)


Tristan Austin 12:52
true
but even the consumer Mac OS X operating system has an option to encrypt its swap space for this very reason
we're going down a bit of a tangent here


Michael James 12:53
yeah


Tristan Austin 12:53
i think 'transient' should simply include the potential short term storage of data in physical memory and on disk in virtual memory


Michael James 12:54
yep,ok


Tristan Austin 12:54
ok, so in summary. I'll update the wiki to have the internal DMZ version of the zone model and I'll update the Node & Flows table to include a distinction between transient and persistently stored Information Assets


Michael James 12:55
sounds good


Tristan Austin 12:55
oh, and we'll need a table of some sort to map persistently stored information asset classifications to where it should be deployed in the zone model


Michael James 12:56
I can do that.


Tristan Austin 12:56
cool
one last question on a kind of semi-related topic
The colors of the zones
I think we kind of agreed that hand picked colors for each zone that look good and convey and increasing level of trust is better than the gradient approach I had a play with
um, and the question itself is, do you concur?


Michael James 12:59
definitely.  Solid colours are better.


Tristan Austin 1:00
ok, cool.
we've closed out all those open discussion points then
I'll publish this in the discussion page like last time


Michael James 1:00
ok

Personal tools