Perimeterless Security

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.

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..

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...

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.

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. ;)

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.

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.

Quote:

---

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 :cool:

Quote:

---

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

---

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

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. ;)

That helps some! I think I'm starting to understand. Thanks!

- Xierox

Tiger, giving up on the "ever hated raiders". That's what we refer to them in Shanahan Land...

You are looking at it from a literal sense. For example of course you log your devices. I am doing a poor job of explaining the concept. Where as you design an authentication system that is built across the board and evey device follows that policy. It's not general but very concise. It adresses the perimeter as only one aspect of security. You are in charge of the perimeter. But what about beyond the perimeter? Deeper inside your network into the core? There is authentication and accountability there as well and EQUAL in importance. Who audits your work on a regular basis? In my understanding of this mechanism, you looking at your own work does not constitute an Audit. You administering access, controlling authentication and looking at the logs does not take into account the principles. And I am telling you now the GOV is on to this. wink wink- trust me If you are like me, no one looks over your shoulder or even has a clue what you do all day. :) It makes sense to me from a policy and management umbrella at a high level, to shift security from a compartmentalized mechanism to one based on role versus location and proximity. And provide some oversight. It is true the perimerter is the first line of authentication. But as you move past the gateway and move deeper into the core you find many others. The perimeter is merely a draw bridge across the boundary but it has, in tradition been the only focus. Or if not the only focus the most watched. Shifting from a different perspective does not make it any less important but it does raise the level of other vulerabilities. If you want to think in terms of a perimeter then consider shifting the perimeter deeper inside. But I agree the wording "perimeterless" isn't appropriate.

Take this line of thinking. The perimeter never breaks down. And that's where concepts we are proposing step in. The perimeter doesn't have to be fluid, you present it based on your assets. If a laptop is roaming in china the perimeter is useless or becomes authentication mechanisms on his laptop (a cert maybe) and you're never changing VPN gateway, which also has an authentication mechanism that matches the one contained on the lap top. Once authentication is established (note we haven't even established a password check) then we check to see if the authenticated laptop is authorized access to the mail server. Then once given access, authentication is checked again. This is over simplified I know. But all this has only taken place in the perimeter. So we tend to focus ourselves in a perimeter paradigm. Perhaps in one case, all functions exist in the perimeter. But then again if that is the case it isn't really a perimeter. It's the core? Or course it's impossible to secure laptops roaming the planet with monkeys behind the keyboard. That's why I have successfully managed to stop it's ugly head each time it breathes fire. If I did turn it on, I would have to have multiple perimeters and zones of authentication, accountability, and authorization.

Authorization and authentication are very different. :) But they are all direct products, even accountability. They don't even use the same mechanism in many cases. And once again, buzz words in the GOV. For once I actually see their point of view. Out of time but if the discussion contiues I have some anologies...

LOL... Shanahanland.... "Squinty eyed little rat bastard" is what we call him here in Tigersharkland.... Hate the little deviant and one of the most pleasurable things in my life is seeing his bright red face with his funny eye going ballistic when the Raiders beat the Broncos :D.

OK.... Here's the way I see/define the process/concepts with or without a well defined perimeter:-

Either the user, the computer or both provide authentication information to the systems authentication mechanism. The authentication mechanism accepts or rejects the authentication but for this discussion let's assume that the authentication is accepted. Subsequent requests for services/data are then arbitrated through the authorization mechanism with reference back to the authentication. Outside _both_ those concepts is that of accountability which should be a separate and independently managed system though, as we both know, it is all usually managed by us poor saps because there "isn't the money in the budget" for x, y or z that we propose....

If all three systems function _perfectly_ then there is no real reason for a perimeter at all. The system as a whole would be aware that the computer and the user on the far end are who they say they are and thus the authorization would go as planned and just to prove it the accountability would document how smoothly everything is running ;).

I consider my perimeter to be fixed if all my assets remain within my "hard" perimeter, (the corporate network), where I have full control, I can see all traffic to and from the boxes and I can walk into the office and ask for an ID if I need to. I consider my perimeter to become "expanded" when assets leave the hard perimeter and then return. During it's period of absence I have no control or knowledge of who touches it, what it gets connected to or what traffic goes in and out. It doesn't have to have any access to my network in it's absence - the absence
itself "expands" my perimeter in that I need to try to protect the asset while I can't control it, (firewall, good authentication, IP Filtering etc.), in the hope that when it returns to the hard perimeter it does so in the same state it left in, (Think of it as a "satellite" perimeter, not joined to mine but a small ring around he asset). My perimeter becomes "fluid" when those assets both leave my control and then are expected to connect into the the system from the big wide world. That's when I require my perimeter to extend around the asset, (think of an amoeba). The difference between the extended and fluid perimeter is that I can intercept the asset from the extended perimeter and check it before allowing it back inside the hard perimeter. I can't do that with the asset in the fluid perimeter wothout vast expenditure.

So, _my "definitions" aside, (and feel free to correct me if I'm missing something here), what is the single point of failure in the model however the implementation manifests itself?

Quite simply put, the single point of failure is the authentication phase in _any_ scenario. Once authentication has completed the authorization is automatic. Who/whatever completed the authentication correctly is now automatically granted access to whatever the authorization process is told to. In some ways the process of authentication/authorization are a single process even though they may be carried out by utterly different systems and mechanisms. The accountability process will ring no "alarm bells" if the authenticated user only attempts to access items that the authorization process allows it to. In other words, once I beat the authorization system I have access to all the assets the authorization system allows and as long as I don't try to exceed the permissions of the "intended" user. That "intended" user could be the receptionist checking her email or the CEO who demands access to the entire network structure.

The best authorization and accountability systems in the world have their use severely degraded once the authentication has authenticated the wrong asset, (computer, user or combination of the two). We both know that there are a multitude of ways that any of those authentication
methods, or combinations of them, could be attacked/broken... The obvious one is the laptop with the list of logins and passwords but it goes right up to sophisticated MITM attacks, DNS poisoning, Evil Twin WAP's etc. Short of the secadmin going with each asset to "hold it's hand" and be able to recognize such things, (or at least have his suspicions raised and be able to determine the threat), the asset is alone in hostile territory. While we both might agree that following that cutie from Accounting around for 24 hours a day while she is at a conference might not be a bad idea I think we both agree that the same assignment with the CFO is not such an attractive proposition...

So, with the inherent weakness in the assets, (both human and computer), in the authentication process how would we implement a "perimeterless" network while still assuring the integrity and confidentiality of our data? I don't believe we truly can until we come up with a foolproof system of authentication.... And they will just breed a better fool.... <LOL>

Damn that's a response. I think it's funny too when Shanahan gets worked up. We could spend a while talking about the quality of punk asses on the Raiders but my passion really lies with Hockey. I am so pissed at the league and players I need a beer stat. Real quick, multiple downed exhanges....

Authentication is not the single point of failure, though it may or may not be the highest risk. I am sure you agree that authenticated users, thus a perimeterless view, are the biggest risk factor. Not violation of the perimeter like traditionaly noted. They have already bypassed the authentication mechanism. The perimeter is breached, what is left? Say they aren't the culprit though, say someone copied your authentication mechanism from the laptop that tricks the perimeter into thinking the user and the machine are authentic. That does not mean they violate the integrity of an authorization mechanism (wish I had a spell checker). It would still be intact and watching. If this is windows only or course, it defeats the concept. :D But it could be a filter rule, machine "Bob" can never access machine "Jane" or network "monkey boys" and once it does happen, authorization policy revokes the rogue laptops authentication. Because the truly unauthenticated won't have a clue what they are authorized to access at the portal. Sounds perfect doesn't it? But it does not have to be automated. I am not introducing anything new here, just advocating a shift in the way systems are administered or policed.

You used your VPN as an example, I look at it like they are web users. We don't know who is out there, who has a valid account or not UNTIL they hit my first leg of the perimeter. I don't consider them part of the perimeter until they invoke the authentication process and my web site verifies they are who they say they were. Once that is done, they are inside the perimeter and moving about making changes and mucking about hiting additional instances of authentication once in a while and alot of authorization checks. And most importantly they are being audited before processing requests in the core. And then once again outside IT.