Sometimes the methods for dealing with hostile or infected systems on the network are drastic, resulting in lost productivity, time, and energy. In one example the IT staff would physically shut down the user's main network port, sealing off all production systems, test systems, etc, until the hostile machine could be dealt with. Phone calls results, requiring the user to deal personally with the affected system. Now take Intel AMT's System Defense. Remotely quarantine a hostile system and use Altiris to remediate it. System Defense, it puts the power in the hands of the administrator remotely.

Introduction

System Defense (formerly known as Circuit Breaker) allows network filtering at the level of AMT. Systems that have been compromised and are a threat to the network can be remotely quarantined, with certain ports and IP addresses available for remediation. For example the entire network can be filtered out except to the NS, and only those ports required for the Notification Server to remediate the client (install anti-virus, patches, remove harmful software, etc).

Note that testing is vital when using a mechanism that can potentially cut off a system from the network. The ease of remediating compromised systems remotely while quarantining from the main network will remain as long as the filters are properly configured. If not, the system may require a desk-side visit to bring back on the network.

System Defense

System Defense shows as Circuit Breaker in some versions of the Altiris Manageability Toolkit for Intel® vPro Technology. This feature allows a network filter to be placed at the hardware level via AMT. AMT will hijack the operating system's hold on the network connection and apply a secure filter based on a configuration file provided by the administrator.

See the following diagram for a representation of how System Defense (Network filtering) works:

This filter becomes a complete block that disallows any network communication in OR out, save those sources that are configured. Note that the parameters for allowing network communication are those of Sending IP Address and Port. This means that not only to systems have to be explicitly defined to be allowed through, but the ports they are using as well.

Use Cases

The following use cases will find real value with System Defense network filtering:

• Virus attack from an infected vPro client - This cuts off the ability of that virus to send packets out on the network

• Vulnerable vPro clients without anti-virus - Close off the ability of a virus from getting through to the vulnerable system

• Vulnerable vPro clients without critical patches or updates - Quarantine systems, but allow NS to remediate to bring the system up to corporate security standards

• Unauthorized Network use - plug a system that is found participating in unauthorized network use, whether it be unauthorized content, gross use of bandwidth for non-approved purposes, etc...

• For fun - Drive a fellow administrator crazy by applying and removing filters randomly from his computer (Just kidding, don't try this at home, or at work for that matter)

Task Server Integration

As of Real Time Console Infrastructure release 6.3 the Task Server now has a Task type of Network Filter. This exclusively uses Intel AMT System Defense to apply a comprehensive filter that only allows strict communication to and from the NIC. Because of Task Server's sequencing engine and collection targeting, jobs using this can be setup to do a large number of things, including patching, critical application install such as anti-virus, and other critical computer maintenance items required by the organization.

Task Server Jobs

As a primer for details in this article, see the following article series on Altiris Juice: http://juice.altiris.com/article/2088/utilizing-intel-vpro-amt-technology-with-task-server-introduction.

See the Introduction for more information on jobs. There are two major types of a Network Filtering job:

1. Apply a System Defense network filter, either the default filter allowing communication to the NS for remediation or a custom filter allowing access to necessary resources

2. Remove a System Defense network filter to open back up general network communication

See the following screenshot for the option when this Task type is created:

• The first radial button allows the application of a filter, either a custom or the default, with the added option of enabling anti-spoofing filter

• The second radial button simply applies a PING filter to the target systems

• The third and final radial button removes any filters previous applied to the system

Job Targeting

Because of the significance of System Defense and what it does to client computers, I'm going to cover how Task Server Jobs target systems. With a Task Server job you can add individual systems or whole collections of computers. Collections are either manually or dynamically defined and can have few or many systems therein. Multiple systems and collections can be attached to the running of a job, either on demand or by a schedule.

Since System Defense is essentially quarantining vPro Systems, any Task or Job should be tested in a lab environment to ensure workability. If a custom filter is used, the potential to decapitate vPro systems from the network becomes a very real, very severe consequence of improper filters. Take the scenario of having a custom filter that does not allow proper communication back to the Notification Server or another critical resource (like Task Server) in the remediation process. Once the trigger is pulled and the System Defense network filter has been applied, those systems now have insufficient network access to remediate, which may mean that a remote Task to remove the filter is unavailable. IF the job contained half the computers in the environment, the impact is huge.

I say again: Test every filter within every job to ensure everything works properly!

Filter Configuration

Real-Time System Manager allows you to create your own filter configuration files to use with a System Defense Task. In some instances it may be required to open additional ports or destination IPs for full remediation to occur. If you use Package Servers to deliver software you may need to allow communication to these systems.

Edit Network Filters Utility

A utility is provided to create, edit, or otherwise revise any filter file to be used by a System Defense Task. This filter is provided via the Altiris Knowledgebase.

Installation The ENF Utility

See the following article for both the guide in using the utility and to download the utility directly:

https://kb.altiris.com/article.asp?article=34891&p=1

The attached file is a zip. The file included Altiris_ENF_6_2.exe will install the utility on the computer it is executed on. The prerequisites for this utility include:

1. Windows 2000 Server or Windows 2003 Server

2. .NET 1.1

3. Notification Server 6.0 Sp3

4. At least Real-Time Console Infrastructure 6.2

Using the ENF Utility

Once the installation has run, the Altiris Console can now be used to edit the filters. It's found in the Altiris Console under View > Solutions > Real Time Console Infrastructure > Configuration > and click on ‘Edit Network Filters'. The console provided a spreadsheet of the current filters for the default filter file, as shown:

When you click the Edit pencil icon, a subsequent window will appear. This wizard will walk through editing of the filters. This same wizard is used to add new filters to the list. This wizard is robust and allows minute tuning of what ports are allowed, both for sending and receiving from the NS and from the host AMT computer. The wizard appears as follows:

The default file is called CBFilters.xml and is found at \Program Files\Altiris\RTSM\UIData\. Other files can be created and used in the System Defense Filtering Tasks. It is configurable per Task or Job instance.

NOTE: If you plan on making changes to the default filter file, it is recommended to browsing to the file and making a copy of it. The copy will be a backup to use in case the default file becomes corrupt through editing or for related recovery options.

The best way to know how to open which ports to enable the access you require is to consult the documentation for the application or mechanism you are trying to work with. For example the Task Server uses ports 50120 through 50124, and these ports need to be opened between the Task Server to be used and the client computer.

Conclusion

As previously indicated, make sure you test every system defense task and job you plan to use out in your environment. It's one thing to test against one or two systems where you can manually resolve any unforeseen problems, but if a targeted collection contains many systems and the job or task as an unforeseen issue, this can cut off all these systems from the necessary access to restore network functionality. So test, test, test, and test again before deploying large jobs using System Defense network filtering.

When used properly, this tool enables administrators to remotely deal with vulnerable or infected systems remotely, and stop unauthorized network use. With System Defense enable your administrators to more quickly deal with threats, and remediate in much less time.

This is the third and final part of this series (at least for now). The previous two posts include

and

BEFORE GOING ANY FURTHER - PLEASE READ AND ENSURE THE FOLLOWING

At this point, you have ensured the infrastructure is setup correctly and have attempted to troubleshoot the common Intel SCS errors as listed in the SCSconsole log file. Intel vPro systems are being recognized and listed in the SCSconsole. However, strange or unexpected behavior continues to occur - whether during provisioning, maintenance, or other activities. If Intel SCS has been included in a system management console or a provisioning script provider with whom you are working - AND - further debug analysis is needed, the following points may help. The debug log output may be one of the datapoints requested to replicate and remediate issues.

Before we go on - please note that these steps require modifications to the Microsoft Windows Registry on the system labeled as "ProvisionServer". That system will be running the AMTconfig service. Enabling the debug logging features will require root drive access and space to capture and store the log outputs. The logs will be stored at the root of C:

Ready to create an Intel SCS debug log?

SCS debug logging is off by default. If enabling for troubleshooting purposes, be sure to disable when done troubleshooting. The following steps will require a new registry key and string value to be added. Once these changes have been made - restart the AMTconfig service. At most, two log files will appear on the root of c: drive. The first is scs_win_server.log the second is scs_server.log. The second commonly appears only after errors have occurred.

Create the following registry key on the service's machine:

HKEY_LOCAL_MACHINE\SOFTWARE\INTEL\AMTConfServer\Log with string value "LogLevel"="V"

Click on the following image to view the entire image

Logging levels can be set to 'V' for verbose, 'W' for warnings and errors, 'E' for only errors.

Once the debug log capture is complete, remove the LogLevel entry from the registry and restart the AMTconfig service.

This concludes the three part Intel SCS troubleshooting. If the community is experiencing additional events or has additional questions - please comment\reply.

This blog is divided into 3 sections - understanding the basics,

, and

If only solutions were perfect, errors resolved automatically, and tuning was never required nor needed. Then again, that's what many of us get paid to do and handle. The intent here is to focus on common Intel® vPro™ configuration and provisioning errors with Intel Setup and Configuration Services (SCS). More importantly, the article intent is to provide some insight on the correction needed or tasks to handle common errors.

The Basics

Deploying Intel® vPro™ enabled solutions presents many working parts. In a lab environment - these "always" work well. In a production environment, determining the cause of an error could be difficult. Generally speaking, to isolate the scenario take into consideration the management console, the vPro configuration services (e.g. Intel® SCS), the OEM firmware and drivers, and the infrastructure. The lab environment comes in handy to isolate components and aspects, especially when so many variables are present.

In stepping through each item, consider the following basic points:

• OEM hardware and drivers - Check the update page for the latest BIOS and Firmware on the platform. The BIOS update will often include the Intel® AMT firmware. The drivers to be checked are mentioned Management Engine Interface (MEI), Local Management Service (LMS), Serial over LAN (SoL), and User Notification Service (UNS). NOTE: UNS applies to AMT 3.0 and higher versions.

• Intel® SCS version - Don't know what version if running? Check the AMTconfig service properties or version listed in the SCSconsole. More on SCS and AMT versions

  here

  . Version 3.2 is the latest. If running version 1.x, an update to version 3.x is recommended. Check first with preferred system management vendor on supported setups, upgrade paths, and so forth.

• Infrastructure - Ensure a ProvisionServer DNS record exists for the target DNS domain, and that this pointer record resolves to the server running AMTconfig (e.g. Intel SCS). Ensure proper resolution of the DNS entry for the FQDN of ProvisionServer (e.g. ProvisionServer.company.com)

• Verbose Logging for SCS events - Within the SCSconsole, access the Change the Log Level to "Verbose" mode. This will log all informational, warning, and error messages and events in the SCS log. This is good to see when a hello packet is received, when the ProvisionServer attempts to provision the target system, and so forth. When changing this setting, you may also want to decrease the log retention level to a few days or shorter timeframe than the default value. Depending on the number of systems managed or attempting to provision, setting the log level to "verbose" may rapidly grow the size of the IntelAMT database.

The buzz has started on the Intel's X38 Express chipset, making use of the next-gen PCI Express 2.0 connectivity.

Geoff Gasior from The Tech Report takes a look at how the X38 chipset stacks up.

"...the X38 takes a major step beyond the P35 with its 32 PCI Express 2.0 lanes, which make the X38 the first chipset to offer second-generation PCI Express, ensuring plenty of bandwidth for future graphics cards. The X38's full 32 lanes also make it the first Intel chipset capable of supporting dual-x16 CrossFire configurations.

The X38 has other perks, too, such as support for DDR3 speeds up to 1333MHz. DDR3 memory modules have quickly scaled to 1333MHz and beyond, making support for faster memory an attractive feature. However, DDR3 still carries a hefty premium, and we suspect most enthusiasts will prefer to stick with DDR2-based X38 implementations for now. "

Tech Report puts together an impressive report running a number of test on the first X38 boards from Asus (Asus P5E3 Deluxe WiFi-AP @n) and Gigabyte(Gigabyte GA-X38-DQ6). Check out the full report and let us know what you think.

Tune in 6:30 Monday 10/22/07

Chat live

The Social Media Club of Silicon Valley will be at Intel Headquarters on Monday October 22 from 6:00 to 8:30 p.m. I will be one a many cool cats discussing Social Media and the Enterprise. If you can't attend watch the live webcast here.

The panel will be led by Shel Israel, co-author of “how blogs are changing the way businesses talk with customers” book with Robert Scoble.

Panel members will include:

• Dave McClure, 500 hats blogger,

• Jeremiah Owyang, social media researcher at Forrester

• Jennifer Jones, host of

• Eleanor Wynn is an Enterprise Architect, Social Computing and blogger at http://blogs.intel.com/it/authors#eleanor_wynn

• Bob Duffy, (the dude writing this post)Community Stratgist and site manager for Open Port

Also on hand will Bay Area NBC affiliate KNTV-TV, some smart folks from Bay Area NBC affiliate KNTV-TV, and some familiar voices from this web site (Open Port), on hand to do a bit of show and tell.

Register to attend the event here and add it to your Upcoming events listing here.

If you can make it in person come back to this post to watch and post your questions live.

Over the last year I have worked with our internal IT shop to implement vPro & CentrinoPro into the environment. While that was fun & rewarding, I thought now would be a good time to implement a smaller instance w/ a mix of clients & try out the new Intel System Defense Utility that I put a link on the tool page..

I've currently procured a centrinoPro, vPro(AMT2.x) & working on obtaining a vPro(AMT3.0) box to showcase all use cases & functionality, especially the Remote Configuration feature. What is good to note is that Matt Royer already helped me demonstrate Remote Configuration in San Francisco IDF & it was very nice to watch the out of the box to having the console automatically provision & show the vPro machine. However now the immediate challenge is for me to set this up w/ ISDU & see what use cases I can utilize.

if your on this path as well, let me know. I like to hear how you are using AMT (active management technology).

Cheers. Off to Provisioning....

UPDATE

I updated the BIOS via USB on the CentrinoPro & vPRO machines to ensure latest bios. I will work to get the post up this week on how to create a dos bootable USB stick & the preferences on size of the stick.

I then downloaded the Intel System Defense Utility, then I hard lined the CentrinoPro machine for now as I have not changed my Access Point settings for WPA at this point

(remember i'm doing this in SMB mode).

I then started the scan & was able to see both machines. If you click on link below you will find that I was able to detect both machines. I started first with inventory to show what I could validate from the Machines. Good to note is that both machines are Plugged into the network & the power (desktop - of course, notebook - yes). I wasn't satisified with the results so I went to each of the machines Web UI to ensure I could connect.

Initial Scan to obtain machines on the subnet, while this took longer than I expected it did find all the machines.

After finding you double click on each PC & it connects you to the Firmware.

Then I pulled an asset mgmt screen on both the notebook & desktop to show that I can pull inventory, take in account each machine is powered down at this point.

Now to be sure you can establish communication I went to the Web UI on both, which in the ISDU tool it is simple to click the link & hit the admin login.

While this is good, it's time to now showcase the rest of the use cases, including System Defense with a few good filters. I was out hunting for a good virus & found the backdoor.darkmoon. One of the ports is listens on is 6868 & 7777.. I was able to use System Defense as seen below to block these ports by doing the following:

#1. Open up Intel System Defense Utility

#2. Connect to the impacted machine

#3. Select the "System Defense" tab

#4. Select "Block LImited Services"

#5. Uncheck all items & then in blocked ports in put "6868,7777"

#6. Hit Apply Settings, then Apply Changes

DONE - I've now protected my machine quickly against the potential exploit. It doesn't fix it for cleaning, however it does protect the virus from communicating & receiving future instruction.

Now I can remote control it, turn it on, update the DAT files.

</object>

Sneak peak at Skulltrail system using two 45nm Quad Core Xeon processors (Harpertown) running at 4GHz.

From Channel Intel.

The conference goes through end of the week - yet the excitement around Intel vPro will continue for days\months to come. Below is a quick summary of items shown. Have questions or want more information? Add a comment or post a question.

• Keynote demonstration

  - showing how the Intel vPro client can be remediated (or isolated) to only the management console on specific ports. Using the Altiris TaskServer - a 1:many job was defined to place a system in remediation, restart a process on the client, and remove the system from remediation. This did require a customization to the network filter settings (e.g. System Defense). The value of isolating a system on the computers NIC was very compelling and led to many conversations.

• At the demo booth

  - some of the most frequent questions (and associated answers) include:

1. When will Intel vPro and Centrino Pro be available? (Product available today from all major OEMs - including Dell's recent product announcement for Latitude 630c)

2. How long has Intel vPro been available? (Product has been available for a year now)

3. Are customers adopting Intel vPro? (Yes)

4. How do channel partners and service providers get training or more information to assist their customers? (Utilize sites such Intel vPro Expert, Altiris Juice, and so forth today. Formalized training material and events are being created. Stay tuned)

5. Does Intel vPro utilize Wake-on-LAN? (The remote power features are communicated via TCP\IP for reliability\consistency. WoL utilizes UDP and a "magic packet" to contact systems - yet may not act as reliably. In addition, Intel vPro remote power features allow for power off. With integration into Altiris - the ability to record present power state, perform list of defined tasks, and to return the system to the previously recorded power state.)

6. Will Intel vPro appear in other platforms beyond PC-based laptops and desktops? (No publicly stated plans. Raise the question\interest with your preferred OEM)

7. What break-out sessions and materials were available at the event? ("Realizing the value of Intel vPro" - focus on how to integrate Intel vPro into a production environment. A hands-on lab also occurred to step through common operational usage models.)

There were likely other questions - yet these questions occurred frequently.

With the event closing this Thursday - some early discussions already starting to build on the momentum.... "What should we show next time?". I'm thinking more real-world scenarios, enterprise reference architecture for implementation, and remote configuration - what do you think?

Ok, this question has been out there for sometime now. Can playing video games at work be good for you? Could having your brain always on the "go" position be bad for productivity.

I think many social psychologists (full disclosure, none were interviewed for this blog) would agree that taking short breaks to recharge your brain is much better then charging full steam through the day. But can we even take that idea a step further and say that not only could it be good for your mental health but possibly good for the company as well? More then what a typical break to the soda machine can offer, playing games may also encourage certain activities (such as teamwork, if you can convince your company to let you play a team-based game like Halo 3 for instance...).

Well as is always the case, someone did a study on this -

It's amusing to note that the researchers had a lot of trouble finding companies willing to let their employees play games. However, the results show that workers who got to play up to an hour of games a day were more productive and more satisfied in their jobs. Of course, someone will come along and point out (like your boss) that if people are just playing games, no work will get done - agreed. But I'm not saying that people should play games all day long, just as a break here and there. Hey, they did a study right and the data doesn't lie. Anyway, with that said, I'm off to go spend the rest of my day conquering virtual worlds and dominating invading aliens...

Note this blog was written with the help of Mike Masnick as I wanted to write more but i'm on level 6 of

and couldn't pull myself away...

Matt Rosenquist, Information Security Strategist at Intel, says that measuring success in the security industry is difficult, since there isn't a perfect tool for measuring what doesn't happen. In this podcast, Matt talks about how Intel approaches security. How is measuring security programs any different than other IT or production programs? The heart of the problem is in trying to measure what does not occur. Security initiatives strive to prevent loss. So in effect they try and make something not happen or to lessen the outcome. And if something does not occur, how can you measure it?

Discuss this topic and more with Matt in his recent blogs:

The Problem of Measuring Information Security

Managing the Effort to Measure Security

Practical Aspects of Measuring Security

Well, it probably won’t work if you stick it there, but the

truth is that there are a lot of certificates used in AMT, and knowing where to

put those certificates and their private keys can save a lot of hair pulling

down the line.

<!--<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=ifgtevml+1">if gte vml 1>
id="_x0000_t75" coordsize="21600,21600" o:spt="75" o:preferrelative="t"

path="m@4@5l@4@11@9@11@9@5xe" filled="f" stroked="f">





































]]>

<v:imagedata src="file:///C:\DOCUME_{1\gjbevan\LOCALS}1\Temp\msohtmlclip1\01\clip_image001.emz"

o:title=""/>

endif><!<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=if%21vml">if !vml</a>>!AMT Certs.jpg!<!<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=endif">endif</a>><!<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=ifgtemso9">if gte mso 9>


DrawAspect="Content" ObjectID="_1253102892">



endif-->]]>

AMT Certificates

Let’s start with the AMT system itself.

TLS Certificate

If the SCS profile calls for TLS to be enabled then a

private key and certificate are generated at the SCS and then installed on the

Amt device as part of the provisioning process. This certificate and key are

then used in future communications between the SCS and the AMT device and the

Management Console and the AMT device. I’m going to use the SMS Add-on as an

example of the management console because it uses gSOAP libraries which have

addition certificate storage requirements.

802.1x Certificate

If the SCS profile calls for and 802.1x certificate then a

private key and certificate are generated at the SCS and installed on the AMT

device as part of the provisioning process. This certificate and key are used

to allow the AMT device to connect to an 802.1x protected network without the

host operating system being available.

Mutual Authentication Root Certificate (MTLS Root)

The MTLS root certificate is used by the AMT device to

validate the mutual authentication certificate provided by the SCS or

management console after provisioning has completed. (Assuming of course that

the SCS profile used for provisioning configures MTLS). This certificate is

installed during the provisioning process. Note only the certificate is

installed – there is no private key installed for this certificate.

h1. Remote Configuration

The remaining two certificates on the AMT device are used

for Remote Configuration. This feature is available in AMT 2.2, 2.6 and 3.0.

(Note that does not include 2.5).

Remote Configuration Root Certificate (RCFG Root)

Actually this is not a whole certificate. It’s just the

certificate thumbnail, referred to as a hash. The certificate hashes can come

from a couple of places:

<!<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=if+%21supportLists">if !supportLists</a>>·

hashes from VeriSign, GoDaddy and Comodo.

<!<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=if+%21supportLists">if !supportLists</a>>·

<!<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=endif">endif</a>>Your OEM can place a certificate hash of your

choosing on to the AMT devices you buy as part of their manufacturing process.

E.g. if you have your own PKI and wish to use your own root certificate.

<!<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=if+%21supportLists">if !supportLists</a>>·

manually enter the certificate hash into the MEBx screen.

The advantages and disadvantages of each of these methods

are best left for another discussion.

This certificate is used to validate the remote

configuration certificate provided to the AMT device by the SCS service that is

trying to provision the AMT device. The details of this validation are somewhat

complicated and also best left to another discussion.

Remote Configuration Self Signed Certificate

Finally the remote

configuration processes requires the AMT device to generated its own self

signed (i.e. there is no certificate authority involved – and hence no trust

established) certificate to serve as a TLS/SSL certificate in place of the Pre

Shared Key (PSK) that was used to protect provision in earlier version of AMT.

Both the certificate and the key are generated locally on the AMT system.

SCS Certificates

Once we get to the server side, certificates become more

interesting as we have to know which Windows certificate store to put the

certificate and private key.

The SCS requires four certificates.

SSL Certificate

The SCS service runs as a web service within IIS.

Connections to the service can be carried out by the SCS console or by an ISV

supplied UI. To secure this traffic the SCS service requires that these web

services be protected by TLS/SSL. The SSL certificate is the same type used to

secure other web servers like amazon.com or eBay.

This certificate is installed in the Windows certificate

store of the service account used to run IIS. If you use the IIS “Server

Certificate” this is a two step process. First the IIS server generates the

private key and a certificate request. The private key is stored in the IIS

service account key store, and the request is stored in a text file. The

certificate request is then sent to the CA who issues the certificate. The

wizard then installs the certificate and matches it up with the private key.

<!--<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=ifgtevml+1">if gte vml 1>
type="#_x0000_t75" style='width:555pt;height:444pt' o:ole="">

]]>

<v:imagedata src="file:///C:\DOCUME_{1\gjbevan\LOCALS}1\Temp\msohtmlclip1\01\clip_image003.emz"

o:title=""/>

endif><!<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=if%21vml">if !vml</a>>!SCS Certs.jpg!<!<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=endif">endif</a>><!<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=ifgtemso9">if gte mso 9>


DrawAspect="Content" ObjectID="_1253102893">



endif-->]]>

TLS Root

The TLS root certificate is the root certificate from the

certificate chain that issued the TLS certificates to the AMT devices. This may

or may not be the same as your MTLS Root, depending on how you issue your

certs. This certificate is used to validate the TLS certificate provided by the

AMT device when the SCS connects to the device to perform some function after

initial provisioning. This could be re-provisioning or one of the maintenance

tasks that the SCS performs – like setting the AMT system time.

There is no private key associated with this certificate.

The certificate should be stored in the “Trusted Root Certification

Authorities” folder of the SCS service accounts certificate store.

Mutual TLS Authentication Certificate

This certificate is used by the SCS to authenticate itself

to the AMT devices. Both the certificate and the private key should be stored

in the SCS service accounts “Personal” certificate store. The root certificate

of the chain must be installed on the AMT device during provisioning to allow

this authentication mechanism to work correctly.

Remote Configuration Certificate

This is the most interesting of the three SCS service

certificates. This is because the certificate needs to be in two certificate

stores – but the private key only needs to be in one. The SCS service presents

this certificate to the AMT device to start remote provisioning. As this is a

mutually authenticated TLS session, the SCS service must have access to the

private key. So the certificate and private key should be installed in the SCS

service accounts certificate store.

To configure SCS for remote configuration, a utility called

“loadcert.exe” is run. This utility lists the certificates in the local

computer store and you select the one you want the SCS service to use for

remote configuration. The utility then make a registry entry containing the

thumbnail of the certificate. The SCS service looks at this registry entry and

then looks up the selected certificate in the SCS service account certificate

store. Because the loadcert.exe utility reads from the local computer store,

the remote configuration certificate needs to be installed in there. But,

because it is only read by the utility to extract the thumbnail, the private

key does not have to be installed in the local computer store.

SMS (Management Console) Certificates

Certificates for the SMS Add-on are complicated by the use

of the gSOAP libraries. GSOAP is a cross platform, open source web services

development toolkit. Because it is cross platform it does not (obviously) use

the windows certificate store. Instead it uses a file format called PEM (from

the Privacy Enhanced Mail system). PEM files store certificates and keys as

base-64 encoded strings. This makes them easy to manipulate (with things like

notepad) and portable between systems. The following discussion assumes a 3

level PKI hierarchy, with a root CA, policy CA and an issuing CA. If there is

sufficient interest I can talk about PKI hierarchies on a separate thread.

As the SMS is also a windows program, it also needs its

certificates in the windows store.

<!--<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=ifgtevml+1">if gte vml 1>
type="#_x0000_t75" style='width:566.25pt;height:407.25pt' o:ole="">

]]>

<v:imagedata src="file:///C:\DOCUME_{1\gjbevan\LOCALS}1\Temp\msohtmlclip1\01\clip_image005.emz"

o:title=""/>

endif><!<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=if%21vml">if !vml</a>>!SMS Certs.jpg!<!<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=endif">endif</a>><!<a class="jive-link-adddocument" href="http://communities.intel.com/openport/community-document-picker.jspa?communityID=&subject=ifgtemso9">if gte mso 9>


DrawAspect="Content" ObjectID="_1253102894">



endif-->]]>

h2. Mutual Authentication Certificate (MTLS)

If the AMT profile the SCS calls for mutual TLS, then the

management console needs to supply an MTLSS certificate. This certificate, and

its private key, needs to be installed in SMS Add-on Service account

certificate store. This allows the SMS Add-on service to access the key for

operations such as power management. Because

the windows certificate store can “walk certificate chains”, only the MTLS cert

needs to be installed. Windows will work out where to get the rest of the chain

from on its own.

This is not true for the PEM file. In order for the gSOAP

library to have access to the certificate chain, all the chain entries must be

placed in the file (in the right order).

TLS Root Certificate

When a connection to the AMT device is made, it presents its

TLS certificate. In order for the Management console to trust the certificate,

the root certificate the issued the AMT certificate must be installed in the

“Trusted Root Certification Authorities” folder in the SMS Add-on’s certificate

store. . Because the windows certificate

store can “walk certificate chains”, only the TLS root cert needs to be installed.

Again, this is not true for the PEM file. In order for the

gSOAP library to have access to the certificate chain, all the chain entries

must be placed in the file (in the right order).

First let me say I'm not on the inside track with Moorestown. I'm an outside observer with my own perspective on this product, but I have to say... I think this will be HUGE. Lot's of talk about the Moorestown platform at IDF this year and I've heard many refer to this as the iPhone killer, or next generation iPhone. The game changer is size, the processing power, and WiMax capabilities. This is much more than anything in the market now. It can be almost anything you want it to be, and what you want it to do might be more about what devices it talks to. Here's my personal speculation on potential uses for Moorestown.

Harmony Remote Killer: This one is easy. Unlike the iphone with this kind of device you should be able to add and download applications and be configure to do pretty much what you want it to do. It's the size of a remote. It has bluetooth and WiMax. It should be able to talk to all of your AV stuff and replace your most advanced universal remotes.

GameBoy/PSP Killer: This be will run on Intel’s next generation 45nm chips. It should far exceed anything any hand held game system can do today. You could host games on the fly with people near you or host over the Internet. I actually believe this could be an XBox Killer. It will have the horsepower, it will be ultimately connected. It just needs peripherals like a dock or wireless connectivity to a large display and keyboard. Drop it on your coffee table, turn on your wall mounted LCD, pick up a wireless controller and you are gaming.

Desktop Killer: Yes, a desktop killer. Again it should have the horsepower. It will have highspeed connections and a full blown browser. More and more apps are moving to the web. There's a lot of talk about the death of the application, as applications can be run in the browser. Drop it on your desk, have it detect and synch with your wireless keyboard, mouse and monitor and you are working. Also more IT shops are starting to see the value of OS and application streaming technology where you can pull down the apps you need when you need them. Edit a spreadsheet, crop a photo, do a CAD Design, all apps come from the network when you need them, wherever you are.

Storage may only an issue for the few things you need locally. With WiMax, songs, videos, applications could all be available at your finger tips whether you have them stored on your PC, DVR, or from a service provider. You could ultimately have any data or any application on a powerful mobile device on your hip, in your pocket or in your purse.

My perspective is Moorestown is shaping up to be the ubiquitous everything device. I discussed this idea 2 years ago with an Intel engineer, during a school fundraiser. I claimed if Intel could create the device the size of cell phone with the processing power of a PC, you would not need any other device other than peripherals. I was new, I was in marketing and he thought I was nuts. And he pretty much told me so, citing that he didn't see how Intel would profit from it. A couple of weeks later I saw him again and he was anxious to tell me he just saw a presentation that discussed exactly what I was talking about. I'd like to think this is Moorestown... and personally I can't wait!!

Implementing Intel vPro in a production environment is "easy" in comparison to a major project such as domain migration, email setup\migration, ERP setup\update, or changes due to business acquisition or divestiture. A successful project requires disciplines across IT operations, business processes and governance, project management, client systems management, and understanding of the vPro\AMT technology.

That said - there are a few roles\responsibilities that might help.

The executive or project sponsor with the vision of success, ability to get "buy-in" from others, and has the foresight to navigate internal non-technical challenges.

Coordination of resources, schedules, expectations, and so forth. A key role for any successful project, which often has representation both inside and outside a production environment.

Intel vPro extends the reach of client system management with out-of-band capabilities. Understanding the current and future business processes and IT governance is key. Understanding the capabilities of Intel vPro and how it will augment and extend the environment is key. Understanding the desired future state of the environment and associated metrics is paramount.

Intel vPro is focused on the security and manageability of the client systems. It leverages many of the infrastructural capabilities which exist as a foundation to build upon. Understanding the impacts, interactions, troubleshooting, and so forth is important technologically.

Understanding the usage models requires some technical experience with the platform. Combined with the roles above, along with the functionality of client system management and Intel vPro technology - this project team role\responsibility is critical.

Individual or team with a holistic understanding of the current and future state of the environment, upcoming technological advances, and so forth. Perhaps a superset of previously stated roles. This role\team assists in making visions become reality.

Agree or disagree? Please share

As the industry moves towards the next big leap, virtualization, I can't help wondering will this be a security professionals dream or nightmare?

Disruptive technology:

I generalize virtualization as the necessary separation and compartmentalization of resources so things can be moved, consolidated, and managed better, across a wide swath of hardware platforms, users, and networks. It is a "disruptive technology" (not a bad term) which represents a fundamental change in how computer systems will operate, communicate, and be designed. It is a leap forward and represents greater agility, more functionality, and lower costs. The interesting security question is, what are we leaping into?

In the virtualization world you can name your poison....er, pleasure: Server, Client, Hardware, Operating System, Software, even data portability virtualization exists or is in development. I am not going to differentiate or explain the differences. Instead I am taking the strategic point of view. All these areas will be developed and instituted in some fashion. The details are far from being worked out. From a security perspective, it is the big picture that is important at the moment.

History has shown that the attackers have the advantage of ‘initiative' in technology, over the defenders. Basically, the attackers innovate and security then responds. But will this hold true for virtualization?

The Security Dream:

Virtualization holds the promise of security paradise by making systems more robust, hardened, simpler, and enabling new capabilities to make security more effective and cost efficient.

• Virtualization allows a much greater consolidation of hardware resources. Multiple OS, applications, and databases on a platform equate to less platforms to protect. Consolidation and portability for efficiency sake, may result in less network traffic to monitor, scan, and secure

• Virtualization allows for effective security sandboxes to be employed for un-trusted or questionable applications and processes

• Segregation of resources for applications, processes, OS's, and users means a compromise in one will be easier to contain due to compartmentalization. This makes it tougher for an attacker to break a weak link and begin to elevate their control over a system

• Application restoration is a snap and full systems restoration becomes easier when a client does bite-the-dust

• Systems and applications can be designed to operate with multiple environments of trust: very secure, secure, marginally secure, and not-so-trusting secure, all on one box (or the informal version: I trust you with my sister secure, I trust you with my wallet secure, I trust you as far as I can throw you secure, and I trust you will steal from me the first chance you get secure)

• Virtualization will drive standardization of application design and data types making them easier to secure

• Failover systems become less painful to design and implement at many different levels

• System upgrades become seamless as jobs can be moved temporarily to other systems and then returned without disruption

• Virtualization and other supporting technologies will drive advances in real-time security state monitoring, potentially across the enterprise and deeply into applications, OS's, data, and users

• My personal favorite is that eventually we will have the ability to monitor for suspicious activities from a trusted person, versus just looking at applications or data. Think insider threats. This will be the first significant advance in a long time for this problem

The Security Nightmare:

Virtualization may be the very bane of security for decades to come by circumventing every type of security technology and enabling new capabilities for attackers to do real damage, thus forcing an entire redesign and reinvestment of security.

• At the highest level, virtualization offers pure stealth to an attacker. Currently, malware must hide, lay dormant, or be very quiet in order not to be detected. This limits what the bad guys can do. They must trade capabilities and impact for stealth. Not so with virtualization. Malware could have the best of both worlds

• Total Control - it's mine, you can't find me, and if you do, you can't make me leave! I can see everything, I can control everything, and I can do anything! Mine, mine, mine! Control can extend well beyond a single system and permeate across the virtual domains, with the persistence requiring an entire group of machines be burned down and rebuilt with great care

• Now for the sledgehammer effect. Virtualization technology will undermine every current type of security control (the short list):

• Anti-Virus, HIPS/HIDS, and Host Firewalls - Cannot detect or monitor an attackers activities in a higher plane of control, making them ineffective while still giving the illusion of security

• Patching - Controlling virtual instances, more importantly creating false ones, will have patches installed on fake instances, leaving the real one vulnerable and under the intruders control

• Security scanning, used to check the system's state-of-security, can be fooled. Reporting back that all is fine when it is not

• Encryption - At the right level, an attacker will be able to see before encryption, after decryption, and have your keys to decrypt at their whim

• Security monitoring devices and agents can also be deceived, by showing them what they expect to see and nothing else

• User Privacy will be compromised at many different levels and open the risks of aggregation across multiple data sources

• Adware/Spam filters can be subverted

• Secure channels can be monitored by attackers and setup between compromised systems

• Security forensics may become a nightmare for many years due to the complexities inherent to virtualization and the fact that a high level compromise invalidates the integrity of logs

• Even NIDS/NIPS & Network Firewalls become less effective. Hardware consolidation translates to less traffic on the backbone network and more in-between systems on a platform and within a local subnet. This gives less information to these network monitoring devices and lowers the chances they will detect malicious activity

• The very same ‘sandbox' which can be used to isolate risky activities can be employed against security applications and processes, limiting their ability to control and protect the system

• Virtualization adds more complexity and therefore risking more confusion when it comes to system management. Especially for patching and system scanning. Keeping track of who owns what is bad enough today. But at least if you track down a server owner, you can normally have a quick decision on when to patch and reboot. In the future, the server owner, may not know who owns the virtual instances running on their machine. So how does one coordinate downtime, patching, or other change control issues? These delays may extend the window of vulnerability giving attackers more options and targets

• Less systems but more diversity and ambiguity gives places to hide and more opportunity to find a vulnerability

• Virtualization portability will drive the standardization of application design and data types, making them predictable and easier to locate and compromise

• Very complex designs which continually change are extremely difficult to restore and recover. Additionally, cascading failures can occur bringing down multiple systems whereas in a stovepipe environment they would be more insulated

Take the High Ground - Sun Tsu "Art of War"

The ultimate sweet spot for any computer attacker is to gain the deepest level of control, which in turn can control all other virtual instances. This is the proverbial high ground which can see and control everything, yet not be seen if it does not want to. Attackers are already making great advances and shown the initial ability to take the high ground. Defenders are quick on their heals, finding ways of detecting and defending this vital area.

Who can make the final determination in this battle? Intel and other hardware designers, of course! You can't get any deeper than the hardware. Imbedded security controls will be the key to victory. But here is the twist. You may have assumed I meant the victory to the glorious and honorable path of security. You are wrong. It is just the key to victory, period. Security and administrative controls are just functions with great power. Whoever controls those functions will be the victor.

Sometimes, the computer industry itself is its own worst enemy. Infighting on standards, rushing products to market, designing security as bolt-on afterthoughts, ill designed security solutions, etc may cause temporary self destruction. Even when a security function is developed, there is no guarantee it will be embraced by the industry or the consumer. It will take a small army of very smart people across the hardware, OS, application, and security services to design robust controls which present a value proposition necessary for widespread adoption.

In the end, the age old battle will continue to rage on between the attackers and defenders. Virtualization is simply the next battlefield. A new landscape to which these players will innovate, respond, jockey for position, and struggle for dominance. The rules and possibilities have yet to be defined. All we know about computer security will be thrown on its side and everything we do now will need to be rebuilt from the ground up. Virtualization is a brave new world, sure to bring both dreams and nightmares.

When dealing with Initial trust it is important to figure out who is trusting what.

First we will define a few terms to use.

Verifier - The entity that wants to trust the platform.
Platform - the vPro platform everyone is buying (you are buying one aren't you?)
Platform Configuration - the set of software measured by the platform (vPro measures BIOS and if executing the VMM)
Platform credentials - evidence of the platform properties which on vPro includes presence of TPM and the ability to execute TXT.

Now with these definitions let us work through a few trust decisions.

IT wants to trust new platform in the enterprise

Here we are assuming that the platform is brand new. The IT department uses the platform credentials to ensure that the platform delivered matches the platform credentials. If the platform does not come with credentials IT can create credentials for internal IT use.
Trust here is on either supplied credentials or direct creation of new credentials.

IT wants to trust a platform as it attaches to the network

here the platform contacts an access point (wired or wireless) and before assigning an IP address the access point asks for the current platform configuration. The trust necessary here is that the access point has to have sufficient evidence of the platform properties (credentials from our first use model) and then the access point obtains the platform configuration and validates the TPM report. (note that this is just the network access control protocol)
The access point must be able to determine what is a valid platform configuration and it does not matter if it is the first time the platform connects or the 20th time. The only issue is does the access point understand the platform configuration, if it does then the access point grants access, if it does not the access point blocks access. Determination of a valid platform configuration includes knowing what BIOS is supposed to be present and which VMM is supposed to be running.
Trust in this model requires the platform evidence (credentials) and the ability to understand the platform configuration.

Timing for the first two models does not matter. Whenever IT creates the evidence it is sufficient for IT, does not matter if it is the first day of use for the platform or in the second year of use. If one is using NAC, then the credentials provide the root of trust to believe the measurements and then the measurements provide information on the platform configuration. What else is executing on the platform does not change what measurements were taken. Measurements are not a one time operation but occur each time the associated root of trust executes (static RTM that is on each boot, dynamic RTM occurs on each invocation of GETSEC[SENTER]). It does not matter what else is executing or has executed, the measurement represents what occurred during the execution of the RTM.

Understand that platform configuration would not normally include the entire application stack. Rather the measured environment would provide additional measurements for applications. The entries in the PCR represent those components measured by the RTM and do not normally include applications. For instance when launching TXT the DRTM measures the SINIT authenticated code module, the measured launched environment (MLE), and a few registers. That is it. No applications, additional measurements would be provided by the MLE for applications or environments the MLE launches.

Applications can not just register with the TPM, there must be some process that measures the application and stores the measurement into some repository (which may or may not be the TPM).

Hopefully this little explanation helps in who is trusting what.

David