Research

Building security in? Bolting it on? If you develop in-house applications, it’s likely both. Application security will be a key theme of the show. But the preponderance of application security tools will block, scan, mask, shield, ‘reperimeterize’, reconfigure, or reset connections from the outside. Bolt-on is the dominant application security model for the foreseeable future. The good news is that you may not be the one managing it, as there is a whole bunch of new cloud security services and technologies available. Security as a service, anyone? Here’s what we expect to see at this year’s RSA Conference. SECaaS Security as a Service, or ‘SECaaS’; basically using ‘the cloud’ to deliver security services. No, it’s not a new concept, but a new label to capture the new variations on this theme. What’s new is that some of the new services are not just SaaS, but delivered for PaaS or IaaS protection as well. And the technologies have progressed well beyond anti-spam and web-site scanning. During the show you will see a lot of ‘cloudwashing’ – where the vendor replaces ‘network’ with ‘cloud’ in their marketing collateral, and suddenly they are a cloud provider – which makes it tough to know who’s legit. Fortunately at the show you will see several vendors who genuinely redesigned products to be delivered as a service from the cloud and/or into cloud environments. Offerings like web application firewalls available from IaaS vendors, code scanning in the cloud, DNS redirectors for web app request and content scanning, and threat intelligence based signature generation, just to name a few. The new cloud service models offers greater simplicity as well as cost reduction, so we are betting these new services will be popular with customers. They’ll certainly be a hit on the show floor. Securing Applications at Scale Large enterprises and governments trying to secure thousands of off-the-shelf and homegrown applications live with this problem every day. Limited resources are the key issue – it’s a bit like weathering a poop storm with a paper hat. Not enough protection and the limited resources you have are not suitable for the job. It’s hard to be sympathetic as most of these organizations created their own headaches – remember when you thought it was a good idea to put a web interface on those legacy applications? Yeah, that’s what I’m talking about. Now you have billions of lines of code, designed to be buried deep within your private token ring, providing content to people outside your company. Part of the reason application security moves at a snail’s pace is because of the sheer scope of the problem. It’s not that companies don’t know their applications – especially web applications – are not secure, but the time and money required to address all the problems are overwhelming. A continuing theme we are seeing is how to deal with application security at scale. It’s both an admission that we’re not fixing everything, and an examination of how to best utilize resources to secure applications. Risk analysis, identifying cross-domain threats, encapsulation, reperimetrization, and multi-dimensional prioritization of bug fixes are all strategies. There’s no embodying product that you’ll see at the show, but we suggest this as a topic of discussion when you chat with folks. Many vendors will be talking about the problem and how their product fits within a specific strategic approach for addressing the issue. Code Analysis? Meh. DAST? Yeah. The merits of ‘building security in’ are widely touted but adoption remains sporadic. Awareness, the scale of the issue, and cultural impediments all keep tools that help build secure code a small portion of the overall application security market. Regardless, we expect to hear lots of talk about code analysis and white box testing. These products offer genuine value and several major firms made significant investments in the technology last year. While the hype will be in favor of white box code analysis, the development community remains divided. No one is arguing the value of white box testing, but adoption is slower than we expected. Very large software development firms with lots of money implement a little of each secure code development technique in their arsenal, including white box as a core element, basically because they can. The rest of the market? Not so much. Small firms focus on one or two areas during the design, development, or testing phase. Maybe. And that usually means fuzzing and Dynamic Application Security Testing (DAST). Whether it’s developer culture, or mindset, or how security integrates with development tools, or this is just the way customers want to solve security issues – the preference is for semi-black-box web scanning products. Big Data, Little App Security You’re going to hear a lot about big data and big data security issues at the conference. Big Data definitely needs to be on the buzzword bingo card. And 99 out of 100 vendors who tell you they have a big data security solution are lying. The market is still determining what the realistic threats are and how to combat them. But we know application security will be a bolt-on affair for a long period, because: Big data application development has huge support and is growing rapidly A vanishingly low percentage of developer resources are going into designing secure applications for big data. SQL injection, command injection, and XSS are commonly found on most of the front-end platforms that support NoSQL development. Some of them did not even have legitimate access controls until recently! Yes, jump into your time machine and set the clock for 10 years ago. Make no mistake – firms are pumping huge amounts of data into production non-relational databases without much more than firewalls and SSL protecting them. So if you have some architects playing around with these technologies (and you do), work on identifying some alternatives to secure them at the show. Share:

As you can tell from my TidBITS review of Gatekeeper, I think this is an important advancement in consumer security. There are a lot of in-depth technical aspects that didn’t fit in that article, so here’s an additional Q&A for those of you with a security background who care about these sorts of things. I’m skipping the content from the TidBITS article, so you might want to read that first. Will Gatekeeper really make a difference? I think so. Right now the majority of the small population of malware we see for Macs is downloaded trojans and tools like Mac Defender that download through the browser. While there are plenty of ways to circumvent Gatekeeper, most of them are the sorts of things that will raise even uneducated users’ hackles. Gatekeeper attacks the economics of widespread malware. It conveys herd immunity. If most users use it (and as the default, that’s extremely likely) it will hammers on the profitability of phishing-based trojans. To attackers going after individual users, Gatekeeper is barely a speed bump. But in terms of the entire malware ecosystem, it’s much more effective – more like tire-slashing spikes. How does Gatekeeper work? Gatekeeper is an extension of the quarantine features first implemented in Mac OS X 10.5. When you download files using certain applications a “quarantine bit” is set (more on that in a second). In OS X 10.5-10.7 when you open a file Launch Services looks for that attribute. If it’s set, it informs the user that the program was downloaded from the Internet and asks if they still want to run it. Users click through everything, so that doesn’t accomplish much. In 10.6 and 10.7 it also checks the file for any malware before running, using a short list that Apple now updates daily (as needed). If malware is detected it won’t let you open the file. If the application was code signed, the file’s digital certificate is also checked and used to validate integrity. This prevents tampered applications from running. In Mac OS X 10.8 (Mountain Lion), Gatekeeper runs all those checks and validates the source of the download. I believe this is done using digital certificates, rather than another extended attribute. If the file is from an approved source (the Mac App Store or a recognized Developer ID) then it’s allowed to run. Gatekeeper also checks developer certificates against a blacklist. So here is the list of checks: Is the quarantine attribute set? Is the file from an approved source (per the user’s settings)? Is the digital certificate on the blacklist? Has the signed application been tampered with? Does the application contain a known malware signature? If it passes those checks, it can run. What is the quarantine bit? The quarantine bit is an extended file attribute set by certain applications on downloaded files. Launch Services checks it when running an application. When you approve an application (first launch) the attribute is removed, so you are never bothered again for that version. This is why some application updates trigger quarantine and others don’t… the bit is set by the downloading application, not the operating system. What applications set the quarantine bit? Most Apple applications, like Safari, Firefox, Mail.app, and a really big list in /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/Exceptions.plist. Plus any applications where developers implement it as part of their download features. In other words, most things a consumer will use to download files off the Internet. But the clearly they won’t catch everything, so there are still applications that can download and avoid Gatekeeper. System utilities like curl, aren’t protected. What apps aren’t protected? Anything already on your system is grandfathered in. Files transferred or installed using fixed media like DVDs, USB drives, and other portable media. Files downloaded by applications that don’t set the quarantine bit. Scripts and other code that isn’t executable. So will this protect me from Flash and Java malware? Nope. Although they are somewhat sandboxed in browsers (which varies widely by browser), applets and other code run just fine in their container, and aren’t affected or protected. Now we just need Adobe to sandbox Flash like they did on Windows. What is the Developer ID? This is a new digital certificate issued by Apple for code signing. It is integrated into XCode. Any developer in the Mac App Developer Program can obtain one for free. Apple does not review apps signed with a Developer ID, but if they find a developer doing things they shouldn’t they can revoke that certificate. These are signed by an Apple subroot that is separate from the Mac App Store subroot. How are Developer ID certificates revoked? Mountain Lion includes a blacklist that Apple updates every 24 hours. If a malicious application is found and Apple revokes the certificate, will it still run? Yes, if it has already run once and had the quarantine bit cleared. Apple does not remove the app from your system, although they said they can use Software Update to clean any widespread malware as they did with Mac Defender. What about a malicious application in the Mac App Store? Apple will remove the application from the app store. This does not remove it from your system, and it would also need to be cleaned with a software update. If we start seeing a lot of this kind of problems, I expect this mechanism to change. Does this mean all Mac applications require code signing? No, but code signing is required for all App Store and Developer ID applications. Starting in Lion, Apple includes extensive support for code signing and sandboxing. Developers can break out and sign different components of their applications and implement pretty robust sandboxing. While I expect most developers to stick with basic signing, the tools are there for building some pretty robust applications (as they are on Windows – Microsoft is pretty solid here as well, although few developers take advantage of it). What role does sandboxing play? All Mac App Store applications must implement sandboxing by March 1st, long before Mountain Lion is released. Sandbox entitlements are

I managed to take a couple days off last week, and got out of town. I went camping with a group of friends, all from very different backgrounds, with totally unrelated day jobs – but we all love camping in the desert. Whenever we’re BSing by the camp fire, they ask me about current events in security. There’s almost always a current data breach, ‘Anonymous’ attack, or whatever. This group is decidedly non-technical and does not closely follow the events I do. This trip the question on their minds was “What ‘s the big deal with SOPA?” Staying away from the hyperbole and accusations on both sides, I explained that the bill would have given content creators the ability to shut down web sites without due process if they suspected they hosted or distributed pirated content. I went into some of the background around issues of content piracy; sharing of intellectual property; and how digital media, rights management, and parody make the entire discussion even more cloudy. I was surprised that this group – on average a decade older than myself – reacted more negatively to SOPA than I did. One of them had heard about the campaign contributions and was pissed. “Politicians on the take, acting on behalf of greedy corporations!” was the general sentiment. “My sons share music with me all the time – and I am always both happy and surprised when they take an interest in my music, and buy songs from iTunes after hearing it at my place.” And, “Who the hell pirates movies when you can stream them from Netflix for a couple bucks a month?” I love getting non-security people’s reactions to security events. It was a very striking reaction from a group I would not have expected to get all that riled up about it. The response to SOPA has been interesting because it crosses political and generational lines. And I find it incredibly ironic that the first thing both sides state is that they are against piracy – but they cannot agree what constitutes piracy vs. fair use. One of my favorite slogans from the whole SOPA debate was It’s No Longer OK To Not Know How The Internet Works, accusing the backers of the legislation of being completely ignorant of a pervasive technology that has already changed the lives of most people. And even people who I do not consider technically sophisticated seem to “get it”, and we saw wit the ground-swell of support. I am willing to bet that continuing advances in technology will make it harder and harder for organizations like the RIAA to harass their customers. Maybe invest some of that money in a new business model? I know, that’s crazy talk! On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian’s OWASP presentation is live. Adrian’s Dark Reading post on The Financial Industry’s Effect On Database Security. Rich’s TidBITS posts: Mac OS X 10.8 Mountain Lion Stalks iOS & Gatekeeper Slams the Door on Mac Malware Epidemics. Favorite Securosis Posts Mike Rothman: RSAG 2012: Application Security. Love Adrian’s summary of what you’ll see at the RSA Conference around AppSec. Especially since we get to see SECaaS in print. Adrian Lane: OS X 10.8 Gatekeeper in Depth. Real. Practical. Security. Other Securosis Posts RSA Conference 2012 Guide: Key Themes. RSA Conference 2012 Guide: Network Security. Incite 2/15/2012: Brushfire. Friday Summary: February 10, 2012. [New White Paper] Network-Based Malware Detection: Filling the Gaps of AV. Implementing and Managing a Data Loss Prevention (DLP) Solution: Index of Posts. Implementing DLP: Starting Your Integration. Implementing DLP: Deploying Network DLP. Implementing DLP: Deploying Storage and Endpoint. Favorite Outside Posts Mike Rothman: The Sad and Ironic Competition Within the Draft “Expert” Community. Whether you are a football fan or not, read this post and tell me there aren’t similarities in every industry. There are experts, and more who think they are experts, and then lots of other jackasses who think breaking folks down is the best way to make themselves look good. They are wrong… Adrian Lane: Printing Drones. I can think of several good uses – and a couple dozen evil ones – for something like this. Control and power will be a bit tricky, but the potential for amusement is staggering! Project Quant Posts Malware Analysis Quant: Metrics – Build Testbed. Malware Analysis Quant: Metrics – Confirm Infection. Malware Analysis Quant: Monitoring for Reinfection. Malware Analysis Quant: Remediate. Malware Analysis Quant: Find Infected Devices. Malware Analysis Quant: Defining Rules. Malware Analysis Quant: The Malware Profile. Research Reports and Presentations Network-Based Malware Detection: Filling the Gaps of AV. Tokenization Guidance Analysis: Jan 2012. Applied Network Security Analysis: Moving from Data to Information. Tokenization Guidance. Security Management 2.0: Time to Replace Your SIEM? Fact-Based Network Security: Metrics and the Pursuit of Prioritization. Tokenization vs. Encryption: Options for Compliance. Top News and Posts Flash Player Security Update via Krebs, and a Java Security Update. Gatekeeper for Mountain Lion. Vote for Web Hacking Top Ten. No so random numbers lead to bad keys? Who Knew? Paget Demo’s Wireless Credit Card Theft. Carrier IQ Concerns. Blog Comment of the Week No comments this week. Starting to think our comments feature is broken. Oh, wait, it is! Share: