Neil MacDonald

One of my major areas of research is in application security, helping clients to change their development (and procurement!) processes to deliver more secure code. This is imperative.

However, an equally important application security discussion must be had about how applications should consume security services within our organization. For example, do you have good answers for these questions?

• How should authentication of users be performed?
• If the application will be accessed by non-employees how will authentication be performed?
• Are there non-user based communications that the application uses (like a back-end RPC) and how/when should these be authenticated?
• In what cases is stronger authentication necessary?
• How should authorization within the application be performed?
• Is there a standard set of enterprise roles that the application should be consuming?
• How do we prevent applications from each developing their own silo of authorization information?
• Do we have a standard way of logging events? Do developers know which events should be logged?
• Do we have standard libraries for authentication, authorization, encryption and so on?

I could go on and on. I see so much focus on the first part of application security and not enough on the second. Yet.

My belief is that we’re still in the middle of performing essentially triage with our vulnerable applications and getting more secure code produced/procured and that once this is under control, the second part of application security will become a priority.

Just program your IPS to look for credit card numbers (or similarly sensitive data) and presto, you now have content-aware DLP (well, a tiny piece of it at least). I’ve got vendors of antivirus solutions for SharePoint that can perform general expression pattern matching while they crawl the SharePoint content repository doing DLP. Seems everything is DLP nowadays.

My colleague Greg Young has written a clever series of blogs on classic vendor mistakes. This one resonated with me:

“Saying your product is in X market because X is currently ‘cool’.

DLP is hot.. It’s one of the top five IT security spending areas I see in 2010. The problem is, much of what we do in information security is ultimately directed at stopping the loss of sensitive data. So almost everything we do is a form of DLP in one way or another. So whether or not a vendor provides a DLP solution depends on how you define DLP.

Rather than rely on the vendor’s definition, turn the tables: whether or not you need a DLP solution depends on what your data protection needs are – and data protection is not a product, it’s a process.

Data protection is the process of identifying and understanding where and how sensitive information is created, consumed, processed, moved, shared, stored and retired and protecting it throughout this lifecycle.

There are a myriad of security controls and policy enforcement points that map to this process: full drive encryption, file/folder encryption, content monitoring and filtering at email and web security gateways, application-level encryption, end-user activity monitoring, sensitive data discovery tools, digital rights management, … and, yes, sure (why not?) – even an IPS or AV scanner that is programmed to look for sensitive data.

If you’ve budgeted for a DLP product in 2010, take a step back and look at the process, then decide which controls take priority in 2010. Don’t let a vendor take your money just because they position themselves as a DLP vendor. That can mean just about anything.

As the number of mobile smartphones increases, as several platforms begin to dominate and as users begin to download lots of executable code, they will become targets for attack. Rather than repeat the mistakes of the PC world, why can’t we do things better from a security perspective this time around?

So far, most mobile platforms have a good start. Requiring all third party to run a sandboxed environment (and making ‘jailbreaks’ difficult) is a great start. This is a lot like running users as ‘standard user’ in Windows which I’ve recommended multiple times. However, a smart and financially motivated malware writer will simply target the user data rather than trying to break out and corrupt the main OS. Just like today’s attacks on enterprise PCs, why should a malware writer go for a noisy attack on the mobile OS when you can quietly harvest user-accessible sensitive data or other activate other user-accessible features? For example, user-accessible data such as address books, contact lists, email, etc and user-accessible features such as turning on/off the microphone, camera, and so on.

Restricting the application ecosystem to an application store (as opposed to the widespread nature of software availability on today’s PCs) also helps, but relies on fast removal of malware once it is reported. Call it what you will, this is a form of blacklisting. As AV has shown us, this model isn’t effective enough and malware writers will simply reregister, create another ‘variant’ and repost.

There’s a couple of things we could do. One would be to require developers to show proof of security testing before being allowed to post an application. We require this for procured enterprise software, why not for mobile software? Problem is, there aren’t any standards of proof for this and a smart hacker would simply fake the results or write code that isn’t vulnerable per se, but contains embedded malicious intent (like copying the address book).

We could also require stronger vetting of developers before they are allowed to post applications. I’ve talked about this concept before in the PC world. This doesn’t prevent vulnerable (and potentially malicious) software from being written, but would help prevent the rapid reregistration problem above. However, the application store vendors don’t want to do anything that slows the number of developers and amount of applications in their stores.

It seems to me the best option would be that the application store owner sets a minimum standard for security and backdoor/trojan testing that is independently performed. However, this raises the cost for developers (or for the store owner) and potentially slows down the ‘network effect’ of having the largest application store (which attracts more users, which attracts more developers, repeat)

Seems like this conflict of interest between the network effect of more developers and applications versus improved security won’t be resolved until a significant attack is publicized and users start voting with their dollars.

Get off of Internet Explore version 6. Now.

IE6 has become an anchor (and a security risk). For Gartner clients, we’ve been advising this since October 2006. In blogging, I’ve said it here and most recently, here again.

However, in reality, the move is easier said than done. Here’s what I said in this research note on planning for and deploying the security features of Windows 7:

The most significant change in IE8 is not security-related — the new rendering engine is more standards-compliant. This introduces significant Web-based application compatibility issues for applications written to specific idiosyncrasies of IE6 (see “IE6 Apps Are Windows XP Apps, So Treat Them That Way in Migration Planning”). Although Microsoft includes IE5 and IE7 back-level rendering support, an IE6 rendering mode is not supported.

Some of your own in-house developed applications that use IE6-specific features will create problems during migration. But clients are telling us that some of their large enterprise application ISVs are the bigger problem. Some don’t officially support IE8 yet. Worse, some of the ISVs won’t support a newer browser unless you pay them money to upgrade to a newer version of their software. Issues with Cognos, Siebel and Peoplesoft are commonly called out as trouble areas in this regard.

Advice going forward: Make any web-enabled application vendor support multiple web-browsers and adhere to widely accepted rendering standards so that the chance of getting ‘locked in’ to a specific browser and version are minimized. Minimize the use of custom browser plug-ins to extend functionality (and that will hamper future migrations). 

I don’t want us to have to go through this again when IE9 (or Firefox 4 for that matter) comes out.

One of my frequent blog posting topics is virtualization security. Virtualization isn’t inherently insecure, but in many cases, it is being deployed insecurely. The latter is a result of the relative immaturity of our tools, processes, staff and service providers. Also, in many cases, information security isn’t proactively involved in the virtualization planning. Survey data from Gartner conferences in late 2009 indicated that about 40% of virtualization deployment projects were undertaken without involving the information security team in the initial architecture and planning stages — an improvement from the same survey a year earlier where 50% indicated that they didn’t proactively involve information security.

Based on responses from the same survey, I’ve just published this research note for clients: Addressing the Most Common Security Risks in Data Center Virtualization Projects  to specifically address the risks that were rated the highest. The survey data is being turned into two research notes. Here’s a list of the most highly rated risks that I addressed in the first RN:

• Information Security Isn’t Initially Involved in the Virtualization Projects
• A Compromise of the Virtualization Layer Could Result in the Compromise of All Hosted Workloads
• The Lack of Visibility and Controls on Internal Virtual Networks Created for VM-to-VM Communications Blinds Existing Security Policy Enforcement Mechanisms
• Adequate Controls on Administrative Access to the Hypervisor/VMM Layer and to Administrative Tools Are Lacking
• There Is a Potential Loss of SOD for Network and Security Controls When These are Virtualized

I’m not a doom-and-gloom type of security analyst, so the bulk of the 10 pages in the research discuss specific actions you can take to address each risk in detail and I provide multiple options to either reduce or eliminate each risk based on established best practices from discussions with thousands of clients over the past three years on these issues.

In my previous post, I discussed three lessons from the recent breaches of Google’s infrastructure as the result of attacks on unknown vulnerabilities in Internet Explorer where no patch was available.

I need to break one out explicitly that falls under the broader category of host-based intrusion prevention: Application Control/whitelisting. I am convinced that whitelisting at the endpoints would have stopped these attacks.

I’ve discussed whitelisting/application control solutions multiple times and I research the approach and solutions extensively. The principle is simple: if an application isn’t on the list (whitelist), then it isn’t allowed to execute. Period. So even if IE had an unknown vulnerability, was subject to a zero-day attack and malicious code was dropped on the machine, the code wouldn’t be allowed to execute because it wasn’t on the approved list. Application control solutions provide straightforward and powerful protection – if code isn’t supposed to be running on a system, don’t let it run.

In practice, it’s not quite that simple, but the principle is sound and I would argue should be foundational in our strategy to protect endpoints. The key to success is the maintenance of the whitelist over time as applications and user’s needs change. This is where the providers of these solutions differentiate and where organizations will succeed or fail in their application control deployments. For those clients evaluating solutions on the market, I discuss the application control market and best practices in detail in this research note or give me a call.

In the very slight chance that the injected code runs within the process space of the compromised application (and thus didn’t try to launch another application that would be blocked by the whitelisting solution), Windows XP SP2 and higher as well as other modern OSs include hardware support for Data Execution Prevention and, for additional protection, some application control solutions include supplemental buffer overflow protection

There is no silver bullet in information security, but if managed correctly (and ideally combined with users running as standard user), application whitelisting solutions at the endpoint provide exceptional protection from zero day and targeted attacks.

We’ve got a team of analysts working on a broader event research note that will be published shortly. What I wanted to discuss here is “so what do I do if my organization is using IE?”. Longer term, there are three key takeaways from the recent events:

Lesson #1 – Run more users as standard user. I’ve said it here and here and most recently here again. This has got to be a top priority initiative in 2010. Use the migration to Windows 7 as a catalyst if this is planned for this year.

Lesson #2 – Get off of IE6 ASAP. I don’t care if this is to Firefox, Chrome, Safari, Opera, IE7 or IE8. Get off of IE6 in 2010. Use the migration to Windows 7 as a catalyst if needed for budget and resources if this planned in 2010.

Lesson #3 – Use defense-in-depth at the endpoint. If you are planning on Windows 7, make sure some of the defense-in-depth capabilities if the OS are turned on in your master image. Technologies and techniques like Address Stack Layout Randomization (ASLR) and extending data execution prevention (DEP) into the browser are discussed in detail in this research note. Note that DEP applies to XP SP2, SP3 if used with IE8 as well. Other clients using third-party host-based intrusion prevention solutions like Cisco Security Agent or McAfee HIPS have additional protection

What to do short term? Back to the compromise at Google. Reports indicate that Microsoft has confirmed an IE vulnerability was involved in the Google attacks. Microsoft’s Security Advisory provides more information about the vulnerability here.

What can you do now if you are worried about IE6 until the patch is released by Microsoft? In addition to Microsoft’s guidance in the advisory, there are several alternatives we discuss with clients, but one option is to run IE6 from a terminal services or hosted virtual desktop (VDI) session where the session is restored back to a known good state after each use.

I’ve written before about OWASP and the guidance they provide to organizations looking to improve application security. One of the best practices for improving application security is to ensure that any code we produce or procure is more secure right from the beginning. Many of the clients I talk with are highly focused on the ‘produce’ part – improving their development processes to ensure that more secure code is produced and that security testing is incorporated in the software development lifecycle.

What about the ‘procure’ part?

Here, organizations should make sure that their contract language when procuring (or outsourcing) software externally also includes similar requirements of proof of testing in their software development lifecycle.

OWASP has a project that provides sample contract language here and using OWASP as a foundation, SANs provides guidance here 

If you haven’t modified your procurement and outsourcing contracting process to include security-related requirements like these, make this a priority in 2010. Use these sample contracts as starting points and make sure to have a qualified attorney help with the final contract negotiation language.

As I discuss multiple security alternatives for enterprise desktops with clients, one of the options that must be discussed is the use of server-based computing and terminal services also referred to by vendors as “presentation virtualization”. One of the questions that comes up is “are terminal services really a form of virtualization, or are vendors just calling this ‘presentation virtualization’ to take advantage of the industry hype around anything to do with virtualization?”.

At its most fundamental level, virtualization is a layer of abstraction between a resource and something that consumes that resource, decoupling these in a way that neither the consumer nor the resource has to know they are being decoupled.

With “presentation virtualization”, the layer of abstraction is between the windows eventing system (the resource) and the Windows application (which consumes and processes the events). The most relevant events in this case are keystrokes, mouse clicks and video updates – let’s start there.

By inserting a layer of software, we can capture the relevant events in both directions and decouple the linkage so that the application can be run by a keyboard, mouse and video system located elsewhere. A network-based protocol (like ICA or RDP) is used to carry the KVM information to and from the physical KVM and the application. Since the abstraction separates the consumer and resources across a network connection, the abstraction takes two pieces of software that work together – in this case, the terminal services software running at the server and the ICA/RDP client running at some type of client device.

The setup delivers what most people consider to be examples of what virtualization enables:

• The application (say Excel) doesn’t know that the user (KVM data) is no longer directly attached.
• The physical keyboard, video and mouse systems don’t know that the application they are using is no longer necessarily local.
• The application could be changed out (say to a new version of Excel) and nothing has to change.
• The keyboard could be replaced and nothing has to change.
• One KVM system could drive multiple copies of the application (as is used in training/classroom scenarios)
• One application could be driven by multiple mice/keyboards (this happens when the technology used for remote support by the help desk for example but can be quite confusing if the user isn’t expecting this!)

The evolution of the ICA/RDP (and others) software and protocols can now virtualize more than just KVM. They can also do the same for USB, printers, CD ROM and other interfaces. The principle is exactly the same. It would be more accurate to call this “user interaction virtualization” but “presentation virtualization” is close enough and is what the industry has settled on for a term.

If we simply virtualized the user interface stuff as described above, this provides usefulness in of itself – say for help desk support or for people to remotely access their desktops. But terminal services and Citrix go farther. Perhaps what is confusing people is that in conjunction to the user interface virtualization, terminal services / Citrix also create the illusion of multiple copies of Windows desktops running on a single copy of Windows. This in of itself is a form of OS virtualization, similar to what Solaris Containers or Virtuozzo does, but TSE/Citrix focuses more on the end-user workspace experience. So it is more accurate to describe terminal services/Citrix as a combination of virtualization solutions that a) creates the illusion of multiple desktops on a single copy of Windows *and* b) virtualizes the user interaction as well so everyone doesn’t have to be directly and physically attached to the server.

In any event,  I believe it is a form a virtualization – albeit one that has been around for more than a decade.

Semantics aside, why do you care? As you consider your enterprise strategy for desktop virtualization and securing these assets, understand there are multiple types of desktop virtualization available on the market today – including full OS virtualization, workspace virtualization, application virtualization and “presentation virtualization” (user interaction virtualization) and more. Each has their uses and pros and cons. In fact, these types of virtualization should be able to be mixed and matched as needed to create a manageable and secure composite workspace appropriate to the user’s needs and the sensitivity of the data and application being hosted.

Over the holiday break, I watched an excellent presentation on PBS titled “What Darwin Never Knew”

During the 2 hour show, it stuck me that all of the diversity — from the simple to the complex — of life on earth is expressed with DNA using only four types of molecules called bases – abbreviated as C,G, A and T.

Then I remembered some of the REST versus WS-*/SOA discussions I’ve been involved in over the past few years.

If four bases can express all of the diversity of life on earth, why can’t four programming verbs express all of what we need in applications — from the simple to the complex?

And just so this thought doesn’t stray too far from information security – I see far too much complexity in our information security infrastructure, many times in the name of “defense in depth”. Don’t get me wrong, DiD is a sound principle, its just that somehow the vendors and some overly zealous security practitioners have warped this into meaning spend lots and lots of money on lots of lots of point solutions. 

One of our goals for 2010 should be the reduction of information security complexity and one of the first ways should be the consolidation onto security platforms that consolidate multiple, disparate security point solutions.