Work from home strategies leave many companies in regulatory limbo

Like most American businesses, middle market companies have been forced to rapidly implement a variety of work-from-home strategies to sustain productivity and keep employees safe during the COVID-19 pandemic. This shift, in most cases, was conducted with little chance for appropriate planning and due diligence.

regulatory grace period

This is especially true in regard to the security and compliance of remote work solutions, such as new cloud platforms, remote access products and outsourced third parties. Many middle market companies lacked the resources of their larger counterparts to diagnose and address potential gaps in a timely manner, and the pressure to make these changes to continue operations meant that many of these shortcomings were not even considered at the time.

Perhaps more important than the potential security risks that could come with these hastily deployed solutions is the risk that an organization could realize later that the mechanisms they deployed turned out to lack controls required by a variety of regulatory and industry standards.

The dilemma

Take medical and financial records as an example. In a normal scenario, an organization typically walls off systems that touch such sensitive data, creating a segmented environment where few systems or people can interact with that data, and even then, only under tightly controlled conditions. However, when many companies set up work-from-home solutions, they quickly realized that their new environment did not work with the legacy architecture protecting the data. Employees could not effectively do their jobs, so snap decisions were made to allow the business to operate.

In this situation, many companies took actions, such as removing segmentation to allow the data and systems to be accessible by remote workers, which unfortunately exposed sensitive information directly to the main corporate environment. Many companies also shifted data and processes into cloud platforms without determining if they were approved for sensitive data. In the end, these workarounds may have violated any number of regulatory, industry or contractual obligations.

In the vast majority of these circumstances, there is no evidence of any type of security event or a data breach, and the control issues have been identified and addressed. However, companies are now in a position where they know that, for a period of time (as short as a few days or months in some cases), they were technically non-compliant.

Many middle market companies now face a critical dilemma: as the time comes to perform audits or self-attestation reports, do they report these potential lapses to regulatory or industry entities, such as the SEC, PCI Council, HHS, DoD or FINRA, knowing that could ultimately result in significant reputational and financial damages and, if so, to what extent?

A temporary regulatory grace period is needed, and soon

The decision is a pivotal one for a significant number of middle market companies. To date, regulators have not been showing much sympathy during the pandemic, and a large segment of the middle market finds itself in a no man’s land. If they had not made these decisions to continue business operations as best they could, they would have gone out of business. But now, if they do report these violations, the related fines and penalties will likely result in the same fate.

A solution for this crucial predicament is a potential temporary regulatory grace period. Regulatory bodies or lawmakers could establish a window of opportunity for organizations to self-identify the type and duration of their non-compliance, what investigations were done to determine that no harm came to pass, and what steps were, or will be, taken to address the issue.

Currently, the concept of a regulatory grace period is slowly gaining traction in Washington, but time is of the essence. Middle market companies are quickly approaching the time when they will have to determine just what to disclose during these upcoming attestation periods.

Companies understand that mistakes were made, but those issues would not have arisen under normal circumstances. The COVID-19 pandemic is an unprecedented event that companies could have never planned for. Business operations and personal safety initially consumed management’s thought processes as companies scrambled to keep the lights on.

Ultimately, many companies made the right decisions from a business perspective to keep people working and avoid suffering a data breach, even in a heightened environment of data security risks. Any grace period would not absolve the organization of responsibility for any regulatory exposures. For example, if a weakness has not already been identified and addressed, the company could still be subject to fines and other penalties at the conclusion of the amnesty window.

Even a proposed grace period would not mean that middle market companies would be completely out of the woods. Companies often must comply with a host of non-regulatory obligations, and while a grace period may provide some relief from government regulatory agencies, it would not solve similar challenges that may arise related to industry regulations, such as PCI or lapses in third-party agreements.

But a grace period from legislators could be a significant positive first step and potentially represent a blueprint for other bodies. Without some kind of lifeline, many middle market companies that disclose their temporary compliance gaps would likely be unable to continue operations and a significant amount of jobs subsequently may be lost.

5 tips to reduce the risk of email impersonation attacks

Email attacks have moved past standard phishing and become more targeted over the years. In this article, I will focus on email impersonation attacks, outline why they are dangerous, and provide some tips to help individuals and organizations reduce their risk exposure to impersonation attacks.

email impersonation attacks

What are email impersonation attacks?

Email impersonation attacks are malicious emails where scammers pretend to be a trusted entity to steal money and sensitive information from victims. The trusted entity being impersonated could be anyone – your boss, your colleague, a vendor, or a consumer brand you get automated emails from.

Email impersonation attacks are tough to catch and worryingly effective because we tend to take quick action on emails from known entities. Scammers use impersonation in concert with other techniques to defraud organizations and steal account credentials, sometimes without victims realizing their fate for days after the fraud.

Fortunately, we can all follow some security hygiene best practices to reduce the risk of email impersonation attacks.

Tip #1 – Look out for social engineering cues

Email impersonation attacks are often crafted with language that induces a sense of urgency or fear in victims, coercing them into taking the action the email wants them to take. Not every email that makes us feel these emotions will be an impersonation attack, of course, but it’s an important factor to keep an eye out for, nonetheless.

Here are some common phrases and situations you should look out for in impersonation emails:

  • Short deadlines given at short notice for processes involving the transfer of money or sensitive information.
  • Unusual purchase requests (e.g., iTunes gift cards).
  • Employees requesting sudden changes to direct deposit information.
  • Vendor sharing new.

email impersonation attacks

This email impersonation attack exploits the COVID-19 pandemic to make an urgent request for gift card purchases.

Tip #2 – Always do a context check on emails

Targeted email attacks bank on victims being too busy and “doing before thinking” instead of stopping and engaging with the email rationally. While it may take a few extra seconds, always ask yourself if the email you’re reading – and what the email is asking for – make sense.

  • Why would your CEO really ask you to purchase iTunes gift cards at two hours’ notice? Have they done it before?
  • Why would Netflix emails come to your business email address?
  • Why would the IRS ask for your SSN and other sensitive personal information over email?

To sum up this tip, I’d say: be a little paranoid while reading emails, even if they’re from trusted entities.

Tip #3 – Check for email address and sender name deviations

To stop email impersonation, many organizations have deployed keyword-based protection that catches emails where the email addresses or sender names match those of key executives (or other related keywords). To get past these security controls, impersonation attacks use email addresses and sender names with slight deviations from those of the entity the attacks are impersonating. Some common deviations to look out for are:

  • Changes to the spelling, especially ones that are missed at first glance (e.g., “ei” instead of “ie” in a name).
  • Changes based on visual similarities to trick victims (e.g. replacing “rn” with “m” because they look alike).
  • Business emails sent from personal accounts like Gmail or Yahoo without advance notice. It’s advisable to validate the identity of the sender through secondary channels (text, Slack, or phone call) if they’re emailing you with requests from their personal account for the first time.
  • Descriptive changes to the name, even if the changes fit in context. For example, attackers impersonating a Chief Technology Officer named Ryan Fraser may send emails with the sender name as “Ryan Fraser, Chief Technology Officer”.
  • Changes to the components of the sender name (e.g., adding or removing a middle initial, abbreviating Mary Jane to MJ).

Tip #4 – Learn the “greatest hits” of impersonation phrases

Email impersonation has been around for long enough that there are well-known phrases and tactics we need to be aware of. The emails don’t always have to be directly related to money or data – the first email is sometimes a simple request, just to see who bites and buys into the email’s faux legitimacy. Be aware of the following phrases/context:

  • “Are you free now?”, “Are you at your desk?” and related questions are frequent opening lines in impersonation emails. Because they seem like harmless emails with simple requests, they get past email security controls and lay the bait.
  • “I need an urgent favor”, “Can you do something for me within the next 15 minutes?”, and other phrases implying the email is of a time-sensitive nature. If you get this email from your “CEO”, your instinct might be to respond quickly and be duped by the impersonation in the process.
  • “Can you share your personal cell phone number?”, “I need your personal email”, and other out-of-context requests for personal information. The objective of these requests is to harvest information and build out a profile of the victim; once adversaries have enough information, they have another entity to impersonate.

Tip #5 – Use secondary channels of authentication

Enterprise adoption of two-factor authentication (2FA) has grown considerably over the years, helping safeguard employee accounts and reduce the impact of account compromise.

Individuals should try to replicate this best practice for any email that makes unusual requests related to money or data. For example:

  • Has a vendor emailed you with a sudden change in their bank account details, right when an invoice is due? Call or text the vendor and confirm that they sent the email.
  • Did your manager email you asking for gift card purchases? Send them a Slack message (or whatever productivity app you use) to confirm the request.
  • Did your HR representative email you a COVID resource document that needs email account credentials to be viewed? Check the veracity of the email with the HR rep.

Even if you’re reaching out to very busy people for this additional authentication, they will understand and appreciate your caution.

These tips are meant as starting points for individuals and organizations to better understand email impersonation and start addressing its risk factors. But effective protection against email impersonation can’t be down to eye tests alone. Enterprise security teams should conduct a thorough audit of their email security stack and explore augments to native email security that offer specific protection against impersonation.

With email more important to our digital lives than ever, it’s vital that we are able to believe people are who their email says they are. Email impersonation attacks exploit this sometimes-misplaced belief. Stopping email impersonation attacks will require a combination of security hygiene, email security solutions that provide specific impersonation protection, and some healthy paranoia while reading emails – even if they seem to be from people you trust.

Data protection predictions for 2021

2020 presented us with many surprises, but the world of data privacy somewhat bucked the trend. Many industry verticals suffered losses, uncertainty and closures, but the protection of individuals and their information continued to truck on.

data protection 2021

After many websites simply blocked access unless you accepted their cookies (now deemed unlawful), we received clarity on cookies from the European Data Protection Board (EDPB). With the ending of Privacy Shield, we witnessed the cessation of a legal basis for cross border data transfers.

Severe fines levied for General Data Protection Regulation (GDPR) non-compliance showed organizations that the regulation is far from toothless and that data protection authorities are not easing up just because there is an ongoing global pandemic.

What can we expect in 2021? Undoubtedly, the number of data privacy cases brought before the courts will continue to rise. That’s not necessarily a bad thing: with each case comes additional clarity and precedent on many different areas of the regulation that, to date, is open to interpretation and conjecture.

Last time I spoke to the UK Information Commissioner’s Office regarding a technicality surrounding data subject access requests (DSARs) submitted by a representative, I was told that I was far from the only person enquiring about it, and this only illustrates some of the ambiguities faced by those responsible for implementing and maintaining compliance.

Of course, this is just the GDPR. There are many other data privacy legislative frameworks to consider. We fully expect 2021 to bring full and complete alignment of the ePrivacy Regulations with GDPR, and eradicate the conflict that exists today, particularly around consent, soft opt-in, etc., where the GDPR is very clear but the current Privacy and Electronic Communication Regulation (PECR) not quite so much.

These are just inside Europe but across the globe we’re seeing continued development of data localization laws, which organizations are mandated to adhere to. In the US, the California Consumer Privacy Act (CCPA) has kickstarted a swathe of data privacy reforms within many states, with many calls for something similar at the federal level.

The following year(s) will see that build and, much like with the GDPR, precedent-setting cases are needed to provide more clarity regarding the rules. Will Americans look to replace the shattered Privacy Shield framework, or will they adopt Standard Contractual Clauses (SCCs) more widely? SCCs are a very strong legal basis, providing the clauses are updated to align with the GDPR (something else we’d expect to see in 2021), and I suspect the US will take this road as the realization of the importance of trade with the EU grows.

Other noteworthy movements in data protection laws are happening in Russia with amendments to the Federal Law on Personal Data, which is taking a closer look at TLS as a protective measure, and in the Philippines, where the Personal Data Protection Act 2021 (PDPA) is being replaced by a new bill (currently a work in progress, but it’s coming).

One of the biggest events of 2021 will be the UK leaving the EU. The British implementation of the GDPR comes in the form of the UK Data Protection Bill 2018. Aside from a few deregulations, it’s the GDPR and that’s great… as far as it goes. Having strong local data privacy laws is good, but after enjoying 47 years (at the time of writing) of free movement within the Union, how will being outside of the EU impact British business?

It is thought and hoped that the UK will be granted an adequacy decision fairly swiftly, given that historically local UK laws aligned with those inside the Union, but there is no guarantee. The uncertainty around how data transfers will look in future might result in the British industry using more SCCs. The currently low priority plans to make Binding Corporate Rules (BCR) easier and more affordable will come sharply to the fore as the demand for them goes up.

One thing is certain, it’s going to be a fascinating year for data privacy and we are excited to see clearer definitions, increased certification, precedent-setting case law and whatever else unfolds as we continue to navigate a journey of governance, compliance and security.

Moving to the cloud with a security-first, zero trust approach

Many companies tend to jump into the cloud before thinking about security. They may think they’ve thought about security, but when moving to the cloud, the whole concept of security changes. The security model must transform as well.

moving to the cloud

Moving to the cloud and staying secure

Most companies maintain a “castle, moat, and drawbridge” attitude to security. They put everything inside the “castle” (datacenter); establish a moat around it, with sharks and alligators, guns on turrets; and control access by raising the drawbridge. The access protocol involves a request for access, vetting through firewall rules where the access is granted or denied. That’s perimeter security.

When moving to the cloud, perimeter security is still important, but identity-based security is available to strengthen the security posture. That’s where a cloud partner skilled at explaining and operating a different security model is needed.

Anybody can grab a virtual machine, build the machine in the cloud, and be done, but establishing a VM and transforming the machine to a service with identity-based security is a different prospect. When identity is added to security, the model looks very different, resulting in cost savings and an increased security posture.

Advanced technology, cost of security, and lack of cybersecurity professionals place a strain on organizations. Cloud providers invest heavily in infrastructure, best-in-class tools, and a workforce uniquely focused on security. As a result, organizations win operationally, financially, and from a security perspective, when moving to the cloud. To be clear, moving applications and servers, as is, to the cloud does not make them secure.

Movement to the cloud should be a standardized process and should use a Cloud Center of Excellence (CCoE) or Cloud Business Office (CBO); however, implemented within a process focused on security first, organizations can reap the security benefits.

Shared responsibility

Although security is marketed as a shared responsibility in the cloud, ultimately, the owner of the data (customer) is responsible and the responsibility is non-transferrable. In short, the customer must understand the responsibility matrix (RACI) involved to accomplish their end goals. Every cloud provider has a shared responsibility matrix, but organizations often misunderstand the responsibilities or the lines fall into a grey area. Regardless of responsibility models, the data owner has a responsibility to protect the information and systems. As a result, the enterprise must own an understanding of all stakeholders, their responsibilities, and their status.

When choosing a partner, it’s vital for companies to identify their exact needs, their weaknesses, and even their culture. No cloud vendor will cover it all from the beginning, so it’s essential that organizations take control and ask the right questions (see Cloud Security Alliance’s CAIQ), in order to place trust in any cloud provider. If it’s to be a managed service, for example, it’s crucial to ask detailed questions about how the cloud provider intends to execute the offering.

It’s important to develop a standard security questionnaire and probe multiple layers deep into the service model until the provider is unable to meet the need. Looking through a multilayer deep lens allows the customer and service provider to understand the exact lines of responsibility and the details around task accomplishment.

Trust-as-a-Service

It might sound obvious, but it’s worth stressing: trust is a shared responsibility between the customer and cloud provider. Trust is also earned over time and is critical to the success of the customer-cloud provider relationship. That said, zero trust is a technical term that means, from a technology viewpoint, assume danger and breach. Organizations must trust their cloud provider but should avoid blind trust and validate. Trust as a Service (TaaS) is a newer acronym that refers to third-party endorsement of a provider’s security practices.

Key influencers of a customer’s trust in their cloud provider include:

  • Data location
  • Investigation status and location of data
  • Data segregation (keeping cloud customers’ data separated from others)
  • Availability
  • Privileged access
  • Backup and recovery
  • Regulatory compliance
  • Long-term viability

A TaaS example: Google Cloud

Google has taken great strides to earn customer trust, designing the Google Cloud Platform with a key eye on zero trust and its implementation of the model BeyondCorp. For example, Google has implemented two core concepts including:

  • Delivery of services and data: ensuring that people with the correct identity and the right purpose can access the required data every time
  • Prioritization and focus: access and innovation are placed ahead of threats and risks, meaning that as products are innovated, security is built into the environment

Transparency is very important to the trust relationship. Google has enabled transparency through strong visibility and control of data. When evaluating cloud providers, understanding their transparency related to access and service status is crucial. Google ensures transparency by using specific controls including:

  • Limited data center access from a physical standpoint, adhering to strict access controls
  • Disclosing how and why customer data is accessed
  • Incorporating a process of access approvals

Multi-layered security for a trusted infrastructure

Finally, cloud services must provide customers with an understanding of how each layer of infrastructure works and build rules into each. This includes operational and device security, encrypting data at rest, multiple layers of identity, and finally storage services: multi-layered, and supported by security by default.

Cloud native companies have a security-first approach and naturally have a higher security understanding and posture. That said, when choosing a cloud provider, enterprises should always understand, identify, and ensure that their cloud solution addresses each one of their security needs, and who’s responsible for what.

Essentially, every business must find a cloud partner that can answer all the key questions, provide transparency, and establish a trusted relationship in the zero trust world where we operate.

Preventing cybersecurity’s perfect storm

Zerologon might have been cybersecurity’s perfect storm: that moment when multiple conditions collide to create a devastating disaster. Thanks to Secura and Microsoft’s rapid response, it wasn’t.

Zerologon scored a perfect 10 CVSS score. Threats rating a perfect 10 are easy to execute and have deep-reaching impact. Fortunately, they aren’t frequent, especially in prominent software brands such as Windows. Still, organizations that perpetually lag when it comes to patching become prime targets for cybercriminals. Flaws like Zerologon are rare, but there’s no reason to assume that the next attack will not be using a perfect 10 CVSS vulnerability, this time a zero-day.

Zerologon: Unexpected squall

Zerologon escalates a domain user beyond their current role and permissions to a Windows Domain Administrator. This vulnerability is trivially easy to exploit. While it seems that the most obvious threat is a disgruntled insider, attackers may target any average user. The most significant risk comes from a user with an already compromised system.

In this scenario, a bad actor has already taken over an end user’s system but is constrained only to their current level of access. By executing this exploit, the bad actor can break out of their existing permissions box. This attack grants them the proverbial keys to the kingdom in a Windows domain to access whatever Windows-based devices they wish.

Part of why Zerologon is problematic is that many organizations rely on Windows as an authoritative identity for a domain. To save time, they promote their Windows Domain Administrators to an Administrator role throughout the organizational IT ecosystem and assign bulk permissions, rather than adding them individually. This method eases administration by removing the need to update the access permissions frequently as these users change jobs. This practice violates the principle of least privilege, leaving an opening for anyone with a Windows Domain Administrator role to exercise broad-reaching access rights beyond what they require to fulfill the role.

Beware of sharks

Advanced preparation for attacks like these requires a fundamental paradigm shift in organizational boundary definitions away from a legacy mentality to a more modern cybersecurity mindset. The traditional castle model assumes all threats remain outside the firewall boundary and trust everything either natively internal or connected via VPN to some degree.

Modern cybersecurity professionals understand the advantage of controls like zero standing privilege (ZSP), which authorizes no one and requires that each user request access and evaluation before granting privileged access. Think of it much like the security check at an airport. To get in, everyone —passenger, pilot, even store staff— needs to be inspected, prove they belong and have nothing questionable in their possession.

This continual re-certification prevents users from gaining access once they’ve experienced an event that alters their eligibility, such as leaving the organization or changing positions. Checking permissions before approving them ensures only those who currently require a resource can access it.

My hero zero (standing privilege)

Implementing the design concept of zero standing privilege is crucial to hardening against privilege escalation attacks, as it removes the administrator’s vast amounts of standing power and access. Users acquire these rights for a limited period and only on an as-needed basis. This Just-In-Time (JIT) method of provisioning creates a better access review process. Requests are either granted time-bound access or flagged for escalation to a human approver, ensuring automation oversight.

An essential component of zero standing privilege is avoiding super-user roles and access. Old school practitioners may find it odd and question the impact on daily administrative tasks that keep the ecosystem running. Users manage these tasks through heavily logged time-limited permission assignments. Reliable user behavior analytics, combined with risk-based privileged access management (PAM) and machine learning supported log analysis, offers organizations better contextual identity information. Understanding how their privileged access is leveraged and identifying access misuse before it takes root is vital to preventing a breach.

Peering into the depths

To even start with zero standing privilege, an organization must understand what assets they consider privileged. The categorization of digital assets begins the process. The next step is assigning ownership of these resources. Doing this allows organizations to configure the PAM software to accommodate the policies and access rules defined organizationally, ensuring access rules meet governance and compliance requirements.

The PAM solution requires in-depth visibility of each individual’s full access across all cloud and SaaS environments, as well as throughout the internal IT infrastructure. This information improves the identification of toxic combinations, where granted permissions create compliance issues such as segregation of duties (SoD) violations.

AI & UEBA to the rescue

Zero standing privilege generates a large number of user logs and behavioral information over time. Manual log review becomes unsustainable very quickly. Leveraging the power of AI and machine learning to derive intelligent analytics allows organizations to identify risky behaviors and locate potential breaches far faster than human users.

Integration of a user and entity behavior analytics (UEBA) software establishes baselines of behavior, triggering alerts when deviations occur. UEBA systems detect insider threats and advanced persistent threats (APTs) while generating contextual identity information.

UEBA systems track all behavior linked back to an entity and identify anomalous behaviors such as spikes in access requests, requesting access to data that would typically not be allowed for that user’s roles, or systematically accessing numerous items. Contextual information helps organizations identifying situations that might indicate a breach or point to unauthorized exfiltration of data.

Your compass points to ZTA

Protecting against privilege escalation threats requires more than merely staying up to date on patches. Part of stopping attacks like Zerologon is to re-imagine how security is architected in an organization. Centering identity as the new security perimeter and implementing zero standing privilege are essential to the foundation of a security model known as zero trust architecture (ZTA).

Zero trust architecture has existed for a while in the corporate world. It is gaining attention from the public sector since NIST’s recent approval of SP-207 outlined ZTA and how to leverage it for the government agencies. NIST’s sanctification of ZTA opened the doors for government entities and civilian contractors to incorporate it into their security model. Taking this route helps to close the privilege escalation pathway providing your organization a secure harbor in the event of another cybersecurity perfect storm.

Can we trust passwordless authentication?

We are beginning to shift away from what has long been our first and last line of defense: the password. It’s an exciting time. Since the beginning, passwords have aggravated people. Meanwhile, passwords have become the de facto first step in most attacks. Yet I can’t help but think, what will the consequences of our actions be?

trust passwordless

Intended and unintended consequences

Back when overhead cameras came to the express toll routes in Ontario, Canada, it wasn’t long before the SQL injection to drop tables made its way onto bumper stickers. More recently in California, researcher Joe Tartaro purchased a license plate that said NULL. With the bumper stickers, the story goes, everyone sharing the road would get a few hours of toll-free driving. But with the NULL license plate? Tartaro ended up on the hook for every traffic ticket with no plate specified, to the tune of thousands of dollars.

One organization I advised recently completed an initiative to reduce the number of agents on the endpoint. In a year when many are extending the lifespan and performance of endpoints while eliminating location-dependent security controls, this shift makes strategic sense.

Another CISO I spoke with recently consolidated multi-factor authenticators onto a single platform. Standardizing the user experience and reducing costs is always a pragmatic move. Yet these moves limited future moves. In both cases, any initiative by the security team which changed authenticators or added agents ended up stuck in park, waiting for a greenlight.

Be careful not to limit future moves

To make moves that open up possibilities, security teams think along two lines: usability and defensibility. That is, how will the change impact the workforce, near term and long term? On the opposite angle, how will the change affect criminal behavior, near term and long term?

Whether decreasing the number of passwords required through single sign-on (SSO) or eliminating the password altogether in favor of a strong authentication factor (passwordless), the priority is on the workforce experience. The number one reason for tackling the password problem given by security leaders is improving the user experience. It is a rare security control that makes people’s lives easier and leadership wants to take full advantage.

There are two considerations when planning for usability. The first is ensuring the tactic addresses the common friction points. For example, with passwordless, does the approach provide access to devices and applications people work with? Is it more convenient and faster what they do today? The second consideration is evaluating what the tactic allows the security team to do next. Does the approach to passwordless or SSO block a future initiative due to lock-in? Or will the change enable us to take future steps to secure authentication?

Foiling attackers

The one thing we know for certain is, whatever steps we take, criminals will take steps to get around us. In the sixty years since the first password leak, we’ve done everything we can, using both machine and man. We’ve encrypted passwords. We’ve hashed them. We increased key length and algorithm strength. At the same time, we’ve asked users to create longer passwords, more complex passwords, unique passwords. We’ve provided security awareness training. None of these steps were taken in a vacuum. Criminals cracked files, created rainbow tables, brute-forced and phished credentials. Sixty years of experience suggests the advancement we make will be met with an advanced attack.

We must increase the trust in authentication while increasing usability, and we must take steps that open up future options. Security teams can increase trust by pairing user authentication with device authentication. Now the adversary must both compromise the authentication and gain access to the device.

To reduce the likelihood of device compromise, set policies to prevent unpatched, insecure, infected, or compromised devices from authenticating. The likelihood can be even further reduced by capturing telemetry, modeling activity, and comparing activity to the user’s baseline. Now the adversary must compromise authentication, gain access to the endpoint device, avoid endpoint detection, and avoid behavior analytics.

Conclusion

Technology is full of unintended consequences. Some lead to tollfree drives and others lead to unexpected fees. Some open new opportunities, others new vulnerabilities. Today, many are moving to improve user experience by reducing or removing passwords. The consequences won’t be known immediately. We must ensure our approach meets the use cases the workforce cares about while positioning us to address longer-term goals and challenges.

Additionally, we must get ahead of adversaries and criminals. With device trust and behavior analytics, we must increase trust in passwordless authentication. We can’t predict what is to come, but these are steps security teams can take today to better position and protect our organizations.

New research shows risk in healthcare supply chain

Exposures and cybersecurity challenges can turn out to be costly, according to statistics from the US Department of Health and Human Services (HHS), 861 breaches of protected health information have been reported over the last 24 months.

healthcare supply chain

New research from RiskRecon and the Cyentia Institute pinpointed risk in third-party healthcare supply chain and showed that healthcare’s high exposure rate indicates that managing a comparatively small Internet footprint is a big challenge for many organizations in that sector.

But there is a silver lining: gaining the visibility needed to pinpoint and rectify exposures in the healthcare risk surface is feasible.

Key findings

The research and report are based on RiskRecon’s assessment of more than five million of internet-facing systems across approximately 20,000 organizations, focusing exclusively on the healthcare sector.

Highest rate

Healthcare has one of the highest average rates of severe security findings relative to other industries. Furthermore, those rates vary hugely across institutions, meaning the worst exposure rates in healthcare are worse than the worst exposure rates in other sectors.

Size matters

Severe security findings decrease as employees increase. For example, the rate of severe security findings in the smallest healthcare providers is 3x higher than that of the largest providers.

Sub sectors vary

Sub sectors within healthcare reveal different risk trends. The research shows that hospitals have a much larger Internet surface area (hosts, providers, countries), but maintain relatively low rates of security findings. Additionally, nursing and residential care sub-sector has the smallest Internet footprint yet the highest levels of exposure. Outpatient (ambulatory) and social services mostly fall in between hospitals and nursing facilities.

Cloud deployment impacts

As digital transformation ushers in a plethora of changes, critical areas of risk exposure are also changing and expanding. While most healthcare firms host a majority of their Internet-facing systems on-prem, they do also leverage the cloud. We found that healthcare’s severe finding rate for high-value assets in the cloud is 10 times that of on-prem. This is the largest on-prem versus cloud exposure imbalance of any sector.

It must also be noted that not all cloud environments are the same. A previous RiskRecon report on the cloud risk surface discovered an average 12 times the difference between cloud providers with the highest and lowest exposure rates. This says more about the users and use cases of various cloud platforms than intrinsic security inequalities. In addition, as healthcare organizations look to migrate to the cloud, they should assess their own capabilities for handling cloud security.

The healthcare supply chain is at risk

It’s important to realize that the broader healthcare ecosystem spans numerous industries and these entities often have deep connections into the healthcare provider’s facilities, operations, and information systems. Meaning those organizations can have significant ramifications for third-party risk management.

When you dig into it, even though big pharma has the biggest footprint (hosts, third-party service providers, and countries of operation), they keep it relatively hygienic. Manufacturers of various types of healthcare apparatus and instruments show a similar profile of extensive assets yet fewer findings. Unfortunately, the information-heavy industries of medical insurance, EHR systems providers, and collection agencies occupy three of the top four slots for the highest rate of security findings.

“In 2020, Health Information Sharing and Analysis Center (H-ISAC) members across healthcare delivery, big pharma, payers and medical device manufacturers saw increased cyber risks across their evolving and sometimes unfamiliar supply chains,” said Errol Weiss, CSO at H-ISAC.

“Adjusting to the new operating environment presented by COVID-19 forced healthcare companies to rapidly innovate and adopt solutions like cloud technology that also added risk with an expanded digital footprint to new suppliers and partners with access to sensitive patient data.”

Three best practices for responsible open source usage in the COVID-19 era

COVID-19 has forced developer agility into overdrive, as the tech industry’s quick push to adapt to changing dynamics has accelerated digital transformation efforts and necessitated the rapid introduction of new software features, patches, and functionalities.

open source code

During this time, organizations across both the private and public sector have been turning to open source solutions as a means to tackle emerging challenges while retaining the rapidity and agility needed to respond to evolving needs and remain competitive.

Since well before the pandemic, software developers have leveraged open source code as a means to speed development cycles. The ability to leverage pre-made packages of code rather than build software from the ground up has enabled them to save valuable time. However, the rapid adoption of open source has not come without its own security challenges, which developers and organizations should resolve safely.

Here are some best practices developers should follow when implementing open source code to promote security:

Know what and where open source code is in use

First and foremost, developers should create and maintain a record of where open source code is being used across the software they build. Applications today are usually designed using hundreds of unique open source components, which then reside in their software and workspaces for years.

As these open source packages age, there is an increasing likelihood of vulnerabilities being discovered in them and publicly disclosed. If the use of components is not closely tracked against the countless new vulnerabilities discovered every year, software leveraging these components becomes open to exploitation.

Attackers understand all too well how often teams fall short in this regard, and software intrusions via known open source vulnerabilities are a highly common sources of breaches. Tracking open source code usage along with vigilance around updates and vulnerabilities will go a long way in mitigating security risk.

Understand the risks before adopting open source

Aside from tracking vulnerabilities in the code that’s already in use, developers must do their research on open source components before adopting them to begin with. While an obvious first step is ensuring that there are no known vulnerabilities in the component in question, other factors should be considered focused on the longevity of the software being built.

Teams should carefully consider the level of support offered for a given component. It’s important to get satisfactory answers to questions such as:

  • How often is the component patched?
  • Are the patches of high quality and do they address the most pressing security issues when released?
  • Once implemented, are they communicated effectively and efficiently to the user base?
  • Is the group or individual who built the component a trustworthy source?

Leverage automation to mitigate risk

It’s no secret that COVID-19 has altered developers’ working conditions. In fact, 38% of developers are now releasing software monthly or faster, up from 27% in 2018. But this increased pace often comes paired with unwanted budget cuts and organizational changes. As a result, the imperative to “do more with less” has become a rallying cry for business leaders. In this context, it is indisputable that automation across the entire IT security portfolio has skyrocketed to the top of the list of initiatives designed to improve operational efficiency.

While already an important asset for achieving true DevSecOps agility, automated scanning technology has become near-essential for any organization attempting to stay secure while leveraging open source code. Manually tracking and updating open source vulnerabilities across an organization’s entire software suite is hard work that only increases in difficulty with the scale of an organization’s software deployments. And what was inefficient in normal times has become unfeasible in the current context.

Automated scanning technologies alleviate the burden of open source security by handling processes that would otherwise take up precious time and resources. These tools are able to detect and identify open source components within applications, provide detailed risk metrics regarding open source vulnerabilities, and flag outdated libraries for developers to address. Furthermore, they provide detailed insight into thousands of public open source vulnerabilities, security advisories and bugs, to ensure that when components are chosen they are secure and reputable.

Finally, these tools help developers prioritize and triage remediation efforts once vulnerabilities are identified. Equipped with the knowledge of which vulnerabilities present the greatest risk, developers are able to allocate resources most efficiently to ensure security does not get in the way of timely release cycles.

Confidence in a secure future

When it comes to open source security, vigilance is the name of the game. Organizations must be sure to reiterate the importance of basic best practices to developers as they push for greater speed in software delivery.

While speed has long been understood to come at the cost of software security, this type of outdated thinking cannot persist, especially when technological advancements in automation have made such large strides in eliminating this classically understood tradeoff. By following the above best practices, organizations can be more confident that their COVID-19 driven software rollouts will be secure against issues down the road.

The brain of the SIEM and SOAR

SIEM and SOAR solutions are important tools in a cybersecurity stack. They gather a wealth of data about potential security incidents throughout your system and store that info for review. But just like nerve endings in the body sending signals, what good are these signals if there is no brain to process, categorize and correlate this information?

siem soar tools

A vendor-agnostic XDR (Extended Detection and Response) solution is a necessary component for solving the data overload problem – a “brain” that examines all of the past and present data collected and assigns a collective meaning to the disparate pieces. Without this added layer, organizations are unable to take full advantage of their SIEM and SOAR solutions.

So, how do organizations implement XDR? Read on.

SIEM and SOAR act like nerves

It’s easy for solutions with acronyms to cause confusion. SOAR and SIEM are perfect examples, as they are two very different technologies that often get lumped together. They aren’t the same thing, and they do bring complementary capabilities to the security operations center, but they still don’t completely close the automation gap.

The SIEM is a decades-old solution that uses technology from that era to solve specific problems. At their core, SIEMs are data collection, workflow and rules engines that enable users to sift through alerts and group things together for investigation.

In the last several years, SOAR has been the favorite within the security industry’s marketing landscape. Just as the SIEM runs on rules, the SOAR runs on playbooks. These playbooks let an analyst automate steps in the event detection, enrichment, investigation and remediation process. And just like with SIEM rules, someone has to write and update them.

Because many organizations already have a SIEM, it seemed reasonable for the SOAR providers to start with automating the output from the SIEM tool or security platform console. So: Security controls send alerts to a SIEM > the SIEM uses rules written by the security team to filter down the number of alerts to a much smaller number, usually 1,000,000:1 > SIEM events are sent to the SOAR, where playbooks written by the security team use workflow automation to investigate and respond to the alerts.

SOAR investigation playbooks attempt to contextualize the events with additional data – often the same data that the SIEM has filtered out. Writing these investigation playbooks can occupy your security team for months, and even then, they only cover a few scenarios and automate simple tasks like virus total lookups.

The verdict is that SOARs and SIEMs purport to perform all the actions necessary to automate the screening of alerts, but the technology in itself cannot do this. It requires trained staff to bring forth this capability by writing rules and playbooks.

Coming back to the analogy, this data can be compared to the nerves flowing through the human body. They fire off alerts that something has happened – alerts that mean nothing without a processing system that can gather context and explain what has happened.

Giving the nerves a brain

What the nerves need is a brain that can receive and interpret their signals. An XDR engine, powered by Bayesian reasoning, is a machine-powered brain that can investigate any output from the SIEM or SOAR at speed and scale. This replaces the traditional Boolean logic (that is searching for things that IT teams know to be somewhat suspicious) with a much richer way to reason about the data.

This additional layer of understanding will work out of the box with the products an organization already has in place to provide key correlation and context. For instance, imagine that a malicious act occurs. That malicious act is going to be observed by multiple types of sensors. All of that information needs to be put together, along with the context of the internal systems, the external systems and all of the other things that integrate at that point. This gives the system the information needed to know the who, what, when, where, why and how of the event.

This is what the system’s brain does. It boils all of the data down to: “I see someone bad doing something bad. I have discovered them. And now I am going to manage them out.” What the XDR brain is going to give the IT security team is more accurate, consistent results, fewer false positives and faster investigation times.

How to apply an XDR brain

To get started with integrating XDR into your current system, take these three steps:

1. Deploy a solution that is vendor-agnostic and works out of the box. This XDR layer of security doesn’t need playbooks or rules. It changes the foundation of your security program and how your staff do their work. This reduces your commitment in time and budget for security engineering, or at least enables you to redirect it.

2. It has become much easier in the last several years to collect, store and – to some extent – analyze data. In particular, cloud architectures offer simple and cost-effective options for collecting and storing vast quantities of data. For this reason, it’s now possible to turn your sensors all the way up rather than letting in just a small stream of data.

3. Decide which risk reduction projects are critical for the team. Automation should release security professionals from mundane tasks so they can focus on high-value actions that truly reduce risk, like incident response, hunting and tuning security controls. There may also be budget that is freed up for new technology or service purchases.

Reading the signals

To make the most of SOARs and SIEMs, you XDR – a tool that will take the data collected and add the context needed to turn thousands of alerts into one complete situation that is worth investigating.

The XDR layer is an addition to a company’s cybersecurity strategy that will most effectively use SIEM and SOAR, giving all those nerve signals a genius brain that can sort them out and provide the context needed in today’s cyber threat landscape.

In the era of AI, standards are falling behind

According to a recent study, only a minority of software developers are actually working in a software development company. This means that nowadays literally every company builds software in some form or another.

standards development

As a professional in the field of information security, it is your task to protect information, assets, and technologies. Obviously, the software built by or for your company that is collecting, transporting, storing, processing, and finally acting upon your company’s data, is of high interest. Secure development practices should be enforced early on and security must be tested during the software’s entire lifetime.

Within the (ISC)² common body of knowledge for CISSPs, software development security is listed as an individual domain. Several standards and practices covering security in the Software Development Lifecycle (SDLC) are available: ISO/IEC 27024:2011, ISO/IEC TR 15504, or NIST SP800-64 Revision 2, to name some.

All of the above ask for continuous assessment and control of artifacts on the source-code level, especially regarding coding standards and Common Weakness Enumerations (CWE), but only briefly mention static application security testing (SAST) as a possible way to address these issues. In the search for possible concrete tools, NIST provides SP 500-268 v1.1 “Source Code Security Analysis Tool Function Specification Version 1.1”.

In May 2019, NIST withdrew the aforementioned SP800-64 Rev2. NIST SP 500-268 was published over nine years ago. This seems to be symptomatic for an underlying issue we see: the standards cannot keep up with the rapid pace of development and change in the field.

A good example is the dawn of the development language Rust, which addresses a major source of security issues presented by the classically used language C++ – namely memory management. Major players in the field such as Microsoft and Google saw great advantages and announced that they would focus future developments towards Rust. While the standards mention development languages superior to others, neither the mechanisms used by Rust nor Rust itself is mentioned.

In the field of Static Code Analysis, the information in NIST SP 500-268 is not wrong, but the paper simply does not mention advances in the field.

Let us briefly discuss two aspects: First, the wide use of open source software gave us insight into a vast quantity of source code changes and the reasoning behind them (security, performance, style). On top of that, we have seen increasing capacities of CPU power to process this data, accompanied by algorithmic improvements. Nowadays, we have a large lake of training data available. To use our company as an example, in order to train our underlying model for C++ alone, we are scanning changes in over 200,000 open source projects with millions of files containing rich history.

Secondly, in the past decade, we’ve witnessed tremendous advances in machine learning. We see tools like GPT-3 and their applications in source code being discussed widely. Classically, static source code analysis was the domain of Symbolic AI—facts and rules applied to source code. The realm of source code is perfectly suited for this approach since software source code has a well-defined syntax and grammar. The downside is that these rules were developed by engineers, which limits the pace in which rules can be generated. The idea would be to automate the rule construction by using machine learning.

Recently, we see research in the field of machine learning being applied to source code. Again, let us use our company as an example: By using the vast amount of changes in open source, our system looks out for patterns connected to security. It presents possible rules to an engineer together with found cases in the training set—both known and fixed, as well as unknown.

Also, the system supports parameters in the rules. Possible values for these parameters are collected by the system automatically. As a practical example, taint analysis follows incoming data to its use inside of the application to make sure the data is sanitized before usage. The system automatically learns possible sources, sanitization, and sink functions.

Back to the NIST Special Papers: With the withdrawal of SP 800-64 Rev 2, users were pointed to NIST SP 800-160 Vol 1 for the time being until a new, updated white paper is published. This was at the end of May 2019. The nature of these papers is to only describe high-level best practices, list some examples, and stay rather vague in concrete implementation. Yet, the documents are the basis for reviews and audits. Given the importance of the field, it seems as if a major component is missing. It is also time to think about processes that would help us to keep up with the pace of technology.

CPRA: More opportunity than threat for employers

Increasingly demanded by consumers, data privacy laws can create onerous burdens on even the most well-meaning businesses. California presents plenty of evidence to back up this statement, as more than half of organizations that do business in California still aren’t compliant with the California Consumer Privacy Act (CCPA), which went into effect earlier this year.

CPRA

As companies struggle with their existing compliance requirements, many fear that a new privacy ballot initiative – the California Privacy Rights Act (CPRA) – could complicate matters further. While it’s true that if passed this November, the CPRA would fundamentally change the way businesses in California handle both customer and employee data, companies shouldn’t panic. In fact, this law presents an opportunity for organizations to change their relationship with employee data to their benefit.

CPRA, the Californian GDPR?

Set to appear on the November 2020 ballot, the CPRA, also known as CCPA 2.0 or Prop 24 (its name on the ballot), builds on what is already the most comprehensive data protection law in the US. In essence, the CPRA will bring data protection in California nearer to the current European legal standard, the General Data Protection Regulation (GDPR).

In the process of “getting closer to GDPR,” the CCPA would gain substantial new components. Besides enhancing consumer rights, the CPRA also creates new provisions for employee data as it relates to their employers, as well as data that businesses collect from B2B business partners.

Although controversial, the CPRA is likely to pass. August polling shows that more than 80% of voters support the measure. However, many businesses do not. This is because, at first glance, the CPRA appears to create all kinds of legal complexities in how employers can and cannot collect information from workers.

Fearful of having to meet the same demanding requirements as their European counterparts, many organizations’ natural reaction towards the prospect of CPRA becoming law is fear. However, this is unfounded. In reality, if the CPRA passes, it might not be as scary as some businesses think.

CPRA and employment data

The CPRA is actually a lot more lenient than the GDPR in regard to how it polices the relationship between employers and employees’ data. Unlike for its EU equivalent, there are already lots of exceptions written into the proposed Californian law acknowledging that worker-employer relations are not like consumer-vendor relations.

Moreover, the CPRA extends the CCPA exemption for employers, set to end on January 1, 2021. This means that if the CPRA passes into law, employers would be released from both their existing and potential new employee data protection obligations for two more years, until January 1, 2023. This exemption would apply to most provisions under the CPRA, including the personal information collected from individuals acting as job applicants, staff members, employees, contractors, officers, directors, and owners.

However, employers would still need to provide notice of data collection and maintain safeguards for personal information. It’s highly likely that during this two-year window, additional reforms would be passed that might further ease employer-employee data privacy requirements.

Nonetheless, employers should act now

While the CPRA won’t change much overnight, impacted organizations shouldn’t wait to take action, but should take this time to consider what employee data they collect, why they do so, and how they store this information.

This is especially pertinent now that businesses are collecting more data than ever on their employees. With companies like the workplace monitoring company Prodoscore reporting that interest from prospective customers rose by 600% since the pandemic began, we are seeing rapid growth in companies looking to monitor how, where, and when their employees work.

This trend emphasizes the fact that the information flow between companies and their employees is mostly one-sided (i.e., from the worker to the employer). Currently, businesses have no legal requirement to be transparent about this information exchange. That will change for California-based companies if the CPRA comes into effect and they will have no choice but to disclose the type of data they’re collecting about their staff.

The only sustainable solution for impacted businesses is to be transparent about their data collection with employees and work towards creating a “culture of privacy” within their organization.

Creating a culture of privacy

Rather than viewing employee data privacy as some perfunctory obligation where the bare minimum is done for the sake of appeasing regulators, companies need to start thinking about worker privacy as a benefit. Presented as part of a benefits package, comprehensive privacy protection is a perk that companies can offer prospective and existing employees.

Privacy benefits can include access to privacy protection services that give employees privacy benefits beyond the workplace. Packaged alongside privacy awareness training and education, these can create privacy plus benefits that can be offered to employees alongside standard perks like health or retirement plans. Doing so will build a culture of privacy which can help companies ensure they’re in regulatory compliance, while also making it easier to attract qualified talent and retain workers.

It’s also worth bearing in mind that creating a culture of privacy doesn’t necessarily mean that companies have to stop monitoring employee activity. In fact, employees are less worried about being watched than they are by the possibility of their employers misusing their data. Their fears are well-founded. Although over 60% of businesses today use workforce data, only 3 in 10 business leaders are confident that this data is treated responsibly.

For this reason, companies that want to keep employee trust and avoid bad PR need to prioritize transparency. This could mean drawing up a “bill of rights” that lets employees know what data is being collected and how it will be used.

Research into employee satisfaction backs up the value of transparency. Studies show that while only 30% of workers are comfortable with their employer monitoring their email, the number of employees open to the use of workforce data goes up to 50% when the employer explains the reasons for doing so. This number further jumps to 92% if employees believe that data collection will improve their performance or well-being or come with other personal benefits, like fairer pay.

On the other hand, most employees would leave an organization if its leaders did not use workplace data responsibly. Moreover, 55% of candidates would not even apply for a job with such an organization in the first place.

Final thoughts

With many exceptions for workplace data management already built-in and more likely to come down the line, most employers should be able to easily navigate the stipulations CPRA entails.

That being said, if it becomes law this November, employers shouldn’t misuse the two-year window they have to prepare for new compliance requirements. Rather than seeing this time as breathing space before a regulatory crackdown, organizations should instead use it to be proactive in their approach to how they manage their employees’ data. As well as just ensuring they comply with the law, businesses should look at how they can turn employee privacy into an asset.

As data privacy stays at the forefront of employees’ minds, businesses that can show they have a genuine privacy culture will be able to gain an edge when it comes to attracting and retaining talent and, ultimately, coming out on top.

The anatomy of an endpoint attack

Cyberattacks are becoming increasingly sophisticated as tools and services on the dark web – and even the surface web – enable low-skill threat actors to create highly evasive threats. Unfortunately, most of today’s modern malware evades traditional signature-based anti-malware services, arriving to endpoints with ease. As a result, organizations lacking a layered security approach often find themselves in a precarious situation. Furthermore, threat actors have also become extremely successful at phishing users out of their credentials or simply brute forcing credentials thanks to the widespread reuse of passwords.

A lot has changed across the cybersecurity threat landscape in the last decade, but one thing has remained the same: the endpoint is under siege. What has changed is how attackers compromise endpoints. Threat actors have learned to be more patient after gaining an initial foothold within a system (and essentially scope out their victim).

Take the massive Norsk Hydro ransomware attack as an example: The initial infection occurred three months prior to the attacker executing the ransomware and locking down much of the manufacturer’s computer systems. That was more than enough time for Norsk to detect the breach before the damage could done, but the reality is most organization simply don’t have a sophisticated layered security strategy in place.

In fact, the most recent IBM Cost of a Data Breach Report found it took organizations an average of 280 days to identify and contain a breach. That’s more than 9 months that an attacker could be sitting on your network planning their coup de grâce.

So, what exactly are attackers doing with that time? How do they make their way onto the endpoint undetected?

It usually starts with a phish. No matter what report you choose to reference, most point out that around 90% of cyberattacks start with a phish. There are several different outcomes associated with a successful phish, ranging from compromised credentials to a remote access trojan running on the computer. For credential phishes, threat actors have most recently been leveraging customizable subdomains of well-known cloud services to host legitimate-looking authentication forms.

anatomy endpoint attack

The above screenshot is from a recent phish WatchGuard Threat Lab encountered. The link within the email was customized to the individual recipient, allowing the attacker to populate the victim’s email address into the fake form to increase credibility. The phish was even hosted on a Microsoft-owned domain, albeit on a subdomain (servicemanager00) under the attacker’s control, so you can see how an untrained user might fall for something like this.

In the case of malware phishes, attackers (or at least the successful ones) have largely stopped attaching malware executables to emails. Most people these days recognize that launching an executable email attachment is a bad idea, and most email services and clients have technical protections in place to stop the few that still click. Instead, attackers leverage dropper files, usually in the form of a macro-laced Office document or a JavaScript file.

The document method works best when recipients have not updated their Microsoft Office installations or haven’t been trained to avoid macro-enabled documents. The JavaScript method is a more recently popular method that leverages Windows’ built-in scripting engine to initiate the attack. In either case, the dropper file’s only job is to identify the operating system and then call home and grab a secondary payload.

That secondary payload is usually a remote-access trojan or botnet of some form that includes a suite of tools like keyloggers, shell script-injectors, and the ability to download additional modules. The infection isn’t usually limited to the single endpoint for long after this. Attackers can use their foothold to identify other targets on the victim’s network and rope them in as well.

It’s even easier if the attackers manage to get hold of a valid set of credentials and the organization hasn’t deployed multi-factor authentication. It allows the threat actor to essentially walk right in through the digital front door. They can then use the victim’s own services – like built-in Windows scripting engines and software deployment services – in a living-off-the-land attack to carry out malicious actions. We commonly see threat actors leverage PowerShell to deploy fileless malware in preparation to encrypt and/or exfiltrate critical data.

The WatchGuard Threat Lab recently identified an ongoing infection while onboarding a new customer. By the time we arrived, the threat actor had already been on the victim’s network for some time thanks to compromising at least one local account and one domain account with administrative permissions. Our team was not able to identify how exactly the threat actor obtained the credentials, or how long they had been present on the network, but as soon as our threat hunting services were turned on, indicators immediately lit up identifying the breach.

In this attack, the threat actors used a combination of Visual Basic Scripts and two popular PowerShell toolkits – PowerSploit and Cobalt Strike – to map out the victim’s network and launch malware. One behavior we saw came from Cobalt Strike’s shell code decoder enabled the threat actors to download malicious commands, load them into memory, and execute them directly from there, without the code ever touching the victim’s hard drive. These fileless malware attacks can range from difficult to impossible to detect with traditional endpoint anti-malware engines that rely on scanning files to identify threats.

anatomy endpoint attack

Elsewhere on the network our team saw the threat actors using PsExec, a built in Windows tool, to launch a remote access trojan with SYSTEM-level privileges thanks to the compromised domain admin credentials. The team also identified the threat actors attempts to exfiltrate sensitive data to a DropBox account using a command-line based cloud storage management tool.

Fortunately, they were able to identify and clean up the malware quickly. However, without the victim changing the stolen credentials, the attacker could have likely re-initiated their attack at-will. Had the victim deployed an advanced Endpoint Detection and Response (EDR) engine as part of their layered security strategy, they could have stopped or slowed the damage created from those stolen credentials.

Attackers are targeting businesses indiscriminately, even small organizations. Relying on a single layer of protection simply no longer works to keep a business secure. No matter the size of an organization, it’s important to adopt a layered security approach that can detect and stop modern endpoint attacks. This means protections from the perimeter down to the endpoint, including user training in the middle. And, don’t forget about the role of multifactor authentication (MFA) – could be the difference between stopping an attack and becoming another breach statistic.

October 2020 Patch Tuesday forecast: Trick or treat?

It’s October and that means Halloween will be here at the end of the month. It won’t be much fun if we only get to ‘dress up’ and look at each other via video conference. But then, we’ve had a lot of ‘tricks’ thrown at us this last month – Zerologon, explosion of ransomware, COVID phishing attacks, and more. Will we get more tricks next week or are we in for a treat on Patch Tuesday?

October 2020 Patch Tuesday forecast

The Netlogon Elevation of Privilege Vulnerability, CVE-2020-1472, also referred to as the Zerologon vulnerability, dominated the news this past month. The US Department of Homeland Security issued Emergency Directive 20-04 on September 18, requiring all government agencies with a domain controller to update their servers within three days.

Microsoft has also issued updated guidance since the August Patch Tuesday release to clarify the steps needed to secure systems with this vulnerability. Per the outlined process in the article, the first step is to apply the August 11 updates which will begin enforcement of Secure RPC (Remote Procedure Call), but still allow non-compliant devices to connect and log the connections. Full enforcement will begin with the deployment of the February 9, 2021 updates.

All systems in your environment should be updated and monitored between now and February to verify they are configured and using the secure channels properly. Once the February updates are deployed, only vulnerable systems explicitly listed in group policy will be allowed to connect to the domain controller.

It’s not unexpected that the education community has been hit the hardest by cyberattacks in the past several months. Students of all ages are now spending many hours online in daily remote learning sessions and are constantly exposed to a full host of attacks. The Microsoft Security Intelligence center is showing that 62% of malware encounters are affecting this industry.

As funny as it may sound, this is partially an ‘education’ issue. Most students haven’t received any form of security training and need to be aware of phishing attacks and what to look for, the importance of strong passwords, the need to keep personal or ‘sensitive’ information private, and similar practices we in the industry often take for granted.

With the sudden increase of connections from personal computers, many of which are running out-of-date software, it is more important than ever to maintain solid security practices for the infrastructure and support systems. Teachers should be running authorized software and IT must be prepared to apply the latest security updates, especially for programs like Zoom, WebEx, GoToMeeting, etc., which are critical for remote learning. We’ll weather this storm and the good news is that we’ll have a more security-aware group entering the workforce in the upcoming years.

October 2020 Patch Tuesday forecast

  • Microsoft continues to address record numbers of vulnerabilities each month. Expect that to continue in October. Microsoft Exchange Server received a major update last month, so I don’t expect another one. But we will see the standard updates for operating systems and Office, and extended support updates for Windows 7 and Server 2008.
  • Select service stack updates (SSUs) should appear as they usually do.
  • The last security updates for Adobe Acrobat and Reader were in August. There are no pre-announcements on their web site, but we may see an update.
  • Apple will most likely release major security updates for iTunes and iCloud later in October if they maintain their quarterly schedule.
  • Google Chrome 86 was released this Tuesday with significant security updates. Don’t expect any updates around Patch Tuesday.
  • Security updates were released on September 22 for Mozilla Firefox and Thunderbird. We could see some additional updates next week.

In summary, expect the standard set of Microsoft releases, maybe some updates from Adobe, and probably two from Mozilla. Based on this limited list of updates, It sounds like we should be in for a treat!

How to avoid the most common mistakes of an identity governance program

It’s a story I have seen play out many times over two decades in the Identity and Access Management (IAM) field: An organization determines that it needs a more robust Identity Governance and Administration (IGA) program, they kick off a project to realize this goal, but after a promising start, the whole effort falls apart within six to twelve months.

IGA program

What an IGA program does

People become frustrated about wasted time and money. The audit and compliance teams who need IGA grow disappointed, perhaps even anxious. The regulatory risks they are trying to mitigate continue to loom large. Finger pointing ensues, arguing and discord follow.

Don’t get me wrong, a fine-tuned and efficient IGA program is well worth it. An IGA program helps ensure an organization’s data security, assist in completing audits, and support significant boosts in operational agility.

The three common IGA project mistakes

The specific things that can go wrong vary by company, but they follow a sadly familiar pattern. Three common mistakes stand out in particular:

1. Underestimating the costs

An IGA project is an IT project, but it’s so much more. Viewing IGA simply as a matter of buying and installing software is an avoidable error. To work, IGA usually needs advisory services on top of in-house resources. Application integration costs may get under-counted as well, as project stakeholders fail to grasp the interconnected nature of the IGA process. For example, the IGA solution usually has to link with HR management systems and so forth. Training costs can be higher than people predict. Finding people with IGA skills also tends to take longer and cost more than anyone might guess at the outset.

2. Not building for user experience (UX)

IGA end users need to feel comfortable and confident on the system, or the whole project finds itself in jeopardy. People want to get their jobs done. They generally don’t have the time or interest in learning a new system and lexicon. If using the solution isn’t a basically effortless part of their day-to-day work lives, users will seek ways around it. They’ll call the help desk or contact a colleague, claiming they cannot complete IGA tasks. This sort of slow-building mutiny can wreck an IGA program.

3. Failing to secure or sustain C-suite sponsorship

IGA projects can be challenging. They require collaboration across departments. Strong executive sponsorship is critical for success for overcoming potential points of friction. In my experience, one can predict that trouble is on the horizon as soon as the executive sponsor stops coming to status meetings. This usually isn’t the executive’s fault. He or she is simply quite busy and has not been properly briefed on the importance of his or her role in ensuring a good outcome for the investment in IGA.

How to avoid IGA project problems

These pitfalls need not sink an IGA program. Being conscious of the potential problems and addressing them in the project planning stage helps a great deal. Budgeting accurately, thinking through UX, and making expectations clear with executive sponsors provide the basis for IGA success.

There’s also a new approach in IGA implementation that can make a huge difference. It involves integrating the IGA toolset with the existing application platform, a system that everyone is already using for IT-related workloads. These platforms exist in most organizations, a popular example is ServiceNow.

Building IGA on top of an existing platform delivers a number of distinct advantages for the program:

  • It maximizes the current investment in the platform
  • It’s less expensive than purchasing an IGA solution that is its own stack—a savings that applies to both the build and manage phases of its life cycle
  • No new skillsets are required, either, which avoids the costly recruit/train/retain struggles that can arise with standalone IGA solutions
  • Changes to the IGA system are more economical as well when it runs atop a familiar incumbent platform in the organization.

Employees are already using the platform interfaces, so there are few training issues or UX problems inherent in launching an IGA program that is seamlessly integrated into existing processes. Knowledge workers know the interfaces and workflows to request and approve identity governance services. They won’t have to bookmark a new URL or learn a new way of doing things, speeding overall acceptance.

Application platforms are also increasingly becoming one of the main vehicles for digital transformation (DX) projects. This makes sense, given the importance of IT agility and smooth IT operations in the DX vision. By linking IGA with DX, it becomes easier to attract sustainable executive interest in the IGA program.

C-level executives sponsor DX projects, bonuses may hinge on them. They know DX projects are ambitious and potential generators of strong return on investment. With IGA built into DX, the identity governance program will not be neglected.

Avoiding the common pitfalls inherent in launching an IGA program will take some focus and work, but the resulting benefits are well worth the effort. As you look to refresh or improve your current IGA program, consider leveraging what platforms you already have in place to achieve the most successful outcome.

Three common mistakes in ransomware security planning

As the frequency and intensity of ransomware attacks increase, one thing is becoming abundantly clear: organizations can do more to protect themselves. Unfortunately, most organizations are dropping the ball. Most victims receive adequate warning of potential vulnerabilities yet are woefully unprepared to recover when they are hit. Here are just a few recent examples of both prevention and incident response failures:

  • Two months before the city of Atlanta was hit by ransomware in 2018, an audit identified over 1,500 severe security vulnerabilities.
  • Before the city of Baltimore suffered multiple weeks of downtime due to a ransomware attack in 2019, a risk assessment identified a severe vulnerability due to servers running an outdated operating system (and therefore lacking the latest security patches) and insufficient backups to restore those servers, if necessary.
  • Honda was attacked this past June, and public access to Remote Desktop Protocol (RDP) for some machines may have been the attack vector leveraged by hackers. Complicating matters further, there was a lack of adequate network segmentation.

Other notable recent victims include Travelex, Blackbaud, and Garmin. In all these examples, these are large organizations that should have very mature security profiles. So, what’s the problem?

Three common mistakes lead to inadequate prevention and ineffective response, and they are committed by organizations of all sizes:

1. Failing to present risk in business terms, which is crucial to persuading business leaders to provide appropriate funding and policy buy-in.

2. Not going deep enough in how you test your ransomware readiness.

3. Insufficient DR planning that fails to account for a ransomware threat that could infect your backups.

Common mistake #1 – Failing to present security risk in business terms to get funding and policies

I was reminded of just how easy it is to bypass basic security (e.g., firewalls, email security gateways, and anti-malware solutions) when I recently watched a ransomware attack simulation: the initial pre-ransomware payload got a foot in the door, followed by techniques such as reverse DNS lookups to identify an Active Directory service, that has the necessary privileges to really do some damage, and finally Kerberoasting to take control.

No organization is bulletproof, but attacks take time – which means early detection with more advanced intrusion detection and a series of roadblocks for hackers to overcome (e.g., greater network segmentation, appropriate end-user restrictions, etc.) are crucial for prevention.
This is not news to security practitioners. But convincing business leaders to make additional security investments is another challenge altogether.

How to fix mistake #1: Quantify business impact to enable an informed cost-based business decision

Tighter security controls (via technology and policy) are friction for the business. And while no business leader wants to fall victim to ransomware, budgets are not unlimited.

To justify the extra cost and tighter controls, you need to make a business case that presents not just risk, but also quantifiable business impact. Help senior leadership compare apples to apples – in this case, the cost of improved security (capex and potential productivity friction) vs. the cost of a security breach (the direct cost of extended downtime and long-term cost of reputational damage).

Assessing business impact need not be onerous. Fairly accurate impact assessments of critical systems can easily be completed in one day. Focus on a few key applications and datasets to get a representative sample, and get a rough estimate of cost, goodwill, compliance, and/or health & safety impacts, depending on your organization. You don’t have to be exact at this stage to recognize the potential for a critical impact.

Below is an example of the resulting key talking points for a presentation to senior leadership:

ransomware security planning

Source: Info-Tech Research Group, Business Impact Analysis Summary Example, 2020

Common mistake #2 – Not going deep enough in testing ransomware readiness

If you aren’t already engaged in penetration testing to validate security technology and configuration, start now. If you can’t secure funding, re-read How to fix mistake #1.

Where organizations go wrong is stopping at penetration testing and not validating the end-to-end incident response. This is especially critical for larger organizations that need to quickly coordinate assessment, containment, and recovery with multiple teams.

How to fix mistake #2: Run in-depth tabletop planning exercises to cover a range of what-if scenarios

The problem with most tabletop planning exercises is that they are designed to simply validate your existing incident response plans (IRP).
Instead, dive into how an attack might take place and what actions you would take to detect, contain, and recover from the attack. For example, where your IRP says check for other infected systems, get specific in how that would happen. What tools would you use? What data would you review? What patterns would you look for?

It is always an eye-opener when we run tabletop planning with our clients. I’ve yet to come across a client that had a perfect incident response plan. Even organizations with a mature security profile and documented response plans often find gaps such as:

  • Poor coordination between security and infrastructure staff, with unclear handoffs during the assessment phase.
  • Existing tools aren’t fully leveraged (e.g., configuring auto-contain features).
  • Limited visibility into some systems (e.g., IoT devices and legacy systems).

Common mistake #3 – Backup strategies and DR plans don’t account for ransomware scenarios

Snapshots and standard daily backups on rewritable media, as in the example below, just aren’t good enough:

ransomware security planning

Source: Info-Tech Research Group, Outdated Backup Strategy Example, 2020

The ultimate safety net if hackers get in is your ability to restore from backup or failover to a clean standby site/system.

However, a key goal of a ransomware attack is to disable your ability to recover – that means targeting backups and standby systems, not just the primary data. If you’re not explicitly guarding against ransomware all the time, the money you’ve invested to minimize data loss due to traditional IT outages – from drive failures to hurricanes – becomes meaningless.

How to fix mistake #3: Apply defense-in-depth to your backup and DR strategy

The philosophy of defense-in-depth is best practice for security, and the same philosophy needs to be applied to your backups and recovery capabilities.

Defense-in-depth is not just about trying to catch what slips through the cracks of your perimeter security. It’s also about buying time to detect, contain, and recover from the attack.

Achieve defense-in-depth with the following approach:

1. Create multiple restore points so that you can be more granular with your rollback and not lose as much data.

2. Reduce the risk of infected backups by using different storage media (e.g., disk, NAS, and/or tape) and backup locations (i.e., offsite backups). If you can make the attackers jump through more hoops, it gives you a greater chance of detecting the attack before it infects all of your backups. Start with your most critical data and design a solution that considers business need, cost, and risk tolerance.

3. Invest in solutions that generate immutable backups. Most leading backup solutions offer options to ensure backups are immutable (i.e., can’t be altered after they’re written). Expect the cost to be higher, of course, so again consider business impact when deciding what needs higher levels of protection.

Summary: Ransomware security planning

Ransomware attacks can be sophisticated, basic security practices just aren’t good enough. Get buy-in from senior leadership on what it takes to be ransomware-ready by presenting not just the risk of attack, but the potential extensive business impact. Assume you’ll get hit, be ready to respond quickly, test realistically, and update your DR strategy to encompass this fast-evolving threat.

Working together to secure our expanding connected health future

Securing medical devices is not a new challenge. Former Vice President Cheney, for example, had the wireless capabilities of a defibrillator disabled when implanted near his heart in 2007, and hospital IT departments and health providers have for years secured medical devices to protect patient data and meet HIPAA requirements.

connected health

With the expansion of security perimeters, the surge in telehealth usage (particularly during COVID-19), and proliferation in the number and types of connected technologies, healthcare cybersecurity has evolved into a more complex and urgent effort.

Today, larger hospital systems have approximately 350,000+ medical devices running simultaneously. On top of this, millions of additional connected devices are maintained by the patients themselves. Over the next 10 years, it’s estimated the number of connected medical devices could increase to roughly 50 billion, driven by innovations such as 5G, edge computing, and more. This rise in connectivity has increased the threat of cyberattacks not just to patient data, but also patient safety. Vulnerabilities in healthcare technology (e.g., an MRI machine or pacemaker) can lead to patient harm if diagnoses are delayed or the right treatments don’t get to the right people.

What can the healthcare industry do to strengthen their defenses today? How can they lay the groundwork for more secure devices and networks tomorrow?

The challenges are interconnected. The solutions cannot be siloed, and collaboration between manufacturers, doctors, healthcare delivery organizations and regulators is more critical now than ever before.

Device manufacturers: Integrating security into product design

Many organizations view medical device cybersecurity as protecting technology while it is deployed as part of a local network. Yet medical devices also need to be designed and developed with mobile and cloud security in mind, with thoughtful consideration about the patient experience. It is especially important we take this step as medical technology moves beyond the four walls of the hospital and into the homes of patients. The connected device itself needs to be secure, as opposed to the network surrounding the device.

We also need greater visibility and transparency across the medical device supply chain—a “software bill of materials.” The multicomponent nature of many medical products, such as insulin pumps or pacemakers, make the final product feel like a black box: hospitals and users know what it’s intended to do, but they don’t have much understanding about the individual components that make everything work. That makes it difficult to solve cybersecurity problems as they arise.

According to the 2019 HIMSS Cybersecurity Survey, just over 15% of significant security issues were initially started through either medical device problems in hospitals or vendor medical devices. As a result, some of these issues led to ransomware attacks exposing vulnerabilities, as healthcare providers and device makers scrambled to figure out just which of the products were at risk, while their systems were under threat. A software bill of materials would have helped them respond quickly to security, license, and operational risks.

Healthcare delivery organizations: Prioritizing preparedness and patient education

Healthcare providers, for their part, need to strengthen their threat awareness and preparedness, thinking about security from device procurement all the way to the sunsetting of legacy devices, which can extend over years and decades.

It’s currently not uncommon for healthcare facilities to use legacy technology that is 15 to 20 years old. Many of these devices are no longer supported and their security doesn’t meet the baseline of today’s evolving threats. However, as there is no replacement technology that serves the same functions, we need to provide heightened monitoring of these devices.

Threat modeling can help hospitals and providers understand their risks and increase resilience. Training and preparedness exercises are imperative in another critical area of cybersecurity: the humans operating the devices. Such exercises can put doctors, for instance, in an emergency treatment scenario with a malfunctioning device, and the discussions that follow provide valuable opportunities to educate, build awareness of, and proactively prepare for cyber threats.

Providers might consider “cybersecurity informed consent” to educate patients. When a patient signs a form before a procedure that acknowledges potential risks like infection or side effects, cyber-informed consent could include risks related to data breaches, denial of service attacks, ransomware, and more. It’s an opportunity to both manage risk and engage patients in conversations about cybersecurity, increasing trust in the technology that is essential for their health.

Regulators: Connecting a complex marketplace

The healthcare industry in the US is tremendously complex, comprised of hundreds of large healthcare systems, thousands of groups of physician practices, public and private payers, medical device manufacturers, software companies, and so on.

This expanding healthcare ecosystem can make it difficult to coordinate. Groups like the Food & Drug Administration (FDA) and the Healthcare Sector Coordinating Council have been rising to the challenge.

They’ve assembled subgroups and task forces in areas like device development and the treatment of legacy technologies. They’ve been reaching out to hospitals, patients, medical device manufacturers, and others to strengthen information-sharing and preparedness, to move toward a more open, collaborative cybersecurity environment.

Last year, the FDA issued a safety communication to alert health care providers and patients about cybersecurity vulnerabilities identified in a wireless telemetry technology used for communication that impacted more than 20 types of implantable cardiac devices, programmers, and home monitors. Later in 2019, the same device maker recalled thousands of insulin pumps due to unpatchable cyber vulnerabilities.

These are but two examples of many that demonstrate not only the impact of cybersecurity to patient health but to device makers and the healthcare system at large. Connected health should give patients access to approved technologies that can save lives without introducing risks to patient safety.

As the world continues to realize the promise of connected technologies, we must monitor threats, manage risks, and increase our network resilience. Working together to incorporate cybersecurity into device design, industry regulations, provider resilience, and patient education are where we should start.

Contributing author: Shannon Lantzy, Chief Scientist, Booz Allen Hamilton.

Why developing cybersecurity education is key for a more secure future

Cybersecurity threats are growing every day, be they are aimed at consumers, businesses or governments. The pandemic has shown us just how critical cybersecurity is to the successful operation of our respective economies and our individual lifestyles.

developing cybersecurity education

The rapid digital transformation it has forced upon us has seen us rely almost totally on the internet, ecommerce and digital communications to do everything from shopping to working and learning. It has brought into stark focus the threats we all face and the importance of cybersecurity skills at every level of society.

European Cybersecurity Month is a timely reminder that we must not become complacent and must redouble our efforts to stay safe online and bolster the cybersecurity skills base in society. This is imperative not only to manage the challenges we face today, but to ensure we can rise to the next wave of unknown, sophisticated cybersecurity threats that await us tomorrow.

Developing cybersecurity education at all levels, encouraging more of our students to embrace STEM subjects at an early age, educating consumers and the elderly on how to spot and avoid scams are critical to managing the challenge we face. The urgency and need to build our professional cybersecurity workforce is paramount to a safe and secure cyber world.

With a global skills gap of over four million, the cybersecurity professional base must grow substantially now in the UK and across mainland Europe to meet the challenge facing organisations, at the same time as we lay the groundwork to welcome the next generation into cybersecurity careers. That means a stronger focus on adult education, professional workplace training and industry-recognised certification.

At this key moment in the evolution of digital business and the changes in the way society functions day-to-day, certification plays an essential role in providing trust and confidence on knowledge and skills. Employers, government, law enforcement – whatever the function, these organisations need assurance that cybersecurity professionals have the skills, expertise and situational fluency needed to deal with current and future needs.

Certifications provide cybersecurity professionals with this important verification and validation of their training and education, ensuring organisations can be confident that current and future employees holding a given certification have an assured and consistent skillset wherever in the world they are.

The digital skills focus of European Cybersecurity Month is a reminder that there is a myriad of evolving issues that cybersecurity professionals need to be proficient in including data protection, privacy and cyber hygiene to name just a few.

However, certifications are much more than a recognised and trusted mark of achievement. They are a gateway to ensuring continuous learning and development. Maintaining a cybersecurity certification, combined with professional membership is evidence that professionals are constantly improving and developing new skills to add value to the profession and taking ownership for their careers. This new knowledge and understanding can be shared throughout an organisation to support security best practice, as well as ensuring cyber safety in our homes and communities.

Ultimately, we must remember that cybersecurity skills, education and best practice is not just a European issue, and neither is it a political issue. Rather, it is a global challenge that impacts every corner of society. Cybersecurity mindfulness needs to be woven into the DNA of everything we do, and it starts with everything we learn.

Why CIOs need to focus on password exposure, not expiration

The cybersecurity market is growing even in the midst of the pandemic-driven economic downturn, with spending predicted to reach $123 billion by the end of the year. While disruptive technologies are undoubtedly behind much of this market growth, companies cannot afford to overlook security basics.

focus on password exposure

Biometrics may be a media darling, but the truth is that passwords will remain the primary authentication mechanism for the foreseeable future. But while passwords may not be a cutting-edge security innovation, that’s not to suggest that CIOs don’t need to modernize their approach to password management.

Mandatory password resets

Employees’ poor password management practices are well-documented, with Google finding that 65% of people use the same password for multiple, if not all, online accounts. To circumvent the security risks associated with this behavior, companies have historically focused on periodic password resets. Seventy-seven percent of IT departments surveyed by Forrester in 2016 were expiring passwords for all staff on a quarterly basis.

This approach made sense in the early days of the digital age, when employees typically only had a handful of passwords to remember. I’d argue that times had already changed by 2016, but we are certainly in an entirely different landscape today. As digital transformation accelerates and employees are faced with managing multiple passwords for all of their accounts, it’s simply no longer realistic or wise to force frequent password resets.

It’s time to retire password expiration

Both NIST and Microsoft have recently come out against forced periodic password resets for a variety of reasons, including:

  • Password expiration eats up significant resources and budget. According to Forrester, a single password reset costs $70 of help desk labor. When you multiply this by the average number of employees in a typical organization, it’s easy to see how password expiration can become an unwieldy expense and add significant pressure on overburdened IT teams.
  • It encourages poor cybersecurity practices. When users are frequently asked to change passwords they typically create weaker ones—for example, slight variants of the original password or the same root word or phrase with different special characters for each account.
  • The practice impedes efficiency and introduces friction. Forced resets have a negative impact on productivity as employees often struggle to remember their passwords. One recent study found that 78% of people had to reset a password they forgot in the past 90 days, eating up valuable time that could have better been deployed elsewhere. In addition, the frustration associated with frequent changes can cause employees to seek a workaround or engage in poor security practices like sharing passwords among colleagues or reusing personal passwords for corporate accounts.

Exposure, not expiration

The fundamental purpose of passwords is to ensure that no one but the authorized user has access to the account or system in question. As such, it follows that password security has evolved from a focus on expiration to a focus on exposure. If credentials are secure, there is no reason for companies to incur the cost and other issues associated with forcing a reset. It’s critical that CIOs adopt this mindset and evaluate how they can continuously screen passwords to ensure their integrity.

Putting NIST’s recommendations into practice

According to NIST, companies should compare passwords “ …against a list that contains values known to be commonly-used, expected or compromised… The list MAY include, but is not limited to:

  • Passwords obtained from previous breach corpuses
  • Dictionary words
  • Repetitive or sequential characters
  • Context-specific words, such as the name of the service, the username, and derivatives thereof.”

Given that multiple data breaches occur in virtually every sector on a daily basis, companies need a dynamic, automated solution that can cross-reference proposed passwords against known breach data. In this environment, it’s highly likely that a password could be secure at its creation but become compromised down the road. As such, CIOs also need to monitor password security on a daily basis and take steps to protect sensitive information if a compromise is detected.

Depending on the nature of the account and the employee’s privilege this could take a variety of forms, including:

  • Stepping up MFA or additional authentication mechanisms
  • Forcing a password reset
  • Temporarily suspending access to the account

Because these actions occur only if a compromise has been detected, this modern approach to credential screening eliminates the unnecessary cost and friction associated with password expiration.

Protecting the password layer in the new normal

Replacing password expiration with password exposure will be particularly critical as CIOs manage an increasingly hybrid workforce. With Gartner finding that 74% of organizations plan to shift some employees to permanent remote work positions, it’s likely that users will be creating new digital accounts and accessing different services online.

A modern password management approach that continuously screens for any credential compromise is the best way that organizations can secure this complex environment while simultaneously encouraging productivity and reducing help desk costs.

Three immediate steps to take to protect your APIs from security risks

In one form or another, APIs have been around for years, bringing the benefits of ease of use, efficiency and flexibility to the developer community. The advantage of using APIs for mobile and web apps is that developers can build and deploy functionality and data integrations quickly.

API security posture

API security posture

But there is a huge downside to this approach. Undermining the power of an API-driven development methodology are shadow, deprecated and non-conforming APIs that, when exposed to the public, introduce the risk of data loss, compromise or automated fraud.

The stateless nature of APIs and their ubiquity makes protecting them increasingly difficult, largely because malicious actors can leverage the same developer benefits – ease of use and flexibility – to easily execute account takeovers, credential stuffing, fake account creation or content scraping. It’s no wonder that Gartner identified API security as a top concern for 50% of businesses.

Thankfully, it’s never too late to get your API footprint in order to better protect your organization’s critical data. Here are a few easy steps you can follow to mitigate API security risks immediately:

1. Start an organization-wide conversation

If your company is having conversations around API security at all, it’s likely that they are happening in a fractured manner. If there’s no larger, cohesive conversation, then various development and operational teams could be taking conflicting approaches to mitigating API security risks.

For this reason, teams should discuss how they can best work together to support API security initiatives. As a basis for these meetings, teams should refer to the NIST Cybersecurity Framework, as it’s a great way to develop a shared understanding of organization-wide cybersecurity risks. The NIST CSF will help the collective team to gain a baseline awareness about the APIs used across the organization to pinpoint the potential gaps in the operational processes that support them, so that companies can work towards improving their API strategy immediately.

2. Ask (& answer) any outstanding questions as a team

To improve an organization’s API security posture, it’s critical that outstanding questions are asked and answered immediately so that gaps in security are reduced and closed. When posing these questions to the group, consider the API assets you have overall, the business environment, governance, risk assessment, risk management strategy, access control, awareness and training, anomalies and events, continuous security monitoring, detection processes, etc. Leave no stone unturned. Here are a few suggested questions to use as a starting point as you work on the next step in this process towards getting your API security house in order:

  • How many APIs do we have?
  • How were they developed? Which are open-source, custom built or third-party?
  • Which APIs are subject to legal or regulatory compliance?
  • How do we monitor for vulnerabilities in our APIs?
  • How do we protect our APIs from malicious traffic?
  • Are there APIs with vulnerabilities?
  • What is the business impact if the APIs are compromised or abused?
  • Is API security a part of our on-going developer training and security evangelism?

Once any security holes have been identified through a shared understanding, the team then can collectively work together to fill those gaps.

3. Strive for complete and continuous API security and visibility

Visibility is critical to immediate and continuous API security. By going through step one and two, organizations are working towards more secure APIs today – but what about tomorrow and in the years to come as your API footprint expands exponentially?

Consider implementing a visibility and monitoring solution to help you oversee this security program on an ongoing basis, so that your organization can feel confident in having a strong and comprehensive API security posture that grows and adapts as your number of APIs expand and shift. The key components to visibility and monitoring?

Centralized visibility and inventory of all APIs, a detailed view of API traffic patterns, discovery of APIs transmitting sensitive data, continuous API specification conformance assessment, having validated authentication and access control programs in place and running automatic risk analysis based on predefined criteria. Continuous, runtime visibility into how many APIs an organization has, who is accessing them, where they are located and how they are being used, is key to API security.

As organizations continue to expand their use of APIs to drive their business, it’s crucial that companies consider every path malicious actors might take to attack their organization’s critical data.

MITRE Shield shows why deception is security’s next big thing

Seasoned cybersecurity pros will be familiar with MITRE. Known for its MITRE ATT&CK framework, MITRE helps develop threat models and defensive methodologies for both the private and public sector cybersecurity communities.

MITRE Shield

MITRE recently added to their portfolio and released MITRE Shield, an active defense knowledge base that captures and organizes security techniques in a way that is complementary to the mitigations featured in MITRE ATT&CK.

The MITRE Shield framework focuses on active defense and adversary engagement, which takes the passivity out of network defense. MITRE defines active defense as ranging from “basic cyber defensive capabilities to cyber deception and adversary engagement operations,” which “allow an organization to not only counter current attacks, but also learn more about that adversary and better prepare for new attacks in the future.”

This is the first time that deception has been proactively referenced in a framework from MITRE, and yes, it’s a big deal.

As the saying goes, the best defense is a good offense. Cybercriminals continue to evolve their tactics, and as a result, traditional security and endpoint protections are proving insufficient to defend against today’s sophisticated attackers. Companies can no longer sit back and hope that firewalls or mandatory security training will be enough to protect critical systems and information. Instead, they should consider the “active defense” tactics called for in MITRE Shield to help level the playing field.

Why deception?

The key to deception technology – and why it’s so relevant now – is that it goes beyond simple detection to identify and prevent lateral movement, notoriously one of the most difficult aspects of network defense. The last several months have been especially challenging for security teams, with the pandemic and the sudden shift to remote work leaving many organizations more vulnerable than before. Cybercriminals are acutely aware of this and have been capitalizing on the disruption to launch more attacks.

In fact, the number of data breaches in 2020 has almost doubled (compared to the year before), with more than 3,950 incidents as of August. But what this number doesn’t account for are the breaches that may still be undetected, in which attackers gained access to a company’s network and are performing reconnaissance weeks, or potentially months, before they actually launch an attack.

As they move through a network laterally, cybercriminals stealthily gather information about a company and its assets, allowing them to develop a plan for a more sophisticated and damaging attack down the line. This is where deception and active defense converge – hiding real assets (servers, applications, routers, printers, controllers and more) in a crowd of imposters that look and feel exactly like the real thing. In a deceptive environment, the attacker must be 100% right, otherwise they will waste time and effort collecting bad data in exchange for revealing their tradecraft to the defender.

Deception exists in a shadow network. Traps don’t touch real assets, making it a highly valued solution for even the most diverse environments, including IT, OT and Internet of Things devices. And because traps are not visible to legitimate users or systems and serve only to deceive attackers, they deliver high fidelity alerts and virtually no false positives.

How can companies embrace MITRE Shield using deception?

MITRE Shield currently contains 34 deception-based tactics, all mapped to one of MITRE’s eight active defense categories: Channel, Collect, Contain, Detect, Disrupt, Facilitate, Legitimize and Test. Approximately one third of suggested tactics in the framework are related to deception, which not only shows the power of deception as an active defense strategy, but also provides a roadmap for companies to develop a successful deception posture of their own.

There are three tiers of deceptive assets that companies should consider, depending on the level of forensics desired:

1. Low interaction, which consists of simple fake assets designed to divert cybercriminals away from the real thing, using up their time and resources.

2. Medium interaction, which offers greater insights into the techniques used by cybercriminals, allowing security teams to identify attackers and respond to the attack.

3. High interaction, which provides the most insight into attacker activity, leveraging extended interaction to collect information.

While a company doesn’t have to use all of the deception-based tactics outlined in MITRE Shield to prevent attacks, low interaction decoys are a good place to start, and can be deployed in a matter of minutes. Going forward, CISOs should consider whether it’s time to rethink their security strategy to include more active defense tactics, including deception.

How managed detection and response became a game changer

Gartner recently released its 2020 Market Guide for Managed Detection and Response (MDR) Services. Reading the fifth edition of this report reminds me of how far the industry has come and just how far it needs to go.

I remember 2016 and working with Gartner analysts to champion a new category that better described what eSentire delivered. We managed threats, not devices like managed security service providers (MSSPs), but no category existed. In response, the first MDR market guide contained a baker’s generous dozen of vendors with varying services.

Five years on, Gartner predicts that the majority of firms will use MDR by 2025 and they have seen a 44 percent increase in user inquiries. MDR has mass, but a history of vendor accretion still leaves MDR without a cohesive identity. Plus, many MSSPs simply relabel their services to jump on the bandwagon.

Half a decade later, there is still an argument whether alerting equates to response (FYI, it doesn’t!). Your kid telling you water is flooding your basement is an alert and does nothing to stop the resulting damage. Alerts don’t equate response. If your security vendor can’t even triage the leak and turn off the water source, then they are simply managed detection and alerting. That’s it without the ultimate payoff of real response.

What does that look like? MDR vendors must respond to millions of security events per client (potentially leaking pipes and flooding basements) and begin triage within minutes and resolve (contain attacks and report with full forensics) in less than 30 minutes. Criminals measure their time in minutes and hours, not the typical days or months of their victims.

Experience counts. The lessons learned in business continuity as a result of the 9/11 attacks were predicated on the resiliency of a primary facility. Back-ups in New Jersey were sufficient to recover from events in Manhattan. But, a little over a decade later, Hurricane Sandy flooded Manhattan and made us see resiliency as more than protecting a building. COVID-19 and work-from-home was business as usual for companies prepared for distributed workforces but was devastating to organizations that focused on the traditional perimeters.

Vendors focused on the network and porting log-based responses from MSSP to MDR marketing could not protect their clients during COVID-19. Or at least, there were massive delays and gaps in which criminals could exploit their clients. Consider the tens of thousands of hospital beds in compromised healthcare facilities or theft and disruption targeting critical infrastructure and manufacturers working to deliver life-saving technology.

Digital transformation is accelerating like a runaway freight train. Everything is connected and there is nowhere to hide. Every surface is exposed. When you look over your cybersecurity wall, look at the MSSP or MDR vendor at your side. Are they shiny and full of promise, or do they carry the weight of experience? When it comes to protecting my business, I want experts who have seen it all and know how to confront cyberthreats. Catchy phrases, pretty slide decks and enticing price tags won’t seem very comforting when the cybersecurity predators start circling your business.