Security and Complexity

Dr. G.Usha Devi

Professor
School of Information Technology and Engineering
VIT University, Vellore
• Security Failures
• Functional and Attacker Perspective for Security Analysis
• System Complexity Drivers and Security
• Problem complexity
Security Failures
• A failure—an externally observable event—occurs when a system does not
deliver its expected service (as specified or desired).
• An error is an internal state that may lead to failure if the system does not
handle the situation correctly; a fault is the cause of an error.
• For example, in a buffer overflow, the error might be in a functional component
that does not check the size of user input. An attacker could exploit that error by
sending an input stream that is larger than available storage and that includes
executable code: This is the fault. The program logic that accepts the bad input
actually overwrites another part of program logic. The attacker then executes the
added code, which enables him or her to bypass authentication controls. In this
way, the functional error can be leveraged into a security failure.
Categories of Errors
five system elements:
1. Specific interface. An interface controls access to a service or component. Interfaces that fail to
validate input often crop up on published vulnerability lists.
2. Component-specific integration. Assembly problems often arise because of conflicts in the design
assumptions for the components.
3. Architecture integration mechanisms. Commercial software tool vendors often provide a built-in
capability for purchasers to integrate a tool into their systems and tailor its functionality for their
specific needs.
4. System behavior: component interactions. The behavior of a system is not the simple sum of the
behaviors of its individual components. System behavior is strongly influenced by the interactions
of its components. Components may individually meet all specifications, but when they are
aggregated into a system, the unanticipated interactions among components can lead to
unacceptable system behavior.
5. Operations and usage. Operational errors are also a frequent source of system failures
Attacker Behavior
• Modeling attacker behavior presents significant challenges in software
failure analysis.
• The analysis for quality attributes such as performance and hardware
reliability is based on well-established failure rates, but security
analysis does not have as solid a foundation
• Example:
• buffer overflow exploit –interaction models
• Social engineering exploits – usage models
Functional and Attacker Perspectives for
Security Analysis
• The functional perspective identifies the importance of an issue to the
business functionality of the system and hence is a component of a risk
assessment.
• The attacker’s perspective considers the opportunities that business usage
and the specifics of a technology create.
• Two examples:
1. Web services are often deployed to support business requirements for the
integration of geographically distributed systems.
2. Identity management concentrates on one aspect of system
interoperability: authentication and authorization across multiple systems
functional perspective
• For Web services, the functional perspective includes the capability of
dynamically exchanging information
• For identity management, the functional perspective is represented
by two objectives:
• Interoperability across systems to enable sharing of identity information
• Consolidation and, where desired, centralization of the security services of
authentication and authorization across multiple systems
Web Services: Functional Perspective
• A Web services message not only contains the ordering data, but also
provides mechanisms for the necessary authentication and
authorization.
• Encryption might be used by the sender to restrict access to this
information.
• Signing can be used to confirm data integrity or as a means to identify
the author of specific components of the message.
• Security Assertion Markup Language (SAML) can be used to share
user identities and attributes
Web Services: Attacker’s Perspective
• attack risks associated with Web services
• Web services have been implemented using the Simple Object Access
Protocol (SOAP)
• SOAP is an XML-based protocol that lets applications exchange
information
• The information exchanged might consist of business data (such as a
purchasing order) or instructions on how the business process should
be done
Web services
• Web services are designed to support interchanges among diverse
systems.
• The initial step of an interchange is for the purchasing organization to
acquire a description of the data transaction and the protocols used
for encryption and signing.
• The eventual objective is for the initial exchanges to establish security
policies that are acceptable to both parties.
• A service registry contains the message exchange pattern, types,
values, methods, and parameters that are available to the service
requester.
• It could be controlled by the service provider or could be a more
widely accessible site operated by a third party.
• Two main risk factors are associated with Web services:
• Distributed systems risks—risks to the service providers themselves that are
similar to risks that exist in Web applications and component applications.
For example, malicious input attacks such as SQL injection fit this
description. These risks arise simply because the system is distributed on a
network. Note that standard IT security controls such as network firewalls
are largely blind to Web services risks, because Web services are deployed on
commonly available open ports. Nevertheless, some types of application
firewalls have the ability to examine content, such as XML message bodies,
and can use application-specific knowledge to thwart some attacks.
• Message risks—risks to the document and data that are exchanged among
participants. The document may participate in a multisystem transaction or
be subject to inspection by a variety of intermediaries, each operating in
different security zones, including separate policy, geographic, technical, and
organizational domains. The message’s content may also, of course, contain
sensitive data.
Table 6–1. Disclosure of Information
Attack The XML-based messages may be passed without encryption (in the clear) and may
tactics contain valuable business information, but an attacker may be more interested in
gaining knowledge about the system to craft attacks against the service directly and
the system in general. A security vulnerability in the service registry (like that shown
in Figure 6–1) might let the attacker identify the system’s data types and operations.
That same information could be extracted from messages sent in the clear. Messages
may also contain valuable information such as audit logs and may lead to identity
spoofing and replay attacks, which use message contents to create a new message
that might be accepted.

Mitigations Authentication and authorization mechanisms may be used to control access to the
registry. There are no centralized access control mechanisms that can protect the XML
messages, but message-level mechanisms such as encryption and digital signatures
can be used.
Table 6–2. Deception
Attack tactics An attack can try to spoof the identity of the service requester by sending a
well-formed message to the service provider. The identity of the service
provider could also be spoofed. XML messages are passed without integrity
protection by default. Without integrity protection, an attacker could tamper
with the XML message to execute code or gain privileges and information on
service requesters and providers.

Mitigations Web services provide a number of integrity and authentication mechanisms

that can mitigate deception. For example, WS-Security defines how to include
X.509, Kerberos, and username and password security information in the XML
message to support end-to-end authentication. Message integrity is supported
through digital signatures and message origin authentication.
Table 6–3. Disruption
Attack An attacker could execute a denial of service at the network level against a Web
tactics service. Messages could also be used for a denial-of-service attack. For example, an
attacker could send a specially formed XML message that forces the application into
an infinite loop that consumes all available computing resources. The receipt of a
large volume of malformed XML messages may exceed logging capabilities.

Mitigations A network-level denial of service is mitigated in a similar fashion to a Web application

denial of service—that is, by using routers, bandwidth monitoring, and other
hardware to identify and protect against service disruption. Mitigation of message-
level disruptions depends on validating the messages, but that mitigation can be
tricky, because the target of such attacks is that mitigation component. One tactic
would be to encapsulate message validation in a service that is applied before
messages are passed to applications.
Table 6–4. Usurpation
Attack An attacker may usurp command of a system by elevating his or her privileges. One way to do so is to
tactics exploit the service registry to redirect service requests, change security policy, and perform other
privileged operations. XML messages may be used to propagate viruses that contain malicious code to steal
data, usurp privileges, drop and alter tables, edit user privileges, and alter schema information.

Mitigations When service registries are used in Web services, they become a central organizing point for a large
amount of sensitive information about services. The service registry (and communication to and from the
service registry) should be hardened to the highest degree of assurance that is feasible in the system.
Vulnerability analysis of source code pays particular attention to system calls to privileged modules in the
operating system. The service registry can affect policy, runtime, and locale for other services and hence is
analogous in importance to the operating system. Therefore particular attention must be paid to how
service requesters access the service registry. At the message level, vendors are beginning to realize the
significant threat that viruses, when attached and posted with XML documents, may pose to the
environment. For systems that may have XML or binary attachments, virus protection services should be
deployed to scan XML and binary messages for viruses in a similar fashion to email messages—that is,
before the messages are executed for normal business operations.
REFERENCE
• SOFTWARE SECURITY ENGINEERING
• BY
• JULIAH ALLEN, SEAN BARNUM, ROBERT J ELLISON, GARY MCGRAW,
NANCY R MEAD
• PEARSON EDUCATION