The ability to provide access to the Real-Time tab of Resource Manager will enable administrators to provide this valuable tool to IT specialists or Helpdesk workers. Furthermore the ability to configure access to certain functions within the console will allow administrators to grant or restrict what users can do with Real-Time System Manager. This includes WMI functionality as well as powerful AMT functionality.

Introduction

Your environment will likely have a unique set of requirements on who can access what in Real-Time System Manager. It can be as simple as two levels of workers, from an administrator to an IT Specialist, to a complex system of access rights in a multi-tiered environment tightly controlled. No matter the environment, this article provides the details to customize access to the Real-Time tab, including WMI and AMT access rights.

RTSM contains limited functionality to configure access via WMI. AMT, on the other hand, can be configured at a function-granular level. Whether you're simply trying to give users full access to RTSM, or to provide access to only certain functions, this document assists to achieve this.

NS Role Security

The first item that must be enabled is creating a role or modifying an existing role to have rights to Real-Time System Manager at the general level. Without assignment to such a role, a user cannot gain access to RTSM.

Overview

Briefly I'll explain how NS Role and Scope security work together in Notification Server. Roles give feature access rights. For example in Software Delivery Solution there's a role object labeled ‘Item Tasks - Software Delivery Wizard'. The two options allow use of the Simple or Advanced Software Delivery Wizard. Without this right, the user cannot launch the Software Delivery Wizard, regardless if they have scope rights to the Wizard and Status node in the console.

Scope security is much like the Windows File-System security model. In the Altiris Console the left-hand tree can be accessed like the file system, applying security to folders or to nodes, as opposed to folders and files. Inherence allows security to be inherited from the containing folder, on up the chain until the root node is reached.

Role Configuration

The following steps show how to create a user with RTSM permissions.

1. In the Altiris Console, browse to View > Configuration > Server Settings > Notification Server Settings > Security Roles.
2. Select an existing Role or Right-click on the Security Roles folder and choose to create a new Role.
3. Under Privileges, find the following categories and check the indicated option. After the screenshot the items are details with description of the option:
   
   1. Altiris System Privileges - Use Real-Time System Management - This is the ability to use the product at the most basic and general level.
   2. Altiris Console Privileges - View Resources Tab - For this example I'm providing the user the ability to see collections so he or she can launch Resource Manager and use the Real-Time tab.
   3. Altiris Console Privileges - View Tasks Tab - Access to the ‘Manage' node allowing launch of Resource Manager requires this privilege.
   4. Item Tasks - Real-Time System Manager - Manage - This is access to the main tree for RTSM. Most functions are covered by this option.
   5. Item Tasks - Real-Time System Manager - Password Reset - Because of the nature of this function, it has been separated out as a single security role object in Notification Server but belongs to the Real-Time tree.
   6. Item Tasks - Real-Time System Manager - Port Check - The Port Check feature is normally accessed as a separate contextual item in the right-click menu, or launch from an icon under the Real-Time tab.
   7. Item Tasks - Real-Time System Manager - Trace Route - This is treated in the same way as Port Check.
   8. Item Tasks - Real-Time System Manager - Hardware Management - This is one of the objects in the tree that provides basic hardware function, which is greatly extended if the system is Intel vPro capable and Provisioned.
4. Click the Membership tab.
5. Use the blue + icon to add users and/or groups to the Role. These can be digest users or local computer groups, or Domain users or groups.
6. Click Apply to save the Role.

Note: The users will not have access yet to the Altiris Console as the scope-level security has not been set for the new Role. Complete the below NS Scope Security section to give access to the Altiris Console

NS Scope Security

Altiris Console

For Altiris Console access, scope security must be configured before a Role can access or login to the console. The security window is the same for any node, be it a folder or otherwise. The two screenshots below show the security window and the permission selection screens:

Note: Depending on the object type, the available permissions may differ

To allow access to the ‘Manage' Real-Time Console Infrastructure Task, follow these steps:

1. In the Altiris Console, browse under View > Tasks > Incident Resolution > Tools.
2. Right-click on the node ‘Manage' and choose Properties.
3. Click on the Security tab.
4. Click the ‘Add' button.
5. Select from the list Role name of your role (+ie:+ Role RTSM Workers) and click the ‘Select' button.
6. Check the option for ‘Full Control' and click ‘Select'.
   Note: Full Control does not give the user the ability to delete or otherwise manipulate the Manage node. This node can only be accessed for the function alone.
7. Click ‘Apply' to save the security changes made.

To access Collections so the users of the role can view collections so they can use the RTSM right-click contextual menu options for a listed resource, follow these steps:

1. In the Altiris Console, browse to View > Resources > Collections.
2. Depending on what collections you want to give the user access to, browse to a containing folder or an individual collection.
3. Right-click on the folder or collection and choose Properties.
4. Click on the Security tab.
5. Click the ‘Add' button.
6. Select from the list Role name of your role (+ie:+ Role RTSM Workers) and click the ‘Select' button.
7. Check the following options:
   1. Altiris System Permissions - Read
   2. Altiris Resource Management Permissions - Read Resource Data
   3. Altiris Resource Management Permissions - Read Resource Association
8. Click Select, and then click Apply on the permissions window.

Now we have allowed the user access to certain parts of the Altiris Console so they can execute Real-Time System Manager on managed systems. To restrict access to certain parts of the RTSM console, see the previous Role section for what options are available to you.

AMT Permissions

RTSM takes advantage of powerful functionality available in Intel vPro, AMT technology. Once a user has access to RTSM, their user account, if permitted, is used to connect to the remote system by WMI. An AMT connection can either use Kerberos integration or an inputted digest user when prompted. The credentials must be specified in the destination system's AMT Profile, otherwise authentication will fail.

To configure who has rights to AMT, follow these steps:

1. In the Altiris Console, browse to View > Solutions > Out of Band Management > Configuration > Provisioning > Configuration Service Settings > Provision Profiles.
2. Double-click on an existing profile, or create a new one.
3. Click on the ACL tab.
4. Click Add to add either a digest user or to use Domain users and groups with Kerberos integration.
5. Once a user is inputted, the ‘Realms' section allows or disallows access to different AMT functions. The boxes that are of importance to RTSM are:
   1. Circuit Breaker - Now known as System Defense, or Network Filtering
   2. Hardware Asset - For power management capabilities
   3. Redirection - To allow IDE Redirection
   4. Remote Control - Allows Serial Over LAN (SOL) remote connection
   5. Event Manager - Allows viewing of AMT logs
   6. General Info - Allows viewing of AMT data on the system
6. The ‘Access Permission' dropdown should be used to select either Network Access or Any. The Local Access option gives that user rights to log into the Intel ME locally when the system boots and isn't needed for RTSM function, however if you wish to allow the user to have access to both, choose ‘Any'.
   
7. Click OK to save the changes.

To apply the updated or new profile to an AMT system Provisioning must occurred. If the system was already provisioned with this same profile previously, a reprovision will update the profile.

This will not limit access to see the functions available in the Real-Time tab for AMT, but will throw a not authorized message if an applicable function is attempted with a user who does not have the rights to execute it.

Conclusion

The Real-Time tab, a one-to-one solution for system access, data gathering, or troubleshooting, provides a powerful tool to IT administrators and IT professionals alike. Providing this ability to users you do not want to have full access to Altiris is essential for any secure environment. With the additional ability to configure granular AMT rights for vPro capable and configured systems, an administrator has the ability to get very specific on what users or groups of what rights.

I am been taking a two day class on C/C++ secure coding, a required class for every coder within my group at Intel. First, I am so thankful I mostly don’t code in C/C++ because as I learned in the class, it’s quite challenging to write secure code that is not susceptible to stack overflow attacks or any number of other attacks. My co-worker Sandeep who works on Intel AMT Switchbox and Guardpost, both entirely built in C/C++ is going to have a challenge.

This said, C# is not immune to security issues and there is an ongoing debate whether the Intel AMT DTK C# and C/C++ tools should complete a security review. One argument is that as long at Intel AMT is secure and does not expose vulnerabilities, any Intel AMT tool is also safe and does not need to be reviewed. On the other hand, many people use the DTK source code for other projects and which we make no claims of security; it’s probably not a bad idea to check.

Right now, the DTK is not being checked for any security issues, but there are so design considerations that can, at a high level, help with security. One of them is to minimize or remove completely any listening sockets. In Intel AMT Commander there is one listening for SNMP traps, in Intel AMT Terminal there is also a socket used to connect debug terminals to pass serial-over-LAN information thru for debugging. On the agent side, Intel AMT Outpost have no incoming sockets, its powerful serial agent is connected to the serial-over-LAN COM port and so, relies on Intel AMT authentication.

I would like to invite the community to comment or post me directly any security issues you find with the DTK. I will certainly try my best to fix all of the issues.

Ylian (Intel AMT Blog)

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 GETSECSENTER). 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

Traditionally speaking - if security is improved, manageability suffers. The reverse of this is true also - traditionally.

Intel vPro presents a different approach and perspective to this common understanding - consider some of the usage models and scenarios described at the follow link. http://www.intel.com/business/vpro/index.htm (see the "improve security" and "extend manageability" links on this page under Resources - lower right side)

The above links demonstrates and introduces the usage models and capabilities. But - what about ensuring the security of the platform. As commonly inquired - "Could vPro be used maliciously?". Considering that any tool of value - even the screwdriver sitting in a garage or a desk drawer - could be used maliciously, the question might be better phrased - "What are the built-in security features of Intel vPro?" The following is only a summary and overview - yet should provide some comfort in the platform. (BTW: Are you aware of all the security features in current environments, or would introducing vPro perhaps expose a long term policy or technological oversight? Just a thought.)

• Internal security - Use of Intel digitally signed firmware. In some cases, the OEM will also require their digital signature for firmware updates. The non-volatile RAM (NVRAM) has strict security and access control. There is a small section referred to as "3rd party datastore" or 3PDS. Access to this area requires registration with Intel and granting of a token. Communications into the management engine occur through secure channels - whether from the operating system or from the network interface. Generally speaking - compromising the internal security would indicate there are bigger problems in the environment.
• Enterprise setup and configurationsecurity - Enterprise mode setup and configuration is handled via either a pre-shared secret or certificate based authentication. (see related blog on the latter). The configuration uses secure handshakes, authentication, and so forth. Replay attacks are prevented. With the latest configuration service, option to require authentication or approval of systems to be provisioned\configured. Pre-shared keys are changed after configuration, and subsequently based on definable schedules. Minimal setup rights can be used to limit exposure of accounts to perform setup\configuration. Security audit logs and event logs monitor activities. The process also has dependencies on the enterprise DHCP, DNS, PKI\CA, and so forth. Generally speaking - if the enterprise setup and configuration service is compromised, there are bigger problems wtihin the environment (whether technological, social networking, policy\procedure, etc)
• Operator Security - Roles, permissions, and AMT security realm access control come into play here. This effectively defines who is allowed to configure the "configuration services", who is allowed to authorize or change vPro configurations, and who is allowed to utilize functions on configured vPro systems. The "who" could be defined by a user, group, service, etc.In addition - use of Kerberos for user rights mgmt and so forth provides an integration into the Microsoft Active Directory. Thus a group of users can be defined withe various levels of access control and capability. Plus - all security related actions and configuration changes can be logged. Generally speaking - if an operator compromising vPro security, there are likely bigger problems in the environment (eg. policies, procedures, etc)
• Communication Security - Once a system configured, transport layer security (TLS) or Mutual TLS can used to secure management traffic. User sessions can authenticated using a digest protocol or Kerberos.
• Infrastructure Security - Since vPro effectively hasa separate management computer inside, this management engine can be configured for environments supporting wireless profiles (WPA or WPA2), VLAN, Network Access Control, 802.1x, etc.
• Operational Client Security - On top of all the configuration security items is the end-user usage and capabilities. Items such as System Defense, Agent Presence, remote power management, and so forth.

This returns to the first question - Can manageability and security be raised together for client management?

Open to hear from the community on your thoughts - whether in agreement or disagreement.