Welcome. I am Shawn Geddis. Security consulting engineer in the Apple Enterprise division. Today we really want to take a serious look at some of the additional ways that you can enhance the security or the fortification of your systems. And we will get through the presentation here. I just want to give you kind of some advanced information.

In addition to my sharing some information, I also have a colleague from NSA joining us. And we're going to be sharing some of our joint guidance. Some of the direction we want to give you as users, administrators, developers, and how to, again, fortify the security within OS X. So let's kind of walk you though this.

If I can use the clicker. We want to introduce you to some concepts and then back that up with some guidance. And the first is system hardening. A lot of times they'll -- people will mention system hardening, and they're not sure what that is. Yeah. We're hearing something back there. We'll ignore them.

We're going to review some of the security services and the tools that are in Mac OS X today. Both as users, Admins, and of course development. And then we want to let you know both for now and ongoing, the resources that you have available to you for additional guidance. Because securing systems is not an easy thing. And it's not a win time thing. It's a constant battle, and it gets harder and harder as you get more and more people attacking things.

So what we hope you will learn out of this really is to better understand what that hardening in your environment. Because hardening your system if you look to the person to the left and the right, it means something totally different. Because the system is in a totally different environment. If you're in a hot spot, if you're in kind of your own kind of personal network, if you're in a corporate enterprise environment, if you're kind of exposed out in a travelling environment.

So again, that's where you're hitting the different hardening techniques for different environments. I struggle to figure out what would best -- what I would have best to share with you on how to do this hardening. Because it gets kind of tedious, it gets kind of mundane after a while. And so I really kind of hit the top ten items.

So really target something that all of you in this room should be able to do today. Right? Something that even people new to OS X should be able to do some of the tasks, some of the approaches that I am going suggest here. And you'll walk away with a better protection of your system.

Mentioned about the guidance vote from Apple and from NSA. And then I mentioned also about some physical guidance documents and some other groups externally that you have as kind of your security tool chest. So first of all, what does system hardening really mean. Well, the purpose of it is really to in one way reduce and hopefully eliminate any of that risk that's possible in the environment. Like I mentioned. In the environment that the system is running in. If I have a stand-alone computer that in my house, it's not attached to anything, no network, that's in a different attack environment than if I'm sitting at a Starbucks going through T Mobile.

So let's kind of walk through the ten -- as I say the top ten steps that all of you in this room should be able to do today They're kind of categorized. And when it comes to security, you have to start protecting. You have to start with a good protection from the get-go.

So what is it that all of you in this room should be able to do right out of the gate? Well, first of all I am surprised on a daily basis how many people will, whether they're in an organization, very large company, maybe even kind of a small business. And they'll kind of share systems. They'll kind of -- hand me downs. You know, you get a brand new system and you hand that next system off.

That -- now you should be taking that system back and starting fresh. Wiping information off, starting from a fresh install. If you don't, you're now starting with any kind of configuration, any kind of potential embedded attack that may have been there before. So start clean. Start from a known state. Again, these are very simple, should be common thinking in your day-to-day approach in the computers. Never assume that the system's okay. If you got somebody, or it got shipped to you, or it's in your organization.

So on each one of these steps I kind of want to also hit on some of the tools that we have as Apple. There's always some third party open source and others. I want to specifically point out those that Apple provides that you can use today to address these.

So to really start out, obviously some of the typical ones is the installation. Disk utility. Many of you that may not be familiar with the fact that in Disk Utility you can do the secure erase of your drive. Kind of a nice user interface, so you don't have to know the command line. You do secure erase of that disc plus what's known as securely erasing free space. Free space is where you may have let's say 100 files, and there's a whole bunch of kind of space that's not allocated, or not supposedly allocated in that drive.

It may still have some data written there from before. It may have had some temp files that have been deleted. You can use disc utility to securely erase all that area on any given volume. It's always a good idea to do that on -- particularly some external drives. If you're travelling between individuals, your sharing them.

ASR is for the restoring. Apple software restore. So if you're restoring imaging. A lot of you folks are using other tools built on top of ASR. And then net install. Again, most of those are geared towards restoring a corporate image. Many of you are doing a lot of imaging. I think you've been to some of the sessions on that. Very simple. So we're starting out clean. So let's kind of keep going forward with this.

What are some ways that you can secure the host? So we're going to work our way on up. We're talking about the host; we're talking just that physical box. What are some of the ways that you can increase the protection of this box. Whether it be your lap top or your desktop.

One is the discussion that many folks have had of leveraging the lock down of firm ware. Okay, had we had the PowerPC systems, it was referred to as the open firm ware. When we had the Intel based, and you've got EFI. It really is the boot -- the starting process of the hardware, and you're actually booting your system with OS X, with your machines, whether you're back to PowerPC or on the Intel. That's where your whole boot process starts. And you can lock things down with tools that we have within the OS.

Now if you're doing the firm wear lock down, it's related to a password. And many people new to this aren't familiar with the fact that the password related in firm wear has absolutely nothing to do with a root account. It's not the root account, it's not your Admin account. This is really maintained within that firm wear.

Another key thing that I've seen in many environments is probably many of you have external FireWire drives. Maybe even with you. Right? And they're in a housing. And many of you might have even opened that up and taken the drive out and swapped the drives. When you're doing -- if you look at start up disc and you're selecting that image, and when you go to lock it down with the firmer utilities, you're really locking it down to that unique identifier -- unique identifier for that drive.

But note that with FireWire drives, really, the unique identifier is the bridge chip; not the drive. So if you locked it down to that external FireWire drive, you open that up and you swap drives out, the system would still boot from that carrier. You wouldn't be locking the physical drive out.

Most of you should be aware of these. The open firm ware password utility was on the PowerPC side. Firm wear password utility is on the Intel machines. And those -- on your install DVDs, again, that's where you'll be getting those as well. And then those of you that are not faint of heart here, we're getting down to the command line. Getting down at firm wear. On the PowerPC systems you could actually drop directly into firm wear and set up the security command and enter that password and lock it down that way.

Okay. So locking the host down initially. Hopefully, again, everyone in this room should be able to do this as you walk out of this room. Second of all; very simple things. I am surprised at how many systems when you go to a public environment are broadcasting the fact that they have Bluetooth, broadcasting their own wireless, they've created their own ad hoc.

These are attack vectors. These are now areas where you broadcast your existence. You're letting other systems now that you're available, and you potentially have listening processes, you potentially have a point of attack. Simple things much turning them off. In some cases some environments go further and physically disable components, or remove them. The key particularly with related to some Bluetooth pieces is making sure that you don't retain that discoverability beyond your set up time.

The standard tools -- many of you guys are going to use on this -- are local management, System Preferences, turning things on and on from the GUI line, from the GUI space. Work group manager, if you're doing centralized management you can lock out those devices, lock out the media. For instance, you don't want to the CDs, DVDs and some other cases.

And then the Terminal. Many of you guys are doing scripting, you're doing desktop and pushing out some scrips that modify the work stations. Again, these are tools and services that I am highlighting are from Apple. There are so many other as well from third parties being court-martial and open source.

This is one that's near and dear to my heart, many of you that know me. Passwords -- we should be moving off of passwords. Moving off of the age old attempt at entering something that we know -- that's our attack. Moving to something that's a secure and reliability form of authentication, but still retains some simplicity in the user's experience. So doing the use of two-factor authentication like smart cards, or one-time password use.

But the first two there, I always thought that these were so common that people should just know. But first of all, operating as an Admin is a typical thing that we always tell everybody. But yet everyone that is an experienced administrator I think what happens is they all know it. But they still operate as an Admin.

There's a lot of functions, right? Everyone in here doesn't act as Admin, right? Come on! Be honest! Okay. Won't tell. The other thing is a lot of folks are new to the platform, thinking of Unix, they're starting to enable the root -- the root account. On OS X you really should never ever have to enable root on the client.

And so those very two simple things -- we'll get into some auditing later on -- these are some simple steps of protecting. But with user authentication -- another point I want to get at in just a minute -- some of the modifications that you can make to the authorization rights and the rules. System preference, work group manager, and Terminal. Again, tools that you can use today whether you're doing a direct kind of one to one management, centralized management across your organization. Or if you're wanting to do a lot of integration with other scripting or other tools off other systems.

Okay. So there's a couple rights and rules within the net C authorization that I've had several customers quite alarmed at situations that they just weren't aware of the default setting there. And it's a very simple thing to modify according to policies that they may have in their organization, or just to kind of be a little bit more secure themselves.

So a lot of people deal with the screen saver. You set your system aside or you're leaving it; you go away to get your Starbucks coffee. You come back, your screen saver's engaged. You need to authenticate. Well, so the right associated with being able to authenticate there is the system dot log in dot screen saver.

And the point that I want to point out here is the rule at the bottom. The name of the rule that's used for that is authenticate with a session owner or Admin. That's a key thing to keep in mind here, look at this. That's the default configuration. So let's look at that a little bit closer.

And if we look at the rule, the definition of the rule now, for authenticate session owner or Admin, it means that if someone is in the group Admin, or me as the user, either one can unlock that screen saver and get back into that session. Okay? So if I'm the user, I stepped away, I went to Starbucks, and my Admin's down a couple of cubes from me. And Admin is capable on that machine could unlock that screen and actually gain access to my session.

But this is something, again, that's very easy to tweak if you are in that kind of attack environment, or potential attack environment. We're looking again at the very bottom of this. This is the owner of Admin associated rule. So how can we correct this problem in this environment? Well, let's go back to the original right.

Remember, down at the rule. We're going to use a different rule for this. For this now we want to use just authenticate with session owner. And I've eliminated the potential of any Admin to unlock my screen saver and gain access to my session. So if we look specifically -- come on -- there we go.

If we look at that rule in the name of that rule is authenticate session owner, you no longer see the ability of a group. There's no Admin group now that's capable of doing that authentication. This will take you about two seconds, and now you're change that environment. There are so many -- there are so many modifications like this that you can do within the Nets authorization to match the various requirements maybe policy, maybe just kind of a desire in the working environment in your -- at work or at home. There's a couple other ones here that I like to point out because people again are sometimes unaware of how OS X does this enforcement.

Think about installation. We're going to install some software. So one of the rights for that is system install Admin user. Right? So this would be something that the user's going to go ahead and install, in this case an Admin. Going to install an application let's say into the applications folder. It says that the group that's allowed is the Admin.

And I also want to point you down to the lower part -- oops -- the lower part that shows the time out. Okay. Of the time out means that if I authenticate, I'm an Admin. And I do this install for the next 300 seconds I can repetitively do other tasks that require the same right.

Okay? So if I make a slight change, here I might be in an environment where I don't want just any Admin that has access to this machine to do installs in my -- on this box. I can leverage a different group. I can create a different install group. Here I changed it to My Install Group. And I can also change that time out to zero. Means that every time it needs to authenticate, it's going to force me to do that authentication. It's not going to resolve automatically for me in those 300 seconds.

Okay. So hopefully you got an idea there. There are lots of changes that you can make -- again, specific to your environment. The way the default configuration covers the masses. We're trying to help you understand how you can configure this according to yours. We're hitting on a couple of points.

Let's go on to how do you maintain some of this good posture once you've got -- once you've set up your system and made some changes. Well, hopefully one of the first things that many of you are doing -- how many people are using File Vault? Everybody? Put up your hand. Protection of data at rest. How many people have heard of lap tops stolen in your area in the last month.

Okay? How many of you heard of lap tops stolen in the government in the last couple of months. We didn't used to have to worry did that, did we. I mean, it was -- things got stolen, that kind of stuff. But what's happening is we're carrying around, you know, some of us couple of hundred gig drives now.

It used to be -- I can remember when you had a hundred gig drive and you felt like you just spent your week's pay to get that drive. We're carrying tons of data around. What we're doing now also is we're carrying tons of sensitive data. Very sensitive data. Whether that is financial information, whether it's personal information, or whether we're actually carrying somebody else's data. Somebody else's confidential information.

At least within the government space, a reference to typically identifiable information, is PII -- Personally Identifiable Information. Something that uniquely identifies you. So if that data's there, you're in the airport. Let's say you go to SF O here and you put your lap top down and you turn around, and all of a sudden your lap top's gone.

Right? Without protection you now have the potential for that data going anywhere. Being used in various nefarious ways, I guess. So the protection that we have in OS X for this, is File Vault is being one. File Vault is -- many of you should know, we've had several sessions on this as well. Protecting the user's home directory. And Tiger had 128 bit A S, Leopard's bringing 256 built. Just stronger protection, stronger data protection. Making it much harder. And in some cases hopefully impossible, for someone to ever be able to recover your data.

We then, of course, have the portable encrypted containers, or encrypted disc images. Anybody using those? There's some cool features related to that, that I think hopefully either you're aware or we can help you be aware of some of the added advantages to the approach Apple took in providing that encrypted storage rather than physically locking it down to a particular drive or a single entity without giving you the ability to share. So we'll hit on a couple of those I believe.

And of course with Leopard, you've got Time Machine. You're going to have the ability of actually storing that in an encrypted format as well. Secure virtual memory. You should be doing that as well where on that Unix system you're doing a lot of swapping. Right? You're running tons of applications.

System's got to swap that data back and forth. Well, that stuff gets written to a drive just like you storing your physical data. You don't want to expose any of that information physically on this. Anything that can be recovered at a later time. Some folks truly believe that when they erase those files they're gone.

Well, probably every single one of you is in a company that had a drive restored by a company that has good tools to do some very low-level interrogation to do that recovery. Okay. Think of that. If you're got readily available tools and companies to do that, that means that they can get access to your data.

Okay. One thing that I didn't quite mention on a lot of these slides is the fact that when it comes to security, the methods you use, the tools, the expense you go to to protect your data really should reflect the importance of that data or the value, the financial loss, the impact to your personally or corporately, if that data exposed.

If I have a machine that has some, you know, game scores and some information that really is typically irrelevant and just information -- I'm not going to spend a couple hundred thousand bucks to just protect that data right? It has to be relevant, it has to be in direct correlation to the value of that information if it got potentially exposed.

So again, the same kind of tools. The new stuff within Leopard being the fact that you can force File Vault as well on those accounts. Those of you that are familiar with H D I, the Terminal, or managing disc images. Hopefully you're also aware that in Leopard, added a huge feature in giving you the ability of using that two factor authentication smart cards with the unlock of that File Vault. Encrypted home directory. So you would have one of those smart cards. Whether they're in this form factor or kind of a USB download.

Again, we've got a lot of these tools built in locally or on the server side to give you the ability of managing the protection of your data. Encryption. So a couple points that I wanted to bring out related to disc images. Hopefully this is review for most of you, maybe good news for others. That disc utility is where your performance action -- here's one of the newer screen shots. You see that the encryption there is bringing the new level of 256 bit. But with the approach of encrypted images, you can put that encrypted container on any media.

Okay? There's been a lot of folks that ask, well, I found this thumb drive, but there's a driver for it to encrypt it on windows, and I don't have a driver to encrypt it on OS X. Why not? Right? They're looking for third party software to provide that. The nice thing about the encrypted disc images here is you can create a container and store it on any media. Whether it be that thumb drive, whether it be a CD DVD or a network volume.

You could fill that thumb drive with one big image and store everything inside. Take it with you, and now you have protection if ever that thumb drive is lost. You physically lose the data, or hopefully you've got copies. You backed up. Maybe use Time Machine. You can store this data anywhere. So what do we do -- what are some of the added advantages of this approach as well? Well, lots of you create multiple partitions. You probably have at least two or three partitions on your drives.

Well, remember that with the disc images, that image should be viewed as that hard drive. Anything you can do with your hard drive you should be able to do with the image. Partition it. You can have multiple partitions, different data, different disc formatting. But the whole container is all encrypted.

There's a lot of folks who are doing this for partitions -- for instance, years ago there were folks that did this for some Unix apps that required both the data and the application to be on a U F S partition. They didn't have to physically partition their hard drive. But they could do it with disc image. Others are using virtualization software, like parallels and others, and storing that container on one of those images as well.

But there's -- oops. I have I missed a slide. Let me go back. Use this as a guidance for you. But explain one more -- one more approach here. With disc images, the physical file, again like I mentioned, can be stored on any kind of accessible media. So let's use the scenario of storing that file on a file server. Corporate file server, Internet accessible server. You name it. And I am on a -- I am at home, I could be at a hot spot. I could be anywhere. And I need to gain access to some of that data.

What I've now done is given myself the ability to access that data across the Internet, and I've mounted that image on my desktop, just as a volume. All the data that's traversing from that file server to my desktop is now again either 128 bit in Tiger, or all the way up to 256 built in Leopard.

I'm getting blocks of encrypted data that that file server to my local work station. CPU -- local lap top, desk top, you neighboring it. Without any overhead. Without any additional infrastructure, I've now protected my data physically at rest, and in transit. Without any complexity, any more complexity to myself.

All the runtime environments have access to that. So if I'm running job apps, if I am running a local OS X app, if I am running a virtualization, I can have access to that same data when it's available and mounted on my desktop. So there's a lot of value add in using encrypted images for accessing data remotely. So some of the high visibility attacks and compromises and thefts of lap tops that have been around, even lately. Some of the physical ones being like the V A in the government.

It was all because the lap top had the data and they took it with them. And the lap top got stolen. But in that work scenario, or that usage scenario. If that individual would have gone home and even V-PINed in, or gained access in, they could have mounted that data just like I just mentioned, had full access to it, unfettered locally.

The data would have been encrypted, passed back and forth from the file server locally. And yet if someone stole their lap top, the data isn't local. Right? That data was back on that file server. So again, there's some significant valued there. So let me move on again here.

The next is how do you secure the services that you have on your box? Probably the first thing that all of us say -- this is one that Kim and I start out with a lot of folks -- is if you aren't using the service, disable it. Or in many cases just physically remove it.

Don't leave any additional -- we always refer to it as kind of an attack factor. Don't leave something there that potentially exposes you to further attack. Don't leave something on. Something listening. A service file sharing, Web sharing -- something. If you're not using it. The easiest thing you can do is disable it. That's exactly what Apple does when we ship OS X. All those services are turned off. That's the best protection. Always use the as I would say the security enhanced version of a lot of the command line tools.

Many of you should be standard using secure shell. You're doing sessions between hosts. Some folks are still using kind of the old tell net approach. The difference is you're exposing data, you're exposing information. This is standard, easy approach to solving problems. We also have all the service Apples. Right? In Tiger as well, and that further is enhanced in management in Leopard. But this gives the ability of that fine grain control over who gains access. So this is just typical permissions. That's all it comes down to.

Same tools, System Preferences, Server Admin for the management of those services, and then command line. We could go through and step you through how to lock down some of these services. But what we'll show you here towards the end is we've painfully gone through a lot of this work and tried to provide service by service instructions to how to further enhance this in the security guides that we provide out to all of you that are publicly available. We'll talk about that in a bit.

So if you've enabled some services, the best thing for you to do is enable the firewall. Okay? The firewall is one level of protection. It's another layer. And when it comes to security, the best thing for you to do is layer things. Right? You don't just -- you don't want just one level of protection. If you to, as soon as you break through that, you're exposed. You want layers of protection.

Firewall's one of them. So if you enable that for any services, you should enable a firewall. Some of you might remember -- some of you might be using it right now on Tiger, when you enable the firewall you actually have the little stealth mode. Everyone remember that little option for stealth mode? Hopefully you're aware of what that does. And that is that if someone's -- let's take for example Sarah, you're out in that hot spot and stay you're on the a Starbucks, I kind of like Starbucks, so that's where I'd go.

And I have services running on my machine. If someone's kind of doing probing and scanning all the machines in that area they would start finding out what services are running, what potential attack vectors they could use for those various sources. Well, in the stealth mode, it's just not going to respond to those probing tests, or the scanning for various tools.

It would not acknowledge the fact that that service really was running there. And then in Leopard, there's a brand new method of enabling the protection when it comes to services application acre session within Leopard. Kind of limiting the Internet connection, the incoming connections and out going connections in Leopard in the firewall.

Okay. System preference, severer Admin, and Terminal. Again, I keep bringing several of these up so you're aware of what tools you have available from Apple to enable and manage a lot of these services. Okay. So you've got all the set up. You started out secure. You kind of fortified a little bit, your hardware. You started out fresh. And then a week from now somebody identified a problem.

The first thing you did is well, you said well, there's an attack. I am not going to worry about that. Security is not going to hit me. Well, you have to vigilant all the time. Regardless of whether it's an operating system or an application, or maybe just a small tool that maybe you used. You need to be constantly vigilant in protection, and getting patches to those services. So first of all, if Apple's gives you that there's a notification that there's a patch out for something that's been identified, heed that warning.

Right? Corresponding Apple security patch. We provide those to you. Use them. The biggest problem that folks have on various platforms is the simple fact that people aren't up dating their systems. There's an available patch. People just don't do it. These are simple things that people can do to protect themselves better.

Maintain vigilance is what I mentioned. And other things, particularly since most of you are getting more and more into pulling in open source projects that aren't already shipped in OS X. When you're getting to additional open source projects, be very vigilant in what updates they may have. Because remember, we test and we provide those updates for the open source projects that they ship on the OS. But we're not providing it for that third -- third party or that additional open source program that maybe you pulled from somewhere else. So that's an area that you need to be especially vigilant.

Remote desktop is an additional one here. And that is the ability for you to go out and push and maintain those remote systems. Remote desktop is an awesome tool to give you that additional capabilities and -- with the -- able -- with the ability to do Unix commands within remote desktop you literally can do anything that you need to do on each one of those clients or hosts.

So the other thing related to software update is that many folks may or may not may have their own software update server internal. You may be running Mac OS X server with a software severer inside your agency. But in many cases you don't want the end users to arbitrary get an update, maybe even from us, without being able to test it yourself. You may have additional applications. You may have additional special configuration.

This is -- this is less so on the security side, but more so on the stability. And yet stability can lead to problems on a security side. So it may just be the fact that a new update conflicts with something that you've already got on there. So one of the things that many folks do is physically redirect that client -- you can do this manually, or obviously through of the tools here. Is redirect it to another server. The nice thing about the client is you can redirect this to a server that that client may never get to. Right? But it's going to silently fail under the hood. That client, that CPU, that lap top, whatever the people have.

They're never going to be going out and getting an update. So you can have better control of that in making sure that only you the Admin and only you the policy enforcer in your environment are able to apply those updates that you've validated yourself. So one of the default settings on that rather than kind of my server dot company dot com, would be the software update dot com. That's where each one of those systems is pointed to originally in getting software up dates from Apple.

Okay. The next thing is we've done all this work, we've maintained our updates. But how do we know if what we have in our system is what we should still have in our system. Right? So this is kind of validating the integrity. And to know what you've had on your system that nothing is changed, the first thing is you've got a baseline. You have to know physically what was on there before.

You have to have a method to say, these are the ten applications I've had, or I had previously on my machine. And nothing has changed. Just previous sessions dealing with code signing. And that was a way of making sure that that app hadn't been changed. That's one method. There are other methods of knowing and ensuring the integrity of the applications, the integrity of files, physically, on your machine.

Snap shotting, kind of that concept. Doing comparisons. A lot of folks will be doing and using tools comparing hashes of binaries. Like, there's all kinds of ways of doing this. And if you have a questionable system, if the user has a system that is -- appear to have been potentially compromised. Appears to have had some altered services -- one of the easiest thing is to do really a quick comparison to your baseline system to ensure for yourself that you have -- you truly have a system that you can rely on. That you're validating the integrity.

Auditing. Remember that lots of your applications log information. You can even enable more log in capabilities from within applications or services. That's one method. That's the application telling the system what happened or what transpired. Auditing goes further than that. Auditing is -- think of auditing as a view from the outside saying what happened that may not have been reported by the application. Right? Kind of the environment.

So OS X has auditing built in ESM. So if you do kind of the single user boot you will actually see ESM enabled. Built into OS X. But this is where I want to take this opportunity to help many of you understand how you can leverage that auditing capabilities built into the OS. Because probably many of you weren't aware of that.

Right? How many of you are using the auditing services in OS X? Probably about ten of you? Okay. So within OS X, it's somewhat hidden. We did a really good job, I guess, of hiding it from you. Part of our certification of OS X, and this goes back to the 10.3 days, is related so a world wide standard for certification of independently validating products on the common side. Or referred to as Common Criteria. Associated with that is when we provided the auditing services.

And if you go to any of the Apple Web sites and you do a search on Common Criteria you will see several references, and one of them's kind of the portal to all of the related documents. And here I talk about the CC tools, or the Common Criteria tools.

That's really the auditing, the additional auditing services that give you that ability of modifying the auditable events, changes what it is you want to know about that's happened on this environment. And the ability to actually look at the physical logs themselves, physical audit logs. And CC tools, they're available out there for the PowerPC systems.

And when we shifted from PowerPC over to Intel, remember the certification there was on 10.3.6, we've shifted to Intel. So if you are in an environment and you need to use auditing tools on Intel, that might be some of you that talked to me afterwards. We can help you out on that side.

But the audit log viewer is a GUI version to allow you to view the logs and of course the tools give you the actual ability at the command line to display the audit records, display the whole audit log file itself. Or even to reduce them. To physically only look at certain events.

Maybe you want to see how many times somebody has failed to authenticate at log in. Failed to access a particular service, or who has attempted to gain access to an object or a file that they did not have the authorization for. All these kinds of events, these are auditable events. Not kind of a system log. But your auditable events.

And this final one, many folks have the need within their organization or it's become their policy that in addition to doing all this work, they have to be sure that the people using that machine are notified, that if they use that machine they're being monitored. What transpires if they do nefarious things to that machine. So notifications, even though it seems somewhat of a standard configuration change, it really is one of the key changes that you can and should do, related to security. Because many times there have been event last where folks have attempted to protect systems, people have compromised them.

And ironically due to the fact that it's not specifically notified to that user, even though they're attacking, specifically notified that this is a government or corporately owned machine, an all the legalese there. That that gets into issues on the legal side as to whether they were properly notified. You don't want to get into that situation.

And on the notifications, many of you have probably been doing modifications to the log in window P-list, right? Yes? No? Nobody? Am I talking to the right people? Many of you have been doing the log in window P-list. You've been modifying the little nib file and changing it.

And sometimes it looks good, sometimes it doesn't. That's the typical method you've been using over the years. There's actually some good -- a good resource, and many of us have been chatting about this before and that is -- and I'm trying to remember when it was actually shipped on one of the DVDs -- developer DVDs. But some of you should be familiar with off plug-ins. Right? When you go to authenticate, you know, like, say when you did the log in window.

The off plug-ins is what is enforcing how that is displayed, and what are the mechanisms behind that. And one of the off plug-ins that was even on the developer DVD a while back was referred to as a banner sample This is -- was already out there in your hands. So you might not have known it.

This really is a perfect way that you can create your own corporate or organizational banner, the notification, that you can push out to all those machines. It's an off plug-in, right? You dump it into the directory for the off plug-ins and all you do is add that to the first line of the authentication mechanisms in system dot log in dot console. If you just want this to be in the log in window.

There's already a sample there and it shows you what you can do with it. Set it up, put it out to your machines. The key here is that you no longer are modifying the operating system to do this notification. Again, trying to help you out with definitely meeting the legal needs to this side as well.

Of course you're going to do Xcode off plug-in, you're going to hit the Terminal. So hopefully at least what I've walked you through gives yu a little bit better idea on what steps that every single -- I truly believe every single one in this room should be able to do in mitigating the risks on their machines in whatever environment, he ever kind of attack environment you are in, either now or later, those incremental steps.

Of course we do a great job of a default configuration. But everybody's environment changes. Everybody's system changes. You have different apps, different tools that you use. So you start protected, you maintain that good protection throughout, doing the updates, being vigilant on open source projects that you've added as well. Making sure that you know for sure what's on your system.

Baseline. And then kind of that notification in the end. So for my part of this piece, you should take this as a take away that you should feel confident you don't need your IT staff to tell you how to do this. You should be able to walk out and ensure that your system is better fortified So I will welcome Kimberly Cummings from NSA, but we do a lot of collaboration on various approaches, various tasks.

And one of those pieces of collaboration was on providing the security guides for all of you, and helping you in somewhat of an exhaustive way walk through the services, walk through of the steps of how to take each one of these areas of your system and better enhance the protection in various attack environments of the so at this point, I will turn it over to Kim.

Thanks Sean.

I'm looking out here and I thought nobody was interested in security, Sean? I thought I was going be talking to ten people! Maybe I should make you do my slides. Well, okay. As Sean said I am Kim Cummings, I work for the System and Network Analysis Center at National Security Agency.

And I am going to talk to you today a little bit about -- well, what I want to start out talking to you about is just a little background about the security guides and how we got where we are today with those. And then I am going to talk to you a little bit about kind of our -- perspective.

Our psychology on security. And give you an idea of how you should kind of think about security to look at your systems and your security and really how you should think about it to secure your systems and look at your systems to make sure you know what you're doing with your security.

So first of all, with the configuration guides, one of the functions of the Mac center over the last several years is to develop security configuration guidance for computer operating systems, hardware, and applications for the defense community. Before we were writing security guidance we had begun noticing that when customer requests came in, most of them had the same questions over and over again. And most of them were making the same configuration mistakes in their systems and networks.

At the same time, we realized that as a result of the analysis we do, we frequently had questions about how the system should be configured. But we didn't have any practical way of getting that information out to our customers, and this ended up resulting in our first configuration guides.

So when we first began this process, the guidance was all researched, developed, and maintained by NSA within our center. We began with a single product, and because of the success of the guidance for that, the request for our services for other products came in. Eventually, with trying to develop new guides as new requests came in and maintain guides that we had already developed, and develop new versions of the guides we already had, we realized this job was just overwhelming. And we also realized that vendors themselves could do a much more efficient job of keeping the guides current.

The only difficulty was making sure the level of security in the guides was at the level that we considered to be sufficient for our customers. So we started approaching some of these vendors to develop relationships with them for working on the guides. NSA asked that these vendors work with us to develop the next versions of the guides, and we agreed to assist them as much as possible. And with -- we had the vendor ultimately develop -- publish the guides.

This ended up with having NSA vendor collaborations. We would have NSA remain involved by providing reviews, comments, suggestions, and we do all this in order to ensure that our guidance -- or that the guidance they provided was secure enough to be used by our customers, but that the vendors would be the runs providing it.

Any place where the NSA and the vendors couldn't reach a consensus on what was going to go in the guide, the vendor could publish what they wanted, and then NSA could then put out an addendum out on our site so that any differences -- we could tell our customers what we wanted them to do.

All of these guides can be found out on the NSA dot gov site under the Information Security page. We have a number of different guides out there, including guides for Panther and Tiger. And the Tiger guides are the ones developed by Apple. And NSA has not put out any addendums for them We were able to come to agreement on everything.

okay. Now I'm going to talk a little bit kind of about your philosophy for securing a system.

First of all, kind of -- just the major factors of a secure system, which as you can see, user education, system monitoring, system patching, and system configuration. And of course what we're talking about is system configuration. The others are all important, but that's really the largest factor in making and keep a system and a network secure.

There we go. System configuration not only plays a huge role in keeping systems secure, but it's really difficult, because the system's always changing. Someone always has a new requirement for the system, a new machine to add to the network, something breaks and has to be replaced. Software up dates come in, users want new software, or they just want different software, or access to something that they don't have access to. The systems need patched.

Am I forgetting anything? Am I forgetting a lot of things? And none of that even addresses vulnerabilities in the system. We all know holes are found all the time. And that's part of the reason that patches are needed. But these holes don't suddenly appear. They were there long before they were ever found, and an attacker could have been using them before they were publicly disclosed. And the hardest part about all of this is that those of us protecting the systems have to worry about blocking every single hole. Because we don't know which one is the one that will be used. And of course, the attacker only has to find one of them.

So first I'm going to give you some examples of some poor security. And first of all Sean talked about having multilayer security. Poor security is having single layer security. You rely on just your passwords, you rely on just a firewall, something like that. By providing only a single layer of security you give only a single point for an attacker to break into your system.

Layered security, having a firewall, requiring passwords, bio metrics, smart cards or all three, configuring systems in network securely, removing any services not needed on the network and other such cautions provide multiple blocks against an attacker's efforts. It's unlikely that one layer will be completely impervious, but by overlapping multiple layers it becomes less likely that an attacker will find its way through all the layers of security.

Then there's poor system hygiene. If you don't delete old, unused, and outdated software, services, and users. When the software services or users that are no longer being used remain on the system, they become targets for attackers. Old software and services are no longer being patched and they may have vulnerabilities that can be exploited by an attacker to elevate privileges on the system.

An unused user account is also a target for an attacker. It's an account that can be used by an attacker with which his intrusion is less likely to be noticed as Sean talked about, not keeping good separation of administrator and regular user accounts. I know we talked about this a little, but I am going to pound on it just a little more.

I saw that quite a few of you do use just your administrator account, right? Uh huh. I've been guilty of that on my home system. I was until recently. And when -- actually in the process of doing the guides I realized that that really wasn't a good idea. Because you know, you're sitting there, and you're using your administrator account, and then you decide, oh I need to go look something up. And you use the Web browser. And tell me, where are the most -- most recent vulnerabilities in the system found? Yeah. Well, Windows. Okay, okay.

But in -- when you see vulnerabilities come out under OS X, where are they usually located? Web browsers. You go look at something and you're an administrator, and you're using your Web browser. And that's actually for any of the systems. A lot of the vulnerabilities are up in the Web browsers.

You -- and that's just one reason not to be an administrator. You forget that you're an administrator and you accidentally go do something and erase something that you shouldn't have. There's just so many reasons not to do it. I can't stress that enough. It's one of the biggest things you shouldn't be doing. Another thing, not limiting your remote access.

Often those configuring a system will assume that setting up some form of authentication such as SSH for remote access is enough. But opening any remote access to a system is an invitation to attackers. To help provide layered security that access should always be further limited. That can be done through the firewall. Using the example of SSH, it can also be done by configuring SSH to limit which users can use SSH. And disabling root SSH log ins.

And then passwords. I know Sean talked about that some too. But -- I'm going to talk about that a little bit. Let's face it. Passwords are a problem. Users hate them, attackers break them. Administrators hate them because users forget them. What do we do? Smart cards are out there.

Bio metrics are out there. Some of them work and some of them don't. There's a lot of different manufacturers and some places -- some companies have trouble moving over. A lot of places still seem to be stuck with passwords. A lot of places are just stuck for them for now. As long as we have to deal with them, we have to have a policy to deal with them securely.

The mistakes some make are not putting policies on passwords at all. Or not putting strong enough policies. No minimum length, no password aging, no password history -- no requirement for special characters or numbers in the password -- things like that. Make sure you put some policies on your passwords that make them strong. You want users to be able to remember them so they're not writing them down.

But you've still got to make is so that they can't put dog for their password either. You know? So you need to do a few things like that too. Let's talk a little bit about what an attacker can do. This is just a very short list. But it gives you a few examples. First one. Steal cycles. This one, okay, it can cost businesses money because it slows down the systems. But if that's all an attacker does to you, you've gotten really lucky. Crashing the system.

That's what people tend to worry about the most. Virus coming in and attacking the system and wiping it, and causes everything to be lost. Makes the system unusable. An attacker coming in and trashing the system. Yeah, this can cause a lot of damage and cost a lot. But it can actually be a lot less damaging than the next two on the list. Number three. Stealing data. An attacker can come in and read what's on your system. And quote unquote, steal the data.

You might not even know what on the system he's accessed. But if you know an attacker's been there, you can probably assume that every single thing on the system, or at least everything on the system that wasn't encrypted was compromised. So if you have any company secrets, the attacker now knows them if it wasn't encrypted. Next is stealing identity. An attacker might infiltrate a system to use it to get into other systems that give access to the system being compromised.

Once a system has been compromised, any trust relationships that system had have also been compromised. An attacker will bounce through any number of systems to get to the system in which he's really interested. So he might not be breaking into your system to get to your system. He might be breaking into your system to get to another system five systems over. Might be just bouncing through to get to the system that's really important. Or he might be bouncing through five systems to get to yours.

And finally, he could be coming in hide time bombs or back doors. There might not be any indication that anything on your system has been compromised at all. It might appear that he didn't do everything, and you might not even be sure anybody has even been there. An attacker can hide code on a machine that will execute at a later time to give him access, ship him data, destroy the machine, or just cause annoying problems. He might also make changes somewhere in the system that will either give him an account he can access or open up a known vulnerability in the system he can later exploit.

Okay. Now, I'm going to move on a little bit to guide development. What goes into developing a security configuration guide? Well, the amount of data that we consider for this can be overwhelming. The list here's kind of long. And these are just general overall categories. As we start breaking out each area and we're working on -- when we're working on a specific product the list keeps growing.

Okay. So some general principals about your -- these are just general principals you need to think about when you're using a guide and when you're trying to figure out how you want to secure your system. The first principal you need to think about is separation of function. You really want to try and put different functions on different servers.

It's especially important to have a separate firewall providing an in between -- you know, have a separate firewall between outside networks and your internal network. E-mail and Web servers should be on separate machines from any other servers whenever possible. The user database should reside on its own server whenever possible.

Having these services reside separately means that if someone should compromise one weaker service he won't necessarily be able to compromise your entire network. Having good separation between the services by putting them on separate servers and having good, strong authentication required between the services adds yet another layer of security. Separation of rights. Having separate Admin and user accounts. Just pounding on it a little bit again, I know. Encrypting wherever possible, even locally. Encryption provides yet another layer of security, and no remote log in should ever be done without some sort of encryption.

And then minimize -- as Sean had talked about, minimizing services, especially network services. Any services that are not absolutely needed should be stopped on the system. That's also true of any unused code in the system. And this one's more for developers. If you're developing code and you have code that turns out you're not using, you know, you've changed the code, you've got unused code. Don't just leave it in there. Take it out.

Clean up your code. It helps. Another case, even though it's not exactly a service, is IPV-6. IPV-6 is currently started automatically in the system. But a lot of people have not switched over to IPV-6 addresses yet. And if you haven't, you should disable IPV-6 on your systems. Because any unused services or code in a system that are active are potential windows for an attacker.

Also, kernel extensions. You should remove unnecessary or unwanted kernel extensions. They can provide an attacker a window, and this can also be a good place to remove capabilities from the system. Such as the ability to use USB flash drives. If you have a requirement in your organization that people not be able to have flash drives, that's a place where you can remove that capability.

The thing you need to remember is that kernel extensions might be restored any time of the system is updated. So if you have used that capability -- that way to remove these capabilities, then any time you do a system update you need to also remove those kernel extensions again.

Kind of a corollary to this is in the guide we use this way to remove things like Bluetooth and Airport and things like that. If -- any of those things that -- if that's not sufficient enough for you, you might need to remove them in the hardware, or the microphone. If having a microphone in your system is a security risk in your area, you might have to remove it in the hardware. You might have to find a service provider that there are service providers out there that have specialized in doing that.

And you might have to go and have that hardware removed or become a -- an Apple authorized technician and actually remove the hardware. There are a number of ways you can do these things. Those are for extremely secure areas, of course. Most people don't have to go that far. But those are possibilities too.

Another thing with these guides is when we create them, we always -- we tend to do them with the idea of making them as locked down security-wise as possible and still have the system be useable for some guides, as they've evolved, they developed into providing different levels of security in them. Generally, however, our philosophy is that if we provide the most locked down mode possible in the guide, the users of the guide can determine what risks they're willing to live with and then loosen up the configuration from there.

So because we do try to make the system as locked down as possible, we also try to explain the implications of each setting. What it will break if you do set it, what risks you'll -- you'll take -- take if you don't set it. For the most basic settings that should always be used, we don't always do this.

But for services where some sites may want to use them and some may not or for other such settings, this allows the users of the guides to determine whether or not the risk of using a feature is worth it. And we also try to put in step by step instructions for everything to make sure how sure -- how all the configurations are done is completely clear to everyone, no matter what the experience of the user is.

Okay. And then I just have a few best practices for you. And this is kind of an idea about how to use the guide. And this sounds simple, but it isn't always. And this is a list -- you know, determine what you have. What level of security you want. What level of services you need.

And then you take the guide and then you customize it to fit your particular circumstances. First of all, your current architecture may be completely wrong. So weir (Phonetic) management allow you to tear it completely down and start from scratch. I'm guessing in most cases no. If not, what will you be able to do? You know, Sean recommended completely reloading your machine.

Completely reloading a machine may be somewhat realistic. But completely tearing down your whole network and redesigning from scratch what your entire network is going to look like probably isn't it a lot of cases. So you're going to have to try and figure out what you can do realistically without upsetting the network too much and upsetting your bosses too much. So you have to figure out what your current architecture is. What you have, and how you're going to be able to fit it into your security plan.

Best, of course, is always to reload and start from zero. Scratch the whole network and start from scratch. But as I said, that's frequently not very realistic. You also need to figure out what your risk is, what the threat is, and what you're trying to protect against. Are you a non-profit with very little risk? If so, you might not be as worried about shutting down services, then. If your company is a research and development company that may have competitors looking to steal company secrets, you're going to want to protect against outside threats, and you will have some concern about inside threats as well.

If the projects are short term projects that go to market quickly, you wouldn't have as much concern as the firm that has long term projects that stretch out over many years. Since the security breech would not hit you as hard as it would a long term research company. Financial institutions, generally, need to protect their systems very heavily.

And of course the level of services you have is effected by the level of security you need. The higher your level of security, the fewer services you can, or at least should have. The thing to remember is that every service you allow, every privilege you open up, every trust you allow, makes it easier for someone to break into your system. And once you have a grasp of the different factors of your system, your network or your enterprise, then you can use the guide to come up with your own customized security configuration guide.

And finally, don't forget. User policies and administrator policy. Policies for how machines will be kept up-to-date, overall security policies, and policies for how security incidents will be handled, policies for reviewing the logs, you're going to need policies for how to handle all of your security. That needs to be put into place.

User education. Even though people have gotten a lot more security conscious, most users still don't know a lot about security basics. It might be worthwhile to give users some security pointers, or at least point them to some sort of security primer for users. And securing a system or network is never a one-time effort.

Keeping all of the patches updated, keeping all of the security matched up with any changes in the systems and any time works, responding to any attacks to the systems, or responding to newly found vulnerabilities and other such changes requiring security updates means that the work to keep your systems and network secure is never done. And with that, I'm going hand it back over to Sean.

First of all, we both mentioned the guides that we jointly collaborated on. The 10.3 guides were formerly developed by NSA and we worked closely to contribute to that. The 10.4 guides is when we as a vendor took that upon ourselves. We developed those guides with the feed back and the validation from the NSA guide -- from NSA -- so whether you want to get these from our site, from the server documentation location, or from the NSA dot gov SNAC sites. It's the same document, 10.4 mirrored on both places.

There is additional security services, resources I wanted you all to be aware of. Just kind of the security overview at Apple, Apple security overview at Apple dot com slash security. Product security, which covers many things. Kind of the action for notices, the action for providing software update. So the Apple security updates post each one, correspond changes that have been done or provided. And the corresponding CDEs in those up dates.

And all of you, or all of the IT folks actually implementing and deploying a lot of these systems should definitely be leveraging Apple's security training and certification process in this as well. And additional external resource at NIST, National Institute of Standard Technology, is another form of guidance on product security checklists.

There you will find references to Mac OS X, and all of these are really in the process of merging together. So in years to come, whether it be in combining all of them with NSA and NIST and DISSA and Apple. All of these will be merging into a single document in the future. But until now, you have additional resources.

So with that said, if you are enterprise customers, typically you would be dealing directly with me. If you're developers, deal directly within your -- on the developer relations side of the house. And those of you that need to get into some auditing on the Intel side, you can talk to me off line.

Since we're very short on time, we aren't going to be able to do Q and A here. But hopefully we gave you the ability of truly understanding the purpose of system hardening, better understanding what you can do right now, what you can do ongoing in protecting yourself in the changing environments that your systems are in with those top ten steps. And we've given you some excellent resources to provide to ongoing guidance.