In a previous blog post, we covered why poor user experience is one major pain point of Chief Medical Officers (CMO) that are responsible for ensuring healthcare professionals aren’t taken away from their primary mission of patient care, yet can still securely access patient data, validate their identity and e-prescribe with multi-factor authentication.

In this blog post, we’ll cover a common concern of IT operations leaders or IT VPs and directors, often the head of infrastructure, networking and architecture. They’re responsible for managing internal resources and deploying technology projects in their organization’s environment.

Feelin’ the Pain

Your access security solution should be comprehensive in its coverage, but not overly complex or difficult to manage. These are some of the challenges you face in developing and deploying security:

Overworked Support Teams - Taking on a lot of new IT projects that require time and resources to integrate, deploy and provision users can overload your IT, compliance and help desk teams, reducing productivity across your organization.

Juggling Vendors - Too many security solutions and vendors to do all of the different jobs you need done - from authentication to endpoint security - can result in many different administrative user interfaces and data spread across different solutions.

Complex Access Control Management - Cloud and mobile applications come with their own set of access management controls, introducing complexity to your team's management workload.

Clinician Circumvention - If your security tools aren’t easy to use or get in the way of patient care, clinicians may find ways to bypass their implementation that may result in a less secure environment, applications and/or data.

Easing the Pain

Simplify access management with a security solution that works as a force multiplier, without the additional burden on your IT teams.

Rapid Solution Deployment - Duo’s solution is designed to work natively with out-of-the-box integrations that allow your IT teams to roll out the service within hours and days, reducing the burden and need for a large support or tech team to implement the solution.

Reduce Time to Security - With flexible integration options including support for SAML, RADIUS, APIs and more, Duo’s solution allows healthcare administrators to quickly secure access to all cloud and on-premises applications.

Intuitive & Scalable Enrollment - Reduce your help desk team’s workload by choosing a multi-factor authentication solution that puts your users first. A variety of enrollment options empowers users to sign up with Duo easily, or admins to automatically set up a large amount of users. Duo's self-service portal allows users to manage their own devices, choose preferred login methods, change device names and more without IT assistance.

Flexible Authentication Options - With different options for every user scenario, your help desk teams can spend less time solving for edge use cases. Duo’s wide variety of authentication options provide offline ways to authenticate for nurses without cell service on the hospital floor, or traveling professionals that may not have internet access.

Learn more about Duo for Healthcare, and check out An Enterprise Healthcare CISO's Journey to Zero Trust to see how one of the largest healthcare systems in the nation deployed Duo Beyond to secure access to patient data by over 20,000 users and 60,000 devices, enabling clinicians to access patient data from anywhere, using any device.

Using Duo, the company’s security and IT team discovered thousands of net-new personal devices accessing applications with patient data - that is, an additional 30,000 mobile devices than they previously thought accessed their environment. 

As Chief Medical Officer (CMO), your primary mission is to ensure doctors, clinicians and other key healthcare professionals aren't taken away from their primary mission of patient care.

But balancing healthcare organizational productivity with the security and compliance of safeguarding patient data can be challenging.

Enforcing a consistent set of security policies for all of your users means designing a streamlined workflow that doesn't get in the way of healthcare clinicians. And usability is security, as we say at Duo - meaning, you can't have one without the other.

Feelin' the Pain

Pairing security and users means you need to address the following pain points:

Impact to Clinician Workflow & Productivity - Requiring additional steps and greater complexity to how clinicians log into applications and systems can negatively affect productivity, multiplying user frustration while slowing down patient care.

User Privacy Concerns - Existing mobile device management (MDM) tools have many capabilities that users aren't wild about - including complete visibility into web traffic, browsing activity, personal data, user location and more.

Electronic Prescribing of Controlled Substances (EPCS) - This workflow can be time-consuming and frustrating for physicians, as there are security regulations on the process that are governed by the Drug Enforcement Administration (DEA) to confirm the identity of providers, as well as identity verification when they’re signing a prescription. They often require the use of a token to complete two-factor authentication.

Enforced Security Policies - Requiring healthcare professionals to verify their identity every time they log in, while restricting access to dedicated devices as they work can get in the way of their every day tasks as they need to remain mobile, log in to many different systems, and navigate the complexity of different security solutions.

Easing the Pain

Instead of many disparate solutions, seek out one that can consolidate and simplify security, and will work for your diverse user base and their different user scenarios.

Improve Productivity - With Duo's one-tap two-factor authentication, clinicians can log in securely by approving a push notification sent to their smartphone by Duo Mobile, our authenticator app. Or, they can choose from several authentication methods for every type of user scenario (depending on the type of application being protected, as well as regulations that need to be met) - there are also offline options for those without internet or cell service.

Alleviate Privacy Concerns - Duo Mobile verifies the trust of your users' devices, without invading their privacy. Our app doesn't have access to any user data on devices - it cannot see information about other apps on their device, nor track their location. But it can assess the security hygiene of their devices and check for a device certificate for managed devices.

Streamline EPCS Workflows - Duo makes enrolling in 2FA for EPCS easy for clinicians - our Level of Assurance 3 (LOA3) remote identity proofing solution also provides a simple, one-tap authentication experience (no tokens required) that doesn't get in their way of e-prescribing, but is audited by a third party to ensure it is secure enough to meet DEA compliance requirements. Learn more about how Duo for EPCS works.

Effective Security Policies - A large part of security effectiveness lies in the usability of its implementation. With Duo, IT administrators can leverage adaptive authentication and policy enforcement behind the scenes at a granular level, without adding more friction to their users' day to day.

And of course you can learn more. Here’s where:

• Duo for Healthcare Security
  
• Duo for Epic EHR
  
• A Healthcare CISO’s Journey to Zero Trust (eBook)
  
• Healthcare Information Security Guide (eBook)
  
• Securing the Physician Mobile Experience (blog post)
  

In my earlier post, we covered some lessons the security community has learned about human behavior in the last several decades. Here’s a quick recap of the high-level lessons:

• Users expect security without having to work for it -- not due to laziness, but because it’s an expected feature of the service product.
  
• Users engage best with a relatively easy step during a period of already-expected friction, e.g. setting up a new device.
  
• Users expect security to be inherent in the device, regardless of what they’ve actually configured.
  
• In an unexpected period of friction of a product (oAuth, permissions, etc,), user engagement will be lower than other times. User education and engagement is crucial at this time.
  

So now that we’ve learned these lessons, how is the security community planning on integrating these lessons going forward? What new things are both technologically sound and relatively frictionless for the user?

Passwordless Authentication & WebAuthn

Universal 2nd Factor (U2F) was popular in part because it was easy, but it also used the battle-tested security of public key cryptography. If you’re unfamiliar with the mechanics of public key cryptography and would like a non-technical primer, here’s an excellent explanation.

U2F became a good second factor in a world where the primary factor was becoming increasingly flawed. To quote Randall Munroe, our first factor, the password, was becoming something “hard for humans to remember and easy for computers to guess.”

As U2F became popular and easily available, the security community began examining the technology as an option to replace our primary factor instead of supplementing it. This has manifested primarily in the WebAuthn spec, which is already implemented within Chrome and Firefox, with Edge and Safari on the way.

WebAuthn takes the security of U2F and makes it more accessible and familiar. It supports using hardware tokens similar to U2F, but it can also use the security hardware already common in Android, iOS, Mac and Windows devices.

As Webauthn becomes widespread, you’ll create your online accounts with biometrics and log in the same way, no password needed. Your biometrics won’t leave the device; the actual authentication is handled by secure hardware in the device itself. The biometric will only be used to decide whether to allow or deny the authentication attempt. This will be one of the easiest authentication methods ever made available that’s still backed by good security practices.

In fact, you can test an early implementation of this now if you have an Android device or a Mac with Touch ID. Use Chrome and go to http://webauthn.io and select the TPM option.

This is still an area of ongoing research, where engineers are currently debating the best way to handle things like account recovery, but the groundwork for a passwordless future has been laid.

Zero-Trust Networking

While passwordless authentication & WebAuthn have far-reaching implications for consumer and enterprise authentication, a similar revolution is happening in enterprise authorization and networking known as zero-trust networking (ZTN) - also referred to in Google’s BeyondCorp and de-perimeterization.

Traditionally, a lot of authorization has happened at “Layer 2” and “Layer 3” so users are able to access services if they have physically connected to their office network.

Multiple offices needing to connect together has led to virtual private network (VPN) usage becoming widespread at the networking level, i.e., the network managers would connect offices over a VPN so that from an employee’s perspective, a New York City office and a San Francisco office would be the same network. As laptops and working from home became more common, a consumer VPN application achieved the same effect. Employees logged into an app on their computer and were connected as if they were physically connected in the office.

As this happened, the consumer world was solving a similar issue in a very different way. For accessing an early web service like Hotmail, the creators didn’t want users to have to install new software, so they had users enter their credential into the software they already had - their web browser. They started handling authentication and authorization in the Application Layer itself.

As users become more mobile and started conducting work on mobile devices such as Blackberries, and eventually iOS and Android devices, it was clear a new method of both authentication and authorization for enterprises was needed. Google began implementing these security procedures and published several papers on their BeyondCorp effort.

Enterprises are moving from authorizing at Layers 2 and 3, to the Application Layer where it is easy to authorize a user per service, not just the network as a whole (or even network segments).

As enterprises increasingly move toward the goal of ZTN, more procedures happen when a user is authorized. The user logs in and their credentials are checked as usual, but the authentication and authorization systems can also check the health of the device the user is using, their location and history for anomalies, and more. With all of this info, access can be allowed or denied with a greater degree of granularity.

In an ideal implementation of a ZTN network, all connections are authorized every time they’re initiated. All connections are proxied through a proxy server. The proxy server handles the authentication and authorization of the request. The proxy can use multiple data points -- most commonly from a policy engine -- to make its decision.

While this adds a great amount of information and security to the systems used by enterprises, it also makes the user experience vastly different. The employee doesn’t have to use a special app or have a prerequisite for using a corporate system. They simply go to the URL of the application they want to use and log in the same way as they do using a consumer app. The ZTN features that happen are mostly transparently to the user.

Recap

As information security has progressed, one of the major changes has been a shift in responsibility. While the user’s own security was and still is ultimately their responsibility, developers, IT and security teams are taking more ownership of the process than ever before.

Users are regularly exposed to phishing, social engineering, malicious applications, compromised sites, apps and extensions. Even completely “secure” implementations are so confusing and error-prone that the user explicitly allows things that are not what they intended.

The security community is taking on larger systemic issues of user psychology and social engineering attacks, and protecting users from them, not just enabling them to protect themselves.

As we go forward, passwordless authentication and Webauthn will grow in usage to better protect users against more psychological threats such as phishing. In enterprises, zero-trust systems will protect the employees, the company and the data belonging to the customers of the company.

As new systems are developed, security, both technological and psychological, will be considered from the beginning and built into the design of products.

A Retrospective on Authentication, Authorization and Human Psychology in Cybersecurity

Authentication and authorization have changed over the years, and continue to do so. As the internet became a core part of communications, threats expanded from local to global, and from technological to psychological. Information security is still often dependent on computer passwords; a creation of the 1960s, as well as network perimeters; a distinction that becomes less relevant every year.

Attacks increasingly involve exploiting human psychology as much as technology. The security community had learned a lot from 50+ years of information security and human behavior. I’ll discuss how we're using human behavior to our advantage and how easier-to-use security results in better security.

What is Information Security?

Information security is a huge and varied field, but at its core, the overarching goal is making sure malicious actors don’t get access to places, data and systems they shouldn’t.

A common issue that the security community comes up against is that a security system or feature is difficult to use, or is actively resisted by the users the system is attempting to secure.

Authentication vs. Authorization

Two of the most important components in information security are authentication and authorization. These terms are occasionally used incorrectly or interchangeably, or combined under the generic term “auth.” A simple way to distinguish between them is the questions they each attempt to answer.

Authentication attempts to answer the question “who are you?” as accurately as it can. Passwords are an example of an authentication system. Multi-factor authentication methods such as security keys and time-based codes are used to increase the confidence of the authentication.

Authorization attempts to answer the question “should you have access to what you’re attempting to access?” Authorization systems are more varied than authentication systems, but a commonly used one is the permissions setting in apps like Dropbox, Google Drive, or OneDrive. There you can add collaborators via their email address. Collaborators can then access the shared files if and only if they have authenticated with that email address, and met all of the authentication system requirements (usually a password).

Usability is Security

Security features and techniques must be utilized to be effective. Human psychology is as much a part of this process as anything else, if not more so. Security as a goal is generally well regarded by people, but has a reputation (not unjustifiably) that more security means less usability. For systems and services to truly be secure, they must have good security features that lend themselves to being easily configured and used.

Historical Examples

There have been many attempts to solve security issues without truly considering human psychology as a response.

One such example is passwords. Passwords have long been compromised and intercepted by man-in-the-middle attacks. The impact of these security concerns was magnified by the fact that many users understandably reuse their password across multiple services. As of 2017, the average business user had 191 accounts that needed passwords! A virtual impossibility without reusing passwords or using a password management tool.

The security community began addressing password reuse by requiring passwords to be changed regularly so that if a password was compromised by an attacker, it would “only” be usable for a limited time. However, password expiration policies resulted in the (now well known) phenomenon of people using extremely predictable passwords. While this would prevent a permanent silent takeover of the account, it didn’t prevent data loss which made this an inadequate mitigation for many organizations.

Once this realization was widespread, services began implementing multi-factor authentication (MFA). This was better than regular password changes and solved the same problem even better. However, the old password policies were often retained unnecessarily.

Early MFA was often implemented with RSA SecurID tokens. This was an effective mitigation, but required purchasing of a physical hardware token. MFA was eventually made easily available to common consumer accounts through SMS and TOTP apps (such as Duo Mobile and Google Authenticator).

Universal 2nd Factor (U2F) was another great advancement in both usability and security. With the Yubikey nano and other U2F devices, all that was needed for MFA was a simple press of a security key plugged into your laptop. U2F has strong defenses against phishing and is one of the easiest to use, however, it still required purchasing a separate device, which made it rare among consumers.

When used in tandem with relaxed password rotation requirements, these resulted in huge improvements over the previous state of affairs. However, unless MFA was required for the account, it was rarely enabled by the user. In 2016, less than 10 percent of Google accounts used MFA.

The additional overhead of some MFA systems were a deterrent to them actually being used.

The mobile device world had a similar issue. Devices were often not being protected with a password or PIN because it prevented easy usage of the phone. People unlock their smartphones about 80 times per day on average. The additional friction that a screen lock added made their usage uncommon. In the case of iPhones, Apple added Touch ID and Face ID features but also added biometric configuration to the phone setup flow. Today, 89 percent of iPhone users have screen lock enabled.

Security technology has to be easy to use and hard to miss.

Lessons Learned

One of the takeaways from early information security is that users will be more likely to configure and enable security features that are easier to set up. This seems obvious, and perhaps it is, but there was a basic assumption that people would configure their security settings to the appropriate level - unfortunately, it turned out that this was rarely the case.

Some of the conclusions drawn in earlier years were that users didn’t care about their own security as they weren't enabling security features. Yet, they got angry when security breaches happened. Users expect their devices to protect them, as opposed to the devices simply having options for users to protect themselves with.

People consider security a given when they buy a device. They expect “secure” to be a feature of a product, as opposed to the availability of “security features.”

This affects the level of engagement developers can expect from users. When using the product, there is a base level of engagement that’s happening, but deviation from the normal operations will result in interaction without real engagement. But the security expectations of the user remain unchanged.

A good example of this is a reoccurring topic from mainstream journalists on how third party humans can read your Gmail. While true, this only happens after the user views and accepts a dialog authorizing said third party to “read, [emphasis added] send, delete and manage your email.”

Example Dialog Box

Users were presented with a dialog explaining exactly what they were agreeing to and agreed to it. After clicking “approve” on a dialog, users were angry that the action explained on the dialog actually happened.

When a substantial amount of consumers misunderstand something, we as engineers need to reexamine how we communicate that information.

Recap

So, as a security and engineering community, we have a few high-level takeaways:

• Users expect security without having to work for it, and they expect for that security to be effective regardless of how much of any configuration was actually completed. This is not due to laziness, but because it’s an expected feature of the product.
  
• Users engage best with a relatively easy step during a period of already expected friction, e.g. setting up a new device.
  
• During unexpected friction of a product (oAuth, permissions, etc.), user engagement will be lower than other times. User education and engagement is crucial at this time.
  

As we move forward in developing new security technologies, the security and engineering communities have taken these and many other lessons to heart. I’m extremely excited about the next generation of authentication and authorization technologies as making them easy and accessible has been a top priority of mine.

In the next post in this series, I’ll discuss how the security community is applying these lessons to the next generation of technologies, and how the foundations have been already laid out using the technology you likely have in your pocket!

This blog post is the first in a three-part series on how Duo integrates with Cisco technology.

Most organizations are going through a major technology transition deploying on-premises applications and workloads to the cloud. For many, this transition takes several years. At Duo, most of our customers operate in a hybrid environment where some of their workloads and applications are located on-premises and accessible via a virtual private network (VPN), while several major applications such as email, file sharing, collaboration, marketing automation and design tools have moved to the cloud.

While organizations are in this transition, IT admins have to ensure that user productivity isn’t impacted. Admins want applications to be available and accessible at all times. In addition, they have to secure all data and continue meeting any or all compliance regulations required to do business.

Duo is a part of this transition or journey for our customers. To provide secure access to applications, customers typically start by adding Duo’s multi-factor authentication (MFA) to VPNs like Cisco AnyConnect.

Security trends suggest attackers continue to use compromised credentials via phishing, brute force and other attack methods as a way to gain unauthorized access to internal applications. If attackers steal VPN credentials, they may be able to access several corporate applications and data, causing potentially catastrophic data breaches. For others, securing VPN access is also a data regulatory compliance requirement.

For example, PCI DSS 3.2 requires organizations with cardholder data environment (CDE) to secure all remote access with MFA. Aside from PCI DSS, several other compliance requirements such as HIPAA and NIST 800-171 have similar MFA requirements. 

Duo helps these organizations instantly reduce their risk of a data breach while helping them easily meet compliance requirements.

However, from a security risk perspective, securing access to your VPN is just one of many steps. As workloads and applications increasingly continue to run in the cloud, admins want to ensure a consistent level of access security for all on-premises and cloud applications. 

With Duo, admins can easily add MFA to any cloud application such as Office 365, Azure, AWS, Google, Workday, Box and more.

For users, there are no additional steps. If users are already enrolled into Duo’s MFA service, they are prompted to authenticate when they log in to access their cloud applications.

After Duo’s MFA is set up with on-premises and cloud applications, admins can also take advantage of its rich device telemetry. With Duo, admins can get visibility into the security posture of all user devices such as laptops, desktops and mobile devices, including all personal devices (bring your own device - BYOD) accessing applications.

In addition to user authentication, Duo can get visibility into all corporate-owned and BYO devices without the use of agents. Since there are no device agents involved, Duo is easier to deploy and more user friendly. With complete device visibility, admins can determine risks due to personally-owned devices in their environment. For example, one of our enterprise customers discovered 30,000 new devices accessing their environment - and nearly 50 percent of those devices didn’t meet their company’s security and compliance requirements.

Admins can leverage user and device data collected by Duo to enforce security policies based on the risk level of data and applications. For example, admins can enforce a security policy for VPNs to allow access only from specific locations such as United States and from devices that have up-to-date software running on them. With Duo, admins can have a high level of assurance before granting a user and their device access to applications. Many of our customers also call this zero trust (ZT) or the software-defined perimeter (SDP). If you want to learn more about zero trust, refer to our blog here. 

Today, the Duo Labs team is releasing an in-depth look at Apple’s new approach to secure boot as described in Apple’s recently released T2 Security Chip Overview.

Enabled by the T2 chipset, new generations of the Macbook Pro and the iMac Pro aim to mitigate many software and hardware-based attacks against the very first pieces of code executed during the initial boot process. By ditching the flash memory chip containing Unified Extensible Firmware Interface (UEFI) firmware and using chipset functionality typically reserved for server architectures, the T2 is able to dynamically provide and validate UEFI payload contents at runtime.

We have spent considerable time looking at the T2 and have written a paper that outlines the technical details of what actually happens when the power button is pressed. The T2 is a great first step in the right direction, but there is still room for improvement when it comes to the secure boot process on an Apple T2-enabled device.

UEFI firmware contains some of the earliest code executed by modern computers at power on. It is in charge of setting up and initializing low-level hardware components before locating the operating system and handing off control of the boot sequence to the operating system’s kernel. Whether through leveraging operating system OS vulnerabilities or through an ‘evil-maid attack,’ the attacker’s goal is to inject their code into this durable storage medium.

If this firmware can be modified by an attacker, it could subvert security subsystems in order to effectively backdoor the operating system. These types of attacks are commonly referred to as bootkits and can be extremely difficult to detect as they live outside of the OS installation and can even survive OS reinstallation and hard disk replacement.

The crux of UEFI firmware security is that the code to validate the firmware image itself lives in the UEFI firmware image. This leads to the classic chicken and egg problem: How can you trust the result of the firmware validation routine without trusting the routine itself? To address this, Apple took the approach of entirely removing the firmware containing the flash chip and outfitted the T2 with what is called Slave Attached Flash (SAF) capability. This allows the T2 to first validate firmware signatures before providing the UEFI firmware to the rest of the chipset for execution.

Using an immutable, signature-validated image for UEFI firmware would be a huge win in terms of platform security. However, reality gets in the way. The traditional flash chip not only contains UEFI firmware, it also contains all the system firmware that enables the Intel Management Engine (ME) to operate, which uses areas of the flash chip for non-volatile storage. What the T2 ends up doing during ‘first-boot’ scenarios is validating the signature on Apple-provided images and then copies them over to internal mutable flash storage. So while the image is known to have started out as good and trusted, it can theoretically degrade into an untrusted state through external writes.

This is compounded with the complexity of the T2. It is coupled with the host OS, exposing new attack surface. Much of its functionality can be interfaced with from userland without having root permissions. A bug in the Apple XNU common-kernel used in many Apple products could effectively create a shortcut for an attacker. That’s not to say there is no benefit to be gleaned from a unified codebase. Apple’s masked-ROM rooted chain-of-trust, through the efforts of Apple’s engineers and security researchers worldwide, has matured in to one of the hardest targets in existence. Apple should be lauded for trying to bring their laptop and desktop lines into the same defensive posture as their mobile offerings.

Check out the full research report.

Summary

• Duo’s support for offline multi-factor authentication (MFA) for Windows has shipped
  
• There are two ways to use it - both of them easy to use and highly secure
  
• Duo is the only company to offer Universal 2nd Factor (U2F)-based offline MFA
  
• Available now to all Duo MFA, Duo Access and Duo Beyond customers at no additional cost
  

We’re pleased to announce the general availability of our offline MFA for Windows laptops, desktops and servers. Duo’s offline MFA for Windows allows end users to perform 2FA even while they are temporarily disconnected from the internet.

This is critical to support users whose job requires them to be temporarily offline, but who still need to perform 2FA to log in to their Windows computer. Here’s a few examples of different types of users and user scenarios that Duo now supports:

• An executive or salesperson who works offline or must securely log in to the (offline) computer before connecting to the in-flight Wi-Fi or hotel Wi-Fi
  
• An engineer or contractor at a customer site where they are not allowed to use Wi-Fi or internet, or where there is no internet available
  
• Federal contractors fulfilling requirements for Defense Federal Acquisition Regulation Supplement - Controlled Unclassified Information (DFARS-CUI)
  

Strong Pre-Release Demand

We’ve seen overwhelmingly strong interest from customers in the run-up to release. See our previous blog posts on the subject here and here. We also hosted a heavily-attended customer webinar, recorded here, where we addressed many common customer questions. One customer’s story about their rollout and use of offline MFA is located here.

Two Usage Options

Customers have the option to choose between two different ways to use Duo offline MFA for Windows. Both authentication methods achieve Duo’s high standards for ease of use and provide industry-leading security.

Duo Mobile App

The first option: users can choose the one-time passcode (OTP) method in their Duo Mobile app. This has the advantage of being very familiar for users who already use the OTP option in the Duo Mobile app on a regular basis. Watch how passcodes work with Duo Mobile in this video:

Offline U2F

The second option: users can opt to use a standard physical U2F security key (such as Yubico’s YubiKey). The advantage here is that it is extremely easy to use (just touch the key when prompted on screen). This works for users who don’t or can’t use a mobile device.

Duo is the first and only security vendor to deliver offline MFA based on U2F security key technology. Universal 2nd Factor, or U2F, is an authentication standard developed by the FIDO Alliance that is designed to be open, secure, private and easy to use. Learn more about U2F.

A YubiKey or other standard U2F security key is plugged into the user’s USB port. Once enrolled with Duo, a simple tap or button press on the key provides a second authentication factor to validate a user’s identity at login - similar to the one-tap convenience of online U2F login that users are already familiar with.

“With the introduction of this new feature, Duo provides a unified solution for offline, online, and web login using a single service and the YubiKey for strong hardware-backed two-factor authentication,” said Jerrod Chong, SVP of Product at Yubico. “This use case and integration expands many benefits of U2F for secure login without compromising security or usability for offline support that we are excited to see.”

The U2F security key option makes use of asymmetric cryptography. At enrollment time, a public/private key pair is generated for each user (a separate pairing for each unique application to be protected). The user’s private key is embedded on the U2F device hardware in a tamper-proof way. The user’s private key never leaves the hardware, and cannot be used for any other reason.

Available Now to All Duo Customers

The offline MFA for Windows is available as part of all Duo product editions (Duo MFA, Duo Access and Duo Beyond) at no extra cost. Administrators decide which groups of users can use the offline MFA option. Customers do not need to buy any additional licenses for users who use offline MFA. See additional information on Duo’s Windows login capability here.

The last Duo blog redesign was two years ago - launched in January 2016. Since then, Duo.com has undergone many changes, both driven by new content and design branding, as well as rapidly evolving strategic direction.

That's why the Creative team has launched the latest intentional redesign of the blog this week. You'll find several new components in this version, all part of a larger content strategy, with the objective of broadening the scope of the Duo blog to serve as a central news hub of Duo.com.

Keeping with our Duo values to simplify security and always remain transparent, we’re bringing content from all of our channels to the forefront to help keep you informed about the latest Duo ongoings - from the newest product release notes in the Duo Community to our recently published case studies and press releases.

Beyond the Blog

Beyond the Blog

This section highlights the latest company innovations and ongoings, beyond just blog posts, from product updates to events to press releases and a rotating open Duo job position - bridging the gap between our different news outlets into one featured area on the Duo blog.

Changelog

Changelog

Updated every few weeks with new line items as needed, this content component features minor and major product features and updates to guides, docs and the Duo Admin Panel. It's a strategic way to surface otherwise buried releases and news.

Content Promotions

Decipher Article Promo

Event and Case Study Promos

New to the blog are content promotions interspersed within blog post content - these are ways to promote and encourage further user engagement throughout our site, linking and featuring Duo’s ebooks and guides, Decipher articles, upcoming Duo events/webinars, case studies with our customers and more to help surface previously released content.

Twitter Content

Twitter Promo

Finally, we end with some social proof - a feed of @duosec's latest tweets and retweets, and a call to action to follow us on Twitter, to better feature & promote social engagement.

Sleek New Article Page Design

Blog Article

Click into an individual blog post and see the sleek new design (or, like, just look at this page you're on right now) - tags are now displayed on the right-hand side of the screen, with related content and author bio brought up higher to the left.

Other Updates

In addition to new content components and features, we’ve made a few other navigational and design changes:

• Updated blog navigation with Categories & Archive dropdown
  
• Pagination! No longer are you left hanging on the blog homepage 
  
• Cleaner icon design + navigational elements (no 'learn more' but rather, header links)
  

Thank you to our Creative web development, web design and content teams for all their hard work on up-leveling Duo's blog and content marketing. We hope you enjoy the improvements, and know that we’re always dedicated to providing (beautifully designed and developed) content of value.

When our customers came to us with a desire to support offline multi-factor authentication for Windows, we started off by focusing on the fundamental technical problem to be solved. How can we trust enrollment and continued authentication from a device that is offline?

Fortunately, we were not starting from the ground floor. We already had a broadly-used framework of Windows Logon to build upon. Windows Logon is our third most installed application integration with the eighth most users. Windows Logon relies upon the credential provider framework. By relying on an existing Microsoft Windows framework, it helps both our development team and our customers in terms of supportability.

Offline Enrollment

One of the first decisions we made was requiring an initial online authentication to prove the user’s identity before allowing an offline authentication. This paradigm correlates with our requirement for enrollment within the Duo Prompt, where we require an authentication (via Duo Push, Universal 2nd Factor or U2F, passcode, etc.) prior to allowing end users to add a new device or manage other authentication methods.

Our First Authentication Method

We looked at a number of authentication methods to support offline in conjunction with the Duo Labs R&D team. Duo Push was untenable because that requires either the Apple Push Notification Service (APNS) or Google Play services to speak to our service and request an authentication. Since that laptop or desktop is offline, there’s nothing that can invoke a call out to the internet to start that process. There is the same limitation with phone callback or SMS-based passcodes, since there’s not an initial step from the laptop or desktop to start authentication.

We also looked at proximity-based authentication via technologies like Bluetooth or Wi-Fi, but came to the conclusion that there were too many variables outside of our immediate control associated with these types of technologies. For example, with Bluetooth, although it’s ubiquitously available on laptops and desktops at this point, the pairing process for a mobile device to a Windows 7, 8.1 or 10 device is challenging. And it’s a user experience that Duo couldn’t meaningfully improve.

Wi-Fi-based proximity had too many variables over signal maintenance and quality - especially for cases in which the user is flying on a plane. That’s not even mentioning the variable of the smartphones that customers use, where we see well over 200 different types of Android devices with minor or major differences in settings, operating system versions and UX.

Not only did we have the benefit of an existing Windows Logon integration, we also had Duo Mobile widely used by millions of users. While Duo Mobile could not support us with push notifications due to the offline device requirement, Duo Mobile also supports one-time passcode (OTP) token storage. We could create an enrollment event using a QR code, similar to how we enroll applications into Duo Mobile, by which we can use Duo Mobile to share secrets from the laptop to create an OTP token. As this is a completely separate enrollment from the online Duo credential, even in a worst-case scenario in which that device was compromised, the lost secret would only be for that local login to that endpoint.

Why Security Keys?

Customers told us that they also needed to be able to use hardware tokens for offline MFA, for a number of reasons:

• For users that may choose not to use their mobile device for work authentication
• For users that won’t have access to their mobile device due to rules at company sites or restrictions around on-site vendor visits

Initially, we went to the existing D-100 tokens that we sell. This is a common solution set for legacy authentication tools in the marketplace. But there were a number of downsides to using these traditional keys. For one, we would need a mechanism to share OTP seeds stored in our Duo online database to the local laptop or computer. If that local OTP seed was stolen or used, then that token would be compromised and worthless for any other purposes.

With Duo Mobile, we were creating an enrollment event through a QR code communications mechanism. D-100s and other hardware tokens don’t have any sort of interface with a computer. This was a security challenge without a good solution that would require a potentially risky mechanism for user enrollment. Second, our customers have been loud and clear about the fact that the hardware token authentication experience from other products is what made them switch to Duo.

We wanted to help customers with a hardware token solution, but we needed a stronger solution. One that had stronger security properties and made security easy for end users.

Here at Duo, we are strong advocates of FIDO security keys and have deployed them broadly. First of all, the U2F token guarantees user presence at point of login because of the capacitive touch step. Secondarily, because the U2F standard relies upon asymmetric cryptography like Duo Mobile, it means that we limit the risks stated above in regards to leaked seeds. The private key is stored on the hardware itself and only a unique public key is shared with the endpoint.

In the worst case of a compromised endpoint, all that is lost is the multi-factor credential unique to that local login, similar to our solution using Duo Mobile. For example, if the same security key is used for local offline login and online login, those two credentials are separate, so losing the offline credential would not constitute a loss of the online credential.

Finally, and just as importantly, it’s a much better user experience. Instead of typing in a multi-digit code that rotates through, all the user needs to do is tap the capacitive touch token.

The combination of stronger security properties and a better user experience is part and parcel to how Duo approaches and develops solutions to customer problems. Plus, it helped that we validated the solution with the 40 customers that we were working with throughout the beta. Many of these customers in banking, energy, medicine and technology were, in fact, in the process of trialing security keys and used this opportunity to test them for more use cases.

Storing Local Seeds

When the endpoint is able to reach out to our service, we can deal with the challenge of securing seeds within our cloud infrastructure. Since this is the first product we’ve released that will be offline at the point of authentication, we needed to develop a mechanism to store offline MFA credentials on the endpoint.

Luckily, endpoints have become increasingly secure over time. Ever since fall 2015, all Intel-based Windows devices ship with a Trusted Platform Module (TPM). The TPM provides a tamper-proof storage mechanism for encryption keys. Windows 10 provides APIs for relying on the TPM for encryption, so we used it to encrypt the credentials that are stored in the registry for local access. By design, software is not able to save arbitrary data to the TPM, so we weren’t able to store the seeds in the TPM.

In enterprise environments, we know that hardware refreshes take a few years. So for devices that do not contain a TPM, we are using Windows software encryption to write the encrypted key in the registry.

With security keys, a unique benefit is that the private key is embedded on the security key hardware itself and not shared with the endpoint. All that is stored locally is the unique public key to facilitate verification of the U2F token response.

Other Configurations

We thought we’d use this opportunity to share lessons from working with 40 customers during the beta timeframe in regards to securing local Windows endpoints. The first recommendation we heard from our customers is to start by encrypting the hard drive. Bitlocker is the built-in Microsoft solution for hard drive encryption, but there are also third-party solutions that customers will choose to leverage. Encrypting the hard drive has the added benefit of restricting safe mode access for savvy users that are attempting to work around credential providers like Windows Logon.

The second lesson is around managing administrative permissions by disabling administrative rights. Many customers went a step beyond that and leveraged Privileged Identity Management tools like CyberArk, which is a Duo Select Partner, to manage temporary permissions escalations.

Finally, security keys come in a number of form factors. Yubico provides keys that can be left embedded in the device in the nano form factor as well as the more standard key fob-sized devices. Our customers were split as to which form factor they would choose to use, and it depends on your reading of NIST 800-53’s definition of multi-factor authentication.

Some customers interpret it as stating that the authenticator for MFA must be completely separate from the access device, so they’ve chosen to use the key fobs that users will need to plug in and pull out. Other customers view that as long as they are distinct devices, it’s acceptable to use the nano form factors that stay in the device.

Ultimately, it is our view that customers are positioned to choose the types of devices that best fit their particular risk profile and use case. Some customers choose to support only Duo Mobile, others choose to only allow security keys, and the majority will offer both as options. We leave the choice up to you.

Summary

We started this project because customers had a problem: securing access for an increasingly mobile workforce that isn’t always connected to the internet.

The journey to delivering Windows Offline began just about a year ago today and would not have been possible without contributions across the entire organization.

It started with our Duo Labs R&D team and Windows Engineering teams, then grew to include the Product Design and Mobile Engineering teams. Then we expanded to work with our 40 beta customers for input and feedback from the initial front-end designs and architectures to the first piece of beta software.

We want to thank everybody that made this feature possible and look forward to your continued use and feedback. Looking forward to the next evolution of Windows Logon, we are planning on adding support for Security Key authentication when the device is online.

The Federal Risk and Authorization Management Program, or FedRAMP, as it’s commonly known, elicits respect from organizations, but as with anything involving security, it can also make some organizations nervous.

It helps to look at FedRAMP as a lifestyle choice – while it requires a significant investment, it gives cloud service providers (CSPs) a stronger security model, as it touches a lot of what a company does for a living.

Today, Duo Security entered into the FedRAMP certification process with sponsorship from the U.S. Department of Energy (DOE). FedRAMP is currently reviewing for authorization our cloud-based Duo Access solution, which enables federal agencies to replace or augment traditional security card authentication methods with Duo’s push-based two-factor authentication (2FA) technology. Duo is now listed as “In Process” in the FedRAMP Marketplace.

It’s important to go through the onboarding process with an understanding that FedRAMP is an ongoing “program” and not simply a “certification” to be achieved and to move on. Some CSPs are not as versed in the long history of NIST 800-53 controls morphing into FISMA, and now FedRAMP. They will tend to treat FedRAMP more as a certification than a program. Remember, the move the cloud is risky in the eyes of some (most?) federal agencies, but they need to do it and they need to do it quickly.

The move to “cloud first” and now “cloud smart” has only accelerated in the last couple of years even though it was laid out by the Office of Management and Budget (OMB) way back in 2011 (seems a lifetime ago). The predominance and proliferation of mobile as the endpoint and the constant drumbeat of attackers (state-run and hacktivists) have not only raised our risk awareness, but they’ve also necessitated the need to move faster, and to be more agile. Move faster and smarter to the cloud. Move faster to mobile. Move faster to mitigate the non-stop barrage of risks. To just move faster. FedRAMP helps agencies do this without compromising security along the way. On the contrary, it helps CSPs and their agency customers “bake in” the security architecture. And we all know “baked in” is better than “bolted on.”

Will we reach a time and level of awareness where all of these security controls are automated and we as CSPs can just run a report and get an onboarding (and yearly) assessment? Will we find ways to make this process quicker while still maintaining an acceptable risk profile/posture? I certainly believe so. In the meantime, FedRAMP is an important process for us to mitigate and identify risk, and an important process for agencies to participate in as they accelerate their inevitable move to “cloud first.” That’s why we’re excited about Duo’s “In Process” status as we help federal agencies adopt a cloud-first model and address the need for strong authentication to secure and protect critical data.

Duo Oracle Access Manager (OAM) Plugin 1.2.0 released

PRODUCT 2018-11-01

New Admin Status feature (set to Active or Disabled) available for Duo MFA, Duo Access and Duo Beyond

DOCS 2018-11-02

Check out the new updates to our Duo Deployment Guide

PRODUCT 2018-11-09

New Policy Impact Report available for Duo Access & Duo Beyond

Healthcare Chief Information Security Officers (CISOs) and other security/IT team leaders are responsible for identifying patient safety or care issues, while driving the selection and adoption decisions on technology purchases to help address those concerns.

It’s not a simple task, especially when so many variables are at play:

• You’re concerned about securing patient data, employee data, financial and more
• But you also need to enable your diverse team of healthcare professionals - from physicians to clinicians to contractors - to do their jobs with limited additional friction
• You need to meet yearly audit requirements for HIPAA, PCI DSS, HITRUST, Joint Commission and NIST standards, and many other regulations
• Plus, you need to support always-available access from your users’ personal devices, no matter where they’re located

A large healthcare enterprise system needs a powerful, flexible and low-maintenance access security solution that doesn't introduce friction to workflows, and can work with complex, interconnected systems.

Oh, and it must work for every user scenario, with technical accessibility limitations. Did we mention it also has to provide a rich dataset for compliance audits and reporting needs? No big deal.

A CISO Guide for a New Approach to Security

To help see you through your 2019 game plan to provide a proactive and comprehensive security strategy, we’ve put together this guide, in which you’ll find:

• A detailed account of one healthcare CISO's experience with a zero-trust security model
• An overview of the needs of their hybrid, mobile and cloud environment, as well as the need to meet HIPAA compliance
• How they balanced usability and security and fit Duo Beyond into their existing network architecture

Their security team also discovered a hefty, surprising number of shadow devices after they gained insight into managed and unmanaged devices using Duo Beyond - there were nearly three times as many personal devices accessing their healthcare system network as they initially thought.

Check out our guide to learn about their other findings and how Duo helped them better secure patient data, get visibility into cloud apps they never had before, and meet their many different compliance and security objectives with Duo’s unified solution.

The security industry has turned its eyes toward the zero-trust model to mitigate risk and protect applications and data. To help our security partners give their customers the latest Unified Access Security (UAS) solution, which is headlined by our premiere zero-trust edition, Duo Beyond, Duo today announced a sole distribution agreement with Ignition, a UK&I-based value added distributor (VAD). With the exponential growth we’re seeing in the EMEA region, we’ve seized the opportunity to engage with Ignition to deliver zero-trust security to a wider set of partners and customers.

Why Ignition?

Our partnership serves strategic security partners who offer consultancy and advisory services through to deployment and ongoing services. With a particular focus on mid-market and enterprise, this partnership will provide increased support to more partners to implement the full spectrum of Duo Beyond product features, such as multi-factor authentication (MFA), adaptive authentication, endpoint visibility and single sign-on (SSO).

Ignition Technology’s progressive approach to IT security, including their vendor and partner relationships and sales, as well as marketing and technical support, makes them the perfect partner for Duo. Together, we accelerate the adoption of innovative MFA, zero-trust access and bring your own device (BYOD) solutions to the partner community.

This partnership provides great opportunities for the channel and compliments Ignition's strong, existing portfolio of software-as-a-service (SaaS) cyber solutions. Together, our joint business is being driven by more adoption of mobile access and cloud-based applications that continue to challenge the traditional foundations of security policy.

There are few constants that organisations can rely upon, but Duo’s zero-trust approach is one of them. With Duo and Ignition's complimentary vendors like SailPoint and Bitglass, we have the strongest Unified Access Security platform for today’s digital business transformation.

Get Started Today

Whether you are new to Duo or are already selling Duo (or even Cisco products), contact our dedicated Ignition team today -

Dave Risk +44 (0)20 3873 6580 duo@ignition-technology.com

Duo Security

This is a guest post from Coveware on the security risks of ransomware, RDP breaches and brute-force attacks.

Ransomware has been making steady headlines in 2018, most notably in the latest attacks on the City of Atlanta. Some of the most devastating attacks are claimed by ransomware variants such as Dharma and SamSam that are installed directly by online attackers after compromising a company’s Remote Desktop Protocol (RDP) ports.

These access points are either weakly secured or entirely unsecured and easily hacked via brute-force attacks, allowing attackers to upload ransomware to specific locations within a targeted company’s systems. Given the high proportion of ransomware attacks that begin with compromised RDP access, raising awareness of this vulnerability is critical.

In Q3 of 2018, Coveware estimated that over 80 percent of the cases it handled started with an RDP breach. In this post, we will look more closely at aspects of RDP that make it such an effective attack vector and how organizations should approach its security.

The History of RDP

RDP dates back to the early 1990s and the release of Windows NT (New Technology) 4.0. The functionality allowed IT service providers to work on any system within the network from their location. At the time, this dramatically lowered the cost and complexity of troubleshooting support issues. It also gave a generation of managed service providers a new tool to avoid costly on-site client visits, and enabled the industry to scale the services they offered.

Like most conveniences, however, RDP had its weaknesses - the most serious being that it created a new vector to launch an attack. Importantly, the ability to access a network via RDP sidesteps endpoint protection, making lateral proliferation between endpoints, partitioned networks and backup systems much easier to accomplish.

Compromising RDP

Attackers can breach RDP via a few different methods:

• By using port scanning via websites like Shodan and then subsequently brute-forcing RDP sessions until credentials are compromised.
• Purchasing and using brute-forced credentials for sale on sites like XDedic.
• Phishing an employee of the company to gain access and control of their machine. Then using that access to brute-force RDP access from inside the network.

There are tens of thousands of corporate RDP credentials available for sale for as little as $3 on dark web marketplaces. The wide availability of hacked RDP credentials is low-hanging fruit for cyber criminals looking to launch ransomware attacks.

While plenty of large organizations continue to leave this vector unsecured, smaller companies are equally complacent. Most assume they are too small to be targeted, and don’t appreciate just how easily targeted they are. Many also lack the resources, people or knowledge of how to properly secure access.

Another important point is that even in the absence of malware, ransomware or evidence of exfiltrated data, the presence of RDP credentials to a company’s network on a dark market is evidence of a prior breach.

If ransomware like Dharma or SamSam strikes, it's likely the second of two breaches that occurred, with the first being the compromise of RDP access credentials that were subsequently sold to the attacker. Under certain regulatory frameworks, both of these breaches would be reportable events.

The Attack Vector

The public and lateral access enabled by RDP allows ransomware to spread across a multitude of devices from individual machines, servers and backup systems.

Additionally, RDP can be exploited by attackers that elevate local login permissions of an account to allow for the creation of RDP sessions, as well as the ability to access and execute applications, after gaining initial access. Using executables, an attacker can gain control of the command prompt on a targeted system, giving them access to download ransomware.

Protecting RDP

In order to secure RDP, companies should consider a combination of preventative, reactive and recovery-focused measures:

1. Two-factor authentication (2FA): The vast majority of corporate ransomware attacks could be thwarted by enabling two-factor authentication on remote sessions and all remotely-accessible accounts - learn more about 2FA for RDP.
2. Limit access: Limit access by putting RDP behind a firewall, using a VPN to access it, changing the default port, and/or allowing access by a select whitelist of IP ranges can help mitigate the risk of compromise.
3. Endpoint & alternative solutions: Today’s endpoint solutions can detect anomalies in network usage (such as an in-office workstation attempting an RDP session) and stop them before damage is done. 4. Additionally, there are several new products that offer alternatives for remote access that are more secure.
4. Disaster Recovery (DR) & Incident Response (IR): Should RDP configurations become compromised, it’s critical that a company’s DR and IR plans be codified and up to date. Backup systems should have up-to-date versions of all data accessible on-premises, in the cloud and on systems located separately from the corporate network. IR firms should be kept on retainer to minimize costs and time to recover in the event of a breach.

Summary

The risks created by RDP are immense and can have disastrous outcomes if not managed. Every organization, large and small, should heavily prioritize securing their RDP access to avoid ransomware infection, a data breach or compromise, loss of data and more.

About Coveware

The Coveware Community combats ransomware by enabling managed service providers (MSPs) to offer proactive solutions to new and existing clients and was recently named by CRN as a 2018 Emerging Vendor in the Security.

We recently presented a technical research paper at Black Hat USA 2018 called Don’t @ Me: Hunting Twitter Bots at Scale. This paper provides an in-depth look at the entire process of gathering a large Twitter dataset and using a practical data science approach to identify automated accounts within that dataset.

In our paper, we built a classifier to detect automated Twitter accounts in a generic way. During the course of this research, we identified various types of bots that serve different purposes. These include:

• Content-Generating Bots - Bots that actively generate new content, such as spam or links to malicious content
• Amplification Bots - Bots that exist to like and retweet content in order to artificially inflate the tweet’s popularity
• Fake Followers - A type of amplification bot; fake followers exist to follow users in order to make those users appear more popular than they really are.

Each of these types of bots exhibit unique behavior that makes them worth covering in-depth separately. In this post, we’ll explore how fake followers operate, showing how to find an initial list of fake followers and then using this initial list to uncover a larger botnet measuring at least 12,000 accounts.

Seeing the Forest for the Trees

When examining accounts, more information is better. The more activity and information we have for an account, the more accurate of a categorization we can make. Traditional fake followers are challenging to detect on an individual level since they have very little (if any) activity other than following accounts:

It’s difficult to say that this account is a fake follower, since a lack of activity doesn’t mean an account is malicious. It’s perfectly reasonable to assume that legitimate users create accounts just to follow other users, treating Twitter like a newsfeed.

Instead of looking at fake followers on an individual level, we need to take a different approach, looking at their social network as a whole. This approach should help us to differentiate between low activity, non-malicious users and fake followers.

Mapping Suspicious Patterns

To find fake followers, we can start with an assumption: fake followers operate in groups. Intuitively, this makes sense, since followers aren’t usually purchased individually. Instead, they are purchased and applied as a group of accounts, all of which likely share the same characteristics since they were created by the same bot owner.

So what characteristics should we look for? In 2014, The New York Times published an article called “The Follower Factory” that explored the economy of fake followers. This article demonstrates clear patterns that emerge when comparing the followers for a legitimate account against when those followers were created.

Here’s what this mapping looks like for a user account with a low number of presumed fake followers (the author’s own Twitter account):

The x-axis represents the order in which account started following our target account, and the y-axis represents the date on which the account was created. The chart above shows an expected diversity in the account age of followers. There are no clear patterns of followers that were all created at the same time.

Compare this with the followers for a different user:

In this case, we see a group of thousands of followers at the top right of the graph that were all created at the same time. These accounts then followed the user one after another, which is unlikely to occur under normal circumstances, so these accounts would be suspected to be fake followers.

It’s important to note that just having fake followers isn’t proof that they were purchased and used intentionally. It’s possible that the bot operator directed the accounts to follow innocent accounts to evade detection or as an attempt at harassment, which is why we don’t reveal the identity of the user in this post.

Our technical paper presented at Black Hat USA 2018 included a case study detailing the discovery of a large botnet actively spreading a cryptocurrency giveaway scam. The bots in this botnet used multiple techniques to evade detection, including spoofing legitimate well-known accounts. In multiple cases, the accounts used to broadcast the spam appeared to be accounts of legitimate users that had been hijacked and repurposed.

After our initial research was concluded, the botnet began using fake followers to trick victims into believing their spoofed accounts were legitimate. This large influx of fake followers is clearly seen when mapping out the followers for the scam account:

Following the Thread

Browsing through the accounts following the fake Elon Musk profile revealed that they shared similar characteristics:

Each of the followers has a description that appears to be a proverb or fortune. Searching for these descriptions suggests that they may have been pulled from this list on Github.

Now, remember that the botnet owner aims to create fake accounts that bypass spam detection. One metric for determining the quality of a bot is how complete the profile is.

Creating random display names and screen names is straightforward. Creating a large number of unique, believable descriptions is much harder. This use of a precompiled list of fortunes appears to be the bot owner’s way of making the profiles more complete with believable profile descriptions.

However, sometimes attempts to blend into the background actually make the bots stand out.

Since each bot has a description from a known list of possible values, we can identify these bots from otherwise legitimate followers with a high degree of accuracy. Granted, similar to how we mentioned earlier that just following users doesn’t make an account malicious, having a fortune in the account description also isn’t indicative of maliciousness.

In this case, we’re able to say these are fake followers because we’re studying the accounts as a network and seeing the similar accounts act in a coordinated way.

Once we’ve identified a small group of fake followers, we can start mapping out their social networks looking for other fake followers with similar characteristics. This will result in the unraveling of the botnet.

We started with a one-degree crawl of a single fake follower:

A one-degree crawl means that we’re fetching the social network for the fake follower and the social network for each account the fake follower is following. The code we open-sourced as part of our initial research includes a script, crawl_network.py which crawls the social network for an account and outputs the results as both compressed JSON as well as in GEXF format for graphing.

We can start the crawl like this:

python crawl_network -g AkgunNasim.gexf -r AkgunNasim.json.gz AkgunNasim

The GEXF output includes both the fake followers as well as legitimate followers. To make our graph cleaner and quicker to layout, we wrote a simple script to identify and parse out the fake followers by searching for which accounts have a description that appears in the list of proverbs. This resulted in a list of nearly 10,000 bots.

After trimming the graph to only the fake followers and the accounts they follow, we can visualize the graph using the Force Atlas 2 layout in Gephi.

The graph above shows the relationships between the fake followers (black nodes) and the legitimate accounts they follow (green nodes). Many legitimate accounts have the same bots following them, resulting in the highly-connected cluster in the bottom right. In other cases, we see legitimate accounts that have bots unique to them, which result in the fan-like networks towards the top of the graph.

This is a great start! By starting with a single fake follower, we were able to find thousands with the same characteristics, but this isn’t the full story.

We can assume that not every bot in the botnet will follow the same users. This means that there may be entire groups of fake followers that don’t follow any users our initial bot did.

This means that our initial crawl likely didn’t find all the bots in this botnet. To find new bots, we can simply take another bot found during our initial crawl and crawl its network, looking for fake followers we haven’t already discovered. We ran this crawl for another fake follower, resulting in another 1,200 bots found.

To try and fully map out the entire botnet would require us to crawl the network of every fake follower we come across. Unfortunately, this is where Twitter’s API limits make this infeasible.

As we detailed in our initial report, the API endpoints used to fetch the social network, friends/ids (API link) and followers/ids (API link) are both rate limited to 15 requests per rate-limit window. This essentially allows us to make one request per minute. To map the full scope of this botnet, we would have to get the social network for both every fake follower (to discover new legitimate accounts) and for every account that each legitimate account is connected to (in order to discover new bots).

Doing some basic estimation, since each fake follower is connected to around 100 accounts, this would take nearly two years to complete. This also doesn’t include the time it takes to crawl any new bots we find in the process.

But Wait, There’s More

In the previous sections, we showed how graphing an account’s followers revealed interesting patterns that indicate a group of fake followers. Large groups of fake followers make very clear patterns that are easy to see. However, patterns created by smaller groups of fake followers may not be as obvious. To accurately find these smaller groups, we can take a programmatic approach.

Detecting Fake Followers Programmatically

In order to find smaller clusters of potential fake followers, we first started by determining the different instances when multiple accounts created on the same day followed our target account consecutively. Then, we computed the length of these instances which is the number of accounts that followed our target account in a row.

For example, if seven accounts created on August 31st, 2018 followed our target account, one after the other, the length for that instance would be seven. Since it is plausible for legitmate users with accounts created on the same day to follow a given user consecutively, we computed the standard deviation of each length, multiplied it by three, and used that as our threshold for determining potential groups of fake followers.

While the distribution of the lengths may be skewed, using three standard deviations should still filter out the potential lengths of what could be considered suspicious. The code for finding these groups can be found here.

Using the followers from a well-known journalist, we can point out these potential small clusters of fake followers. From first glance, there appears to be a large group of potential fake followers around the 75,000 index.

However, our script found five other clusters that would have been more difficult to find through visual inspection. These clusters of potential fake followers can be found below.

Now that we’ve identified these potential groups of fake followers, we can follow the same approach as we did earlier: crawling their social networks and doing further analysis to better understand how these potential groups may be connected.

Conclusion

Social networks allow communities to be built, ideas to be shared and people to connect to one another. By artificially inflating a user’s popularity, fake followers introduce dishonesty into the platform.

This post shows that looking at social networks as a whole allows us to find fake followers. After finding an initial set of bots, connections can be mapped out, revealing the larger botnet.

For more information on how to gather a large Twitter dataset and find bots within that dataset, be sure to check out our research paper Don’t @ Me: Hunting Twitter Bots at Scale.

Bubble bubble, toil and trouble...

Halloween, threats and elections, oh my!

So, full disclosure, Halloween is one of my favorite holidays. I enjoy the dressing up (the kids, not me) and I am a big fan of candy (chocolate, specifically). My kids are grown now so my excuse to go buy large quantities of candy from Costco is gone. I still do it, I just don’t have an excuse anymore.

Halloween is meant to be a spooky time, but when you couple it with a major election and all the cyber revelations being dropped like Casey Kasem’s top 40 singles, it moves from spooky to downright terrifying.

Case in point - this little ditty that just recently popped into the top 40:

Watchdog: 'Nearly all' new US weapons systems vulnerable to cyber attacks

Essentially, the Government Accountability Office (GAO) found that nearly every new Department of Defense weapon system was vulnerable to some kind of compromise or attack. Some were simple, such as open-source software that still had their default passwords or passwords that were easily guessable within minutes.

We keep seeing this, time and time again, and it sometimes boggles the mind when you think about how some simple things could be applied to avoid these types of catastrophes. First, if there is a default password, change it! Seems pretty straight forward. I know passwords suck and I have high hopes that we will get rid of them in my lifetime, but until then, practice some basic account hygiene. Change the passwords.

Also, since passwords by themselves are problematic, 2FA, 2FA and 2FA (two-factor authentication). If the answer to the question, “What happens if someone guesses the password?” is “I am owned” - then yeah, 2FA. It’s a simple, yet very effective way to not get owned; at least, not easily.

Elections Matter

This brings me to my next Halloween spooktacular issue. Election security.

I still don’t think we have a good handle on how to protect an election. That includes the election apparatus itself (voting machines), systems used by voting officials, their contractors and elected officials. Let’s just say it: 2016 was a abysmal failure of epic proportions. Like gargantuan. I like the word gargantuan and I rarely get to use it in a sentence.

“Sometimes the winning move is not to play.”

Or at least to regroup to fight another day.

I personally think it’s so bad that the only real choice for protection of the voting apparatus is to go back to paper ballots. Heresy, I know (especially for this self-professed tech geek), but desperate times call for desperate measures. And don’t talk to me about “hanging chads.” This is a false equivalency, similar to saying, “Well, my calculator is broken and I could do the math on paper, but I’d rather just live with the incorrect calculations.” Please. This is a minor sticking point when compared to an overall system vulnerability.

Even if we don’t go completely back to the Stone Age, we might still want to put in a paper trail (you know, receipt?) so that we can reconcile to ensure the numbers add up. I’m no accountant, but I think most would understand this analogy.

For additional context, here are some blogs we’ve posted over the past several months that talk about all the research and exposure around election security:

• Spoofed Domains Target U.S. Senate and Political Organizations
• Breaking Down the DNC & DCCC Cyber Attack

Boo!

Ok, now that I’ve scared everyone (myself included), here’s the thing. We can do this. We have the smart, dedicated people we need. Just look at all the discussions in Vegas this past summer:

• Election website security a mess for states and candidates alike
• DEFCON Video Shows a Voting Machine Used in 18 States Is Hacked in 2 Minutes

Boo Boo!

Paper ballots?

I think so… maybe…you betcha. But I think (nay, hope) we wouldn’t need to go back forever. This is not an insurmountable task. But the risk is high enough to do a reset. Let’s get our security ducks in a row and then re-engage. Look, democracy is messy. I get that, but we as citizens? This is what we do. As they say, it’s our civic duty. And while i don’t think we need to pull the ripcord just yet, we do need to be vigilant and take the security of this solemn process seriously.

This is too important not to get right.

Recently, a few interesting federal government security stories have popped up in the news:

• The payment card and travel information of 30,000 Department of Defense (DoD) military and civil personnel was stolen from a third-party contractor (Reuters)
• New DoD computerized weapon systems can be easily hacked, according to a report from the U.S. Government Accountability Office (GAO) (ZDNet)
• Voter records from 19 U.S. states were found up for sale on a hacking forum - with the seller stating the records are being updated on a weekly basis (SCMagazine)
• A North Carolina water utility's computer systems were subjected to a ransomware attack, prompting the FBI and Department of Homeland Security to investigate (TheState)

This slew of rather grim news always comes with just a few lessons learned and many recurring motifs. Let me break it down:

Third-party vendors - Not a lot of information was made available due to pending investigation, but the DoD breach was due to single, unnamed commercial vendor of the executive branch department. It's well-known that attackers often target the lower-hanging fruit of small contractors that may have weaker or nonexistent security in place, granting attackers an easy proxy to larger organizations like the DoD.

In 2017, many security standards for federal contractors were made mandatory, as part of the final rule clarification of the Defense Federal Acquisition Regulation Supplement (DFARS). Among those controls include multi-factor authentication for local and network access, employing the principle of least privilege, retaining audit records and more - see an overview of those rules here.

Related resources on third-party vendors security:
Security Best Practices for Third-Parties: Protecting the Enterprise

Privileged access - In the GAO tests against the DoD weapons systems, test teams were able to easily move throughout a system and escalate their privileges until they'd taken over the system. One test indicated they were able to guess an administrator password in nine seconds. Other actions included copying, changing, deleting and scanning entire system data while disrupting and manipulating system operations.

Implementing the rule of least privilege - giving users access only to that which they need to complete their job function - can be done several ways. Controlling which users and user groups can access which applications, while granting access only after checking a combination of their verified identity and trusted device gives administrators the flexibility of an adaptive authentication solution.

Related resource:
Managing Risk With Adaptive Authentication

Data profiling for identity fraud - While state voter registration lists aren't strictly confidential, the usage of them is restricted. When this list of personally identifiable information (PII) is paired with other breached data lists of more sensitive information (like Social Security Numbers), malicious actors can create a target profile of the U.S. electorate for malicious means, as Anomali stated in a blog post on their findings.

The political repercussions could include identity fraud or fraudulent changes to online voter registrations - potentially rendering legitimate voters ineligible to cast ballots, or allowing attackers to delete voter registrations, request absentee ballots, etc.

This all highlights the need to keep access to sensitive data restricted with adaptive access policies that limit access to the users and devices that meet your organization's specific risk tolerance levels. With these, you can restrict access based on geolocation, user roles, network type and more.

Related resource:
Adaptive Authentication & Policy Enforcement

Credential-stealing (among other destructive behaviors) malware - In a media release from the targeted water utility company, Onslow Water and Sewer Authority (ONWASA), their CEO stated that their servers and personal computers had been experiencing persistent virus attacks from Emotet, a wormlike malware variant referred to as a modular banking Trojan by the U.S. Computer Emergency Readiness Team (US-CERT).

Emotet has a spambot module that enables itself to spread quickly, using email templates, attachments and email credentials downloaded from its host server. And yet another module steals credentials from web browsers and email clients, sending passwords to the host server to enable attackers to log in and spread spam emails, according to a Blueliv report.

While early detection and backups can somewhat help mitigate ransomware infections, backing up primary authentication with multi-factor authentication - a second factor in addition to passwords to verify users’ identities - can further block attackers from leveraging stolen credentials to log into email accounts and spread malware.

Related resources:
Multi-Factor Authentication (MFA)
Two-Factor Authentication Evaluation Guide

Critical vulnerabilities - Nearly all of the DoD computerized weapon systems were also found to be rife with vulnerabilities, according to the GAO report, rather aptly titled DOD Just Beginning to Grapple with Scale of Vulnerabilities(PDF).

Many of the vulnerabilities exploited by the test teams had already been identified in previous assessments - only one in 20 cyber vulnerabilities had been corrected since, and yet another test report indicated that the team exploited 10 total previously-identified vulnerabilities.

What does all of that mean? It means that for some reason, the DoD weapon systems weren’t updating or implementing solutions to close security gaps, making it trivial to exploit them to gain access or control of their systems. Many vulnerabilities exist in older versions of software, like operating systems, plugins and browsers. Knowing this, attackers are able to leverage out-of-date devices to compromise or install malware on them to steal data or gain entry to organizations' systems.

Getting visibility into all of the different endpoints accessing your environment - from managed to unmanaged; mobile to desktop; etc. - is essential to understanding which devices are out of date, and which require security remediation. Coupled with device access policies, admins can block and notify users to update their devices before granting access, protecting your apps and data from exposure.

Related resource:
Mobile Device Security Made Easy with Duo’s Security Checkup

Summary

• Compromised credentials are a top cause of business data theft and security breaches. Security teams struggle to keep up with the volume of security alerts, while identity-based threats slip through the cracks.
• Duo and Exabeam bring together the power of rich authentication data and advanced analytics to automatically detect and remediate identity-based threats.
• This solution extends zero-trust policies beyond the point of access to the user session.

Credential theft continues to be the top cause of security breaches, as it has been for the past several years, according to the Verizon Data Breach Investigation Report. Compromised identities and credentials are even more damaging when they belong to privileged users who hold access to the “crown jewels” of an organization.

Security teams are finding it difficult to keep up with the avalanche of security events they need to investigate, let alone take swift action to prevent and remediate security incidents. According to Cisco’s 2018 Annual Cybersecurity Report, the quantity of organizations’ security events have increased four-fold in last two years. Further complicating matters, the lack of integration and automation between siloed security tools adds to the woe of SecOps teams, such that it takes about 66 days to contain a breach.

The result: According to Cisco’s cybersecurity report, half of legitimate events not remediated have led to the doubling of breaches in recent years.

Accelerate Security Analytics and Response for Identity-Based Threats

Duo and Exabeam have partnered to deliver a robust identity analytics, detection and response solution.

Speed Up Detection and Response

This integration enables SecOps to respond in real time to security alerts, thereby preventing or containing breaches.

Duo provides detailed authentication and endpoint data that helps in identifying potential threats very quickly and reliably, with less false positives. Duo’s adaptive authentication and endpoint data coupled with Exabeam’s advanced analytics and machine learning provides accurate and timely security alerts. This integration also removes manual remediation by automating the actions to be taken by Duo.

“This partnership will be of great benefit to our customers by increasing the speed, certainty and breadth in which they can detect and respond to potential threats in their IT environments,” said Ray Tam, Vice President of Security of Trace3. “We’ve been working closely with both Duo and Exabeam already and we look forward to engaging with both teams to ensure their solution is readily available to the organizations in our diverse customer portfolio.”

Extending Zero-Trust to User Sessions

Being squarely in the access path for every user, every device and every application allows Duo to enforce zero-trust policies at the time of access. This integration extends the zero-trust policies beyond the point of access by continuously monitoring, detecting anomalies and enforcing zero-trust policies throughout the user’s session.

While organizations need to build a strong front door to prevent breaches, they also need to build the capability to detect, resolve and respond to threats in order to limit damage as effectively as possible.

Beyond securing the front door with Duo, Exabeam is able to find the unfindable with advanced analytics and machine learning during the user session.

How It Works

• The Exabeam Security Intelligence Platform takes in rich authentication and device data provided by Duo.
• Exabeam’s advanced analytics and machine learning uses session data to find risky behaviors and suspicious devices.
• Exabeam initiates a response by prompting Duo’s adaptive multi-factor authentication to verify the user.
• If the user approves, the incident is closed. If the user doesn’t approve or doesn’t respond, Exabeam takes containment actions against the user through Duo to disable that user account, revoke permissions and/or send an email to the Security Operation Center (SOC) or SecOps team.

Configuring Duo services in Exabeam

For more details about the integration, see the configuration document.

Learn More

Duo and Exabeam partner page
Duo and Exabeam solution brief
Duo and Exabeam press release

Last month on Tuesday, September 18, Duo Security co-hosted the 2018 Cloud-Native Security Summit with Capsule8 and Signal Sciences in New York City. This full-day summit was jam-packed with panels, discussions and presentations focusing on security challenges and advancements in the cloud-native world.

Kicking off the event was Chenxi Wang, founder and managing partner for Rain Capital, as she went over the results of The State of Cloud-Native Security, our recent research survey of 486 IT and security professionals on adoption of and concerns about Cloud Native Applications.

The survey notes an increasing reliance on Cloud Native for three primary reasons: new software development, operational cost savings and business modernization. However, increased security risks present a barrier to cloud adoption. Many companies struggle with threat visibility and detection: 73 percent say that they lack real-time insight into threats and on-going attacks, while nearly half report that false positives account for more than half of their production environment security alerts. In addition, companies struggle with deploying effective security in their production environments, with 40 percent saying they do not have a DevOps function in place.

In order to solve these difficulties, the survey suggests that companies find ways to increase visibility to production infrastructure, demand more immediate and precise detection tools, establish defined DevOps processes, and enable security teams to work hand-in-hand on deployment scales.

Following Chenxi’s presentation, Art Coviello, former chairman and CEO of RSA, and Ed Amoroso, CEO at TAG Cyber, took the stage for a fireside chat. During the discussion, they noted the importance of taking cybersecurity seriously by focusing on people and processes instead of point products, as well as the importance of understanding and acknowledging the dangers of not taking security seriously.

They also discussed being realistic about what can and can’t be done, especially when it comes to things like Artificial Intelligence. Ed pointed out that there’s lots of crazy hype about AI solving all our problems — unfortunately, this isn’t the case, but AI is finding its place when it comes to detecting behavioral patterns.

The summit continued with a panel discussion between:
• Doug DePerry, Director of Product Security, Datadog
• Patrick Ancillotti, VP of Systems Engineering, Vimeo
• JJ Agha, Head of Information Security, WeWork

A key theme in this discussion was instilling a companywide security culture by bridging the gap between security groups and non-security groups. All three panelists emphasized transparency and clear communication, stressing that we need to approach people at their level. JJ mentioned the effectiveness of providing metrics, showing how things actually work, and explaining what you’re doing. Patrick mentioned moving accountability upwards and conducting audits. Doug suggested raising awareness through visibility, though he warned, “Don’t be Chicken Little!”

Continuing the theme of bridging gaps and working with others, Stephen Fridakis, CISO of HBO, shared his experiences in navigating security for the television network’s original productions in a fireside chat moderated by Andrew Peterson, Founder & CEO of Signal Sciences.

Stephen talked about the difficulty of controlling security for these productions, sharing that there are 20 to 70 entities involved in post-production, and the software they use does not always work in the cloud. Additionally, once the content is ready for distribution, there’s the problem of platforms and developers — HBO is available on 37 different platforms, all using a wide range of tools. Because of all this, they must strike a balance between security and the needs of the producers and developers.

In the summit’s second panel, the discussion shifted slightly to how people and processes figure into detecting attacks at scale. The panel was moderated by John Viega, co-founder and CEO of Capsule8, and included:
• Melody Hildebrandt, CISO, 21st Century Fox
• Heather Adkins, Director of Info Security & Privacy, Google
• Brad Maiorino, former CISO, Target, GE, GM
• Jess Frazelle, Microsoft

The panel explored the role of humans vs machines, with Heather noting that machine learning can provide insights into what’s happening, but not why it’s happening — the new role of humans, she suggested, is to teach the system this.

The panel also stressed that we need to change how we think about detection. Heather noted that we should be offering services instead of demanding requirements. Brad stressed the need for relentless practice and red team simulation, so that we can train people to fill in any technology gaps when it comes to missed threat profiles.

Geoff Belknap, CISO at Slack, also noted the importance of people during his fireside chat, stating that the most important thing is to help set the stage for culture. One of his biggest wins was using Security Bot (an automated program/persona within Slack) to discourage risky engineering behaviors. He noted that it’s possible to subtly modify behaviors by making the safe option the easiest option and providing incentives for doing the secure thing.

When asked how people are thinking about the problem of cybersecurity, Geoff suggested what was once a network and infrastructure problem is now an issue of the generation gap. Some people are used to thinking about things in a physical way, but we can’t do that now. We do need to understand how people are thinking about it, but then correct misconceptions and adapt our narrative so that it makes sense to them.

Following Geoff, Duo’s Director of Advisory CISOs Wendy Nather led a panel discussion on learning to trust zero trust. Participating in the panel were:
• Ross McKerchar, CISO, Sophos
• Nick Selby, Director, Cyber Investigations & Intelligence, NYPD
• Harry Sverdlove, CTO of Edgewise Networks

Just what is zero trust? Nick explained that it involves continuously checking if users are who they claim, with Harry adding that it’s starting with no trust and then building trust with every interaction. Ross stated that it means setting user identity as the perimeter instead of the server, while minimizing privilege to that user.

How do we implement a zero-trust structure? Ross advised that you shouldn’t change everything at once, but focus on one group at a time. Harry suggested starting with the biggest risk first, and Nick added that if you do, be sure that each part is finished completely before moving on to the next step. Wendy noted that users of critical systems are the crankiest, so an alternative approach would be to start off with users that you know will follow through.

All four panelists asserted that different systems will go through different paths in their journey to implementing zero trust. However, Wendy surmised that perhaps in the future, zero trust won’t be zero trust anymore...it will just be security.

The final presentation came from Rich Smith, Director of Duo Labs, who stressed that zero trust is not a product, but an approach. To continue protecting both users and devices (which are equally important), we must build security with an attack-driven defense in mind, by predicting how new technology will be abused and working to resolve those instances.

While the summit provided and reinforced many great points on the importance of security culture, human-machine responsibilities and interactions, and vigilance and collaboration in the face of threats and breaches, there’s still so much to learn about security in the cloud-native world. As we continue to grow our understanding and technologies, we appreciate all the contributions everyone has provided, and we look forward to seeing you at the next summit!

Beneath the noble birth
Between the proudest words
Behind the beauty, cracks appear
-Rush

Please don’t throw the baby out with the bathwater.

I’ve always hated this saying, but there is a point to it, and this point resonates with me when it comes to upping the game of human identity-based authentication. We in the public sector have spent millions of dollars and dozens of years putting a pretty good system in place to deal with this.

Pretty good...but not great and not without its holes - some small, some gaping. We’ve also been lurching back and forth between “smart cards are dead!” & “smart cards are with us forever!”. The truth, as it always is, is somewhere in between.

We spend a good amount of time talking about quick wins to get started (or maybe restarted?). Or, at least, recommitted to closing the gaps that exist and doing it in a way that has an eye toward a longer, more complete journey and doesn’t break the proverbial piggy bank.

But from an enterprise perspective, we have to keep going back to the investments we’ve made and find a way to leverage them.

SP-800-157

We’ve tried to do this with a derived credential with mixed results. While it looks good on paper, you lose something in the translation - you lose one of your factors. It would be a stretch to call PIV-D (Derived Personal Identity Verification) multi-factor authentication.

So you would still need something else. And while it’s great in a mobile context and will be even greater once all endpoint platforms have on-board TPMs (Trusted Platform Module) or a secure hardware-based element with which to store the credential, it’s still not strong enough. It doesn’t mirror the strength of...the card.

Which is why we want to build in support for card-based proofing for enrollment. This leverages the years-long investment in public key infrastructure (PKI) and “the card” to prove identity and device ownership in order to provision a simpler, more widely-accepted authenticator.

These authenticators can be one or many and can be provisioned and utilized based on risk as outlined in NIST’s SP-800-63-3 guidance. For example, you could authenticate with a PIV or CAC (Common Access Card) and provision a Yubikey for AAL Level 3, AND provision a Duo Push token for AAL Level 2 access.

It’s important to note that since NIST was smart and separated the enrollment/provisioning from usage, this “derived authenticator” should satisfy, depending on workflow, NIST SP-800-63-3 IAL Level 3. We really are moving more toward a “risk-based” model, which will only help us and is really the right security approach.

The technology world is moving fast. This pace is creating heartburn and fire drills in private enterprise, and public sector enterprise is really no different here. By leveraging existing infrastructure and existing investment, we can find a way to save $$$ and deliver a superior user experience while still meeting the “laws of the land.”

These are exciting times and we ain’t even done yet.