Learning objectives

• understand senior management's frame of reference,
• effectively communicate secure development concerns to senior management,
• develop value and risk related argumentation to support process improvement activities,
• share experience with other organisations.

Overview

This is an interactive session to exchange ideas and opinions in relation to how to convince senior management to improve and invest in better development methods and tools. It identifies senior management's typical concerns in relation to the five focus areas of IT governance:

• Business-IT alignment: What are the developments, investments and operations that are key to our strategy?
• Value generation: How to generate value from all activities and investments?
• Risk management: How to avoid enterprise risk such as not reaching objectives, financial losses, security breaches and unacceptable delays?
• Resource management: How can we better inventory and manage our resources? What architecture has more long term value? What technical decisions could be directly translated into business results/impacts?
• Performance measurement: What performance metrics to put in place to keep the visibility of our objectives and of progress toward them?

• how can we explain to senior management that our proposals to introduce secure application development methods address their concerns?
• what is required from Executive Management?

We hold an open discussion on participants’ actions to improve relationship with management and how to address their concerns through the proactive use of the five IT Governance focus areas.

Learning objectives

• understand the key concepts: threat, vulnerability and countermeasure
• be familiar with the most important categories of threats
• understand the relation between threats and security requirements
• master the process of threat modeling

Overview

Security is about reducing the risk that an organization's assets are exposed to. Risk is reduced by countering the various threats to those assets. Hence, understanding the nature of the threats that a particular software system is subject to, is key to securing that software system. Threat modeling is an activity in the development process of a software system, that tries to systematically identify and document possible threats.

In this module we elaborate on the process of threat modeling. First we define the notion of threat and illustrate it with examples. We discuss the most important categories of threats in a software system, and discuss systematic techniques for discovering and documenting threats, leading to a threat model. Microsoft's STRIDE is discussed as a representative threat modeling methodology.

Learning objectives

• understand the security guarantees offered by the different types of cryptographic algorithms;
• understand the APIs offered by libraries in popular programming languages that give access to these algorithms;

Overview

Cryptography is the scientific study of mathematical techniques relating to information security. In the field of cryptography, a wide variety of types of algorithms is studied. The most important types of algorithms include symmetric encryption, asymmetric encryption, hash functions, Message Authentication Codes (MAC's), digital signatures and secure random number generation. We discuss each of these types of algorithms, by defining in a precise way what security guarantees they offer, and by giving examples of applications. The emphasis is on the "black-box" behaviour of the algorithms, not on how they are implemented, or on the mathematical principles they are based on.

A fair amount of attention is given to software libraries that implement cryptographic algorithms. Modern cryptographic libraries are often based on a pluggable provider model, supporting so-called Cryptographic Service Providers (CSP's). We discuss the rationale behind this design, and the implications it has on developing software that uses CSP-based libraries.

]]> yo 17 July 2008 17:18 GMT http://secappdev.org/2008/language.html 2008/language Security architectures inside the programming language

Learning objectives

Characterize security mechanisms of the CLR and Java virtual machines.

Overview

The programming language used can strongly influence the security properties of applications. Modern programming languages such as Java or C# are favored because they have been designed with security requirements in mind. The notions of safety and type soundness, and their implications for security are discussed. Language based mechanisms for sandboxing partially trusted components are introduced and illustrated for both Java and .NET platforms.

Learning objectives

Understand how to pursue security qualities in software architectures.

Overview

In the first part, we introduce the basic concepts of software architecture, i.e. how to create, document and evaluate a software architecture, and sketch how security requirements are covered in well-known approaches, for instance in the work of the Software Engineering Institute.

In the second part, we extend and customize software architecture development approaches in order to deal with security in a more fundamental way. A case study in the health-care domain is used as a practical illustration of the presented material.

Recording part 1:

Recording part 2:

In the modeling framework introduced by the first lecture, this lecture focuses on security goals and their obstacles. Techniques will be presented for elaborating security goals, for specifying them, and for analyzing them against conflicts and threats. Obstacles to security goals can be accidental or malicious. Malicious obstacles require hostile environments to be modeled in terms of attacker anti-goals, knowledge, and capabilities.

In this setting, threat trees are built systematically through anti-goal refinement until leaf nodes are derived that are either software vulnerabilities observable by attackers or anti-requirements implementable by such attackers. New security requirements are then obtained as countermeasures through threat resolution operators. Such operators are applied to the specification of the anti-requirements and vulnerabilities revealed by the analysis.

The optional formalization of security-critical parts of the system model provides additional benefits. Attacks can then be generated formally as anti-goal refinements; potential conflicts involving security goals can be detected formally; some of the countermeasure operators can be formalized to yield more precise countermeasures. The talk will introduce epistemic constructs and patterns for specifying various types of security goals in order to support the formal derivation of anti-goals, boundary conditions for conflict, and countermeasures.

Learning objectives

• Understand the function of minimum disclosure credentials.
• Illustration of the basics of zero-knowledge proofs.
• In depth understanding of the showing and issuing protocols of a simple credential scheme.

Overview

Credentials are tokens issued by some authority to prove to third parties that a subject has some attributes. These constructions are ubiquitous: e-passports, train tickets and even cash can be thought of as credentials. Yet showing traditional credentials often leaks more information than necessary about the subject. Minimum disclosure, or anonymous, credentials use modern cryptography to limit the information disclosed to the minimum required to perform a protocol, and provide privacy even if the issuer and the verifier of the credentials collaborate to uncover the subject. As a result of these properties anonymous credentials are fundamental building blocks of privacy technologies.

In this lecture we will present their high-level properties and the basic families of credentials that have been developed over the last ten years. Then we will dive into the technical details of how they work, by providing a gentle introduction to zero-knowledge proofs, that are a fundamental part of modern cryptography. From there we will show how to build a simple anonymous credentials scheme and go into the details of the showing and issuing protocols.

Learning objectives

• Understanding the technological impact of legal requirements concerning the handling of personal information
• Becoming familiar with standard conceptual tools to improve privacy in computer and security systems

Overview

Handling personal data is part of day to day business, but losing them, disclosing them or not maintaining them up to date, exposes an enterprise to serious legal as well as reputation risks. This lecture presents an overview of what is personally identifiable information, and the principles by which the law and society at large expects it to be handled. The impact of these principles on technology is illustrated through real-world system designs, that support privacy, and the presentation of privacy features in established security protocols such as SSL and TLS.

Learning objectives

• decide if and when cryptography should be used.
• make informed key architecture and management decisions.
• use appropriate algorithms and parameters.
• select an appropriate cryptographic library.
• choose network protocols for distributed applications.

Overview

Application architects need to make informed choices to use cryptography well:

• Alternative key architectures have their merits and drawbacks. PKIs, in particular, should be contrasted with symmetric key architectures such as Kerberos.
• Network protocol characteristics are pivotal in ensuring distributed applications meet security requirements. Key strength choices impact on security guarantees offered, as do cryptographic algorithm modes.
• While strong keys and wise use of cryptographic algorithms may thwart cryptanalytic attack, applications are insecure without prudent key management. In this context, key generation and key storage require particular attention.
• The selection of crypto-libraries requires awareness of inherent library qualities and failures. Application developers are advised not to implement their own.
• Cryptography is used innovatively in areas such as obfuscation and watermarking.

Learning objectives

• gain an overview of secure network protocols.

Overview

As well as being important practical examples of the use of PKIs, networking protocols such as SSL/TLS, HTTPS, SSH and IPsec are also of great interest to the designer of secure systems in their own right. Participants gain an appreciation of how security requirements influence the choice of network technology.

Learning objectives

Be aware of the latest advances in cryptology that affect software developers.

Outline:

After an introduction to the basic concepts of volatility and persistence, Wietse presents examples of how to recover time line information from a variety of network and host-based sources.

After a walk-though of a post-mortem file system analysis, the presentation ends with results from file and memory persistence measurements. The results are based on measurements of a variety of UNIX and Linux systems, with some results for Windows/XP, including how to recover encrypted files without knowing the key.

Recording part 1:

Recording part 2:

Neither the UNIX system, nor the C programming language were built with security as a primary goal. Consequently, building a secure program can be like building a house on quicksand. The challenge for the implementor is to avoid the mechanisms that are weak, and to carefully build on the few mechanisms that remain. This tutorial focuses on implementation errors, why these errors happen, and how an implementor can avoid making such errors.

Outline

Security problems happen when system behavior does not match the user's expectation. The first segment illustrates this with a very small and obviously correct file shredder program that does not work at all, and for more reasons than most people can think of.

The second segment illustrates several flaws that were found in real applications that used the UNIX file system in an exploitable manner.

The set-uid feature is unique to UNIX, and deserves its own segment. Wietse demonstrates why it is fundamentally impossible to write set-uid software without creating a security hole.

In the final segment, Wietse presents the open source Postfix mail system, and how its partitioned design not only helped to build a secure mail system, but also helped to avoid code degeneration as the system expanded in size by more than four times.

Part 1

Part 2

Part 3

Part 4

Recording part 1:

Recording part 2:

Objectives

• Understanding of several available secure development methodologies (Microsoft's SDL, Cigital's "Touchpoints," and OWASP's CLASP)
• Understanding of the strengths and weaknesses of each of these lifecycle models
• Awareness of how to combine the best of each and put together one's own hybrid process that best suits each individual development organization
• Awareness of pitfalls to avoid in trying to implement a secure development process in a development organization

Overview

Several secure software development processes have been published in the past few years. These include Microsoft's Secure Development Lifecycle, Cigital's "Touchpoints", and OWASP's own CLASP project. Which one is right for your organization, or would your needs be best served by taking the best of each and coming up with "your own" process? In this talk, we'll compare and contrast each of these approaches and talk about the practical aspects of putting them to maximum use, including pitfalls to avoid.

Learning objectives

Gain insight into

• entity authentication protocols,
• the benefits and limitations of authentication factors,
• key establishment protocols,
• why and how to use authentication servers.

Overview

Authentication methods are based on something known, owned, biometric, location or evidence of trusted third party authentication.

• A password is a case of something known. Passwords are a vulnerable, but cheap and convenient way of authenticating an entity. Several techniques to augment their effectiveness are in use including challenge-response and one-time passwords.
• Secure devices such as smart cards and USB tokens often combine the 'owned' with the 'known', since secret keys are locked in the token with a password or PIN code. However, within the broad category of secure tokens, trustworthiness is variable, depending on whether keys can be extracted, passwords can be eavesdropped or the device can be tampered with.
• Biometry identifies a person via physical characteristics.
• Location is often used as the sole authentication factor, but is insecure given the relative ease of spoofing IP or MAC addresses.
• Multi-factor authentication is stronger than single-factor.
• The Kerberos protocol uses a key distribution-based authentication server. Service consumers must authenticate with a central server to obtain a secret session key with service providers. Such schemes require a single sign-on to access servers across a trust domain.

Learning objectives

• appreciate the cross-cutting nature of security operations;
• know how to address them by aspect-oriented programming;
• understand the vulnerabilities aspect-oriented programming introduces.

Overview

Over the last decade, Aspect Oriented Programming (AOP), a development paradigm that focuses on improving the modularisation of cross-cutting concerns, has received a great deal of attention from both the academic and the industrial community. AOP has been shown to bring a number of software engineering benefits. However, the security characteristics of AOP have been studied less. Whether AOP can be used to build secure software is the key questions addressed in this session.

In this presentation we elaborate on a number of security implications of AOP. Risks will be shown to originate from the core concepts of AOP, as well as from tool-specific implementation strategies. In the tool arena, we specifically focus on AspectJ. The presentation concludes by indicating how these risks can be mitigated, both from a theoretical and from a practical perspective.

]]> yo 15 July 2008 14:37 GMT http://secappdev.org/2008/planning.html 2008/planning Planning and tracking security requirements

Learning objectives

Plan and track security requirements in a software project.

Overview

Organizations develop software applications to create value. Modern project planning and management techniques explicitly take value creation into consideration when allocating and scheduling development resources. Risk, on the other hand, usually receives little attention. Nonetheless, risk in general, and the risk of security breaches in particular, have the potential of annihilating the value created by development activities, or even cause a project to realize negative value.

The first prerequisite of rationally allocating resources is being able to compare the benefits of value creation on the one hand and risk reduction on the other. Secondly, there must be a good estimate of the resources needed to achieve those benefits.

Mechanisms need to be in place to ascertain that development effort, whether invested in value creation or in risk reduction, meets its targets. Furthermore, as the environment of a system under development tends to change in the course of the development cycle, so do the requirements. Hence the planning and tracking protocol must make allowances for the flexibility demanded by most organizations.

Agile Security Requirements Engineering

Cost-Effective Security]]> yo 15 July 2008 09:16 GMT http://secappdev.org/2008/Exploits.html 2008/Exploits Exploiting vulnerabilities

Learning objectives

• Know the different classes of vulnerabilities.
• Understand the structure of exploit code.
• Understand how common exploits work.
• Be aware of the impact of working exploit code.

Overview

Exploits are the reason that vulnerabilities matter. This session will discuss how exploits are created and used against real-world targets. Attendees will become familiar with the different classes of vulnerabilities, the structure of exploit code, and the post-exploit processes that can occur on a compromised system.

]]> yo 15 July 2008 09:12 GMT http://secappdev.org/2008/standards.html 2008/standards International standardization of IT security

Over the last 10 years security has evolved from being exclusive to the IT department of a company to an inherent part of the corporate governance and strategy. Previously there was a lack of management buy-in. Now security is put more and more under senior management control. ICT security has evolved from a very fragmented “reactive” approach to an integrated “pro-active” one. Two important drivers for this are business interoperability and cost effectiveness and “standardization” plays a major supporting role in this. The presentation will provide an overview on the most important IT security standardization bodies. Next it will focus mainly on the activities of ISO/IEC JTC 1 SC27. It is a primary resource of international standards on application-independent IT security techniques for use by industry and other standardization groups. It has developed many standards already in use by commerce and industry and its current development programme is set to shape an even better future for protecting those assets critical to the success and well-being of businesses world wide. Its scope ranges from cryptographic techniques to security guidelines, criteria and methods.

]]> yo 15 July 2008 09:10 GMT http://secappdev.org/2008/tools.html 2008/tools Integrating security tools into the SDLC

Learning objectives

• Understand the range of tools available to the software security practitioner
• Demonstrate an ability to select the appropriate tools for a particular task
• Effectively integrate the tools into a software build process

Overview

Automated security tools are often used in software development, from static source code analysis tools to penetration testing tools. Unfortunately, due to a variety of reasons, many development organizations fail to get the maximum benefit from the tools. Worse, the way that many organizations use security tools may actually hamper effective development work. Penetration testing tools, for example, are commonly used for late life cycle “black box” testing. This forces, at best, knee jerk reactions to remediate any defects that are found, quite often at the expense of the application’s original design concepts. It also likely fails to find a great many security defects. To make matters worse, forced integration of tool technologies into existing workflows can be disruptive and counter productive.

This session delves into the automated tools associated with secure software development, and how they can be successfully integrated into a development workflow.

NOTE Many of the tools described in this session will be available for hands-on examination in Friday's "Hands-on security tools" session.

]]>