As part of the BAE profiling and reference implementation, we have a full test & validation suite.  Our desire has always been to make the barrier to entry for anyone using the test suites to be the minimum it needs to be. As such we focused on creating our test suites using open source tooling so that we could provide a test suite project that an implementer could import into their open source testing tool, point it at their BAE implementation, run it, and get immediate feedback on whether or not their implementation was conformant to the profile.

To that end, we have been using the popular and free soapUI testing tool. Unfortunately, we are running into some limitations in the tool support for SAML 2.0. It would appear that the current soapUI implementation is using the OpenSAML 1.1 implementation and not the current OpenSAML 2.0 which supports SAML v2. In particular, this means that the following functionality that relates to the testing of SAML AttributeRequest/Response are not supported:

• Ability to digitally sign and validate attribute requests and responses using the enveloped signature method
• Ability to utilize the <saml:EncryptedID> as a means of carrying the encrypted name identifier
• Ability to decrypt the <saml:EncryptedAssertion> element sent by the Attribute Authority which contains the encrypted contents of an assertion

This has required us to go thru some gyrations in how we are implementing the test suites, which is making the user experience not as smooth as we would like.

Ideally we would love to continue using soapUI going forward, but we are also on the lookout for other open source tooling that we could utilize for our testing. Suggestions and recommendations from folks who have experienced this issue and have found a resolution would be very much appreciated.

FIPS 201 defines a US Government-wide interoperable identification credential for controlling physical access to federal facilities and logical access to federal information systems.  The FIPS 201 credential, known as the Personal Identity Verification (PIV) Card, supports PIV Cardholder authentication using information securely stored on the PIV Card. Some PIV Cardholder information is available on-card through PIV Card external physical topology (i.e., card surface) and PIV Card internal data storage (e.g.  Magnetic stripe, integrated circuit chip). 

Other PIV Cardholder information is available off-card. Examples of off-card information, say in the First Responder & Emergency Response domain, could be certifications that could be presented by a Doctor or EMT that could verify their claims and allow physical and/or logical access to resources.

Accordingly, the federal government requires a standard mechanism for Relying Parties to obtain PIV Cardholder information (User Attributes), which are available off-card, directly from the authoritative source (Attribute Authority). The authoritative source is the PIV Card Issuing Agency, which is the agency that issued the PIV Card to the PIV Cardholder.  The exchange of these User Attributes between backend systems is known as “Backend Attribute Exchange” (BAE). The architectural vision for the BAE can be found at IDManagement.gov (Direct link to "Backend Attribute Exchange Architecture and Interface Specification" - PDF).

I, and members of my team, have been part of a joint DHS and DOD team that have been working on a proof of concept implementation of the BAE in order to validate the approach, gain valuable implementation experience, and to provide feedback to the relevant governance organizations within the US Federal Government. The results of our work are three-fold:

1. A SAML2 Profile of the BAE, with both normative and informative sections, that provide concrete implementation guidance, lessons learned as well as recommendations for folks seeking to support this profile
2. Reference implementations stood up within the T&E environments of both DHS and DOD for interoperability testing
3. Test suites that can be used by implementers to verify compliance with the profile

I am happy to report that the profile is currently at v1.0 (DRAFT) status, under external review, and that we are scheduled to give a briefing on the work to a sub-committee of the Federal CIO Council later this month. In addition, we have our reference implementations up and running and are putting the finishing touches on the Test Suites.

As someone who has and is participating in industry standards efforts, I am fully aware that one of the critical items for a standard to become successful is for incorporation of the standard into vendor tooling. Some of the choices that we made, beyond satisfying the needed functionality, was to make sure that it was as easy as possible to build in profile support by:

• Not reinventing the wheel; Leverage the conventions and standards established by some of the fine work that has been done to date by the OASIS Security Services (SAML) TC on Attribute Query Profiles
• Keep the delta's as small as possible between the BAE Profile and existing profiles such as the X.509 Attribute Sharing Profile (XASP)
• Provide LOTS of informative guidance
• Striking a balance between making sure that the profile was generic enough to be widely used and deployable, but provided enough information in the message flow for implementers to get full value.

The last item was something that we found to be critical and sometimes contentious to balance. But, we would not be where we are right now, had we not been informed by our actual proof-of-concept implementations. A pure paper effort would have left too many holes to patch.

We have also made an active effort to reach out to vendors, especially in the federation, entitlement management and XML security arenas, and have been gratified by their response in committing to support this profile in their tooling (In some cases, folks already have beta support baked in!). We are fully expecting to highlight and point out those folks during our out-brief later this month. If you are a vendor, want to find out what it takes to support this profile, and are interested in receiving a copy of the v1.0 DRAFT, please feel free to ping me at anil dot john at jhuapl dot edu.

This has been a pretty extensive, exciting and detailed effort and we are very grateful for the senior level support from both Organizations for this effort.  Beyond that, it has been a blast working with some very smart people from both DHS and DOD to make this real.

In another context, I was recently asked:

Since you first posted your article about interoperability, did you find out "Who among you actually implement this interoperable interface specification in your current shipping product?"

Thought I'd share the relevant bits of the answer that I gave:

"... before I answer your question, please know that the focus for my environment was/is on building out a policy driven infrastructure for a web services environment. And the motivations for going down that path include:

1. Consistent enforcement of policy (and in this particular case, access control policy) across multiple services
2. Minimize the number of interception points in the message path
3. Take the burden/complexity/headache of security policy out of the hands of the development teams who are deploying the services and move it into the infrastructure

As such, what I was particularly interested in having happen is for the XML Security Gateways in my environment to act as a XACML PEP to a remote XACML PDP. So to answer your question, you need to look at both the PEP and the PDP side:

One the PEP side, the answer is “It depends” on how flexible the product is. *Most* of the gateways provide you some mechanism for making an external “call-out” as part of the decision making process. i.e. Incoming request comes in to the PEP; PEP intercepts, does some basic threat and malicious content scanning, Authenticates the user/entity, then formulates an AuthZ request, sends it out in an “external call-out” to a PDP, and acts on the decision when it is returned.  The ease of how you can do this, and the ability to customize that call-out depends on the particular product. You basically have on one extreme the need to engage the consulting services of the vendor to customize that call, to the other of being able to have the ability to do-it yourself using nothing more than message templates.  So in short, you can bend the metal to make the PEPs generate a XACMLAuthzDecisionQuery and I am aware that at least a couple of the vendors in this space have it on the roadmap to be a native XACML PEP, but I am unsure of exactly what they mean by that term.

On the PDP side, what I will say is that silence as answer to the question is an answer in itself..   Pretty much all of the PDP vendors have some sort of a web service interface to their “Authorization Service”. To date my experience working with multiple products (both on the PEP and the PDP side) has been that you simply cannot point a PEP to PDPs implemented by multiple vendors and expect it to work without custom “franken-code” on either/both the PEP and PDP ends (Even though this was exactly the point of the Catalyst Demo that I noted in my blog entry).

These days my response to the vendor response of “Oh, Sure we do that!” is a request for a pointer to the WSDL and the XSDs of their  Authorization/Entitlement Service of their current shipping product to prove that they indeed do it. For some reason, the conversation seems to just die out at that point … <shrug>"

As always, if my understanding is incomplete or incorrect, please feel free to leave a comment on this blog entry.

What is the current state of interoperability between XACML PEPs and PDPs from different vendors? I am currently looking to see if there is a consistent implementation of PDP interfaces among the multiple Fine Grained Authorization/Entitlement vendors such that I can point a XACML PEP from one vendor to the XACML PDP of multiple vendors and not have to do custom integration to make it work.

Back in February 2007, Burton Group issued a challenge to the the industry to demonstrate interoperability of XACML. Some of the questions they asked were "Can enterprises really mix and match policy administration points (PAPs), policy decision points (PDPs), and policy enforcement points (PEPs) from different vendors? Is the XACML RBAC Profile practical? Or will we find that different interpretations of the specification yield less than satisfactory levels of interoperability?"

The industry responded, via the OASIS XACML TC, in June 2007 by having the first XACML Interoperability Demo at the Burton Group Catalyst conference. There were two particular use cases in this demo, which required interoperability between vendor implementations of PEPs, PDPs and PAPs:

• Authorization Decision Request/Response
• Policy Exchange

I am particularly interested in the first scenario and in looking at the interop scenario document, it would appear that some specific choices were made in order to make this work:

• Implementation of the XACML Interface of the PDP as a SOAP Interface which accepts a XACMLAuthzDecisionQuery and returns a XACMLAuthzDecisionStatement which are contained in the SOAP body.
• Use of the SAML 2.0 Profile for XACML 2.0 which defines a Request/Response mechanism for carrying xacml-context:Request and xacml-context:Response elements.

In effect, what you ended up with in order to make this work is the implementation of a standardized SOAP interface that adhered to the following Request/Response (Taken from the interop scenario document):

Sample SOAP SAML XACML Request wrapper:

Sample SOAP SAML XACML Response wrapper:

I attended this event and remember coming away impressed at the results while simultaneously amused at some of the coding heroics of the vendors who, if I remember correctly, in some cases had very short time frames to work with.

It has now been more than a year since this interop event and at this point I have a very simple question for the vendors in this space "Who among you actually implement this interoperable interface specification in your current shipping product?"

From what I see to date (and I am more than happy to be corrected on this point) is that while many vendors claim conformance and implementation of the XACML 2.0 standard, their PDP interfaces are still proprietary and unique. Oh, don't get me wrong, these interfaces may be implemented using web services etc. BUT each web service implementation is unique and special to that vendor and does not follow any consistent interface specification and as such is an integration exercise that is left up to implementers if you have PEPs from multiple vendors. e.g. XML Security Gateways or Software PEPs from multiple vendors which need to talk to a XACML PDP.

In the physical world, when an attacker is preparing to assassinate someone or bomb a target, the first thing that they will do is to determine how best to set up that attack. The phrase used to describe the initial phase of the set-up is called 'pre-operational surveillance'. 

Unfortunately, the default configuration of most web services allow a potential attacker to do the digital equivalent of pre-operational surveillance very easily. In the digital world, these type of threats are often classified under the category of 'Information Disclosure Threats'. There are two in particular (there are more) that I would like to call attention to:

1. SOAP Fault Error Messages
2. WSDL Scanning/Foot-Printing/Enumeration

1. SOAP Fault Error Messages

All too often, detailed fault messages can provide information about the web service or the back-end resources used by that web service. In fact, one of the favorite tactic of attackers is to try to deliberately cause an exception or fault in a web service in the hope that sensitive information such as connection strings, stack traces and other information may end up in the SOAP fault. Mark O'Neill has a recent blog entry 'SOAP Faults - Too much information' in which he points to a vulnerability assessment that his company did of a bank that provided information that enabled an attacker to understand the infrastructure the bank was running and presumably allowed them to further tailor the attack.

The typical mitigation for this type of information disclosure is the implementation of the 'Exception Shielding Pattern' as noted in the Patterns & Practices Book 'Web Service Security' [Free PDF Version] which can be used to "Return only those exceptions to the client that have been sanitized or exceptions that are safe by design. Exceptions that are safe by design do not contain sensitive information in the exception message, and they do not contain a detailed stack trace, either of which might reveal sensitive information about the Web service's inner workings." (FULL DISCLOSURE:  I was an external, unpaid, technical reviewer of this book).

You can either implement this pattern in software or use a hardware device like a XML Security Gateway to implement this pattern. Mark utilized a Vordel Security GW, but this is something that can be implemented by all devices in this category. I have direct experience with Layer 7 as well as Cisco/Reactivity Gateways and happen to know that they support this functionality and I don't doubt that IBM/DataPower and others in this space support it as well.

Note that this does not imply that the error's that happen are not caught or addressed but simply that they are not propagated to an end-user.

2. WSDL Scanning/Foot-Printing/Enumeration

Appendix A of 'NIST 800-95: Guide to Secure Web Services' provides a listing of common attacks against web services, and you will note that there are many references to the information that can be found in a WSDL that can lend itself to a variety of attacks including Reconnaissance Attacks, WSDL Scanning, Schema Poisoning and more.

And in the 'Security Concepts, Challenges, and Design Considerations for Web Services Integration' article at the "Build Security In" web site sponsored by the DHS National Cyber Security Division, it notes that "An attacker may footprint a system’s data types and operations based on information stored in WSDL, since the WSDL may be published without a high degree of security. For example, in a world-readable registry, the method’s interface is exposed. WSDL is the interface to the web services. WSDL contains the message exchange pattern, types, values, methods, and parameters that are available to the service requester. An attacker may use this information to gain knowledge about the system and to craft attacks against the service directly and the system in general." 

The type of information found in a WSDL, and which can be obtained simply by appending a ?WSDL to the end of a service endpoint URL, can be an extremely useful source of info for an attacker seeking to exploit a weakness in a service, and as such should not be provided or simply turned off.

There are multiple ways of mitigating this type of an attack which include turning off the automatic ?WSDL generation at the SOAP stack application level or by the configuring the intermediary that is protecting the service end-point. For example, most XML Security Gateway's by default turn off the ability to query the ?WSDL on a service end-point.

I consider this to be a very good default.

When this option is implemented, there are often a variety of questions that come up that I would like a take a quick moment to address.

Q. If you turn off the automatic WSDL generation capabilities (i.e. ?WSDL) how are developers supposed to implement a client that invokes the web service?

There are two ways. (1) Publish the WSDL and the associates XML Schema and Policy files in an Enterprise Registry/Repository that has the appropriate Access Control Mechanisms on it so that a developer can obtain a copy of the WSDL/Schema/Policy Documents at design time. (2) Provide the WSDL/Schema/Policy files out of band (e.g. Zip File, At a protected web site) to the developer. 

Oh yes, there is always the run-time binding question that comes up here as well. What I will say is that run-time binding does not mean "run time proxy generation + dynamic UI code generation + glue code" but simply that the client side proxy and the associated UI and glue code are generated at design time, but that the end-point that the client points to may be a dynamic lookup from a UDDI compliant Registry. I've done this before and this does not require any run-time lookup of a web service's WSDL.

There is an additional benefit to this method as well. Have you ever gone through the process of defining a WSDL and Schema using best practices for web services interoperability, implemented a service using that WSDL and Schema, and then looked at the auto-generated WSDL? You may be surprised to find that the automatic generated WSDL may be in a majority of cases is not as clean or easy to follow and in some cases may indeed be wrong. The best practice for developing interoperable web services recommends following a contract-first approach. This requires that the "contract" i.e. the WSDL and the Schema to be something that is developed with a great deal of care given to interoperability. Since the automatic generation of WSDL is platform-specific, there is always the possibility of some platform-specific artifacts ending up in the contract documents, which is not what you intended to happen.

Q. What about those existing/legacy services that do a run time lookup? Won't those break?

The question that needs to be asked at this point is why these services are doing a run time lookup, is there value being added by this capability in this client, and are there alternatives that will enable the client to provide the same functionality without compromising security? 

As an example take the case of a BEA Weblogic client.  If you will look at the documentation that BEA provides on building a Dynamic client you will note that they provide two different approaches, one that uses a dynamic WSDL lookup and another that does not. The interesting thing about this is that the approach that uses the WSDL makes a run-time lookup of a Web Service's WSDL which will end up breaking if the ?WSDL functionality is turned off. But the alternative approach of building a dynamic client provides the same functionality without the run-time WSDL lookup.

From what I can see, from a functional perspective there is no difference between the two approaches and given that one of the things that you want to do when developing web services, or any software for that matter, is to minimize the number of external dependencies, I would choose the second option of NOT doing a run-time WSDL lookup in this particular case. What is regrettable in this case is that it appears that the default configuration in BEA's tooling is to use the run-time WSDL option (Or so I have been informed), which leads to issues when folks who choose the default options with their tools develop the clients. 

Mitigating these information disclosure threats requires both developers and operational support folks to understand their shared responsibility for security. Developer's need to understand that security should be part of the software development lifecycle and is not something that is bolted on at the end or is 'thrown over the wall' for someone else to take care of. Operational folks need to understand that a layered defense in depth strategy is needed and that secure coding practices of developers are an essential component of any operational environment. In particular the mentality of "Firewalls and SSL will save us all" needs to change for all parties concerned.

Digital ID World 2008 is the first IdM conference that I've gone to as part of a team, and given the variety of breakout sessions we decided early on to use the divide and conquer approach based on our areas of interest and expertise.

The following are some highlights on some (not all) of the sessions that I attended and found to be interesting. As with a lot of conferences, there were some sessions that were pretty much disguised vendor pitches which I am not even going to bother with a mention.

Keynote - Identity Assurance: A Backbone For The Identity Marketplace
by Peter Alterman - GSA, Andrew Nash - PayPal, Frank Villavicencio - Citigroup

In some ways this was rehash of the panel on the same topic that was moderated by Mark Diodati at Burton Catalyst but with the addition of Peter Alterman of the GSA, who tends to add a certain amount of ...ah... flair to the conversation

The intent of the Liberty Identity Assurance Framework (IAF) is to develop a framework that leverages the existing work that has been done by EAP, tScheme, US e-Auth etc. to generate an identity assurance standard that is technology agnostic but provides a consistent way of of defining identity credential policy and the process and policy rule set etc.  The IAF consists of four parts (1) Assurance Levels (2) Assessment Criteria (3) Accreditation and Certification Model and (4) Business Rules. You can find out more about it on the IAF Section of the Liberty Alliance Web Site.

What interested me about the entire conversation was the leveraging of OMB M-04-04 and NIST 800-63 to define the assurance criteria but the drive to make a "Liberty Alliance IAF Assurance Token" (if you will) that will be certified to mean the same thing across federations. Mr. Alterman also noted, and I hope that I interpreted this correctly, that the intent from the GSA side would be to not re-invent the wheel but to adopt this IAF framework going forward. He spoke of current inter-federation work he is involved in between NIH and the InCommon Federation that is leveraging this.

During the Q&A session, I brought up the fact that this work is directly focused on AuthN but in general, access to resources is granted based on a variety of factors, only one of which is the strength and assurance of the authentication token. The response is that the Liberty work is deliberately focusing on the AuthN and considers AuthZ to be out-of-scope for their work.

Keynote Presentation: State Of The Industry
by Jamie Lewis - Burton Group

Enterprise IdM is the set of business processes, and a supporting infrastructure, that provides identity-based access control to systems and resources in accordance with established policies.

• Business trends are driving integration across processes and folks are being asked to do more with less.
• SaaS is gaining momentum
Many failures in IdM projects caused by a lack of doing homework and a belief in the silver bullet product etc.

• People manage risk, not products.
• IdM is a means and not an end; It is about enabling capabilities and not an end in itself.
• The Identity Big Bang is around new ways of working, collaborating and communicating
• Make every project an installment on the Architecture and scope the goals to around 3 years.
• Always think about data linking and cleansing

That was the first half of the keynote, but the second half was something I found to be very fascinating and is based on work that Burton has been proposing around the idea of a "Relationship Layer for the Web"

• AuthN and AuthZ are necessary but not sufficient
• Centrism of any kind does NOT work
• Lessons from social science on trust, reciprocity, reputation etc.
• The future of identity is relationships
• Difference between close and distant relationships; Able to make many observations in a close relationship, so able to get good identity information. Not so for distant relationships
• A good relationship provides value to all parties. And it is not just about rights but also obligations
• Values like privacy etc. require awareness of relationship context
• Systems fail if they are not "relationship-aware"
• Difference between Custodial, Contextual and Transactional identities.
  -- Custodial Identity is directly maintained by an org and a person has a direct relationship with the org.
  -- Contextual identity is something you get from another party but there are rules associated with how that identity can be used.
  -- Transactional identity is just the limited amount of info that an RP (?) gets to complete a transaction e.g. Ability to buy alcohol requires a person to be over 18 (?) but in a transactional relationship, you would simply ask the question of "Is this person old enough to buy alcohol?" and the answer would come back as "Yes/No". Compare this to a question of "What is this person's age or birthday?" which releases a lot more info.
• The last type of identity in effect requires the existence of what Burton Calls an "Identity Oracle" (See Bob Blakley's blog entries) that has a primary and trusted relationship with a user as well as with relying party and can stand behind (from a legal and liability perspective) the transactional identity statements that it makes.

I found this entire topic absolutely fascinating as this is so very relevant to a lot of the work that I do around information sharing across organizations that may or may not trust each other for a variety of (sometimes very valid) reasons. Will be actively tracking this area on an ongoing basis.

The Plot To Kill Identity
by Pamela Dingle - Nulli Secundus

I really enjoyed this session by Pamela on the disconnect that currently exists between the needs of the users, what is being asked of the application vendors and the lack of a common vocabulary to express our needs such that there is a change in the same old way of doing business.

• Need for an effort to be consistent all the way at the RFP/RFI time
• Need a common vocabulary when requesting capability from vendors
• Start with:  Provide and Rely support i.e. the ability to choose whether or not a product relies on external identity services or provides its own.
• Pamela also had a great starting set of RFI type questions one can use.. I am hoping that she will post them on her blog.

One of the questions I brought up during the Q&A session was that if I bought in to the Kool-Aid of what she discussed during the presentation (and I do), what would it take to scale the conversation to a larger audience? Bob Blakley, who was also in the audience, chimed in and noted that if Pamela wrote up a white-paper on the topic, he would help her get it published and widely distributed as well.

I would also be very interested in expanding the scope of the sample RFI questions to be grouped by product/project category (and released under an open licence; Creative Commons?) so that folks like me can use them in our RFP/RFIs as well.

There were more sessions that I attended that were interesting such as the Concordia Workshop on "Bootstrapping Identity Protocols: A Look At Integrating OpenID, ID-WSF, WS-Trust And SAML", "Using An Identity Capable Platform To Enhance Cardspace Interactions" and more..

All in all, beyond the sessions themselves, the hall-way conversations and the connections made to be as valuable (or even more so) than just the sessions themselves. I know that I found and made connections with multiple folks who work in my community and am very much looking forward to future collaborations with them and others.

I am off next week to Anaheim, with the rest of my team, to attend Digital ID World 2008.  Very much looking forward to the event given its packed agenda as well as some already scheduled side-bar meetings.

This looks like it is going to be another one of my usual business trips that combines visiting some of the nicest/most-scenic cities on the North American Continent and spending all the time indoors in window-less conference sessions, which in turn leaves you with absolutely no time for any site-seeing

Federating identities across information and security domains is not just a technical problem, and anyone who tells/sells you that it is, is not operating in a frame of reality that is conducive to success!

Please note that, for me, an implementation of an Identity Federation architecture takes into account both Authentication and Authorization as well as a host of other areas.  As such I've always found it amusing to be informed (usually by a vendor) that this is a straight forward problem and that once I deploy [Insert technology / tool / product / magic pixie dust of choice here], we will have you "federating in no time". Ha!

We have been wrestling with this and at one of our working meetings recently, one of my team-mates came up with the following representation to describe the challenges of reaching agreement on what information needs to flow across federation boundaries, and what needs to be in place to accomplish it. Based on the same principle as the Boy Scout's triangle (heat, oxygen, fuel), you take away one side, and the entire Attribute Triangle (or as we call it, "Tom's Triangle", in honor of our team-mate who came up with it) collapses.

When you look at it, it seems so obvious and simplistic, but we have found value in thinking thinking about it in this manner.  Organizational Policy determines the rules of the road. Those rules in turn are reflected in the choices of attributes and the agreements around their semantics. At the same time, you need to be assured that the agreed upon attributes are not things that you come up out of the blue but are instead drawn from trusted and authoritative sources in the Enterprise.

GSA's USA Services/Intergovernmental Solutions sponsors monthly workshops around topics such as emergency preparedness, environmental monitoring, healthcare and law enforcement.

The upcoming "Exploring Identity Management: Global Landscape and Implications for Stakeholder Engagement Around the National Response Framework" session is focused on the implications of the "National Response Framework [PDF]" to Identity Management.

National Response Framework (NRF) is a guide to how the Nation conducts all-hazards response.  It is built upon scalable, flexible, and adaptable coordinating structures to align key roles and responsibilities across the Nation, linking all levels of government, nongovernmental organizations, and the private sector.  It is intended to capture specific authorities and best practices for managing incidents that range from the serious but purely local, to large-scale terrorist attacks or catastrophic natural disasters.

I had the opportunity to speak with both Susan Turnbull at the GSA as well as Dr. Duane Caneva, Director of Medical Preparedness at the White House Homeland Security Council, who are putting this event together, and came away impressed with their obvious passion in addressing this critical issue.

Basically, this is all about the technical, social and organizational infrastructure that needs to be in place to respond to a Katrina-like or Tsunami-like event.  Identity Management is seen as an enabler in bringing the right people, the right resources and the right information together to help make a difference in responding to a crisis of this magnitude.

I also came away with an action item to discuss with this community how some of the work that I am currently involved with could help out in this particular domain.  The agenda looks pretty interesting and builds upon past events such as the IDTrust 2008 etc. Looking forward to this!

Just picked up the current issue of IEEE Security & Privacy Magazine and it is full of Identity Management Goodness!

• I'm Pc01002/SpringPeeper/ED288l.6; Who are You? by Susan Landau and Deirdre K. Mulligan
• The Venn of Identity: Options and Issues in Federated Identity Management (Abstract) by Eve Maler and Drummond Reed
• The Seven Flaws of Identity Management: Usability and Security Challenges (Abstract) by Rachna Dhamija and Lisa Dusseault
• Biometrics in Identity Management Systems (Abstract) by James L. Wayman
• Privacy and Identity Management (Abstract) by Marit Hansen, Ari Schwartz and Alissa Cooper
• Identity Management, Privacy, and Price Discrimination (Abstract) by Alessandro Acquisti
• Use Cases for Identity Management in E-Government (Abstract) by Robin McKenzie, Malcolm Crompton and Colin Wallis
• Dynamic Security Assertion Markup Language: Simplifying Single Sign-On by Patrick Harding, Leif Johansson, and Nate Klingenstein

Looking forward to this read!

Some time ago, I was having a conversation with some folks about the usage of SAML Authentication Assertions for Web Browser Single Sign-On (SSO) versus Digital Certificates.  The folks that I was having this conversation with support one of the larger PKI deployments in the US, and their response to my comment about the lack of support for SAML for Web Browser SSO in that particular vertical was the following question:

"Provided the experience to the user is the same, why does it matter?"

I didn't have a very good answer at that point in time but it is something that I've been mulling over since that time. The issue has come up again in separate conversations, including this one by Patrick Harding of Ping Identity and this posting by James McGovern.  This blog posting is an attempt to articulate some of the points on both sides of this debate.

SAML 2.0 and Web Browser SSO

The Web Browser SSO Profile in SAML 2.0 supports both an Identity Provider (IdP) initiated and Service Provider (SP) initiated SSO message flows. As described in the SAML documentation ".. the most common scenario for starting a web SSO exchange is the SP-initiated web SSO model which begins with the user choosing a browser bookmark or clicking a link that takes them directly to an SP application resource they need to access. However, since the user is not logged in at the SP, before it allows access to the resource, the SP sends the user to an IdP to authenticate. The IdP builds an assertion representing the user's authentication at the IdP and then sends the user back to the SP with the assertion.  The SP processes the assertion and determines whether to grant the user access to the resource.

In an IdP-initiated scenario, the user is visiting an IdP where they are already authenticated and they click on a link to a partner SP. The IdP builds an assertion representing the user's authentication state at the IdP and sends the user's browser over to the SP's assertion consumer service, which processes the assertion and creates a local security context for the user at the SP."

Some points to keep in mind regarding these two flows:

• The user's credentials are maintained at their IdP, which means that the SP must trust the IdP to assert information about its users. The establishment of this "organizational trust" is typically done out of band.
• The IdP can support multiple authentication mechanisms of varying strengths including user-id/password, software certificates and smart-cards based on a PKI, biometrics etc.
• The type and the strength of the authentication used by the user can be conveyed in a SAML authentication context which can be used in (or referred to from) a SAML Authentication Assertion. In fact an SP can include an authentication context in a request to an IdP to request that the user be authenticated using a specific set of authentication requirements, such as a multi-factor authentication.
• Do not conflate authentication with authorization! Although the user has been authenticated, the SP more than likely needs a LOT more information about the user (than what was provided in the Authentication Assertion) in order to make an access control decision.  This typically requires the usage of SAML attribute statements and/or SAML authorization decision statements. And in any reasonably complex environment that wants to remain standards based, this more than likely involves the usage of XACML for defining access control criteria.
• SAML supports mechanisms to support the integrity and confidentiality of the assertions themselves including SSL mutual authentication, XML Signature etc. and does so across both the HTTP and SOAP bindings.

PKI and Web Browser SSO

This is pretty straight forward from the usage perspective. It begins with a user choosing a bookmark or clicking a link that takes them directly to a Relying Party (RP) i.e. application resource they need to access.  The user is prompted to present a digital certificate as the authentication mechanism.  The user's certificate, whether it is in the form of a soft certificate or coming from a smart card, is used to authenticate the user.

Some points to keep in mind:

• In a PKI environment, when a Certification Authority issues a certificate, it is making a statement to a RP that a particular public key is bound to a specific entity (i.e. the subject of the certificate).
• The degree to which a RP trusts a CA is based on the RP's understanding of the CA's user identification and credential issuance practices, operating policies, security controls etc.
• Depending on the identity issuance requirements of a CA, the digital certificate is usually consider a higher assurance authentication mechanism than something like a user-id and password.
• Each RP has to put into place the technical infrastructure needed to make it PKI-aware i.e. the ability to use digital certificates as authentication mechanism.
• Each RP has to put into place the mechanisms for both validation and revocation operations. This is especially challenging when you have CA's that are cross-certified and CA's and clients need to support certificate path processing.
• The user experience, in browsing from one PKI protected resource to another may not be seamless.
• The authorization aspect is indeed separate from the authentication.  Information needed to make an access control decision may not be present in the information provided by a digital certificate.

What strikes me when I look at these two options is that the question posed at the start of this entry may not be the right one to ask. The question one should be asking instead is "Who do you trust?"

The fundamental precept of a PKI environment is that everyone must buy into trusting the CA. I would bet that that a lot of the "entrenched PKI communities" have expended significant amount of resources in standing up not just the technical infrastructure but the credential proofing and issuance processes for their domain. As such, they implicitly trust a certificate vouched for by the CA. The downside to this is that every single RP must be PKI-enabled, which is non-trivial.

SAML is not a trust mechanism but more of a mechanism for a particular domain to make assertions about its users. As such, what is needed in the federated world for this to work is for a relying domain to trust the asserting domain. The relying domain would have to have confidence in the credential proofing and issuance process of the asserting domain. The advantages here would be that SAML-enabling an SP is a more straight forward process and there is significant out-of-the-box support for SAML in vendor tooling.

In each case, I consider authorization to be separate and distinct from the authentication.

But that organizational trust... Ah!  Is it not remarkable that the truly hard problems, whether one is discussing Identity Management or Service Orientation, really do not have to do with technology but with people, culture and behavior?

Series of posts on threat modeling. Good stuff!
[Found via Bruce Schneier]

• The Trouble with Threat Modeling
• The New Threat Modeling Process
• Getting into the Flow With Threat Modeling
• Making Threat Modeling Work Better
• Threat Modeling Self Checks and Rules of Thumb
• The STRIDE per Element Chart
• Wrapping up Threat Modeling

Also check out JD's post on Getting Started with Threat Modeling and the Threat Modeling Blog maintained by the Microsoft Application Consulting and Engineering Team.

Congratulations to the Shibboleth Team on the release of Shibboleth 2.0.  This version provides support for SAML 2.0 as well as integration with most major identity stores, including Microsoft Active Directory, Kerberos, LDAP-compliant directory services, and JDBC-compliant databases.

For those not familiar with this fine piece of open source software, Shibboleth is a "... standards-based, open source middleware software which provides Web Single Sign-On (SSO) across or within organizational boundaries. It allows sites to make informed authorization decisions for individual access of protected online resources in a privacy-preserving manner."

One of the things I have been doing a bit of work on has been Attribute Authorities in the SAML 2.0 sense i.e. a SAML entity that produces assertions in response to identity attribute queries from an entity acting as an attribute requester.  In particular, my interest lies in controlling the release of attributes based on policies that could be externalized.

My interest in finding a hopefully standardized way of doing this was sparked by the article "Using XACML for Privacy Control in SAML-Based Identity Federations" by Wolfgang Hommel, which I found on the XACML section of the OASIS Cover Pages. The article describes the use of XACML to control the release of attributes and an implementation of this using an earlier release of Shibboleth.

At the IDTrust 2008 Symposium, one of the sessions that I enjoyed was the panel session on "Federations Today and Tomorrow" hosted by Ken Klingenstein of Internet2 and Patrick Harding of Ping Identity.  When Ken spoke a bit about the release of Shibboleth 2.0, which supports SAML 2.0, this brought me back full circle.

In an earlier conversation I had had on this topic with some colleagues who are working with release candidate versions of Shibboleth 2.0, I was curious to find out if the "Attribute Filter" capability in Shibboleth had made it into the SAML 2.0 standard given that Shibboleth 2.0 is the convergence of Shibboleth, SAML 1.X and the Liberty IDFF. Unfortunately, I was informed that it had not. The implementation is specific to the Shibboleth functionality and does not seem to exist as part of the SAML 2.0 specification.

So what I asked the panel was that given that both SAML 2.0 and XACML 2.0 are based out of OASIS, is there any work in integrating the two standards to enable this type of functionality, as there is definitely a use case for this in a lot of the communities that I am familiar with. The answer I got back was that, while this is not outside the realm of possibility, it is not something that someone is working on. In a hallway conversation I had with some other folks after the session, someone mentioned that this type of functionality may be built into one of the Oracle products, but again the implementation was proprietary to that vendor.

I'm going to be attending "IDtrust 2008 - 7th Symposium on Identity and Trust on the Internet" this week.

Especially looking forward to some of the discussions around Federated Identity, Access Control etc.

I recently got an e-mail asking about a blog entry I had made back in 2005 regarding Identity Federation, SAML and WS-Federation, and if I had attained any measure of clarity regarding their usage since that time. Since this is something I have been spending a bit of time on recently, it seemed like the perfect opportunity to talk about this.

When I wrote the original blog post, I phrased it as a competitive situation. I have since moved on from that position and consider them to be be complementary approaches, each with strengths in certain areas. An Enterprise that is looking at an IdM implementation should be seeking to leverage the strengths that each camp brings to the table.

As of November, 2007, SAML 2.0 is an OASIS standard and can be considered a combination of the features of SAML 1.X, Liberty Alliance Identity Federation Framework and Shibboleth.

The other camp one should be looking at in the area of Identity Federation is the OASIS Web Services Secure Exchange (WS-SX) family of standards which include WS-Trust, WS-SecureConversation and WS-SecurityPolicy.

The area of contention between the two camps all too often arises when it comes to the domain of browser-based Single Sign-On. This has historically been the playground of SAML but now the new kid on the block is WS-Federation which describes how to use WS-Trust for browser-based Single Sign On scenarios. WS-Federation is currently going through the standardization process at OASIS.

My perspective on both starts with the basic fact that SAML assertions are universal and can be used independently of the SAML protocol. I also very much like the capability that is provided by the WS-Trust based Security Token Service (STS) which provides the ability to translate token formats.

SAML has great deal of traction in the browser based federation arena while WS-SX targets securing web services. Given that SAML assertions are supported by a wide variety of IdM and SOA infrastructure products such as WAM products, WSM products, XML Security Gateways and more, my approach to dealing with interoperability concerns in this area (until the vendor camps work this out) will be to use products and technologies that bridge the gap by supporting both camps.

Note to self for for use as a reference...

SAML assertions have no dependencies on and can be used independently of the SAML Protocol. SAML 2.0 defines three types of assertion statements:

1. Authentication:- The assertion subject was authenticated by a particular means at a particular time.
2. Authorization Decision:- A request to allow the assertion subject to access the specified resource has been granted or denied.
3. Attribute:- The assertion subject is associated with the supplied attributes.

<Issuer> (Required):- The SAML authority that is making the claim(s) in the assertion.

<Signature> (Optional):- An XML Signature that protects the integrity of and authenticates the issuer of the assertion.

<Subject> (Optional):- The subject of the statement(s) in the assertion.

<Conditions> (Optional):- Conditions that MUST be evaluated when assessing the validity of and/or when using the assertion.

<Advice> (Optional):- Additional information related to the assertion that assists processing in certain situations but which MAY be ignored by applications that do not understand the advice or do not wish to make use of it.

Zero or more of the following statement elements:

• <Statement>
• <AuthnStatement>:- An authentication statement.
• <AuthzDecisionStatement>:- An authorization decision statement.
• <AttributeStatement>:- An attribute statement.

An assertion with no statements MUST contain a <Subject> element. Such an assertion identifies a principal in a manner which can be referenced or confirmed using SAML methods, but asserts no further information associated with that principal.

Otherwise <Subject>, if present, identifies the subject of all of the statements in the assertion. If <Subject> is omitted, then the statements in the assertion apply to a subject or subjects  identified in an application- or profile-specific manner. SAML itself defines no such statements, and an assertion without a subject has no defined meaning in this specification.

<Version> (Required):- Version of the assertion. "2.0" for SAML 2.0.

<ID> (Required):- The identifier for this assertion.

<IssueInstant> (Required):- The time instant in UTC.

SAML 2.0 Core Spec [PDF], OASIS Security Services (SAML) TC

Cisco announced today that it is planning on acquiring Securent,  which is considered a leading vendor in the area of Entitlement/Fine Grained Authorization with deep support for XACML.

My initial thought after hearing about that this was that this would be a rather interesting and complementary match to their earlier acquisition of Reactivity, the XML Security Gateway vendor.  Would it not be sweet if the the Reactivity (now the ACE XML) Security Gateway could act as a Policy Enforcement Point that for the Securent supplied Policy Decision Point and even more could now natively understand XACML?

Then I read this blog entry by Phil Schacter of the Burton Group and learned that the acquisition is actually driven by Cisco's Collaboration Software Group, which is looking to "... enhance its ability to provide some shared access control infrastructure for its growing portfolio of collaboration and unified communication offerings..". As noted in Phil's blog entry this acquisition is NOT driven by Cisco's Security  Technology Group which I presume has ownership of the NAC, VPN, network authentication product lines (which I assume is where the ACE XML Gateway product line lives). As he notes, it will be hard for Cisco to not focus exclusively on the business priorities of the Collaboration Software Group.

I personally would consider that to be a bad thing from the perspective of both the current Securent customers as well as folks from Enterprise's that are interested in Entitlement Management/Fine Grained Authorization.  Will be watching to see how this plays out.

Came across this on the Privacy Commissioner of Canada's blog:

It is a speech by Professor Valerie Steeves of the University of Ottawa's Department of Criminology on how "... children interact with popular sites like Webkinz, Neopets and Barbie Girls".

Scary!

Highlights from the presentation can be found here. If you have young children, would definitely recommend checking it out.

There is new blog posting by James McGovern, "How Industry Analysts weaken Enterprise Security", that seems to take industry analysts to task for not asking enterprise application vendors if they "...implement this security specification or any security specification..." in their product. The example specification that is used is XACML.

It is an interesting question but seems to be designed more to get a rise out of people rather than addressing the ground truth, which is that the responsibility lies not with the Analysts but with the Architects and Engineers who are evaluating potential products for their Enterprise. 

So, to my mind, the more appropriate questions would be:

1. Are the customers of the various analyst firms are being provided the appropriate and independent information such that they can ask the right questions of the vendors? Which is the role of the Analysts.
2. Are the Enterprise's actually holding the vendors accountable by NOT spending money with vendors that do not implement open standards? Which is the role of the Business and the Enterprise Architect.

Interesting report [1] published by the Information Assurance Technology Analysis Center (IATAC) and the Data and Analysis Center for Software (DACS) on the current state of Software Security Assurance.

"The [report] provides an overview of the current state of the environment in which software must operate and surveys current and emerging activities and organizations involved in promoting various aspects of software security assurance.  The report also describes the variety of techniques and technologies in use in government, industry, and academia for specifying, acquiring, producing, assessing, and deploying software that can, with a justifiable degree of confidence, be said to be secure.  The report also presents observations about noteworthy trends in software security assurance as a discipline."

[1] http://iac.dtic.mil/iatac/download/security.pdf

Message replay is a very real attack vector for web services attacks. The description of the defense against it is pretty straight forward. To quote the "Message Replay Detection Pattern":

Message replay detection requires that individual messages can be uniquely identified. [...] Cache an identifier for incoming messages, [...] identify and reject messages that match an entry in the replay detection cache.

You have a couple of choices in how you can leverage the relevant web services standards to implement this.

1. Given that WS-Security XML Signature must include a <ds:SignatureValue> element, you can use that as a unique identifier for the messages. The <ds:SignatureValue> is computed from the hash values of the message parts that are being signed (and you can make sure that the parts include both the message body and the WS-Security timestamp i.e. <wsu:Timestamp>.
2. You can use another unique identifier e.g. the WS-Addressing messageid <wsa:MessageID>, which is a URI value that uniquely identifies the message that carries it.  Combine it with the WS-Security timestamp i.e. <wsu:Timestamp> and you are good to go here as well.

In both cases, what you need in order for this to work is a configurable replay cache. And that is also relatively straight-forward to implement, especially if you are doing this in software.

The proverbial devil and the details come into play when you want to abstract this type of capability into the infrastructure.  I for one am very interested in NOT doing this in software (Perf, consistent implementation across SOAP stacks etc.), so a natural place that I would seek to implement this type of capability would be in my perimeter PEP which typically, at least in my environment, is implemented using a XML Security Gateway. 

When it comes to deployment, you do not want a single point of failure in your infrastructure, so what you typically do for deploying perimeter PEP's (XML Security Gateways) is to deploy a cluster (at least two) with a (clustered) load balancer in front of the Gateways. Now, if you are going completely stateless what typically happens in this configuration is that requests are dynamically spread across your cluster of XML Gateways. And that is where the details come into play. If each Gateway implements its own replay cache, and requests are spread out across multiple Gateways, how can you truly be assured that you can detect a replay attack?

The way that you would handle this, if you were implementing this in software, would be to have a shared replay cache (typically a shared database) across multiple load balanced app servers (Note that there are perf implications with this).  But this really does not work with XML Gateways. These are hardened, FIPS compliant devices that typically cannot be tied into a database back-end. So, what possible solutions could you have for this:

1. Configure the load balancer for Active-Passive rather than an Active-Active configuration. i.e. Instead of distributing traffic across the Gateways equally, send all traffic to one Gateway and only if that one fails should the traffic be sent to another cluster member.
2. Actually modify the Gateway configuration to be able to connect to a database back-end.
3. Others?

At present, I am thinking that option (1) is probably the most realistic one. I am not aware of any XML Security Gateway vendors who have implemented anything like option (2). But I am most certainly curious as to how folks are doing this in their environment, so if you are doing this, I would appreciate any info you can share on your implementation details and what you find to be the trade-offs.

Dominick Baier, now with thinktecture (Congrats Christian!), has a good article in the current issue of MSDN Magazine on the usage of certificates in .NET 2.0. The article covers:

• The Windows Certificate Store
• Certificate classes in .NET
• Validation, SSL, Web services, and code signing
• Signing and encrypting data

It is a good read for those who need to work with certs on the .NET Platform. Check it out!

Right after posting my last blog entry on Threats to Message Exchanges in a SOA, I cam across a blog entry by Gunnar Peterson of Cigital that points to a paper that he co-authored with Howard Lipson at CERT on "Security Concepts, Challenges, and Design Considerations for Web Services Integration" in which they describe "... best practices for development staff who want to actually build security services into the software they are developing. The paper is really two papers in one - the first part is on web services and their impact on security concepts, the second part deals with message level security (WS-Security, WS-Trust, WS-SecureConversation) to enable end to end security model for an integrated system, and the last part is on design considerations for security in Web Services." 

I have not had a chance to peruse this in detail, but this definitely looks like a must read document!

A new bit of security goodness from the MS ACE Security Services Team. From the docs:

"Cross-site scripting (XSS) attacks exploit vulnerabilities in Web-based applications that fail to properly validate and/or encode input that is embedded in response data. Malicious users can then inject client-side script into response data causing the unsuspecting user's browser to execute the script code. The script code will appear to have originated from a trusted-site and may be able to bypass browser protection mechanisms such as security zones.

These attacks are platform and browser independent, and can allow malicious users to perform malicious actions such as gaining unauthorized access to client data like cookies or hijacking sessions entirely.

Simple steps that developers can take to prevent XSS attacks in their ASP.NET applications include (see How To: Prevent Cross-Site Scripting in ASP.NET in the patterns & practices series for more detail):

• Validating and constraining input
• Encoding output

For defense in depth, developers may wish to use the Microsoft Anti-Cross Site Scripting Library to encode output. This library differs from most encoding libraries in that it uses the "principle of inclusions" technique to provide protection against XSS attacks. This approach works by first defining a valid or allowable set of characters, and encodes anything outside this set (invalid characters or potential attacks). The principle of inclusions approach provides a high degree of protection against XSS attacks and is suitable for Web applications with high security requirements."

Check it out @ http://msdn2.microsoft.com/en-us/security/aa973814.aspx

This came across on one of the lists that I am on. One of the best books on Security, “Security Engineering” by Ross Anderson is now available for free on the web!

Here is the chapter index:

1. What is Security Engineering?
2. Protocols
3. Passwords
4. Access Control
5. Cryptography
6. Distributed Systems
7. Multilevel Security
8. Multilateral Security
9. Banking and Bookkeeping
10. Monitoring Systems
11. Nuclear Command and Control
12. Security Printing and Seals
13. Biometrics
14. Physical Tamper Resistance
15. Emission Security
16. Electronic and Information Warfare
17. Telecom System Security
18. Network Attack and Defense
19. Protecting E-Commerce Systems
20. Copyright and Privacy Protection
21. E-Policy
22. Management Issues
23. System Evaluation and Assurance
24. Conclusions
25. Bibliography

Check it out!

I am trying to troubleshoot an installation of L2TP VPN on my SBS2K3 network.  I had set this up to work at one point, but that was before I upgraded to ISA 2004 and the expiry of my laptop computer cert.

The issue is around the inability to request a computer certificate for a client computer. I keep getting the error “The certificate request failed. The RPC server is unavailable.” whenever I attempt to request a Computer Cert for the laptop. I am also seeing a “DCOM was unable to communicate with the computer XYZ using any of the configured protocols” in my System Event Viewer.  Did some web searching and came across this entry which seemed to be an exact duplicate of my problem. But the solution does not seem to work for me.  Just for the record, I am logged into the domain with domain admin creds, disabled the Wi-Fi connectivity, and am connected using a hard line to the internal network.  Has anyone come across this problem and resolved it?

Is there a documented method for setting up L2TP VPNs on a SBS2K3 network? I was using the excellent instructions in the “Windows Small Business Server 2003 Administrator’s Companion” by Charlie Russel, Sharon Crawford and Jason Gerend, but the relevant section of the book became outdated when ISA 2004 was released for SBS2K3.

Someone on one of the OASIS lists asked for a “SAML Elevator Pitch”. Eve Maler [Sun] pointed to her “SAML in a technical nutshell” [PDF] slide desk. Good read!

SAML in a technical nutshell:

• XML-based framework for marshaling security and identity information and exchanging it across domain boundaries
  • Wraps existing security technologies rather than inventing new ones
  • Its profiles offer interop for a variety of use cases, but you can extend and profile it further
• At SAML's core: assertions about subjects
  • Assertions contain statements: authentication, attribute, entitlement, or roll-your-own

Key use cases covered by SAML out-of-the-box:

• Single sign-on
  • Using standard browsers
  • Using enhanced HTTP clients (such as hand-held devices) that know how to interact with IdPs but are not SOAP-aware
• Identity federation
  • Using a well-known name or attribute
  • For anonymous users by means of attributes
  • Using a privacy-preserving pseudonym
• Attribute services
  • Getting attributes that can be interpreted according to several common attribute/directory technologies
• Single logout

Have you ever wanted to pay a friend for lunch or settle a coffee bill? And wanted to do it while you were out and about directly from your Mobile phone? Then check out the new PayPal mobile service.

Security is an important consideration for something like this and they do a good job of making sure that Identity and Authentication remain distinct.  For a good read on this topic, check out Steve Riley’s article on TechNet on this topic.

To reprise some elements of the above article, Identity is that answer to the question “Who are you?” that you present to the system that you wish to access. The interesting thing about Identity is that it is a claim that you make about yourself using something public like a ATM Card, a User ID or in this particular case your cell phone and the corresponding cell phone number. Authentication is the answer to the question “Can you prove you are you?”. Common mechanisms for doing this are passwords, PINs etc. In short, this is a secret known to you and the system (The system either knows it or can verify that the secret is authentic). In this particular case, when you send the request to make a payment from your cell phone, the PayPal IVR system calls you back on your mobile phone number and you have to prove that you are indeed you by putting in a shared secret that only you and PayPal know about. Your possession of the secret verifies that you are you and the payment proceeds. Very nice!

[Now playing: The Mummers' Dance - Book of Secrets]

J.D. Meier is the Program Manager on the patterns & practices team who is focused on helping customers incorporate security and performance into their life-cycle.  In his own words “Who wants an insecure app that scales ... or a "secure" app that won't?”

He has a great deal of information to share and now that he has a weblog, he has a place to share them as well. Check out his latest entries:

• High ROI Engineering Activities
• Domain Specific Categories
• Web Application Security Frame

I especially love his entry on Security Approaches that Don’t work.

“Federation refers to the establishment of some or all of business agreements, cryptographic trust, and user identifiers or attributes across security and policy domains to enable more seamless cross-domain business interactions. As web services promise to enable integration between business partners through loose coupling at the application and messaging layer, federation does so at the identity management layer - insulating each domain from the details of the others' authentication and authorization infrastructure.” — SAML Executive Overview [PDF]

This is a big deal to any distributed enterprise that needs to manage Identity and provide Single Sign On. Security Assertion Markup Language (SAML) 1.1, which is an OASIS Standard, has been an accepted mechanism for accomplishing this.  SAML is something is extensively leveraged within the Enterprise that I work in, so this is of particular interest to me. SAML 2.0 is the next generation of this technology that is going through the OASIS standardization process and is backed by folks like the Liberty Alliance among others. I recently read in an Infoworld article that Microsoft will not be supporting SAML 2.0, but will instead back the WS-Federation protocols. WS-Federation is an effort that is being backed by companies such as IBM, Microsoft, BEA Systems, RSA Security, and VeriSign.

I am unsure of what this means as of yet, so I need to do some further research into both efforts. Here are some links to various sources of information on both efforts so that we can understand, hopefully, what the technical approach each effort is taking, and the impact if one chooses one approach versus the other.

J.D. Meier, the guy who was responsible for driving PAG’s books on “Improving Web Application Security” and “Perf & Scale” has some great blog postings that cover various aspects of Security Engineering.  These are must read items if you wish to bake in security as part of your Software Development Life-cycle.

In particular check out:

• Threat Modeling Terms and How to Use Them
• Context Precision
• Security Approaches that don’t work
• High ROI Security Activities

This material is so very relevant to some work that I am currently doing and J.D. has been kind enough to allow me to review some of this material and reference it. [I am not a big believer in re-inventing the wheel].

Heck, just subscribe to the man’s blog! He puts out some very, very good info!

I am currently in the process of reviewing some material for the PAG on Security Engineering.. In short how to bake in security practices into the development life-cycle. Keith has a blog entry about this as well, so I won’t repeat it here. What I will say is that this is a very approachable and readable material that is targeted at the developers who work in the trenches.  I am very much looking forward to this. A good jumping off point for the Security Goodness that the PAG is putting out is http://msdn.com/securityguidance

During the MVP Summit, the developer security MVPs such as myself, had a chance to spend some time with Michael Howard, the author of “Writing Secure Code”. He is currently working on a book on the Secure Development Life-cycle which I am very much looking forward to reading as well.

Foundstone has released a white-paper based on a bug that they discovered that “…..describes the limitations of the FormsAuthentication.SignOut method and provides more information about how to ease cookie replay attacks when a forms authentication cookie may have been obtained by a malicious user.  The paper introduces methods that web developers can employ to reduce cookie replay attacks in the ASP.NET applications.  Some of these methods include:

• Use SSL by configuring the Web application in Microsoft Internet Information Services.  This ensures the forms authentication feature will never issue a cookie over a non-SSL connection.
• Enforce TTL and use absolute expiration instead of sliding expiration.
• Use HttpOnly cookies to ensure that cookies cannot be accessed through client script, reducing the chances of replay attacks.
• Use the membership class in ASP.NET 2.0 only in order to protect forms authentication cookies from being used maliciously by storing user information in the MembershipUser object.” 

Check it out here [PDF]

According to them, in response to this bug, Microsoft now has a KB article that details the limitations of the FormsAuthentication.SignOut Method

Security Engineering Index
http://msdn.microsoft.com/SecurityEngineering

This page provides an index to available and emerging guidance for patterns & practices Security Engineering. To build secure applications, security engineering activities must be an integral part of your software development practices. patterns & practices Security Engineering builds on, refines, and extends core life cycle activities to create security-specific activities. You can adopt these activities incrementally as you see fit. These security activities are integrated in MSF Agile, available with Visual Studio Team System. This provides tools, guidance, and workflow to help make security a seamless part of your development experience.

Security Guidance Index
http://msdn.microsoft.com/SecurityGuidance

This page provides an index of patterns & practices Security Guidance for applications. The resources include guides and books available on MSDN together with modular content of various types including scenarios and solutions, guidelines, explained, checklists, and How Tos.

Threat Modeling
http://msdn.microsoft.com/ThreatModeling

This guidance presents the patterns & practices approach to creating threat models for Web applications. Threat modeling is an engineering technique you can use to help you identify threats, attacks, vulnerabilities, and countermeasures that could affect your application. You can use threat modeling to shape your application's design, meet your company's security objectives, and reduce risk.

Security How To Index
http://msdn.microsoft.com/library/en-us/dnpag2/html/SecurityHowTosIndex.asp

This page provides an index of patterns & practices Security How Tos organized using multiple views by categories. The "A Through Z" view at the bottom lists each How To in alphabetical order.

The security engineering index happens to be among my favorite security resources and the Security How-To Index is awesome!

Lots of good publicity recently on the security resources that the PAG has been putting out. Excellent!

As I noted in my earlier entry back in June, the starting point for pretty much all of this goodness, even before it becomes live on MSDN, is the Patterns & Practices Security Wiki.

An invaluable resource you should check out AND contribute to! 

I spent some time yesterday upgrading my SBS2003 home network to SP1.  The document written by the SBS MVP’s on “How to Install Service Pack 1 for SBS 2003” was very helpful in this regard. Thank You!

I currently have a networked Tivo in my home network which I moved to a land line some time ago, primarily so that I could beef up the security on my wireless network.  The Tivo firmware STILL does not support anything more than WEP and I most definitely was not comfortable with the “security” of WEP.  The key point with having the Tivo on the home network is that, if you want it to use the network to connect to the Tivo service, you need to set it up as a SecureNAT client.

In ISA Server 2004 2000, in addition to setting it up as a SecureNAT client, I had to open the out-bound TCP ports 1026, 4006 and 8080 for the Tivo to connect to the service. The great thing in ISA 2004 was that I could get rid of all of those extra items that I needed to set up. 

In ISA Server 2004:

• Internet Access Firewall Policy: Tivo => External Network
  External network is predefined in ISA and I added the Tivo as a Computer Network Object
• Protocol == All Out-bound Traffic
• Condition == All Users
  All Users group includes both authenticated and unauthenticated users. The SecureNAT client is an unauthenticated user.
• Go into the HTTP Protocol and disable the “Web Proxy”  Application Filter.

The above limits unauthenticated users to the Tivo box which is now on a closed land line network which I physically control.  All other machines in the network require authentication and utilize the ISA 2004 Firewall client.

Microsoft, earlier this month, released v2.0 of MBSA. Here is the official blurb:

“In response to direct customer need for a streamlined method of identifying common security misconfigurations, Microsoft has developed the Microsoft Baseline Security Analyzer (MBSA). Version 2.0 of MBSA includes a graphical and command line interface that can perform local or remote scans of Windows systems. MBSA runs on Windows Server 2003, Windows 2000, and Windows XP systems and will scan for common security misconfigurations in the following products: Windows 2000, Windows XP, Windows Server 2003, Internet Information Server (IIS) 5.0, and 6.0, SQL Server 7.0 and 2000, Internet Explorer (IE) 5.01 and later, and Office 2000, 2002 and 2003. MBSA also scans for missing security updates, update rollups and service packs published to Microsoft Update.”

Definitely a tool that should be in your Security Toolbox. Check it out….

One of the basic tenets of secure coding is that ALL input is EVIL and should be validated and sanitized before being allowed into the application.  This is also definitely an area where a lot of mistakes can be made.

The PAG folks have written a set of modular How-To's to tackle the finer points of injection attacks and as such implement effective input validation in your ASP.NET Applications. The guidance covers both .NET 1.1 and 2.0.

Check them out:

• How To-Protect from Injection Attacks in ASPNET
• How To-Use Regular Expressions to Constrain Input in ASP.NET
• How To-Protect from SQL Injection in ASP.NET
• How To-Prevent Cross-Site Scripting in ASP.NET
         
  
  

Ha! Who cares about TechEd! More interesting things are happening as part of the patterns and practices Security wiki coming out party! 

Ward Cunningham, Yes.. THAT Ward Cunningham,  walked through with the PAG Security folks on a scenario and a solution for an application and documented the process on the wiki. Check it out!

If you are a software developer and you are interested in making sure that your application is robust and secure, this is a MUST see & utilize resource!

The PAG ( patterns & practices ) folks have put online a resource that provides a view into their present and future deliverables around security engineering to application scenarios. The additional benefit is that the content is provided as a wiki so that the community can annotate, elaborate and contribute.

The security wiki is brought to you by the same folks who brought you "Improving Web Applicaton Security" and "Building Secure ASP.NET Applications" which are both great resources in their own right.

In their own words "This is where we think out loud. Here you’ll find emerging practices, guidance for application scenarios, security engineering, threat modeling, technical guidance and more. We’re looking for your experience, input and feedback to make this a useful resource for application security."

I've had the pleasure of working with the PAG folks on this effort.. I hope that you will also take this opportunity to contribute to making this security wiki a living, working resource that will improve the state of software security.

Check it out @ http://Channel9.Msdn.Com/Security

The topics discussed include everything from ApplicationSecurityMethodology to WebServerSecurity. The products and technologies cover everything from NETFrameworkSecurityHub to ASPNET2SecurityHub.  Some of the resources that are provided include SecurityChecklists (These are awesome, BTW!) to information about the SecurityBlocks.

Highly recommended!

Gary McGraw of Cigital, co-author of "Exploiting Software" and "Building Secure Software", has been writing a series of articles on secure coding issues in the IEEE Security & Privacy magazine.  As a service to the community, he has provided free PDF downloads of the articles at his web site. Be sure to check them out.

• Software Security
• Regulation and Information Security
• Risk Analysis in Software Design
• Misuse and Abuse Cases: Getting Past the Positive
• Static Analysis for Security
• Software Penetration Testing
• Knowledge for Software Security
• Adopting a Software Security Improvement Program

The Patterns & Practices folks have released an updated Security Guidance regarding Threat Modeling for Web Applications.

The Threat Modeling process as defined here is context-relevant (i.e. The threat model for a Web App is going to be different from a Win Forms application) as well as a more iterative process. The iterative threat modeling process as defined here consist of:

• Step 1: Identify security objectives. Clear objectives help you to focus the threat modeling activity and determine how much effort to spend on subsequent steps.
• Step 2: Create an application overview. Itemizing your application's important characteristics and actors helps you to identify relevant threats during step 4.
• Step 3: Decompose your application. A detailed understanding of the mechanics of your application makes it easier for you to uncover more relevant and more detailed threats.
• Step 4: Identify threats. Use details from steps 2 and 3 to identify threats relevant to your application scenario and context.
• Step 5: Identify vulnerabilities. Review the layers of your application to identify weaknesses related to your threats. Use vulnerability categories to help you focus on those areas where mistakes are most often made.

I am the Vice-Chair of the IEEE Computer Society (Baltimore Chapter).  Our next technical meeting will be held on Thursday, May 19, 2005 (6:30 p.m - 8 p.m) at the Historical Electronics Museum. Please note that both IEEE Members AND Non-Members are welcome to attend!

If you are interested in Information Security, please join us.

TOPIC

"Application of Operations Research techniques in Infosec" by Dr. Julie J.C.H. Ryan.

ABSTRACT

There is a great deal of opportunity in using the techniques and methods in operations research to investigate the operational aspects of information security. At GWU, we are embarked on a long-term research effort to systematically investigate the application of OR methods to operational information security to see which provide the most promise for more in-depth study. So far we have investigated the use of the Cox model, most commonly used in medical research, and the approach of expert judgment elicitation. This talk will provide a brief overview of the work performed to date and the results achieved through these efforts.

ABOUT THE GUEST SPEAKER

Julie J.C.H. Ryan received her D.Sc. from The George Washington University (GWU) in Engineering Management and Systems Engineering. She holds an M.L.S. in Interdisciplinary Studies from Eastern Michigan University and a B.S. from the United States Air Force Academy. She is currently an Assistant Professor at GWU. Her research interests include information security, knowledge management, international relations, and information warfare. She worked for 18 years as an information security specialist, systems engineer, intelligence data analyst, and policy consultant prior to her academic career. She is the co-author of "Defending Your Digital Assets Against Hackers Crackers, Spies, and Thieves" (2000, McGraw-Hill).

LOCATION

Historical Electronics Museum
1745 West Nursery Road
Linthicum, Maryland

Directions @ http://www.hem-usa.org/contact.html

Came across an interesting comment on one of the lists that I am on. 

It would appear that Michael Howard and David LeBlanc, the authors of Writing Security, are working on a new book with John Viega (Building Secure Software) and David Wheeler which is scheduled to hit the shelves in about 6 months.  According to LeBlanc, they specifically chose this set of authors to provide really good cross-platform coverage.

Looks like a must have book!

Gary McGraw has a series of articles in IEEE Security & Privacy that address secure coding issues. As a service to the community, he has made the articles available to the community. The current article in the series ".... is on Penetration Testing.  This article was co-authored by Brad Arkin (Symantec) and Scott Stender."

Previous articles in the series:
http://www.cigital.com/papers/download/bsi5-static.pdf
http://www.cigital.com/papers/download/misuse-bp.pdf
http://www.cigital.com/papers/download/risk-analysis.pdf
http://www.cigital.com/papers/download/j2oth-qxd.pdf
http://www.cigital.com/papers/download/software-security-gem.pdf
http://www.cigital.com/papers/download/bsi6-pentest.pdf

Check them out!

I just got back from the CMAP .NET User Group meeting during which I did 2 short presentations. At CMAP's December meetings we have a "10 Tips & Tricks for the Holidays" presentation format in which members do short 10-15 minute presentations on various topics. This year's topics ranged from my stuff to a demo of how to use client side script in ASP.NET.  My topics were "Instrumenting .NET Code with Log4Net" and "Applying Defense-in-Depth to protecting admin sections of web sites". 

During the instrumenting & logging presentation I mentioned that K. Scott Allen has a great write-up on Diagnostics and Logging in ASP.NET and that people should check it out to get a background on the "Why?" regarding instrumenting applications. Then I went into a short description of what Log4Net brought to the table and compared it to the PAG's Exception Management Block and the Logging Block.  In addition, I also had an earlier blog entry about incorporating logging into a web application.

My Defense-in-Depth short presentation was an expansion of an earlier blog entry that I had made on this topic.

Jerry Bryant [MS] has an excellent post with links to Security resources that are provided by Microsoft. I am copying this here so that I do not have to go looking for them later:

Tools

• Microsoft Baseline Security Analyzer (MBSA)
  Use this tool to identify common security misconfigurations and missing security updates. MBSA runs on the Windows Server™ 2003, Windows® 2000, and Windows XP operating systems and will scan for vulnerabilities in multiple products and technologies, including Microsoft Internet Information Services (IIS) and SQL Server™.
• Software Update Services (SUS) / Windows Update Services (WUS)
  Quickly and reliably deploy the latest security updates, and service packs with Software Update Services. This new site now has the latest info on WUS.
• Windows Update
  Scans your computer and provides a selection of updates tailored for your operating system, software, and hardware.
• Microsoft Office Product Updates
  Scans and updates Microsoft Office products.
• IIS Web Server Lockdown Wizard
  Reduces the attack surface of Internet Information Services (IIS) and includes URLScan to provide multiple layers of protection against attackers.
• UrlScan Security Tool
  Helps prevent potentially harmful HTTP requests from reaching IIS Web servers.

• Mydoom, Zindos and Doomjuice worms
• Blaster Removal Tool for Windows XP and 2000
• Sasser (A-F) Worm Removal Tool
• MS04-028 Enterprise Scanning Tool    

• http://www.microsoft.com/technet/security/tools/default.mspx
• Security Risk Self-Assessment for Midsize Organizations

• Understanding Update Management: Microsoft’s Software Update Strategy
  Updated white paper talks about the need for strong update management process.
• Other Update Management info in the TechNet Topics Page

• Listing of resources for the IT Pro to evaluate and deploy XP SP2
• Network Access Protection
• Internet Security and Acceleration (ISA) Server 2004 whitepapers updated
  Read about secure remote Outlook access in the Unique Protection for Microsoft Exchange Server whitepaper, a very viable business scenario with ISA Server

• Trustworthy Computing: Security
• Whitepapers on Security Enhancements:
  Describes the Trustworthy Computing initiative as applied to the Windows Server, Office 2003 and Exchange Server 2003 development processes respectively.
  Windows Server 2003
  Office 2003
  Exchange Server 2003
• Get the Facts:
  Windows and Linux
• SQL

• Security Guidance Centers on Microsoft.com
  Worldwide
  US
  Prescriptive guidance to help provide defence-in-depth security.
• E-Learning Security Training
  E-Learning self-paced clinics - 4 Developer and 8 ITPro modules
  Now available in French, German, Spanish and Japanese
  XP SP2
• Security Guidance Kit CD (now shipping in US and Canada)
  CD-ROM with tools, templates, and how-to guides
• Microsoft IT Security Showcase
  An insider view into Microsoft's process of deploying, and managing its own enterprise solutions.
• Security Newsletter
  Register for our free monthly e-mail newsletter that's packed with security news, guidance, updates, and community resources to help you protect your network.
• Security Program Guide: Events and Training Information
  Events, webcasts and training ivailable for both IT Professionals and Developers.
• US Security Summit Keynote and Training Content
• Security Notifications via e-mail
  Sign up today to get e-mail alerts when an important security bulletin or virus alert has been released.
• Security Update RSS Feed
• Security Bulletin Search Page
  Search on product, technology or KB article
• Security Bulletin Webcast
  Join Microsoft experts on the day after bulletin announcements to get the latest information and have the opportunity to ask questions.
• How to Tell If a Microsoft Security-Related Message Is Genuine
• Writing Security, 2nd edition
  Best practices for writing Security and stopping malicious hackers.
• Building and Configuring More Secure Web Sites
  Best Practices used at OpenHack.
• Recent Security Guidance Center additions:
  Windows XP Guide, includes SP2
  New Security Risk Management Guide
  Windows NT 4.0 and Windows 98 Threat Mitigation Guide
  Microsoft Identity and Access Management Series
  Antivirus Defense-in-Depth
  Securing Wireless LANs with PEAP and Passwords
• Small Business Guidance
  Guidance specifically for the smaller business
• Configuring Windows XP 802.11 Wireless Networks for the Home / Small Business
• Consumer Information:
  http://www.microsoft.com/security/protect
  http://www.microsoft.com/athome/security/default.mspx
• Newsletter for home users
• Security bulletin notifications for home users
  

Michael Howard discusses how you can run as an administrator and access Internet data safely by dropping unnecessary administrative privileges when using any tool to access the Internet.

He has created an application called DropMyRights to help users who must run as an administrator run applications in a much-safer context—that of a non-administrator. It does this by taking the current user's token, removing various privileges and SIDs from the token, and then using that token to start another process, such as Internet Explorer or Outlook. This tool works just as well with Mozilla's Firefox, Eudora, or Lotus Notes e-mail.

Check out the article...

Like most computer savvy folks these days, the amount of digital "stuff" in my house is growing rather rapidly. That includes:

• MP3 music files that I've ripped from my CDs
• Photos from my digital camera
• Videos that I've taken
• Documents and Papers
• Source Code stored in my CM system
• Virtual Machine Images
• and more...

Needless to say I have multiple computers in the house that are connected via both wired and wireless networks.  Currently I am running a Windows 2000 Domain in the house as my server class machine, which is a bit old, is not one I have upgraded to Windows 2003. All my Windows 2003 machines are Virtual Machines

1. I need a redundant and reliable file storage for my network. A lot of the content that I have on the network is simply things I cannot afford to lose.
2. I want to lock down my wireless network.
3. ASP.NET Development environment.
4. I am seriously getting into collaboration via Windows SharePoint Services. So I am looking to make sure that I have an environment that I can play a bit with it.. A personal goal, at least for the home, is to have a shared calendar for the family.

The issue I have is that the highest level of encryption Tivo supports is 128 WEP. It does not support WPA at all!  This has limited my ability to upgrade the security of my Wireless network. So, I've gotten irritated enough that I am pulling wires to my Tivo to convert it from wireless to a hard line. Once this is done, my plan is to implement 802.11x authentication with certificates and lock down the the network.. Now, if I you ask me if I REALLY need to do this, the answer would be, probably not.. But I can, so I will

The premier issue of TechNet Magazine is out and it is focused on Security. Sections include

• Hacking: Fight Back
• Cross-Platform Security
• Security: Beyond the Basics

Check it out the full issue which is availabe for free online.

Of course, the current issue of MSDN Magazine is also focused on security. Topics include Attack Surface minimization, App Lockdown, Crypto and more. Check it out online as well.

One of my fellow CMAP User Group Members, Scott McMaster, recently posted a question on our listserve:

"Like most people, I imagine, I've always considered Windows Authentication for intranet-only scenarios.  However, from what little relevant discussion I've been able to find on the subject, it appears that using Windows Authentication to access domain-hosted ASP.NET applications over the Internet using IE5+ is a valid approach as long as IIS is properly configured (i.e. no anonymous access, no basic auth).  IE and IIS do NTLM/Kerberos without sending passwords around, and the world is nice and safe."

 Just to level-set here, this is the web server and browser configuration:

• Website is set for only Integrated Windows Authentication
• Stand alone client machine on the Internet (Not logged into domain)
• Browser is IE 5+

Now, I am a bit... ah.. paranoid when it comes to things like this.  Given the fact that if you are on the Internet and are not connected to a domain, you get a login prompt, I went with the assumption that if the login prompt came up and you had to enter your domain credentials, then they were sent as clear text.  Well, Scott was persistent and was backed up by our local DCC, Geoff Snowman, who also chimed in that it was valid to use Integrated Windows Authentication on the Internet.

By this time, I was well and truly engaged.  In communicating privately with Scott, the resources that we were finding in our searches were simply not that clear on this point ... at least to me   So, following my traditional method of when in doubt, ask the experts, I asked the question regarding this scenario on a list that I am on and got a definitive answer from Ken Schaefer, who just so happens to be an IIS MVP.

The short answer, Scott's research proved to be right, my assumptions were wrong, and the world is a safer place

The long answer is as follows (The answers are pretty much a direct quote from Ken. My stuff in bold):

Integrated Windows Authentication covers two authentication mechanisms - Kerberos and NTLM. Neither authentication mechanism allows for plain-text credentials (well, not of the password anyway).

In general:

• Whether the site is in the Intranet security zone determines whether IE attempts to automatically authenticate when prompted by the server.
• Whether the site is in the Internet security zone determines whether IE attempts to use Kerberos authentication (Kerberos authentication requires the client machine to be able to contact the KDC to get TGTs etc, and generally this isn't possible in an Internet setting, so IE uses NTLM instead).
• Whether your user is logged on to the domain or not, on their workstation, is irrelevant to determining the authentication mechanism used, or how IE sends credentials to the server.

If the site is placed into the local Intranet security zone -and- Internet Explorer is still in its default configuration (if you go to Tools -> Internet Options -> Security -> Custom settings for Intranet zone, there is an option "automatic logon only in Intranet zone"), then Internet Explorer will attempt to log you on using your current logged on credentials when the web server sends back its 401 response (IE will attempt an anonymous request first no matter what the configuration, then the server will send back a 401, then IE will attempt to auto-logon). If the credentials IE sends automatically are not accepted by the server (the server sends back another 401), then IE will prompt you to supply alternate credentials.

The important thing to note here is that if the browser is IE, the domain credentials that I enter are NOT sent in cleartext but instead use either NTLM or Kerberos depending on the configuration above.

Neither NTLM nor Kerberos authentication uses plain text to pass the password.  NTLM authentication uses the NTLM hashing algorithm to generate a hash of  the password. This is sent across the wire by the client and is compared to the hash of the password stored by the web server (for local accounts) or by the DC (for domain accounts). If the hash matches, then the user is authenticated. (The process is actually a little more complex, otherwise anyone could just sniff a hash and use that). If you want the gory details, check out: http://davenport.sourceforge.net/ntlm.html (about 40% of the way down the page is a section titled "The NTLM v2 Response" which describes how the hash is constructed when using NTLM v2). Kerberos authentication uses Kerberos tickets.

Excellent! It is a good day when you learn something new. It is a great day when what you have learned can improve your security. Thanks Guys!

Mark Burnett, who is the author of "Hacking the Code", has a couple of great articles posted to the OWASP site.

• Using Secret Question to recover passwords
• Blocking Brute Force Attacks

There has been much talk about what is considered a secure password. So it was a true pleasure for me to recently read a fascinating study on this topic that provided some hard numbers to back up the claims.  The study was published in the current issue of IEEE Security and Privacy and is titled "Password Memorability and Security: Empirical Results" by Jeff Yan, Alan Blackwell, Ross Anderson and Alasdair Grant.

First some background. Per the article "Human memory for sequences is temporally limited, with a short term capacity of around seven, plus or minus two items. In addition, when humans do remember a sequence of items, those items be familiar chunks such as words or familiar symbols. Finally, human memory thrives on redundancy-we're much better at remembering information we can encode in multiple ways"

So what these folks did was have three separate test groups:

Then the testers ran the following types of attacks against the passwords:

• Dictionary attacks: Simply use different dictionary files to crack the passwords
• Permutation of words and numbers: For each word from a dictionary file, permute with 0, 1, 2 and 3 digits and also use common number substitutions such as 1 for an I and 5 for S etc.
• User information attacks: Exploit user data that is collected from password files such as userid, full name etc
• They also tried brute force attacks (Try all possible combination of keys) against passwords 6 characters long.

Pick up and read the article itself for the details and the numbers, but the conclusions are interesting. The permuted dictionary attack was the most successful and the brute force attack successfully cracked all six-character passwords. 

They also confirmed the two folk beliefs that "... user have difficulty remembering random passwords and that passwords based on mnemonic phrases are harder to guess than naively selected passwords." They have also debunked the folk beliefs that "... random passwords are better than passwords based on mnemonic phrases. Each appeared to be as strong as the other" and that "... passwords based on mnemonic phrases are harder to remember than naively selected passwords. In fact, each type is as easy to remember as the other".

Some of the key take-aways were:

•  "... security can be significantly improved by educating users to select mnemonic passwords
• Size of the password matters
• Entropy per character matters, so instruct users to choose passwords containing numbers and special characters as well as letters."
  

So what does this mean for me?  Well from now on, my password selection page is going to have the following (Some of the content is adapted from the directions that were given to the mnemonic group in the test):

• Choosing a good password is critical to maintaining the security of this system. To construct a good password, create a simple sentence of 8 to 9 words and choose letters from the words to make up a password. You might take the initial or final letters; you should put some letters in upper case to make the password harder to guess; and at least one number and special character should be inserted as well.  An example is the phrase "It's 12 noon and I am hungry" which can be used to create the password "I's12n&Iah".  All passwords will be checked to make sure that the following complexity requirements are met: 

  • Must be at least 9 characters
  • Must contain at least one lower case letter, one upper case letter, one digit and one special character
  • Valid special characters are -   @#'$%^&+=
    

Oh yes, as a bonus here is a regex that will enforce the above complexity requirement:

^.*(?=.{9,})(?=.*\d)(?=.*[a-z])(?=.*[A-Z])(?=.*[@#'$%^&+=]).*$

It has been interesting to me to see the recent ASP.NET vulnerability play out.  One of the main factors that came into focus for me was that most developers do not seem to consider the principal of Defense in Depth when it comes to writing privileged code.

Since an example speaks much louder than lectures, lets take the following case..

My web site is as follows:

\webroot
 - web.config
           \Camelot
                - ProtectedPage.aspx

My web.config has the following:

<location path="Camelot">
    <system.web>
        <authorization>
            <allow roles="KnightsRoundTable" />
            <deny users="*" /> 
        <authorization>
    <system.web>
<location>

In response to the vulnerability in ASP.NET forms authentication that was posted to NTBugtraq, Microsoft has released a HTTP Module and associated installer that "...  protects all ASP.NET applications on a Web server against canonicalization problems that are currently known to Microsoft.."

Find more info about it and install NOW!

There has been some discussion of late about passwords vs. pass phrases and how long a password should be. I won't add to the mix except to say that I am a believer when it comes to complex passwords. Heck, my 4 year old is required to use a userid and password to log into his session on his computer

I've recently been working on some things that require me to make sure that the passwords that are used are sufficiently complex.  Here is what I am using right now:

• Must be at least 10 characters
• Must contain at least one one lower case letter, one upper case letter, one digit and one special character
• Valid special characters are -   @#$%^&+=

^.*(?=.{10,})(?=.*\d)(?=.*[a-z])(?=.*[A-Z])(?=.*[@#$%^&+=]).*$

 

Robert has a great post in which he talks about some of the attacks that can be mounted against web sites.. In particular he gives good info on hidden field tampering, sql injection and cross-site scripting.

I just wanted to add a couple of notes to his most excellent comments on protecting the viewstate.  By default, view state transmitted to the client includes a salted hash. But you can also use the <machineKey> element to specify the encryption keys, validation keys and the particular algorithm used to protect both the forms authentication cookies as well as the page level view state.

<machineKey validationKey="AutoGenerate,IsolateApps" 
    decryptionKey="AutoGenerate,IsolateApps" validation="SHA1" />

The IsolateApps setting is new to .NET 1.1 and tells ASP.NET to automatically generate the encryption keys and make them unique for each app. The validation attribute specifies the algorithm used for checking the integrity of the page-level viewstate.

The caveat is that in a web farm scenario you would have to explicitly generate the keys to keep them the same across the web farm nodes. When you do so, make sure you use a cryptographically strong key.  I would highly suggest using Keith Brown's "GenerateMachineKey" utility which can be found on pluralsight's tools page.

The other thing that can be done is to key the view state to an individual using a unique value of your choice.  This option, which is again only available in ASP.NET 1.1, is the Page.ViewStateUserKey. This needs to be applied in Page_Init because the key has to be provided to ASP.NET before view state is loaded. Here is an example:

void Page_Init (Object sender, EventArgs e)
{ 
    if (User.Identity.IsAuthenticated)
        ViewStateUserKey = User.Identity.Name;
}

Make sure you check out Robert's blog entry...

I recently saw a BizTalk demo that utilized the WSE adapter to authenticate against a web service using an X.509 certificate.  From what I saw this was purely a machine to machine authentication. 

The question I have is "Is it possible to dynamically pass my credentials i.e. X.509 cert, into a BizTalk orchestration such that such that the authentication against an external web service is done using MY credentials?"

I *think* what I am looking for (I am not a BizTalk guru so may be getting my terminology mixed up) is for an Orchestration to run under my security context so that everything that is done as part of that orchestration is done using my credentials... Is it possible?  Scott? Anyone?

In the latest issue of Crypto-Gram, Bruce Schneier provides a "Cryptanalysis of MD5 and SHA" which looks at the weakness in the MD5 and SHA functions that were announced at the CRYPTO Conference recently. Some highlights:

"...  Today, the most popular hash function is SHA-1, with MD5 still being used in older applications. "

"..  To a user of cryptographic systems -- as I assume most readers are -- this news is important, but not particularly worrisome. MD5 and SHA aren't suddenly insecure."

"It's time for us all to migrate away from SHA-1."

"Luckily, there are alternatives. The National Institute of Standards and Technology already has standards for longer -- and harder to break -- hash functions: SHA-224, SHA-256, SHA-384, and SHA-512. They're already government standards, and can already be used."

.NET Provides out of the box support for MD5, SHA-1, SHA-256, SHA-384 and SHA-512 hashing algorithms. 

A major use of hash functions in a web based application is to store a password as a hash, or even better as a salted hash.  A frequently used helper function that is used by many to implement this functionality is the very appropriately named HashPasswordForStoringInConfigFile method of FormsAuthentication.  Presently, the only hash algorithms that are supported by this method are MD5 and SHA-1.  I REALLY would like to see this support extended to SHA-256.

One of the things I am researching a bit these days is how best to go about incorporating logging into a web based application.  I am looking at it from both an application troubleshooting perspective as well as a security perspective. 

• Do I need to have logging in my application even if I've W3C logs?

Yes, it's important that your application maintains "application level" logs even when W3C logging is used. As W3C logs contain records for every http request, it is difficult (and, at times impossible) to extract a higher level meaning from these logs. For instance, the W3C logs are cumbersome to identify a specific session of user and the activities that the user performed. It's better that the application keeps a trail of important activities, rather than decode it from W3C logs.

• What should I log from within my application?

Keep an audit trail of activity that you might want to review while troubleshooting or conducting forensic analysis. Please note that it is inadvisable to keep sensitive business information itself in these logs, as administrators have access to these logs for troubleshooting. Activities commonly kept track of are:

• Login and logout of users
• Critical transactions (e.g.. fund transfer across accounts)
• Failed login attempts
• Account lockouts
• Violation of policies

The data that is logged for each of these activities usually include:

• User ID
• Time stamp
• Source IP
• Error codes, if any
• Priority

• Error messages and information, including a stack trace of the error
• The state of internal data structures at key points in the application
• User actions, such as button clicks and menu item selections
• The time the significant actions were performed
• Important information about the environment, such as variable settings and available memory

• Audit and log access across application tiers
• Consider identity flow
• Log key events
• Secure log files
• Back up and analyze log files regularly

• Log IP Addresses
• If you are creating a lot of files, you should have your own log files and not use the OS Application Log
• Logs should go into a directory that is user configurable and it's best to create a new log file every day
• Consider creating multiple log files, one for routine events another for extraordinary events
• Application logs should be writable only by the administrator and the user the service runs under
• When code fails for security reasons, log the data in a place that only the administrator has access to

"Hacme Bank™ is designed to teach application developers, programmers, architects and security professionals how to create secure software. Hacme Bank simulates a "real-world" online banking application, which was built with a number of known and common vulnerabilities such as SQL injection and cross-site scripting. This allows users to attempt real exploits against a web application and thus learn the specifics of the issue and how best to fix it. Foundstone uses this application extensively in our Ultimate Web Hacking and Building Secure Software training classes. "

The application is written in ASP.NET (C#) and they have a "User and Solutions Guide" that walks you through the lessons. Very cool! You can find the link to download the software and the guide on Foundstone's Strategic Secure Software Page.

A link to this info (Thanks Susan!) came across on one of the lists that I am on:

USB "thumb drives" drive some security folks crazy because they're so small physically and so big storage-wise; what's to keep people from popping a USB drive into a USB slot, copying corporate data and walking out the door?  For the USB-paranoid, SP2 includes an ability to let users read data from a USB drive, but not write data to that drive.  It's a simple Registry change.  First, create a whole new key: HKLM\System\CurrentControlSet\Control \ StorageDevicePolicies.  Then create a REG_DWORD entry in it called WriteProtect.  Set it to 1 and you'll be able to read from USB drives but not write to them.

Cool!

From /. :

Cryptography Research has issued a Q&A that explains the security implications of the hash function collision attacks recently announced at CRYPTO 2004. Apparently the consequences can be catastrophic for certain kinds of code signing and digital signatures, but MD5 sums for checking binaries are (mostly) OK. While the speculation that SHA-1 is about to fail seems to be overblown, updating the many legacy systems and protocols that rely on MD5 is going to be a massive undertaking.

Per Mike Shaw:

There is now a new version of the Microsoft Security Baseline Analyzer updated.  MBSA is a tool that can be used to validate the configuration and patch status of computers on your network. It is a BASELINE tool i.e. it gives you a place to start with your security configuration.

You can get more details and download from: http://www.microsoft.com/technet/security/tools/mbsahome.mspx

The Windows XP Security Guide provides recommendations for deploying Windows XP in three distinct environments. The first and most common of these is an enterprise environment that consists of Windows XP running in a Windows 2000 or Microsoft Windows Server(tm) 2003 domain. The second consists of Windows XP in a high security environment in which security risk mitigation can be implemented at the highest possible level. Finally, guidance is offered for deploying Windows XP in a stand-alone or unmanaged environment. Information is also provided about the numerous new security options that are available in Windows XP Service Pack 2 (SP2).  

It looks like OWASP, one of my favorite web application security projects has updated their portal (Umm... Guys, where is the RSS feed? - at least for the news items on the front page?) AND even better, is starting local chapters!

I am chagrined to note that I missed the initial meeting of my relatively local chapter (Washington D.C) :-(  The DC chapter leader is Jeff Williams of Aspect Security and hopefully I can meet him and the rest of the like minded folks at the next chapter meeting. The DC chapter meetings are scheduled to meet the last Wednesday of every month.

Per Michael Howard:

Authentication and Access Control Diagnostics 1.0 (more commonly known as AuthDiag) is a tool released by Microsoft aimed at aiding IT professionals and developers at more effectively finding the source of authentication and authorization failures.

These users have often seen behavior from Internet Information Services (IIS) that doesn't seem appropriate or random when users authenticate to the IIS server. The complex world of authentication types and the various levels of security permissions necessary to allow a user to access the server causes many hours of labor for those tasked with troubleshooting these problems.

AuthDiag 1.0 offers a robust tool that offers a efficient method for troubleshooting authentication on IIS 5.x and 6.0. It will analyze metabase configuration and system-wide policies and warn users of possible points of failure and guide them to resolving the problem. AuthDiag 1.0 also includes a robust monitoring tool called AuthMon designed at capturing a snapshot of the problem while it occurs in real-time. AuthMon is robust and specially designed for IIS servers removing any information not pertinent to the authentication or authorization process.

Download @

• For x86 Platform
• For IA-64 Platform 
• For AMD64 Platform

The primary focus of Microsoft .NET Framework 1.1 Service Pack 1 (SP1) is improved security. In addition, the service pack includes roll-ups of all reported customer issues found after the release of the Microsoft .NET Framework 1.1. Of particular note, SP1 provides better support for consuming WSDL documents, Data Execution prevention and protection from security issues such as buffer overruns. SP1 also provides support for Windows XP Service Pack 2 to provide a safer, more reliable experience for customers using Windows XP.

• .NET 1.1 Service Pack 1 for Windows XP
• .NET 1.1 Service Pack 1 for Window 2003

Ken on the SC-L Listserve asked for suggestions on ".... first steps that developers might consider, even in the absence of top-level embracing of a more secure development methodology" and Hans Westphal [MS] responded with the following list of excellent resources. I am putting this down for my own benefit!

Subscribe to Security lists:
Sc-l@securecoding.org, NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM

Self Education through books:

• Secure Coding: Principles and Practices
• Writing Security 2nd edition
  

and Webcast's:

MSDN Webcast: Secure Mobile Data Using the Microsoft .NET Compact Framework and SQL CE 2.0 - Level 300
Wednesday, September 01, 2004 - 11:00 AM-12:30 PM Pacific Time
Rob Tiffany, President, Hood Canal Mobility

Would you like to be certain that data on a mobile device is secure? Without needing any knowledge of cryptography, you can build an application that lets users check-in and check-out their sensitive files.  This webcast focuses on building an encrypted, password-protected storage vault for files residing on Pocket PCs.
http://www.placeware.com/cc/mseventsbmo/join?id=1032257382&role=attend&pw=webcast

MSDN Webcast: Essentials of Application Security (Part 1) - Secure Communications - Level: 200
Friday, September 3, 2004 - 9:00 AM-10:00 AM Pacific Time
Ron Cundiff, MSDN Developer Community Champion, Microsoft Corporation
This webcast is the first of a 3-part series about the importance of Application Security and its best practices and guidelines. This part specifically addresses Secure Communications in the context of secure
application development. After an overview of the costs of inadequate security and the benefits of developing secure applications, this presentation concentrates on secure communications as part of a larger
security solution, examining specific techniques such as using certificates in the Secure Sockets Layer (SSL). The webcast includes two demonstrations: Buffer Overruns and SSL Server Certificates.
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032257602&Culture=en-US


MSDN Webcast: Essentials of Application Security (Part 2) - Authentication - Level: 300
Tuesday, September 7, 2004 - 9:00 AM-10:00 AM Pacific Time
Ron Cundiff, MSDN Developer Community Champion, Microsoft Corporation
This webcast is the second of a 3-part series about the importance of Application Security and its best practices and guidelines. This part specifically addresses Authentication in the context of secure application development. After an overview of the costs of inadequate security and the benefits of developing secure applications, we concentrate on Authentication as part of a larger security solution, examining specific Authentication techniques and best practices in IIS. The webcast includes two demonstrations: Buffer Overruns and IIS Authentication Techniques.
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032257885&Culture=en-US


MSDN Webcast: "Ask The Developer Security Experts" Series: Windows XP Service Pack 2: A Developer Overview - Level: 200
Tuesday, September 7, 2004 - 11:00 AM-12:00 PM Pacific Time
Tony Goodhew, Product Manager, Microsoft
This webcast series brings together some of the sharpest security-focused Microsoft developers to provide expert answers to your security questions. Beginning with a brief overview of Windows(r) XP Service Pack 2 (SP2), we will focus the discussion on what these changes mean for you as a developer and how these changes will affect your various development tools. This presentation will be followed by an
extensive Q&A period where you can "Ask the Experts" your in-depth questions about Windows XP SP2.  Do you have a question you want to submit to the experts before the webcast? Send your security questions
about Windows XP SP2 to our panel of experts ahead of time at devxcast@microsoft.com.
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032257887&Culture=en-US


MSDN Webcast: A Hackers View of Your Web Applications Part 1: Procedures for Code Security - Level: 300
Tuesday, September 7, 2004 - 1:00 PM-2:00 PM Pacific Time
Dennis Hurst, Senior Consulting Engineer, SPI Dynamics
With the threat of cyber attacks, today's Web environment has made application security an essential element in the application development lifecycle. The first part of this two part series will define what Web
application security is, why it is needed, and how it differs from other categories of Internet security. Additionally, we will examine appropriate procedures and technologies essential to the security of Web
application code. Through a review of recent Web application breaches, we will expose the prolific methods hackers use to execute break-ins via the Web. By taking an in-depth look at how Web-based applications work and the techniques hackers use to exploit them, you will be better equipped to protect your confidential information.
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032257889&Culture=en-US


MSDN Webcast: Essentials of Application Security (Part 3) - Authorization - Level: 300
Friday, September 10, 2004 - 9:00 AM-10:00 AM Pacific Time
Ron Cundiff, MSDN Developer Community Champion, Microsoft Corporation
This webcast is the third of a 3-part series about the importance of Application Security and its best practices and guidelines. This part specifically addresses Authorization in the context of secure
application development. After an overview of the costs of inadequate security and the benefits of developing secure applications, we concentrate on Authorization as part of a larger security solution,
examining Trusted Subsystem Model Authorization techniques and best practices. The webcast includes two demonstrations: Buffer Overruns and Trusted Subsystem Model Authorization Techniques.
http://msevents.microsoft.com/cui/eventdetail.aspx?EventID=1032257892&Culture=en-US


MSDN Webcast: A Hackers View of Your Web Applications Part 2: Web Hacking - Attack Scenarios and Examples - Level: 300
Monday, September 13, 2004 - 1:00 PM-2:00 PM Pacific Time
Dennis Hurst, Senior Consulting Engineer, SPI Dynamics
By taking advantage of the public access to a company and using it to subvert your applications, hackers can gain easy access into your company's sensitive backend data. Firewalls and IDS will not stop such
attacks because hackers using the Web application layer are not seen as intruders. In the 2nd part of this two-part series, learn how to defend against attacks at the Web application layer with examples covering
recent hacking methods such as: SQL Injection, Cross Site Scripting, Parameter Manipulation, Session Hijacking, and LDAP Injection.
http://msevents.microsoft.com/cui/eventdetail.aspx?EventID=1032257907&Culture=en-US


MSDN Webcast: Overview of XP SP2 for Developers - Level: 200
Tuesday, September 14, 2004 - 9:00 AM-10:30 AM Pacific Time
Tony Goodhew, Product Manager, Microsoft
Review the changes that Windows XP Service Pack 2 delivers and what they mean for you. Windows XP SP2 is designed to deliver a number of safety technologies in the Internet Connection Firewall, Web Browsing
experience, Email /IM and Application Memory Protection. Each of these areas has direct impact on developers and this session covers the major items and what you need to know. Learn how these changes will affect your various development tools.
http://msevents.microsoft.com/cui/eventdetail.aspx?EventID=1032257920&Culture=en-US


MSDN Webcast: Implementing Application Security Using the .NET Framework Part 1 - Level: 300
Wednesday, September 14, 2004 - 9:00 AM-10:00 AM Pacific Time
Rob Jackson, Developer Community Champion, Microsoft Corporation
This is part 1 of a 3-part series for experienced developers.  In this series, you will learn how to implement additional security features to secure applications that are built on the .NET Framework. You will learn
how security features are integrated into the .NET Framework. You will learn how to use both code access security and role-based security to limit vulnerabilities. You will also learn how to use the cryptographic
provider support in the .NET Framework to encrypt and sign data. Additionally, you will learn how to secure Web applications and Web services that are built by using ASP.NET. Finally, you will learn a few
tips for writing Security with the .NET Framework.  Parts 2 and 3 of the series will be presented on 9/21 and 9/28, respectively.
http://msevents.microsoft.com/cui/eventdetail.aspx?EventID=1032257965&Culture=en-US


MSDN Webcast: Writing Security - Threat Defense Part 1 - Level: 200
Friday, September 17, 2004 - 9:00 AM-10:00 AM Pacific Time
David Deatherage
This is part 1 of a 3-part series for experienced developers.  In this series, you will learn established best practices for applying security principles throughout the development process. You will learn effective
strategies for defending common security threats such as buffer overruns, cross-site scripting, SQL injection, and denial of service attacks.  Parts 2 and 3 of the series will be presented on 9/24 and
10/1, respectively.
http://msevents.microsoft.com/cui/eventdetail.aspx?EventID=1032258007&Culture=en-US


MSDN Webcast: Implementing Application Security Using the .NET Framework Part 2 - Level: 300
Tuesday, September 21, 2004 - 9:00 AM-10:00 AM Pacific Time
Ron Cundiff, MSDN Developer Community Champion, Microsoft Corporation
This is part 2 of a 3-part series for experienced developers.  In this series, you will learn how to implement additional security features to secure applications that are built on the .NET Framework. You will learn
how security features are integrated into the .NET Framework. You will learn how to use both code access security and role-based security to limit vulnerabilities. You will also learn how to use the cryptographic
provider support in the .NET Framework to encrypt and sign data. Additionally, you will learn how to secure Web applications and Web services that are built by using ASP.NET. Finally, you will learn a few
tips for writing Security with the .NET Framework.  Part 3 of the series will be presented on 9/28.
http://msevents.microsoft.com/cui/eventdetail.aspx?EventID=1032258017&Culture=en-US


MSDN Webcast: "Ask The Developer Security Experts" Series: Using WSE to Secure your Web Services with WS-Security - Level: 200
Thursday, September 23, 2004 - 11:00 AM-12:00 PM Pacific Time
Maarten Van De Bospoort, Consultant, Microsoft Corporation
This webcast series brings together some of the sharpest security-focused Microsoft developers to provide expert answers to your questions about securing your Web services. We will begin this webcast with a brief discussion of the advantages of using WS-Security over traditional wire level security on the protocol level, including an explanation of how WS-Security is built upon XML security and how the new Web Services Enhancements (WSE) make this easy to implement. After this overview, this session will continue with an extensive Q&A period where you can "Ask the Experts" your in-depth questions about securing your web services with WS-Security and WSE.  Do you have a question you want to submit to the experts before the webcast? Send your questions about securing Web services to our panel of experts ahead of time to
devxcast@microsoft.com.
http://msevents.microsoft.com/cui/eventdetail.aspx?EventID=1032258027&Culture=en-US


MSDN Webcast: Writing Security - Threat Defense Part 2 - Level: 200
Friday, September 24, 2004 - 9:00 AM-10:00 AM Pacific Time
Ron Cundiff, MSDN Developer Community Champion, Microsoft Corporation
This is part 2 of a 3-part series for experienced developers.  In this series, you will learn established best practices for applying security principles throughout the development process. You will learn effective
strategies for defending common security threats such as buffer overruns, cross-site scripting, SQL injection, and denial of service attacks.  Part 3 of the series will be presented on 10/1.
http://msevents.microsoft.com/cui/eventdetail.aspx?EventID=1032258029&Culture=en-US


MSDN Webcast: Implementing Application Security Using the .NET Framework Part 3 - Level: 300
Tuesday, September 28, 2004 - 9:00 AM-10:00 AM Pacific Time
Rob Jackson, Microsoft Corporation
This is part 3 of a 3-part series for experienced developers.  In this series, you will learn how to implement additional security features to secure applications that are built on the .NET Framework. You will learn
how security features are integrated into the .NET Framework. You will learn how to use both code access security and role-based security to limit vulnerabilities. You will also learn how to use the cryptographic
provider support in the .NET Framework to encrypt and sign data. Additionally, you will learn how to secure Web applications and Web services that are built by using ASP.NET. Finally, you will learn a few tips for writing Security with the .NET Framework.
http://msevents.microsoft.com/cui/eventdetail.aspx?EventID=1032258031&Culture=en-US

MSDN Webcast: Windows XP Server Pack 2 Change Walkthrough - Level: 300
Tuesday, September 28, 2004 - 11:00 AM-12:30 PM Pacific Time
Tony Goodhew, Product Manager, Microsoft
This session is a detailed walkthrough of the changes to Windows XP with Service Pack 2. It will cover the 4 major areas of change - Networking, Web Browsing, Email/IM and Hardware. In each of these sections the
change and its implication will be discussed.
http://msevents.microsoft.com/cui/eventdetail.aspx?EventID=1032258033&Culture=en-US

An extensive Collection of cryptographic utilities from Michel I. Gallant, a Microsoft Security MVP, that uses CryptoAPI, CAPICOM and more to do various tasks (thanks rido). Check it out at:

http://www.jensign.com/JavaScience/cryptoutils/index.html

Via Larkware News:

Per fes:

We've posted an updated Threat Modeling Tool at MSDN that addresses a few bugs. 

Thanks to BobB for his assistance.  Basically, this addresses several unhandled exceptions that resulted in the tool crashing at some rather inconvenient times.  (Okay, not that there are convenient times for a tool to crash.)

Some notes on the tool:

• We released it mostly because it is a useful way of organizing the data collected during threat modeling.  Since it is not formally supported externally, I (and a few other contributors) fix bugs and add features also informally.  So I'm hoping not to get a barrage of bug reports, but I will do my best to find time to address serious issues.
• Note that it works best (DFD-wise) if you have Visio 11 installed.  Visio 11 has a drawing control that you can embed in other applications (which is exactly what the TM tool does).  This is a much easier way of integrating DFDs in to the threat model.
• If you want to print from the tool, the best way to do it is to use the Preview button.  This applies the default XSLT (configurable in Tools->Config) to the threat model and displays it in an IE control.  You can right-click in this control and select print to print directly.
• The threat model document, if you haven't taken a look, is XML.  (Visio diagrams are stored in BASE64 blobs, though, and not in their XML format.)  So, you can customize the report format if you like playing with XSLTs.  The XSLTs that come with it are fairly basic, but show some ways of presenting the document.
• The sample document for the tool is in the tool's install directory, and is for “Fabrikam Phone 1.0.”  This is basically the same as one of the samples in the threat modeling book (http://www.microsoft.com/MSPress/books/6892.asp).  Note that the DFDs are in Visio, so you won't see them if you don't have it installed.  The sample is intended to show threat modeling concepts without being specific to any software type or technology.

The WSE 2.0 Documentation is now online.. Putting up the links for future reference.

1. Overview of WSE
2. Programming with WSE
3. Quickstart samples
4. What's New?
5. Installing WSE 2.0
6. System Requirements
7. Web Service Specifications supported by WSE
8. Managing Applications created with WSE
9. Troubleshooting WSE Applications
10. WSE Reference

Paul links to an an article by Addy Santo who ".. wrote a very interesting blurb about the dangers of XPath Injection attacks .... he also linked to a report which illustrates a Blind XPath Injection attack by Sanctum."

Maxim is back with another article on CAS. 

".....in my previous article on Code Access Security  I barely scratched the surface, so in this installment I want to continue my endeavor with CAS and point out 3 different approaches regarding its use; (1) Configure Policy, (2) Sandbox pattern and (3) Install into a Global Cache Assembly, to successfully execute an assembly in the partially trusted execution environment."

Needless to say, Check it out @
http://ipattern.com/simpleblog/PermLink.aspx?entryId=48 

Aaron Margosis (MCS Federal) has started a series of articles on the trials and tribulations of running as non-admin. Good read. Check them out:

• Not running as admin...
• Why you shouldn't run as admin...
• The easiest way to run as non-admin

Essentials of Security (Part 1) - Security and Defense - Level 200
June 14, 2004, 9:00AM-10:00AM Pacific Time (GMT-7, US & Canada)
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032253084&Culture=en-US

How does a security plan affect the commerce of the business it is supposed to protect? How can you be sure your security plan implements the right kind of security for each type of vulnerability? This webcast presents a defense-in-depth model that can help provide protection for each layer of an infrastructure. The discussion also includes strategies for security response, common attack scenarios, and best practices. During this webcast we will walk through two demonstrations: Internet Connection Firewall and Protecting IIS 5.0.

.NET Framework Security (Part 2) - Code Access and Role-Based Security - Level 300
June 14, 2004, 1:00PM-1:45PM Pacific Time (GMT-7, US & Canada)
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032253116&Culture=en-US

This webcast is the second of a 3-part series about the importance of Application Security and its best practices and guidelines. This part specifically addresses Authentication in the context of secure application development. After an overview of the costs of inadequate security and the benefits of developing secure applications, we concentrate on Authentication as part of a larger security solution, examining specific Authentication techniques and best practices in IIS. The webcast includes two demonstrations: Buffer Overruns and IIS Authentication Techniques.

Essentials of Application Security (Part 3) - Authorization - Level 300
June 16, 2004, 9:00AM-9:45AM Pacific Time (GMT-7, US & Canada)
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032253123&Culture=en-US

This webcast is the third of a 3-part series about the importance of Application Security and its best practices and guidelines. This part specifically addresses Authorization in the context of secure application development. After an overview of the costs of inadequate security and the benefits of developing secure applications, we concentrate on Authorization as part of a larger security solution, examining Trusted Subsystem Model Authorization techniques and best practices. The webcast includes two demonstrations: Buffer Overruns and Trusted Subsystem Model Authorization Techniques.

Writing Security - Threat Defense - Level 300
June 18, 2004, 9:00AM-10:30AM Pacific Time (GMT-7, US & Canada)
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032253126&Culture=en-US

In this session for experienced developers, you will build upon existing knowledge of secure coding best practices to learn about analyzing, mitigating and modeling threats. The session will discuss established threat modeling methodologies and tools and show how they can be applied with other best practices to minimize vulnerabilities and limit damage from attacks.

Windows XP Service Pack 2 - Security Information for Developers [1]

With Windows XP Service Pack 2 (SP2), Microsoft is introducing a set of security technologies that will help improve Windows XP-based computers' ability to withstand malicious attacks from viruses and worms. These technologies include:

• Network protection
• Memory protection
• Improved email security
• Safer browsing

Together, these security technologies will help make it more difficult to attack Windows XP, even if the latest patches or updates aren't applied. These security technologies together are particularly useful mitigation against worms and viruses. To developers these technologies will have impacts on the applications that they create and the tools they use. This page contains resources to assist developers in dealing with these impacts.

How to Make Your Web Site Work with Windows XP Service Pack 2 [2]

"Examine the new security features in Windows XP SP2 that affect Internet Explorer and ActiveX controls, file downloads, pop-up windows, and more."

Security improvements in the upcoming Windows XP Service Pack 2 [3]

"Rebecca Norlander, group manager .... in charge of the Windows XP Service Pack 2 effort invited us over to chat about the upcoming Service Pack.

...So, for this first interview (the rest will come over the next week or so) we wondered just what was the big deal about security in Service Pack 2"

[1] http://msdn.microsoft.com/security/productinfo/xpsp2/default.aspx
[2] http://msdn.microsoft.com/security/default.aspx?pull=/library/en-us/dnwxp/html/xpsp2websites.asp
[3] http://channel9.msdn.com/ShowPost.aspx?PostID=9104

Dana posted a list of resources that describe different aspects of Threat Modeling. Posting it for future reference.

• Web: OCTAVE
• Paper: Attack Modeling for Information Security and Survivability
• Paper: Collaborative Attack Modeling
• Paper: Bruce Schneier's Attack Trees
• Paper: Systematic Network Vulnerability Analysis based on Attack Graphs
• Book: Managing Information Security Risks: The OCTAVE Approach
• Book (Chapter 4): Writing Security
• Book: Threat Modeling
• Book (Chapter 3): Improving Web Application Security

The Securing Wireless LANs with PEAP and Passwords solution guide is designed to help small- and medium-sized organizations protect their wireless local access network (LANs). This prescriptive guidance will assist you in planning, deploying, testing, and managing a wireless LAN security infrastructure using Microsoft Windows XP, Windows Server 2003, and Pocket PC 2003. The guide is a companion to the earlier solution guide Securing Wireless LANs – a Certificate Services Solution. However, this updated guide uses passwords to authenticate users and computers to the LAN instead of digital certificates.

The solution uses industry standards such as 802.1X to ensure broad interoperability. Windows XP Wireless Auto Configuration and the Microsoft Active Directory directory service help to minimize the complexity of installing and managing the solution—many of the more complex operations are automated in scripts that are provided with the guide. You can also install the solution entirely on existing servers in your environment to keep costs low.

Download @
http://www.microsoft.com/downloads/details.aspx?familyid=60c5d0a1-9820-480e-aa38-63485eca8b9b&displaylang=en

The May/June issue of the IEEE Security & Privacy magazine is out and that means another issue of the "Building Security In" column, which is edited by Gary McGraw.  This month's column actually has been released free to the web, so go check it out...

Misuse and Abuse Cases: Getting Past the Positive
Paco Hope, Gary McGraw, and Annie I. Antón
http://www.computer.org/security/v2n3/bsi.htm

Software development is all about making software do something: when software vendors sell their products, they talk about what the particular products do to make customer's lives easier, such as improving business processes or something similarly positive. Following this trend, most systems for designing software also tend to describe positive features.

Ken on the SC-L list posted a pointer to an excellent article on the principle of least privilege. The article is by David Wheeler and can be found at:
http://www-106.ibm.com/developerworks/linux/library/l-sppriv.html?ca=dgr-lnxw04Privileges

The examples in the article are *nix/Linux focused but the concepts are relevant whatever OS you are running.

A section that struck a chord with me is:

"One of the most important ways to secure programs, in spite of these bugs, is to minimize privileges. A privilege is simply permission to do something that not everyone is allowed to do. On a UNIX-like system, having the privileges of the "root" user, of another user, or being a member of a group are some of the most common kinds of privileges. Some systems let you give privileges to read or write a specific file. But no matter what, to minimize privileges:

• Give a privilege to only the parts of the program needing it
• Grant only the specific privileges that part absolutely requires
• Limit the time those privileges are active or can be activated to the absolute minimum

These are really goals, not hard absolutes. Your infrastructure (such as your operating system or virtual machine) may not make this easy to do precisely, or the effort to do it precisely may be so complicated that you'll introduce more bugs trying to do it precisely. But the closer you get to these goals, the less likely it will be that bugs will cause a security problem. Even if a bug causes a security problem, the problems it causes are likely to be less severe. And if you can ensure that only a tiny part of the program has special privileges, you can spend a lot of extra time making sure that one part resists attacks."

"The NSA found that most operating systems' security mechanisms, including Windows and most UNIX and Linux systems, only implement "discretionary access control" (DAC) mechanisms. DAC mechanisms determine what a program can do based only on the identity of the user running the program and ownership of objects like files. The NSA considered this to be a serious problem, because by itself DAC is a poor defense against vulnerable or malicious programs. Instead, NSA has long wanted operating systems to also support "mandatory access control" (MAC) mechanisms.

MAC mechanisms make it possible for a system administrator to define a system-wide security policy, which could limit what programs can do based on other factors like the role of the user, the trustworthiness and expected use of the program, and the kind of data the program will use. A trivial example is that with MAC, users can't easily turn "Secret" into "Unclassified" data. However, MAC can actually do much more than that.

... So, NSA hit upon an idea that seems obvious in retrospect: take an open source operating system that's not a toy, and implement their security ideas to show that (1) it can work and (2) exactly how it can work (by revealing the source code for all). They picked the market-leading open source kernel (Linux) and implemented their ideas in it as "security-enhanced Linux" (SELinux)."

Threat modeling allows you to systematically identify and rate the threats that are most likely to affect your system. By identifying and rating threats based on a solid understanding of the architecture and implementation of your application, you can address threats with appropriate countermeasures in a logical order, starting with the threats that present the greatest risk.

The Threat Modeling tool was built by Frank Swiderski, a Microsoft Security Software Engineer, who is also the author of an upcoming book on Threat Modeling.

The Threat Modeling Tool allows users to create threat model documents for applications. It organizes relevant data points, such as entry points, assets, trust levels, data flow diagrams, threats, threat trees, and vulnerabilities into an easy-to-use tree-based view. The tool saves the document as XML, and will export to HTML and MHT using the included XSLTs, or a custom transform supplied by the user.

http://www.microsoft.com/downloads/details.aspx?FamilyID=62830f95-0e61-4f87-88a6-e7c663444ac1&displaylang=en

From Michael Howard:

The Microsoft Solutions for Security (MSS) team has released The Antivirus Defense-in-Depth Guide on the Web  @
http://go.microsoft.com/fwlink/?LinkId=28734

• A high-level overview of different malware types such as viruses and worms, their characteristics and replication techniques, and the payloads or actions malware use to attack computers.
• How to use defense-in-depth planning for both the clients and servers in your organization, including patch management, firewall protection, general security measures, and related tools to reduce the risk of infection.
• A comprehensive step-by-step methodology to quickly and effectively respond to malware outbreaks or infections and recover from them. The guidance in this area is based largely on Microsoft internal operations and the experience Microsoft has gained from assisting customers.
  

Casey Chesnut had implemented the functionality that is present in the desktop .NET System.Security.Cryptography namespace in the .NET compact framework as part of his http://www.brains-N-brawn.com/spCrypt article. What he did was wrap the unmanaged CryptoApi in managed code and then made sure that there was cross platform compatibility between his implementation and the full framework on the desktop.

Very Cool!

Now his code has been incorporated into the NETCF Smart Device Framework v1.1, which is a third party framework that " ..enriches and extends the .NET Compact Framework by providing a rich set of classes and controls not available in the .NET Compact Framework."

His code can be found under the OpenNETCF.Security.Cryptography Namespace. Check out the functionality provided @ http://www.opennetcf.org/library/

All relational databases are susceptible to SQL injection attacks. The following SQL Server Magazine article teaches you four important steps to protecting your Web applications from SQL injection attacks.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsqlmag04/html/InjectionProtection.asp

The above came across on the MSDN feed. I thought I would add a bit to it.

SQL Injection attacks occur when applications use input to construct dynamic SQL statements to access the database. One of the often quoted defenses against this type of attack is to use stored procedures.  That is a good start. Just remember that SQL injection attacks can also occur if your code uses sprocs that accept strings which contain unfiltered user input.  This attack gets exponentially worse if the application is using an over privileged account to connect to the database.

• Constrain the input by validating it for type, length, format and range. Remember, ALL INPUT IS EVIL, until proven otherwise!
• Use type safe SQL parameters. The parameter collection in SQL provides type checking and length validation. So if you use the Parameters collection, input is treated as a literal value and SQL does not treat it as executable code.  Another point is that the Parameters collection can be used to enforce type and length checks so that values outside of the range trigger exceptions. You can use the Parameters collection with both sprocs as well as dynamic SQL.
• Use filter routines that sanitize the code by adding escape characters to characters that have special meaning to SQL. An example would be adding an escape character to the single apostrophe character. Keep in mind that these type of filter routines can be bypassed by an attacker that uses ASCII hex characters. So they should be used as just another part of your defense in depth strategy.

What is the Security Guidance Kit?

The Security Guidance Kit is a collection of how-to information, software tools, and detailed prescriptive guidance within a small "viewer" application. The materials within the Kit are all designed to help you implement security measures in your environment. The topics covered include patch management, anti-virus measures, securing remote access, and blocking unsafe email attachments.

What is in the Security Guidance Kit?

The Security Guidance Kit contains documentation files along with a viewer application to allow you to navigate the documentation. It also contains free software tools from Microsoft, which you can optionally install or copy to other computers in your network.

Who is the Security Guidance Kit for?

The Security Guidance Kit is for the information technology implementer in any small, medium, or large organization. The Kit is not intended for use by the home pc user or by the application developer. Home users should continue to consult www.microsoft.com/protect for security guidance and information. Developers should consult the Security Guidance Center (www.microsoft.com/security/guidance) or MSDN (msdn.microsoft.com).

Download @
http://www.microsoft.com/downloads/details.aspx?familyid=c3260bd0-2ebb-4496-ad07-7e9d55d0ef1f

Per Brian Redmond:

"The Microsoft Solutions for Security team is proud to announce the release and availability of the Microsoft Identity and Access Management Series on the Web.  This is an excellent set of papers, scrips, and solution details related to Microsoft Identity Management technologies.  Each paper is based on field experience that deals with real-world problems, and the solutions offered are technically validated. Microsoft engineering teams, architects, consultants, support engineers, partners, and customers contributed to, reviewed, and approved each paper."

Part I – The Foundation for Identity and Access Management
Part II – Identity Life-Cycle Management
Part III – Access Management and Single Sign On

Check it out @
http://www.microsoft.com/technet/security/topics/identity/idmanage/default.mspx

MSDN Webcast: Writing Security - Threat Defense - Level 200
http://go.microsoft.com/fwlink/?LinkId=27559
May 20, 2004, 1:00 PM - 2:30 PM Pacific Time
Joel Semeniuk, VP of Software Development, ImagiNET Resources Corp.

In this session for experienced developers, you will build upon existing knowledge of secure coding best practices to learn about analyzing, mitigating and modeling threats. The session will discuss established threat modeling methodologies and tools and show how they can be applied with other best practices to minimize vulnerabilities and limit damage from attacks

Date:  Thursday, May 13, 2004
Time:  9:00AM-10:30AM Pacific Time (GMT-8, US & Canada)

Description:  In this webcast for experienced developers, you will learn established best practices for applying security principles throughout the development process. We will discuss common security threats faced by application developers, such as buffer overruns, cross-site scripting and denial of service attacks, and you will learn effective strategies to defend against those threats.

Register for the level 300 Webcast @
http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032250060&Culture=en-US

Maxim has a new article on Code Access Security, which is a topic that is near and dear to my heart. I have not had a chance to go through it fully, but his articles are always densely packed with good info.

So, go check it out @
http://ipattern.com/simpleblog/PermLink.aspx?entryId=43

SecurityFocus has an article that discusses common attacks and vulnerabilities in e-commerce shopping cart systems, with reference to SecurityFocus vulnerability reports where relevant.

Among the ones mentioned are:

• SQL Injection
• Price Manipulation
• Buffer Overflows
• Cross-Site Scripting
• Remote Command Execution
• Weak authentication and authorization

This guide is designed to provide you with essential information about how to harden your Microsoft® Exchange Server 2003 environment. In addition to practical, hands-on configuration recommendations, this guide includes strategies for combating spam, viruses, and other external threats to your Exchange 2003 messaging system. While most server administrators can benefit from reading this guide, it is designed to produce maximum benefits for administrators responsible for Exchange messaging, both at the mailbox and architect levels.

Dana points to 4 Security slide decks from the MSDN Security Seminars.. Check them out!

• Essentials of Application Security.ppt
• Implementing Application Security Using the .NET Framework.ppt
• Writing Security -- Best Practices.ppt
• Writing Security - Threat Defense.ppt

I presented today to CMAP (http://www.cmap-online.org) on writing Secure ASP.NET based applications.  I wanted to take a moment to thank everyone who came out and asked questions.  Hopefully I provided some take-away's that you can utilize every day.

As I mentioned, there are four reference books that I believe should be on EVERY .NET developer's bookshelf:

• Building Secure ASP.NET Applications
• Improving Web Application Security
• Enterprise Solution Patterns Using Microsoft .NET
• Improving .NET Application Performance and Scalability

Oh, did I mention that EVERY SINGLE ONE of the books above is put out by the Microsoft PAG and focuses on Current, Shipping Technology?

UPDATE: One of the topics that came up in conversation was how best to find out about local .NET events. For that I would highly suggest keeping tabs on Geoff Snowman's weblog.  Geoff is the Microsoft Developer Community Champion for the Mid-Atlantic, all around great guy, and the “Bringer of Gifts“ to local user groups

One of the basic tenets of Secure Coding is that "All input is Evil" until it has been validated to be otherwise.

Both in my DevDays presentation as well as in the "Improving Web Application Security" book, one of the Defense in Depth countermeasures when it comes to input validation is to set the correct character encoding in your web application.  The recommendation in both is to use the "ISO-8859-1" encoding. 

You do this because:

• "To successfully restrict what data is valid for your Web pages, it is important to limit the ways in which the input data can be represented. This prevents malicious users from using canonicalization and multi-byte escape sequences to trick your input validation routines."
• Using "safe" character encodings mitigates the possibility of using Unicode and multibyte encodings to disguise harmful characters. For example, an attacker might compromise URL authorizations incorporating the user name "Bob" by employing a legitimate account named "Bxb," where "x" is an oddball encoding of the letter "o"

"ISO-8859-1" is called the Latin-1 encoding and should work fine for any western European language including English. So safety in this case is enforced by limiting the character set to what is possible in a western European language. But try to display a language like Russian or Hebrew or Hindi and you'll get a bunch of un-displayable characters on the screen.

Of course you can use the UTF-8 character set, but then you will expand the ways in which input data can be represented. Which in turn leads to the possibility of canonicalization attacks.

So the take away from this is not necessarily to use "ISO-8859-1" at all times for all languages, as much as it is to limit the character encodings that are used in your web app such that you can realistically validate the info that comes in.  So for example, if you are running a Hebrew language website, an option may be to use an encoding that limits the input to only what is possible in that language.

BTW, to find out more about Unicode and Character Sets, I would point you to the following article by Joel Spolsky, which is probably the most lucid explanation of the topic that I've come across.

“The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)“
http://www.joelonsoftware.com/articles/Unicode.html

On a list serve that I am on, a question was posed by a developer who is working with a hosting company that runs their ASP.NET webservers under a partial trust scenario.  The developer uses File I/O and Reflection within the control code for some functions.  The hosting company's recommendation to the developer was to ask that all of the controls be marked with the AllowPartiallyTrustedCallersAttribute (APTCA) attribute. The questions that were posed had to do with Code Access Security (CAS) under .NET 1.0 and 1.1 as well exactly what AllowPartiallyTrustedCallersAttribute (APTCA) does.

It was an interesting question and may be something that pops up more and more in the future, so I thought I would share the answer that I gave. Comments and corrections are very welcome.

ASP.NET Web Applications under .NET 1.0 run with FullTrust privileges (i.e. They are no way constrained by CAS). The concept of the “trust“ element simply did NOT exist in 1.0.  Only .NET 1.1 will allow you to run ASP.NET Web Applications under a partial trust scenario.

The basic concept behind AllowPartiallyTrustedCallersAttribute (APTCA) is that:

• An assembly that has a strong name cannot, by default, be called by a partial trust assembly (i.e. an assembly that has not been granted Full Trust privileges). So by default, an ASP.NET Web Application that is running in a partial trust scenario cannot call a strongly named assembly.
• The only way a partial trust assembly/ASP.NET Web App running under partial trust can call an assembly with a strong name is if the strong named assembly is marked with the APTCA.

BTW, Web Applications built on .NET 1.0 always run with full trust because the types in System.Web 1.0 demand full trust callers.  In .NET 1.1, the System.Web, System.Web.Services, System.XML and some others are marked with APTCA, so they can actually be called from a partially trusted ASP.NET Application.

So one of the basic approaches to running an application under partial trust is:

• The ASP.NET Policy files grant full trust to any assembly that is located in the GAC.
• Put your code that accesses the privileged resource in a wrapper assembly that is then strongly named so that it can be installed in the GAC.
• The wrapper assembly, because it is in the GAC and has full trust can now call the privileged resource.
• Mark the wrapper assembly with APTCA
• Because the wrapper has been marked with APTCA, the ASP.NET application which is running under partial trust can actually call it.
• In short, Web App cannot call the privileged resource directly, but can call the wrapper which in turn can the privileged resource.

BTW, this info and a lot more are documented very thoroughly in Chapters 6-9 of "Improving Web Application Security: Threats and Countermeasures" from the Microsoft PAG

I'll be doing a reprise of my DevDays 2004 presentation on "Defenses and Countermeasures" for the Columbia, MD ASP.NET Professionals User Group on Tuesday, May 4, 2004. 

Here is the Official Blurb:

Date: 5/4/2004 6:30pm-9:00pm
Topic: Defenses and Countermeasures - Secure Your ASP.NET Applications from Hackers
Location: 8850 Stanford Blvd, Suite 4000, Columbia, MD 20723
Description: Secure Your ASP.NET Applications from Hackers

This session presents countermeasures to defend against threats. Topics include input validation; best practices when working with Microsoft SQL Server™, including the use of parameterized commands, stored procedures, accounts with limited privileges, Microsoft Windows; authentication versus SQL Server logins, and secure storage of connection strings; HTML-encoding of user input; vulnerabilities specific to ASP.NET forms authentication and forms authentication cookies; use of encrypted view state rather than hidden fields to maintain state between requests; storage of password hashes rather than passwords for added security; and more.

Please stop by and say hello if you are in the area. I won't be under the strict time constraints that I was under for the DevDays presentation, so my hope is that it will be a more interactive session. BTW, I've presented to these guys before, so I KNOW interaction won't be an issue

[Now Playing: Chale Chalo - Lagaan]

I normally do not make vulnerability and patch announcements here, as there are many other places that focus on just that area and do an excellent job of it.

But I recently got pinged about the fact that the exploit code that target the vulnerabilities that were patched by MS4-011 is out and a pointer to resources on how to protect yourself against it. This is a rather critical update that you need to be aware of if you are running a webserver that is SSL enabled. (Thanks, Scott). 

I also wanted to use this as an opportunity to point everyone to some resources that specialize in this particular area:

• Bugtraq
• NTBugtraq
• Microsoft TechNet Security Bulletins

Read/Subscribe and keep up.

Keith "Mr. Security" Brown kicks off a series of security articles on Longhorn. In this piece,[1]  Keith digs into the current plans for making Longhorn a much safer place for applications, only really giving administrator privileges to applications with a special need for them, regardless of the privileges of the user running the applications. This is a core piece of taking back our computers from the world's hackers and Keith lays out the basics nicely.
[Marquee de Sells: Chris's insight outlet]

This is my first and probably my last link to Longhorn until it is shipped as a beta, as I am interested in solving today's security and architecture issues..  But it is a glimpse at where Microsoft is going with Security in the future OS and it is written by Keith Brown.. So..

[1] http://msdn.microsoft.com/longhorn/default.aspx?pull=/library/en-us/dnlong/html/leastprivlh.asp

[Now Playing: O Rey Chori - Lagaan]

Great news. TechNet now has a Security Bulletin RSS feed.

This page on MSDN describes the MSDN feeds available and has links to a few of the different feed readers. As always, the latest Security Bulletin information can be found on the Microsoft Security Bulletin Search page.

[BufferOverrun]

Excellent news indeed. Subscribe @
http://www.microsoft.com/technet/security/bulletin/secrss.aspx

Too much good stuff in there to echo it here. Read it, Live it and Subscribe to it.

Read it @
http://www.microsoft.com/technet/security/secnews/newsletter.htm

Subscribe @
https://profile.microsoft.com/RegSysSubscriptionCnt/SubCntDefault.aspx?LCID=1033&SIC=1#NewsLetterSub

From the latest TechNet Flash:

This book [1] discusses how, when using S/MIME, encryption protects the contents of e-mail messages and digital signatures verify the identity of a purported sender of an e-mail message. The book also provides guidance on how to implement S/MIME with Microsoft Exchange Server 2003 and it directs you to other resources where those are necessary.

[1] http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/exmessec.mspx

Shawn Farkas has an article and code [1] on how to convert a password into a key for symmetric encryption. Good read.

One of the things he mentions is the possible vulnerability of the password choices that we make. This was covered in "Writing Security" and I had expanded on it in a previous blog entry as well. [2]

[1] http://blogs.msdn.com/shawnfa/archive/2004/04/14/113514.aspx 
[2] http://cyberforge.com/weblog/aniltj/articles/253.aspx

Gary McGraw, author of "Exploiting Software" posted the following recently to the SC-L mailing list:

The April 2004 issue of Information Security Magazine contains an article I wrote on the future of software.  It is adapted (pretty heavily) from Exploiting Software and identifies seven trends that will help you understand how software is evolving and how this evolution will impact security. You can view the article at http://infosecuritymag.techtarget.com/ss/0,295796,sid6_iss366_art684,00.html

At 12:00PM EST on Thursday of this week (4/15), I will conduct a live webcast titled "Best Practices for Software Security. According to the hype, l will offer "exclusive training tips for software developers, architects and testers as well as providing security strategies managers can use to make the smartest technology choices." Righto.  Anyway, you can pre-register for the webcast at http://www.searchsecurity.com/secure_code. If you miss the live event, you'll still be able to view the webcast on demand by visiting http://searchsecurity.techtarget.com/webcasts/0,295024,sid14,00.html

Microsoft has an extensive selection of on-demand Security webcasts that cover both platform and developer security. The topics range from "Implementing Security Patch Management" to "Writing Security - Threat Defense" Check it out @ http://www.microsoft.com/seminar/events/security/ondemand.mspx

You can also find the current list of live webcasts @ http://www.microsoft.com/seminar/events/security/upcoming.mspx

[Now Playing: Pretty Women - Kal Ho Naa Ho]

[1] http://www.dotnetthis.com/Articles/SNandSmartCards.htm

Microsoft Security E-Learning Our free Microsoft® Security E-Learning Clinics follow the same content outline as our Security Webcasts, but deliver that information via a learner-centered format that offers unique user benefits.

[BufferOverrun]

Brian points to the FREE Security E-Learning Clinics from Microsoft. This content is platform-centric rather than developer-centric.

Michael Howard - When does threat modeling come into play?
http://channel9.msdn.com/ShowPost.aspx?PostID=946
Michael Howard, program manager on Microsoft's security team, discusses how the Internet Explorer team used threat modeling to reduce the attack surface of its software.

Michael Howard - What if we had an unattackable system?
http://channel9.msdn.com/ShowPost.aspx?PostID=168
What if Michael Howard's job became obsolete? After all, he's the top security official at Microsoft. What would the bad guys do if the system itself became unattackable?

Michael Howard - What isn't being taught well enough in college?
http://channel9.msdn.com/ShowPost.aspx?PostID=169
Michael Howard, Microsoft's top security official, notes that many college graduates need to get remedial security training.   

[BufferOverrun]

Cool! Great information from the co-author of "Writing Security"!

[Now Playing: Meri Makhna Meri Soniye - Baghban]

For those who have been following the thread on how to set up SSH Tunneling, Beau has written up an excellent step by step article [1] on how to configure this on the Windows platform.  Highly recommended!

[1] http://bmonday.com/articles/653.aspx

Microsoft Knowledge Base Article - 823659 [1]

This article describes incompatibilities that may occur on client computers that are running Microsoft Windows 95, Microsoft Windows 98, Microsoft Windows NT 4.0, Microsoft Windows 2000, Microsoft Windows XP Professional, or Microsoft Windows Server 2003 when you modify specific security settings and user rights assignments in Windows NT 4.0 domains, in Windows 2000 domains, and in Windows Server 2003 domains. By configuring these settings and assignments in local policies and in group policies, you can help tighten the security on domain controllers and on member computers. The downside of increased security is the introduction of incompatibilities with clients, with services, and with programs.

This article contains examples of clients, of programs, and of operations that are affected by specific security settings or user rights assignments. However, the examples are not authoritative for all Microsoft operating systems, for all third-party operating systems, or for all program versions that are affected. Not all security settings and user rights assignments are included in this article.

This KB article came across one of the list serves that I am on. Very useful information written in a very accessible manner. Check it out.

[1] http://support.microsoft.com/default.aspx?scid=kb;en-us;823659

Gary fired off a message to SC-L pointing out that the National Cyber Security Partnership released a set of reports about the problems with software security today. Included was a report [1] that he co-authored with Mike and a few others on the process of producing secure software.

The principal recommendations in this report are in three categories:

1. Principal Short-term Recommendations
   • Adopt software development processes that can measurably reduce software specification, design, and implementation defects.
     
   • Producers should adopt practices for producing secure software
     
   • Determine the effectiveness of available practices in measurably reducing software security vulnerabilities, and adopt the ones that work.
     
   • The Department of Homeland Security should support USCERT, IT-ISAC, or other entities to work with software producers to determine the effectiveness of practices that reduce software security vulnerabilities.
2. Principal Mid-term Recommendations
   • Establish a security verification and validation program to evaluate candidate software processes and practices for effectiveness in producing secure software.
     
   • Industry and the DHS establish measurable annual security goals for the principal components of the US cyber infrastructure and track progress.
     
3. Principal Long-Term Recommendations
   • Certify those processes demonstrated to be effective for producing secure software.
     
   • Broaden the research into and the teaching of secure software processes and practices.