On 13 August, jcorey asked about how to deal with those who firmly believe that the only answer to any security problem is to inspect everything at the edge. This is an important question, and I wanted to give Joe an answer. (You might have to scroll down when you click the previous link, it seems that linking to individual comments is broken.)

Today, 15 October, I wrote a little thesis as an answer to his question. I’m calling it out in a separate post because I want to make sure those of you with aggregators that don’t update when posts receive new comments still have a chance to reply with your thoughts. I’ll also repost it here:

jcorey-- You've nailed the biggest obstacle to deploying something like direct connect. Many security professionals have been taught that there simply is, and never will be, a process or technology that allows you to trust anything that originates from outside your corpnet. These professionals cling to this belief, and have been the cause that allowed the whole “detection” market to bloom.

Let me be clear: this total lack of trustworthiness is no longer absolutely true. Of course there will be times when unknown machines will be used by known and unknown people to access your information. But what about one particular subset -- known humans, with known portable computers -- can't we do something better than treat them as toxic invaders?

Indeed we can. And that's what I'm proposing with direct connect. The technology -- managed, of course, with the right processes -- exists so that you can extend the trust to known computers even though you don't trust the network they're connected to. This is because you have mechanisms that:

1. Allow you to configure the machine according to your requirements (domain join, group policy)

2. Dictate computer and user authentication requirements (IPsec policies, smart cards)

3. Limit what the users of these machines can do (UAC, non-admin, Forefront Client Security, Windows Firewall, even software restriction policies)

4. Validate the health of machines initiating incoming connections and remediate if necessary (NAP, System Center Configuration Manager)

5. Limit the threat of attacks against stolen computers (domain logon, smart cards, BitLocker with TPM)

With the robust authentication, validation, configuration, and control mechanisms available to you, I simply don't see that there's any need to fall back to “detection” now. Detection technologies were -- and remain -- necessary for the times when we have no clue about the health of client computers and when we had no way to gauge the intent of the users. But it is truly reflective of a head-in-the-sand mentality to assume that this is a complete description of what's capable today.

You know, someone once asked me what it takes to be a security professional. I answered that there are two primary elements: become a networking/packet wonk, and be willing to change your opinions when the right evidence comes along. Indeed, I suspect that many security folk have forgotten the need to keep their wonikness updated, which in turn makes them resist new ideas regardless of the strength of the evidence. I'm not very proud of what I just wrote, because I loathe generalities, but I'm not sure what else to think here. Sigh.

Joe’s question is important and strikes at the foundation of what it means to be a security professional today. I’m eager to continue this conversation, because it’s reflective of what I sense to be a radical shift in our jobs—we are, or should be, no longer the wolf-crying propeller-head who sits in the basement and twiddles with the firewall. Instead, our job should be defined as one who’s charged with protecting the organization’s information from attack, while maximizing its utility to authorized users, according to the principles of least privilege. Your thoughts?

At TechEd this year, I gave a presentation called "21st century networking: time to throw away your medieval gateways." (Actually, I've given this same talk before, at events in Amsterdam, Brussels, Oslo, and numerous on-campus customer meetings. It's time to bring the knowledge to the masses.)

I described an idea of using IPv6, IPsec, NAP, and group policy to build a pretty slick replacement for clunky VPN gateways. Turns out we've been piloting this very idea on our internal corpnet. Like a good little bunny I got myself enrolled in the thing and -- pardon the unattractive gushing -- this thing rawks! Here's a brief rundown of the parts you'd configure on managed clients:

• Windows Vista Business (with Software Assurance), Enterprise, or Ultimate editions
• That are domain-joined
• Users run as non-admin
• Group policy applies numerous settings
• UAC is enabled
• BitLocker is configured to protect confidential information stored offline
• The Windows Firewall is enabled
• NAP is used for checking health
• Forefront Client Security for keeping malware off the box
• Smart cards for strong authentication of users
• IPsec is required for connection authentication and traffic encryption
• IPv6 is required for worldwide Internet connectivity
• A DNS suffix search list represents the data center name space
• Static IPv6 DNS servers provide name resolution for hosts in the data center

What does this give you? True anywhere access, anywhere in the world, directly to corpnet resources from managed and secure client PCs. The Internet has replaced private WAN links for good reason: enormous cost benefits. The only thing holding us back from fully utilizing this development has been a lack of way to enforce and monitor the security of clients not physically located within the corpnet. Well, those days are over. Now you can build PCs that are trusted just as if they were on the corpnet, without knowing or caring anything about the underlying network connections. And let me tell you, it's as addictive as a few other substances I could mention, but will refrain, since this is (I hope) a family blog :)

Maybe you've heard of the notion of "deperimeterization." Taken to its extreme, I think it's a bit silly. To put a SQL Server directly on the Internet is just plain stupid -- not because I don't think I could keep it protected, but simply because that's unnecessary risk. Only my web server -- and no one else -- should be talking to my SQL Server. But that web server will be in the same subnet as the SQL Server, and IPsec policies used also here will govern who can connect to the SQL Server. Warning to any and all network DMZs: your days are numbered!

Shrink your perimeter to that which really matters -- your data center. All your clients live (as we would say in the olden days) "on the outside of the firewall." Now then, there are two kinds of clients. Managed clients, as I described above, establish IPsec-authenticated/encrypted, group-policy-configured, NAP-enforced IPv6 connections directly to corpnet resources without going through any kind of access gateway. The router connecting you to your ISP is fully sufficient for blocking denial of service attempts. Be sure to follow my advice in "Configure your router to block DOS attempts," and then add two more rules to permit incoming port udp/500 and IP protocol 50 over IPv6. That's it. No NATing or other unnatural network acts are required (finally, you can stop lying to your significant other about why you squirrel yourself away in the computer room all those weekend nights).

Unmanaged clients will continue to use IPv4 to access published Web and Win32 applications through a gateway like IAG. Since you can't trust these clients nor can you trust the data they're throwing at you, you have to inspect and validate at the perimeter. You can take advantage of IAG's application-modifying capabilities to "wrap" security around poorly-written web apps; you can even download an ActiveX control to unmanaged clients to perform some basic health checking, policy enforcement, and cache clearing. None of these eliminates the final requirement to continue inspecting and removing malware from servers where users store data: Exchange, SharePoint, Office Communications Server, and file servers.

Machines are mobile, data is mobile. The mainframes and large desktop PCs of the past posses an effective security attribute: the heaviness of the machines. You couldn't easily saunter out the front door with a PC-AT in your pocket! These days, we all line our pockets with tiny little mobile phones stuffed with 16GB of storage. It's now a fact: data moves. And like water, data moves wherever it can, as rapidly as it can, often beyond your control if you don't prepare for that. With properly-configured and managed clients we can enjoy a single access and authentication experience no matter where the computer is physically located. For example: I can sit in my house and enter '"http://internal-web-site-name" in my browser. The DNS suffix search list adds the appropriate suffix, my browser's resolver performs an IPv6 name lookup, and my computer makes an authenticated and encrypted connection, after it meets the NAP policy, directly to that internal server. Very nice. As far as I'm concerned, there's no difference between the Internet and my corpnet. It's all just there.

For a while now many of you know I've been speaking and writing, mostly at the conceptual level, about the day when such a way of remote computing will arise. Well, my friends, that day is now. You can indeed build it now, with the products you have. I won't admit it's all peaches and cream: there's a fair number of moving parts here, it's true. But most of these moving parts are parts you're already familiar with: I'm simply encouraging you to move them in a specific way. You'll need to do some custom scripting for client-side connection diagnostics, but that's about it.

My next step is to create a more detailed guide, which I plan to publish through TechNet Magazine. I'm targeting (but not promising) the October issue. The article will include greater details about configuring your infrastructure to support the managed clients I describe.

I've lost track of the swelling number of individual conference attendees and the plethora of email writers who've expressed a desire to build this in their own environments. The one common thread from everyone is "I want to do it now!" Folks, it's really pretty exciting for me to see so many of you ready to cross the chasm from the perdition of paleo-networking (layer upon endless, complex layer of DMZs) into the paradise of flat, simple, cheap, and secure access to information. If you haven't yet, please take the time to read through some of our information (especially Scott Charney's paper) on end-to-end trust. Friends, the idea I describe above is the plumbing for realizing the end-to-end trust vision.

Q1: When you mention "forensics", are you speaking in term of legal forensic terminology - or in terms of incident investigation?

A1: When I say "forensics", I usually mean it in the legal sense. I call other investigations simply "incident investigations;"  forensics carries an extra burden of proof and seeks to establish facts, not just "good hunches."

Q2: Are there solutions that can handle 2-3 Terabytes of log data per minute?

A2: No. Easy, huh? :-) See this for a specific example.  Well, let me take this back: theoretically, you can always use a vendor that can handle a lot of data (like LogLogic) AND that has an ability to run a distributed operation across many appliances. The catch? You will need a lot of the appliances since 2-3 TB/minute is about 90 millions of log  messages/second (assuming an optimistic 200 bytes/message)

Q3: I have terabytes of log data but how can be analyzed all this data? Are there products that can process all this data and receive valuable information?

A3: Yes, but you need to ask one question first: analyze why (example reasons here)? To discover something "interesting" (my favorite reason)? To find some specific artifact that you need in the logs? Or for some other reason? Before anybody can answer a question about "are there tools to 'analyze this'?", you'd need to answer that dreaded "why" question.

Q4: We were told to log every access to every SQL database in our environment. Is this even feasible with the best products on the market?

A4: Yes, it is. However, one needs to be extra careful with this. Look at this post for options and ideas. It may turn out that logging every SELECT statement and then collecting those native database logs will not be the best approach (mostly for database performance reasons) and a dedicated tool will need to be used. Database built-in auditing are better used for selective auditing.

Q5: Once logs are captured, and centrally stored, who should be responsible for the management and review of those logs?

A5: Good question! Really, this is a very good question that a) is important to have answered  and b) does not have an "accepted," standard answer. It also depends upon what logs are those; let's assume the most complex scenario of a diverse set of logs from networks, systems and applications. So, the choices are: security team (sometimes: CIRT i.e. incident response team), some dedicated team in IT that provides "log services" (uncommon option, but growing in popularity) or some unit  in IT that is responsible for regulatory projects (if compliance driven). If your answer is nobody, then you will be in trouble :-) If you answer wrong, you might have to fight to access your own logs (example)

Q6: Most of the discussion so far is about how to get started. What about after the system is deployed? Products tend to focus on collection and not on action or response. Where are the tools heading in terms of usability, incident tracking, collaboration?

A6: That's a long story, really, and it is hard to provide a short answer to this. Yes, collection has been a focus of products in the last few years, but now we are at a point where analysis and various uses of the data will come to the forefront. At the very least, you should be able to run reports and searches on the logs that you collected.

Q7: Do vendors typically offer a template of which logs to collect based the desired use cases?

A7: They should, yes :-) In some cases what you have is a bit of a push-pull between a vendor and a customer: "Tell us what to do?" - "First, you tell us what you would like to accomplish?" - "No, really, you tell me what I should be looking to accomplish." - .... sometimes ad infinitum. Also, for some uses cases it is hard to come up with a credible list (see this discussion about PCI DSS here)

Q8: What are the biggest difficulties when the log management solution is going to to be integrated and deployed in an organization with a lot of different log sources?

A8: Political boundaries and "log ownership issues" (see some discussion here)  If you need to submit a paper form in triplicate to add a line to /etc/syslog.conf and then send more forms when something doesn't work right and you need to troubleshoot it (a real story), everything becomes painfully slow and inefficient.

Enjoy! Again, here is the link to the webcast recording.

I came up in the network / security industry with the concept of "trust no one" at the forefront of my brain.  Well, trust no one until you have been given assurance that you should trust someone or something.

So, do you trust "Virtual Disk Images" downloaded off the internet?  Would you download an image from VMWare's Virtual Market Place or a web site called ThoughtPolice.com?

Have no clue about what I am talking about?

Well, one of the cool things about virtualizaiton is that servers and desktops now have the ability to go mobile.  They can be copied from place to place and even be downloaded off the internet.  This capability makes it easy for you to get a server up and running. 

Remember the days when you had to install a Novell 3.11 server from 20-30 floppy disks?  It was painful wasnt it?  Worse than watching paint dry.  You had to stare at a screen and wait for the next prompt to change the floppy disk.  Then you would get to a question to enter some information that you didn't have a clue about and then have to rush to grab the manual.

Well, now with virtualization you or someone else can go through the installation process and once the server is  installed, you can replicate it without having to ever install it again.

The problem with the above sentence is "someone else".  Again, I trust no one else and I definitely don't trust someone I don't know installing a Linux server and publishing it on the internet for me to use.

But there are many people out there in the world that are ok with downloading "Virtual Disk Images" off the internet and placing them either in lab environments or production environments.  The problem with this is that anyone could create a Virtual Disk Image of the latest Fedora Linux operating system, purposely embed a trojan or virus in it and make it readily available on VMWare's Virtual Market Place or sites like ThoughtPolice.com

   Click Me                Click Me  

An unsuspecting, trusting individual could then download that "Virtual Disk Image", run it inside their VMWare environment and the next thing you hear is there data center or lab is attacked.

Downloading these virtual disk images are more dangerous than downloading a file off the internet or clicking on an attachment in an email from an unknown sender.  Why do I say this?  Because downloading a virtual disk image is a FULL ON operating system with many applications in it.  If a hacker has control of a full operating system they can do things like schedule attacks that happen in the middle of the night, port scan your network for information and email the results to a BotNet Master and even run a packet capture of traffic and FTP that to a BotNet master.  Imagine the possibilities and imagine being able to run any application not just a small file attachment.  An application buried in a directory somewhere on the Virtual Disk Image.

Did I just bum you out and paint another picture of doom and gloom?

Well, its not all doom and gloom.  Knowledge is power as they say and now with this knowledge you should think twice before downloading an image off the internet and use it without fully checking it out.  Fully checking it out means running anti-virus software INSIDE the image and making sure you have VM to VM aware firewalls within your virtual environment to isolate traffic flows between VM's.

Lastly, I think downloading these images is pretty cool and would love to be able to take advantage of someone else watching the paint dry during an installation however, I think there needs to be a "Verisign" of Virtual Disk Images.  This way someone who you trust can do the work of inspecting these images for me.

-JP

I came up in the network / security industry with the concept of "trust no one" at the forefront of my brain.  Well, trust no one until you have been given assurance that you should trust someone or something.

So, do you trust "Virtual Disk Images" downloaded off the internet?  Would you download an image from VMWare's Virtual Market Place or a web site called ThoughtPolice.com?

Have no clue about what I am talking about?

Well, one of the cool things about virtualizaiton is that servers and desktops now have the ability to go mobile.  They can be copied from place to place and even be downloaded off the internet.  This capability makes it easy for you to get a server up and running. 

Remember the days when you had to install a Novell 3.11 server from 20-30 floppy disks?  It was painful wasnt it?  Worse than watching paint dry.  You had to stare at a screen and wait for the next prompt to change the floppy disk.  Then you would get to a question to enter some information that you didn't have a clue about and then have to rush to grab the manual.

Well, now with virtualization you or someone else can go through the installation process and once the server is  installed, you can replicate it without having to ever install it again.

The problem with the above sentence is "someone else".  Again, I trust no one else and I definitely don't trust someone I don't know installing a Linux server and publishing it on the internet for me to use.

But there are many people out there in the world that are ok with downloading "Virtual Disk Images" off the internet and placing them either in lab environments or production environments.  The problem with this is that anyone could create a Virtual Disk Image of the latest Fedora Linux operating system, purposely embed a trojan or virus in it and make it readily available on VMWare's Virtual Market Place or sites like ThoughtPolice.com

   Click Me                Click Me  

An unsuspecting, trusting individual could then download that "Virtual Disk Image", run it inside their VMWare environment and the next thing you hear is there data center or lab is attacked.

Downloading these virtual disk images are more dangerous than downloading a file off the internet or clicking on an attachment in an email from an unknown sender.  Why do I say this?  Because downloading a virtual disk image is a FULL ON operating system with many applications in it.  If a hacker has control of a full operating system they can do things like schedule attacks that happen in the middle of the night, port scan your network for information and email the results to a BotNet Master and even run a packet capture of traffic and FTP that to a BotNet master.  Imagine the possibilities and imagine being able to run any application not just a small file attachment.  An application buried in a directory somewhere on the Virtual Disk Image.

Did I just bum you out and paint another picture of doom and gloom?

Well, its not all doom and gloom.  Knowledge is power as they say and now with this knowledge you should think twice before downloading an image off the internet and use it without fully checking it out.  Fully checking it out means running anti-virus software INSIDE the image and making sure you have VM to VM aware firewalls within your virtual environment to isolate traffic flows between VM's.

Lastly, I think downloading these images is pretty cool and would love to be able to take advantage of someone else watching the paint dry during an installation however, I think there needs to be a "Verisign" of Virtual Disk Images.  This way someone who you trust can do the work of inspecting these images for me.

-JP

Yesterday we announced our latest version of our Safe Access NAC product.  This release has several new wrinkles for Safe Access which keep it at the forefront of NAC functionality, but the biggest thing is that we finally are offering StillSecure branded appliances. We still offer Safe Access as software that you can run on your own hardware, but after years of swimming against the tide we have come to the realization that it is just easier for people to buy an appliance than anything else. So with this version of Safe Access we now offer a StillSecure branded appliance.   

Designing and putting in the processes to sell and support these appliances has been a long time in the making, but we think we have it down now. I am looking forward to see what difference this is going to make.  We will soon have StillSecure appliances for the rest of our products as well.

There are several other new features in Safe Access that are worthy of mention. One is a plug in that allows for DHCP NAC to be done not in line and more scalability. Vista testing is another.  Post-connect integration with StillSecure Strata Guard as well as the ability to integrate with other IDS is another important feature. One of the most important is what we are calling Deep Checks.  This gives us the ability to audit at a much deeper level for policy compliance. I will probably do a full article on deep checks in the near future.  There is a laundry list of other new features and improvements in the product as well, but you can check the release for the whole story.

Many are saying that this is the year NAC gets real and NAC vendors have to stand and deliver. With this release of Safe Access I think StillSecure has the goods to win.