Okay, so we gotta take a poll here. We gotta start with a poll. How many people are from government? So this is spot the Fed. No. How many people are from kind of commercial? Okay, how many people are education? Now, some of you held your hand up twice.

Are you not sure? There's a little schizophrenia going on here. Okay. Those, okay, so maybe I'll ask one last question. How many of you were here for this same kind of similar session last year? Okay, hopefully you'll still get some value. What we're trying to do is kind of give you some high-level guidance, give you some lower-level thinking.

We'll be talking about kind of critical thinking of security. But most of all, this comes back to the security guidance that we do really within our documents. And we'll hit on this a little bit later, but hopefully you're all aware that for both Leopard Client and Leopard Server, the security guides that we do collaboratively with several of the agencies hit the street back in the beginning of June.

So again, in this session, Help Set Expectations, is we want to help you better understand how you can do a little bit of system hardening. Some folks say, well, OS X is secure, right? Well, when you're changing environments, maybe go to some hotspots, you may be going into some more where security requirements are at a higher level.

What do you do? What do you need to figure out what services to modify or to manage? So that's kind of where this guidance of this session is going. We want to introduce you to some of the tools, and of course, at the very end, we want to be sure that you have the right resources, the right references to get this guidance on a regular basis.

So that's what we're going to do today. So hopefully, we're going to help you better understand how to do that hardening in your environment, and I want to emphasize your environment, because every environment that you're running, the laptops, desktops, handhelds, the iPhones, each environment that you're in, has a different kind of attack vector, a different kind of attack environment, right? You need services, maybe when you're on a laptop in a hotspot, you need Wi-Fi that you may not need when you're inside of your own agency. So these are all considerations that you need to understand when you're kind of doing that fortification in your environment.

We want to help you with kind of some of those steps of what you can do to mitigate some risk. Kim from NSA will be helping you. She's going to walk through some thinking about how to think critically about security when you're thinking of this fortification, and again, ongoing guidance.

Okay, kind of like what we did last year, for those of you who are new to this, or you just kind of need a refresher, what do we really mean by system hardening? Well, really, it's taking the steps to eliminate or minimize a lot of the security risks, or minimize it as much as possible, right? Again, you always need to leverage services, so you're trying to take as many steps or the appropriate steps to reduce any kind of risk, but still maintain that functionality.

And one of the areas I kind of wanted to hit on on my part of this is that predominantly with the laptop environment and with handhelds, portables, phones, it's really become a very mobile landscape here with data, right? We're all kind of moving around with a lot of our portable devices, and we're all kind of moving around with a lot of our portable devices, it's not the same as it was several years ago.

Very few folks had so many laptops that carried around so much sensitive data. And now all of that sensitive data, whether it's our corporate information, whether it's national information or whatever, it's walking, right? It's leaving the doors, it's going out on devices, and so this becomes a sensitive issue, things that we need to protect.

So now you think of this mobility, probably every one of you have heard of so many situations that have raised awareness. And so I kept on a couple government-related issues. When you think of facilities that have so many laptops, thousands and thousands of laptops, things walk out the door, you don't have good protection on this, and they get into environments where things are exposed.

These are concerns with this change of landscape that now has raised awareness, kind of triggered the thinking, in some cases triggered a lot of policy related to that. But most of all, it has given us two reasons for taking a closer look at what we can do or what we should do with our systems. So at least in my part here, I want to focus a little bit on how can you take some minor, very simple modifications on your systems in improving things from a portable computing standpoint.

Some of these points, those of you who were here last time, I kind of carried some of the points forward because these are just points that just can't be emphasized enough. First is, a lot of the Wi-Fi access or just communication, any kind of security guidance that you receive from anybody, one of the first things that we all say is, if you're not using the service, turn it off.

That's kind of a simple thing, but it's easily forgotten because you might be enabling Wi-Fi for a hotspot, you might be enabling Bluetooth for some other device, and you move about. We're in a hurry, we're constantly running from one thing to another, but yet that's a typical form of learning new information about people's machines, a new way of attacking. So one of the first things you can do, item number one is, turn things off when you're not using them. All these ports for Wi-Fi, Bluetooth, you name it.

And particularly when you're doing discoverable, right? If you're discovering or enabling your system for discoverability, whether it's your phone or your laptops, it's just one more reason that folks have, or one more capability folks have of learning what kind of device you have, what kind of system you may have that they can attack with through various means.

So on each one of these, I want to kind of bring up, why would you take this approach, or why are you using these kinds of steps to mitigate these risks? And one is, in this case, we're just going to reduce... this attack, right? We're going to reduce what any kind of malicious individuals or organizations or services can actually attack us. We're going to reduce that down to the bare minimum that we actually have to use right now. In this case, it may just be a Wi-Fi access.

So what are the tools that Apple provides in our products to help you with this? Well, first of all, if you are being centrally managed and you're doing this from a Mac OS X server, you'll notice that you can fully manage those ports and do that disablement on a given system for users.

So you could enforce this by policy on behalf of that user that may forget or, again, you may require this. So second of all, if you're doing the one-to-one deployments, of course, you can physically disable those interfaces as well. Lock this down and require administrative or additional authentication mechanisms to modify that and re-enable it.

So you can do that by using the kernel extension. Many of you might be in environments where you've got to go to the lowest level, and that is you may physically need to remove some of the kernel extensions to just, through software, disable those services, right? Anytime you're doing modifications, whether it's network setup or whether you're using terminal to physically remove kernel extensions for disabling ports, always remember that anytime we do an update, right, if you're removing kernel extensions or something, that they might be reapplied. So be aware of the ramifications of updates to your systems with respect to the type of approach or the type of management you're doing here. Another point I brought up last year was about baselining your system.

It's amazing how many folks, when you ask them, they say, "Something's happened to my machine," and you may ask them, "Well, how do you know?" "Well, I think something's changed," right? You always want to be sure that you have leveraged a server or a service or a capability that you can truly baseline what your system should have or does have as kind of the approved or configuration of your system. And there's a lot of reasons why you want to do this.

First of all, again, is how else are you going to know that something's changed? You want to be sure that you can ensure what's right, and how do you ensure that? Many of the cases, many of the tools that folks are using are tools that, generally, do potentially hashes of applications. It may do the validation of signed apps within OS X, within Leopard at this point.

There's a lot of the open-source tools and referencing for scanning to be sure that it's the same services, the same file system is there, same files, same environment, same configuration. And there's several organizations that, surprisingly, are using a combination of some of these tools. So they may be doing some scripting themselves, tying that back into remote desktop, and kind of pushing those out, other scripts out to run on each one of their desktop or laptop environments.

Another area that we've provided services that you can leverage, and not everyone always knows about these, so we always want to bring about awareness, is that BSM, or Basic Security Module, was ported over from Sun onto OS X. So you have the ability of doing the additional security auditing on OS X.

And what we mean by this is you're quite familiar with the system log and what applications and the OS logs as activity, but you can go further into defining and configuring what additional security relevant events are that you want to capture. And so the auditing services are there.

Some of you might be familiar with some of the turmoil that has happened throughout the different versions of the OS. There were some transition periods, 10.4 on Intel, where it wasn't readily available. 10.5 auditing tools are available publicly for all 10.5 systems now, so you're all back to snuff on that.

This gives you the ability of capturing and, in many cases, most folks, most of you are probably aggregating these security audit logs on a central server or in a data center for reporting, in many cases, this is by policy, organizationally by policy at a later time, so that you can prove what did or did not happen on a system.

So let's go forward. This is something that many folks should be doing, more so than they are, and that is we talked about all these laptops, this mobile data, this landscape change where a lot of our data is going around on mobile devices, the leveraging of the built-in FileVault. How many people are leveraging FileVault? How many? Some of you.

Okay. Well, we've got FileVault there, and hopefully you're aware that with Leopard Server, you can additionally force that by policy on those accounts. We did a security discussion on the East Coast just this other week, and the awareness of being able to force FileVault onto all the portable devices was kind of a new thing to many of them, that they could now force all of their mobile devices on their devices. So we're going to be working with the local workforce to have FileVault running for their accounts, or FileVault containers for their account on their portable devices.

Then with the extension of encrypted containers, portable encrypted containers on external drives, just about every one of us have received all the chachkas, all the little thumb drives from just about every conference we've gone to, a couple gig drives here that typically are just used for exchanging data. Sometimes we've been able to do that.

We've been able to do that. We've been able to do that. And we put sensitive information on there. The best thing is put an encrypted container on there using disk utility, dump in an encrypted container. That way every time we write data to and from that, we're protecting all of it.

Again, why are we doing this? To protect or prevent the exposure of our data. And many times that can cost each one of us a lot. In many cases, from some of the companies, when data gets exposed, it's corporate IP. It could mean loss. In some cases, it could mean loss of millions of dollars just with information. For many of us, it could mean loss of our jobs, again, with the type of information that gets out.

So with FileVault and the disk images, always be aware now that you can -- the upgrade with Leopard gives you the 256-bit encryption now. If you're using things like FileVault, it's on the fly. You kind of set and forget. In many cases, it's a situation where most users, if they have to deal with trying to figure out whether they're going to encrypt, they're going to do it. If they have to deal with trying to figure out whether they're going to encrypt the data or not, probably not a good thing because most likely they're going to forget because we're all in a hurry.

So when you're thinking of FileVault, fully encrypts their user account, set and forget. If you're using encrypted disk images, it's also the capability of carrying that data across the network that becomes quite helpful. And I'll share this in a second because the encrypted disk image is something that carries across all storage devices that you use.

This is an environment that, within OS X, using the same technology on all of your storage devices. So whether this is your CDs, DVDs, thumb drives, USB, FireWire, whatever it is, if you can access it as storage, as media, then you can put these encrypted containers on here.

Then again, with the Leopard brings a 256 bit. Well, one of the areas that has really been helpful for folks is the fact that these containers can then also be partitioned, right? Consider that encrypted container, do the same thing with it that you would do with a hard drive.

You can partition it, have various disk formats in each one of those. A lot of folks are doing that for maybe creating a FAT32 disk formatted partition and use that with Parallels or VMware for storage of their content, their additional data, additional apps, while it's part of that full encrypted container.

And the area here which really is helpful to a lot of folks and they haven't been aware of it is this same encrypted technology gives you the ability of storing that data on a file server and accessing it remotely on your laptop and accessing that as a block device. So you now have blocks of either 128 or... or 256 bit encrypted data traversing that network.

So it now means that remotely I can have access to massive amounts of data that's encrypted at rest on the server and I may have a very low bandwidth connection, but I have full access to that data on my mobile device, right? So I'm no longer relying on a sole solution of carrying all my data with me on my laptop and being concerned about having that data physically on the drive and if it gets stolen. So now during use of that data, I have access to it across the network.

That's been quite helpful to a lot of folks. Things that are near and dear to my heart, and many folks in the audience as well, particularly if you're in the government space, is the shifting and using of two-factor authentication, predominantly in a smart card space. This is where no longer do you deal with the typical weaknesses of all of us in passwords, either the weakness of a password or just human nature that if we have to keep changing passwords, it becomes reduced entropy in the difference of our passwords.

So between that and the ability of now with all kinds of resources and super computer capabilities, even on our own systems, is the ability to crack passwords if you're trying to protect things just with passwords alone. Moving to a two-factor authentication, solutions like smart cards, give you a significant protection, really with reduced or limited complexity. for systems.

I want to take the smart card piece just a little bit further for some of you, because this happens to be particularly in the customers that I deal with in the enterprise space. They weren't aware of all the capabilities that we have integrated in with smart cards. Here you'll notice about biometrics and one-time passwords, cryptocard and secure ID.

Ty those two together with the smart cards and the key thing is that we're trying to give you multiple forms of strong authentication built on the platform that you can tie into whatever directory service that you have on the back end. As I just mentioned, I want to highlight the smart card piece here real quick.

And that is with the integration work that we've done, you can now leverage that single form of two-factor authentication, that smart card, for obviously logging into your system, for system administration, the unlocking of screen saver, typical, sign encrypting of email, VPN, you've got secure web access, and even the unlocking of key chain.

With Leopard came the unlocking of FileVault with those smart cards. And this doesn't require heavy infrastructure on the back end. This could actually enable many of you with one-to-one deployment with your own laptop to do that two-factor authentication with a smart card directly on your local workstation, requiring the infrastructure on the back end.

Now, going forward with other things here. As I mentioned, there's always certain things that any kind of security individual would suggest folks do, and that is securing services. Anytime you're enabling a service, you always want to leverage the more secure version, and if you're not using that service, disable it, just kind of like I said about the interfaces.

We always note within OS X that we definitely don't want customers to be using the insecure versions of things like Telnet and others. That's why we, by default, use SSH, right? That's the way it's configured in OS X. SSH, secure copy, secure remove for securely erasing data. So again, if you aren't using the service, disable it.

Some organizations will go as far as to physically remove that service off the box. Because if it's a... If it's still there, and it's... Even if it's just installed and not enabled, if there's a compromise or a vulnerability in another service, it does allow for the potential kind of hopping between services or capabilities on the box.

And that is, you leverage a vulnerability in one, if the service is still available or the executables are there, there is a potential for leveraging that in a form of attack. So again, these are all types of ways that you can better avoid these kinds of risks. Typical tools, we always kind of highlight this again, is what you can use to control that. Now, we get into firewalls.

By default, you've got all your services turned off and there's really nothing sitting there listening to any kind of a request for a service. But once you do enable services on OS X, the best thing to do is start enabling and configuring that firewall for that protection. You always want to put up yet another barrier to attack.

Blocking those services and the little image you're seeing there is the new application-based firewall that's built in OS X. It was our ongoing effort to simplify the complexities of firewall for the average user. I still am amazed at how many times we're in conversations, even in very large organizations, where there are so many challenges to folks understanding complexities of firewalls.

And that's just the case, right? It's so complex. But yet we're expecting as IT folks for our users, our end users, to protect themselves It's either going to be done by policy, by you all enforcement, but Apple takes the extra effort to simplify the process for kind of the rest of us.

Now, keep in mind that when we did on Leopard, we brought the application-based firewall, so you're doing that leveraging through system preferences. And on Leopard, we still have IPFW on the client, so many of you were looking at kind of larger-scale deployment and management of the firewall on Leopard client.

And the approach many of you have taken, which is the right way to do that, and that is you're still managing and pushing out those rule sets and leveraging the built-in IPFW on the box, rather than the individual themselves managing the application-based firewall. And on the server, that's management on the server admin, of course, that's the full granular control of IPFW on the servers.

Maintaining system updates. Again, some of these seem so simple and so natural, but we always want to be sure that folks are aware of and fully leverage the additional updates and advancements of security updates coming from Apple. We wouldn't be putting out security updates if it wasn't something that we truly felt is in your betterment.

We're trying to address identified issues that have arisen either that we've identified, external entities have identified. So, as we might say, heed those security notifications from us and update those systems after you're doing some validation internally in your organization. The key thing is, the longer you wait between those updates, the longer you're going to have to wait for the security updates to come. So, when you're doing security updates, when they're available, again, is that time that you're potentially exposing yourselves to vulnerabilities once a given vulnerability in a service or an application has been known, the longer you wait, the longer you expose that system.

Of course the tools in our case. Many folks are doing some incredible scripting in their environments to do a lot of the management and we'll talk a little bit later about the security guides. Many of you, if you've looked at them, we've added the additional command line equivalents for each tweaking the configuration on the client and the server.

This should enhance those scripts that you've already developed and are pushing out either through third-party tools or remote desktop for tweaking and maintenance on those systems. So, as I kind of hit some of those highlights, let me bring Kim on to walk you through thinking critically about security and how you should be formulating security guidance or security by policy within your organization.

So, Kim? Hi, I'm Kim Hersh from the National Security Agency. And as Shawn said, I'm going to talk to you a little today about thinking critically about security. What I want to do is just give you a way to kind of

Just get a good grip on thinking about security and getting into, really into thinking about it and just a step-by-step way of locking down systems. Most people want the step-by-step way of locking down systems. They want it to be just kind of a no-brainer way of doing it.

the... When we develop the configuration guidance, we design it to be kind of step-by-step guidance to securing a system and it comes from the best knowledge we have on the security features of a system and it's designed using standard security design principles. And, but like I said, most people want it to be a no-brainer, but does one size really fit all? Well, not really. There's too many varied environments, differing requirements for a single guidance document to fit all needs. And trying to write several documents to capture a majority of needs would still not satisfy everyone.

So the approach we've taken is simply to tell how to lock down everything as securely as possible and to give some of the ramifications for not doing so where we possibly can. And this allows every organization to use the guide to develop an individual security plan for locking down their own systems according to their own particular needs. Okay, so using the guide means knowing how to adapt them.

Adapting them to fit organizational need, organizational policy, sensitivity level of the data, and balancing these needs and the easy use against the security risk to the systems. All right, so there are general principles that are followed when developing security configuration guidance. These are the same principles that should be followed when adapting that guidance for use in specific environment. Let's look at the security principles.

We have separation of function. If at all possible, you should have a separate firewall between the outside networks and your internal network. I know a lot of times in a mobile environment these days that's not always possible. Email and web servers, those should be separate. Also, the user database should reside on its own server whenever possible.

Having all these services reside separately means that if someone should compromise one has a strong authentication requirement, and he's not necessarily going to compromise your entire network. Having good separation between the services by putting them on separate servers and having strong authentication required between the servers adds another layer of security.

Never surf the web with your admin account. This cannot ever be said enough. Use admin only for administrative functions. Encryption provides yet another layer of security. No remote login should be done without some sort of encryption. Any services, especially network services that are not absolutely needed, should be stopped on the system.

This is true also of any unused code in the system. One such case, even though it's not a service, is IPv6. IPv6 is currently started automatically. Many organizations have currently not yet switched over to IPv6 addresses, and so if you're not using it, go ahead and turn it off.

Kernel extensions. They can also provide an attacker a window, so if there are any unused or unneeded extensions in the system, they should be removed. Also, they can be a good place to remove capabilities from the system, such as the ability to use USB flash drives. You must be remembered, however, that kernel-less extensions may be restored any time the system is updated. So, if any extensions are removed from the system, they should be removed each time an update is done to the system. Choose the most locked-down configuration you can while still providing the functionality that's required by your users.

Always lock down anything that is not absolutely needed. And last but not least, you want to always give least privilege. This includes for the users, for file systems, for groups, anything on the system, group ownership. You want to give the least privilege needed for everything to work properly and for the user to be able to still do what he needs to do on the system.

Okay, now I'm going to show you how we go about using those security principles to develop guidance by taking a look at the iPhone. Right now, we have We are starting to look at guidance for the iPhone. Eventually, we're going to develop a guidance document with the goal that probably a federal desktop core configuration guide will be developed. Under the Enterprise Environment. But, of course, the Enterprise Environment's not out yet. So meanwhile, using just our standard security principles, we can at least somewhat secure the iPhone just as it comes right out of the box right now.

So, first, you turn off access whenever you are not actively using it, such as when the device is sitting idle on a desk or in a car. This reduces the risk that an attacker will access the device remotely without your knowledge. Next, set the iPhone to always ask to join a network, rather than joining automatically by toggling the Ask to Join Network switch to on.

You should only join your iPhone to networks you know and trust. Only enable the Bluetooth communications when it is explicitly being used to pair the device with a Bluetooth headset or hands-free device. This limits the chance that an attacker could take advantage of the Bluetooth connection to attack your iPhone.

Airplane mode should be enabled whenever taking the iPhone into a sensitive area where all wireless functionality should be disabled. Obviously a good example would be on an airplane. Set the auto lock option to five minutes or less in order to mitigate unauthorized access to the device when it is not in use or in case the device is left unattended.

Again, setting a passcode for the device helps to reduce the chance of unauthorized access to the device. In order for the passcode to be truly effective, the required passcode option must be set to immediately. Now remember, if you set this passcode, make sure you know what the passcode is. If you don't, it's going to get locked up. You're going to get a little message that you're going to have to contact your carrier to be able to unlock it.

And suddenly we're going to have a whole bunch of people in the room calling AT&T and AT&T is going to wonder why we suddenly have a room full, you know, a hundred people or so calling them from Santa Fe, New York. And then you're going to have to get a message from the AT&T. And then you're going to have to get a message from San Francisco with locked-up phones. So please know your passcode if you set this option.

Okay, using VPNs for internet connections whenever possible is strongly recommended. They should always be configured to use L2TP in conjunction with IPSec if at all possible. PPTP alone should be avoided because there are known security problems. The RSA SecureID feature provides token-based, two-factor authentication between the user device and the remote VPN server. This option provides additional protection and should be enabled if possible. If the RSA SecureID feature cannot be used, a strong password should be used instead.

Password strength is an old topic at this point. Everybody knows you need to use strong passwords. There's plenty of guides out there on the internet, everywhere else about what password strength is, so go find them, do it. PPTP is not recommended at all, but if there's no other choice, it's better than nothing. If it's used, make sure the encryption level is set to maximum.

Advertising the type of device you're using, an iPhone, just gives attackers a head start on knowing how to approach attacking your device. It also notifies them when the iPhone is active and available based on when an email was sent from your iPhone. If all of your emails have the same signature, attackers will not know whether they came from your iPhone, your work machine or somewhere else.

So they won't know if your phone's available to be targeted. So change it. When setting up mail service, it's recommended to set it up to communicate over SSL if possible. The default on the phone is set to communicate over SSL, so don't override the option if you can use it.

If you set the show my caller ID switch to off, your phone number will not show up on other caller IDs. So if that's important to you, you should set that option. Toggle the SIM pin option to on and create an eight-digit pin to lock down the SIM card. This will provide an extra layer of protection by helping to prevent unauthorized use of the SIM in the iPhone or in any other GSM cellular phone. No phone calls can be made or received when the SIM is locked. And as I said, remember your pin.

Also, there are a number of known exploits not just under Safari, but with all web browsers. Because of this, Safari should be tightened down as much as possible. Unfortunately, there's a limited amount you can do to lock down Safari on the iPhone. But you should use what little bit is available to lock it down as much as possible. So disable JavaScript and plug-ins, enable pop-up blocking. Toggle the Accept Cookie option to From Visited. The Accept Cookies option should never be set to Always.

And every time Safari settings are changed, the phone should be rebooted or restarted to make sure the settings are accepted. Also, cookies, history and cache should be cleared each time Safari is used and every time a secure connection is made. The phone should be also here too, the phone should be restarted after these are cleared to make sure the settings were applied.

Okay, now that we've gone over what the settings should be, we're gonna go over a few best practices for using, carrying around, you know, having your iPhone. Once a phone is left unattended, if you still have it after that, it will be suspect. It may have been compromised. So you don't know if your data has been seen by somebody else, you don't know if something's been put on it, you just don't know what has happened to that phone while it was left alone.

Always use the provided applications to download and play media, not third-party applications. Third-party applications are from unknown sources and they may introduce additional risks. Clearing the history in Google Maps clears all addresses in the history, except for the last one entered. So, if you care about people knowing about any of your addresses on the phone, that last address won't be cleared until a new address is entered, so you might just want to put in some new arbitrary address to clear that address.

Don't hack the iPhone, including jailbreaking, fake activating and unlocking the phone. All the sources to do this are unverified, untrusted sources and they could introduce malicious code onto your phone and could compromise any personal data on your phone and could even render it useless. And installing software from sources other than those provided through the official sources have the same risks as the packages provided for hacking the phone.

Best Practices for Browsing with Safari Browsing the internet is where some of the greatest security risks lie. Some of the best ways to mitigate security risks are in how you use the device when you're on the internet. Make sure that whenever a web page requires a login that it uses SSL. or that it says HTTPS instead of HTTP. If it doesn't, don't log in.

Also make sure that SSL is being used whenever sensitive personal information, such as credit card numbers, are being exchanged. There's going to be a small gray lock at the end of the address to indicate that the connection is encrypted. Don't just click continue if the site certificate is not properly validated. When a message comes up that indicates the certificate is invalid, there's a reason for that.

Make sure that any site with which you are exchanging sensitive information has a valid cert. Make sure you log off and navigate to a blank page when you are exiting a secure link in Safari. Don't just quit Safari without logging off first. And always log off and quit Safari between secure sessions.

Okay, storing your sensitive information. Currently there is no way to encrypt stored data on the iPhone. And though the iPhone is a very handy way to keep a whole lot of information in one place to carry with you, remember things, it's also a very handy way to give out a whole lot of personal information in one package if you lose it or it gets stolen or it's compromised when it's not.

So sensitive personal information or company information should never be stored on the iPhone or should at the very least be kept to a bare minimum. This includes information stored in the notes application. And it includes things like usernames and passwords, account numbers, personal data and proprietary information among others.

Don't go putting your credit cards on there and storing them because you want to keep them in a safe place. and then you don't have to carry your credit cards because... There's no way to encrypt them. It's a very dangerous thing to do, let's just put it that way. And so it's taking pictures of them and keeping pictures of them on there. I've heard that that's something people do too. Any of your sensitive data is wide open on there.

Clear out all personal data after browsing the internet. To make sure this takes effect, as I said before, the phone must be restarted after clearing these settings. As stated previously, this should be done not only after browsing overall, but it should be done after each secure session before beginning another web session.

When connecting to a Wi-Fi access point, you should always choose the strongest wireless security available to you. WPA2 provides the strongest security available on the iPhone. You should always choose this if it's available, use the Enterprise Edition when it's possible, and choose EAPTLS or TTLS for authentication. When WPA2 is not available, WPA should be used as the next best available choice. The enterprise option should be used over the personal or pre-shared key option.

The enterprise option requires more infrastructure, but it's more secure. If PSK must be used, again, choose a strong password. Use only, oh, WEP, avoid using it. Only use it if WPA2 and WPA are both unavailable. Choose a strong password if you have to use it, and avoid performing any sensitive transactions.

Do not connect to unknown wireless networks. A good example of this is free public Wi-Fi. It's a rogue ad hoc wireless network that maliciously propagates itself across connecting hosts. Many commercial and private networks do not implement proper wireless security, leaving them open for connection. Even though they are open for connection, connecting to them without permission and proper authorization is unlawful, and it also leaves you open to attack. Disconnecting from your wireless access point when your connectivity is no longer needed. helps mitigate the risk of unauthorized remote access or exploitation. It also has the added benefit of helping save your battery life.

Okay, so summing up. When securing or even just using a system, Such as your iPhone, your laptop, anything, always applying basic security principles can help keep your system a lot more secure. So, even though we've got these guides out and you should use them, a lot of this is just thinking about security by using basic security principles. Take these principles, think about them, use them, always apply them to your system, always apply them to the way you use your system.

Using guidance will help, but even without this guidance, if you apply the principles, go through the system, you'll be able to lock down a lot of things in the system on your own. And remember, the user has a greater responsibility than ever to secure the machine. Securing a machine or device frequently means disabling features that people insist they must have. So sometimes the security is in the hands of the user. When locking down a system, we always end up having to strike a balance between functionality and security. And Shawn, I'll hand it back to you.

So right about now, probably at least half of you in this room are scratching your heads saying, "Can I actually use my system after I do all this?" Keep in mind that a lot of this is, again, kind of across the board guidance. We keep mentioning about making it apply to your environment, to where you're using your system.

So if you took your system and applied every aspect of this, it may indeed be unusable for the functions, for the services that you need. So again, these are just that, guidance about how to further fortify various services or general systems. Keep that in mind as you go forward.

So, as I mentioned, And... We always want to be sure that you have ongoing understanding of where to get this guidance on a regular basis. Share with you a little bit of the guidance that we've done in the past. Hopefully many of you are aware of the fact that we started a collaborative effort with NSA on security guidance for client and server back in the 10-3 days. That's where it was predominantly generated within NSA. We were part of the vetting process of that.

We moved forward with this collaboration, provided guidance documents directly from Apple that were collaboration between us again and NSA for 10-4. Then when we came and just recently released for 10-5, those documents were many folks from NSA, from DISA, NIST and from Apple were kind of the core group of this. There were several folks within government. There were a couple of folks in commercial who were additional vetters of the document that came out. Keep in mind that the release that we just put out recently is kind of the first release for Leopard.

We're going to be taking some additional public review part of the NIST process and the DISA is some additional external public review. We'll be bringing that input back in, working both that input and some of our additional refinement of this first release. So we'll be bringing that in for the second release for Leopard. And then there'll be a subsequent release or an update to this guide, again for Leopard itself. And Kim had mentioned that work is already underway for the phone itself.

So if you are in an environment where you need some very specific guidance on these devices, whether it be desktop, server or the phone, the best place to go for this is references on the on snack site at NSA. But at Apple, we have a. Website where a lot of these resources are as well. And the second down there is a security configuration guides.

That's a new site. Many of you probably aren't aware of that, but at Apple dot com slash support slash security slash guides is kind of a new website for the aggregation of all of these guides. So that's kind of your landing spot for looking for these guidance documents going forward.

There's a lot of resources, whether you're in the I.T. Space, whether you're the developer, whether you're just kind of looking at information. Related. To security updates and OS ten and of course, subsequent updates for phone the iPhone and all these are very good resources for you going forward relative to guidance. So now I think at the end, bring Kim back on.

And those of you that have some additional questions that we can help you through at this point, we'd be more than happy to answer questions related to general guidance, security guidance in your environment or specific questions if we can help you navigate. now on particular issues you may have.