Please Accept My Apologies

If you have seen my presentation 'How Not To Do Security: Lessons learned From The Galactic Empire' than regardless of if you liked it or not, I owe you an apology.

It was pointed out to me that a satirical image of the Death Star, was in fact a thinly veiled political jab at one of the US parties. It was not my intention to use this image in this way, in fact it completely escaped me that it was even remotely political in nature. I missed it, and I think allot of viewers did since I've done this a few times now, and no one mentioned it until recently. I also suspect many that have seen the presentation, and picked up on the image, most likely concluded I was not trying to project a political advocation, since the talking point was specific to cost of IT security relative to a complete infrastructure, but thanks for letting me keep putting it out there ;)

I make no secret my thoughts on politics, it means very little to me. I follow it more like a sport, then with any seriousness, and tend to make light of the value of any political system. Sometimes they do good, sometimes they do bad, but most of the time they are just trying to survive with little control, like everyone else.

I understand these things are very important to some people, and I am not equipped or able to intelligently and thoughtfully discuss the nuances of political parties in any country, so please, do not take that image to have any intention around making a political statement. And if you did not notice, don't worry about it, I still don't quite get it, but either way it was an altered image (when I looked closely at the slide, I could easily see a change from the original design and images) that meant something I did not. It is removed with my apologies.

If you are going to give me 45 minutes of your life, I should at least try to teach you something useful or interesting.  And if I can't do that, I should at least entertain you, but please know I had no intention of trying to make any kind of political stance.

@kellman

On a side note, here is an updated version of the Introduction movie for How NOT To Do Security: Lessons Learned From The Galactic Empire.

How NOT To Do Security: A Sketchnote

It occurred to me that for as powerful as the Galactic Empire was, they continually failed as some of the most basic security controls that could have averted their entire destruction at the hands of those terrorist rebels. Here is a sketchnote by @agentfin of http://graphitemind.com, of my talk at Security Bsides San Francisco 2012 on the subject, How NOT To Do Security: Lessons Learned from the Galactic Empire.

What if the TSA secured the internet?

     Bill C-30, Bill C-11, and whatever they call it next, all keeps coming down to the same pointless issue.  Our government wants to force ISP and service providers to store logs of user activity on the internet, and to hand them over without a warrant and no questions asked. Oh, and it’s for the good of the children.  Unfortunately when we just focus on the ‘save the children’ argument, the realities of where this idea is fundamentally flawed ends up being conveniently ignored. It’s airport security all over again. Spend allot of money to secure very little, and actually cause more problems then you fix. 

     I see two huge fundamental flaws with this plan that very few seem to be talking about, and it has nothing to do with ‘personal rights’ or privacy or constitutional rights, or whatever activist group is crying the blues about. I will spare you the soapbox stories of our personal liberties being squashed, it’s being covered enough. What isn’t being talked about is how this is actually going to work.

     Storing and tracking the amount of data we are talking about has a cost associated with it.  Storage on the scale of spying on an entire country is not going to come cheap.  Who is paying these costs?  If you think internet access in Canada is expensive now, wait until we are also paying the extra charges to spy on ourselves. We also haven’t talked about what systems we are going to build to harvest the right data from the massive amount of traffic we are going to be saving.  Who pays for that? (Maybe google will offer to do it for free? ;) Keep in mind, our personal data use is only going to keep growing.  How far back are we saving it?  Are we only storing or sampling some data? If we are using it in a court case, we might need to see all of the activity to accurately define what is really happening. This leads me to fundamental problem number two.

     So what if we can track peoples activity on the internet? The data we are collecting is questionable at best. We know there are botnets out there in the millions. That’s millions of infected machines per botnet type.  As you read this, computers are being hijacked on a mass scale.  So let me ask the question, if we use this data we just payed to collect on ourselves, what are we doing to protect the literally millions of unsuspecting users whose machines are infected, hijacked, part of a botnet, and generally under the control of someone else, from being swept up for copyright violations, child pornography, file sharing, etc, when we can’t even be sure the end user has any idea it’s even happening?  

     Hard to believe, but the Canadian government is actually planning on paying extra costs, to collect and sort information about ourselves, that we can’t even be confident is valid traffic from the physical owner of the computer. You can argue that the users should know better, or that they are part of the problem, or maybe the data is valid and you never know until you look. But the end result is still the same.  We will fill our jails and courts with people that have no clue what was happening, while the real criminals, pedophiles, and thieves use tunnelling with communication obscuring technologies to move around illicit data, likely with botnets, same as they ever have.  And best of all, we get to pay the extra jail and enforcement costs associated with this influx of new ‘criminals’. Does the police force have the ability to tell valid from bot generated traffic? What is the process to validate a machine they suspect was used to commit a crime and identify potential botnet activity which could point to a different perpetrator? These are things large organizations with huge amounts of funding already struggle with, do we really believe we are equipped as a country to deal with this on such a massive scale? Are we prepared to treat the data collected as true without validating the system has not been compromised and we are looking in the wrong direction?

     I know the politicians want to at least seem like they are doing something, but what they are proposing is a little too far from a useful reality for my comfort.  I’m sure it all sounds good on paper, but when you consider the technology that is going to have to wrap around this, it’s going to be complicated, expensive, and ultimately not all that useful when it’s done.

     This sounds like modern airport security for the internet.

Meet Joe Roberts

How do you curb the security risk behaviours of a user population you are responsible for?  You educate them about your policy in real time.  Meet Joe Roberts, who regularly skips the quarterly lunch and learn corporate security training, and always signs his acceptable use policy without actually reading it.

↵ Use original player

Meet Joe Roberts

By kellmant

YouTube

• 360p
• 240p FLV

← Replay

X

i

Next Generation Policy Management

The Movie version of this blog for the ADD generation.

There is allot of talk in security about ‘next gen’. This use of the term ‘next gen’ implies we have something new and beyond what we had before. That it’s somehow a colossal leap forward and unlike anything we have seen or heard of before. And when you finally rip the cover off of the shiny new ‘next gen’ security solution, what do we have? Well, the same challenges, but hopefully you at least found more visibility, and policy control options than you did before. Now the question is, what do we actually do with these strange new ‘abilities’? What is so ‘next gen’ about your security?

First off, I thought ‘next gen’ was overused 20 years ago with Star Trek, but it still seems to resonate with everyone. Marketing aside, in most cases you can reduce this overused moniker with a rather rudimentary feature in most firewalls today, application identification. What I find ironic is that this feature, in and of itself, is not new at all. What is new about it is the ability to branch out and see applications that don’t have a defined RFC or common protocol agreement, but the act of identifying traffic based on heuristics, signatures, protocol formats, etc, is far from new. It’s so old and been done to death, I can’t help but smirk when people talk about application control like it’s new. And if your ‘next gen’ security device is defining ping as an application, then I have some disappointing news for you; I was deploying ‘next gen’ firewalls in the nineties, albeit with not nearly the number of applications you have today.

There is no magic feature that suddenly removes the requirement for you to manage your risk with process and procedures. You suddenly don’t have to do audit and control. What these features are giving you is better visibility, and theoretically better control over what your users are doing, but let’s not forget what your solution as a whole is still trying to do. Manage risk, protect data, audit activity. We don’t need a ‘next gen’ feature. We need ‘next gen’ policy management.

How We Always Did It

Traditional policy is based on a simple approach of defining access control based on IP. We define networks by the IP addressing they use, and as long as someone doesn’t move around too much, or change IP, we can track them just fine.

Of course this view of policy management is antiquated as it is a security level that is fundamentally dependant on how much physical control you have over what can connect to your network. If you have already invested quite heavily in some type of NAC (Network Access Control) solution, you will probably be able to get away with IP based access for at least a little while longer. But it is going to get very ugly to manage as time goes on. As your organization designs and adopts more agile computing options, things will start to change quicker than your security policy can adapt.

Security Policy of the Future

The popularity of mobile devices, coupled with computing devices like tablets, has equated to people having many devices, and therefore, many IP's. Managing IP based access with a constantly changing array of devices in the user base quickly becomes unmanageable and therefore, insecure. New applications, coupled with new mobile devices makes keeping up with policy change requests more and more ugly. If the requests keep coming in based on people and their devices, and your final policy is compiled based on IP, you are already in allot of trouble with exposure you wont even see, until it’s too late.

And it’s actually worse than this, because these new and exciting devices are coming into the office from the home too. Without being validated, secured or even looked at. Users are bleeding their personal devices all over your network; they take work home, they bring home to work.

Now let's consider the impending adoption of IPv6 (yes, it's going to happen sooner or later). Are you going to continue building rules based on your network of a billion or so IP's? Does your policy account for the fact that an IPv6 devices could actually have many IP’s connected to many networks at any given time? And come audit time, are we going to be looking over whole netblocks of IPv6 addresses and have a quick way to validate no one is accessing applications or data they shouldn’t? Not without a whole lot of pain and cost under an IP based security policy.

Identity Awareness

Knowing who your users are, is critical to managing a security policy. Knowing what IP they are using, not so much. If we are getting policy requests in a business language that talks about people, then you are beyond IP based control. Defining policy based on user access is not just the logical choice, but the only way to manage access moving forward. And that’s just for starters.

Remember all those devices we are acquiring? It's not enough to know who is accessing the data, you better be able to define what machine they are accessing from.

Device Control

Knowing what devices your users are on allows you to make better security policy decisions. For example, a user on their corporately controlled and encrypted laptop should be allowed differentiated access from the same employee on their iPhone. This also allows you to track what devices have accessed what data, so if you need to determine where data was lost from, you already have a defined limit on the number of devices and people that could access that data.

Consider how powerful the addition of this parameter can make your security policy. The CEO is allowed to access portal versions of some applications from his iPhone, and all the critical financial data from the corporately controlled, encrypted and highly secured desktop at the company headquarters. If the CEO was to loose their phone, and an attacker was able to extract a login password from the device, they would still be without access to the more sensitive data since it requires access from both the login and a specific identified device.

How Does Application Control Help?

As long as we are getting rid of IP based identification, let’s do something about getting rid of TCP port based identification of applications. Identification of application activity is not a new function of a security device, as I have mentioned. Knowing that ssh services are attempting to access over port 80 (http), for example, have existed for quite some time. But the ability to identify applications that are not defined by standards and RFC, applications like the preverbal Web 2.0 that have crept into the enterprise, is a powerful addition to a next generation policy. Moving forward, it is important that we are providing access, not just to a service port, but to the application itself.

Having a flood of applications coming and going doesn't help if we don't add one more dimension to this policy, and that is the user.  Having a way for the user to interact with the security system, not to educate a user on acceptable use, but to take feedback from the user so new business opportunities with applications are not missed.  Make user realtime user feedback part of your next generation policy, and you will truly have application control.

But don't get too far ahead of yourself, there is a danger in depending completely on the feature of application control.  In order for the device to determine the application being used, they must allow the connection to be setup, and for initial data to pass, before qualifying the application.  This creates two risks, one, that someone could scan through every open port on the remote server, even if your intention was to only allow a single service.  For example, defining the http application on a server that has other ports open, like remote desktop for management.  By just defining the application, and not access rules with it, a remote attacker could probe and determine the remote desktop service is there, simply by pretending to send web calls to all the ports on a remote system.

Application control doesn’t mean people will no longer be able to use applications they shouldn’t, it just means we have a new game of cat and mouse. As fast as our security devices identify applications, watch what happens when people get into spoofing application signatures. It doesn’t solve all our problems, and it is not infallible, so there will always be the need for some element of basic network control.  But we also need to add another parameter to our policy, that gives ourselves another layer of protection.

Identity + Device + Application = Not Enough

With all this information at our disposal to create policy, you would think this would provide all you need to enforce a complete security policy, but unfortunately we are still ignoring the most critical element. Let's remember what all this effort is for, and that is protecting the data within your organization. When you combine access control based on people plus machines, with the identification of applications that are accessing, sending and manipulating data, the final piece to create a complete policy is the ability to analyze the data being transferred to ensure the applications are not leaking or sharing information they should not be. In short, let's go back to basics and ensure we have a policy around not just what applications people can use, but what data these applications are allowed to use.

Who Touched My Data?

At the core of any security policy should be the control of the flow of data. As such, focus on the data of any type of application ensures that the applications we allow into our organization are following the the policy and rules around what is permitted when it comes to the flow of information.

If there is an application in your environment, that is showing itself to be rather innocuous, then we tend to ignore them after seeing them. Even after you have identified an application, we still need to continue watching, not just the application, but the data it is handling. If it is a low risk, low impact application, it should never be touching or revealing sensitive information. By getting back to the root of our risk, the data, we ensure a policy that goes beyond the user, the machine, the IP, the application and right to the data. Data Loss Prevention is not just about blocking what you perceive to be sensitive data, it is about watching what your applications are doing with the data they are handling.

Next Generation Policy Control

By combining information about people, and the devices they use, with the applications they are allowed to run, and finally, what data these applications are allowed to access and modify, a cohesive policy focused on the critical asset, your data, can be created and managed.

Your migration to a next generation policy should include the ability to blend requirements as you evolve your change requests to work closer with the business language. Start by bringing in User/Device options to be used with or without IP. Keep in mind IPv6 hasn’t exactly hit us in the head, and if you have a NAC solution, adding and extra layer of validation when you are not positive about the new options can actually make this a smoother transition. You have six factors to consider creating a next generation rule.

Access Rule = (User+Device) else/+ IP ; (Application) else/+ PORT + (Data Type)

This will start the process, allowing you to migrate fixed IP addresses to users and devices. Keep in mind devices apply to server as well, and you can create access rules in both the source and destination that are defined by the device and user, not just an IP.

I believe this will evolve you to the point where network based decisions are no longer part of the security definition, and at that point, you will be into a next generation of something useful, policy management. You have extracted the dependance on network design from the security posture, and as such free your infrastructure to upgrade, downgrade, shrink, expand, try IPv6, etc. The security is built a few layers up, giving you the flexibility you need to make your infrastructure as dynamic as possible. In essence, we stop thinking about managing security rules, and focus on creating security roles around 4 defining parameters.

Access Role = (User+Device) ; (Application) + (Data Type)

Removing the confines of IP based security rules, opens up an agile security solution that allows you to create policy independent of the network design. Imagine the flexibility and freedom for the security team, if the policy they are managing is all about security, and not about network engineering. And how good will the network engineering team feel about being able to make changes to the physical infrastructure, without having to consult and validate those changes with the security team?

Now imagine how you will deal with virtualization, cloud computing and an ‘app for that’ world without a next generation policy design.