In a recent post on ZDNet, Larry Seltzer makes the case that browser security has peaked, and argues that “that’s probably a good thing”. Browser security may well have peaked, but it’s definitely not a good thing. Adding new features can easily make it decrease, and it isn’t great to start with.
IE11 adds support for the oft vilified WebGL standard (security white-paper), which enables client gpu-assisted rendering of complex graphical elements, including games. Since graphical languages are basically programming languages, and require the client device to hand the graphics driver to the browser with no understanding of the “program”, you can see why Microsoft for a long time pushed back on the inclusion of WebGL in the browser. (As an aside, client-side graphical command remoting is a hot issue in the desktop virtualization arena, where Citrix and Microsoft vie to outdo each other in terms of the fidelity of hosted Windows apps/desktops. Fortunately in that arena there is an explicit trust relationship between the client and the server hosting the desktop/app.) To help protect against possible WebGL based attacks, Microsoft has added client-side sandboxing / sanity checking to its graphics drivers to mitigate the risks of this new interface. However, this is an area of great complexity, and the new interface, though presumably carefully tested by Microsoft, has yet to be fuzzed by malware writers. So I put this very decidedly in the category of “let’s wait and see”.
Seltzer’s argument is deceptively simple: In a nutshell, the vendors aren’t adding many new security features, and browser-based attacks are harder, so presumably we’re all OK? This is wrong for several reasons:
Browser vendors may well have done what they can to sandbox the browser, but that does not mean that the browser is a secure gateway to the scary web, or that users are safe. There are limits to the protection that software can offer, and they continue to add new features with large code bases:
- An attacker can bypass the browser by attacking the kernel directly, or escaping the sandbox from user-space via a vulnerable Windows service.
- The code surface of the browser and its plug-ins is huge. New code means new vulnerabilities, which will be found and exploited.
- In the specific case of IE, Flash is incorporated into the browser so that it can auto-update (making it more secure), but this exposes the browser to a massive third party code base and its latent vulnerabilities Here are some recent exploits for IE10 on Win8, which on their own utterly contradict the notion of Browser security completeness. Today the easiest (admittedly reliable) way to infiltrate into the enterprise is via Web browsers and emails. This is not just because of the ubiquity of Internet Explorer but also because of the large attack surface of browsers in general and the fact that all users need to run untrusted code every time they surf the web.
- To make things worse, scripting engines of browsers provide ample scope for exploit obfuscation and evasion to bypass traditional signature/detection based defenses, making it the best target ROI for malware deployment.
- Every browser version is touted to be ‘better’ and ‘more secure’ than the previous one – which in some cases is true. Microsoft undoubtedly is doing a great job in plugging off older ‘traditional’ exploitation vectors. However, we should not forget that it’s a war of adding functionality, backward compatibility and security in a vastly complicated code base. They are climbing their own ‘mount never-rest’. Here, for example are some stats for IE9 and IE10.
- Java, Java, Java. Enterprises require legacy JRE support on the client because server-side applications impose version compatibility requirements (and you gamers also need Java to support Minecraft). Even the latest Java releases have had issues. Malware that breaks the JVM bypasses the browser sandbox directly.
- The user can still trivially download, save and execute malware or poisoned content using the browser, leaving protection up to your AV suite (good luck!), the user, or IE protected-mode and UAC – otherwise known as “click to edit/trust/install/run…” and “do not show me this warning again..”
- The clipboard can be used to transfer attacks from unsafe content in the browser to other applications.
The browser vendors are doing good work – perhaps as much as one could ask for. But you’re still vulnerable – as Seltzer acknowledges: “Obviously users still get hacked through browsers, but that’s a different sort of problem, usually involving social engineering and no real software error. It’s just another way of saying we’ve done what we can securing the browser; now we have to secure the user and that may be impossible.” But this is not a good thing.
It is impossible to train the idiot user out of me. Worse, my browser cannot secure me and the OS is vulnerable. There is only one way to radically increase system security given the inevitability of an attack: massively decrease the attack surface of the end point using micro-virtualization. This is the only way to protect the end point from the idiot in me.
Last week’s shocking admission by Adobe that customer data, including encrypted credit card information for almost 3 million customer accounts, and source code for Adobe Acrobat, which is used to create electronic documents in the PDF format, as well as ColdFusion and ColdFusion Builder – ought to utterly terrify you. The breach itself, discovered as a result of painstaking sleuthing by Brian Krebs and and Alex Holden (ie: Adobe was unaware of the compromise) turns the spotlight on a security vendor that we have to trust absolutely, every time we open a document.
Beyond the theft of confidential customer data (which is not the subject of this post), the theft of Adobe’s source code is of grave concern: An attacker can now readily examine the Adobe sandbox for vulnerabilities, and write exploit code to specifically target them. Since these by definition would be vulnerabilities that Adobe itself has not spotted, there is nothing that Adobe can do beforehand to prepare for such attacks. Moreover, the massive installed-base of Adobe products means that even if new versions are quickly delivered to patch new exploits, millions of devices will still be vulnerable.
Interestingly, the problem facing Adobe is no different than the (ongoing) problem Oracle faces with Java. And while the Java bashers quickly picked up on the Apple led call for users to “disable client Java”, it really isn’t so easy this time around. Are you ready to ban PDFs from your organization? We need to remind ourselves, yet again, that the massive attack surface of all software sandbox technologies represents a another failed approach to securing the endpoint. Failure of the sandbox is catastrophic for system security.
So, how bad is it? We know that Adobe has adopted the Chrome sandbox, whose source code is already available in open source, developed and tested by a robust community, and further bolstered by Google’s bug-bounty program. In addition, our research has shown that Chrome is the best software sandbox available. While the Adobe implementation leaves the system open to attack in several more ways than Google Chrome, it is my view (contrary to popular hand-wringing) that the availability to attackers of the Adobe sandbox source does not present the industry with an immediate crisis or any radically increased threat. That said, it will be critical for Adobe and the Chrome team to rapidly respond in the event of evidence of attacks in the wild. The key lesson is this: security critical code should be available in open source, and it should be exposed to merciless, continuous testing and review by a community comprising diverse – even competitive – economic interests. It’s a better way to develop better code.
But let’s be generous to Google and Adobe. Let’s assume the sandbox is perfect. What’s scary is that software vendors pretend that sandboxing can help. Even a bug-free sandbox cannot protect a vulnerable endpoint. We have repeatedly shown that malicious code can readily bypass any Windows sandbox using well-known attacks that are impossible for sandbox vendors to protect against. The attacker has more determination and resources than any IT team. So we need a back-stop technology that is vastly more secure than any software containment technique.
Hardware-enforced security will be the next major leap forward in our ability to protect endpoints from attack. We see early signs of this in modern mobile devices, including Windows 8 tablets, which require a TPM (for an attested boot) in order to qualify for the Windows logo. Similar techniques for boot-time security checking are present in iOS. And hardware-enforced security will protect the runtimes of modern OSes and devices too. An early sign of this can be found in a recently granted Apple patent, which describes a way to segregate memory for a “scary application” such as a browser. And as far as I’m aware, the most advanced approach is micro-virtualization. Bromium uses the open source Xen hypervisor to implement micro-virtualization to protect an entire endpoint, but one could just as easily use it to protect a particular targeted application, such as a document renderer, that is vulnerable to attack.
Micro-virtualization, and Bromium vSentry in particular, offers a huge leap forward – making a device vastly more secure because it relies on hardware to contain and isolate untrusted tasks. Most importantly, micro-virtualization works on today’s PCs, laptops and even virtual desktop infrastructure. Once deployed, you can effectively banish concerns you might have about Oracle’s latest foibles, or Adobe’s latest mis-step. You can achieve practical, hardware-enforced security now, and stop worrying about the latest zero-day, browser vulnerability, PDF or Office-based attack. And then you can empower your users to be mobile and access the full power of the web.
While no system can ever be perfect, it is easy to show how vSentry makes an endpoint tens of thousands of times more resilient to attack. It doesn’t rely on pre-conceived notions of good or bad, it works with software sandboxes, and all of your existing investments in endpoint and network security. Dramatically increasing the cost to the attacker by massively reducing the attack surface of the system has the net effect of making it too expensive for an attacker to compromise a hardware protected endpoint.
There is no silver bullet in security, but there is a very simple set of steps you can take to achieve a massively more secure endpoint posture that allows you to relax in the face of continued software vendor missteps.
Sometimes my commute is all of 10 seconds. I walk into our small home office and I can get cracking right away. A quick chat with my friends on twitter, and then on to deleting email, all with a nice fresh cup of tea. Oh, and no pesky enterprise network in the way.
I visited a west-coast financial services vendor a couple of weeks ago. They had called us in because they have a recurring problem with malware. What could be wrong? I started to ask what sorts of protection systems they use.
- Network: They have all the “latest and greatest” widgets in place: A BlueCoat Proxy, the leading “Next Gen” (must be good) Firewall from Palo Alto. A FireEye box that throws inbound web traffic at sacrificial Windows VMs to see if they are attacked, and an IDS and IPS.
- Endpoint: Each Windows endpoint runs Fed-grade Host Intrustion Prevention, and they use DLP for compliance reasons.
They were doing all the “right” things, though each of these technologies has limitations:
- Advanced malware can easily bypass the most sophisticated network widgets. Why? Malware writers are smart(er) – they simply wait for user interaction before they commence their attack. On the network these attacks appear to be non-malicious because they do nothing until they reach an endpoint with an actively engaged user.
- HIPS is just a variation on the “detect to protect” paradigm. If you don’t have a signature or pattern for the attack, the malware will execute anyway.
I continued to dig into the problem. “Do users have access to consumer apps, like Facebook and Twitter?” I asked. “No – except for a few in Marketing”. And then the first real clue: “Are your users ever mobile?” The reply: “A few… But we have a new policy now where everyone gets to work at home one day a week.” Aha! Now we were onto something: “Do you use VDI for remote access?” “No – it’s too expensive, so we just give each user a laptop.”
It turned out that those WFH days were likely the major cause of the problem. “Can users access the web when they are not on your network?” “Yes”. “Twitter & Facebook?” “Yes, just not allowed from the corporate network because of compliance.”
I see this pattern all too often. An enterprise that is compliant, but insecure. Everyone is complicit in the ultimate insecurity:
- The user just wants to get on with their work, use the web and not have to deal with a slog of a morning commute. WFH? What’s not to like about that?
- IT is over-worked and knows that the vendors’ best detection tools won’t really solve the problem. But they are tasked with compliance, and if compliance is how they are measured, that’s what the CFO will get – instead of protection.
- The vendors just want to sell more stuff. They give the customer incredibly detailed logs to prove that the use of the product ensures compliance. But not protection. And the architecture is the antithesis of what makes users productive.
Protect-first is the only way forward. If you protect the user you can then empower them to do anything. Safely. And compliance is then just a freebie that comes along for the ride.
I was invited invited by Chris Wolf to debate the necessity of VDI with Gunnar Berger at last week’s Gartner Catalyst Conference (a superb event, in the original Burton spirit), chaired by PQR’s Ruben Spruijt (co-creator of the de-facto standard Login VSI benchmark suite for VDI/SBC).
It’s been almost two years since I posted my (scandalous) blog that challenged vendors and customers to properly crystalize the value propositions for VDI by comparison with the much more widely deployed, less expensive and more scalable SBC (Remote Desktop Services). Although we agree on the key use cases for VDI, and its limitations, Gunnar (generously) took a pro-VDI stance (VD-aye) and I took a neutral stance (VD-why). The debate (Video, Free Gartner login needed) offered us an opportunity to re-examine VDI in light of the considerable evolution of the technologies and market adoption over the last two years.
Gunnar (VD-aye) is (like all ex-Burton analysts) a hands-on technologist who knows his stuff. He has exhaustively explored the costs of VDI, both current and projected, based on the evolution of server, memory and storage technologies and Microsoft licensing. He is a staunch opponent of Microsoft’s VDA license requirement for virtual desktops, but recognizes that the license fee on its own ($100/user/year) is a small component in the still staggering costs of VDI on a per user basis, which are dominated by storage. He estimates current cost at just under $1000/user/year, and projects that with new flash-dominated storage technologies this price could fall by as much as $300 in the next few years. His analysis does not include IT or user training costs.
My position remains basically unchanged. There are three core beliefs upon which I believe the adoption of VDI depends:
- Manageability: It is much easier to centrally manage a single golden image of the Windows desktop OS, and then automatically build user desktops (apps, personalization) from this.
- Many-ness: You can deliver a VDI based Windows desktop to many end-points including a work PC, an iPad and a home device
- Security: Centralizing the desktop, apps and data make the enterprise more secure.
But I contest all of these:
- You’d have sworn I said the Pope isn’t Catholic when I said “If your apps run on Windows 7, quit managing the OS – let Microsoft do it instead”. In other words, it’s time for IT to get out of the business of OS patching, as I have previously argued. Moreover, the only successful VDI deployments I’ve seen have all used dedicated desktops, not pooled. Assuming that you can rebuild a desktop from a new golden image and the user’s personalization to get rid of malware is false: lots of malware uses the user profile to persist.
- Windows on an iPad is horrible. Rather use SBC to deliver the application (without the desktop). Moreover, delivering hosted apps or desktops to non-enterprise owned PCs is not secure. Malware on the client can easily steal login credentials and any other data (including pixels) delivered to the device.
- The security arguments are over-inflated. As the community at BriForum 2012 agreed, a hosted virtual desktop is no more secure than a physical one. There may be compliance benefits associated with centralization of data, but what’s to stop your user emailing files from their VDI desktop to their gmail account? Right – you still need DLP.
Net-net there are some limited benefits of hosted virtual desktops, and of course there are some very good (and relatively niche-y) use-cases for them. But for the vast majority of enterprise users, VDI is not the answer. Instead it:
- Is expensive by comparison with traditional endpoints; in particular the VDA CAL adds $100 per user/year. For the valid use cases for VDI, why not dedicate an instance of Windows Server to each user, and dress up the desktop to look like Windows 7?
- Alienates users. Users just want stuff that works, not multiple different environments. Yes, you can force your users to BYO iPad with BYO network for their personal use. But that doesn’t improve security. An attacker going after your assets will attack the corporate desktop directly (browser in the VM, email attachment etc.).
My argument is this: The client computing world is undergoing massive change at present. Use RDS to deliver server hosted Windows apps where necessary. Let Microsoft manage Windows updates wherever possible (they do an awesome job, it’s time you got out of the way). Finally, the industry’s most important security advances over the last 10 years are due to Microsoft. Windows 8 is 20x more secure than Windows XP. By the time you stand up a VDI farm the world will have moved on – a lot – and you’ll be further mired in expensive legacy computing approaches.
At the debate I asked Gunnar to wear a “VD-aye” T-shirt, which he generously agreed to do. On the back was the name “Dr Faustus”. The Faustian deal that IT organizations make with their users is this: “We will give you a VDI desktop. We understand it isn’t productive, powerful, secure or pretty. But if you accept this, we’ll let you use your own Mac” (and in many cases, IT will buy the Mac). The user quickly agrees (who wouldn’t?), uses a rich “BYO” client on which they enjoy admin privileges and an ability to install their own apps (what use is a Mac without iTunes?), and of course use the Office suite to achieve full rich client productivity, on and offline. IT turns a blind eye. It has done what is needed for compliance. And users are happy.
But, it’s not secure. Not even slightly.
The flaw allows malware to escape user-space containment and compromise an endpoint that is equipped with a full suite of traditional endpoint protection software. Our demonstration exploits a (known, patched) vulnerability in a key Windows service that is exposed (visible) within every sandbox.
Before we dive into the details, you might wonder why Bromium cares about breaking sandboxes.
- We continually conduct research to break our own product and other security infrastructure, to allow us to reason about the overall security of systems that we claim to protect.
- Sandboxes are clearly a good idea as part of an application, but we have repeatedly questioned the value of general purpose “OS improvement” sandboxes that increase the attack surface significantly. We wanted to know if they actually help. (They don’t)
Breaking any technology carries with it an ethical reporting obligation. It is important to note that in our work we did not try to expose any new vulnerabilities. We used known vulnerabilities in Windows 7 SP1 to demonstrate common architectural flaws present in all sandboxes. We are not distributing exploit code, and no user will be any more vulnerable as a result of this disclosure than they were prior to it. All vendors have been informed, and most have thanked us for our work.
We have addressed two key attack vectors:
- Our Research presented at Black Hat EU 2013 showed how malware can bypass any sandbox to take advantage of a kernel mode vulnerability – a rapidly growing class of attacks
- We have now also shown how user-mode malware can escape from any sandbox, permitting it to elevate its privileges and disable or bypass other forms of endpoint protection, and comprehensively compromise the endpoint, including data theft
To research whether or not we had uncovered a common flaw in all sandboxes, we tested the attack on several commercial products, including Dell DDP | Protected Workspace, Google Chrome, Adobe Reader XI, Sandboxie, and Trustware Bufferzone Pro.
- No sandbox can protect an OS that is itself vulnerable
- Sandboxes do not substantially reduce the attack surface of the system as a whole
- Sandboxes are not additive: Layering sandboxes doesn’t change system vulnerability at all
- Application sandboxes (eg: the Chrome browser, Adobe Reader XI) are a good idea
- But they cannot protect against advanced malware
- OS Improvement sandboxes (eg: Sandboxie, Dell DDP, Bufferzone Pro) expose many inherent weaknesses due to their need to work with many applications, and should not be relied upon
The Bottom Line
- Do not rely on any sandbox to protect your users from attack
- Do not assume that you can safely execute malware within a sandbox to understand its behavior
- Continue to regularly patch Windows to address both user-mode and kernel mode vulnerabilities.
Everybody accepts that AV has passed its sell-by date. To protect against today’s torrent of malware, AV would need more signatures than any endpoint could consume. To get around this ISVs, the security industry and application /desktop virtualization vendors have added a slew of additional technologies to their offerings, each of which has its own advantages and limitations.
This blog is focused on sandboxing, whose goal is to use software to contain malicious code, to prevent it from compromising the endpoint. The Bromium Labs team has demonstrated that all Windows sandboxes suffers from two fundamental limitations that are difficult or impossible for the vendor to address: Sandbox bypass, and Sandbox escape.
At Black Hat Europe 2013, our team showed how every sandbox is (and always will be) vulnerable to complete bypass when the attacker compromises the OS kernel directly, without needing to escape from the sandbox itself.
In our attack (pictured above) a malicious website simply causes the Windows kernel to parse a poisoned font, compromising the kernel directly without requiring malicious user-mode code to escape from the containment of the sandbox, into the kernel. The attack simply exploits a logic flaw in the kernel itself, and relies on an ability to cause the kernel to stumble when it is doing work on behalf of the malicious application (in this case a malicious web site). This category of vulnerability (a kernel flaw) is unfortunately being exploited much more frequently, with over 60 CVEs disclosed in 2013 to date.
At Black Hat US in July 2013, the Bromium Labs demo takes advantage of a design limitation of every sandbox that permits user-mode code contained in the sandbox to escape, elevate its privileges and arbitrarily attack the system. The vulnerability allows an attacker to escape from any sandbox and achieves privilege escalation by injecting itself into a shell outside the sandbox, from which it can carry disable other endpoint protection and comprehensively compromise the endpoint. The architectural flaw results from the requirement that key Windows OS services be accessible to code executing within the sandbox. A vulnerability in any of these services can be exploited to escape containment.
Here’s the attack. For detail see the Bromium Labs Blog, where you can also download the full pen-tester’s guide to evaluation of sandboxes.
- The attack relies on the observation that key Windows system services are present in (and unprotected by) every sandbox. The diagram below lists the services that are visible within Sandboxie. In Chrome they are fewer in number, but key services such as CSRSS are still present in the sandbox.
2. It takes advantage of a bug in the CSRSS service detailed in CVE-2011-1967. Malicious code running supposedly isolated in the sandbox (for example in the browser) uses the exploit to inject keystrokes into a privileged shell outside the sandbox, which in turn permits it to disable other security software and download a sophisticated attack to comprehensively compromise the device.
- Today’s software based endpoint protection mechanisms all have limitations. They are useful, but cannot be relied upon.
- You should pay for solutions based on the value they deliver. The leading anti-virus solution detects 83% of known attacks (and presumably a lot less than that for unknown attacks). Would you buy a car that started only 83% of the time? Every sandbox can be readily bypassed. Pay accordingly.
- Sandboxes are useful components of applications, but are not viable as an endpoint protection mechanism since they cannot prevent advanced malware from compromising the system.
- The increased sophistication of attackers means that you should expect a targeted attack to be able to bypass all of your current endpoint protection mechanisms.
The only way forward is to leverage hardware-enforced protection:
- Hardware encryption of all data at rest (or simpler: hardware encryption of the whole device – such as Bitlocker)
- Attested boot. This is now a Logo requirement for PCs that ship with Windows 8
- Hardware-based execution protection, including DEP and SMEP.
- Hardware isolated execution of untrusted code, for example using Bromium micro-virtualization.
There is a rich seam of security innovation arriving from Intel. We are at the beginning of a brighter future in which devices protect themselves – independent of IT controls and pesky legacy security technologies.
It’s become cool, particularly among those that sport Macs, to scoff at Java and pretend that it’s an anachronism that the world doesn’t need. Perhaps it’s a re-enactment by the Apple faithful of Steve Jobs’s disdain for Flash, spurred by Apple’s removal of Java as a default plugin for Safari after Apple itself was compromised by a Java-based attack. After all, who can resist getting in a dig at Larry Ellison’s expense?
But the fever pitch around Java is bigger than that. It has grown to the point that the US DHS warned users to disable client-side Java. Talk about shouting into the wind: Java is here to stay – approximately forever. And it can easily be made completely secure.
If you need to ask why Java is needed, then you do not work in a real enterprise setting. Last week I visited a leading manufacturer of heavy machinery, whose innovative designs are crucial to its success. It is being heavily targeted as a result. Like many organizations for which IT is not the focus of the business, the IT operations team is stretched thin. They do their best to keep up.
The company is being actively attacked using Java as a vector because they are stuck with an old version: They use Oracle R11 as their ERP system, which apparently (I haven’t been able to verify this) requires the client to use Java 1.5.0_17. Upgrading the ERP system would be disruptive, expensive and complex, and banning client side Java is not an option – everyone, from Finance to Engineering, has to use the system.
No matter how you look at it, the problem isn’t Java. Nor is it the “You” in “User”. Unlike the countless failed attempts to train users not to click on “seemingly unsafe” links or files, I’m going to assert that user training will never succeed since the attacker is always a step ahead of the trainer. (Unpatched) Java, and un-trainable users are with us to stay.
What is the problem? Complex application and OS software environments are vulnerable because they offer a huge attack surface. Java has been successfully targeted of late because it is a classic example of a complex software environment, and because of its ubiquity and platform independence. Java meets the economic needs of malware writers: One can target a massive number of deployed systems with one piece of malware.
The response of the security and OS vendors is at best, sad. The security industry has nothing more useful to offer than advice on how to un-install, or update the Java plugin. Apple removed Java from Safari last October, and Microsoft FixIt now blocks Java from IE. For its part, Oracle has repeatedly promised to fix Java once and for all, and a recent blog is telling (the highlights are mine):
In JDK 7.2, Oracle added enhanced security warnings before executing applets with an old Java runtime… In JDK 7.10, Oracle introduced a security slider configuration option, …. Further, with the release of JDK 7.21, Oracle introduced the following:
- … With this update … users can prevent the execution of any applets if they are not signed.
- The default plug-in security settings were changed to further discourage the execution of unsigned or self-signed applets. This change is likely to impact most Java users, and Oracle urges organizations …to sign [their] Applets
- While Java provides the ability to check the validity of signed certificates … the feature is not enabled by default because of a potential negative performance impact. …In the interim, we have improved our static blacklisting to a dynamic blacklisting mechanism …
The Oracle “solution” appears to be
- “hope the user does the right thing”,
- “make Java unusable”, and
- “when all else fails, try blacklisting”.
Depending on the user is a bad idea. Making Java unusable is a terrible response, both for Oracle and for its customers. Moreover banning or disabling Java doesn’t address the root of the problem. Blacklisting is an article of faith for the AV vendors, but I think we all recognize that its time has come and gone.
A Future Proof Architecture
There is a way out of this mess that enables
- Today’s vulnerable applications & plugins (Flash, Java, Silverlight, Chrome, Firefox, IE, Word, Powerpoint, Excel, PDF, media etc) to run as intended by the vendor
- New mobile-centric, cloud based applications for consumers or enterprises, to deliver a user experience that fully empowers the user, and
- With absolute security.
The way out is Bromium vSentry. We use use hardware isolation on a per-task basis - to protect the system from every attack. When the next zero day comes along, the attacker will be unable to steal any information or gain access to the corporate network. Moreover, the attacker and all persisted state will be simply discarded as soon as the user closes the task window. No remediation. No change to the applications or to the end user experience. And if the endpoint is attacked, Bromium LAVA will provide live attack visualization, with complete forensic analysis – delivered instantly to the SOC. Check out our new Safely Use Java Apps page to learn more.
Bromium Labs – a security research organization within Bromium whose charter is to serve enterprise security teams – providing research and analysis of security technologies, attack strategies and specific threats. We would like you to have the tools and knowledge to be able to critically examine new and old security widgets in their ability to deal with advanced threats, not just at a point in time, but also in the context of an enduring security architecture.
The Br Labs team is headed by Rahul Kashyap, Bromium’s Chief Security Architect, a veteran security researcher and scientist, and includes acclaimed security researcher Rafal Wojtczuk and Microsoft Bluehat 2012 prize finalist Jared DeMott. If you’ve been following Bromium, you’ll be aware of the team’s ground breaking research on hardware and software security. With Black Hat USA 2013 rapidly approaching, this team is once again poised to shock the world, detailing a set of devastating new end point vulnerabilities and advice for customers.
Enterprise security teams are in a “Catch 22” situation. They know that legacy end point protection systems are unable to protect them, but at the same time, they cannot completely lock the user down or further restrict their ability to access untrusted content or sites. They cannot stop mobility, or make the desktop user experience so awful that users simply go around IT to remain productive. Security teams need clear headed advice, information on attack classes and vectors, and specific techniques and tools to help them better secure their environments, given their current tools and technologies. The Bromium Labs team will provide it.
In a couple of weeks the Bromium Labs team will unveil their next research report at Black Hat 2013. Stay tuned!