On one of the panels I moderated on APTs, Dave Merkel from Mandiant put it best. “You are compromised, get over it”. Others in the US Government have come to the same conclusion.

We spend far too much of our information security budget on increasingly ineffective mechanisms designed to prevent intrusions including network and host-based solutions, firewalls, IPS and antimalware systems. Does that mean we give up on these Not at all. What we need are new capabilities in other areas.

Assume you’ve been compromised. How would you know? We don’t spend nearly enough on systems that help us to better detect a compromise after it has occurred. We can’t keep pretending that we can keep the bad guys out.

Where are net new investments needed? Here’s just a few of the specific areas I discuss in my research.

• More monitoring. Lots more. At all layers of the stack – packet, flows, sessions, transactions, applications, user activities – all of it.
• More context-awareness. To separate meaningful anomalies out from a sea of monitored events will require more context – identity, application, content, location, time of day, reputation and so on.
• Big data and analytics brought to information security. Information security is becoming a big data problem and we need the systems, algorithms and new sets of security skills to derive insight from this.
• Higher levels of automation. To free up time to focus on the really important stuff, security professionals have got to get out of the day to day programming of security policy enforcement points. Program policies? Yes. Program quintuples? No.
• Cloud-based security policy enforcement. If we don’t own the device or the network (think 3G, 4G etc) then we can’t always rely on traditional network and host-based security controls for protection.
• Applications that are designed to be securely operated and used from inception. DevOpsSec must and will become a reality.
• A shift in thinking from Security Information and Event Management to delivering Security Intelligence

I believe information security infrastructure is at a critical inflection point. The status quo isn’t cutting it. Changes are needed.

Are the vendors up to it if it means we spend less for increasingly ineffective legacy solutions they are selling us? (The good news is that we’ll spend more in the other areas highlighted above if they’d make these types of advancements)

Are we up to it? Are we prepared to admit that we are currently on the losing side of this battle and make the types of process, technology and mindset changes above?

Both approaches have their pros and cons and, until recently, the market for these tools has evolved separately with different vendors and solutions. Even when a single vendor offers both DAST and SAST solutions, they have not historically been integrated.

In the latest research for clients – Gartner Magic Quadrant for Dynamic Application Security Testing – one of the criteria we looked at was whether or not the vendor’s solution provided Interactive Application Security Testing (IAST). Specifically, we are looking for ways that application security testing solutions combine dynamic and static techniques to improve the overall quality of the testing results. The information gathered by this instrumentation agent gives the hybrid solution an inside-out view that complements the outside-in view of a purely DAST solution — for example, identifying the specific line of code where a security vulnerability occurred, or providing detailed visibility into code coverage. There are a couple of ways that Dynamic and Static testing techniques can be integrated and made to be interactive:

1) The web application platform (IIS, Apache, or other) can be instrumented to observe the application as it is being tested dynamically.

2) The web application can be instrumented via injected code (.NET, Java, or other) so that it can be observed during dynamic testing

3) The output of a static code/binary analysis could be used to create and “tune” the dynamic test that is subsequently performed.

4) The results of observing an application under dynamic test or in use could be used to modify the dynamic test that is being performed in real time. In this way, the dynamic test can be made much more “intelligent” in how it tests an application. This is exactly the approach used by Quotium – a vendor we wrote up in 2011 as a Gartner Cool Vendor.

Multiple DAST solutions now provide IAST capabilities.  Some of the vendors evolving their offerings in this direction and offering IAST include Acunetix, HP, IBM, NTO, Parasoft and Quotium. However, most IAST solutions also requires that an agent be deployed on the application platform, which relegates the technique largely to QA and also requires that the vendor explicitly support the platform or language being instrumented (such as PHP, Java or .NET/ASP).

Look for IAST capabilities in your next evaluation of Dynamic Application Security Testing solutions.

Conventional wisdom believes the agile nature of the DevOps vision is fundamentally at odds with the historically static and cumbersome nature of information security. I disagree. I believe that security can support a unified vision of DevOpsSec, but to do this, information security must change in multiple ways including security infrastructure becoming more adaptive and programmable and making information security representation an integral part of DevOpsSec teams from the genesis of new applications and services.

I’ve just published a research note for clients DevOpsSec: Creating the Agile Triangle that makes the argument for DevOpsSec and outlines the major areas of change for information security to support a unified DevOpsSec vision. My colleague, Cameron Haight, from the IT Operations side of Gartner research joined me on the research note. He has pioneered much of the research on DevOps for Gartner and increasingly he is being asked how DevOps can be adopted without sacrificing security. Increasingly, I am being asked how to rationalize the agile nature of DevOps with the need for security testing. Together, we teamed up to deliver the first in a series of research notes on how to deliver DevOpsSec.

Development, operations and security are fundamentally intertwined. A well-designed, developed and managed system is the foundation of a secure system. DevOps must evolve to a new vision of DevOpsSec that balances the need for speed and agility of enterprise IT capabilities with the enterprise need to protect critical assets, applications and services.

In Gartner’s latest Magic Quadrant for Dynamic Application Security Testing (DAST) solutions for clients, one of the evaluation criteria we looked at was whether or not the vulnerability knowledge of the DAST solution could be exported and used by a web application firewall (WAF – for example Imperva, F5, Citrix, Barracuda, DenyAll, ModSecurity, Bee Ware, etc ) to protect the vulnerability application from attacks (note that this is conceptually identical to using network or host-based IPSs to shield from attacks on endpoints until patches can be applied)

Before I start a firestorm of comments, let me be clear: we believe the vulnerable application should be fixed if possible (just like vulnerable endpoints should ultimately be patched). WAFs should be viewed as a way to shield vulnerable web applications until they can be fixed/patched. However, this isn’t always possible in a timely manner. Sometimes the backlog of applications in development prevents a timely fix. Sometimes the organization doesn’t have the expertise to fix the application because the person that wrote it has left (or the development was outsourced/contracted). In other cases, there may be limited access to the source code. Regardless, what if we’ve got a vulnerable web application that we can’t fix in a timely manner?

That’s where DAST/WAF integration comes in. Most DAST solution providers will link directly to WAF providers to provide specific protection from a vulnerability. The DAST tool discovers the vulnerability and the WAF helps to shield from attacks on that vulnerability. Makes sense doesn’t it?

Here’s a couple of things to keep in mind:

• Look for explicit WAF support. Some DAST solution providers will talk about exporting vulnerability knowledge in XML and how this could be consumed by a WAF… leaving out the part where you have to perform the translation from a generic XML-based representation of the vulnerability into the native WAF rule syntax. Make sure both your WAF provider and DAST solution provider state explicit out of the box support for this integration.
• Even with explicit integration, don’t expect DAST vulnerability information to flow to a WAF without requiring human intervention and testing.
• Favor DAST solutions that allow you to quickly and easily retest/replay a specific vulnerability with the WAF in place to confirm that the protection is working as expected.
• To check for false positives, use testing scripts or recorded sessions to exercise the web application with the WAF rule in place. Favor WAF solutions that can place new rules in a “monitor only” mode for a period of time before being placed into blocking mode.

If you haven’t evaluated DAST solutions recently, it is time to take another look. The market continues to evolve rapidly. If a vulnerable web application can’t be fixed in a timely manner, don’t leave yourself exposed. Look for explicit, out of the box support for WAF rule generation in your next DAST or WAF solution evaluation.

DAST solutions have been around for years, so you’d might think the market is fairly static. Not at all. DAST solutions must and have evolved well beyond the security testing of back-end web applications. In order to dynamically test the next-generation of applications, new DAST capabilities are required and not all vendors support them equally.

Here are several areas where DAST solutions are evolving:

(1) Dynamic application security testing as a service. The market for dynamic testing as a service is growing and some of the DAST solutions we evaluated – Qualys, Veracode and WhiteHat – only offer their solution as a service. However, many organizations tell us they prefer to use a product and a service from the DAST vendor — for example, testing their more-sensitive applications on-premises using a DAST product, and testing their less-sensitive applications via DAST as a service, or testing deployed applications as a service, with testing of applications in the QA phase of the development process using on-premises DAST products.

(2) The ability to crawl and test Rich Internet Applications (RIA). A hallmark of Web 2.0 applications is the use of RIA, mostly in the form of JavaScript (The “J” in Ajax) and Ajax frameworks. In addition, many applications include large amounts of client-side logic in the form of Adobe Flash, Flex, and Microsoft’s Silverlight. The use of client-side RIA logic complicates how applications are crawled and how traditional DAST testing is performed, since the JavaScript and other types of code are rendered at the client, not at the server.

(3) HTML5  More recently, interest has shifted to the use of HTML5 for RIA. HTML5 isn’t a single standard and the multiple standards that collectively represent HTML5 are at different levels of maturity and adoption. Testing HTML5 and keeping up with the fluid standards is an emerging requirement for all DAST solutions.

(4) The ability to crawl and test applications that use other types of interfaces carried over web protocols. For example, many DAST solutions test Web services using protocols and formats, such as Simple Object Access Protocol (SOAP), representational state transfer (REST), Extensible Markup Language (XML) and JavaScript Object Notation (JSON).

(5) Static application testing capabilities (SAST). For comprehensive application security testing, applications should be able to be tested from the “inside out” using static analysis and from the “outside in” using dynamic analysis. Several vendors now offer organizations both DAST and SAST solutions.

(6) Interactive Security Testing. Building on #5, some of the testing providers enable interaction between their static and dynamic security testing techniques. One of the most common ways is to instrument the application while it is being tested dynamically. This provides more detailed information (such as identifying the line of code where a vulnerability occurs and assessing the code coverage of testing). While this may not be suitable for production applications, this approach is quite useful in QA testing in order to provide more meaningful results to developers.

(7) Comprehensive fuzz testing. Some DAST solutions are designed specifically to expand well beyond Web protocols to include non-Web protocols (for example, remote procedure calls, Server Message Block, Session Initiation Protocol [SIP] and so on) as well as data input malformation. This is especially critical for the dynamic security testing of applications used within embedded devices, such as storage appliances, telecommunications and networking equipment, directories, automated teller machines, medical devices and so on.

(8) Testing mobile and Cloud-based applications. Ideally mobile applications would be tested with SAST and DAST; however, pure DAST testing can add value. Beyond the use of RIA and HTML5 discussed previously, most Android and iOS applications (even when written as native applications) are Web-like in nature and communicate over Web or RESTful HTTP-based protocols. At a minimum, the exposed interfaces of the applications should be testable using DAST. Many of the mobile applications communicate with cloud-based applications on the back end, which must also be tested. In addition, many applications have specific code paths for supporting mobile devices. In order to test these properly, DAST solutions must emulate a number of mobile browsers.

These are just a few examples of how the market for DAST solutions is anything but static. The market is evolving rapidly and requires that successful solutions here continue to adapt as well. If you haven’t evaluated DAST solutions in a while, it’s time to take another look.

Security was front and center of attendee interests. We had a total of 23 security sessions throughout the 4 days. Like US Fall Symposium, I was fully booked with 1-1 sessions where attendees are able to meet and discuss their issues and questions with analysts.

The top issues of our European attendees differed from those at Gartner’s US Fall Symposim. Here’s what was top of mind in Europe:

1) Protecting information. I had a large number of discussions on how to move information security beyond just a “bottoms up” approach to information security. These organization felt they had a good handle on traditional firewalling, IPS and endpoint protection but hadn’t done much for information protection beyond encrypting laptops. In addition to encouraging them to think about information security protection as a process, we also discussed specific technical controls such as database activity monitoring, file activity monitoring and web application firewall/monitoring solutions.

2) Cloud security. Cloud isn’t one thing, security isn’t either, so these discussions varied. Most were focused on how to better secure access to cloud-based services at the Software-as-a -service level. There were some questions on IaaS, but only one on securing PaaS. In that case it was a leading -edge client moving their entire business as a service provider to Microsoft’s Azure platform and we discussed encryption options within Microsoft’s Azure.

3) Hosted Virtual Desktop  (or if you prefer, Virtual Desktop Infrastructure). In these conversations, the interest was driven primarily as a way to provide access to legacy Windows applications while maintaining control of the information. Several conversations were on the pros/cons of VDI as compared to traditional terminal services.There are strengths and weaknesses to each approach. In a separate roundtable on virtualization and security that I moderated, the preference of the attendees of the session was to use full VMs (VDI/HDV) rather than terminal services..

4) Application security This is really a form of #1 above, but focusing on securing the applications that handle the sensitive information. Most had adopted some amount of security testing, but were interested pushing testing further back into software development. There was a significant amount of interest in testing as a service offerings, many of which are quite inexpensive as compared to testing in house. In most of these cases, testing as a service wasn’t replacing what they were doing, just augmenting it.

Overall, the biggest difference I saw in the interests of European attendees from US attendees was the intense interest on specific ways and mechanisms to augment traditional “bottoms up” security mechanisms with a “tops downs” approach to protecting information. Both are needed.

That’s a good sign that information security organizations are understanding that in a world where IT increasingly doesn’t own or control much of the IT stack (end user device, network, server, OS, etc), our focus absolutely must shift up to various ways to protect the information.

In addition to three presentations, I had more than 30 fantastic one on ones with attendees over the four days.

What was hot? Many of the same issues I blog about. In order of priority, most attendee discussions were on:

1) Endpoint security, application control and whitelisting. Microsoft is causing significant disruption in this market with its new version of Forefront Endpoint Protection and its change in licensing policies.

2) Strategies for protection against Advanced threats (note that this overlaps with #1 a bit)

3) Security trends – what are the major trends we are seeing in information security and are they missing anything? What investments should we be thinking about for 2012?

4) Virtualization and security – trust/assurance of the hypervisor for separation of workloads of different trust levels as well as protecting VMs as they move offsite into Cloud-based providers.

Surprisingly, I only had one or two conversations on application security – specifically looking for best practices to push security testing further back in the SDLC.

In terms of “Cloud”, I think most organizations are moving beyond the ill-defined hype of “cloud security” and looking for specific advice and best practices for addressing specific cloud-related computing concerns. That’s a welcome step forward. Cloud is a computing style, not a location. It’s great to see people embrace this computing style and look to proactively build security in. Thursday afternoon’s presentation on securing private clouds had a good crowd for the final day. The biggest reaction was on the evolution of security to a set of software-based services delivered by programmable infrastructure. I think most IT security professionals have become so accustomed to their firewalls as a physical box, they have a difficult time imagining firewall services decoupled from the physical hardware underneath and shifting to security policies based on logical, not physical, attributes. Indeed, I believe the biggest challenges to the security of private clouds will be related to cultural and mindset change issues, not technical.

If you follow my thoughts from the conference on twitter (@nmacdona), you’ll see some of the feedback on my context-aware security presentation.Despite losing AC during the presentation (not good in Florida, even in October!), the crowd stuck it out with some hanging out in the doorways to watch the presentation and catch a breeze at the same time.

As I have discussed previously many times, all of information security is becoming context-aware and adaptive and this attribute will be a key characteristic of all next generation security offerings (IPS, FW, endpoint protection, IAM, DLP, and so on).

Overall, it was another great Symposium conference (my 15th with Gartner!). They just keep getting better. For those of you that didn’t make it, I’m attending Gartner’s upcoming US Data Center summit in December in Las Vegas and we can catch up there.

Addressing the first set of risks should start with policy – for example a non-disclosure agreement. Technical controls such as running developer sessions from a hosted virtual desktop session are also possible.

To address the second risk, an entire ecosystem of vendors offers solutions for the obfuscation of source code, tamper-resistance and tamper detection. These are covered in the latest Gartner hype cycle for application security which we just published for clients under a dot labeled “code obfuscation”

The latter is especially true with the shift to managed code and platforms such as Java and .NET which are much more easily reverse engineered.

We’ve updated our advice to clients using SecurID tokens in this First Take.

For current customers, RSA has published guidance that focuses on putting in place better protection of the systems that maintain the userid-to-token mappings and of the token seed values.

However, the risk here is higher than it first might appear. Two thoughts:

1) Protection strategies absolutely must include better protection of endpoints where reportedly the hackers were able to obtain the user-to-token mappings using a keystroke-logger or Zues-like Trojan. It is typically much easier to target end-users as a weak link rather then enterprise servers. This problem is compounded when contractors, home users and other non-enterprise managed assets use SecurID for strong authentication. On these systems, the enterprise may or may not have a security stack present (like an endpoint protection platform), the users may run as administrators and the patching discipline is unknown. End-users are the weakest link and end-users coming from unmanaged devices make this even weaker.

2) The attack on RSA was an organized attack, likely a state-sponsored Advanced Persistent Threat. The assumption that the hackers would obtain the seed key values from RSA and then go target enterprises may be far too optimistic. It is quite possible that the hackers obtained at least some of the user-to-token mappings before the attack on RSA occurred, knowing that once the breach at RSA became public, enterprises would place stronger controls on the systems that contained the user-to-token mappings. In other words, we might be trying to close the barn door after the horse is already out.

1) Barracuda’s breach

Major lesson: Test all of your web-enabled applications for vulnerabilities as a part of the ongoing application development and change process. This was the root cause of the breach.

Minor lesson: Web application firewalls work better when they are turned on in active mode. In addition, processes for application downtime should not leave applications exposed without active protection. Specifically, firewalls and web applications firewall protection should remain active at all times an application is accessible.

2) The attack on HBGary

Major lesson:  Test all of your web apps (in this case, a third party developed system for content management) for vulnerabilities. This was the root cause of the breach.

Minor lessons. Don’t use weak passwords and encryption algorithms. Don’t have the CEO function as the email administrator, at least not with the same weak password. The fact that the email was hosted on Google and there was a delay in getting the email deactivated was a factor, but there were many mistakes before this. Blaming the breach on Google is like blaming the sinking of the Titanic on the iceberg. Yeah it was a factor, but there were many bad decisions before this.

3) Amazon’s recent outage:

Major lesson: If you have a critical application, you need to plan for resiliency and this responsibility applies whether the application is kept on-premises on in the Cloud. Moving to cloud-based services hasn’t relieved you of the responsibility to plan for service unavailability.

4) The attack on EMC and subsequent loss of intellectual property

Major lesson: 100% prevention is a fallacy. Get over it. Even the best protected networks and systems will be hacked. Assume you have been breached and focus on detection. Despite hype that information security has been doing detection for years, detecting advanced intrusions is not “security 101” and is quite different than detecting attacks.

Note that the root cause of the first two were vulnerabilities in external-facing web applications. With dynamic application security testing tools and services mainstream and with prices coming down, there’s really no excuse for not proactively testing applications for security vulnerabilities during the development process.

Ideally, you’d test applications with both static and dynamic testing techniques, but at a minimum the use of DAST tools (or DAST as a service) is a straightforward way to get started.