System Complexity and Failures

Introduction

• Complexity in systems affects security due to technical difficulties, size, and conflicting objectives.
• Mitigation strategies and project management approaches are suggested, which includes planning for failure in web services and identity management.
• System development faces new and complex problems not represented in project plans.
• CORBA once received attention for integrating distributed systems; now, focus has shifted to Web services.
• The progression of solutions indicates the difficulty of challenges and progress in overcoming them.

Security Failures

• A failure is when a system doesn't deliver the expected service.
• An error is an internal state that may lead to failure, and a fault is the cause of an error.
• Buffer overflows are examples as the error may be in a component not checking user input size.
• Attackers can exploit errors by sending large input streams with executable code.
• The program logic accepting bad input may overwrite other parts of the program.
• Attackers then execute added code, bypassing authentication controls.
• Functional errors can be leveraged into security failures.
• Errors can cause exploitable failures
• Many security vulnerabilities are in functional components rather than security functions like authentication/authorization.
• Attackers may try to put systems in unanticipated states leading to crashes or bypassed security controls.
• Errors in less analyzed system parts or poor configurations due to focused effort can be exploited.
• Designs may need to mitigate operator and user errors.
• Software engineers should be aware of the ever-lengthening list of exploitable errors

Categories of Errors

• Errors can be categorized according to their occurrence in five system elements: specific interface, component-specific integration, architecture integration mechanisms, system behaviour: component interactions, operations and usage.
• A specific interface controls access to a service or component.
• Component-specific integration assembly problems arise from conflicts in the design assumptions for the components.
• Architecture integration mechanisms are where vendors provide built-in capabilities for purchasers to integrate tools and tailor functionality.
• System behavior: Component interactions are strongly influenced by its interactions.
• Operations and usage is a frequent source of system failures

Attacker Behavior

• Modeling attacker behavior presents challenges in software failure analysis.
• Analyze quality attributes.
• Model work processes for authentication/authorization requirements.
• Model the attacker as an active agent who can change their attack based on defenses.
• Buffer overflows show the complexity of security analysis regarding model interaction.
• Architects model authentication/authorization mechanisms to satisfy design requirements.
• Exploited code allows attackers to move outside implemented software controls.
• The validity of the authorization model depends on data flow security analysis.
• Social engineering involves external events that may not be accounted for in usage models.
• Attackers try to convince users/administrators to take actions that circumvent security.

Functional and Attacker Perspectives for Security Analysis

• Security analysis must consider both the functional and attacker's perspective.
• Functionality identifies business importance, which is a component of risk assessment.
• Attacker's perspective considers business usage and technology.
• Interfaces must be monitored to reflect dynamically changing assurance.
• Enhance control points instead of relying solely on firewall protection.
• Identity management by web services supports business requirements for integrating geographically distributed systems.
• Identity management concentrates on authentication and authorization across multiple systems.
• Management should concentrate on the functional perspective and the attacker's perspective.

Web Services: Functional Perspective

• Business processes are distributed among business divisions, suppliers, partners, and customers, each with technology and automation needs.
• A high degree of interoperability among disparate information systems must be sustained.
• Web services technology uses XML messages passed among diverse, loosely coupled systems.
• Web services are a special case of service-oriented architecture (SOA).
• Service-oriented architectures represent interconnected systems or components as cooperating services.
• Web services technology aims to reduce interoperability issues dramatically.
• Web services messages contains the ordering data.
• Web services messages provide mechanisms for the necessary authentication and authorization.
• Encryption may be used by the sender to restrict access.
• Signing can confirm data integrity and identify message authors.
• SAML can be used to share user identities and attributes.

Web Services: Attacker Perspective

• Web services are implemented using SOAP.
• SOAP is an XML-based protocol for exchanging information.
• Exchanged info could be business data or process instructions.
• Relies on Shirey's model, categorizing threats as disclosure, deception, disruption, and usurpation.
• Service-level and message-level threats categorize the threats further: the former is common to distributed systems, and the latter affects Web services XML messages.

Identity Management: Functional Perspective

• Identity Management (IM) is an administrative system managing the creation, maintenance, and use of digital identities.
• IM includes business processes, computing infrastructure, operating systems, specific applications, database management systems, digital identity and implemented access, control mechanisms, and policies.
• For identity management. the functional perspective is represented by interoperability and access control across systems
• Difficult technical challenges include access control, audit and reporting, identity mapping, and domain provisioning services.

Identity Management: Attacker Perspective

• Identity information is a prized target due to its centrality to many security decisions and application functionality.
• Identity information needs extra diligence from government, regulatory bodies, and users.
• Related architectural constituents of this kind of information should be held to a higher standard.
• During all phases of SDLC, examine identity services & stores to ensure the strongest systems links.
• General mitigations for identity management risks are availability, hardened servers/services, incident response, and usability endpoint attacks.

Identity Management and Software Development

• Development teams lack plans for adopting standard representation and consumption patterns for authentication, attribute query/update, and authorization.
• The current state of identity may have numerous domain-specific technologies, policies, and organizational domains.
• Identity solutions are unreviewed by a wider audience.
• Identity information propagates and integrates throughout software systems and is used for access control decisions.

System Complexity Drivers and Security

• Security risk assessments are affected by unanticipated risks, reduced visibility, and errors.
• Consequences of expanded scope for security include unanticipated threats, reduces visibility, wider spectrum of failures, less development freedom, incremental & evolutionary development, and conflicting/changing goals.

Incremental and Evolutionary Development

• Organizations use approaches to manage risks associated with system complexity such as operational monitoring, consolidation of failure analysis/mitigations, and generalization of the problem.
• System development depends on integrating existing systems like Web services and identity management.
• Size complexity can be mitigated by commercial products, sharing software services, and reusing components/systems.
• Security issues in multisystem computing support designs are similar to large system design in typical IT environments.

Conflicting or Changing Goals Complexity

• Conflicting goals occur when desired product quality attributes or customer values conflict.
• There may be conflicts between portability, performance, security, and ease-of-use requirements
• Meeting cost requirements for new features might increase operational costs.
• Changes in goals can generate equivalent problems and inconsistencies.
• Implementing new objectives can conflict with earlier design tradeoffs.
• Goals change due to business requirements, usage of functionality, or customer understanding of needs.

Deep Technical Problem Complexity

• Deep technical problems arise when focusing on quality measures(reliability, performance, security) over satisfying functional requirements.

How To Solve Problem

• Enable the technical staff to concentrate on such problems
• The project manager needs to consider risk mitigations