Book Review: The Security Development Lifecycle (SDL)

In The Security Development Lifecycle (SDL), A Process for Developing Demonstrably More Secure Software, authors Michael Howard and Steven Lipner explain how to build secure software through a repeatable process.

The methodology they describe was developed at Microsoft and has led to a measurable decrease in vulnerabilities. That’s why it’s now also used elsewhere, like at EMC (my employer).

Chapter 1, Enough is Enough: The Threats have Changed, explains how the SDL was born out of the Trustworthy Computing initiative that started with Bill Gates’ famous email in early 2002. Most operating systems have since become relatively secure, so hackers have shifted their focus to applications and the burden is now on us developers to crank up our security game. Many security issues are also privacy problems, so if we don’t, we are bound to pay the price.

Chapter 2, Current Software Development Methods Fail to Produce Secure Software, reviews current software development methods with regard to how (in)secure the resulting applications are. It shows that the adage given enough eyeballs, all bugs are shallow is wrong when it comes to security. The conclusion is that we need to explicitly include security into our development efforts.

Chapter 3, A Short History of the SDL at Microsoft, describes how security improvement efforts at Microsoft evolved into a consistent process that is now called the SDL.

Chapter 4, SDL for Management, explains that the SDL requires time, money, and commitment from senior management to prioritize over time to market. We’re talking real commitment, like delaying the release of an insecure application.

Chapter 5, Stage 0: Education and Awareness, starts the second part of the book, that describes the stages of the SDL. It all starts with educating developers about security. Without this, there’s no real chance of delivering secure software.

Chapter 6, Stage 1: Project Inception, sets the security context for the development effort. This includes assigning someone to guide the team through the SDL, building security leaders within the team, and setting up security expectations and tools.

Chapter 7, Stage 2: Define and Follow Best Practices, lists common secure design principles and describes attack surface analysis and attack surface reduction. The latter is about reducing the amount of code accessible to untrusted users, for example by disabling certain features by default.

Chapter 8, Stage 3: Product Risk Assessment, shows how to determine the application’s level of vulnerability to attack and its privacy impact. This helps to determine what level of security investment is appropriate for what parts of the application.

Chapter 9, Stage 4: Risk Analysis, explains threat modeling. The authors think that this is the practice with the most significant contribution to an application’s security. The idea is to understand the potential threats to the application, the risks those threats pose, and the mitigations that can reduce those risks. Threat models also help with code reviews and penetration tests. The chapter uses a pet shop website as an example.

[Note that there is now a tool that helps you with threat modeling. In this tool, you draw data flow diagrams, after which the tool uses the STRIDE approach to automatically find threats. The tool requires Visio 2007+.]

Chapter 10, Stage 5: Creating Security Documents, Tools, and Best Practices for Customers, describes the collateral that helps customers install, maintain, and use your application securely.

Chapter 11, Stage 6: Secure Coding Policies, explains the need for prescribing security-specific coding practices, educating developers about them, and verifying that they are adhered to. This is a high-level chapter, with details following in later chapters.

Chapter 12, Stage 7: Secure Testing Policies, describes the various forms of security testing, like fuzz testing, penetration testing, and run-time verification.

Chapter 13, Stage 8: The Security Push, explains that the goal of a security push is to hunt for security bugs and triage them. Fixes should follow the push. A security push doesn’t really fit into the SDL, since the goal is to prevent vulnerabilities. It can, however, be useful for legacy (i.e. pre-SDL) code.

Chapter 14, Stage 9: The Final Security Review, describes how to assess (from a security perspective) whether the application is ready to ship. A questionnaire is filled out to show compliance with the SDL, the threat models are reviewed, and unfixed security bugs are reviewed to make sure none are critical.

Chapter 15, Stage 10: Security Response Planning, explains that you need to be prepared to respond to the discovery of vulnerabilities in your deployed application, so that you can prevent panic and follow a solid process. You should have a Security Response Center outside your development team that interfaces with security researchers and others who discover vulnerabilities and guides the development team through the process of releasing a fix. It’s also important to feed back lessons learned into the development process.

Chapter 16, Stage 11: Product Release, explains that the actual release is a non-event, since all the hard work was done in the Final Security Review.

Chapter 17, Stage 12: Security Response Execution, describes the real-world challenges associated with responding to reported vulnerabilities, including when and how to deviate from the plan outlined in Security Response Planning. Above all, you must take the time to fix the root problem properly and to make sure you’re not introducing new bugs.

Chapter 18, Integrating SDL with Agile Methods, starts the final part of the book. It shows how to incorporate agile practices into the SDL, or the other way around.

Chapter 19, SDL Banned Function Calls, explains that some functions are so bad from a security perspective, that they never should be used. This chapter is heavily focused on C.

Chapter 20, SDL Minimum Cryptographic Standards, gives guidance on the use of cryptography, like never roll your own, make the use of crypto algorithms configurable, and what key sizes to use for what algorithms.

Chapter 21, SDL-Required Tools and Compiler Options, describes security tools you should use during development. This chapter is heavily focused on Microsoft technologies.

Chapter 22, Threat Tree Patterns, shows a number of threat trees that reflect common attack patterns. It follows the STRIDE approach again.

The appendix has information about the authors.

I think this book is a must-read for every developer who is serious about building secure software.

XACML In The Cloud

The eXtensible Access Control Markup Language (XACML) is the de facto standard for authorization.

The specification defines an architecture (see image on the right) that relates the different components that make up an XACML-based system.

This post explores a variation on the standard architecture that is better suitable for use in the cloud.

Authorization in the Cloud

In cloud computing, multiple tenants share the same resources that they reach over a network. The entry point into the cloud must, of course, be protected using a Policy Enforcement Point (PEP).

Since XACML implements Attribute-Based Access Control (ABAC), we can use an attribute to indicate the tenant, and use that attribute in our policies.

We could, for instance, use the following standard attribute, which is defined in the core XACML specification: urn:oasis:names:tc:xacml:1.0:subject:subject-id-qualifier.

This identifier indicates the security domain of the subject. It identifies the administrator and policy that manages the name-space in which the subject id is administered.

Using this attribute, we can target policies to the right tenant.

Keeping Policies For Different Tenants Separate

We don’t want to mix policies for different tenants.

First of all, we don’t want a change in policy for one tenant to ever be able to affect a different tenant. Keeping those policies separate is one way to ensure that can never happen.

We can achieve the same goal by keeping all policies together and carefully writing top-level policy sets. But we are better off employing the security best practice of segmentation and keeping policies for different tenants separate in case there was a problem with those top-level policies or with the Policy Decision Point (PDP) evaluating them (defense in depth).

Multi-tenant XACML Architecture

We can use the composite pattern to implement a PDP that our cloud PEP can call.

This composite PDP will extract the tenant attribute from the request, and forward the request to a tenant-specific Context Handler/PDP/PIP/PAP system based on the value of the tenant attribute.

In the figure on the right, the composite PDP is called Multi-tenant PDP. It uses a component called Tenant-PDP Provider that is responsible for looking up the correct PDP based on the tenant attribute.

Abuse Cases

Gary McGraw describes several best practices for building secure software. One is the use of so-called abuse cases. Since his chapter on abuse cases left me hungry for more information, this post examines additional literature on the subject and how to fit abuse cases into a Security Development Lifecycle (SDL).

Modeling Functional Requirements With Use Cases

Abuse cases are an adaptation of use cases, abstract episodes of interaction between a system and its environment.

A use case consists of a number of related scenarios. A scenario is a description of a specific interaction between the system and particular actors. Each use case has a main success scenario and some additional scenarios to cover variations and exceptional cases.

Actors are external agents, and can be either human or non-human.

For better understanding, each use case should state the goal that the primary actor is working towards.

Use cases are represented in UML diagrams (see example on left) as ovals that are connected to stick figures, which represent the actors. Use case diagrams are accompanied by textual use case descriptions that explain how the actors and the system interact.

Modeling Security Requirements With Abuse Cases

An abuse case is a use case where the results of the interaction are harmful to the system, one of the actors, or one of the stakeholders in the system. An interaction is harmful if it decreases the security (confidentiality, integrity, or availability) of the system.

Abuse cases are also referred to as misuse cases, although some people maintain they’re different. I think the two concepts are too similar to treat differently, so whenever I write “abuse case”, it refers to “misuse case” as well.

Some actors in regular use cases may also act as attacker in an abuse case (e.g. in the case of an insider threat). We should then introduce a new actor to avoid confusion (potentially using inheritance). This is consistent with the best practice of having actors represent roles rather than actual users.

Attackers are described in more detail than regular actors, to make it easier to look at the system from their point of view. Their description should include the resources at their disposal, their skills, and their objectives.

Note that objectives are longer term than the (ab)use case’s goal. For instance, the attacker’s goal for an abuse case may be to gain root privileges on a certain server, while her objective may be industrial espionage.

Abuse cases are very different from use cases in one respect: while we know how the actor in a use case achieves her goal, we don’t know precisely how an attacker will break the system’s security. If we would, we would fix the vulnerability! Therefore, abuse case scenarios describe interactions less precisely than regular use case scenarios.

Modeling Other Non-Functional Requirements

Note that since actors in use cases needn’t be human, we can employ a similar approach to abuse cases with actors like “network failure” etc. to model non-functional requirements beyond security, like reliability, portability, maintainability, etc.

For this to work, one must be able to express the non-functional requirement as an interactive scenario. I won’t go into this topic any further in this post.

Creating Abuse Cases

Abuse case models are best created when use cases are: during requirements gathering. It’s easiest to define the abuse cases after the regular use cases are identified (or even defined).

Abuse case modeling requires one to wear a black hat. Therefore, it makes sense to invite people with black hat capabilities, like testers and network operators or administrators to the table.

The first step in developing abuse cases is to find the actors. As stated before, every actor in a regular use case can potentially be turned into an malicious actor in an abuse case.

We should next add actors for different kinds of intruders. These are distinguished based on their resources and skills.

When we have the actors, we can identify the abuse cases by determining how they might interact with the system. We might identify such malicious interactions by combining the regular use cases with attack patterns.

We can find more abuse cases by combining them systematically and recursively with regular use cases.

Combining Use Cases and Abuse Cases

Some people keep use cases and abuse cases separate to avoid confusion. Others combine them, but display abuse cases as inverted use cases (i.e. black ovals with white text, and actors with black heads).

The latter approach makes it possible to relate abuse cases to use cases using UML associations. For instance, an abuse case may threaten a use case, while a use case might mitigate an abuse case. The latter use case is also referred to as a security use case. Security use cases usually deal with security features.

Security use cases can be threatened by new abuse cases, for which we can find new security use cases to mitigate, etc. etc. In this way, a “game” of play and counterplay enfolds that fits well in a defense in depth strategy.

We should not expect to win this “game”. Instead, we should make a good trade-off between security requirements and other aspects of the system, like usability and development cost. Ideally, these trade-offs are made clearly visible to stakeholders by using a good risk management framework.

Reusing Abuse Cases

Use cases can be abstracted into essential use cases to make them more reusable. There is no reason we couldn’t do the same with abuse cases and security use cases.

It seems to me that this not just possible, but already done. Microsoft’s STRIDE model contains generalized threats, and its SDL Threat Modeling tool automatically identifies which of those are applicable to your situation.

Conclusion

Although abuse cases are a bit different from regular use cases, their main value is that they present information about security risks in a format that may already be familiar to the stakeholders of the software development process. Developers in particular are likely to know them.

This should make it easier for people with little or no security background to start thinking about securing their systems and how to trade-off security and functionality.

However, it seems that threat modeling gives the same advantages as abuse cases. Since threat modeling is supported by tools, it’s little wonder that people prefer that over abuse cases for inclusion in their Security Development Lifecycle.

Book review – Software Security: Building Security In

Dr. Gary McGraw is an authority on software security who has written many security books. This book, Software Security: Building Security In, is the third in a series.

While Exploiting Software: How to Break Code focuses on the black hat side of security, and Building Secure Software: How to Avoid Security Problems the Right Way focuses on the white hat side, this book brings the two perspectives together (see book cover on right).

Chapter 1, Defining a Discipline, explains the security problem that we have with software. It also introduces the three pillars of software security:

  1. Applied Risk Management
  2. Software Security Touchpoints
  3. Knowledge

Chapter 2, A Risk Management Framework, explains that security is all about risks and mitigating them. McGraw argues the need to embed this in an overall risk management framework to systematically identify, rank, track, understand, and mitigate security risks over time. The chapter also explains that security risks must always be placed into the larger business context. The chapter ends with a worked out example.

Chapter 3, Introduction to Software Security Touchpoints, starts the second part of the book, about the touchpoints. McGraw uses this term to denote software security best practices. The chapter presents a high level overview of the touchpoints and explains how both black and white hats must be involved to build secure software.

Chapter 4, Code Review with a Tool, introduces static code analysis with a specialized tool, like Fortify. A history of such tools is given, followed by a bit more detail about Fortify.

Chapter 5, Architectural Risk Analysis, shifts the focus from implementation bugs to design flaws, which account for about half of all security problems. Since design flaws can’t be found by a static code analysis tool, we need to perform a risk analysis based on architecture and design documents. McGraw argues that MicroSoft mistakenly calls this threat modeling, but he seems to have lost that battle.

Chapter 6, Software Penetration Testing, explains that functional testing focuses on what software is supposed to do, and how that is not enough to guarantee security. We also need to focus on what should not happen. McGraw argues that this “negative” testing should be informed by the architectural risk analysis (threat modeling) to be effective. The results of penetration testing should be fed back to the developers, so they can learn from their mistakes.

Chapter 7, Risk-Based Security Testing, explains that while black box penetration testing is helpful, we also need white box testing. Again, this testing should be driven by the architectural risk analysis (threat modeling). McGraw also scorns eXtreme Programming (XP). Personally, I feel that this is based on some misunderstandings about XP.

Chapter 8, Abuse Cases, explains that requirements should not only specify what should happen, in use cases, but what should not, in abuse cases. Abuse cases look at the software from the point of view of an attacker. Unfortunately, this chapter is a bit thin on how to go about writing them.

Chapter 9, Software Security Meets Security Operations, explains that developers and operations people should work closely together to improve security. We of course already knew this from the DevOps movement, but security adds some specific focal points. Some people have recently started talking about DevOpsSec. This chapter is a bit more modest, though, and talks mainly about how operations people can contribute to which parts of software development.

Chapter, 10, An Enterprise Software Security Program, starts the final part of the book. It explains how to introduce security into the software development lifecycle to create a Security Development Lifecycle (SDL).

Chapter 11, Knowledge for Software Security, explains the need for catalogs of security knowledge. Existing collections of security information, like CVE and CERT, focus on vulnerabilities and exploits, but we also need collections for principles, guidelines, rules, attack patterns, and historical risks.

Chapter 12, A Taxonomy of Coding Errors, introduces the 7 pernicious kingdoms of coding errors that can lead to vulnerabilities:

  1. Input Validations and Representation
  2. API Abuse
  3. Security Features
  4. Time and State
  5. Error Handling
  6. Code Quality
  7. Encapsulation

It also mentions the kingdom Environment, but doesn’t give it number 8, since it focuses on things outside the code. For each kingdom, the chapter lists a collection of so-called phyla, with more narrowly defined scope. For instance, the kingdom Time and State contains the phylum File Access Race Condition. This chapter concludes with a comparison with other collections of coding errors, like the 19 Deadly Sins of Software Security and the OWASP Top Ten.

Chapter 13, Annotated Bibliography and References, provides a list of must-read security books and other recommended reading.

The book ends with four appendices: Fortify Source Code Analysis Suite, Tutorial, ITS4 Rules, An Exercise in Risk Analysis: Smurfware, and Glossary. There is a trial version of Fortify included with the book.

All in all, this book provides a very good overview for software developers who want to learn about security. It doesn’t go into enough detail in some cases for you to be able to apply the described practices, but it does teach enough to know what to learn more about and it does tie everything together very nicely.

XACML Vendor: Axiomatics

This is the second in a series of posts where I interview XACML vendors. This time it’s Axiomatics’ turn. Their CTO Erik Rissanen is editor of the XACML 3.0 specification.

Why does the world need XACML? What benefits do your customers realize?

The world needs a standardized way to externalize authorization processing from the rest of the application logic – this is where the XACML standard comes in. Customers have different requirements for implementing externalized authorization and, therefore, can derive different benefits.

Here are some of the key benefits we have seen for customers:

  • The ability to share sensitive data with customers, partners and supply chain members
  • Implement fine grained authorization at every level of the application – presentation, application, middleware and data tiers
  • Deploy applications with clearly audit-able access control
  • Build and deploy applications and services faster than the competition
  • Move workloads more easily to the most efficient compute, storage or data capacity
  • Protect access to applications and resources regardless of where they are hosted
  • Implement access control consistently across all layers of an application as well as across application environments deployed on different platforms
  • Exploit dynamic access controls that are much more flexible than roles

What products do you have in the XACML space?

Axiomatics has three core products today:

  • The Axiomatics Policy Server which is a modular XACML-driven authorization server. It fully implements XACML 2.0 and XACML 3.0 and respects the XACML architecture.
  • The Axiomatics Policy Auditor which is a web-based product administrators and business users alike can use to analyze XACML policies to identify security gaps or create a list of entitlements. Generally, the auditor helps answer the question “How can an access be granted?”
  • The Axiomatics Reverse Query takes on a novel approach to authorization. Where one typically creates binary requests (Can Alice do this?) and the Axiomatics Policy Server would reply with a Yes or No, the Axiomatics Reverse Query helps invert the process to tackle the list question. We have noticed that our customers sometimes want to know the list of users that have access to an application or the list of resources a given user can access. This is what we call the list question or reverse querying.
    The Axiomatics Reverse Query is an SDK that requires integration with a given application. With this in mind, Axiomatics engineering have developed extra glue / integration layers to plug into target environments and products. For instance, Axiomatics will release shortly the Axiomatics Reverse Query for Oracle Virtual Private Database. Axiomatics also uses the SDK to drive authorization inside Windows Server 2012. And there are many more integration options we have yet to explore.

In addition, Axiomatics has now released a free tool and a new language called ALFA, the Axiomatics Language for Authorization. ALFA is a lightweight version of XACML with shorthand notations. It borrows much of its syntax from programming languages developers are most familiar with e.g. Java and C#. The tool is a free plugin for the Eclipse IDE which lets developers author ALFA using the usual Eclipse features such as syntax checking and auto-complete. The plugin eventually generates XACML 3.0 conformant policies on the fly from the ALFA the developers write. Axiomatics published a video on its YouTube channel showing how to use the tool.

What versions of the spec do you support? What optional parts? What profiles?

Axiomatics fully supports XACML 2.0 and XACML 3.0 including all optional profiles as specified in our attestation email.

What sets your product(s) apart from the competition?

Axiomatics has historically been what we could call a pure play XACML vendor. This reflects our dedication to the standard and the fact that Axiomatics implements the XACML core and all profiles – no other vendor has adopted such a comprehensive strategy. Furthermore, Axiomatics only uses the XACML policy language, rather than attempting to convert between XACML and one or more proprietary, legacy policy language formats. The comprehensiveness of the XACML policy language gives customers the most flexibility – as well as interoperability – across a multitude of applications and usage scenarios.

This also made Axiomatics a very generic solution for all things fine-grained authorization. This means the Axiomatics solution can be applied to any type of application, in particular .NET or J2SE/J2EE applications but also increasingly COTS such as SharePoint and databases such as Oracle VPD.

Axiomatics also leverages the key benefits of the XACML architecture to provide a very modular set of products. This means our core engine can be plugged into a various set of frameworks extremely easily: the authorization engine can be embedded or exposed as a web service (SOAP, REST, Thrift…). It also means our products scale extremely well and allow for a single point of management with literally hundreds of decision points and as many enforcement points. This makes our product the fastest, most elegant approach to enterprise authorization.

Axiomatics’ auditing capablities are quite unique too: with the Policy Auditor, it is possible to know what could possibly happen, rather a simple audit of what did actually happen. This means it is easier than ever to produce reports that will keep auditors satisfied the enterprise is correctly protected.

Lastly, Axiomatics has over 6 years experience in the area and is always listening to its customers. As a result, new products have been designed to better address customer needs. One such example is our Axiomatics Reverse Query which reverses the authorization process to be able to tackle a new series of authorization requirements our customers in the financial sector had. Instead of getting yes/no answers, these customers wanted a list of resources a user can access (e.g. a list of bank accounts) or a list of employees who can view a given piece of information. By actively listening to our customers we are able to deliver new innovative products that best match their needs.

What customers use your product(s)? What is your biggest deployment?

Axiomatics has several Fortune 50 customers. Some of the world’s largest banks and enterprises are Axiomatics customers. Axiomatics customers are based in the US and Europe mainly. One famous customer where Axiomatics is used intensively is PayPal. It is probably Axiomatics’ current biggest deployment in terms of transactions.

A US-based bank has also deployed Axiomatics products across three continents in order to protect trading applications.

What programming languages do you support? Will you support the upcoming REST and JSON profiles?

Axiomatics supports Java and C#. Axiomatics has been used in customer deployments with other languages such as Python.

Axiomatics is active in defining the new REST profile of the XACML TC and will try to align with it as much as possible. Axiomatics is also leading the design of a JSON-based PEP-PDP interaction. JSON as well as Thrift are likely to be the next communication protocols supported.

Do you support OpenAz? Spring Security? Other open source efforts?

Axiomatics does not currently support OpenAZ but has been watching the specification in order to eventually take part. Axiomatics already supports Spring Security. In addition, there is a new open source initiative aimed at defining a standard PEP API which Axiomatics and other vendors are taking part in.

How easy is it to write a PEP for your product(s)? And a PIP? How long does an implementation of your product(s) usually take?

Should customers decide to write a custom PEP rather than use an off-the-shelf PEP, they can use a Java or C# SDK to quickly write PEPs. Axiomatics has published a video explaining how to write a PEP in 5 minutes and 20 lines of code.

An implementation of our product can take from 1 week to 3 months or more depending on the customer requirements, the complexity of the desired architecture, and the number of integration points.

Can your product(s) be embedded (i.e. run in-process)?

The Axiomatics PDP can be embedded. Customers sometimes choose this approach to achieve even greater levels of performance.

What optimizations have you made? Can you share performance numbers?

There are many factors such as number of policies, complexity of policies, number of PIP look-ups and others that have an effect on performance. One of our customers shared the result of their internal product evaluation where they reached 30.000 requests per second.

The Axiomatics PDP is also used to secure transactions for several hundred million users and protect the medical records of all 9 million Swedish citizens.

Outbound Passwords

Much has been written on how to securely store passwords. This sort of advice deals with the common situation where your users present their passwords to your application in order to gain access.

But what if the roles are reversed, and your application is the one that needs to present a password to another application? For instance, your web application must authenticate with the database server before it can retrieve data.

Such credentials are called outbound passwords.

Outbound Passwords Must Be Stored Somewhere

Outbound passwords must be treated like any other password. For instance, they must be as strong as any password.

But there is one exception to the usual advice about passwords: outbound passwords must be written down somehow. You can’t expect a human to type in a password every time your web application connects to the database server.

This begs the question of how we’re supposed to write the outbound password down.

Storing Outbound Passwords In Code Is A Bad Idea

The first thing that may come to mind is to simply store the outbound password in the source code. This is a bad idea.

With access to source code, the password can easily be found using a tool like grep. But even access to binary code gives an attacker a good chance of finding the password. Tools like javap produce output that makes it easy to go through all strings. And since the password must be sufficiently strong, an attacker can just concentrate on the strings with the highest entropy and try those as passwords.

To add insult to injury, once a hard-coded password is compromised, there is no way to recover from the breach without patching the code!

Solution #1: Store Encrypted Outbound Passwords In Configuration Files

So the outbound password must be stored outside of the code, and the code must be able to read it. The most logical place then, is to store it in a configuration file.

To prevent an attacker from reading the outbound password, it must be encrypted using a strong encryption algorithm, like AES. But now we’re faced with a different version of the same problem: how does the application store the encryption key?

One option is to store the encryption key in a separate configuration file, with stricter permissions set on it. That way, most administrators will not be able to access it. This scheme is certainly not 100% safe, but at least it will keep casual attackers out.

A more secure option is to use key management services, perhaps based on the Key Management Interoperability Protocol (KMIP).

In this case, the encryption key is not stored with the application, but in a separate key store. KMIP also supports revoking keys in case of a breach.

Solution #2: Provide Outbound Passwords During Start Up

An even more secure solution is to only store the outbound password in memory. This requires that administrators provide the password when the application starts up.

You can even go a step further and use a split-key approach, where multiple administrators each provide part of a key, while nobody knows the whole key. This approach is promoted in the PCI DSS standard.

Providing keys at start up may be more secure than storing the encryption key in a configuration file, but it has a big drawback: it prevents automatic restarts. The fact that humans are involved at all makes this approach impractical in a cloud environment.

Creating Outbound Passwords

If your application has some control over the external system that it needs to connect to, it may be able to determine the outbound password, just like your users define their passwords for your application.

For instance, in a multi-tenant environment, data for the tenants might be stored in separate databases, and your application may be able to pick an outbound password for each one of those as it creates them.

Created outbound passwords must be sufficiently strong. One way to accomplish that is to use random strings, with characters from different character classes. Another approach is Diceware.

Make sure to use a good random number generator. In Java, for example, prefer SecureRandom over plain old Random.

XACML Vendor: eNitiatives

This is a new series of posts where I interview XACML vendors. The first one that was kind enough to participate was eNitiatives.

Why does the world need XACML? What benefits do your customers realize?

Our primary customers are in Government, Defense, Intelligence, Telecommunications, and Health, with some key multinationals. All of these customers are concerned about providing fine grained authorizations for controlled access to digital assets. In the Defense, Government, and Intelligence sectors this is especially critical.

What products do you have in the XACML space?

We have two current products where we have implemented XACML, and one upcoming:

  1. Firstly we have ViewDS. This is our LDAPv3, X.500 and ACP 133(D) Directory server. Here we have built a PEP into our Directory server and use XACML to provide Policy Based Access Control to all data that we store within our Directory. Our Directory includes an Indexing and Search engine supporting 24 different types of searching and matching and fully supports XPath queries and can understand XML content.

    ViewDS has a Management Agent used to control and manage content in our Directory Server. In our latest release, it now has an inbuilt Policy Administration Point tool. ViewDS also has an inbuilt Policy Decision Point. ViewDS thus acts as both an Identity Store and a Policy Information Point as policies can be stored in the Directory schema and are treated as Directory Attributes. As well as XACMLv3, ViewDS fully supports RBAC, Label Based Access Control and Time Based Access Control

  2. Our Second Product is known as ViewDS Access Sentinel. Access Sentinel is an XACMLv3 Policy Decision Point designed to be used for externalizing authorization policy for external applications. Access Sentinel provides a combined PDP, PIP, two PAPs and a number of PEPs off the shelf. ViewDS Access Sentinel can use either ViewDS as its identity store, or an external LDAP Directory or Virtual Directory as its LDAP Identity Store.

    ViewDS also supports multiple schemas and with its inbuilt join engine, ViewDS Access Sentinel plus ViewDS Discovery server offers the capability to also join other data from external services. We have a number of PEPs available and will be announcing some new ones in our v7.3 release. We also offer a second PAP tool for providing fully delegated policy creation

  3. Also in our next release (ViewDS v7.3) we will be launching a third product: ViewDS Identity Bridge. ViewDS Identity Bridge is a bidirectional synchronization and provisioning engine. This will also support XACMLv3

ViewDS and ViewDS Access Sentinel are available for Oracle Solaris 11g, two versions of GNU/Linux and Windows Server 2008 and Windows 7. Other implementations on versions of UNIX are available.

What versions of the spec do you support? What optional parts? What profiles?

In ViewDS version 7.2 (the current release) we support the core specification minus XPath, the Administration and Delegation Profile, the Hierarchical Resource Profile, the Multiple Decision Profile, the Privacy Profile, the Intellectual Property Control Profile and the Export Compliance-US Profile.

An internal build of ViewDS Access Sentinel already supports XPath version 1.0, and we have now built support for XPath in our two XACML PAPs. This capability will be in the next release due out in September. The next release will also support the administration and delegation profile and the multiple decision profile. We are also looking at an implementation of the Export ITAR Profile for a specific US Customer. We are also considering the GeoXACML extensions.

What sets your product(s) apart from the competition?

Unlike other vendors we do not require an external database license such as SQL Server or Oracle to store policies or require an external server. Our PDP, PIP, Attribute Identity Store and PAP are all in the one platform.

This means our product performs well, as all activities are internal function calls. That is, there is no external processing. Because we treat XACML policies as standard directory attributes (ViewDS itself fully supports XML), we can use standard directory protocols to distribute policies which are kept fully in sync with the associated identity attributes. Our Policy Administration Point tools also allow the creation of policies without the need to write any XML and support a capability known as Named Expressions.

What customers use your product(s)? What is your biggest deployment?

All of our ViewDS customers worldwide (our product is in use in Defense, Intelligence, Government, Aviation, Health and multinational corporations with installations in 16 countries) that upgrade to ViewDS v7.2 released in March will have the full capability of XACMLv3 in this release. Roughly 30% of our customers have upgraded already. Our largest implementation covers 26M identities, but our product has been tested with up to hundreds of millions of entries.

ViewDS Access Sentinel was released 3 months ago as a stand-alone product. So far we have a small number of installations in Australia and North America in the Government and Defense sectors.

What programming languages do you support? Will you support the upcoming REST and JSON profiles?

For PEP development, in our V7.2 release we currently support C#/.NET. We now have a PEP library for Java complete but not yet released. This will be provided to customers for the v7.3 release due in September.

Our current plan is to support both the REST Profile and the JSON Profile. However, the REST draft is not publicly available, has not been listed in the working group’s deliverables and hasn’t even been accepted by the working group yet according to the draft itself. This Working Draft (WD) has been produced by one or more TC Members; but we understand has not yet been voted on by the TC or approved as a Committee Draft (Committee Specification Draft or a Committee Note Draft).

Do you support OpenAz? Spring Security? Other open source efforts?

We are currently involved with other XACML vendors (BitKoo/Quest/Dell and Axiomatics) led by Felix Gaethgens from Axiomatics in an open source effort that is getting underway to create a PEP API and implementation for XACML version 3.0 among other things. We are not involved in any other open source effort.

However, we partner with Ping Identity for integration of Authentication and Authorization.

How easy is it to write a PEP for your product(s)? And a PIP? How long does an implementation of your product(s) usually take?

We provide a C#/.NET library known as PDP Liaison and now have a Java equivalent available to allow application vendors to create PEPs in a matter of days. We are currently considering making these Open Source solutions.

We expect a customer to be live in test mode and creating policies in 3 days depending on whether they are using ViewDS as the Identity Store or an external Identity store such as Active Directory.

Can your product(s) be embedded (i.e. run in-process)?

The PDP runs in a separate process.

What optimizations have you made? Can you share performance numbers?

Performance will vary depending on the number and nature of the policies, but version 7.2 has been clocked at 3650 XACML authorization requests per second with a single quad-core Intel Xeon E5430 CPU at 2.66 Ghz.

Visualizing Code Coverage in Eclipse with EclEmma

Last time, we saw how Behavior-Driven Development (BDD) allows us to work towards a concrete goal in a very focused way.

In this post, we’ll look at how the big BDD and the smaller TDD feedback loops eliminate waste and how you can visualize that waste using code coverage tools like EclEmma to see whether you execute your process well.

The Relation Between BDD and TDD

Depending on your situation, running BDD scenarios may take a lot of time. For instance, you may need to first create a Web Application Archive (WAR), then start a web server, deploy your WAR, and finally run your automated acceptance tests using Selenium.

This is not a convenient feedback cycle to run for every single line of code you write.

So chances are that you’ll write bigger chunks of code. That increases the risk of introducing mistakes, however. Baby steps can mitigate that risk. In this case, that means moving to Test-First programming, preferably Test-Driven Development (TDD).

The link between a BDD scenario and a bunch of unit tests is the top-down test. The top-down test is a translation of the BDD scenario into test code. From there, you descend further down into unit tests using regular TDD.

This translation of BDD scenarios into top-down tests may seem wasteful, but it’s not.

Top-down tests only serve to give the developer a shorter feedback cycle. You should never have to leave your IDE to determine whether you’re done. The waste of the translation is more than made up for by the gains of not having to constantly switch to the larger BDD feedback cycle. By doing a little bit more work, you end up going faster!

If you’re worried about your build time increasing because of these top-down tests, you may even consider removing them after you’ve made them pass, since their risk-reducing job is then done.

Both BDD and TDD Eliminate Waste Using JIT Programming

Both BDD and TDD operate on the idea of Just-In-Time (JIT) coding. JIT is a Lean principle for eliminating waste; in this case of writing unnecessary code.

There are many reasons why you’d want to eliminate unnecessary code:

  • Since it takes time to write code, writing less code means you’ll be more productive (finish more stories per iteration)
  • More code means more bugs
  • In particular, more code means more opportunities for security vulnerabilities
  • More code means more things a future maintainer must understand, and thus a higher risk of bugs introduced during maintenance due to misunderstandings

Code Coverage Can Visualize Waste

With BDD and TDD in your software development process, you expect less waste. That’s the theory, at least. How do we prove this in practice?

Well, let’s look at the process:

  1. BDD scenarios define the acceptance criteria for the user stories
  2. Those BDD scenarios are translated into top-down tests
  3. Those top-down tests lead to unit tests
  4. Finally, those unit tests lead to production code

The last step is easiest to verify: no code should have been written that wasn’t necessary for making some unit test pass. We can prove that by measuring code coverage while we execute the unit tests. Any code that is not covered is by definition waste.

EclEmma Shows Code Coverage in Eclipse

We use Cobertura in our Continuous Integration build to measure code coverage. But that’s a long feedback cycle again.

Therefore, I like to use EclEmma to measure code coverage while I’m in the zone in Eclipse.

EclEmma turns covered lines green, uncovered lines red, and partially covered lines yellow.

You can change these colors using Window|Preferences|Java|Code coverage. For instance, you could change Full Coverage to white, so that the normal case doesn’t introduce visual clutter and only the exceptions stand out.

The great thing about EclEmma is that it let’s you measure code coverage without making you change the way you work.

The only difference is that instead of choosing Run As|JUnit Test (or Alt+Shift+X, T), you now choose Coverage As|JUnit test (or Alt+Shift+E, T). To re-run the last coverage, use Ctrl+Shift+F11 (instead of Ctrl+F11 to re-run the last launch).

If your fingers are conditioned to use Alt+Shift+X, T and/or Ctrl+F11, you can always change the key bindings using Window|Preferences|General|Keys.

In my experience, the performance overhead of EclEmma is low enough that you can use it all the time.

EclEmma Helps You Monitor Your Agile Process

The feedback from EclEmma allows you to immediately see any waste in the form of unnecessary code. Since there shouldn’t be any such waste if you do BDD and TDD well, the feedback from EclEmma is really feedback on how well you execute your BDD/TDD process. You can use this feedback to hone your skills and become the best developer you can be.

Behavior-Driven Development (BDD) with JBehave, Gradle, and Jenkins

Behavior-Driven Development (BDD) is a collaborative process where the Product Owner, developers, and testers cooperate to deliver software that brings value to the business.

BDD is the logical next step up from Test-Driven Development (TDD).

Behavior-Driven Development

In essence, BDD is a way to deliver requirements. But not just any requirements, executable ones! With BDD, you write scenarios in a format that can be run against the software to ascertain whether the software behaves as desired.

Scenarios

Scenarios are written in Given, When, Then format, also known as Gherkin:

Given the ATM has $250
And my balance is $200
When I withdraw $150
Then the ATM has $100
And my balance is $50

Given indicates the initial context, When indicates the occurrence of an interesting event, and Then asserts an expected outcome. And may be used to in place of a repeating keyword, to make the scenario more readable.

Given/When/Then is a very powerful idiom, that allows for virtually any requirement to be described. Scenarios in this format are also easily parsed, so that we can automatically run them.

BDD scenarios are great for developers, since they provide quick and unequivocal feedback about whether the story is done. Not only the main success scenario, but also alternate and exception scenarios can be provided, as can abuse cases. The latter requires that the Product Owner not only collaborates with testers and developers, but also with security specialists. The payoff is that it becomes easier to manage security requirements.

Even though BDD is really about the collaborative process and not about tools, I’m going to focus on tools for the remainder of this post. Please keep in mind that tools can never save you, while communication and collaboration can. With that caveat out of the way, let’s get started on implementing BDD with some open source tools.

JBehave

JBehave is a BDD tool for Java. It parses the scenarios from story files, maps them to Java code, runs them via JUnit tests, and generates reports.

Eclipse

JBehave has a plug-in for Eclipse that makes writing stories easier with features such as syntax highlighting/checking, step completion, and navigation to the step implementation.

JUnit

Here’s how we run our stories using JUnit:

@RunWith(AnnotatedEmbedderRunner.class)
@UsingEmbedder(embedder = Embedder.class, generateViewAfterStories = true,
    ignoreFailureInStories = true, ignoreFailureInView = false, 
    verboseFailures = true)
@UsingSteps(instances = { NgisRestSteps.class })
public class StoriesTest extends JUnitStories {

  @Override
  protected List<String> storyPaths() {
    return new StoryFinder().findPaths(
        CodeLocations.codeLocationFromClass(getClass()).getFile(),
        Arrays.asList(getStoryFilter(storyPaths)), null);
  }

  private String getStoryFilter(String storyPaths) {
    if (storyPaths == null) {
      return "*.story";
    }
    if (storyPaths.endsWith(".story")) {
      return storyPaths;
    }
    return storyPaths + ".story";
  }

  private List<String> specifiedStoryPaths(String storyPaths) {
    List<String> result = new ArrayList<String>();
    URI cwd = new File("src/test/resources").toURI();
    for (String storyPath : storyPaths.split(File.pathSeparator)) {
      File storyFile = new File(storyPath);
      if (!storyFile.exists()) {
        throw new IllegalArgumentException("Story file not found: " 
          + storyPath);
      }
      result.add(cwd.relativize(storyFile.toURI()).toString());
    }
    return result;
  }

  @Override
  public Configuration configuration() {
    return super.configuration()
        .useStoryReporterBuilder(new StoryReporterBuilder()
            .withFormats(Format.XML, Format.STATS, Format.CONSOLE)
            .withRelativeDirectory("../build/jbehave")
        )
        .usePendingStepStrategy(new FailingUponPendingStep())
        .useFailureStrategy(new SilentlyAbsorbingFailure());
  }

}

This uses JUnit 4’s @RunWith annotation to indicate the class that will run the test. The AnnotatedEmbedderRunner is a JUnit Runner that JBehave provides. It looks for the @UsingEmbedder annotation to determine how to run the stories:

  • generateViewAfterStories instructs JBehave to create a test report after running the stories
  • ignoreFailureInStories prevents JBehave from throwing an exception when a story fails. This is essential for the integration with Jenkins, as we’ll see below

The @UsingSteps annotation links the steps in the scenarios to Java code. More on that below. You can list more than one class.

Our test class re-uses the JUnitStories class from JBehave that makes it easy to run multiple stories. We only have to implement two methods: storyPaths() and configuration().

The storyPaths() method tells JBehave where to find the stories to run. Our version is a little bit complicated because we want to be able to run tests from both our IDE and from the command line and because we want to be able to run either all stories or a specific sub-set.

We use the system property bdd.stories to indicate which stories to run. This includes support for wildcards. Our naming convention requires that the story file names start with the persona, so we can easily run all stories for a single persona using something like -Dbdd.stories=wanda_*.

The configuration() method tells JBehave how to run stories and report on them. We need output in XML for further processing in Jenkins, as we’ll see below.

One thing of interest is the location of the reports. JBehave supports Maven, which is fine, but they assume that everybody follows Maven conventions, which is really not. The output goes into a directory called target by default, but we can override that by specifying a path relative to the target directory. We use Gradle instead of Maven, and Gradle’s temporary files go into the build directory, not target. More on Gradle below.

Steps

Now we can run our stories, but they will fail. We need to tell JBehave how to map the Given/When/Then steps in the scenarios to Java code. The Steps classes determine what the vocabulary is that can be used in the scenarios. As such, they define a Domain Specific Language (DSL) for acceptance testing our application.

Our application has a RESTful interface, so we wrote a generic REST DSL. However, due to the HATEOAS constraint in REST, a client needs a lot of calls to discover the URIs that it should use. Writing scenarios gets pretty boring and repetitive that way, so we added an application-specific DSL on top of the REST DSL. This allows us to write scenarios in terms the Product Owner understands.

Layering the application-specific steps on top of generic REST steps has some advantages:

  • It’s easy to implement new application-specific DSL, since they only need to call the REST-specific DSL
  • The REST-specific DSL can be shared with other projects

Gradle

With the Steps in place, we can run our stories from our favorite IDE. That works great for developers, but can’t be used for Continuous Integration (CI).

Our CI server runs a headless build, so we need to be able to run the BDD scenarios from the command line. We automate our build with Gradle and Gradle can already run JUnit tests. However, our build is a multi-project build. We don’t want to run our BDD scenarios until all projects are built, a distribution is created, and the application is started.

So first off, we disable running tests on the project that contains the BDD stories:

test {
  onlyIf { false } // We need a running server
}

Next, we create another task that can be run after we start our application:

task acceptStories(type: Test) {
  ignoreFailures = true
  doFirst {
    // Need 'target' directory on *nix systems to get any output
    file('target').mkdirs()

    def filter = System.getProperty('bdd.stories') 
    if (filter == null) {
      filter = '*'
    }
    def stories = sourceSets.test.resources.matching { 
      it.include filter
    }.asPath
    systemProperty('bdd.stories', stories)
  }
}

Here we see the power of Gradle. We define a new task of type Test, so that it already can run JUnit tests. Next, we configure that task using a little Groovy script.

First, we must make sure the target directory exists. We don’t need or even want it, but without it, JBehave doesn’t work properly on *nix systems. I guess that’s a little Maven-ism 😦

Next, we add support for running a sub-set of the stories, again using the bdd.stories system property. Our story files are located in src/test/resources, so that we can easily get access to them using the standard Gradle test source set. We then set the system property bdd.stories for the JVM that runs the tests.

Jenkins

So now we can run our BDD scenarios from both our IDE and the command line. The next step is to integrate them into our CI build.

We could just archive the JBehave reports as artifacts, but, to be honest, the reports that JBehave generates aren’t all that great. Fortunately, the JBehave team also maintains a plug-in for the Jenkins CI server. This plug-in requires prior installation of the xUnit plug-in.

After installation of the xUnit and JBehave plug-ins into jenkins, we can configure our Jenkins job to use the JBehave plug-in. First, add an xUnit post-build action. Then, select the JBehave test report.

With this configuration, the output from running JBehave on our BDD stories looks just like that for regular unit tests:

Note that the yellow part in the graph indicates pending steps. Those are used in the BDD scenarios, but have no counterpart in the Java Steps classes. Pending steps are shown in the Skip column in the test results:

Notice how the JBehave Jenkins plug-in translates stories to tests and scenarios to test methods. This makes it easy to spot which scenarios require more work.

Although the JBehave plug-in works quite well, there are two things that could be improved:

  • The output from the tests is not shown. This makes it hard to figure out why a scenario failed. We therefore also archive the JUnit test report
  • If you configure ignoreFailureInStories to be false, JBehave throws an exception on a failure, which truncates the XML output. The JBehave Jenkins plug-in can then no longer parse the XML (since it’s not well formed), and fails entirely, leaving you without test results

All in all these are minor inconveniences, and we ‘re very happy with our automated BDD scenarios.

Software Development and Security

It seems that not many software developers are interested in security. One reason may be that security is a negative feature. Another could be that developers don’t see how security relates to their daily activities. Let’s look at a detailed example that sheds some light on this relation.

Example: Crashing Tetris

My employer, EMC, takes security seriously. Besides the annual security awareness training that every employee has to take, software developers are required to take additional security courses, so that they understand the Security Development Lifecycle. In one of those courses, security guru Hugh Thompson tells the following story.

While on an airplane, he found a Tetris game in the on-board entertainment system. The game showed the next blocks to drop in a preview pane. The game’s settings had up and down buttons to increase or decrease the number of preview blocks.

Using the up button, the number could only be increased to four. However, using the telephone key pad, Thompson could enter 5 and get it accepted.

No higher digits were accepted from the telephone, but now that the number was five, the up button on the screen happily increased the number further.

He increased the number all the way up to 127. The next time he pressed the up button, the screen went black. And so did the screen next to him. And everywhere else in the plane. Zero availability.

Exploits Use Vulnerabilities, Which Come From Bugs

How did this happen? The answer is simple: there were some bugs in the application that were abused in a systematic manner. In the security world, such a bug is referred to as a vulnerability, and the abuse of them to decrease security is known as an exploit.

There is nothing inherently “security related” about vulnerabilities. In the example, the first mistake was that the two interfaces each had their own logic for manipulating the model, a clear violation of DRY. The second was the off-by-one error in the telephone interface. Next, the logic for the up button only checked for the specific boundary value four, instead of for four and anything larger. The final mistake was a missing check for integer overflow. These four more or less innocent bugs combined to form a vulnerability that Thompson exploited.

Certain bugs are more likely to lead to vulnerabilities than others. Two notorious examples are Buffer Overflow and SQL Injection. Luckily, many of such bugs are easily prevented. Good tools and a little awareness on the side of the developer go a long way.

Conclusion: Less Bugs Means More Secure

If vulnerabilities come from bugs, then we need a relentless focus on preventing and eliminating bugs in order to make our applications more secure.

With that insight, we’re firmly back in the land of software development. Security isn’t the big scary monster we developers sometimes think it is.