1 Raindrop

Essential Factors for Successful Software Security Awareness Training

The current issue of IEEE Security & Privacy Journal has an article by John Steven and Ken van Wyk regarding how to get development and security staff to co-evolve towards better software security. They get right to the heart of the issue:

Developers fulfill the single most important role in software security: they build the software. Yet, it’s very likely that all but a handful of an organization’s developers are completely blind to how the software they’re building or maintaining today could be exploited tomorrow. A predictable consequence is that developers can’t build security into their applications and often push back heavily on any security analyst who takes a pot shot at their code.

This is part of the tension that exists between all operational and development groups, operations staff are typically suspicious of what the developers are throwing over the wall into production, in security we have the additional case that new vulnerabilities and exploits are discovered over time.

The authors discuss mitigating some of the core issues through training. As someone who does security training, I particularly like their suggestion that training should be seperated based on audience:

Executive training should teach the difference between software security and conventional network security approaches, particularly the pervasiveness of software security issues. It should also present and align business owners with the ESSF. Finally, it should establish short- and medium-term goals for software security capability, as well as set group owner expectations, means of measurement, risk management goals, and MBOs.

Management-level awareness training should teach development managers how to make schedule, cost, functionality, and risk trade-offs via a risk-management framework. It should also demonstrate how software security touchpoints affect development methodology. Finally, it should equip managers with knowledge collateral and questionnaires to validate the probability and impact of security findings and mitigation strategies.

Awareness training for development and security staff should seek to transform the way developers behave when they return to their development environments. It should further show how to execute software security touchpoints to build security in to the development life cycle. It’s also vital that it clearly shows how attackers exploit software and how to resist attack. Finally, it should provide analysts with a toolkit of specific attacks and principles with which to interrogate systems.

One of the big challenges in training is targeting the message correctly. Even in the technical software security training sessions I do, I typically see a mix of app arch, app dev, traditional security (i.e. network) staff, and operations. A large part of the challenge is making sure the software people understand enough about security and that the security folks understand enough about software.

As with many big challenges, software security is not going to be solved with one magic tool or technology, instead it is a mix of architecture, process, and organization. Training and awareness runs through all of these.

ModSecurity & Breach

The acquisition of Thinking Stone by Breach looks very promising. Knowing a few of the people involved this combination looks to have the potential to do some very interesting things in a very important part of the software security portfolio. Ivan Ristic's work in the Web Application Firewall space extends beyond his work with ModSecurity and Thinking Stone. Ivan was the lead in putting together the Web Application Firewall Evaluation Criteria. This  helps enterprises understand what they are potentially trying to do with a technology that many companies think is important but may not know exactly how to deploy.

Enterprises may view a WAF as a policy enforcement device, an audit logger, an input validator, a general purpose proxy, an availability architecture, an authentication system, and/or a mix of all of these as well as a host of other ideas. Obviously with ideas on how to deploy all over the map, the first step is to figure out what problem you are trying to solve. Ivan's work in WAFEC and other articles helps you to do that, and ModSecurity helps you deploy. It will be fun to see where this leads....

Laws of Identity and Web Services

Kim Cameron's seminal "Laws of Identity" defines ways that identity systems succeed and fail in the wild. Web Services systems provide an interoperability layer that bridges technologies, geographic, and organizational boundaries. They also carry identity data. Web Services standards open up interesting new ways of dealing with age old problems in distributed programming. One area that we explore in my SOA, Web Services, and XML security class is how the Laws of Identity inform the security architecture for Web Services. Identity is usually thought of in terms of user facing components, plus directories, and other controls like encryption, but there are just as many implications in the machine to machine type world that Web Services works with. Here is an excerpt:

Law 1: User Consent and Control
Description: Technical identity systems must only reveal information identifying a user with the user’s consent.
Implication: Web Services implement interoperable Message Exchange Patterns across multiple systems, the security architecture must deal with how identity data protected as it is ported across organizational and technical domains.

Law 2: Minimal Disclosure for a Constrained Use
Description: The solution that discloses the least amount of identifying information and best limits its use is the most stable long-term solution.
Implication: What options are available to consume identity information in a distributed system? What is the minimal dataset or set of references required to do this? What options require on line or off line replication?

Law 3: Justifiable Parties
Description: Digital identity systems must be designed so the disclosure of identifying information is limited to parties having a necessary and justifiable place in a given identity relationship
Implication: Web Services’ base use case is interoperability -presumes the presence of one or more intermediary systems (likely many more), how is the identity information made available to only those that have a justified purpose? WS-Security headers, SAML, and XACML all may be used to make sure the postal worker does not have direct access to the envelope's contents

Law 4: Directed Identity
Description: A universal identity system must support both “omni-directional” identifiers for use by public entities and “unidirectional” identifiers for use by private entities, thus facilitating discovery while preventing unnecessary release of correlation handles.
Implication: Web Services are frequently used in peer to peer and ESB scenarios where messages may traverse many directions in the system, since these are hard to predict the identity system referenced in the SOAP/XML message should reference tokens who direction is supported by policy

Law 5: Pluralism of Operators and Technologies
Description: A universal identity system must channel and enable the inter-working of multiple identity technologies run by multiple identity providers
Implication: This law acts as a direct design requirement for identity information in Web Services

Law 6: Human Integration
Description: The universal identity metasystem must define the human user to be a component of the distributed system integrated through unambiguous human-machine communication mechanisms offering protection against identity attacks
Implication: Not directly applicable since web services do not typically have GUIs; however composeable nature of SOAP and WS-* protocols means that advances in HCI security may be able to be supported these protocols in future

Law 7: Consistent Experience Across Contexts
Description: The unifying identity metasystem must guarantee its users a simple, consistent experience while enabling separation of contexts through multiple operators and technologies.
Implication: As systems are integrated across organizational and technical boundaries, there security tokens have to deal with conflicting standards and constraints. WS-Trust allows for client using Kerberos, SAML, X.509, and Username/password to exchange their tokens and connect to other remote services thus isolating the client (service requester) from these protocols

Software security training in MN

I am teaching SOA, Web Services, and XML Security training in Minnesota tomorrow. This is the second public version of this training class. The next public class will be at OWASP AppSec in Seattle next month.

Source Code Analysis

In case y'all missed it, the May/June IEEE Security & Privacy journal had an article on Source Code Analysis and security -- Putting the Tools to Work: How to Succeed with Source Code Analysis. The paper was a collaboration of three people with a lot of experience in the space - Pravir Chandra, Brian Chess, and John Steven.

"Get the tool, run the tool, fix the problems, and you're done, right? Wrong. Changing habits is hard..."

The authors point out three fundamental questions to consider when adopting a source code analysis tool: 1) Who runs the tool? 2) When is the tool run? and 3) What happens after the tool is run?

Answering these questions helps to shape the implementation and set the organization up for a successful deployment. Efforts where, say a security group, uses source code analysis tool to beat up developers for "bad code" are pretty much doomed from the start. The development and security groups need to partner for better results. I guess in an ideal world they'd both be incentivized to find/fix security issues in code.

I particularly liked one of the authors' suggestion for five keys to success "Go for the throat."

Rather than trying to stomp out every hint of a security problem on the first day, pick a handful of things that go wrong most often and go after them first. This approach often nets a big impact without overwhelming developers.

I think with some attention paid to implementation and effective partnership with security, development and architecture source code analysis may be one of the very few software security tools that may reside in quadrant 1 - high risk, high effectiveness.

We know software is high risk, but why highly effective, you might say? While it is true that source code analysis will not find architectural defects which may be the highest risk, there are plenty of egregious bugs that source code analysis tools do find. Since these tools may be baked into the automated build process they can be found early in the process and continuously monitored for quality. More good stuff to think about in this thread.

Ajax Security DOA 2.0

Brian Chess on how XSS is not overrated:

If anything, I think the attackers just haven't yet explored much of what's available to them. If a bad guy gets to run javascript on your box, he can make HTTP requests to anything on your intranet. Have a web console for your firewall? That XSS hole could allow him to bring the shields down.

It is a large hole alright, the thing is that there are many attack payload areas that have not yet been explored, Amit Klein touched on a few of them. Of course you have some of the same vectors in traditional, non-Ajax web apps that use Javascript, but web apps don't have to use Javascript, do they? Also, because it is an active application, Ajax makes XSS-enabled attacks able to act like a virus as Billy Hoffman pointed out at his Blackhat talk. Fast, distributed, iterative attacking. Great. At least the maps look nice.

My assumption is that the end game is that the users will eventually figure out to ask for some assurance around the payload and connectivity of ajax apps, but javascript and vbscript are not positioned to deliver these assurances today.

Update: looks like the Fortifiers have a new blog.

MetriCon 1.0 Digest

Dan Geer posted a digest of MetriCon 1.0. It is a great read, almost as good as attending. The slides are here. I blogged some additional thoughts here [1, 2, 3]. As the track chair for Software Security metrics, I had to follow Steve Bellovin saying that we do not have system security metrics that are usable and the security metrics are infeasible. My point was that "system" is way to all encompassing for where we are at right now and we need to begin by decomposing things into smaller pieces. A number of the presentation in the software security metrics did just that with attack pattern metrics at a channel, method, and data level, and pattern-based metrics, for example.

The second point is that the word "security" is particularly harmful in the metrics space, at least for where we are at right now as an industry. We need to be more granular and focus on measuring what we can today. Let's say that security means the union of confidentiality, integrity and availability. So if you are like most enterprises, then you can't do *all* of them today (much less join them all together in some meaningful way), but does that mean you shouldn't measure what you can? Well, every enterprise I see has at least some availability metrics. Granted confidentiality and integrity may be much harder, but at least there are some starting points, for example in authN, authZ, and identity and access management systems are rich sources for potential metrics.

The conference is 1.0 for a reason, it is where the industry is right now, but I never saw any software product that was perfect in version 1.0 and we shouldn't expect security metrics to be perfect right otu of the chute either.

WAF and XSG Risk and Effectiveness at 20,000 feet

I already blogged about one of my favorite presentations at Metricon in which Bryan Ware showed a model of combining risk and effectivness to identify areas to focus on.

Of course, the upper right quadrant of highly effective controls for high risk items make sense to fund, but the harder choices lie in quadrants 2 & 3. Would you rather really make a dent in solving a relatively lower risk problem or partially solve a higher risk item? Bryan's guidance was to incentivize high effectiveness (quadrant 3) over lower effectiveness (quadrant 2). This is a bold move, because it may be seen as ignoring higher risk items, however in the long run it may drive organizations to work towards higher effectiveness.

One area that organizations struggle with is - how to get started in application security? There are a lot of types of controls to consider like static analysis tools, sdlc, threat modeling, strong authentication, federated identity and so on. I have seen several enterprises conduct tradeoff analysis on Web App Firewalls (WAF) which offer some protection web applications from SQL injection and the like and XML Security Gateways (XSG) which protect XML messages and Web Services. So I used Bryan Ware's quadrant to analyze where it would make sense to focus efforts if an organization could choose only one. This is at the 20,000 foot level and both risk and effectiveness are subjective, so YTMMV (Your Threat Model May Vary).

If we assume that risk is higher in the apps that WAFs generally protect, Internet facing portals, than in what XSGs generally protect, say B2B apps on VPNs. Then the WAF goes in the higher risk quadrant than the XSG.

If we further assume that WAFs use a lot of educated guesswork due to performance constraints of signature and anomaly detection on unstructured data in web apps speed then their relative effectiveness is downgraded versus XSGs that may operate on asychronous systems on structured data, and, of course, XSGs can leverage interoperable security standards like WS-Security whereas WAFs rely on patter recognition. Then the relative effectiveness may prove higher for XSGs, again YTMMV. Assuming the above, the decision looks this way.

Depending architecture, threat model and other factors a XML Security Gateway may be a logical choice if you have to choose since it may prove to have higher effectiveness than a WAF. Of course, these need to be mapped to your particular organization, and there are a lot of other controls to consider besides these two, but in my view this model works really well as a decision support tool for hard security architecture choices.

Burton Group's Widening Moat

With its excellent analysts, Burton Group has long held the edge over its competition in key spaces like identity and security. Burton Group has done a lot to increase understanding and adoption of important technologies like Federation. Meanwhile, some other large analyst firms that go a mile wide and an inch deep, yet seem to have difficulty understanding fundamentals, particularly in app security, for example the difference between a WAF and a XML Security gateway. As a consultant, I am always glad when my clients are Burton Group subscribers because it means their people are likely to have a much more mature, in depth understanding of the technology space. Shops that randomly grab "solutions" out of quadrants/waves, without understanding how things hang together, frequently end up with bizarre architectures.

Burton Group's moat between its competition got wider last month when Bob Blakley joined. Now Burton Group has launched a group blog on Identity and Privacy Strategies. The second entry goes through the shots they called in 05 and the actual results. The prescience will not surprise their subscribers.

Why does all this matter? Well, IT is a fairly confusing metaverse to navigate, and it is always changing. Plus even people who have good skills in one area get thrown into new areas all the time, so having a solid end to end analysis that goes a mile deep, is a differentiator for any IT shop.

Update: ...and the moat gets wider: Pete Lindstrom joins Burton Group.

Outsourced CAPTCHA Circumvention

Slashdot (what would Lou Dobbs say?):

"Captchas are a nice idea to protect your blog or guestbook from being spammed by robots. But what good is this protection when you can hire "data entry specialists" to solve captchas for $0.60 per hour for 50 hours a week? Anyone here who can think up a solution that does not include drastically changing the global economy? How about captchas that require cultural background knowledge to solve?"

Who won the world series in 1973?