Blogger: Ramon Krikken

Many different conference tracks, many different perspectives on 'security' and how to best implement it. I spent most of my time in the Service-Oriented Architecture (SOA) track, looking for little nuggets of wisdom to help with my upcoming SOA security overview, and I certainly did find some. There were - luckily - no huge upsets, but there were certainly lots of questions on how to to implement controls in a service-oriented environment. What was once only the question of what Web Services standards to use, has now evolved to discussions on everything from high-level architecture to the minutiae of security token translations.

One of the discussions in SOA security revolves around the location of controls. In general the architecture is best served if most controls, such as authentication and authorization, are externalized from the application code. It creates a separation of concerns, and usually makes management and auditing more straightforward. So some of the different infrastructure components, like web services modules and the XML gateways, support access control, encryption, and data validation features. Some vendors would like us to believe that pushing all this functionality into their well-packaged, standards-based solution is going to solve the 'security problem,' but does it?

It all works out well as long as we can - in the true spirit of service orientation - view the service as a black box, but that isn't necessarily possible from a security perspective. Certain functionality, like the compute-intensive XML schema validation, is an ideal candidate for infrastructure security, and so is service-to-service authentication. User authorization is all over the map depending on its granularity and requirements for data-awareness. With encryption it also depends on whether we're talking data transport or storage. Service-enabling legacy applications also throws us a curve-ball because of, amongst things, the need for identity and access token mapping that take us into the darkness of the black-box service.

In other words, both applying controls in service orientation, and applying service-oriented principles to security, aren't necessarily as straightforward as some may want us to believe. Security professionals probably already had a feeling this would be the case; we're a bunch of skeptics, after all. But if it's the case that enterprise architecture is far ahead of security architecture in SOA planning or implementation, then there may be some misunderstanding in the organization on how to secure the infrastructure and services. At the surface, and in the common case, the decision to put controls at the infrastructure level seems simple. The devil, it appears, is very much in the details that are invisible to us in some of the higher-level architectural discussions.

Fortunately, all is not lost. We may have thought that 'the SOA train has left the station, and security is not on board,' but it now appears - at least from Burton Group's research - that the train isn't necessarily all too far down the tracks yet. We need to work with the architects to create a security strategy that matures along with the other aspects of SOA implementation, work with the development team to overcome the challenges of building security into the SDLC, and most of all, work with ourselves to make sure we're able to apply consistent principles of information assurance no matter what the next best thing in SOA technology is. There is time to get things right, and the best time to start is now. 

Blogger: Ramon Krikken

Many different conference tracks, many different perspectives on 'security' and how to best implement it. I spent most of my time in the Service-Oriented Architecture (SOA) track, looking for little nuggets of wisdom to help with my upcoming SOA security overview, and I certainly did find some. There were - luckily - no huge upsets, but there were certainly lots of questions on how to to implement controls in a service-oriented environment. What was once only the question of what Web Services standards to use, has now evolved to discussions on everything from high-level architecture to the minutiae of security token translations.

One of the discussions in SOA security revolves around the location of controls. In general the architecture is best served if most controls, such as authentication and authorization, are externalized from the application code. It creates a separation of concerns, and usually makes management and auditing more straightforward. So some of the different infrastructure components, like web services modules and the XML gateways, support access control, encryption, and data validation features. Some vendors would like us to believe that pushing all this functionality into their well-packaged, standards-based solution is going to solve the 'security problem,' but does it?

It all works out well as long as we can - in the true spirit of service orientation - view the service as a black box, but that isn't necessarily possible from a security perspective. Certain functionality, like the compute-intensive XML schema validation, is an ideal candidate for infrastructure security, and so is service-to-service authentication. User authorization is all over the map depending on its granularity and requirements for data-awareness. With encryption it also depends on whether we're talking data transport or storage. Service-enabling legacy applications also throws us a curve-ball because of, amongst things, the need for identity and access token mapping that take us into the darkness of the black-box service.

In other words, both applying controls in service orientation, and applying service-oriented principles to security, aren't necessarily as straightforward as some may want us to believe. Security professionals probably already had a feeling this would be the case; we're a bunch of skeptics, after all. But if it's the case that enterprise architecture is far ahead of security architecture in SOA planning or implementation, then there may be some misunderstanding in the organization on how to secure the infrastructure and services. At the surface, and in the common case, the decision to put controls at the infrastructure level seems simple. The devil, it appears, is very much in the details that are invisible to us in some of the higher-level architectural discussions.

Fortunately, all is not lost. We may have thought that 'the SOA train has left the station, and security is not on board,' but it now appears - at least from Burton Group's research - that the train isn't necessarily all too far down the tracks yet. We need to work with the architects to create a security strategy that matures along with the other aspects of SOA implementation, work with the development team to overcome the challenges of building security into the SDLC, and most of all, work with ourselves to make sure we're able to apply consistent principles of information assurance no matter what the next best thing in SOA technology is. There is time to get things right, and the best time to start is now. 

In this first post, I cover the planning process and various considerations that anyone - from a small “mom and pop” shop to a large enterprise – should take into account for successful deployment.

1) What problem(s) are you trying to solve? What are you trying to achieve?

It should come as no surprise that this is the first step but surprisingly it’s a step that is sometimes ignored or not enough time and thought are spent against it in the rush to virtualize. Without really understanding what problem you’re trying to solve and what you’re trying to achieve, how will you ever know that you’ve been successful? Some typical reasons to virtualize:

• Server consolidation and cost savings. ROI and TCO.
• Efficient resource utilization. Chargeback model and measurement.
• Cost-effective growth strategy. Cost avoidance.

2) What resources do you have and what additional resources do you need?

You need to understand your current environment before adding virtualization to the mix. Peel back the onion and look at historical performance. You may not have the right hardware to handle an increase in virtual servers.

Factor in the pattern of the behavior of servers, whether they are running hot during business hours or at night, peak cycles, etc. Are they CPU-intensive or is the gating factor disk or memory or a combination of these? This information forms the performance baseline you must factor into any virtualization capacity planning.

I can’t emphasize enough how important it is to have a capacity plan. People tend to virtualize but don’t always have a capacity plan in place to know when they’re running at full.

Beyond computing assets, you need to look at staffing as well. How will virtualization effect staff resource utilization? Virtualization, done the right way, should gain you efficiencies on the staffing side as well, freeing up resources for other initiatives. But in order to do it the “right way”, that takes an investment in training that should always be factored into your planning.

3) What are your success metrics?

Make sure to draft a document to formally measure your success before, during, and after implementing a virtualized environment. This relates back to the problem you were trying to solve. Depending on what you need to measure, you need to plan for tools and processes to make this a reality.

In the next post, I’ll talk about roadblocks to successful virtualization deployment and how to avoid them.

ShareThis

In this first post, I cover the planning process and various considerations that anyone - from a small “mom and pop” shop to a large enterprise – should take into account for successful deployment.

1) What problem(s) are you trying to solve? What are you trying to achieve?

It should come as no surprise that this is the first step but surprisingly it’s a step that is sometimes ignored or not enough time and thought are spent against it in the rush to virtualize. Without really understanding what problem you’re trying to solve and what you’re trying to achieve, how will you ever know that you’ve been successful? Some typical reasons to virtualize:

• Server consolidation and cost savings. ROI and TCO.
• Efficient resource utilization. Chargeback model and measurement.
• Cost-effective growth strategy. Cost avoidance.

2) What resources do you have and what additional resources do you need?

You need to understand your current environment before adding virtualization to the mix. Peel back the onion and look at historical performance. You may not have the right hardware to handle an increase in virtual servers.

Factor in the pattern of the behavior of servers, whether they are running hot during business hours or at night, peak cycles, etc. Are they CPU-intensive or is the gating factor disk or memory or a combination of these? This information forms the performance baseline you must factor into any virtualization capacity planning.

I can’t emphasize enough how important it is to have a capacity plan. People tend to virtualize but don’t always have a capacity plan in place to know when they’re running at full.

Beyond computing assets, you need to look at staffing as well. How will virtualization effect staff resource utilization? Virtualization, done the right way, should gain you efficiencies on the staffing side as well, freeing up resources for other initiatives. But in order to do it the “right way”, that takes an investment in training that should always be factored into your planning.

3) What are your success metrics?

Make sure to draft a document to formally measure your success before, during, and after implementing a virtualized environment. This relates back to the problem you were trying to solve. Depending on what you need to measure, you need to plan for tools and processes to make this a reality.

In the next post, I’ll talk about roadblocks to successful virtualization deployment and how to avoid them.

ShareThis

In this first post, I cover the planning process and various considerations that anyone - from a small “mom and pop” shop to a large enterprise – should take into account for successful deployment.

1) What problem(s) are you trying to solve? What are you trying to achieve?

It should come as no surprise that this is the first step but surprisingly it’s a step that is sometimes ignored or not enough time and thought are spent against it in the rush to virtualize. Without really understanding what problem you’re trying to solve and what you’re trying to achieve, how will you ever know that you’ve been successful? Some typical reasons to virtualize:

• Server consolidation and cost savings. ROI and TCO.
• Efficient resource utilization. Chargeback model and measurement.
• Cost-effective growth strategy. Cost avoidance.

2) What resources do you have and what additional resources do you need?

You need to understand your current environment before adding virtualization to the mix. Peel back the onion and look at historical performance. You may not have the right hardware to handle an increase in virtual servers.

Factor in the pattern of the behavior of servers, whether they are running hot during business hours or at night, peak cycles, etc. Are they CPU-intensive or is the gating factor disk or memory or a combination of these? This information forms the performance baseline you must factor into any virtualization capacity planning.

I can’t emphasize enough how important it is to have a capacity plan. People tend to virtualize but don’t always have a capacity plan in place to know when they’re running at full.

Beyond computing assets, you need to look at staffing as well. How will virtualization effect staff resource utilization? Virtualization, done the right way, should gain you efficiencies on the staffing side as well, freeing up resources for other initiatives. But in order to do it the “right way”, that takes an investment in training that should always be factored into your planning.

3) What are your success metrics?

Make sure to draft a document to formally measure your success before, during, and after implementing a virtualized environment. This relates back to the problem you were trying to solve. Depending on what you need to measure, you need to plan for tools and processes to make this a reality.

In the next post, I’ll talk about roadblocks to successful virtualization deployment and how to avoid them.

ShareThis

I’ve arrived at the Gartner IT Security Summit in lovely Washington, DC. The flight was uneventful (after the intensive security screening and additional measures taken at the gate when departing for Washington National). This year, we’re being hosted at the Gaylord National Resort - it’s like a casino-less piece of Vegas right here on the Potomac.

After sign in and some pre-conference tutorials, I took in the Optenet party - spanish food, spanish wine, spanish dancers. And I even left while I could still walk!

I’ll have lots more to report after things get underway tomorrow (today). Until then… sunset over the Potomac from the atrium at the Gaylord National.

Tags: gartner it security summit, gartner, optenet, gaylord national, security conferences

Moody’s recently launched their Vendor Information Risk (VIR) ratings service. The main objective of this service is to reduce the overall burden of conducting risk assessments for organizations, as well as their service providers. The whole idea being that if Moody’s can do a risk assessment on behalf of multiple subscribers, it can make the assessment process a lot more efficient.  The service provider will not have to go through multiple assessments and the subscribers will share the cost, and therefore have a much lower price point.

Many CISOs I talk to are sick of performing third party risk assessments; it takes up valuable time, is expensive, and most importantly, pulls resources away from doing actual security work within the company. On the other hand service providers are also having a hard time keeping up with these assessments. A compliance manager at a large service provider estimated that they responded to over 300 audit requests in 2007, and that number would be around 400 in 2008. Thus, a service like this could potentially save millions of dollars for service providers and subscribers.

Industry efforts, such as the BITS framework, have so far focused on providing methodologies but haven’t really addressed the issue of building a platform to ensure consistency across assessments. It was refreshing to see this service from Moody’s that endeavors to take the burden off of your shoulders.

If this service delivers on its promise and is able to gain traction, it has the potential to move others in the industry to follow its approach. Although I think this is a great idea, here are some things to keep in mind as you evaluate this service for your organization.   

• It can reduce the time, resources, and cost, if enough people use this service. There is no question that it would be much cheaper, less resource intensive, and a lot quicker to go through a Moody’s report as opposed to doing the assessment yourself. The trick would be to convince your service provider to go through an extensive assessment (Moody’s estimates two-three weeks), spend a substantial amount of money (Moody’s primary business model estimates US$ 23K for the initial rating and US$ 10K/year monitoring, volume purchase agreements are also available) for an assessment that may not be accepted by many other organizations. So the real value for a service provider be to have multiple companies subscribing to the VIR service.
• Ongoing monitoring reduces time consuming remediation follow-ups. I think this is a very valuable part of the service if Moody’s gets it right. They will rely on a quarterly questionnaire and publicly available sources to identify changes in a service provider environment. Thus, it may be a little bit of challenge to get a clear risk picture if the service provider isn’t honest in providing all the necessary information or if the information isn’t public. Having said that, it is still better than the current situation where there is no monitoring at all, just an annual audit. Quarterly follow-ups on previously identified decencies by Moody’s will also ensure that the service provider stays on its toes.
• Consultant expertise and consistency in scoring will improve over time. Having done a lot of assessments myself, you get better and more consistent as you go through the assessment process repeatedly. Although the current consultant skill set seems pretty good and appropriate checks are in place to check for consistency, it is only natural that different consultants will assess differently. Security assessments may be a very different beast compared to the financial assessments that Moody’s is used to doing primarily because there is a decent amount of subjectivity in these assessments. 

Lastly, the pricing structure may also influence the decision making for subscribers as well as service providers. I personally think that the current pricing structure is pretty reasonable for the current marketing conditions. Lets hope Moody’s is able to nail this one. What do you think about this service? Does it address your pain points? Are you skeptical? I’d love to hear your thoughts on this. 

As I touched on in my December posting on Common Criteria, and as Michael Howard discussed in his post on security metrics, trying to objectively quantify and measure “How secure is secure” is far more difficult than one might think. I’d like to share my perspective that there are two “dimensions” useful to consider when characterizing software security metrics: security functional requirements and security engineering quality requirements. While the SDL is focused primarily (but not exclusively) on the latter, both are ultimately important when assessing the security of a given bit of software. However, for reasons I’ll elaborate on below, the SDL does focus on trying to prevent the most common causes of vulnerabilities today and hence looking at the ways in which Microsoft tracks and measures individual products teams’ compliance with SDL requirements offers some interesting fodder for the security metrics debate. I’m not offering a complete solution, but am sharing our experience at Microsoft with measuring how development teams actually follow the SDL. It’s helped us deliver more secure software, and sharing this will hopefully help others as well as putting more data on the table for consideration when discussing security metrics.

Putting aside computer security for just a moment, it’s interesting to look at other ways in which we attempt to measure security in our society. Padlocks offer security protections, and organizations such as the American Standard for Testing and Materials (ASTM) provide standards like F883-04 Standard Performance Specification for Padlocks that characterize padlock security ratings. Prisons provide security protections as well. Prisoners reside in different facilities that vary by security level. The US Bureau of Prisons uses a numbered scale from one to six to represent the security level. Both of these examples are similar in that the threats and risks each of them must protect against are reasonably well understood and relatively static (meaning the threats don’t change much over time). Computer security is still evolving with new classes of attacks still being discovered, and while hackers understand how to exploit known types of vulnerabilities – software developers are still catching up in learning how to modify engineering practices to be resilient against both new and old types of attacks. Hence, metrics are more challenging for computer security.

Several attempts have been made by governments to come up with a security rating system similar to the examples listed above. In the 1980’s, the US Department of Defense created the “Trusted Computer System Evaluation Criteria (TCSEC)” that tried to establish a standard for measure operating system security. The “Orange Book” offered a relatively simple system for assigning “score” summarized below:

D (Minimal Protection)

C (Discretionary Protection)

C1: Discretionary Security Protection

C2: Controlled Access Protection

B (Mandatory Protection)

B1: Labeled Security Protection

B2: Structured Protection

B3: Security Domains

A (Verified Protection)

A1: Verified Design

In the 1990’s, the US and other nations combined their efforts to create an international security standard for software known as the Common Criteria (ISO 15408). Common Criteria also has a rating system that scores products with “evaluation assurance levels” (EALs):

EAL 1: Functionally Tested

EAL 2: Structurally Tested 

EAL 3: Methodically Tested and Checked 

EAL 4: Methodically Designed, Tested, and Reviewed 

EAL 5: Semi-formally Designed and Tested 

EAL 6: Semi-formally Verified Design and Tested 

EAL 7: Formally Verified Design and Tested 

Both TCSEC and Common Criteria (CC) are primarily focused on “security functional requirements” (as called out earlier, distinct from “security engineering quality requirements”). The EALs reflect the amount of rigor and attention to claimed security functional requirements a developer applied while creating a product. Furthermore, the EALs also reflect increasing levels of effort and resources necessary by anyone reviewing a product in order to evaluate the product’s claimed security functional requirements. However, EAL ratings for commercial products have historically not correlated with the number of vulnerabilities found in commercial products after release. As I discussed in my December posting on Common Criteria, this is because CC is primarily focused on “security functional requirements” and fails to adequately address “security engineering quality requirements”.  This leads a question on how to measure those aspects of software security that earlier efforts have been unable to successfully address. 

Microsoft has been releasing security bulletins since 1999. Based on some informal analysis that members of our organization have done, we believe well over 50% of *all* security bulletins have resulted from implementation vulnerabilities and by some estimates as high as 70-80%. (Some cases are questionable and we debate if they are truly “implementation issues” vs. “design issues” – hence this metric isn’t precise, but still useful). I have also heard similar ratios described in casual discussions with other software developers. In other words, most vulnerabilities can be addressed by the “security engineering quality requirements” described via SDL. This is not to say that “security functional requirements” are unimportant or that SDL ignores secure design (as Adam has described in his threat modeling series), but rather that it is not where vulnerabilities are being most frequently encountered. With SDL, we adopt a pragmatic approach in looking at identifying the root causes of security vulnerabilities, and trying to prevent those root causes from reoccurring. The challenge lies in how we actually validate that development teams are indeed adopting and executing whatever changes SDL requires in engineering (either in terms of process or tools). Process changes are often difficult to quantify, as we must rely upon development teams truthfully attesting they have followed the process. As long as development teams believe the process results in better code, they generally will adopt and follow such practices. Tool usage becomes more interesting and valuable in that using tools becomes a vehicle for objectively and independently verifying if code satisfies requirements or not. But that is just the tip of the iceberg…

As I said above in my comments on EALs, the amount of time required by anyone reviewing a product to assess “security” is relevant since security review can be a very time and resource intensive activity. However, running static code analysis tools, verifying build tools and switches, searching for banned APIs, and recording the output of other tools that inspect code and/or binaries for potential implementation vulnerabilities is a key element in how we approach the challenge of trying to measure compliance with SDL requirements from product groups at Microsoft today. While not every technique required by SDL has a corresponding tool, we try to provide both tools and automation if and wherever possible. There is still much work to be done in terms of standardizing tool output formats and creating automation to assess tool output. However, these “grass roots” metrics derive from practical experience of changing engineering requirements based on actual vulnerabilities. We look objectively at what is causing vulnerabilities, and target solutions to address the root causes of those issues. As the saying goes, “If it hurts when you do that, stop doing that”. If what we have done in the past has hurt our customers by creating vulnerabilities requiring security bulletins, we want to stop doing that. J

The challenge in using a plethora of individual detailed metrics such as I describe above (that we do internally at Microsoft for measuring SDL compliance), is that they don’t roll up into a nice aggregate score that customers can easily understand.  However, they have translated into reduced numbers of vulnerabilities as Michael Howard wrote a few weeks ago. Coupling these types of scores with assessment of compliance with “security functional requirements” might be the basis for coming up with a metric that is useful to customers, both in the government and private sector.

What do you think?