Information Security Management Handbook, Sixth Edition (2012)

DOMAIN 6: SECURITY ARCHITECTURE AND DESIGN

Principles of Computer and Network Organizations, Architectures, and Designs

Chapter 24. Enterprise Zones of Trust

Sandy Bacik

Security is a critical component of the development of any enterprise security architecture. Ad hoc approaches to developing conceptual security architectures do not work and are inefficient, inconsistent, and miss critical details that are important to system design. As such, there is a critical need to use established frameworks, methodologies, procedures, and best practices to ensure that there is a holistic approach to the development of security architectures so that the security architectures are effective, efficient, optimal, consistent, and well thought out. Without a holistic approach and without an enterprise conceptual architecture, the enterprise may not have trusts built into the framework.

Using an enterprise security architecture framework provides comprehensive traceability to enterprise goals and objectives, established business, and use cases and requirements and avoids recreating the wheel. A phased approached with increasing levels of granularity and specificity will develop a conceptual security architecture that is robust and adaptable to any utility environment. The security conceptual architecture will be the translation of the enterprise business vision and business requirements into a defense-in-depth strategy. Basic questions and issues that will be addressed when using an established enterprise security architecture framework are:

1. What goals and objectives were used to assist in developing use cases and security requirements?

2. What business and technical requirements were used in generating security services?

3. How can this conceptual architecture complement and enhance existing enterprise architecture and processes?

4. Has an overall design philosophy to ensure that security is “baked in” from the start of the life cycle been determined?

5. How can we identify all system components to ensure that security services are implemented throughout the enterprise where necessary?

6. How do we ensure the effectiveness and secure operation of enterprise system components?

7. How do we ensure efficient operation around security for the integration of enterprise system components?

8. How is the assurance of the interoperability and integration of security services within the overall enterprise system maintained?

9. How to ensure that security does not degrade the performance of the overall enterprise system?

10. How to ensure that security services are doing what they are intended and designed to do?

11. How to ensure that, once implemented, the enterprise system is being operated properly and securely?

Using an enterprise security architecture framework as a foundational structure can be the impetus in developing a broad range of different security architectures. An enterprise security architecture reference model and framework will aid in designing a target state around security for the enterprise by identifying essential building blocks and ensuring that those building blocks for the smart grid actually fit together. By establishing the baseline processes for what information is being created, transmitted, and stored and by identifying the end and middle points of processes, zones or domains of trusts can be established.

Understanding and Modeling Trust

Consider a simple model of doing an online transaction with the following steps:

1. A flower merchant has flower arrangements to sell online and advertises them on the Internet.

2. The Web interface allows a customer to browse the arrangements to fit an occasion.

3. The customer selects an arrangement on the Web interface and places an order.

4. The customer makes an electronic payment through the Web interface by sending a digitally signed authorization message to use his/her credit card.

5. The Web interface places the order to create a financial transaction, a flower arrangement, and a delivery entry.

As you review this transaction, what needs to be protected? What business functions are required? What security functions need to be part of the business functions? What functions does security serve for this transaction? All of these answers can be summed up into a single word—TRUST.

The key security-related issue in any business or security transactions or any relationship between two entities is trust. And in many ways, security transactions must have two-way trust. Using the above example, let us examine the trust characteristics. The customer must trust the flower merchant to:

Offer flower arrangements for a good quality at a good price

Actually deliver the proper quality order to the proper address, once payment has been received

Not repudiate the payment receipt that has been received

Dispatch the quality order on the proper date and time

Accept a return of the flower arrangement and refund the money, if the flower arrangement does not meet the expectations once it is delivered and seen

Handle after sale complaints about the quality of the flower arrangement and quality of the delivery service.

The flower merchant must trust the customer to:

Pay for the flower arrangement and have enough credit to cover the price

Not make false claims about the quality of the flower arrangement and quality of the delivery service

Not repudiate the flower arrangement order that has been ordered by the customer

Not repudiate receipt of the flower arrangement delivered to the customer

Not repudiate the credit payment authorization.

This is not an exhaustive list, but it shows some basic trust elements needed in a transaction between entities and that the trust elements are multifaceted. A security professional must understand that trust is an attribute of relationships and transactions between entities. A security professional must also understand that levels of trust vary greatly from one transaction to and each transaction is unique.

Identifying and Protecting Trust Relationships

Analyzing each transaction will allow the security professional to identify a series of one-way trust relationships in the transactions, which will make building trust models easier. As a security professional, you will develop and implement technical and procedural solutions to protect these trust relationships. In the above example with the customer and the florist, the customer must trust and be convinced of that trust that the florist has implemented the technical and procedural solutions to protect the identity of the customer, protect the credit card information of the customer, and deliver the appropriate order to the customer, to name a few items. The florist becomes a trust broker. The florist becomes the responsible party to offer remediation, should the transaction go wrong. The florist, the trust broker, takes responsibility for the trust and liability of the transaction. There is also an implied transitive trust. The customer must trust the florist to perform the credit card transaction. The florist trusts a credit card processing firm to execute the transaction properly. The customer then has a transitive trust to the credit card processing firm.

Depending upon the transaction content, different defense-in-depth technologies and processes will be put in place. The above described transaction with the trust and transitive trust models can be applied to the larger and more complex transactions within the enterprise.

Establishing Zones/Levels of Trust

There are different zones and levels of trust for different and more complex transactions. More specifically, the level of trust applied to a transaction will depend upon the trust of the endpoints of the transaction. The security professional designing the architecture will need to answer:

How much validation is done regarding the identity of the endpoint?

How much verification of trust is being carried out within the transaction?

Many times, verifying the credentials or information within the transaction involves transitive trust in a third party. The stronger the process of validation and verification of the identity and transaction content, the higher the level of trust.

Figure 24.1 Zones of trust to asset value.

A security professional architecting security will establish security domains. A security domain is a set of security elements subject to a common set of security controls. A security element is an object such as a field, record, file, database, system, or subsystem. The security controls express security requirements in general terms. Following the florist example, all customer accounts must have an established account with a password and a valid phone number for confirmation. It is the florist who is responsible for establishing the security controls for the requirement. This will be a combination of procedure and technology implementations.

Zones of trust are established based on the enterprise asset value. The security controls implemented establish the trusted entities and endpoints. The larger the asset value, the more or stronger security controls and a lesser amount of allowed devices, applications, locations, and accounts (see Figure 24.1). When an asset is more valuable, less resources have access to the asset. As an asset is more valuable, more trust is required for accessing or using the asset to ensure that the asset is not compromised. Setting up zones or segments for asset protection with access controls compromises a set of security controls for that specific zone of trust. These security controls are a set of activities to perform a specific transaction within an application at a location on a device using an account. The zone of trust security control provides detection and alerting mechanisms when a security control is violated. Depending upon the zone and the asset value, the monitoring, detecting, and alerting mechanisms are higher in priority.

An untrusted zone is an area where information has a limited value and can be accessed by anything by any account from any location. An untrusted zone has a high risk of attack and compromise. Access from this zone must be highly controlled. An example of an untrusted zone might provide limited access to enterprise resources, such as corporate e-mail.

A selective trust zone provides more protection than the untrusted zone. Selective trust zones do not contain critical data or highly valuable assets. An example of a selective trust zone might provide the contractors or partners access to specific applications or data.

A trusted zone provides the most protection for the enterprise’s critical assets. These assets are highly secured and locked down. Access to these resources is specifically controlled by account, location, application, and/or device. An example of a trusted zone might be administrative access to the network routing infrastructure.

Because of the asset values, a security professional must watch to ensure that a trusted entity that can misbehave without a security control violation is said to be unconditionally trusted. Aligning the enterprise in zones of trust based on asset value provides a good way to right-size security control so the asset is used and accessed properly. Establishing zones of trusts for asset access and use allows for easier policy enforcement. By increasing detective controls and implementing aggressive corrective controls, we can mitigate the risk of allowing broader access to the less-trusted assets. The actual balance of preventative, detective, and corrective controls will vary depending upon the zone of trust. For example, in an untrusted zone, we allow broad access to a very limited set of assets and mitigate the risk by increasing detective and corrective controls.

As a security professional sets up security domains within the security architecture, trusts will need to be set up between security domains. Jointly agreed-upon security controls and communications for transactions between security domains will need to be established. Like documenting the transactions within a domain, the transactions must also be documented between domains. The security domains must negotiate a common set of security services and mechanisms, as well as the information that will be exchanged. The security professional will start by establishing the multidomain transaction endpoints and the transaction contents. Within the transaction layers of protection (defense-in-depth), controls will be placed around the information and transaction as it moves between the established domains.

To establish and continue to maintain zones of trust within security domains, the security professional must:

1. Make sure there are explicit, detailed, and clear requirements for transactions

2. Make sure the control of the transaction is explicit and ownership is defined

3. Make sure there is a clear authority established for the transaction within each security domain

4. Be prepared to develop smaller security domain, subdomains, for more complex transactions or transactions that have a need for additional layers of security

5. When designing security controls and security control points, make sure all domain boundaries and interaction points are covered.

Lastly, remember that there is always a surrounding domain that is a “super-domain” and contains all of the security domains that you have defined. This “super-domain” should be considered hostile with no security controls, no security authority, and no trusted security elements.

Conclusion

The security professional must be vigilant on the boundaries of the established security domains. Because as a boundary expands and contracts, the security controls must be trusted enough to monitor the changes and catch any misbehaviors from the endpoints or the transactions within a security domain and among the other defined domains.