134 ◾ Security Strategy: From Requirements to Reality
to many system resources. All you need to do is fi nd a way to exploit a fl aw in one of those
resources to gain unauthorized access to the system. Compromised Internet sites are a great
example of this. Anonymous is a valid user on the system with valid permissions granting read
and execute privileges to system fi les and applications. In December 2009 attackers used these
permissions to execute a SQL Injection attack that compromised over 130,000 websites. e
same type of attacks can be executed against online services as well; it just requires a valid user
identity for the service.
Depending on the type of service being provided, getting that identity can be a trivial pursuit
or a major endeavor. For commoditized services like Windows Live, getting a user ID means you
must provide a valid e-mail address. For shared services like Microsoft Online, a valid e-mail
address and credit card are required. For dedicated services, a valid customer user ID is required.
e latter can be a real challenge, but the other two are trivial. How an attacker obtains the
identity really doesn’t matter; the fact that an attacker can use that identity to directly attack and
compromise service applications and systems is the real concern. Perhaps, even more disconcert-
ing is the fact that a single service identity frequently provides access across multiple services.
Once a system has been compromised, this shared trust can be exploited to propagate the attack
across service boundaries. is is why application-level security is a critical security objective for
service providers. In light of the privileges being granted to users, service providers must provide
uncompromising application security. e slightest user exploitable fl aw can easily result in a
massive compromise.
Exceptional Customer Data Isolation
Service providers must also provide exceptional customer data isolation. Whenever a service
processes, transfers, or stores data from multiple customers, there is the possibility for data
leakage between customer entities. e threat is more prevalent in shared services because all
customers use the same resources, but data leakage is also a threat in dedicated services because
customer environments use a common set of service support applications. For example, infor-
mation from multiple customers can be found in service desk, performance, backup, and mon-
itoring systems. Although this information may be more diffi cult for an external attacker to
compromise, it is still susceptible to disclosure from human or application error. For example,
one of the service providers Bill worked with had a recurring problem with service ticket
reporting. Operators would sometimes include cross customer information in service reports.
e issue was as much a problem with the application as it was with the operators, but that
didn’t make the customer whose information was leaked feel any better, and it certainly was
detrimental to the provider’s reputation. e problem, to some extent, is systemic. Applications
that have been designed for internal use, including monitoring and ticketing systems, typically
do not have robust security features.
e threat of cross customer data leakage in shared environments is even greater. Data is
present in shared memory during processing, intermingled during transport, stored in shared
databases, and backed up to common media. e threat is further exacerbated because these data
elements have diff erent levels of sensitivity and are subject to diff erent regulatory and legal require-
ments. Although there is no practical way for a service provider to know what these sensitivities
and requirements are, nonetheless, customers have a reasonable expectation that the provider will
provide appropriate protections. And if the customer is wise, they will make those expectations
part of the service-level agreement. Exceptional customer data isolation must be a priority security
objective for service providers.
TAF-K11348-10-0301-C008.indd 134TAF-K11348-10-0301-C008.indd 134 8/18/10 3:08:41 PM8/18/10 3:08:41 PM
Layer upon Layer (Defense in Depth) ◾ 135
Shared-Risk Mitigation
Another aspect of security that service providers have little control over is the security state of cus-
tomer systems. Nonetheless, the provider must grant these systems access to their services and fi nd
a balanced way to mitigate the risks these systems pose. e term balanced is used here in the sense
that the mitigation must reduce the risk to acceptable levels without adversely impacting the end
user. Forcing a customer to use health certifi cates or to go through extended system scans before
they can access your service isn’t going to be a good solution.
Shared risk is somewhat easier to deal with in shared services environments because these
services are usually limited to very specifi c ports and protocols. Consequently, there are far fewer
exploits to deal with. In dedicated environments, especially those that provide direct connections
to the customer’s network, things are a little more challenging. Often these connections involve
bidirectional communications that make port-based fi ltering diffi cult; for example, service sys-
tems may use customer-based services like DNS or Active Directory. Routing and other network
protocols may also be involved.
Shared-risk mitigation is one of the most challenging objectives faced by most service provid-
ers, especially those that provide dedicated services. At one service provider Bill worked with,
responding to customer-based attacks was a frequent occurrence. e attacks seldom presented
any real threat, but they were a constant and unnecessary drain on security team resources. Shared
risk is an issue that must be addressed. Failing to address it in your security objectives puts you at
risk of compromise or even worse, in the untenable position of having to prove your service was
not the source of a customer breach.
Superior Accountability
Compliance has had a huge impact on IT services. Before the onslaught of regulatory and legal
requirements, the most valuable commodity in IT was knowledge. Knowledge gave you the
ability to demonstrate competence, resolve problems, implement solutions, and the like. at
same knowledge is still needed, but today the most valuable commodity is proof. Compliance
isn’t about what you know—it’s about what you can prove. It’s about liability: the penalties you
will incur if you cannot prove compliance. Some of these penalties are contractual; others are
imposed by regulators, and still others by the courts. So daunting are the possible liabilities that
one of the priorities for security at Microsoft Online was “keeping compliance from putting us
out of business.”
Superior accountability is the best way to accomplish this objective. Accountability is the
ability to provide irrefutable proof of what actions were taken and by whom they were taken. In
today’s regulatory and legal compliance climate, it is a critical security objective for every service
provider.
Summary
Defense-in-depth objectives for providers of hosted services are focused on two things: data security
in processing, transport, and storage; and the mitigation of risks associated with customer connec-
tions and compliance-imposed penalties. Uncompromising application, networking, and storage
controls are the best overall goals for data security management. After all, data compromise is the
end goal of the attacker. Mitigating shared risk is a balance between risk reduction and service-
ability. Shared-risks are easier to deal with in shared services than they are in dedicated services,
TAF-K11348-10-0301-C008.indd 135TAF-K11348-10-0301-C008.indd 135 8/18/10 3:08:41 PM8/18/10 3:08:41 PM
136 ◾ Security Strategy: From Requirements to Reality
especially those directly connected to the customer’s network. Superior accountability builds
credibility with customers and provides the best defense against compliance and legal liabilities.
Hybrid Objectives
Hybrid environments are common in today’s commuting environments. e lower cost of hosting
and online services made the outsourcing of systems and services very attractive. Technically, a
hybrid environment is an IT confi guration that has some in-house services and some hosted ser-
vices, but this defi nition is probably too generic for this discussion. ere are hundreds of possible
hybrid confi guration scenarios ranging from simple website hosting to fully outsourced server
farms. Consequently, there are a lot of variances to the security objectives for these scenarios. And,
of course, the objectives of the consumer are going to be diff erent from those of the provider.
is discussion of the services scenario has been divided into four levels:
1. Uncoupled—services where the consumer is always the initiator of the connection and
is primarily pushing data to the provider. An example of this type of service scenario is a
hosted website. e consumer makes a secure (SSL) connection to the website usually via a
public network to update Web page content.
2. Loosely coupled—services delivered through a public network where consumer data trans-
fers are bi-directional. e consumer is the party that initiates all the actions (i.e., connec-
tions, data transfers, etc.). Once the consumer is connected, the provider may request that
the consumer take a specifi c action such as update their client software, but the provider
cannot initiate that action. Web-based e-mail is a good example of this scenario.
3. Fully coupled—services delivered through a dedicated connection (e.g., a virtual private
network [VPN]) that allows either party to initiate an action (i.e., a connection or transfer
data). e connection is bi-directional; the consumer can push and pull information, and
so can the provider. Applications that use federated identity are a good example; the end
user (consumer) initiates a connection to the service, and the service validates the connec-
tion request by contacting the customer’s in-house authentication service to verify the user’s
access permissions.
4. Fully integrated—services that are characterized by full-time dedicated connections and bi-
directional data exchanges. ese services can be initiated by either party. An example of this
type of service would be a hosted backend database management service supporting an inter-
active end-user application. e consumer performs reads and writes against the database,
and the service regularly queries the consumer’s authentication server to validate user access.
e service may also use other customer-based services such as DNS, Time, and WINS.
Consumer Objectives
Consumer objectives are based on the level of service being provided. Uncoupled services have very
modest risks associated with them. e primary concern is the security of the content that is stored
at the provider. In the case of website maintenance, there is the possibility of a “drive-by” attack
when the consumer connects to the service if their website has been compromised. A “drive-by”
attack uses a background process to install malicious code such as a keystroke logger on the con-
nected system. is code can then be used to capture user credentials and other information to
further the attack. e presence of attack code could be the fault of the provider (e.g., failing to
TAF-K11348-10-0301-C008.indd 136TAF-K11348-10-0301-C008.indd 136 8/18/10 3:08:41 PM8/18/10 3:08:41 PM
Layer upon Layer (Defense in Depth) ◾ 137
apply patches for a known exploit), or it could be the consumer’s fault (e.g., the Web application is
vulnerable to SQL Injection). Having a website with attack code on it is also a downstream liability
should that code cause damage to users of the site. Another possible issue is the compromise of cre-
dentials passed on a public network. e most likely scenario here is a redirection attack (e.g., DNS
hijacking). However, these attacks are mitigated with SSL certifi cate-based site authentication.
Standard end-user system security confi gurations are usually suffi cient to guard against code
download in a drive-by attack. Assuming you have users knowledgeable enough to deal properly
with website certifi cate warnings, the primary security objective in this scenario is provider man-
agement, ensuring through regular audits and reporting that the provider is properly safeguarding
the data you have entrusted to their care.
Loosely Coupled Scenarios
is scenario is similar to the uncoupled scenario in that it is subject to the same types of drive-by
and redirection attacks. However, there is an additional risk associated with the data being pulled
from the site. In the case of a Web-based mail system, this data would include executables (scripts)
and message content (text, html, attachments, etc.). Client side scripts are necessary to the robust
functionality of many Web-based applications, but they can also be subverted to perform mali-
cious acts via a distribution attack. e most common example of this type of attack is the replace-
ment of script or other executable content on a Web server with malicious code. When a user calls
this function, the malicious code downloads and executes on the user’s system (also see drive-by
attacks). It is also possible to get malicious code installed by modifying the source before it is
installed. A developer could intentionally do this, or a system on which the code is stored could be
compromised and the code tampered with. e bigger concern is the potential for malicious code
in downloaded content. Message attachments are notorious for distributing attacks. e “I Love
You” virus is probably the best known example, but malicious attachments are still in wide use.
Protecting against malicious code downloads must be a key security objective in hybrid envi-
ronments. is includes protections against rogue scripts. e other key objective must be service
provider management, ensuring the provider is properly protecting your data. e provider must
be able to report on who accessed code, confi gurations, or data related to your service and what, if
any, changes were made. For really critical data (e.g., backups), even this level of reporting may not
be suffi cient control, in which case data integrity objectives must also be considered. Data integrity
ensures that data are not altered while they are stored at the provider; this is crucial to the proper
restoration of failed systems, meeting record retention requirements, and so on.
Fully Coupled Scenarios
is scenario is a true enclave-to-enclave connection. It diff ers from the previous two scenarios
because the connections take place over a dedicated circuit. e connection may traverse a public
network, but the systems are not exposed to the public. is reduces the risks associated with
external threats, but amplifi es the need for shared-risk mitigation for two principal reasons: there
is an established level of trust between the parties, and the circuit by default permits all types of
traffi c. Without restrictions these connections provide the perfect conduit for the spread of mali-
cious code. e unrestricted access issue requires well-defi ned boundary protection objectives and
the trust issue makes shared-risk objectives imperative.
Federated identity is a good example of a fully coupled system. Figure 8.4 depicts the fol-
lowing workfl ow: e consumer attempts to access a service, the service collects the user’s
TAF-K11348-10-0301-C008.indd 137TAF-K11348-10-0301-C008.indd 137 8/18/10 3:08:41 PM8/18/10 3:08:41 PM
138 ◾ Security Strategy: From Requirements to Reality
credentials, and then the service passes them to the provider’s identity management system
(IMS) for authentication. e provider’s IMS uses the enclave-to-enclave circuit to forward the
credentials to the customer’s identity system and receive back the required authentication and
authorization claims.
In some instances, this exchange may take place across a public network, but the connection is
still a private connection because mutual authentication of each system involved in connection is
required. Any other connection attempts are simply ignored. is scenario does require that access
control objectives be defi ned.
Fully Integrated Scenarios
is scenario is similar to the fully coupled scenario; communications take place on dedicated
circuits, but the integration between the systems is such that the provider’s enclave functions like
it is part of the consumer’s enclave. For example, one of the consumer’s identifi cation management
systems may be co-located at the provider. e range of services fl owing between the enclaves
can be extensive. One organization Bill worked with kept its business applications in-house, but
farmed its e-mail, instant messaging, collaboration, network management, monitoring, backup,
provisioning, and patch management to its service provider. e arrangement helped the company
focus on its core business, but it also created an operating environment that was nearly impossible
to secure. Every attempt to apply security measures to the enclave connection or services either
caused an unacceptable degradation in performance or caused something to fail completely. In
this scenario, there must be a primary emphasis on shared-risk and service provider management
security objectives and a secondary emphasis on access control and boundary protection.
AuthN server
4.
6.
5.
2.
3.
1.
7.
AuthN server
Company A Company BInternet
1. User attempts to access partner Web server
2. Redirected to partner federation server
3. User chooses their home realm
4. User is redirected to his or her home account
federation server for authentication
5. User is redirected back to resource
federation server with assertion set
6. Assertion is validated
7. User is redirected to Web server
Account
federation
server
Account
federation
server
Web server
Federated trust
Figure 8.4 Federated identity scenario.
TAF-K11348-10-0301-C008.indd 138TAF-K11348-10-0301-C008.indd 138 8/18/10 3:08:41 PM8/18/10 3:08:41 PM
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.