Lenny Zeltser on Information Security

[lennyzeltser]

Security Risks and Benefits of Docker Application Containers

Running applications in containers rather than virtual machines is gaining traction in the IT community. This ecosystem presently revolves around Docker, a platform for packaging, distributing and managing Linux apps within containers. Though this technology is not very mature yet, it will evolve along the trajectory similar to that of VLANs and virtual machines. In the meantime, let's explore the security risks and benefits of using such containers.

The Degree of Isolation of Application Containers

Containers take advantage of the Linux kernel's ability to create isolated environments that are often described as a "chroot on steroids." Containers and the underlying host share a kernel. However, each container is assigned its own mostly independent runtime environment as with the help of Control Groups (cgroups) and namespaces. Each container receives its own network stack and process space, as well as its instance of a file system.

As of this writing, Docker does not provide each container with its own user namespace, which means that it offers no user ID isolation. A process running in the container with UID 1000, for example, will have the privileges of UID 1000 on the underlying host as well. Along these lines, a process running as root (UID 0) in a container has root-level privileges on the underlying host when interacting with the kernel. Docker aims to address this limitation, so that a container's root user could be mapped to a non-root user on the host. This is feasible, as demonstrated by Altiscale's project to bring user namespaces to Docker.

Docker isolates many aspects of the underlying host from an application running in a container without root privileges. However, this separation is not as strong as that of virtual machines, which run independent OS instances on top of a hypervisor without sharing the kernel with the underlying OS. It's too risky to run apps with different security profiles as containers on the same host, but there are security benefits to encapsulating into containers applications that would otherwise run directly on the same host.

Locking Down and Patching Containers

A regular system often contains software components that aren't required by its applications. In contrast, a proper Docker container includes only those dependencies that the application requires, as explicitly prescribed in in the corresponding Dockerfile. This decreases the vulnerability surface of the application's environment and makes it easier to lock it down. The smaller footprint also decreases the number of components that need to be patched with security updates.

When patching is needed, the workflow is different from a typical vulnerability management approach:

Traditionally, security patches are installed on the system independently of the application, in the hopes that the update doesn't break the app.

Containers integrate the app with dependencies more tightly and allow for the container's image to be patched as part of the application deployment process.

Rebuilding the container's image (e.g., "docker build") allows the application's dependencies to be automatically updated.

The container ecosystem changes the work that ops might traditionally perform, but that isn't necessarily a bad thing.

Running a vulnerability scanner when distributing patches the traditional way doesn't quite work in this ecosystem. What a container-friendly approach should entail is still unclear. However, it promises the advantage of requiring fewer updates, bringing dev and ops closer together and defining a clear set of software components that need to be patched or otherwise locked down.

Security Benefits and Weaknesses of Containers

Application containers offer operational benefits that will continue to drive the development and adoption of the platform. While the use of such technologies introduces risks, it can also provide security benefits:

Containers make it easier to segregate applications that would traditionally run directly on the same host. For instance, an application running in one container only has access to the ports and files explicitly exposed by other container.

Containers encourage treating application environments as transient, rather static systems that exist for years and accumulate risk-inducing artifacts.

Containers make it easier to control what data and software components are installed through the use of repeatable, scripted instructions in setup files.

Containers offer the potential of more frequent security patching by making it easier to update the environment as part of an application update. They also minimize the effort of validating compatibility between the app and patches.

Not all is peachy in the world of application containers, of course. The security risks that come to mind when assessing how and whether to use containers include the following:

The flexibility of containers makes it easy to run multiple instances of applications (container sprawl) and indirectly leads to Docker images that exist at varying security patch levels.

The isolation provided by Docker is not as robust as the segregation established by hypervisors for virtual machines.

The use and management of application containers is not well-understood by the broader ops, infosec, dev and auditors community yet.

Containers are Coming

The current state of application containers reminds me of the early days of other segmentation technologies, namely VLANs and virtual machines.

VLANs were created for performance and convenience. They allow defining Ethernet broadcast domains flexibly across multiple switches. As an isolation tool, they are useful for improving the network's performance. They were were initially seen as risky due to software, hardware and security implementation flaws. Security concerns with VLANs still exist, but the technology and management practices have matured to the point that rare is a network that doesn't employ VLANs in some capacity.

Similarly, one could draw a parallel to the evolution of virtualization technologies. Even today, the flexibility that they provide acts as a magnifying force for accomplishing great IT feats, while also giving the organization plenty of opportunities to weaken its security posture. Yet, the proper use of virtual machines is now widely understood and accepted even in environments where data security is important.

Application containers, whether implemented using Docker, LXC, Rocket or another project, are gaining momentum. They are not going away. As the technology and associated processes mature they will address many of the risks outlined above. Security professionals can help shape the evolution of the container ecosystem by exploring its risks and mitigation strategies. We also need to be prepared to discuss containers with our dev and ops colleagues when the time comes. It'll be sooner than you think.

-- Lenny Zeltser

[lennyzeltser]

Getting to Know Docker for Distributing and Running Applications

Docker is a platform for packaging, running and managing applications in a flexible and efficient manner. Its approach to container-based virtualization is gaining traction among OS and cloud providers such as Redhat, Microsoft and Amazon, making it likely that you'll encounter Docker soon if you haven't already. To get started with Docker, let's explore how you might use it to package or run an application, then consider the larger implications. For this example, I'll explain how to build a Docker image for the JSDetox JavaScript deobfuscation tool.

What is Docker?

Docker takes advantage of Linux kernels' ability to run applications in containers, which are sometimes described as "chroot on steroids." Containers provide each application an independent runtime environment, while avoiding the overhead of a full-fledged virtual machine.

Each container gets its own virtual file system, process listing and network stack; however, containers share the OS kernel with each other and the underlying host. In this respect, the isolation provided by containers is less robust than that of real virtual machines, which have independent kernels and run on top of a hypervisor. Yet, sharing the kernel allows containers to run faster and offers management features that are difficult to accomplish with traditional virtualization.

An application distributed as a Docker image incorporates all the dependencies and configuration necessary for it to run, eliminating the need for end-users to install packages and troubleshoot dependencies. This approach allows developers to be certain that if the application worked in dev, it will work in production. Docker provides the tools necessary to build, run and manage applications packaged as Docker images.

Sounds a bit too abstract? The best way to understand Docker is to experiment with it.

Running a Dockerized Application

If you're running Linux as your base operating system, installing Docker is very easy (e.g., "sudo apt-get install docker.io"). If you're running OS X or Windows, you can install Docker as well, though with a few additional steps. Just follow instructions appropriate for your OS.

Next, try running a Dockerized application. Docker maintains a registry of public applications available as Docker images. As a starting point, consider running the image of the JSDetox JavaScript deobfuscation tool, which I packaged for this posting.

Setting up JSDetox the traditional way isn't very difficult, but it requires installing a bunch of packages, which might conflict with other software you've already installed. Not a big deal, but Docker provides an easier way to distribute the application, so that you can run it without worrying about having the right dependencies.

Once Docker is installed on your Internet-connected system, you can run my JSDetox application image by typing:

sudo docker run --rm -p 3000:3000 remnux/jsdetox

Then, launch your web browser and point it to http://localhost:3000. If using Windows or OS X, the steps are a bit more awkward, because you'll need to connect to the IP address of the virtual machine that Docker will have set up on your system for hosting its containers; this is done with the help of a tool called boot2docker.

The "docker run" command above will run the image called "remnux/jsdetox". If the image is not already present on your system, the tool it will look for it in Docker's image registry and automatically download it. If your system already has some of file system layers upon which "remnux/jsdetox" depends, Docker will only download the missing layers. If I update the image, Docker will automatically update the appropriate aspects of your cached image the next time you run the application.

A Docker container is an instance of a Docker image. This allows you to have a single image that represents the application, while being able to launch multiple isolated instances of the app on a single host. The "--rm" parameter in the command above directs Docker to automatically remove the container once it finishes running. This gets rid of any changes the application may have made to the local environment when it ran, but does not remove the cached image file that represents the app on your system.

The "-p 3000:3000" command directs Docker to map TCP port 3000 from the container to TCP port 3000 on localhost. When JSDetox runs, it listens locally on TCP port 3000, so you can connect to it as http://localhost:3000. Since the app will be running in a container, that port will be inaccessible from your underlying system unless you direct Docker to expose it.

To stop a Docker container, such as the one that we just launched, first determine its container ID by running the "sudo docker ps -l" command. Then run the command "sudo docker stop container-id" by specifying the appropriate container ID.

Building a Docker Image of an Application

One way to build a Docker image for the desired application is to start with a base image for the core OS, run it in Docker, install the necessary tools and make the configuration tweaks. You can then use the Docker "commit" command to save the container to an image and, if you wish, publish it in Docker's public registry or your own private registry.

Another approach is to document the steps necessary to build your image in a properly-formatted Dockerfile file. This approach makes sure that all aspects of installing and configuring the application are properly documented and can be repeated. For example, take a look at the Dockerfile I created for the JSDetox image. It's available on the REMnux Github page in its full glory, but here key excerpts:

FROM ubuntu:14.04

The instruction above directs Docker to use a public instance of the Ubuntu 14.04 image as the baseline for the new image, so I don't have to build my own OS image.

USER root RUN apt-get update && apt-get install -y git ruby ruby-dev ...

The instructions above direct Docker to update core OS packages and install additional packages that JSDetox requires to operate properly, running the "apt-get" command within the container with administrative privileges.

RUN groupadd -r nonroot -g 433 && useradd -u 431 -r -g nonroot ...

The instructions above add a group and user named "nonroot" to the image, so that JSDetox can be launched without administrative privileges.

USER nonroot WORKDIR /home/nonroot RUN git clone https://github.com/svent/jsdetox.git

The instructions above download JSDetox from its Github repository as the user "nonroot".

WORKDIR /home/nonroot/jsdetox RUN bundle install

The instructions above install the JSDetox application.

USER nonroot WORKDIR /home/nonroot/jsdetox CMD ./jsdetox -l $HOSTNAME 2>/dev/null

The instructions above specify how Docker should launch the JSDetox application when the user runs its container.

Once you're ready to build the image, run the command "sudo docker build -t=image-name ." from the directory where the Dockerfile is located. You can can also publish the Dockerfile on Github or BitBucket and link it to your account on Docker's public registry; this way, Docker will automatically update your application's image when you change the Dockerfile.

The Benefits of Dockerizing Applications

In the example of the JSDetox image above, you can see that the application maintainer needs to carefully think through the steps needed to install and configure the app. This is easier to do with Docker than in the traditional scenario, because Docker allows the developer to specify all the necessary dependencies in the Dockerfile and to test the image before distributing it to others.

Conveniently, if the developer changes the Dockerfile, Docker automatically updates the corresponding application image in its public repository, making sure that users will get the latest update the next time they run the image. They simply need to run the application by specifying the appropriate Docker image without worrying about OS installation, dependencies, configuration and updates.

A Redhat article outlines additional benefits that Docker offers, which include:

Rapid application deployment

Portability across machines

Version control and component reuse

Simplified maintenance

This introductory posting uses a relatively simple scenario to demonstrate how one might get started with Docker, but there are many more use-cases for running complex applications in dev environments and, potentially, for deploying sophisticated software into production. Docker's initial simplicity is misleading. The more I experiment with Docker, the more I recognize that it offers more than the sum of its parts.

Update 1: I launched a new initiative as part of the REMnux project to build and distribute Docker images of Linux applications useful for malware analysis.

Update 2: If you'd like to understand the security pros and cons of these technologies, read my article Security Risks and Benefits of Docker Containers.

Update 3: To learn more about this topic, tune into the webcast I recorded to explain How to Run Linux Malware Applications as Docker Containers.

-- Lenny Zeltser

[lennyzeltser]

Security of Third-Party Keyboard Apps on Mobile Devices

Major mobile device platforms allow users to replace built-in keyboard apps with third-party alternatives, which have the potential to capture, leak and misuse the keystroke data they process. Before enabling the apps, their users should understand the security repercussions of third-party keyboards, along with the safeguards implemented by their developers.

Third-party keyboards received a boost of attention when Apple made it possible to implement such apps on iOS 8, though this capability have existed on Android for a while. iOS places greater restrictions on keyboards than do Android operating systems; however, even Apple cannot control what keyboard developers do with keystroke data if users allow these apps to communicate over the network.

Granting Network Access to the Keyboard App

The primary security concerns related to keyboard applications are associated with their ability to transmit the user's keystrokes and potentially other sensitive data to developers' servers. On iOS, this is possible if the user grants the app "full access," as encouraged or required by the application.

The notion of "full access" is equivalent to the term "network access" that Apple's App Extension Programming Guide discusses when explaining how to build a custom keyboard. According to the guide, network access is disabled by default. Once enabled by the user, this capability allows the keyboard to access "Location Services and Address Book, with user permission," "send keystrokes and other input events for server-side processing," and perform additional actions that would otherwise be unavailable.

A legitimate keyboard app might send keystrokes to its server to perform intelligent analysis that is best conducted in the "cloud," such as predict upcoming letters, store user typing patterns or perform large-scale lexicon analytics. Some third-party keyboards will function without their users granting them "full access;" however this will disable some of the features that might have drawn the users to the app in the first place.

Guidelines for Networked Keyboard Apps

Apple encourages keyboard developers to "establish and maintain user trust" by understanding and following "privacy best practices" and the associated iOS program requirements, guidelines and license agreements. For instance, if the keyboard sends keystroke data to the provider's server, Apple asks the developer to not store the data "except to provide services that are obvious to the user."

Presumably, Apple's app review process catches blatant violations of such guidelines; however, once the keyboard transmits user data off the phone, there is little Apple can do to assess or enforce developers' security measures. (I haven't been able to locate keyboard-related security guidelines for the Android ecosystem, but I suspect they are not stronger than those outlined by Apple.)

Users of third-party keyboards should not count on mobile OS providers to enforce security practices on server-side keyboard data processing. Instead, they should decide whether they trust the keyboard developer with their data, perhaps on the basis of their perception of the developer's brand and public security statements.

Security and Privacy Statements from Keyboard Developers

I looked at the security and privacy statements published by the developers of three popular keyboard apps that are available for Android and iOS devices: SwiftKey, Fleksy and Swype. Their developers differ in their explanation of how the safeguard users' data.

SwiftKey

SwiftKey publishes a high-level overview of its data security and privacy practices. For users who opt into the SwiftKey Cloud feature of the product, the company collects "information concerning the words and phrases" that users utilize. The company calls this Language Modeling Data and explains that it is used to provide users with "personalization, prediction synchronization and backup." Fields that website or app developers designate as denoting a password or payment information are excluded from such collection.

SwiftKey states that the data transferred to SwiftKey Cloud is transmitted to their servers "over encrypted channels" and is stored in a "fully encrypted" manner. The company also points out that its data protection practices are governed by "stringent EU privacy protection laws and mentions Safe Harbor principles. The company also states that data of users who don't enable SwiftKey Cloud is not transferred out of their devices.

Users of the SwiftKey iOS app are instructed to grant the keyboard full access. Once this is accomplished, the user has the option of enabling SwiftKey Cloud "to enhance SwiftKey's learning" by signing in with their Facebook or Gmail credentials. To discover security implications of enabling this feature, the user had to dig into the details available by clicking "Privacy policy" and "Find out more" links.

Unfortunately, SwiftKey on iOS doesn't function at all until the user grants it full access. The user needs to trust SwiftKey that they won't send data off the mobile device unless SwiftCloud is enabled.

Fleksy

Like SwiftKey, Fleksy uses the term Language Modeling Data in its Privacy Policy, explaining that it refers to data "such as common phrases or words that you use when typing with Fleksy." According to the policy, the collection of this data is "disabled by default" and "is not enabled during the installation process." Like SwiftKey, Fleksy pledges to encrypt the data when transmitting and storing it and to "not log data entered into password or credit card fields."

Fleksy states that it doesn't collect Language Modeling Data unless the user opts into supplying such data to Fleksy. However, I saw no mention of Language Modeling Data or the associated security repercussions in the Fleksy iOS app. Instead, I was encouraged to enable "Customization" by granting the keyboard full access, stating that "keyboard apps require full access to sync your preferences."

Swype

Swype is another popular keyboard for mobile devices. It's developed by a company called Nuance. Unfortunately, I could not find any information about this app's security practices beyond a knowledgebase article for its Android keyboard, which stated that the company "does not collect personal information such as credit card numbers" and "suppresses all intelligent learning and personal dictionary addition functionality when used in a password field." The company's privacy policy contains generic statements such as:

"Nuance may share Personal Information within Nuance to fulfill its obligations to you and operate its business consistent with this Privacy Policy and applicable data protection law."

Conclusions and Implications

Third-party keyboards for mobile devices offer features that improve upon some aspects of built-in keyboards. However, to enjoy such innovations, the users generally need to grant keyboard apps network access. This means that the users need to accept the following risks:

The users need to be OK allowing keyboard developers to collect and store on their servers Language Modeling Data without fully understanding the meaning of this term or its privacy and security implications. The collection of such data is generally acknowledged by the keyboard developers, though they offer almost no details regarding how this data is safeguarded beyond referring to "encryption."

The users need to trust the keyboard developer not to capture keystrokes and other sensitive data beyond Language Modeling Data. Doing this could be done on purpose by a malicious keyboard app or by accident by an otherwise benign application. In this case, the keyboard could act as a powerful keylogger for the mobile device.

Users might assume that the guardians of their mobile OS, be they Google, Apple, Samsung, etc., might protect them from malicious or accidental misuse of keystroke data and network access. However, such firms have no direct control over what happens once the data leaves the mobile device.

Keyboard developers should provide additional details about their security practices to reassure users and consider how their apps might provide innovative features in a manner that minimizes users' risk and the apps' need for network access. It's unclear why SwiftKey cannot function (at least on iOS) without network access, why Fleksy doesn't make it easier for users of its app to understand when data is sent to the company's servers and why Nuance doesn't discuss any of these topics for its Swype keyboard on its website.

Hey, that's just my perspective. What's yours?

-- Lenny Zeltser

[lennyzeltser]

A Closer Look at the Google Domains Registrar

Google's new domain registration service, Google Domains, is shaping up to be a capable, yet easy-to-use service, which will put pressure on traditional registrars to offer additional features, clean-up their user interface or drop prices. Here is what Google Domains—currently in invite-only beta—looks like, once you've registered a new domain using its service or transferred an existing one into it.

When managing a domain using the Google Domains dashboard, you are presented with 4 tabs:

Let's take a look at the features available in each of these areas.

The Website Tab

The Website area is designed to be useful for non-technical people who wish to set up a simple website. For those with an existing site, it allows users to set up URL forwarding. For instance, I configured one of my domains to redirect web visitors to an existing page on my website:

When directed to set up URL forwarding for a domain, Google Domains configures the domain with an A record that specifies the IP address of the Google web server that performs the HTTP redirection. Conveniently, the user of Google Domains doesn't need to know how DNS or HTTP works to set this up.

The Website area of the dashboard also invites the user to "Build your presence with one of our partners" and lists Squarespace, Wix, Shopify and Weebly. If interested, the user can click the "Start trial" button or click "Connect existing account" for each of these companies. Google Domains notes that "Google may be compensated by some of these providers."

The Email Tab

The Email area of the dashboard allows the Google Domains user to create up to 100 email forwarding aliases:

For this feature to work, the domain needs to be configured to use Google's mail servers, which Google Domain accomplishes by automatically defining the appropriate MX record. Once again, the goal is to simplify domain configuration for non-technical users, while giving the more technical people the ability to override default settings and configure additional domain records in the Advanced tab.

The Settings Tab

The Settings area of the dashboard allows the user to pay for extending the length of the domain's registration (1 year $12) and unlock the domain for transferring it to another registrar. Moreover, the user can control the privacy of the domain registration record, which is a major differentiator for Google Domains, because this feature is available without additional fees.

The user can specify contact details for the domain, which Google will keep from showing up in Whois queries upon the user's request by integrating with third-party. In the case of my domain, that third party turned out to be WhoisProxy.com Ltd, which resulted in the following public Whois record being published for it by Google Domains:

WhoisProxy defines an email alias that allows someone to contact the domain's registrant. However, that alias conceals the identity of the person who will receive the email. Moreover, the email address shown in Whois changes frequently and a given alias expires after some period of time; this is designed to make it less useful for spammers to harvest these email addresses. According to WhoisProxy:

"The registrant can be contacted through the encrypted email address only. Mails sent to the physical address will be rejected or destroyed, callers will be redirected [to the WhoisProxy website]."

Consistent with the ease-of-use theme of the other Google Domain features, the service makes it very convenient to protect the privacy of domain registration details.

The Advanced Tab

The Advanced area of the dashboard is designed for the more technical users of Google Domains. For instance, the person can configure the domain to use custom name servers, rather than those provided by Google:

If using Google's name servers, the person can add up to 100 custom resource records:

Google Domains also makes it easy to define DNS records for users of the company's App Engine and Google Apps services. These synthetic records form "an automatically-generated collection of resource records related to a specific feature."

Overall, Google Domains presents the domain and DNS management features most people need in a manner that simplifies the burden of managing these settings. This new service seems to be designed to encourage more small businesses to establish an online presence, which grows the market for Google's advertising and other businesses. The focus on SMBs is consistent with the Google Domains announcement being made on the company's Google+ Your Business page. That announcement explained:

"So as we explore ways to help small businesses succeed online [...], we hought it made sense to look more closely at the starting point of every business’s online presence - a website. And that starts with a domain name."

Google Domains is in invite-only beta at the time of this writing; however, even in its current state the service use useful and appears bug free. As it matures, it will provide a useful resource to smaller companies and encourage other domain registrars to innovate to remain competitive. If you'd like to see what is involved in transferring an existing domain to Google Domains from one of those registrars, see my post First Look at Google's New Domain Registrar.

-- Lenny Zeltser

[lennyzeltser]

Morse-Style Tap Codes for Mobile Authentication

Authenticating legitimate users of mobile devices in a manner that is both reliable and convenient is hard, which is why companies continue to experiment with approaches that try balance security and convenience. A freshly-minted Coin app asks users to authenticate by touching the phone's screen to enter a sequence of short and long taps in the style of Morse code.

When starting the Coin app for the first time, the user needs to login using the traditional username/password pair. After that, the app asks the person to select a private Tap Code, which is "a Morse code-like sequence that you'll use each time you open the Coin app. The Tap Code is a series of 6 taps, short or long."

Anticipating the need to train people how to properly specify a Tap Code, the app requires users to practice entering a Tap Code before selecting their own, requesting that they "get a feel for long and short taps by practicing the pattern above." Sadly, I failed several practice tests before eventually tapping in the right sequence. Tapping short and long codes is harder than you might think!

When the Coin app launches, it prompts the user to enter the "six element tap code." The general approach of providing a quick way to authenticate to the app in lieu of typing the full password is present in many financial and other applications. However, those apps generally ask the user to enter a numeric PIN, rather than to tap a Morse-style code.

As a user of the Coin app, I struggled with the taps. Perhaps my thumb lacked the dexterity, or maybe my brain was intentionally sabotaging the experience to avoid the concentration that remembering and entering my tap sequence requires. Also, I kept forgetting my Tap Code.

When I failed to enter the correct sequence three times in a row, the app prompted for a full password as a way of deterring Tap Code guessing.

I applaud Coin's attempt to provide an alternative to traditional PIN-based shortcut authentication approaches. Unfortunately, I find that the uniqueness of its Tap Code method negatively impacts the user experience, at least in the company's present implementation of the mechanism. Though not as sexy, numeric PINs are familiar to people and work reasonably well. Authentication approaches based on gestures might be more familiar to users, too, especially on Android devices. 

If innovative approaches to mobile authentication is interesting to you, check out these articles:

Creative Options for Better Authentication of Mobile Phone Users

Beyond Logins: Continuous and Seamless User Authentication

Potential Security Applications of the iPhone 5S M7 Motion Coprocessor

-- Lenny Zeltser

[lennyzeltser]

First Look at Google's New Domain Registrar

Without much fanfare, Google entered the domain registration business by announcing the private beta of its new Google Domains service in June 2014. Once invited to join the program, you can use Google Domains to purchase new domains and transfer existing ones at $12 per year. The service offers private domain registration, which lets you to keep contact details private, without additional fees.

I transferred one of my existing domains from GoDaddy to Google Domains to get a feel for the experience and to start experimenting with the service. The process was relatively painless and smooth, with Google's browser-based tool stepping me through the necessary steps. Here's what it was like.

Preparing the Domain for Transfer

After I entered the name of my domain into the tool, Google Domains presented an outline of 4 steps that I needed to follow to prepare the domain for transfer:

I was surprised by the need to turn off the private aspect of the domain at the originating registrar (step "b"). After submitting the transfer request, the transaction will take several days to complete, which means the contact details will be temporarily exposed. This was, perhaps, the only unpleasant aspect of the transfer process.

Importing Domain Settings

Once the preparatory steps above have been completed, Google Domains offers the opportunity to automatically transfer existing domain records and related settings:

It's a good idea to click the "Review or edit resource records" button to tweak the settings, in which case the tool presents the following screen:

Google Domains allows you to add, edit and delete domain records. In addition, it offers a convenient way to define "synthetic records" for automatically configuring the domain to use Google App Engine or Google Apps you can also configure URL forwarding.

Keeping Domain Contacts Private

Closer to the end of the transfer application, Google Domains offers to conceal contact details that would normally be visible to the public via Whois:

Google Domain's inclusion of the private registration option without additional fees helps this service stand out from the competition. This feature might push the established domain registrars to follow suit or at least lower their pricing to remain competitive.

Completing the Domain Transfer Process

Once the application has been submitted, Google Domains emails the administrative contact presently on file for the domain to approve the request:

"We have received your request to transfer your domain to Google Domains. We'll need you to confirm that you'd like to proceed. Please take a moment to read the following instructions from ICANN, the nonprofit organization that oversees the use of Internet domains."

The email message includes a "Confirm Transfer" link. If the recipient doesn't click it within 5 days, the transfer will be aborted. Note that this message is in addition to the one that the originating registrar might send out. Once the transfer has been approved, Google Domains presents the following message on its Incoming Transfers page:

"We have asked your current registrar to release redacted.com to us. The transfer of your domain will complete immediately after your registrar releases it to us. However, your registrar may take up to five days (redacted) to process your transfer request."

What happens next? Take a look at my follow up article A Closer Look at the Google Domains Registrar. In the meantime, you can learn more about Google Domains by reviewing its Help section of Google's support website, which is available to everyone. If this piques your curiosity, you can request an invite to the beta program from Google by filling out a sadly unofficial-looking form. (Watch out, I bet scammers will start a phishing campaign around this sooner or later.)

-- Lenny Zeltser

[lennyzeltser]

Internet Noise and Malicious Requests to a New Web Server

I set up a brand new web server to see what type of connections it will receive. Since the server had no "production" purpose, all attempts to access it could be considered suspicious at best. Such requests are associated with scans, probes and other malicious activities that tend to blend into the background of web traffic. Here's what I observed.

An Internet-Mapping Experiment by PDR Labs

The web server began receiving the following unexpected HTTP requests once or twice per day:

HEAD / HTTP/1.1 Accept-Encoding: identity User-Agent: Cloud mapping experiment. Contact [email protected]

These connection attempts stood out because the HTTP requests were missing the "Accept" header and included the server's IP address, rather than hostname in the "Host:" field (not shown here). This tends to occur with bots.

Searching the web for "pdrlabs.net" led to www.pdrlabs.net, which contained a bare-bones page stating:

"We are conducting an ongoing experiment to map the Internet in its entirety. Our crawling is not malicious in intent and does nothing more than attempt the connection; no further information is mined."

These connections originated from different IP addresses, all of which were hosted at Amazon Elastic Compute Cloud (EC2). These included 75.101.197.159, 23.20.195.127, 23.22.8.3, 54.196.118.77, 23.22.13.205, 54.90.93.247, 54.87.77.99, 54.89.82.208, 107.22.50.242, 54.87.77.99, 54.89.82.208 and 107.22.50.242.

I didn't find any other suspicious connections associated with these IPs so I am not too worried about this activity. Still, what are PDR Labs up to and who is behind this project? Perhaps some day these secrets will be revealed to us.

Scans for Open Web Proxies

Another set of anomalous requests, unrelated to the connections above, looked like this:

GET http:// hotel.qunar. com/render/hoteldiv.jsp?&__jscallback=XQScript_4 HTTP/1.1 Accept-Encoding: gzip,deflate,sdch Referer: http:// hotel.qunar. com/ User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.114 Safari/537.36 Host: hotel.qunar.com

These requests stood out because the client attempted to retrieve a page from hotel.qunar.com, which was unrelated to my web server. Such connections, regardless the third-party URL they attempt to retrieve, tend to be scans for open proxies. If my web server was configured as an open proxy, it would retrieve the requested URL and present it to the client.

According to the Httpd Wiki, such open proxies could be misused to "manipulate pay-per-click ad systems, to add comment or link-spam to someone else's site, or just to do something nasty without being detected." Open proxies are also used to bypass corporate or government access restrictions.

I observed these connections roughly every other day. They originated from different IP addresses, all of which were registered in China. These included 114.232.150.176, 114.231.131.97 and 115.29.146.211.

Why do these scans use the hotel.qunar.com URL for its tests? I doubt the person behind them is intent on finding a way to make anonymous hotel reservations through this site. Any URL would do. However, hotel.qunar.com is specifically mentioned as an example in the onlineProxy.js tool:

/** * a proxy with totoro, to test online page. * step1: totoro -R http:// 10.211.55. 2:9998/proxy?target=hotel.qunar.com -a mocha step2: this proxy, request the target url, add mocha script and case to response step3: response the added html to totoro server * */

This tool is a module for Totoro, which is a free, "simple and stable cross-browser testing tool." Perhaps the scanner was implemented by using Totoro and onlineProxy.js, with the person behind it using the example above when launching the scans. Another mystery of the web unraveled!

This wasn't the only set of proxy connections that the server encountered. Another probe came from 122.226.223.69, which attempted to retrieve:

GET http:// www. k2proxy. com//hello.html

The connecting client specified the following User-Agent string: "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/6.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E)". The connection came from the system that, according to Spamhous CBL was infected with Torpig malware. The K2 proxy website, authored in Chinese, seems to be an effort to locate and document open proxies and appears to be maintained by [email protected].

Yet another proxy probe came from 63.246.129.40, an IP address classified as being potentially malicious by Project Honey Pot:

GET http://www.baidu.com/ HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E)

A couple of seconds before submitting this HTTP request, the attacking system also attempted to connect to the server on TCP ports 135 and 1433, both of which are associated with Microsoft SQL Server activity.

Probes from Potentially-Infected Systems

Let's move to another unusual set of connections Approximately every other day the web server received the following request:

HEAD / HTTP/1.0

These connections stood out because they were missing all other headers typically present in an HTTP connection. The requests came from different IPs, which included 162.242.146.223, 184.173.172.150, 103.3.189.14 and 210.17.38.217. These IPs were located in the US, Japan and Taiwan.

Several of these IP addresses were flagged on the Spamhous Composite Blocking List (CBL) as being associated with infected hosts. According to CBL, some of these systems were running Gameover Zeus and Hesperbot malware. Perhaps these bots were directed to scan the web looking for web servers to infect—I'm not sure, but if you have promising theories, please let me know.

Scans for phpMyAdmin Vulnerabilities

The web server also saw several requests associated with User-Agent "ZmEu". They looked like this:

GET /MyAdmin/scripts/setup.php HTTP/1.1 Accept: */* Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent: ZmEu

These connections stood out because they attempted to access PHP pages not present on the server and specified an unusual User-Agent. Also, they provided a "Host:" header (not shown here) that specified the web server's IP address, rather than its hostname.

These probes came from 95.111.68.120 in Bulgaria. According to Spamhous CBL, this IP was associated with Gameover Zeus malware. The infected system attempted to access pages used by phpMyAdmin, a popular MySQL administration tool. The scanner looked for vulnerabilities in phpMyAdmin that it could exploit.

According to Phil Riesch, User-Agent "ZmEu" is used by "a security tool used for discovering security holes" in phpMyAdmin. Older web probes associated with this tool included a reference to its potential origin and pointed to a now-defunct website:

Made by ZmEu @ WhiteHat Team - www. whitehat.ro

Someone seemed to be using a bot network to scan for vulnerable phpMyAdmin systems, though the reference to "ZmEu" could have been added regardless of whether that was the tool that the attacker actually employed.

This completes the overview of the suspicious activities I observed recently on a brand new web server that should not have seen any connections. Such probes are easy to notice on a non-production system like that. On most real servers, they probably go unnoticed, blending into the noise that comprises today's Internet traffic.

-- Lenny Zeltser

[lennyzeltser]

Attackers Rely on Social Engineering to Activate Macros in Malicious Office Documents

Microsoft Office documents offer a convenient way to infect systems through the use of macros. However, the attacker needs to persuade victims to enable macros after opening the booby trapped file. Social engineering is an important aspect of these attack strategies.

The defense mechanism that such malware authors need to bypass is typically the yellow security warning that Microsoft Office applications display to explain that "Macros have been disabled." How would you persuade the document's recipient to click the enticingly-named Enable Content?

Misrepresent the Meaning of the Security Warning

One approach attackers have employed to deal with the warning involves convincing victims that the security message indicates that the document has been somehow secured to safeguard its contents. This is a clever way of using the pretext of security, which most users don't understand, to persuade individuals. Kimberly's post on the use of macro viruses presents several real-world examples that utilize this approach; these documents "explained" to victims:

"Private text has been hidden to caution against unauthorized person. Click Enable Content"

"Please enable macros to view secure document"

"This is a locked document please click option to enable content"

As convincing as such text can be for some people, sometimes victims might require additional guidance to the activate macros.

Provide Detailed Instructions for Enabling Macros

Recognizing that some of the victims might not be tech-savvy, adversaries have been known to offer step-by-step instructions for enabling macros. This helps address scenario where the person's Microsoft Office is globally configured to disable all macros.

For instance, take the real-world malicious Word document described by Dmitry Bestuzhev. The file was called DIAN_caso-5415.doc. When victims opened this file, they saw a nicely-formatted message that the adversary embedded in the document, explaining why the content could not be shown. The text is in Spanish, because this file was sent to recipients in Spanish-speaking countries:

The text advised that to view the document's contents, the person need to enable macros. The malicious document included step-by-step instructions for accomplishing this. The instructions accommodated multiple versions of Microsoft Word and Excel and include detailed steps and screenshots like this:

If the Approach Works, Keep Using It

According to Dmitry, the document above was sent to victims in Colombia under the guise of a tax fraud notice. Interestingly, another malicious document that incorporated the same macro-enabling instructions was observed a month later by UNAM - CERT in Mexico. In that case, the context was a bank withdrawal notification. The file was called RETIRO-COMPRA_29882.doc.

As I explained in an earlier post about SRP streams, the analysis of SRP streams in both files reinforces the notion that these documents were probably used by the same adversary to pursue victims in multiple Spanish-speaking countries, including Colombia, Mexico and Chile. In each case, the document was crafted to social-engineer the recipient to enable macros and allow the malicious code to infect the system.

If you're like to take a closer look at these two malicious documents, you can download them from the Malwr repository links I provided above for each file. Just be careful to conduct your examination on a properly-isolated laboratory system.

-- Lenny Zeltser

P.S. For those who like this stuff, let it be know that I'll be teaching an online malware analysis course at SANS Institute starting July.

[lennyzeltser]

New Release of REMnux Linux Distro for Malware Analysis

It's my pleasure to announce the availability of version 5 of REMnux, a Linux distribution popular among malware analysts. The new release adds lots of exciting free tools for examining malicious software. It also updates many of the utilities that have already been present in the distro. Here is a listing of the tools added to REMnux v5.

Examine Browser Malware

Thug: Honeyclient for investigating suspicious websites

mitproxy: Intercept, modify, replay and save HTTP and HTTPS traffic

Automater: Look up URL/Domain, IP and MD5 hash details

Java Cache IDX Parser: Examine Java IDX files

JSDetox: Decode obfuscated JavaScript

ExtractScripts: Extract JavaScript scripts from an HTML file

Examine Document Files

AnalyzePDF: Examine a malicious PDF file

Pdfobjflow: Visualize the output from pdf-parser

officeparser: Extract embedded files and macros from office documents

Extract and Decode Artifacts

unXOR: Guess a XOR key via known-plaintext attacks

XORStrings: Locate and decode XOR-obfuscated strings

ex_pe_xor: Carve out single-byte XOR encoded executables from files

Balbuzard: Extract and decode suspicious patterns from malicious files

Foremost: Carve contents of files

Scalpel: Carve contents of files

strdeobj: Extract and decode strings defined as arrays

Handle Network Interactions

tcpick: Sniffer that reassembles TCP streams

prettyping.sh: Ping a host while looking pretty

Process Multiple Samples

Maltrieve: Retrieve malware from malicious sites

Ragpicker: Malware crawler with analysis and reporting functionality

Viper: Store, classify and investigate suspicious binary files

Examine File Properties and Contents

YaraGenerator: Generate Yara rules for designated files

Yara Editor: Create and modify Yara rules

IOCextractor: Extract indicators of compromise from a text report file

Hash Identifier: Identify the types of a hash being examined

nsrllookup: Look up file hashes on an NSRL database server

totalhash: Look up a suspicious file hash in the totalhash.com database

Investigate Linux Malware

Sysdig: Track and examine local system activities on a Linux system

Unhide: Find local hidden processes or connections on a Linux system

Bokken: Interactive static malware analysis tool

Vivisect: Statically examine and emulate the execution of binary files

Evan's Debugger (EDB): Interactively disassemble and debug ELF binary files.

Other Tools

wxHexEditor: Graphical hex editor

TotalRecall: Run popular Volatility commands and generate a report

WIPSTER Installer: Install web interface for MASTIFF and other tools

RATDecoders: Extract and decode configuration details from common RAT samples

In addition to the newly-installed tools above, REMnux v5 includes updates to core OS components as well as numerous other utilities present in earlier versions of the distro, including Volatility, peepdf, Network Miner, OfficeMalScanner, MASTIFF, ProcDOT and others. For a full listing of REMnux v5 tools, see the XLSX spreadsheet or the XMind mind map.

A huge thank you to David Westcott, who set up and upgraded many of the packages available as part of REMnux v5, thoroughly tested them and help with the documentation. I'm also very grateful to the beta testers who reviewed early versions of this release. As always, thank you to the developers of the malware analysis tools that I am able to include as part of REMnux.

You can download the new version from REMnux.org. It's available as a virtual appliance in VMware and OVF/OVA formats, as well as an ISO image of a live CD.

-- Lenny Zeltser

P.S. I expect the next major REMnux release to be based on a Long Term Support (LTS) version of Ubuntu and employ a modular package architecture to support incremental updates.

[lennyzeltser]

Scammers in Action: Domain Names and Family Resettlement to Australia

"You Have Been Selected for Family Resettlement to Australia," began the email that included the seal of the Embassy of Australia. "You are among the list of nominated for 2014 resettlement visa to Australia." The signature line claimed that the message had been sent by Hon Thomas Smith and came from "Australia Immigration Section <[email protected]>."

This was a scam, of course.

"What do I need to do?" I responded, curious what might come next. Hon Thomas Smith responded within a few hours, this time from [email protected].

Request for Personal Information

The message attempted to mimic the letterhead of the Australian Department of Immigration and Citizenship and welcomed me "to Australia visa office." It explained that:

"every year certain number of people are selected through our electronic ballot system for resettlement by Australia Government as part of support to Countries regarded as war zone area."

The miscreant requested that I submit a scanned copy of my travel passport, a recent photo and my phone number. In addition, I was to email a scanned white paper sheet with my fingerprints on it.

The email message included a PDF attachment that claimed to be Visa Form File/10121L-2014, which requested details such as date of birth, mother's name and address. The PDF file didn't have an exploit, as far as I can tell, and was merely designed as a place where the scammer's target could conveniently provide personal information.

The scammer was pursuing this information probably with the goal of performing identity theft. Also, future interactions with the scammer would probably include a request for money to process the bogus application.

Free Sub-Domain Registration

The domain from which the scammer sent the application, immigrationsection.com.au.pn, is considered malicious by some security companies, according to VirusTotal. It redirects webs visitors to www-dot-popnic-dot-com, which some sources consider malicious.

Popnic-dot-com seems to be a front for Unionic-dot-com, which provides free domain registration, email forwarding, web hosting, URL forwarding, etc. under unusual TLDs such as .tc, .mn, .ms and others. More specifically, it offers registration under second-level domains that resemble TLDs assigned to major countries such as .uk.pn, .us.pn, .ca.pn, .au.pn, and others. No wonder it's attractive to scammers, who want to get a domain that at a first glance seems legitimate.

With the increasing variety of TLDs available, scammers will have an easier job selecting domain names that catch the victims' attention or evoke trust. Regardless of the domain used by the sender of the email message, if the offer sounds too good to be true and involves supplying sensitive information, it's probably a scam.

-- Lenny Zeltser

[lennyzeltser]

A Series of Introductory Malware Analysis Webcasts

If you are looking to get started with malware analysis, tune into the webcast series I recorded to illustrate key tools and techniques for examining malicious software:

Malware Analysis Essentials using REMnux: See some of my favorite REMnux tools in action for statically examining malicious Windows executables and other files.

Introduction to Malware Analysis: Learn the two-phased approach to reversing malware, including an example of examining its code using a debugger.

Introduction to Behavioral Analysis of Malicious Software: Take a closer look at the steps needed to analyze the behavior of a suspicious Windows executable, using a backdoor program as a practical example.

What's New in REMnux v4 for Malware Analysis: Get an overview of several handy tools added to REMnux as part of the version 4 release.

How to Run Malware Analysis Apps as Docker Containers: Get started with Docker application containers in the context of malware analysis and a new REMnux initiative.

Since the best way to learn malware analysis involves practice, I am happy to provide you with malware samples from each of these webcasts. Just send me an email after you've watched the webcast and confirm that you will be taking precautions to properly isolate your laboratory environment.

-- Lenny Zeltser

[lennyzeltser]

Mastering 4 Stages of Malware Analysis

Examining malicious software involves a variety of tasks, some simpler than others. These efforts can be grouped into stages based on the nature of the associated malware analysis techniques. Layered on top of each other, these stages form a pyramid that grows upwards in complexity. The closer you get to the top, the more burdensome the effort and the less common the skill set.

Fully-Automated Analysis

The easiest way to assess the nature of a suspicious file is to scan it using fully-automated tools, some of which are available as commercial products and some as free ones. These utilities are designed to quickly assess what the specimen might do if it ran on a system. They typically produce reports with details such as the registry keys used by the malicious program, its mutex values, file activity, network traffic, etc.

Fully-automated tools usually don’t provide as much insight as a human analyst would obtain when examining the specimen in a more manual fashion. However, they contribute to the incident response process by rapidly handling vast amounts of malware, allowing the analyst (whose time is relatively expensive) to focus on the cases that truly require a human’s attention.

For a listing of free services and tools that can perform automated analysis, see my lists of Toolkits for Automating Malware Analysis and Automated Malware Analysis Services.

Static Properties Analysis

An analyst interested in taking a closer look at the suspicious file might proceed by examining its static properties. Such details can be obtained relatively quickly, because they don't involve running the potentially-malicious program. Static properties include the strings embedded into the file, header details, hashes, embedded resources, packer signatures, meta data such as the creation date, etc.

Looking at static properties can sometimes be sufficient for defining basic indicators of compromise. This process also helps determine whether the analyst should take closer look at the specimen using more comprehensive techniques and where to focus the subsequent steps. Analyzing static properties is useful as part of the incident triage effort.

VirusTotal is an example of an excellent online tool whose output includes the file's static properties. For a look at some free utilities you can run locally in your lab, see my posts Analyzing Static Properties of Suspicious Files on Windows and Examining XOR Obfuscation for Malware Analysis.

Interactive Behavior Analysis

After using automated tools and examining static properties of the file, as well as taking into account the overall context of the investigation, the analyst might decide to take a closer look at the specimen. This often entails infecting an isolated laboratory system with the malicious program to observe its behavior.

Behavioral analysis involves examining how sample runs in the lab to understand its registry, file system, process and network activities. Understanding how the program uses memory (e.g., performing memory forensics) can bring additional insights. This malware analysis stage is especially fruitful when the researcher interacts with the malicious program, rather than passively observing the specimen.

The analyst might observe that the specimen attempts to connect to a particular host, which is not accessible in the isolated lab. The researcher could mimic the system in the lab and repeat the experiment to see what the malicious program would do after it is able to connect. for example, if the specimen uses the host as a command and control (C2) server, the analyst may be able to learn about specimen by simulating the attacker's C2 activities. This approach to molding the lab to evoke additional behavioral characteristics applies to files, registry keys and other dependencies that the specimen might have.

Being able to exercise this level of control over the specimen in a properly-orchestrated lab is what differentiates this stage from fully-automated analysis tasks. Interacting with malware in creative ways is more time-consuming and complicated than running fully-automated tools. It generally requires more skills than performing the earlier tasks in the pyramid.

For additional insights related to interactive behavior analysis, see my post Virtualized Network Isolation for a Malware Analysis Lab, a my recorded webcast Intro to Behavioral Analysis of Malicious Software and Part 3 of Jake Williams' Tips on Malware Analysis and Reverse-Engineering.

Manual Code Reversing

Reverse-engineering the code that comprises the specimen can add valuable insights to the findings available after completing interactive behavior analysis. Some characteristics of the specimen are simply impractical to exercise and examine without examining the code. Insights that only manual code reversing can provide include:

Decoding encrypted data stored or transferred by the sample;

Determining the logic of the malicious program's domain generation algorithm;

Understanding other capabilities of the sample that didn't exhibit themselves during behavior analysis.

Manual code reversing involves the use of a disassembler and a debugger, which could be aided by a decompiler and a variety of plugins and specialized tools that automate some aspects of these efforts. Memory forensics can assist at this stage of the pyramid as well.

Reversing code can take a lot of time and requires a skill set that is relatively rare. For this reason, many malware investigations don't dig into the code. However, knowing how to perform at least some code reversing steps greatly increases the analyst's view into the nature of the malicious program in a comp

To get a sense for basic aspects of code-level reverse engineering in the context of other malware analysis stages, tune into my recorded webcast Introduction to Malware Analysis. For a closer look at manual code reversing, read Dennis Yurichev's e-book Reverse Engineering for Beginners.

Combining Malware Analysis Stages

The process of examining malicious software involves several stages, which could be listed in the order of increasing complexity and represented as a pyramid. However, viewing these stages as discrete and sequential steps over-simplifies the steps malware analysis process. In most cases, different types of analysis tasks are intertwined, with the insights gathered in one stage informing efforts conducted in another. Perhaps the stages could be represented by a "wash, rinse, repeat" cycle, that could only be interrupted when the analyst runs out of time.

If you're interested in this topic, check out the malware analysis course I teach at SANS Institute.

-- Lenny Zeltser

P.S. The pyramid presented in this post is based on a similar diagram by Alissa Torres (@sibertor). Also, Andrs Velzquez (@cibercrimen) translated this article into Spanish!

[lennyzeltser]

I was one of the guests at the recent Forensic Lunch discussion, led by David Cowen. Here's the video recording of the conversation. I talked about how I found myself doing malware analysis and some of the challenges of migrating my malware lab to Windows 8.

-- Lenny Zeltser

[lennyzeltser]

Rock-Paper-Scissors Game for InfoSec Pros

[lennyzeltser]

Making Sure Your Security Advice and Decisions Are Relevant

Perhaps the most challenging and exciting aspect of information security is the need to account for business context when making decisions. One way to do this is to determine the unique strengths of the company—its competitive advantages—so you can frame risk conversations accordingly.

Economic Moats to Safeguard the Business

Gunnar Peterson discussed aspects of this concept using the notion of economic moats. According to Morningstar, an economic moat "refers to how likely a company is to keep competitors at bay for an extended period." This term is similar to what others might call a sustainable competitive advantage. Just like a moat helps safeguard the castle from attackers, an economic moat contributes towards protecting the business from competitors.

Companies have different economic moats and those without a sustainable competitive advantage tend to stagnate. Gunnar outlined several types of moats highlighted by Morningstar, including: Low operational costs, intangible assets (strong brand, patents, etc.), high switching costs (customers tend to stay), etc.

Relate Security Risks to Economic Moats

What are your organization's economic moats? If you don't know what capabilities help the company protect or expand its market share, find out. This knowledge will help you make informed security decisions and will allow you to be a more persuasive participant in risk discussions. As Gunnar pointed out, "the two most important things in infosec are identifying what kind of moat your business has and then defending that moat."

Information security professionals often complain that executives ignore their advice. There could be many reasons for this. One explanation might be that you are presenting your concerns or recommendations in the wrong business context. You're more likely to be heard if you relate the risks to an economic moat relevant to your company.

A common approach to emphasizing the importance of information security is based on the notion that a data breach can tarnish the company's brand. In many cases, the reality shows that the business doesn't actually suffer in the long term, and in some cases the attention brought by the breach could actually help the company. However, even if the company might suffer in the short term, an argument based on brand tarnishing could fall on deaf ears if the organization doesn't consider its brand a competitive advantage.

Security in Support of Sustainable Competitive Advantages

A company whose economic moat is its brand, will spend considerable efforts to protect its brand equity. For organizations like that, the brand-tarnishing argument might be effective and could be a good way to justify security funding. However, companies that have other moats, won't care that much about safeguarding their brands.

For instance, consider a firm whose economic moat is tied to low costs due to its operational expertise and supplier relationships. A good context for making security decisions in this organization might be its efforts to protect proprietary details related to internal and supplier logistics. Threats to this moat will likely capture executives' attention.

Another organization whose moat is its proprietary intellectual property will want to hear your thoughts on protecting such trade secrets. Alternatively, if a firm sees its time-to-market as a competitive advantage, it will want to know about the security risks that could slow it down and prevent the next timely release of its product.

An economic moat might protect the company from competitors, but it could be eroded by internal factors such as a security breach. Understand your company's economic moats. Use them to frame security decisions and to ensure that your infosec advice are relevant to the company's business objectives and strategies.

-- Lenny Zeltser

[lennyzeltser]

Malware: Whom or What Are We Fighting?

When characterizing ill-effects of malicious software, it's too easy to focus on malware itself, forgetting that behind this tool are people that create, use and benefit from it. The best way to understand the threat of malware is to consider it within the larger ecosystem of computer fraud, espionage and other crime.

A Tip of a Spear

I define malware as code that is used to perform malicious actions. This implies that whether a program is malicious depends not so much on its capabilities but, instead, on how the attacker uses it.

Sometimes malware is compared to a tip of a spear—an analogy that rings true in many ways, because it reminds us that there is a person on the other end of the spear. This implies that information security professionals aren't fighting malware per se. Instead, our efforts contribute towards defending against individuals, companies and countries that use malware to achieve their objectives.

Understanding the Context

Without the work of personnel that handles technical aspects of malware infections, the malware-empowered threat actors would be unencumbered. Yet, these tactical tasks need to be informed by a strategic perspective on the motivations and operations of the individuals that create, distribute and profit from malware.

To deal with malware-enabled threats, organizations should know how to detect, contain and eradicate infections, but we cannot stop there. We also need to also understand the larger context of the incident. We won't be able to accomplish this until we can see beyond the malicious tools to understand the perspective of our adversaries. The who is no less important than the what.

-- Lenny Zeltser

[lennyzeltser]

Participating in the Eternal Cycle of Cybersecurity

When engaged in a fight, it's natural to ask yourself whether you are winning or losing. However, in the context of cybersecurity, this question might not make sense, because it presupposes that the state of winning exists.

Maintaining the Equilibrium

Every day, new people and transactions appear online, making the digital world more attractive to criminals. Miscreants fund malicious software and attack operations, so they can achieve financial, political and other objectives. Security practitioners respond to evolving online threats; the attackers adjust their tactics, the defenders tweak their approaches, attackers regroup, and so on and so forth.

Defenders sometimes feel that the attackers are innovating at a pace that's outpacing our ability to defend sensitive data and computer infrastructure. Such observations tend to be based on emotions and subjective observations and often lead to questions about which party is winning the fight. Defining our objectives in terms of winning or losing might not be practical.

The Eternal and Vicious Cycle

My perspective on the dynamics between cyber attackers and defenders aligns with the ecological metaphor that Lamont Wood described in an article Malware: War Without End. He referred to it as "an eternal cycle between prey and predator, and the goal is not victory but equilibrium." It's unlikely that this cycle will end and that either party will "win."

When I spoke with Lamont, I suggested that attackers work to bypass our defenses and the defenders respond as part of the cycle. If attackers get in too easily, they are spending too much on their efforts. If we are blocking 100% of the attacks, we are probably spending too much on defense.

The digital ecosystem as a whole continues to thrive, because it benefits its legitimate users and criminals that act as parasites within the system. However, individual participants in this ecosystem could find themselves at a disadvantage and suffer losses. Being complacent is  risky for a given party, because it must constantly apply energy to maintain the equilibrium.

If our goal is to "win" the fight against cyber criminals, we don't stand a chance, in part because there will always be more threats to combat. It might be more useful to define our objectives in terms of maintaining an equilibrium between the defenders and the attackers. This way, we can help our organizations excel in the contaminated world of the Internet.

-- Lenny Zeltser