Admp

Digital Ant Swarms

By Adrian Lane

A friend of mine emailed yesterday, admonishing me for not writing about the Digital Ants concept discussed on Dailytech. I think it's because he wanted me to call B.S. on the story. It seems that some security researchers are trying to mimic the behavior of ants in computer defenses to thwart attackers. From the article:

Security researchers found inspiration in the common ant. Describes Wake Forest University Professor of Computer Science Errin Fulp, "In nature, we know that ants defend against threats very successfully. They can ramp up their defense rapidly, and then resume routine behavior quickly after an intruder has been stopped. We were trying to achieve that same framework in a computer system."

WFU created digital "ants" -- utilities that migrate from computer to computer over networks searching for threats. When one locates a threat, others congregate on it, using so-called "swarm intelligence". The approach allows human researchers to quickly identify and quarantine dangerous files by watching the activity of the ants.

This seems like nature's reaction du jour. Many have written about the use of 'helpful viruses' and viral technologies (cheese worm (PDF), anti-porn worm, wifi worm, etc.) to combat hostile computer worms and viruses. Helpful virus code finds exploits the same way a harmful virus would, but then patches the defect -- curing the system instead of reproducing. But the helpful viruses tend to become an attack vector of themselves, or 'fix' things in very unintended ways, compounding the problem.

Ants behave very differently than viruses. Real ants fill a dual role, both gathering food and defending the hive. Besides access controls, few security products can make this claim. Second, ants can detect threats. Software and systems are only marginally effective at this, even with different pieces operating (hopefully) as a coordinated unit. Finally, ants bite. They have the ability to defend themselves individually, as well as work effectively as a group. In either case they post a strong deterrent to attack, something seldom seen in the digital domain.

Conceptually I like the idea of being able to systemically respond to a threat, with different parts of the system reacting to different threats. On the threat detection side this makes sense as well, as many subtle attacks require information gathered from different parts of the system to be able to identify them. SEM/SIEM has slowly been advancing this science for some time now, and it is a core piece of the ADMP concept for web application security, where the detection and prevention is systemic. It is not the idea of a swam that makes it effective, but holistic detection in combination with multiple, different reactions by systems that can provide a meaningful response. So I am not saying ant swarming behavior applied to computer security is B.S., but "ramping up responses" is not the real problem -- detection and appropriate reactions are.

–Adrian Lane

How The Cloud Destroys Everything I Love (About Web App Security)

By Rich

On Tuesday, Chris Hoff joined me to guest host the Network Security Podcast and we got into a deep discussion on cloud security. And as you know, for the past couple of weeks we've been building our series on web application security. This, of course, led to all sorts of impure thoughts about where things are headed. I wouldn't say I'm ready to run around in tattered clothes screaming about the end of the Earth, but the company isn't called Securosis just because it has a nice ring to it.

If you think about it a certain way, cloud computing just destroys everything we talk about for web application security. And not just in one of those, "oh crap, here's one of those analysts spewing BS about something being dead" ways. Before jumping into the details, in this case I'm talking very specifically of cloud based computing infrastructure- e.g., Amazon EC2/S3. This is where we program our web applications to run on top of a cloud infrastructure, not dedicated resources in a colo or a "traditional" virtual server. I also sprinkle in cloud services- e.g., APIs we can hook into using any application, even if the app is located on our own server (e.g., Google APIs).

Stealing from our yet incomplete series on web app sec and our discussions of ADMP, here's what I mean:

• Secure development (somewhat) breaks: we're now developing on a platform we can't fully control- in a development environment we may not be able to isolate/lock down. While we should be able to do a good job with our own code, there is a high probability that the infrastructure under us can change unexpectedly. We can mitigate this risk more than some of the other ones I'll mention- first, through SLAs with our cloud infrastructure provider, second by adjusting our development process to account for the cloud. For example, make sure you develop on the cloud (and secure as best you can) rather than completely developing in a local virtual environment that you then shift to the cloud. This clearly comes with a different set of security risks (putting development code on the Internet) that also need to be, and can be, managed. Data de-identification becomes especially important.
• Static and dynamic analysis tools (mostly) break: We can still analyze our own source code, but once we interact with cloud based services beyond just using them as a host for a virtual machine, we lose some ability to analyze the code (anything we don't program ourselves). Thus we lose visibility into the inner workings of any third party/SaaS APIs (authentication, presentation, and so on), and they are likely to randomly change under our feet as the providing vendor continually develops them. We can still perform external dynamic testing, but depending on the nature of the cloud infrastructure we're using we can't necessarily monitor the application during runtime and instrument it the same way we can in our test environments. Sure, we can mitigate all of this to some degree, especially if the cloud infrastructure service providers give us the right hooks, but I don't hold out much hope this is at the top of their priorities. (Note for testing tools vendors- big opportunity here).
• Vulnerability assessment and penetration testing... mostly don't break: So maybe the cloud doesn't destroy everything I love. This is one reason I like VA and pen testing- they never go out of style. We still lose some ability to test/attack service APIs.
• Web application firewalls really break: We can't really put a box we control in front of the entire cloud, can we? Unless the WAF is built into the cloud, good luck getting it to work. Cloud vendors will have to offer this as a service, or we'll need to route traffic through our WAF before it hits the back end of the cloud, negating some of the reasons we switch to the cloud in the first place. We can mitigate some of this through either the traffic routing option, virtual WAFs built into our cloud deployment (we need new products for it), or cloud providers building WAF functionality into their infrastructure for us.
• Application and Database Activity Monitoring break: We can no longer use external monitoring devices or services, and have to integrate any monitoring into our cloud-based application. As with pretty much all of this list it's not an impossible problem, just one people will ignore. For example, I highly doubt most of the database activity monitoring techniques will work in the cloud- network monitoring, memory monitoring, or kernel extensions. Native audit might, but not all database management systems provide effective audit logs, and you still need a way to collect them as your app and db shoot around the cloud for resource optimization.

I could write more about each of these areas, but you get the point. When we run web applications on cloud based infrastructure, using cloud based software services, we break much of the nascent web application security models we're just starting to get our fingers around. The world isn't over*, but it sure just moved out from under our feet.

*This doesn't destroy the world, but it's quite possible that the Keanu Reeves version of The Day the Earth Stood Still will.

–Rich

After Action Report: What Fortinet Should Do With IPLocks

By Rich

When Fortinet acquired parts of IPLocks it was a bit of a bittersweet moment. When I started my career as an analyst, IPLocks was the first vendor client I worked with. I was tasked with covering database security and spent a fair bit of time walking clients through methods of improving their database monitoring; mostly for security in those days, since auditors hadn't yet invaded the data center. It was all really manual, using things like triggers and stored procedures since native auditing sucked on every platform. After a few months of this I was connected with IPLocks- a small database security vendor with a tool to do exactly what I was trying to figure out how to do manually. They'd been around for a few years, but since everyone at this time thought database security was "encryption", they bounced around the market more than usual.

Over the next few years I watched as the Database Activity Monitoring market started to take off, with more clients and more vendors jumping into the mix. IPLocks always struggled, but I felt it was more business issues than technology issues. Needless to say, they had some leadership issues at the top.

Since I hired Adrian, their CTO until the sale to Fortinet, it isn't appropriate for me to comment on the acquisition itself. Rather, I want to talk about what this means to the DAM/ADMP market.

First up is that according to this press release, Fortinet acquired the vulnerability assessment technology, and is only licensing the activity monitoring technology. As we dig in, this is an important distinction. IPLocks is one of only two companies (the other being Application Security Inc.) with a dedicated database VA product. (Imperva and Guardium have VA capabilities, but not stand-alone commercial products). From that release, it looks like Fortinet has a broad license to use the monitoring technology, but doesn't own that IP.

Was this a smart acquisition? Maybe- it all depends on what Fortinet wants to do.

On the surface, the Fortinet/IPLocks deal doesn't make sense. The products are not well aligned, address different business problems, and Fortinet only owns part of the IP, with a license for the rest. But this is also an opportunity for Fortinet to grow their market and align themselves for future security needs. Should they use this as the catalyst to develop an ADMP product line, they will get value out of the acquisition. But if they fail to advance either through further acquisitions or internal development (with significant resources, and assuming their monitoring license allows) they just wasted their money. Sorry guys, now you need a WAF.

In the short term they need to learn the new market they just jumped into and refine/align the product to sell to their existing base. A lot of this will be positioning, sales training, and learning a new buying cycle. Threat management sales folks are generally unsuccessful at selling to the combined buying center focused on database security.

Then they need to build a long term strategy and extend the product into the ADMP space. There is a fair bit in their existing gateway technology base they can leverage as they add additional capabilities, but this is not just another blade on the UTM.

It's all in their hands. This isn't a slam dunk, but is definitely a good opportunity if they handle it right.

–Rich

ADMP: A Policy Driven Example

By Adrian Lane

A friend of mine and I were working on a project recently to feed the results of a vulnerability assessment or discovery scans into a behavioral monitoring tool. He was working on a series of policies that would scan database tables for specific metadata signatures and content signatures that had a high probability of being personally identifiable information. The goal was to scan databases for content types, and send back a list of objects that looked important or had a high probability of being sensitive information.

I was working on a generalized policy format for the assessment. My goal was not only to include the text and report information on what the policy had found and possible remediation steps, but more importantly, a set of instructions that could be sent out as a result of the policy scan. Not for a workflow system, but rather instruction on how another security application should react if a policy scan found sensitive data.

As an example, let's say we wrote a query to scan databases for social security numbers. If we ran the policy and found a 9 digit field, verifying the contents were all numbers, or an 11 character field with numbers and dashes, we would characterize that as a high probability that we had discovered a social security number. And when you have a few sizable SAP installations around, with some 40K tables, casual checking does not cut it. As I have found a tendency for QA people to push production data into test servers, this has been a handy tool for basic security and detection of rogue data and database installations.

The part I was working on was the reactive portion. Rather than just generating the report/trouble ticket for someone in IT or Security to review the database column to determine if it was in fact sensitive information, I would automatically instruct the DAM tools to instantiate a policy that records all activity against that column. Obviously issues about previously scanned and accepted tables, "white lists", and such needed to be worked out. Still, the prototype was basically working, and I wanted to begin addressing a long-standing critisicm of DAM- that knowing what to monitor can take quite a bit of research and development, or a lot of money in professional services.

This is one of the reasons why I have a vision of ADMP being a top-down policy-driven aggregation of exsting security solutions. Where I am driving with this is that I should be able to manage a number of security applications through policies. Say I write a PCI-DSS policy regarding the security of credit card numbers. That generic policy would have specific components that are enforced at different locations within the organization. The policy could propagate a subset of instructions down to the assessment tool to check for the security settings around credit card information and access control settings. It could simultaneously seed the discovery application so that it is checking for credit card numbers in unregistered locations. It could simultaneously instruct DAM applications to automatically track the use of these database fields. I instruct the WAF to block anything that references triggering objects directly. And so on. The enforcement of the rules is performed by the application best suited for it, and at the location that is most suitable for responding.

I have hinted at this in the past, but never really discussed fully what I meant. The policy becomes the link. Use the business policy to wrap specific actions in a specific set of actionable rules for disparate applications. The policy represents the business driver, and it is mapped down to specific applications or components to enforce individual rules that constitute the policy. A simple policy management interface can now control and maintain corporate standards, and individual stakeholders can have a say in the implementation and realization of those policies "behind the scenes", if you will. Add or subtract security widgets as you wish, and add a rule onto the policy to direct said widgets how to behave.

My examples are solely around the interaction between the assessment/discovery phase, and the database activity monitoring software. However, much more is possible if you link WAF, web app assessment, DLP, DAM, and other products into the fold. Clearly there are a lot of people thinking along these lines, if not exactly this scenario, and many are reaching to the database to help secure it. We are seeing SIM/SEM products do more with databases, albeit usually with logs. The database vendors are moving into the security space as well and are beginning to leverage content inspection and multi-application support. We are seeing the DLP vendors do more with databases, as evidenced by the recent Symantec press release, which I think is a very cool addition to their functionality. The DLP providers tend to be truly content aware. We are even seeing the UTM vendors reach for the database, but the jury is still out on how well this will be leveraged. I don't think it is a stretch to say we will be seeing more and more of these services linked together. Who adopts a policy driven model will be interesting to see, but I have heard of a couple firms that approach the problem this way.

You can probably tell I like the policy angle as the glue for security applications. It does not require too much change to any given product. Mostly an API and some form of trust validation for the cooperating applications. I started to research the policy formats like OVAL, AVDL, and others to see if I could leverage them as a communication medium. There has been a lot of work done in this area by the assessment vendors, but while they were based on XML and probably inherently extensible, I did not see anything I was confident in, and was thinking I would have to define a different template to take advatage of this model.

Food for thought, anyway.

–Adrian Lane

ADMP and Assessment

By Adrian Lane

Application and Database Monitoring and Protection. ADMP for short.

In Rich's previous post, under "Enter ADMP", he discussed coordination of security applications to help address security issues. They may gather data in different ways, from different segments within the IT infrastructure, and cooperate with other applications based upon the information they have gathered or gleaned from analysis. What is being described is not shoving every service into an appliance for one stop shopping; that is decidedly not what we are getting at. Conceptually it is far closer to DLP 'suites' that offer endpoint and network security, with consolidated policy management.

Rich has been driving this discussion for some time, but the concept is not yet fully evolved. We are both advocates and see this as a natural evolution to application security products. Oddly, Rich and I very seldom discuss the details prior to posting, and this topic is no exception. I wanted to discuss a couple items I believe should be included under the ADMP umbrella, namely Assessment and Discovery. Assessment and Discovery can automatically seed monitoring products with what to monitor, and cooperate with their policy set.

Thus far the focus through a majority of our posts has been monitoring and protection, as in active protection, for ADMP. It reflects a primary area of interest for us as well as what we perceive as the core value for customers. The cooperation between monitored points within the infrastructure, both for collected data and the resulting data analysis, represents a step forward and can increase the effectiveness of each monitoring point. Vendors such as Imperva are taking steps into this type of strategy, specifically for tracking how a user's web activity maps to the back end infrastructure. I imagine they will come up with more creative uses for this deployment topology in the future.

Here I am driving at the cooperation between preventative (assessment and discovery in this context) and detective (monitoring) controls. Or more precisely, how monitoring and various types of assessment and discovery can cooperate to make the entire offering more efficient and effective. And when I talk about assessment, I am not talking about a network port scan to guess what applications and versions are running- but rather active interrogation and/or inspection of the application. And for discovery, not just the location of servers and applications, but a more thorough investigation of content, configuration and functions.

Over the last four years I have advocated discovery, assessment and then monitoring, in that order. Discover what assets I have, assess what my known weaknesses are, and then fix what I can. I would then turn on monitoring for generic threats I that concern me, but also tune my monitoring polices to accommodate weaknesses in my configuration. My assumption is that there will always be vulnerabilities which monitoring will assist with controlling. But with application platforms- particularly databases- most firms are not and cannot be fully compliant with best practices and still offer the business processing functions the database is intended for. Typically weaknesses in security that are going to remain part of the daily operation of the applications and databases require some specific setting or module that is just not that secure.

I know that there are some who disagree with this; Bruce Schneier has advocated for a long time that "Monitor First" is the correct approach. My feeling is that IT is a little different, and (adapting his analogy) I may not know where all of the valuables are stored, and I may not know what the type of alarm is needed to protect the safe. I can discover a lot from monitoring, and it allows me to witness both behavior and method during an attack, and use that to my advantage in the future. Assessment can provide tremendous value in terms of knowing what and how to protect, and it can do so prior to an attack. Most assessment and discovery tools are run periodically; while they may not be continuous, nor designed to find threats in real time, they are still not a "set and forget" part of security. They are best run periodically to account for the fluid nature of IT systems.

I would add assessment of web applications, databases, and traditional enterprise application into this equation. Some of the web application assessment vendors have announced their ability to cooperate with WAF solutions, as WhiteHat Security has done with F5. Augmenting monitoring/WAF is a very good idea IMO, both in terms of coping with the limitations inherent to assessment of live web applications without causing disaster, but also the impossibility of getting complete coverage of all possible generated content. Being able to shield known limitations of the application, due either to design or patching delay, is a good example of the value here.

In the same way, many back-end application platforms provide functionality that is relied upon for business processing that is less than secure. These might be things like database links or insecure network 'listener' configurations, which cannot be immediately resolved, either due to business continuity or timing constraints. An assessment platform (or even a policy management tool, but more on that later) or a rummage through database tables looking for personaly identifiable information, which is then fed to a database monitoring solution, can help deal with such difficult situations. Interrogation of the database reveals the weakness or sensitive information, and the result set is fed to the monitoring tool to check for inappropriate use of the feature or access to the data. I have covered many of these business drivers in a previous post on Database Vulnerability Assessment. And it is very much for these drivers like PCI that I believe the coupling of assessment with monitoring and auditing is so powerful- the applications help compensate for each another, enabling each to do what it is best at, passing off coverage of areas where they are less effective.

Next up, I want to talk about policy formats, the ability to construct policies that apply to multiple platforms, and how to include result handling.

–Adrian Lane

What’s My Motivation?

By Adrian Lane

'Or more appropriately, "Why are we talking about ADMP?" In his first post on the future of application and database security, Rich talked about Forces and Assumptions heading us down an evolutionary path towards ADMP. I want to offer a slightly different take on my motivation, or belief, in this strategy.

One of the beautiful things about mode application development is our ability to cobble together small, simple pieces of code into a larger whole in order to accomplish some task. Not only do I get to leverage existing code, but I get to bundle it together in such a way that I alter the behavior depending upon my needs. With simple additions, extensions and interfaces, I can make a body of code behave very differently depending upon how I organize and deploy the pieces. Further, I can bundle different application platforms together in a seamless manner to offer extraordinary services without a great deal of re-engineering.

A loose confederation of applications cooperating together to solve business problems is the typical implementation strategy today, and I think that the security challenge needs to account for the model rather than the specific components within the model. Today, we secure components. We need to be able to 'link up' security in the same way that we do the application platforms (I would normally go off on an Information Centric Security rant here, but that is pure evangelism, and a topic for another day).

I have spent the last four years with a security vendor that provided assessment, monitoring, and auditing of databases and databases specifically. Do enough research into security problems, customer needs, and general market trends; and you start to understand the limitations of securing just a single application in the chain of events. For example, I found that database security issues detected as part of an assessment scan may have specific relevance to the effectiveness of database monitoring. I believe Web Application security providers witness the same phenomenon with SQL Injection as they may lack some context for the attack, or at least the more subtle subversions of the system or exploitation of logic flaws in the database or database application. A specific configuration might be necessary for business continuity and processing, but could open an acknowledged security weakness that I would like to address with another tool, such as database monitoring.

That said, where I am going with this line of thought is not just the need for detective and preventative controls on a single application like a web server or database server, but rather the Inter-application benefit of a more unified security model. There were many cases where I wanted to share some aspect of the database setup with the application or access control system that could make for a more compelling security offering (or visa-versa, for that matter).

It is hard to understand context when looking at security from a single point outside an application, or from the perspective of a single application component. I have said many times that the information we have at any single processing node is limited. Yes, my bias towards application level data collection vs. network level data collection is well documented, but I am advocating collection of data from multiple sources. A combination of monitoring of multiple information sources, coupled with a broad security and compliance policy set, would be very advantageous. I do not believe this is simply a case of (monitoring) more is better, but of solving specific problems where it is most efficient to do so. There are certain attacks that are easier to address at the web application level, and others best dealt with in the database, while others should be intercepted at the network level. But the sharing of policies, policy enforcement, and suspect behaviors, can be both more effective and more efficient.

Application and Database Monitoring and Protection is a concept that I have been considering/researching/working towards for several years now. With my previous employer, this was a direction I wanted to take the product line, as well as some of the partner relationships to make this happen across multiple security products. When Rich branded the concept with the "ADMP" moniker it just clicked with me for the reasons stated above, and I am glad he posted more on the subject last week. But I wanted to put a little more focus on the motivation for what he is describing and why it is important. This is one of the topics we will both be writing about more often in the weeks and months ahead.

–Adrian Lane

The Future Of Application And Database Security: Part 1, Setting The Stage

By Rich

I've been spending the past few weeks wandering around the country for various shows, speaking to some of the best and brightest in the world of application and database security. Heck, I even hired one of them. During some of my presentations I laid out my vision for where I believe application (especially web application) and database security are headed. I've hinted at it here on the blog, discussing the concepts of ADMP, the information-centric security lifecycle, and DAM, but it's long past time I detailed the big picture.

I'm not going to mess around and write these posts so they are accessible to the non-geeks out there. If you don't know what secure SDLC, DAM, SSL-VPN, WAF, and connection pooling mean, this isn't the series for you. That's not an insult, it's just that this would drag out to 20+ pages if I didn't assume a technical audience.

Will all of this play out exactly as I describe? No way in hell. If everything I predict is 100% correct I'm just predicting common knowledge. I'm shooting for a base level of 80% accuracy, with hopes I'm closer to 90%. But rather than issuing some proclamation from the mount, I'll detail why I think things are going where they are. You can make your own decisions as to my assumptions and the accuracy of the predictions that stem from them.

Also, apologies to Dre's friends and family. I know this will make his head explode, but that's a cost I'm willing to pay. Special thanks to Chris Hoff and the work we've been doing on disruptive innovation, since that model drives most of what I'm about to describe. Finally, this is just my personal opinion as to where things will go. Adrian is also doing some research on the concept of ADMP, and may not agree with everything I say. Yes, we're both Securosis, but when you're predicting uncertain futures no one can speak with absolute authority. (And, as Hoff says, no one can tell you you're wrong today).

Forces and Assumptions

Based on the work I've been doing with Hoff, I've started to model future predictions by analyzing current trends and disruptive innovations. Those innovations that force change, rather than ones that merely nudge us to steer slightly around some new curves. In the security world, these forces (disruptions) come from three angles- business innovation, threat innovation, and efficiency innovation. The businesses we support are innovating for competitive advantage, as are the bad guys. For both of them, it's all about increasing the top line. The last category is more internal- efficiency innovation to increase the bottom line. Here's how I see the forces we're dealing with today, in no particular order:

1. Web browsers are inherently insecure. The very model of the world wide web is to pull different bits from different places, and render them all in a single view through the browser. Images from over here, text from over here, and, using iframes, entire sites from yet someplace else. It's a powerful tool, and I'm not criticizing this model; it just is what it is. From a security standpoint, this makes our life more than a little difficult. Even with a strictly enforced same origin policy, it's impossible to completely prevent cross-site issues, especially when people keep multiple sessions to multiple sites open all at the same time. That's why we have XSS, CSRF, and related attacks. We are trying to build a trust model where one end can never be fully trusted.
2. We have a massive repository of insecure code that grows daily. I'm not placing the blame on bad programmers; many of the current vulnerabilities weren't well understood when much of this code was written. Even today, some of these issues are complex and not always easy to remediate. We are also discovering new vulnerability classes on a regular basis, requiring review and remediation on any existing code. We're talking millions of applications, never mind many millions of lines of code. Even the coding frameworks and tools themselves have vulnerabilities, as we just saw with the latest Ruby issues.
3. The volume of sensitive data that's accessible online grows daily. The Internet and web applications are powerful business tools. It only makes sense that we connect more of our business operations online, and thus more of our sensitive data and business operations are Internet accessible.
4. The bad guys know technology. Just as it took time for us to learn and adopt new technologies, the bad guys had to get up to speed. That window is closed, and we have knowledgeable attackers.
5. The bad guys have an economic infrastructure. Not only can they steal things, but they have a market to convert the bits to bucks. Pure economics give them viable business models that depend on generating losses for us.
6. Bad guys attack us to steal or assets (information) or hijack them to use against others (e.g., to launch a big XSS attack). They also sometimes attack us just to destroy our assets, but not often (less economic incentive, even for DoS blackmail).
7. Current security tools are not oriented to the right attack vectors. Even WAFs offer limited effectiveness since they are more tied to our network security models than our data/information-centric models.
8. We do not have the resources to clean up all existing code, and we can't guarantee future code, even using a secure SDLC, won't be vulnerable. This is probably my most contentious assumption, but most of the clients I work with just don't have the resources to completely clean what they do have, and even the best programmers will still make mistakes that slip through to production.
9. Code scanning tools and vulnerability analysis tools can't catch everything, and can't eliminate all false positives. They'll never catch logic flaws, and even if we had a perfect tool, the second a new vulnerability appeared we'd have to go back and fix everything we'd built up to that point.
10. We're relying on more and more code and web services developed by others. From machine-generated web applications, to frameworks and off-the-shelf web apps we customize, to mashups where we directly pass content generated by someone else to our users.
11. "Web applications" is a misnomer- we mean the entire stack: web servers, web application servers, the databases behind them, and all the various interconnected n tiers. Many of these are internally accessible, creating an additional vector for attack.

To rephrase these a bit:

1. Bad guys are focused on our web applications, and are intelligent and motivated.
2. We have a lot of insecure code, keep generating more, and can't rely on secure development to fix it all.
3. WAFs and code scanning help, but aren't enough.
4. We need to protect a big, complex stack including content and services outside our control.

Following these forces, I'm drawing some assumptions about what any solution needs to look like:

1. We need to include browser elements, but can't trust the browser.
2. We need to monitor and enforce at the transaction level, both for audibility and for logic flaws and other security issues.
3. Such monitoring and enforcement needs to run from the browser to the database.
4. Any solution needs to understand the application and database, not just layer over it.
5. We need to filter anything we pass on to the user.
6. We need to focus on protecting the information.

I'm not totally thrilled with how I've laid this out, but I think it's reasonably understandable. Tomorrow I'll walk through how I think the technology will develop, and where today's tools fit in. I suspect Adrian will start chiming in, once he gets off the road, with his own interpretations.

–Rich