Perimeterless Security

[zencoder]

At the suggestion of another member, I'd like to take up the reins of a new thread to discuss the ideas of information security without boundaries, or perimeterless security as she put it. Wireless networking will certainly play a big role in this, but I think it goes beyond the subject of Wifi and unprotected access points.

This is actually a subject I read about briefly long ago in a magazine article, and it's a concept I've been percolating for some time. With standards like 802.1x becoming reasonably priced and usable (to a limited extent) with modern technology, we can achieve a fair degree of logical security. But networking and security have always been based on a physical model.

Implicit trust has always been an achilles heel; look at the rsh family of applications. Authentication (and subsequently identity management, but that's probably another discussion) is a key part of this issue, and is often considered a silver bullet for security solutions by the uninformed.

Let's break it down with the triple A system:
Authentication
- Are all resources (not *just* the users) what they really appear to be, or claim they are?
Authorization
- Are you able to access *only* resources you have been granted permissions to? Are others denied that should not be, or exposed when they should be concealed?
Audit - also known as - Accounting or Accountability
- Are all activities documented and logged, in a protected fashion to avoid tampering?

Ok, I've started the conversation. Let's carry it forward. Consider Xierox' original dilemma. How do these three points apply, and why or why not?

C'mon, I love the sound of my own voice..., er...typing, but this isn't a tutorial (or it would be in that forum.) Sound off.

[MrLinus]

This specific idea of "perimeter-less security" was brought up at the Transcend's Security and Privacy Symposium 2005 that I attended on the 1st. It was brought up by Barbara Nelson, CEO of Neoscale Systems (in relation to Enterpise Storage Security) and specifically in regards to those that use VPNs but don't secure the home machines used by the VPN users. Given the issue of Bank of America (and the stolen tapes) thinking of security in regards to just what you are "protecting" isn't suffice.

In fact, one of the figures brought up by David Perry, Exec VP of TrendMicro, was a rather scary one. Two biggest security offenders (vis-a-vis worms and such)? CEO. No surprise there. I don't expect the CEO to have clues on this stuff. He's a poster boy/PR type. I expect him to look and sound pretty. The admin is supposed to know all this "techno babble".

The 2nd offender? The Security Guru. Now that shocked me. But I suspect I understand somewhat of why. Security geeks will get complacient and will security up the wazoo at work but forget about home. Or, they won't fight for the security. "What's the point?". Perhaps there is another reason all together (just sick of dealing with security all day long). Who knows. But security cannot end at the firewall anymore. It just isn't sufficient in today's day and age. Imagine if you were the security geek at ChoicePoint or Bank of America and it was your responsibility to deal with those two things. Hindsight is certainly 20/20 but I'm sure none of us would want to be in that position. It's one of those "never though it would happened" (similar statement made before the 9/11 attacks occurred but that's another kettle of fish altogether).

That said, the concept of AAA certainly helps us determine what would fall "in" our perimeter-less pervue and what wouldn't. In the example of the thread mentioned I'd address these things:

Authentication: one of the big things about Authentication is that we know who is allowed and who isn't allowed into the network. It allows us to identify access controls and various levels of controls. A "rogue" AP means anyone ("guest" is one of those no-no accounts) can connect to the network. Well, that might not be an issue ... unless that rogue AP is also connected to a machine that in turn is connected to xierox's network. Now the machine connected may be authenticated and valid but ends up being a "proxy", if you will, for someone/something that isn't.

Ok. Authentication is potentially violated then.

Authorization: since Authentication may be violated, Authorization will soon follow. Again, the same "proxy" issue may be used to by-pass appropriate security. Since I (or xierox in this case) don't know who is on the network (can't verify them since they didn't authenticate), they may get access to various resources.

Now, one way to deal with this would be to ensure a separate (albeit annoying process) login for each resource and limit what students/staff can do remotely. I know even if I log on remotely to our school's network, each resource I attempt to access -- from remote only -- requires that I have to log on each time.

Accountability/Auditing: Slug time. There should *ALWAYS* be a trail. It's kinda hard to follow "guest" around however. You might be able to trace it to the rogue AP but if the rogue AP was shut done or controlled better, then this wouldn't be as much of an issue.

The biggest concern, IMO, with the rogue AP is that it can become an avenue for a covert channel. Basically, it can become a method by which to by-pass any controls put in place. By dealing with it, in a polite and professional manner, it becomes a win-win for all. Since it appears that the rogue AP may not be on the campus, the person running it may benefit from learning some security and avoiding potential "eager students" from violating his privacy (intentionally or otherwise). And it would mean additionally security for the school since a potential by-pass to internet (and any nasties that might come down that router undetected) would be shutdown or controlled more.

There might even be an additional win: good PR for the school to show they care about the community and those around them.

These are my thoughts thus far. I'll probably add more later..

[zencoder]

The article I read way back was about a firm that had a large percentage of mobile users. Salesforce...it may have been a pharmacueticle company. Anyway, essentially, none of the mobile users had any direct network permissions. No matter what their physical location, they were 'tunneling' to the network through a gateway for any and all services. That's a pretty smart idea. Not the most efficient, and certainly not cheap, but it does the trick. Microsoft has a nifty 'application' to address this, Network Access Protection, or NAP. Now this link says it will be built into Longhorn, so don't hold your breath...but according to my source (MS dweeb at the office), it will be available for Srv2003 in the next few months. *shrug*
So with MsM's points above about the CEO and some clod of an IS admin who doesn't lock down their home system...what about all the other new points of access we've given our users? Blackberrys, bluetooth enabled phones/pdas/watches/toasters, b2b VoIP technology, Vonage in everyones home...

[RoadClosed]

I'll bite, the term peremiterless security is misleading. It makes one think of a Keep WITHOUT a wall around it, or a gate to control access to the outer couryard or a moat to hold back attackers at the wall. Who would think of it that way? But I agree, a carefully placed assassin will not need to penatrate the perimeter.

As a stonemason (the figrative character who designed castle defenses) evolving over the years I have been frustrated with the lag in security principles and implementation. 2 years ago firewalls were the hot deal, now they have been mostly implemented with no one to watch over them. For the last 2 years my security stategy focuses on accountability, authentication and audit. It doesn't remove the perimet, it removes the thinking and venture beyond it. For instance, I hold the keys to the kingdom, I am the assassin. So using the stategy mentioned I began to build an infrasturcture policy based on those factors, in fact those ideas trickled down to me through US government guidlines.

I guess I am saying, I agree with the principle and it makes a great template to develop and most importantly segregate security. That is hard for us. But for those charged with the REAL protection of assets, it is critical. No one wants someone looking over their shoulder. An audit trail is just not keeping a log, it's someone ELSE outside of a team reviewing their contents. And in turn, they reviewing you.

[zencoder]

I see what you mean, "perimeter-less security" could be confusing or misleading, I suppose. But I still feel strongly that it really describes what I consider to be (or at least what I think SHOULD be) our goal with infosec.

The perimeter is only a small piece of the picture. It's certainly essential, and very important...but no more important than the wheels are to an automobile. Without them, you don't get anywhere, but when you consider the physics of a high-power internal combustion engine, the engineering in an automatic transmission, and the various electrical safety and control systems in a modern car, the wheels play a small part.

Security is NOT about the perimeter per se. A regular response to suggestions, reccomendations, and directives has always been "yeah, but it's inside our network, so it's not critical." Everyone has firewalls these days, but how many are properly managed, and have logs that are actually monitored on a daily basis? A huge percentage of the firewalls in place didn't do anything to stop Slammer.

I think we need to fundamentally shift awareness, perspective, and PRACTICE from being perimeter based prevention and internal detection and reaction, to an enforced model. Really, our current technologies are mostly based on an Open model. i think we should consider moving towards a closed one, from a security perspective. Is IPv6 one of the answers? Perhaps. 802.1x is another one, really; however, most of these answers are really bandaids to a system that in one perspective 'fails open', although 'fail' may not be the most appropriate term.

This is probably a utopian vision though, and I highly doubt we'll ever see widespread adoption or use of a system as rigidly secure as this. Users won't put up with it and managers won't want to pay for it, so at least those of us that do this professionally will still have jobs.

[RoadClosed]

We see eye to eye. With a tiny difference. In fact, like mentioned my entire operation is based on the princilples detailed. It has to be, I don't see another option. Although I don't see how shifting security as a closed model is better than an open model. That "closed" concept, in my line of thinking, is the very essence of perimeter based thinking. But those are just my interpretations of open versus closed.

You can't get past the fact that there is a perimeter. Anything outside the confines of electronic or facility structures is open. What is critical however is shifting thought or planning processes to consider the perimeter as an intangeable object. That is the bridge you mentioned by shifting from a physical based model. I totally agree, one would accomplish that through authentication systems and procedures as one entity regardless of it's deliniating factors. Then building mechanisms separate from the other entities, such as Audit or Authorization. And applying them to all systems thru out. In this line, there "is no spoon" or there is no perimeter. Even though it definitely exists and must be taken into context BUT planning the perimeter is just a TINY instanciated object of security. For example:

I would call this a "closed"scenario - Company A has a website connected to a protected database. They hire a guy to come in build a firewall, lockdown the server, and connect a secure tunnel to the database. For one they don't even consider database security and they probably have one guy doing the confuguration, testing and logging function. of the perimeter who doesn't have a clue who maintains the database. Since he built the tunnel he probably has full access anyway. Through a very focused look at the perimeter and the perimeter only, the really vulnerable data lies unprotected and unmonitored!

On the surface this seems obvious and aparent, but that's not the case in reality. Really, the perimeter it's very small when you think about it and companies do focus primarily on the perimeter or even worse, the data center. But I'll call that "perimeter based" since it is the same concept. only this perimeter is within the company boundary. Just because you are a member of an authorizing function, it doesn't have to mean you are a member of the audit or authentication process, consider that a risk as well.

Using this method it is also very hard to miss pieces because you aren't thinking of a single device, you are thinking of processes that perform the function over mutliple devices. It's the "way" to go.

[Tiger Shark]

I've been dying to get to this thread, read it and comment since it's inception.... Time is a horrible thing....

Great discussion.... My thoughts...

Perimeter: These days the forces of business tell your more advanced users that they can do this, that and the other from anywhere and technically they _should_ be able to. But what effect does this have on the perimeter? If you embrace the concepts they propose then the perimeter becomes a fluid object that ever changes - today it is their home computer, tomorrow their laptop from the convention or the hotel room all the while having their Blackberry transmitting potentially "secret" information all over the place. Politically, you have _some_ control over the fluidity of the perimeter by allowing certain access to only certain apps but, as we all know, your political "clout" may not be as grand as you would wish.

Authentication: Real authentication falls down the moment the assest being used leaves your Hard Perimeter, (as defined by your corporate network). Once the asset is outside the hard perimeter you no longer have physical control over the asset. With the loss of physical control true authentication without excessive expenditure is difficult/impossible. Once authentication breaks down Authorization is pretty much useless since authorization is a direct product of authentication.

Accountability: I've said it a million times - but I'll say it again - Log it, log it then log it again.... It's your _only_ way of being able to trace what _might_ have happened. Without logs you are totally blind, with limited logs you are totally to partially blind. I'm not talking about complete packet dumps of everything that passes in and out of your network but let's log everything we can - _especially_ where the perimeter becomes fluid. We keep talking in terms of the "information age".... Logs files are information - regardless of how big they may be and how hard they are to comprehend, they are information that may be vital... You can always hire someone who knows what they mean to help you understand them if necessary..... If you don't have the information then you have nothing..... Account for every transaction you can, inbound and out... Where the transaction is part of the "fluid" perimeter then log it to a point where you can see what is going on as best you can and store that information for a long period - not all "Hacks" take seconds or even minutes to happen....

So how can we provide a fluid perimeter while still providing a relatively secure environment? Tough question... The more the perimeter "breaks down" the harder it gets. In many ways it boils down to two things:-

1. Policy: Enforce what you can on the "perimeterless" user. Make them use firewalls, AV, automatic updates, specific logins to the local computer that is the login that allows them to make the VPN connection etc. Have them sign for the fact that when their computer is attached to the corporate network it becomes part of the network and therefore is subject to the same scrutiny a "perimetered" workstation would be - including scanning, remote connection etc. Do it to them occe and show them the screens they were looking at... It shows them that the policy is real and it shows them that others _could_ be doing similar.... From time to time challenge the user - ask them "did you connect to the VPN at 7:46pm yesterday"? Show them that you know everything they do... Most users have a pattern of work from the remote location... They tend to stick to it.... So you can see the deviations... but the simple fact that you are watching them makes them think more about what they do and how tey manage that resource.... It becomes "Important" to them too...

2. Restriction of Access. If you are making them VPN before they can Terminal Services to a local "desktop" make the logins different... then restrict their network use to only their own files or a subset of them. Inside the "hard" perimeter make them understand that their access is "unfettered", (whether it is or not), but that from a remote location they will have certain restrictions placed upon them. Most accept this readily.... there's a few that don't... This becomes an administrative issue... Deal with it with their supervisor if you can. If not then you have to restrict them in any way you can and make excuses....

"Permiterless" is not a valid concept with current authentication technology. Thus Authorization fails too..... Your perimeter may be the simple restriction of access to _any_ resource, or limited access to a few. But since Authentication fails the moment the resource leaves the "hard" perimeter all else except Accountability fails too.... and accountability isn't perfect in most situations...

It's all going to revolve around a truly secure authentication system.... I have yet to see one publicly available yet.... And I would question the "private" ones when the asset is outside the hard perimeter.

[foxyloxley]

C'mon, I love the sound of my own voice..., er...typing, but this isn't a tutorial(or it would be in that forum.) Sound off.

Well, maybe it SHOULD become a tutorial

[xierox]

Originally posted here by foxyloxley
Well, maybe it SHOULD become a tutorial

I second that. (Maybe then I'd know what the heck you're all talking about. )

[zencoder]

xierox, I'll attempt to enlighten you a bit. A lot of this discussion uses conceppts used in the engineering or architecture framework of discussions.

Some of the points that have been made are really discussing the concepts of security and (at least I have been) suggesting that we re-examine those concepts and how we apply them.

Take Authentication for example; most people think username/password, or maybe a token to give users a one-time-password. But authentication is a broader subject, and should be applied in a broader sense. This subject is more readily accepted these days because of the rise of Phishing. Phishing attacks are a perfect example; they are a form of social engineering, but they are also based of false or failed Authenication, but authentication of an asset, not a person.

I suppose one of the points of this thread is to talk about security beyond the current methods and models. But then, it's late, and I am severely lacking in caffeine and/or ale, so I could just be full of it.