Article

Attack Patterns: A New Forensic and Design Tool

International Federation for Information Processing Digital Library; Advances in Digital Forensics III; 11/2007; DOI: 10.1007/978-0-387-73742-3_24
Source: OAI

ABSTRACT A pattern is an encapsulated solution to a problem in a given context that can be used to guide system design and evaluation. Analysis, design and architectural patterns are established formalisms for designing high quality software. Security patterns guide the secure design of systems by providing generic solutions that prevent a variety of attacks. This paper presents an attack pattern, a new type of pattern that is specified from the point of view of an attacker. The pattern describes how an attack is performed, enumerates the security patterns that can be applied to defeat the attack, and describes how to trace the attack once it has occurred. An example involving DoS attacks on VoIP networks is used to demonstrate the value of the formalism to security designers and forensic investigators. Full Text at Springer, may require registration or fee

1 Bookmark
 · 
45 Views
  • Source
    Proceedings of the 23rd International Conference on Software Engineering & Knowledge Engineering (SEKE'2011), Eden Roc Renaissance, Miami Beach, USA, July 7-9, 2011; 01/2011
  • Source
    [Show abstract] [Hide abstract]
    ABSTRACT: An important aspect for the acceptance of Service-Oriented Architectures is having convenient ways to help designers build secure applications. Numerous standards define ways to apply security in web services. However, these standards are rather complex and sometimes overlap, which makes them hard to use and may produce inconsistencies. Representing them as patterns makes them easier to understand, to compare to other patterns, to discover inconsistencies, and to use them to build secure web services applications. Security patterns abstract the key aspects of a security mechanism and can thus be applied by non-experts. We survey here our work on security patterns for web services and their standards and we put them in perspective with respect to each other and to more fundamental patterns. We also consider other patterns for web services security. All the patterns described here have been previously published, we only show here one of them in detail as an illustration of our style for writing patterns. Our main purpose here is to enumerate them, show their use, and show how they relate to each other.
    Future Internet. 01/2012; 4(4):430-450.
  • [Show abstract] [Hide abstract]
    ABSTRACT: A good way to obtain secure systems is to build applications in a systematic way where security is an integral part of the lifecycle. The same applies to reliability. If we want a system which is secure and reliable, both security and reliability must be built together. If we build not only applications but also middleware and operating systems in the same way, we can build systems that not only are inherently secure but also can withstand attacks from malicious applications and resist errors. In addition, all security and reliability constraints should be defined in the application level, where their semantics is understood and propagated to the lower levels. The lower levels provide the assurance that the constraints are being followed. In this approach all security constraints are defined at the conceptual or application level. The lower levels just enforce that there are no ways to bypass these constraints. By mapping to a highly secure platform, e.g., one using capabilities, we can produce a very secure system. Our approach is based on security patterns that are mapped through the architectural levels of the system. We make a case for this approach and we present here three aspects to further develop it. These aspects include a metamodel for security requirements, a mapping of models across architectural levels, and considerations about the degree of security of the system.
    Sixth International Conference on Availability, Reliability and Security, ARES 2011, Vienna, Austria, August 22-26, 2011; 01/2011