Login
Over the last few months, Zero Trust Architecture (ZTA) conversations have been top-of-mind across the DoD. We have been hearing the chatter during industry events all while sharing conflicting interpretations and using various definitions. In a sense, there is an uncertainty around how the security model can and should work. From the chatter, one thing is clear – we need more time. Time to settle in on just how quickly mission owners can classify a comprehensive and all-inclusive, acceptable definition of Zero Trust Architecture.
Today, most entities utilize a multi-phased security approach. Most commonly, the foundation (or first step) in the approach is to implement secure access to confidential resources. Coupled with the shift to remote and distance work, the question arises, “are my resources and data safe, and are they safe in the cloud?”
Thankfully, the DoD is in the process of developing a long-term strategy for ZTA. Industry partners, like McAfee, have been briefed along the way. It has been refreshing to see the DoD take the initial steps to clearly define what ZTA is, what security objectives it must meet, and the best approach for implementation in the real-world. A recent DoD briefing states “ZTA is a data-centric security model that eliminates the idea of trusted or untrusted networks, devices, personas, or processes and shifts to a multi-attribute based confidence levels that enable authentication and authorization policies under the concept of least privilege access”.
What stands out to me is the data-centric approach to ZTA. Let us explore this concept a bit further. Conditional access to resources (such as network and data) is a well-recognized challenge. In fact, there are several approaches to solving it, whether the end goal is to limit access or simply segment access. The tougher question we need to ask (and ultimately answer) is how to do we limit contextual access to cloud assets? What data security models should we consider when our traditional security tools and methods do not provide adequate monitoring? And is securing data, or at least watching user behavior, enough when the data stays within multiple cloud infrastructures or transfers from one cloud environment to another?
Increased usage of collaboration tools like Microsoft 365 and Teams, SLACK and WebEx are easily relatable examples of data moving from one cloud environment to another. The challenge with this type of data exchange is that the data flows stay within the cloud using an East-West traffic model. Similarly, would you know if sensitive information created directly in Office 365 is uploaded to a different cloud service? Collaboration tools by design encourage sharing data in real-time between trusted internal users and more recently with telework, even external or guest users. Take for example a supply chain partner collaborating with an end user. Trust and conditional access potentially create a risk to both parties, inside and outside of their respective organizational boundaries. A data breach whether intentional or not can easily occur because of the pre-established trust and access. There are few to no limited default protection capabilities preventing this situation from occurring without intentional design. Data loss protection, activity monitoring and rights management all come into question. Clearly new data governance models, tools and policy enforcement capabilities for this simple collaboration example are required to meet the full objectives of ZTA.
So, as the communities of interest continue to refine the definitions of Zero Trust Architecture based upon deployment, usage, and experience, I believe we will find ourselves shifting from a Zero Trust model to an Advanced Adaptive Trust model. Our experience with multi-attribute-based confidence levels will evolve and so will our thinking around trust and data-centric security models in the cloud.
The post Data-Centric Security for the Cloud, Zero Trust or Advanced Adaptive Trust? appeared first on McAfee Blogs.
If you are someone who works for a cloud service provider in the business of federal contracting, you probably already have a good understanding of FedRAMP. It is also likely that our regular blog readers know the ins and outs of this program.
For those who are not involved in these areas, however, this acronym may be more unfamiliar. Perhaps you have only heard of it in passing conversation with a few of your expert cybersecurity colleagues, or you are just curious to learn what all of the hype is about. If you fall into this category – read on! This blog is for you.
At first glance, FedRAMP may seem like a type of onramp to an interstate headed for the federal government – and in a way, it is.
FedRAMP stands for the Federal Risk and Authorization Management Program, which provides a standard security assessment, authorization and continuous monitoring for cloud products and services to be used by federal agencies. The program’s overall mission is to protect the data of U.S. citizens in the cloud and promote the adoption of secure cloud services across the government with a standardized approach.
Once a cloud service has successfully made it onto the interstate – or achieved FedRAMP authorization – it’s allowed to be used by an agency and listed in the FedRAMP Marketplace. The FedRAMP Marketplace is a one-stop-shop for agencies to find cloud services that have been tested and approved as safe to use, making it much easier to determine if an offering meets security requirements.
In the fourth year of the program, FedRAMP had 20 authorized cloud service offerings. Now, eight years into the program, FedRAMP has over 200 authorized offerings, reflecting its commitment to help the government shift to the cloud and leverage new technologies.
Any cloud service provider that has a contract with a federal agency or wants to work with an agency in the future must have FedRAMP authorization. Compliance with FedRAMP can also benefit providers who don’t have plans to partner with government, as it signals to the private sector they are committed to cloud security.
Using a cloud service that complies with FedRAMP standards is mandatory for federal agencies. It has also become popular with organizations in the private industry, which are more often looking to FedRAMP standards as a security benchmark for the cloud services they use.
There are two ways for a cloud service to obtain FedRAMP authorization. One is with a Joint Authorization Board (JAB) provisional authorization (P-ATO) and the other is through an individual agency Authority to Operate (ATO).
A P-ATO is an initial approval of the cloud service provider by the JAB, which is made up of the Chief Information Officers (CIOs) from the Department of Defense (DoD), Department of Homeland Security (DHS) and General Services Administration (GSA). This designation means that the JAB has provided a provisional approval for agencies to leverage when granting an ATO to a cloud system.
The head of an agency grants an ATO as part of the agency authorization process. An ATO may be granted after an agency sponsor reviews the cloud service offering and completes a security assessment.
Achieving FedRAMP authorization for a cloud service is a very long and rigorous process, but it has received high praise from security officials and industry experts alike for its standardized approach to evaluate whether a cloud service offering meets some of the strongest cybersecurity requirements.
There are several benefits for cloud providers who authorize their service with FedRAMP. The program allows an authorized cloud service to be reused continuously across the federal government – saving time, money and effort for both cloud service providers and agencies. Authorization of a cloud service also gives service providers increased visibility of their product across government with a listing in the FedRAMP Marketplace.
By electing to comply with FedRAMP, cloud providers can demonstrate dedication to the highest data security standards. Though the process for achieving FedRAMP approval is complex, it is worthwhile for providers, as it signals a commitment to security to government and non-government customers.
At McAfee, we are dedicated to ensuring our cloud services are compliant with FedRAMP standards. We are proud that McAfee’s MVISION Cloud is the first Cloud Access Security Broker (CASB) platform to be granted a FedRAMP High Impact Provisional Authority to Operate (P-ATO) from the U.S. Government’s Joint Authorization Board (JAB).
Currently, MVISION Cloud is in use by ten federal agencies, including the Department of Energy (DOE), Department of Health and Human Services (HHS), Department of Homeland Security (DHS), Food and Drug Administration (FDA) and National Aeronautics and Space Administration (NASA).
MVISION Cloud allows federal organizations to have total visibility and control of their infrastructure to protect their data and applications in the cloud. The FedRAMP High JAB P-ATO designation is the highest compliance level available under FedRAMP, meaning that MVISION Cloud is authorized to manage highly sensitive government data.
We look forward to continuing to work closely with the FedRAMP program and other cloud providers dedicated to authorizing cloud service offerings with FedRAMP.
The post FedRAMP – What’s the Big Deal? appeared first on McAfee Blogs.
You get an email from bank0famerica@acc0unt.com claiming that they have found suspicious activity on your credit card statement and are requesting that you verify your financial information. What do you do? While you may be tempted to click on a link to immediately resolve the issue, this is likely the work of a cybercriminal. Phishing is a scam that tricks you into voluntarily providing important personal information. Protect yourself from phishing by reviewing some examples of phishing emails and learning more about this common online scam.
Phishing is a cybercrime that aims to steal your sensitive information. Scammers disguise themselves as major corporations or other trustworthy entities to trick you into willingly providing information like website login credentials or, even worse, your credit card number.
A phishing email or text (also known as SMiShing) is a fraudulent message made to look legitimate, and typically asks you to provide sensitive personal information in various ways. If you don’t look carefully at the emails or texts, however, you might not be able to tell the difference between a regular message and a phishing message. Scammers work hard to make phishing messages closely resemble emails and texts sent by trusted companies, which is why you need to be cautious when you open these messages and click the links they contain.
Phishing scammers often undo their own plans by making simple mistakes that are easy to spot once you know how to recognize them. Check for the following signs of phishing every time you open an email or text:
Even the biggest companies sometimes make minor errors in their communications. Phishing messages often contain grammatical errors, spelling mistakes, and other blatant errors that major corporations wouldn’t make. If you see multiple, glaring grammatical errors in an email or text that asks for your personal information, you might be a target of a phishing scam.
To enhance their edibility, phishing scammers often steal the logos of who they’re impersonating. In many cases, however, they don’t steal corporate logos correctly. The logo in a phishing email or text might have the wrong aspect ratio or low-resolution. If you have to squint to make out the logo in a message, the chances are that it’s phishing.
Phishing always centers around links that you’re supposed to click. Here are a few ways to check whether a link someone sent you is legitimate:
If the URL you discover doesn’t match up with the entity that supposedly sent you the message, you probably received a phishing email.
Phishing messages come in all shapes and sizes, but there are a few types of phishing emails and texts that are more common than others. Let’s review some examples of the most frequently sent phishing scams:
Some phishing emails appear to notify you that your bank temporarily suspended your account due to unusual activity. If you receive an account suspension email from a bank that you haven’t opened an account with, delete it immediately, and don’t look back. Suspended account phishing emails from banks you do business with, however, are harder to spot. Use the methods we listed above to check the email’s integrity, and if all else fails, contact your bank directly instead of opening any links within the email you received.
Two-factor authentication scam
Two-factor authentication (2FA) has become common, so you’re probably used to receiving emails that ask you to confirm your login information with six-digit numerical codes. Phishing scammers also know how standard 2FA has become, and they could take advantage of this service that’s supposed to protect your identity. If you receive an email asking you to log in to an account to confirm your identity, use the criteria we listed above to verify the message’s authenticity. Be especially wary if someone asks you to provide 2FA for an account you haven’t accessed for a while.
We all know how important tax season is. That’s what phishing scammers are counting on when they send you phony IRS refund emails. Be careful when an email informs you that you’ve received a windfall of cash and be especially dubious of emails that the IRS supposedly sent since this government agency only contacts taxpayers via snail mail. Tax refund phishing scams can do serious harm since they usually ask for your social security number as well as your bank account information.
Sometimes, cybercriminals will try to tick you by sending emails with fake order confirmations. These messages often contain “receipts” attached to the email or links claiming to contain more information on your order. However, criminals often use these attachments and links to spread malware to the victim’s device.
You need to be wary of phishing when you’re using your work email as well. One popular phishing scam involves emails designed to look like someone in the C-suite of your company sent them. They ask workers to wire funds to supposed clients, but this cash actually goes to scammers. Use the tips we listed above to spot these phony emails.
Often, hackers look for ways to update old schemes so that they go undetected by users already aware of certain cyberthreats. Such is the case with the latest phishing evasion technique, which detects virtual machines to fly under the radar. Cybersecurity firms often use headless devices or virtual machines (a computer file that behaves like an actual computer) to determine if a website is actually a phishing page. But now, some phishing kits contain JavaScript — a programming language that allows you to implement complex features on web pages — that checks whether a virtual machine is analyzing the page. If it detects any analysis attempts, the phishing kit will show a blank page instead of the phishing page, allowing the scam to evade detection. To help ensure that you don’t fall for the latest phishing scams, stay updated on the most recent phishing techniques so you can stay one step ahead of cybercriminals.
Never click links in suspicious emails. If you click a link you suspect a phishing scammer sent, the link will take you to a web page with a form where you can enter sensitive data such as your Social Security number, credit card information, or login credentials. Do not enter any data on this page.
If you accidentally enter data in a webpage linked to a suspicious email, perform a full malware scan on your device. Once the scan is complete, backup all of your files and change your passwords. Even if you only provided a phishing scammer with the data from one account, you may have also opened the door to other personal data, so it’s important to change all the passwords you use online in the wake of a suspected phishing attack.
Let’s wrap things up with some summarized tips on how to avoid phishing emails:
Phishing emails only work on the unaware. Now that you know how to spot phishing emails and what to do if you suspect scammers are targeting you, you’re far less likely to fall for these schemes. Remember to be careful with your personal information when you use the internet and err on the side of caution whenever anybody asks you to divulge sensitive details about your identity, finances, or login information.
To stay updated on all things McAfee and on top of the latest consumer and mobile security threats, follow @McAfee_Home on Twitter, subscribe to our email, listen to our podcast Hackable?, and ‘Like’ us on Facebook.
The post Phishing Email Examples: How to Recognize a Phishing Email appeared first on McAfee Blogs.
As Congress prepares to return to Washington in the coming weeks, finalizing the FY2021 National Defense Authorization Act (NDAA) will be a top priority. The massive defense bill features several important cybersecurity provisions, from strengthening CISA and promoting interoperability to creating a National Cyber Director position in the White House and codifying FedRAMP.
These are vital components of the legislation that conferees should work together to include in the final version of the bill, including:
One of the main recommendations of the Cyberspace Solarium Commission’s report this spring was to further strengthen CISA, an agency that has already made great strides in protecting our country from cyberattacks. An amendment to the House version of the NDAA would do just that, by giving CISA additional authority it needs to effectively hunt for threats and vulnerabilities on the federal network.
Bad actors, criminal organizations and even nation-states are continually looking to launch opportunistic attacks. Giving CISA additional tools, resources and funding needed to secure the nation’s digital infrastructure and secure our intelligence and information is a no-brainer and Congress should ensure the agency gets the resources it needs in the final version of the NDAA.
Perhaps now more than ever before, interoperability is key to a robust security program. As telework among the federal workforce continues and expands, an increased variety of communication tools, devices and networks put federal networks at risk. Security tools that work together and are interoperable better provide a full range of protection across these environments.
The House version of the NDAA includes several provisions to promote interoperability within the National Guard, military and across the Federal government. The Senate NDAA likewise includes language that requires the DoD craft regulations to facilitate DoD’s access to and utilization of system, major subsystem, and major component software-defined interfaces to advance DoD’s efforts to generate diverse and effective kill chains. The regulations and guidance would also apply to purely software systems, including business systems and cybersecurity systems. These regulations would also require acquisition plans and solicitations to incorporate mandates for the delivery of system, major subsystem, and major component software defined interfaces.
For too long, agencies have leveraged a grab bag of tools that each served a specific purpose, but didn’t offer broad, effective coverage. Congress has a valuable opportunity to change that and encourage more interoperable solutions that provide the security needed in today’s constantly evolving threat landscape.
The House version of the NDAA would establish a Senate-confirmed National Cyber Director within the White House, in charge of overseeing digital operations across the federal government. This role, a recommendation of the Cyberspace Solarium Commission, would give the federal government a single point person for all things cyber.
As former Rep. Mike Rodgers argued in an op-ed published in The Hill last month, “the cyber challenge that we face as a country is daunting and complex.” We face new threats every day. Coordinating cyber strategy across the federal government, rather than the agency by agency approach we have today, is critical to ensuring we stay on top of threats and effectively protect the nation’s critical infrastructure, intellectual property and data from an attack.
The FedRAMP Authorization Act, included in the House version of the NDAA, would codify the FedRAMP program and give it a formal standing for Congressional review, a critical step towards making the program more efficient and useful for agencies across the government. Providing this program more oversight will further validate the FedRAMP approved products from across the industry as safe and secure for federal use. The FedRAMP authorization bill also includes language that will help focus the Administration’s attention on the need to secure the vulnerable spaces between and among cloud services and applications. Agencies need to focus on securing these vulnerabilities between and among clouds since sophisticated hackers target these seams that too often are left unprotected.
Additionally, the Pentagon has already committed to FedRAMP reciprocity. FedRAMP works – and codifying it to bring the rest of the Federal government into the program would offer an excellent opportunity for wide-scale cloud adoption, something the federal government would benefit greatly from.
We hope that NDAA conferees will consider these important cyber provisions and include them in the final version of the bill and look forward to continuing our work with government partners on important cyber issues like these.
The post NDAA Conference: Opportunity to Improve the Nation’s Cybersecurity Posture appeared first on McAfee Blogs.
This is the final in a multi-part series on cryptography and the Domain Name System (DNS).
In previous posts in this series, I’ve discussed a number of applications of cryptography to the DNS, many of them related to the Domain Name System Security Extensions (DNSSEC).
In this final blog post, I’ll turn attention to another application that may appear at first to be the most natural, though as it turns out, may not always be the most necessary: DNS encryption. (I’ve also written about DNS encryption as well as minimization in a separate post on DNS information protection.)
In 2014, the Internet Engineering Task Force (IETF) chartered the DNS PRIVate Exchange (dprive) working group to start work on encrypting DNS queries and responses exchanged between clients and resolvers.
That work resulted in RFC 7858, published in 2016, which describes how to run the DNS protocol over the Transport Layer Security (TLS) protocol, also known as DNS over TLS, or DoT.
DNS encryption between clients and resolvers has since gained further momentum, with multiple browsers and resolvers supporting DNS over Hypertext Transport Protocol Security (HTTPS), or DoH, with the formation of the Encrypted DNS Deployment Initiative, and with further enhancements such as oblivious DoH.
The dprive working group turned its attention to the resolver-to-authoritative exchange during its rechartering in 2018. And in October of last year, ICANN’s Office of the CTO published its strategy recommendations for the ICANN-managed Root Server (IMRS, i.e., the L-Root Server), an effort motivated in part by concern about potential “confidentiality attacks” on the resolver-to-root connection.
From a cryptographer’s perspective the prospect of adding encryption to the DNS protocol is naturally quite interesting. But this perspective isn’t the only one that matters, as I’ve observed numerous times in previous posts.
A common theme in this series on cryptography and the DNS has been the question of whether the benefits of a technology are sufficient to justify its cost and complexity.
This question came up not only in my review of two newer cryptographic advances, but also in my remarks on the motivation for two established tools for providing evidence that a domain name doesn’t exist.
Recall that the two tools — the Next Secure (NSEC) and Next Secure 3 (NSEC3) records — were developed because a simpler approach didn’t have an acceptable risk / benefit tradeoff. In the simpler approach, to provide a relying party assurance that a domain name doesn’t exist, a name server would return a response, signed with its private key, “<name> doesn’t exist.”
From a cryptographic perspective, the simpler approach would meet its goal: a relying party could then validate the response with the corresponding public key. However, the approach would introduce new operational risks, because the name server would now have to perform online cryptographic operations.
The name server would not only have to protect its private key from compromise, but would also have to protect the cryptographic operations from overuse by attackers. That could open another avenue for denial-of-service attacks that could prevent the name server from responding to legitimate requests.
The designers of DNSSEC mitigated these operational risks by developing NSEC and NSEC3, which gave the option of moving the private key and the cryptographic operations offline, into the name server’s provisioning system. Cryptography and operations were balanced by this better solution. The theme is now returning to view through the recent efforts around DNS encryption.
Like the simpler initial approach for authentication, DNS encryption may meet its goal from a cryptographic perspective. But the operational perspective is important as well. As designers again consider where and how to deploy private keys and cryptographic operations across the DNS ecosystem, alternatives with a better balance are a desirable goal.
In addition to encryption, there has been research into other, possibly lower-risk alternatives that can be used in place of or in addition to encryption at various levels of the DNS.
We call these techniques collectively minimization techniques.
In “textbook” DNS resolution, a resolver sends the same full domain name to a root server, a top-level domain (TLD) server, a second-level domain (SLD) server, and any other server in the chain of referrals, until it ultimately receives an authoritative answer to a DNS query.
This is the way that DNS resolution has been practiced for decades, and it’s also one of the reasons for the recent interest in protecting information on the resolver-to-authoritative exchange: The full domain name is more information than all but the last name server needs to know.
One such minimization technique, known as qname minimization, was identified by Verisign researchers in 2011 and documented in RFC 7816 in 2016. (In 2015, Verisign announced a royalty-free license to its qname minimization patents.)
With qname minimization, instead of sending the full domain name to each name server, the resolver sends only as much as the name server needs either to answer the query or to refer the resolver to a name server at the next level. This follows the principle of minimum disclosure: the resolver sends only as much information as the name server needs to “do its job.” As Matt Thomas described in his recent blog post on the topic, nearly half of all .com and .net queries received by Verisign’s .com TLD servers were in a minimized form as of August 2020.
Other techniques that are part of this new chapter in DNS protocol evolution include NXDOMAIN cut processing [RFC 8020] and aggressive DNSSEC caching [RFC 8198]. Both leverage information present in the DNS to reduce the amount and sensitivity of DNS information exchanged with authoritative name servers. In aggressive DNSSEC caching, for example, the resolver analyzes NSEC and NSEC3 range proofs obtained in response to previous queries to determine on its own whether a domain name doesn’t exist. This means that the resolver doesn’t always have to ask the authoritative server system about a domain name it hasn’t seen before.
All of these techniques, as well as additional minimization alternatives I haven’t mentioned, have one important common characteristic: they only change how the resolver operates during the resolver-authoritative exchange. They have no impact on the authoritative name server or on other parties during the exchange itself. They thereby mitigate disclosure risk while also minimizing operational risk.
The resolver’s exchanges with authoritative name servers, prior to minimization, were already relatively less sensitive because they represented aggregate interests of the resolver’s many clients1. Minimization techniques lower the sensitivity even further at the root and TLD levels: the resolver sends only its aggregate interests in TLDs to root servers, and only its interests in SLDs to TLD servers. The resolver still sends the aggregate interests in full domain names at the SLD level and below2, and may also include certain client-related information at these levels, such as the client-subnet extension. The lower levels therefore may have different protection objectives than the upper levels.
Minimization techniques and encryption together give DNS designers additional tools for protecting DNS information — tools that when deployed carefully can balance between cryptographic and operational perspectives.
These tools complement those I’ve described in previous posts in this series. Some have already been deployed at scale, such as a DNSSEC with its NSEC and NSEC3 non-existence proofs. Others are at various earlier stages, like NSEC5 and tokenized queries, and still others contemplate “post-quantum” scenarios and how to address them. (And there are yet other tools that I haven’t covered in this series, such as authenticated resolution and adaptive resolution.)
Modern cryptography is just about as old as the DNS. Both have matured since their introduction in the late 1970s and early 1980s respectively. Both bring fundamental capabilities to our connected world. Both continue to evolve to support new applications and to meet new security objectives. While they’ve often moved forward separately, as this blog series has shown, there are also opportunities for them to advance together. I look forward to sharing more insights from Verisign’s research in future blog posts.
Read the complete six blog series:
1. This argument obviously holds more weight for large resolvers than for small ones — and doesn’t apply for the less common case of individual clients running their own resolvers. However, small resolvers and individual clients seeking additional protection retain the option of sending sensitive queries through a large, trusted resolver, or through a privacy-enhancing proxy. The focus in our discussion is primarily on large resolvers.
2. In namespaces where domain names are registered at the SLD level, i.e., under an effective TLD, the statements in this note about “root and TLD” and “SLD level and below” should be “root through effective TLD” and “below effective TLD level.” For simplicity, I’ve placed the “zone cut” between TLD and SLD in this note.
The post Information Protection for the Domain Name System: Encryption and Minimization appeared first on Verisign Blog.
This is the fifth in a multi-part series on cryptography and the Domain Name System (DNS).
In my last article, I described efforts underway to standardize new cryptographic algorithms that are designed to be less vulnerable to potential future advances in quantum computing. I also reviewed operational challenges to be considered when adding new algorithms to the DNS Security Extensions (DNSSEC).
In this post, I’ll look at hash-based signatures, a family of post-quantum algorithms that could be a good match for DNSSEC from the perspective of infrastructure stability.
I’ll also describe Verisign Labs research into a new concept called synthesized zone signing keys that could mitigate the impact of the large signature size for hash-based signatures, while still maintaining this family’s protections against quantum computing.
(Caveat: The concepts reviewed in this post are part of Verisign’s long-term research program and do not necessarily represent Verisign’s plans or positions on new products or services. Concepts developed in our research program may be subject to U.S. and/or international patents and/or patent applications.)
The DNS community’s root key signing key (KSK) rollover illustrates how complicated a change to DNSSEC infrastructure can be. Although successfully accomplished, this change was delayed by ICANN to ensure that enough resolvers had the public key required to validate signatures generated with the new root KSK private key.
Now imagine the complications if the DNS community also had to ensure that enough resolvers not only had a new key but also had a brand-new algorithm.
Imagine further what might happen if a weakness in this new algorithm were to be found after it was deployed. While there are procedures for emergency key rollovers, emergency algorithm rollovers would be more complicated, and perhaps controversial as well if a clear successor algorithm were not available.
I’m not suggesting that any of the post-quantum algorithms that might be standardized by NIST will be found to have a weakness. But confidence in cryptographic algorithms can be gained and lost over many years, sometimes decades.
From the perspective of infrastructure stability, therefore, it may make sense for DNSSEC to have a backup post-quantum algorithm built in from the start — one for which cryptographers already have significant confidence and experience. This algorithm might not be as efficient as other candidates, but there is less of a chance that it would ever need to be changed. This means that the more efficient candidates could be deployed in DNSSEC with the confidence that they have a stable fallback. It’s also important to keep in mind that the prospect of quantum computing is not the only reason system developers need to be considering new algorithms from time to time. As public-key cryptography pioneer Martin Hellman wisely cautioned, new classical (non-quantum) attacks could also emerge, whether or not a quantum computer is realized.
The 1970s were a foundational time for public-key cryptography, producing not only the RSA algorithm and the Diffie-Hellman algorithm (which also provided the basic model for elliptic curve cryptography), but also hash-based signatures, invented in 1979 by another public-key cryptography founder, Ralph Merkle.
Hash-based signatures are interesting because their security depends only on the security of an underlying hash function.
It turns out that hash functions, as a concept, hold up very well against quantum computing advances — much better than currently established public-key algorithms do.
This means that Merkle’s hash-based signatures, now more than 40 years old, can rightly be considered the oldest post-quantum digital signature algorithm.
If it turns out that an individual hash function doesn’t hold up — whether against a quantum computer or a classical computer — then the hash function itself can be replaced, as cryptographers have been doing for years. That will likely be easier than changing to an entirely different post-quantum algorithm, especially one that involves very different concepts.
The conceptual stability of hash-based signatures is a reason that interoperable specifications are already being developed for variants of Merkle’s original algorithm. Two approaches are described in RFC 8391, “XMSS: eXtended Merkle Signature Scheme” and RFC 8554, “Leighton-Micali Hash-Based Signatures.” Another approach, SPHINCS+, is an alternate in NIST’s post-quantum project.
Hash-based signatures can potentially be applied to any part of the DNSSEC trust chain. For example, in Figure 1, the DNS record sets can be signed with a zone signing key (ZSK) that employs a hash-based signature algorithm.
The main challenge with hash-based signatures is that the signature size is large, on the order of tens or even hundreds of thousands of bits. This is perhaps why they haven’t seen significant adoption in security protocols over the past four decades.
Verisign Labs has been exploring how to mitigate the size impact of hash-based signatures on DNSSEC, while still basing security on hash functions only in the interest of stable post-quantum protections.
One of the ideas we’ve come up with uses another of Merkle’s foundational contributions: Merkle trees.
Merkle trees authenticate multiple records by hashing them together in a tree structure. The records are the “leaves” of the tree. Pairs of leaves are hashed together to form a branch, then pairs of branches are hashed together to form a larger branch, and so on. The hash of the largest branches is the tree’s “root.” (This is a data-structure root, unrelated to the DNS root.)
Each individual leaf of a Merkle tree can be authenticated by retracing the “path” from the leaf to the root. The path consists of the hashes of each of the adjacent branches encountered along the way.
Authentication paths can be much shorter than typical hash-based signatures. For instance, with a tree depth of 20 and a 256-bit hash value, the authentication path for a leaf would only be 5,120 bits long, yet a single tree could authenticate more than a million leaves.
Returning to the example above, suppose that instead of signing each DNS record set with a hash-based signature, each record set were considered a leaf of a Merkle tree. Suppose further that the root of this tree were to be published as the ZSK public key (see Figure 2). The authentication path to the leaf could then serve as the record set’s signature.
The validation logic at a resolver would be the same as in ordinary DNSSEC:
The only difference on the resolver’s side would be that signature validation would involve retracing the authentication path to the ZSK public key, rather than a conventional signature validation operation.
The ZSK public key produced by the Merkle tree approach would be a “synthesized” public key, in that it is obtained from the records being signed. This is noteworthy from a cryptographer’s perspective, because the public key wouldn’t have a corresponding private key, yet the DNS records would still, in effect, be “signed by the ZSK!”
In this type of DNSSEC implementation, the Merkle tree approach only applies to the ZSK level. Hash-based signatures would still be applied at the KSK level, although their overhead would now be “amortized” across all records in the zone.
In addition, each new ZSK would need to be signed “on demand,” rather than in advance, as in current operational practice.
This leads to tradeoffs, such as how many changes to accumulate before constructing and publishing a new tree. Fewer changes and the tree will be available sooner. More changes and the tree will be larger, so the per-record overhead of the signatures at the KSK level will be lower.
My last few posts have discussed cryptographic techniques that could potentially be applied to the DNS in the long term — or that might not even be applied at all. In my next post, I’ll return to more conventional subjects, and explain how Verisign sees cryptography fitting into the DNS today, as well as some important non-cryptographic techniques that are part of our vision for a secure, stable and resilient DNS.
Read the complete six blog series:
The post Securing the DNS in a Post-Quantum World: Hash-Based Signatures and Synthesized Zone Signing Keys appeared first on Verisign Blog.
This is the fourth in a multi-part series on cryptography and the Domain Name System (DNS).
One of the “key” questions cryptographers have been asking for the past decade or more is what to do about the potential future development of a large-scale quantum computer.
If theory holds, a quantum computer could break established public-key algorithms including RSA and elliptic curve cryptography (ECC), building on Peter Shor’s groundbreaking result from 1994.
This prospect has motivated research into new so-called “post-quantum” algorithms that are less vulnerable to quantum computing advances. These algorithms, once standardized, may well be added into the Domain Name System Security Extensions (DNSSEC) — thus also adding another dimension to a cryptographer’s perspective on the DNS.
(Caveat: Once again, the concepts I’m discussing in this post are topics we’re studying in our long-term research program as we evaluate potential future applications of technology. They do not necessarily represent Verisign’s plans or position on possible new products or services.)
The National Institute of Standards and Technology (NIST) started a Post-Quantum Cryptography project in 2016 to “specify one or more additional unclassified, publicly disclosed digital signature, public-key encryption, and key-establishment algorithms that are capable of protecting sensitive government information well into the foreseeable future, including after the advent of quantum computers.”
Security protocols that NIST is targeting for these algorithms, according to its 2019 status report (Section 2.2.1), include: “Transport Layer Security (TLS), Secure Shell (SSH), Internet Key Exchange (IKE), Internet Protocol Security (IPsec), and Domain Name System Security Extensions (DNSSEC).”
The project is now in its third round, with seven finalists, including three digital signature algorithms, and eight alternates.
NIST’s project timeline anticipates that the draft standards for the new post-quantum algorithms will be available between 2022 and 2024.
It will likely take several additional years for standards bodies such as the Internet Engineering Task (IETF) to incorporate the new algorithms into security protocols. Broad deployments of the upgraded protocols will likely take several years more.
Post-quantum algorithms can therefore be considered a long-term issue, not a near-term one. However, as with other long-term research, it’s appropriate to draw attention to factors that need to be taken into account well ahead of time.
The three candidate digital signature algorithms in NIST’s third round have one common characteristic: all of them have a key size or signature size (or both) that is much larger than for current algorithms.
Key and signature sizes are important operational considerations for DNSSEC because most of the DNS traffic exchanged with authoritative data servers is sent and received via the User Datagram Protocol (UDP), which has a limited response size.
Response size concerns were evident during the expansion of the root zone signing key (ZSK) from 1024-bit to 2048-bit RSA in 2016, and in the rollover of the root key signing key (KSK) in 2018. In the latter case, although the signature and key sizes didn’t change, total response size was still an issue because responses during the rollover sometimes carried as many as four keys rather than the usual two.
Thanks to careful design and implementation, response sizes during these transitions generally stayed within typical UDP limits. Equally important, response sizes also appeared to have stayed within the Maximum Transmission Unit (MTU) of most networks involved, thereby also avoiding the risk of packet fragmentation. (You can check how well your network handles various DNSSEC response sizes with this tool developed by Verisign Labs.)
The larger sizes associated with certain post-quantum algorithms do not appear to be a significant issue either for TLS, according to one benchmarking study, or for public-key infrastructures, according to another report. However, a recently published study of post-quantum algorithms and DNSSEC observes that “DNSSEC is particularly challenging to transition” to the new algorithms.
Verisign Labs offers the following observations about DNSSEC-related queries that may help researchers to model DNSSEC impact:
A typical resolver that implements both DNSSEC validation and qname minimization will send a combination of queries to Verisign’s root and top-level domain (TLD) servers.
Because the resolver is a validating resolver, these queries will all have the “DNSSEC OK” bit set, indicating that the resolver wants the DNSSEC signatures on the records.
The content of typical responses by Verisign’s root and TLD servers to these queries are given in Table 1 below. (In the table, <SLD>.<TLD> are the final two labels of a domain name of interest, including the TLD and the second-level domain (SLD); record types involved include A, Name Server (NS), and DNSKEY.)
| Name Server | Resolver Query Scenario | Typical Response Content from Verisign’s Servers |
| Root | DNSKEY record set for root zone | • DNSKEY record set including root KSK RSA-2048 public key and root ZSK RSA-2048 public key • Root KSK RSA-2048 signature on DNSKEY record set |
| A or NS record set for <TLD> — when <TLD> exists | • NS referral to <TLD> name server • DS record set for <TLD> zone • Root ZSK RSA-2048 signature on DS record set |
|
| A or NS record set for <TLD> — when <TLD> doesn’t exist | • Up to two NSEC records for non-existence of <TLD> • Root ZSK RSA-2048 signatures on NSEC records |
|
| .com / .net | DNSKEY record set for <TLD> zone | • DNSKEY record set including <TLD> KSK RSA-2048 public key and <TLD> ZSK RSA-1280 public key • <TLD> KSK RSA-2048 signature on DNSKEY record set |
| A or NS record set for <SLD>.<TLD> — when <SLD>.<TLD> exists | • NS referral to <SLD>.<TLD> name server • DS record set for <SLD>.<TLD> zone (if <SLD>.<TLD> supports DNSSEC) • <TLD> ZSK RSA-1280 signature on DS record set (if present) |
|
| A or NS record set for <SLD>.<TLD> — when <SLD>.<TLD> doesn’t exist | • Up to three NSEC3 records for non-existence of <SLD>.<TLD> • <TLD> ZSK RSA-1280 signatures on NSEC3 records |
For an A or NS query, the typical response, when the domain of interest exists, includes a referral to another name server. If the domain supports DNSSEC, the response also includes a set of Delegation Signer (DS) records providing the hashes of each of the referred zone’s KSKs — the next link in the DNSSEC trust chain. When the domain of interest doesn’t exist, the response includes one or more Next Secure (NSEC) or Next Secure 3 (NSEC3) records.
Researchers can estimate the effect of post-quantum algorithms on response size by replacing the sizes of the various RSA keys and signatures with those for their post-quantum counterparts. As discussed above, it is important to keep in mind that the number of keys returned may be larger during key rollovers.
Most of the queries from qname-minimizing, validating resolvers to the root and TLD name servers will be for A or NS records (the choice depends on the implementation of qname minimization, and has recently trended toward A). The signature size for a post-quantum algorithm, which affects all DNSSEC-related responses, will therefore generally have a much larger impact on average response size than will the key size, which affects only the DNSKEY responses.
Post-quantum algorithms are among the newest developments in cryptography. They add another dimension to a cryptographer’s perspective on the DNS because of the possibility that these algorithms, or other variants, may be added to DNSSEC in the long term.
In my next post, I’ll make the case for why the oldest post-quantum algorithm, hash-based signatures, could be a particularly good match for DNSSEC. I’ll also share the results of some research at Verisign Labs into how the large signature sizes of hash-based signatures could potentially be overcome.
Read the complete six blog series:
The post Securing the DNS in a Post-Quantum World: New DNSSEC Algorithms on the Horizon appeared first on Verisign Blog.
This is the third in a multi-part blog series on cryptography and the Domain Name System (DNS).
In my last post, I looked at what happens when a DNS query renders a “negative” response – i.e., when a domain name doesn’t exist. I then examined two cryptographic approaches to handling negative responses: NSEC and NSEC3. In this post, I will examine a third approach, NSEC5, and a related concept that protects client information, tokenized queries.
The concepts I discuss below are topics we’ve studied in our long-term research program as we evaluate new technologies. They do not necessarily represent Verisign’s plans or position on a new product or service. Concepts developed in our research program may be subject to U.S. and international patents and patent applications.
NSEC5 is a result of research by cryptographers at Boston University and the Weizmann Institute. In this approach, which is still in an experimental stage, the endpoints are the outputs of a verifiable random function (VRF), a cryptographic primitive that has been gaining interest in recent years. NSEC5 is documented in an Internet Draft (currently expired) and in several research papers.
A VRF is like a hash function but with two important differences:
So, it’s not only hard for an adversary to reverse the VRF – which is also a property the hash function has – but it’s also hard for the adversary to compute the VRF in the forward direction, thus preventing dictionary attacks. And yet a relying party can still confirm that the VRF output for a given input is correct, because of the proof.
How does this work in practice? As in NSEC and NSEC3, range statements are prepared in advance and signed with the zone signing key (ZSK). With NSEC5, however, the range endpoints are two consecutive tokens.
When a domain name doesn’t exist, the name server applies the VRF to the domain name to obtain a token and a proof. The name sever then returns a range statement where the token falls within the range, as well as the proof, as shown in the figure below. Note that the token values are for illustration only.
Because the range statement reveals only tokenized versions of other domain names in a zone, an adversary who doesn’t know the private key doesn’t learn any new existing domain names from the response. Indeed, to find out which domain name corresponds to one of the tokenized endpoints, the adversary would need access to the VRF itself to see if a candidate domain name has a matching hash value, which would involve an online dictionary attack. This significantly reduces disclosure risk.
The name server needs a copy of the zone’s NSEC5 private key so that it can generate proofs for non-existent domain names. The ZSK itself can stay in the provisioning system. As the designers of NSEC5 have pointed out, if the NSEC5 private key does happen to be compromised, this only makes it possible to do a dictionary attack offline— not to generate signatures on new range statements, or on new positive responses.
NSEC5 is interesting from a cryptographer’s perspective because it uses a less common cryptographic technique, a VRF, to achieve a design goal that was at best partially met by previous approaches. As with other new technologies, DNS operators will need to consider whether NSEC5’s benefits are sufficient to justify its cost and complexity. Verisign doesn’t have any plans to implement NSEC5, as we consider NSEC and NSEC3 adequate for the name servers we currently operate. However, we will continue to track NSEC5 and related developments as part of our long-term research program.
A few years before NSEC5 was published, Verisign Labs had started some research on an opposite application of tokenization to the DNS, to protect a client’s information from disclosure.
In our approach, instead of asking the resolver “What is <name>’s IP address,” the client would ask “What is token 3141…’s IP address,” where 3141… is the tokenization of <name>.
(More precisely, the client would specify both the token and the parent zone that the token relates to, e.g., the TLD of the domain name. Only the portion of the domain name below the parent would be obscured, just as in NSEC5. I’ve omitted the zone information for simplicity in this discussion.)
Suppose now that the domain name corresponding to token 3141… does exist. Then the resolver would respond with the domain name’s IP address as usual, as shown in the next figure.
In this case, the resolver would know that the domain name associated with the token does exist, because it would have a mapping between the token and the DNS record, i.e., the IP address. Thus, the resolver would effectively “know” the domain name as well for practical purposes. (We’ve developed another approach that can protect both the domain name and the DNS record from disclosure to the resolver in this case, but that’s perhaps a topic for another post.)
Now, consider a domain name that doesn’t exist and suppose that its token is 2718… .
In this case, the resolver would respond that the domain name doesn’t exist, as usual, as shown below.
But because the domain name is tokenized and no other information about the domain name is returned, the resolver would only learn the token 2718… (and the parent zone), not the actual domain name that the client is interested in.
The resolver could potentially know that the name doesn’t exist via a range statement from the parent zone, as in NSEC5.
How does the client tokenize the domain name, if it doesn’t have the private key for the VRF? The name server would offer a public interface to the tokenization function. This can be done in what cryptographers call an “oblivious” VRF protocol, where the name server doesn’t see the actual domain name during the protocol, yet the client still gets the token.
To keep the resolver itself from using this interface to do an online dictionary attack that matches candidate domain names with tokens, the name server could rate-limit access, or restrict it only to authorized requesters.
Additional details on this technology may be found in U.S. Patent 9,202,079B2, entitled “Privacy preserving data querying,” and related patents.
It’s interesting from a cryptographer’s perspective that there’s a way for a client to find out whether a DNS record exists, without necessarily revealing the domain name of interest. However, as before, the benefits of this new technology will be weighed against its operational cost and complexity and compared to other approaches. Because this technique focuses on client-to-resolver interactions, it’s already one step removed from the name servers that Verisign currently operates, so it is not as relevant to our business today in a way it might have been when we started the research. This one will stay under our long-term tracking as well.
The examples I’ve shared in these last two blog posts make it clear that cryptography has the potential to bring interesting new capabilities to the DNS. While the particular examples I’ve shared here do not meet the criteria for our product roadmap, researching advances in cryptography and other techniques remains important because new events can sometimes change the calculus. That point will become even more evident in my next post, where I’ll consider the kinds of cryptography that may be needed in the event that one or more of today’s algorithms is compromised, possibly through the introduction of a quantum computer.
Read the complete six blog series:
The post Newer Cryptographic Advances for the Domain Name System: NSEC5 and Tokenized Queries appeared first on Verisign Blog.
This is the second in a multi-part blog series on cryptography and the Domain Name System (DNS).
In my previous post, I described the first broad scale deployment of cryptography in the DNS, known as the Domain Name System Security Extensions (DNSSEC). I described how a name server can enable a requester to validate the correctness of a “positive” response to a query — when a queried domain name exists — by adding a digital signature to the DNS response returned.
The designers of DNSSEC, as well as academic researchers, have separately considered the answer of “negative” responses – when the domain name doesn’t exist. In this case, as I’ll explain, responding with a signed “does not exist” is not the best design. This makes the non-existence case interesting from a cryptographer’s perspective as well.
Consider a domain name like example.arpa that doesn’t exist.
If it did exist, then as I described in my previous post, the second-level domain (SLD) server for example.arpa would return a response signed by example.arpa’s zone signing key (ZSK).
So a first try for the case that the domain name doesn’t exist is for the SLD server to return the response “example.arpa doesn’t exist,” signed by example.arpa’s ZSK.
However, if example.arpa doesn’t exist, then example.arpa won’t have either an SLD server or a ZSK to sign with. So, this approach won’t work.
A second try is for the parent name server — the .arpa top-level domain (TLD) server in the example — to return the response “example.arpa doesn’t exist,” signed by the parent’s ZSK.
This could work if the .arpa DNS server knows the ZSK for .arpa. However, for security and performance reasons, the design preference for DNSSEC has been to keep private keys offline, within the zone’s provisioning system.
The provisioning system can precompute statements about domain names that do exist — but not about every possible individual domain name that doesn’t exist. So, this won’t work either, at least not for the servers that keep their private keys offline.
The third try is the design that DNSSEC settled on. The parent name server returns a “range statement,” previously signed with the ZSK, that states that there are no domain names in an ordered sequence between two “endpoints” where the endpoints depend on domain names that do exist. The range statements can therefore be signed offline, and yet the name server can still choose an appropriate signed response to return, based on the (non-existent) domain name in the query.
The DNS community has considered several approaches to constructing range statements, and they have varying cryptographic properties. Below I’ve described two such approaches. For simplicity, I’ve focused just on the basics in the discussion that follows. The astute reader will recognize that there are many more details involved both in the specification and the implementation of these techniques.
The first approach, called NSEC, involved no additional cryptography beyond the DNSSEC signature on the range statement. In NSEC, the endpoints are actual domain names that exist. NSEC stands for “Next Secure,” referring to the fact that the second endpoint in the range is the “next” existing domain name following the first endpoint.
The NSEC resource record is documented in one of the original DNSSEC specifications, RFC4033, which was co-authored by Verisign.
The .arpa zone implements NSEC. When the .arpa server receives the request “What is the IP address of example.arpa,” it returns the response “There are no names between e164.arpa and home.arpa.” This exchange is shown in the figure below and is analyzed in the associated DNSviz graph. (The response is accurate as of the writing of this post; it could be different in the future if names were added to or removed from the .arpa zone.)
NSEC has a side effect: responses immediately reveal unqueried domain names in the zone. Depending on the sensitivity of the zone, this may be undesirable from the perspective of the minimum disclosure principle.
A second approach, called NSEC3 reduces the disclosure risk somewhat by defining the endpoints as hashes of existing domain names. (NSEC3 is documented in RFC 5155, which was also co-authored by Verisign.)
An example of NSEC3 can be seen with example.name, another domain that doesn’t exist. Here, the .name TLD server returns a range statement that “There are no domain names with hashes between 5SU9… and 5T48…”. Because the hash of example.name is “5SVV…” the response implies that “example.name” doesn’t exist.
This statement is shown in the figure below and in another DNSviz graph. (As above, the actual response could change if the .name zone changes.)
To find out which domain name corresponds to one of the hashed endpoints, an adversary would have to do a trial-and-error or “dictionary” attack across multiple guesses of domain names, to see if any has a matching hash value. Such a search could be performed “offline,” i.e., without further interaction with the name server, which is why the disclosure risk is only somewhat reduced.
NSEC and NSEC3 are mutually exclusive. Nearly all TLDs, including all TLDs operated by Verisign, implement NSEC3. In addition to .arpa, the root zone also implements NSEC.
In my next post, I’ll describe NSEC5, an approach still in the experimental stage, that replaces the hash function in NSEC3 with a verifiable random function (VRF) to protect against offline dictionary attacks. I’ll also share some research Verisign Labs has done on a complementary approach that helps protect a client’s queries for non-existent domain names from disclosure.
Read the complete six blog series:
The post Cryptographic Tools for Non-Existence in the Domain Name System: NSEC and NSEC3 appeared first on Verisign Blog.
This is the first in a multi-part blog series on cryptography and the Domain Name System (DNS).
As one of the earliest protocols in the internet, the DNS emerged in an era in which today’s global network was still an experiment. Security was not a primary consideration then, and the design of the DNS, like other parts of the internet of the day, did not have cryptography built in.
Today, cryptography is part of almost every protocol, including the DNS. And from a cryptographer’s perspective, as I described in my talk at last year’s International Cryptographic Module Conference (ICMC20), there’s so much more to the story than just encryption.
The first broad-scale deployment of cryptography in the DNS was not for confidentiality but for data integrity, through the Domain Name System Security Extensions (DNSSEC), introduced in 2005.
The story begins with the usual occurrence that happens millions of times a second around the world: a client asks a DNS resolver a query like “What is example.com’s Internet Protocol (IP) address?” The resolver in this case answers: “example.com’s IP address is 93.184.216.34”. (This is the correct answer.)
If the resolver doesn’t already know the answer to the request, then the process to find the answer goes something like this:
But how does the resolver know that the answer it ultimately receives is correct? The process defined by DNSSEC follows the same “delegation” model from root to TLD to SLD as I’ve described above.
Indeed, DNSSEC provides a way for the resolver to check that the answer is correct by validating a chain of digital signatures, by examining digital signatures at each level of the DNS hierarchy (or technically, at each “zone” in the delegation process). These digital signatures are generated using public key cryptography, a well-understood process that involves encryption using key pairs, one public and one private.
In a typical DNSSEC deployment, there are two active public keys per zone: a Key Signing Key (KSK) public key and a Zone Signing Key (ZSK) public key. (The reason for having two keys is so that one key can be changed locally, without the other key being changed.)
The responses returned to the resolver include digital signatures generated by either the corresponding KSK private key or the corresponding ZSK private key.
Using mathematical operations, the resolver checks all the digital signatures it receives in association with a given query. If they are valid, the resolver returns the “Digital Signature Validated” indicator to the client that initiated the query.
A convenient way to visualize the collection of digital signatures is as a “trust chain” from a “trust anchor” to the DNS record of interest, as shown in the figure above. The chain includes “chain links” at each level of the DNS hierarchy. Here’s how the “chain links” work:
The root KSK public key is the “trust anchor.” This key is widely distributed in resolvers so that they can independently authenticate digital signatures on records in the root zone, and thus authenticate everything else in the chain.
The root zone chain links consist of three parts:
The TLD zone chain links also consist of three parts:
The SLD zone chain links once more consist of three parts:
A resolver (or anyone else) can thereby verify the signature on any set of DNS records given the chain of public keys leading up to the trust anchor.
Note that this is a simplified view, and there are other details in practice. For instance, the various KSK public keys are also signed by their own private KSK, but I’ve omitted these signatures for brevity. The DNSViz tool provides a very nice interactive interface for browsing DNSSEC trust chains in detail, including the trust chain for example.com discussed here.
The effort to update the root KSK public key, the aforementioned “trust anchor” was one of the challenging and successful projects by the DNS community over the past couple of years. This initiative – the so-called “root KSK rollover” – was challenging because there was no easy way to determine whether resolvers actually had been updated to use the latest root KSK — remember that cryptography and security was added on rather than built into the DNS. There are many resolvers that needed to be updated, each independently managed.
The research paper “Roll, Roll, Roll your Root: A Comprehensive Analysis of the First Ever DNSSEC Root KSK Rollover” details the process of updating the root KSK. The paper, co-authored by Verisign researchers and external colleagues, received the distinguished paper award at the 2019 Internet Measurement Conference.
I’ve focused here on how a resolver validates correctness when the response to a query has a “positive” answer — i.e., when the DNS record exists. Checking correctness when the answer doesn’t exist gets even more interesting from a cryptographer’s perspective. I’ll cover this topic in my next post.
Read the complete six blog series:
The post The Domain Name System: A Cryptographer’s Perspective appeared first on Verisign Blog.
Introduction: An overview of the NICE Cybersecurity Workforce Framework In 2017, the National Institute of Standards and Technology (NIST) published Special Publication 800-181, the NICE Cybersecurity Workforce Framework (or NICE Framework); the document categorizes and describes cybersecurity work as well as the knowledge, skills and abilities (KSAs) needed by professionals to complete tasks in the […]
The post How to use the NICE Cybersecurity Workforce Framework to plan career progression: A practitioners’ guide appeared first on Infosec Resources.
Introduction In cryptography, a key is a very important piece of information used to combine with an algorithm (a cipher) to transform plaintext into ciphertext (encryption). The first step of preventive security is not encryption; however, the proper management of a cryptographic key is essential. Key management includes the generating, using, storing, archiving and deleting […]
The post The ultimate guide to encryption key management appeared first on Infosec Resources.
Introduction This article provides an overview of how printing functions work and how format strings are used to format the data being printed. Developers often use print functions for a variety of reasons such as displaying data to the users and printing debug messages. While these print functions appear to be innocent, they can cause […]
The post Introduction to Printing and Format Strings appeared first on Infosec Resources.
Introduction In the previous articles, we discussed printing functions, format strings and format string vulnerabilities. This article provides an overview of how Format String vulnerabilities can be exploited. In this article, we will begin by solving a simple challenge to leak a secret from memory. In the next article, we will discuss another example, where […]
The post How to exploit Format String Vulnerabilities appeared first on Infosec Resources.
We’ve all been spending more of our time online since the crisis hit. Whether it’s ordering food for delivery, livestreaming concerts, holding virtual parties, or engaging in a little retail therapy, the digital interactions of many Americans are on the rise. This means we’re also sharing more of our personal and financial information online, with each other and the organizations we interact with. Unfortunately, as ever, there are bad guys around every digital corner looking for a piece of the action.
The bottom line is that personally identifiable information (PII) is the currency of internet crime. And cyber-criminals will do whatever they can to get their hands on it. When they commit identity theft with this data, it can be a messy business, potentially taking months for banks and businesses to investigate before you get your money and credit rating back. At a time of extreme financial hardship, this is the last thing anyone needs.
It therefore pays to be careful about how you use your data and how you protect it. Even more: it’s time to get proactive and monitor it—to try and spot early on if it has been stolen. Here’s what you need to know to protect your identity data.
How identity theft works
First, some data on the scope of the problem. In the second quarter of 2020 alone 349,641 identity theft reports were filed with the FTC. To put that in perspective, it’s over half of the number for the whole of 2019 (650,572), when consumers reported losing more than $1.9 billion to fraud. What’s driving this huge industry? A cybercrime economy estimated to be worth as much as $1.5 trillion annually.
Specialized online marketplaces and private forums provide a user-friendly way for cyber-criminals and fraudsters to easily buy and sell stolen identity data. Many are on the so-called dark web, which is hidden from search engines and requires a specialized anonymizing browser like Tor to access. However, plenty of this criminal activity also happens in plain sight, on social media sites and messaging platforms. This underground industry is an unstoppable force: as avenues are closed down by law enforcement or criminal in-fighting, other ones appear.
At-risk personal data could be anything from email and account log-ins to medical info, SSNs, card and bank details, insurance details and much more. It all has a value on the cybercrime underground and the price fraudsters are prepared to pay will depend on supply and demand, just like in the ‘real’ world.
There are various ways for attackers to get your data. The main ones are:
|
|
The COVID-19 challenge
As if this weren’t enough, consumers are especially exposed to risk during the current pandemic. Hackers are using the COVID-19 threat as a lure to infect your PC or steal identity data via the phishing tactics described above. They often impersonate trustworthy institutions/officials and emails may claim to include new information on outbreaks, or vaccines. Clicking through or divulging your personal info will land you in trouble. Other fraud attempts will try to sell counterfeit or non-existent medical or other products to help combat infection, harvesting your card details in the process. In March, Interpol seized 34,000 counterfeit COVID goods like surgical masks and $14m worth of potentially dangerous pharmaceuticals.
Phone-based attacks are also on the rise, especially those impersonating government officials. The aim here is to steal your identity data and apply for government emergency stimulus funds in your name. Of the 349,641 identity theft reports filed with the FTC in Q2 2020, 77,684 were specific to government documents or benefits fraud.
What do cybercriminals do with my identity data?
Once your PII is stolen, it’s typically sold on the dark web to those who use it for malicious purposes. It could be used to:
|
|
How do I protect my identity online?
The good news among all this bad is that if you remain skeptical about what you see online, are cautious about what you share, and follow some other simple rules, you’ll stand a greater chance of keeping your PII under lock and key. Best practices include:
|
|
How Trend Micro can help
Trend Micro offers solutions that can help to protect your digital identity.
Trend Micro ID Security is the best way to get proactive about data protection. It works 24/7 to monitor dark web sites for your PII and will sound the alarm immediately if it finds any sign your accounts or personal data have been stolen. It features
|
|
Trend Micro Password Manager enables you to manage all your website and app log-ins from one secure location. Because Password Manager remembers and recalls your credentials on-demand, you can create long, strong and unique passwords for each account. As you’re not sharing easy-to-remember passwords across multiple accounts, you’ll be protected from popular credential stuffing and similar attacks.
Finally, Trend Micro WiFi Protection will protect you if you’re out and about connecting to WiFi hotspots. It automatically detects when a WiFi connection isn’t secure and enables a VPN—making your connection safer and helping keep your identity data private.
In short, it’s time to take an active part in protecting your personal identity data—as if your digital life depended on it. In large part, it does.
The post Identity Fraud: How to Protect Your Identity Data, Accounts and Money During the Coronavirus Crisis appeared first on .
Introduction: This article provides an overview of various techniques that can be used to mitigate Format String vulnerabilities. In addition to the mitigations that are offered by the compilers & operating systems, we will also discuss preventive measures that can be used while writing programs in languages susceptible to Format String vulnerabilities. Techniques to prevent […]
The post How to mitigate Format String Vulnerabilities appeared first on Infosec Resources.
How public-key cryptography works Public-key or asymmetric cryptography is one of the two main types of encryption algorithms. Its names come from the fact that it uses two different encryption keys: a public one and a private one. Public and private keys The private key used in public-key cryptography is a random number with certain […]
The post Public-Key Cryptography in Blockchain appeared first on Infosec Resources.
Trend Micro Research has developed a go-to resource for all things related to cybercriminal underground hosting and infrastructure. Today we released the second in this three-part series of reports which detail the what, how, and why of cybercriminal hosting (see the first part here).
As part of this report, we dive into the common life cycle of a compromised server from initial compromise to the different stages of monetization preferred by criminals. It’s also important to note that regardless of whether a company’s server is on-premise or cloud-based, criminals don’t care what kind of server they compromise.
To a criminal, any server that is exposed or vulnerable is fair game.
Cloud vs. On-Premise Servers
Cybercriminals don’t care where servers are located. They can leverage the storage space, computation resources, or steal data no matter what type of server they access. Whatever is most exposed will most likely be abused.
As digital transformation continues and potentially picks up to allow for continued remote working, cloud servers are more likely to be exposed. Many enterprise IT teams, unfortunately, are not arranged to provide the same protection for cloud as on-premise servers.
As a side note, we want to emphasize that this scenario applies only to cloud instances replicating the storage or processing power of an on-premise server. Containers or serverless functions won’t fall victim to this same type of compromise. Additionally, if the attacker compromises the cloud account, as opposed to a single running instance, then there is an entirely different attack life cycle as they can spin up computing resources at will. Although this is possible, however, it is not our focus here.
Attack Red Flags
Many IT and security teams might not look for earlier stages of abuse. Before getting hit by ransomware, however, there are other red flags that could alert teams to the breach.
If a server is compromised and used for cryptocurrency mining (also known as cryptomining), this can be one of the biggest red flags for a security team. The discovery of cryptomining malware running on any server should result in the company taking immediate action and initiating an incident response to lock down that server.
This indicator of compromise (IOC) is significant because while cryptomining malware is often seen as less serious compared to other malware types, it is also used as a monetization tactic that can run in the background while server access is being sold for further malicious activity. For example, access could be sold for use as a server for underground hosting. Meanwhile, the data could be exfiltrated and sold as personally identifiable information (PII) or for industrial espionage, or it could be sold for a targeted ransomware attack. It’s possible to think of the presence of cryptomining malware as the proverbial canary in a coal mine: This is the case, at least, for several access-as-a-service (AaaS) criminals who use this as part of their business model.
Attack Life Cycle
Attacks on compromised servers follow a common path:
|
|
The monetization lifecycle of a compromised server
Often, targeted ransomware is the final stage. In most cases, asset categorization reveals data that is valuable to the business but not necessarily valuable for espionage.
A deep understanding of the servers and network allows criminals behind a targeted ransomware attack to hit the company where it hurts the most. These criminals would know the dataset, where they live, whether there are backups of the data, and more. With such a detailed blueprint of the organization in their hands, cybercriminals can lock down critical systems and demand higher ransom, as we saw in our 2020 midyear security roundup report.
In addition, while a ransomware attack would be the visible urgent issue for the defender to solve in such an incident, the same attack could also indicate that something far more serious has likely already taken place: the theft of company data, which should be factored into the company’s response planning. More importantly, it should be noted that once a company finds an IOC for cryptocurrency, stopping the attacker right then and there could save them considerable time and money in the future.
Ultimately, no matter where a company’s data is stored, hybrid cloud security is critical to preventing this life cycle.
The post The Life Cycle of a Compromised (Cloud) Server appeared first on .
“We’re here to serve” is Benny Yazdanpanahi’s motto as CIO for City of Tyler located in Texas. Supporting a population of approximately 107,000, Yazdanpanahi’s vision for his city relies on the use of data to deliver exceptional services to citizens, today and into the future.
Since joining the city nearly 19 years ago, Yazdanpanahi has continually challenged himself and his small IT team to stay agile and to keep the needs of the city’s citizens at the forefront. Today, Yazdanpanahi and his team use IT systems to make more informed decisions, enhance community services, and improve public safety.
“Our citizens, and especially the younger generation, want immediate access to information and online services,” said Yazdanpanahi. “We want to keep pace with the latest technologies, not only for citizens but also to make our city employees more effective and efficient.”
But Yazdanpanahi knows that a highly secure IT environment is essential to their continued success. “Many US cities have been hacked, so security is on top of everyone’s mind. As a city, we want to provide great services, but we have to provide them in a highly secure manner.”
To accomplish those security goals with limited resources and staff, Tyler’s leaders have been collaborating with Trend Micro for several years. The cybersecurity giant has brought a hands-on approach and an ability to stay ahead of the threats. Their adaptability to the threat landscape strengthens the city’s security posture and empowers the IT team to focus on serving the community.
The city has been able to stay secure without additional staff and resources. City employees don’t spend time resolving IT issues and improve their productivity to focus on things that mater for the city.
“If you don’t collaborate with a partner that’s highly experienced in the security field, you can easily get blindsided,” said Yazdanpanahi. “We need someone there, day in and out, focused on security. Trend Micro knows how to protect cities like us. They provide the kind of north, south, east, and west protection that makes my job easier and allows us to use our data to accomplish new, exciting things for our city.”
Read more about Benny’s journey to securing the city:
https://www.trendmicro.com/en_ca/about/customer-stories/city-of-tyler.html
The post Connected Security Solutions Helps City of Tyler’s CIO to Reduce Costs While Enabling Delivery of Enhanced Community & Public Safety Services appeared first on .
In Part 1 of this blog, we introduced Trend Micro Cleaner One Pro, a one-stop shop to help you speed up your Mac, highlighting the Quick Optimizer, the Main Console, and the Cleaning Tools. In Part 2, we resume the discussion of how to make your Mac run faster with the remaining Cleaner One Pro features: System and Application Management, Privacy Protection, and Other Options.
Your Mac may get sluggish after a year or two of usage and you may find that booting up takes a lot longer. Doing a Startup Manager scan can help you reduce slowdown due to unwanted startup programs and services, to help your Mac boot faster.
Upon completing the scan, Startup Manager will identify apps under two categories: Login Items and Launch Agents.
Login Items are apps that run automatically upon login. You can manage these apps by enabling them to run automatically or disabling them to make your Mac more efficient. If you don’t need autorun, you can remove the apps from the list.
Launch Agents are background services that run automatically on System startup for the extension features of apps. You can manage these services by letting them run automatically or by disabling them to make your Mac boot faster. Similarly, you can remove these agents if you don’t need them or they’re broken.
When a user installs an app that doesn’t meet their expectations, they’ll never use it again. In many cases, they remove the app by simply dragging it into the trash, assuming the action completely removes the app, but this is not always true. When you uninstall an app, there are often associated files left on your Mac, even after you have emptied the Trash. They’re known as leftovers.
Leftovers are an app’s associated files and folders that can include different languages, log files, agents, or processes that might try to start an application. App Manager aims to resolve this and helps you clean up your Mac by completely removing app leftovers. App Manager detects all app leftovers automatically so you can remove them with just one click.
Data security and privacy are especially important and managing these applies to anyone collecting and keeping data. Data that has reached its retention limit needs to be permanently removed from your file system and to be sure it can’t be recovered you need to overwrite the file with random series of binary data multiple times. This process is often referred to as shredding. With File Shredder, you can remove sensitive files from your hard disk without worrying that they can be recovered.
Preferences allows you to manage how the Cleaner One Pro app performs. In Preferences, you’ll see General, Notifications, Memory, Duplicates, Whitelists and Auto Select.
On the General tab, you can choose Auto start at login and other options according to how you would like Cleaner One Pro to behave during startup.
On the Notifications tab, you can disable the notification about smart memory optimization.
Cleaner One Pro is also equipped with a Smart Memory Optimization feature on the Memory tab. This feature uses artificial intelligence. You can set auto clean when your available memory is low or when an app is closed.
The Duplicates, Whitelists and Auto Select tabs work when you use the Duplicate Files feature on the main console. When there are too many duplicate files on your Mac, you can set the rules on the minimum file size, as well as which files to exempt or prioritize during deletion.
If you need technical assistance about Cleaner One Pro, click the robot icon either in the Apple Menu window or on the Main Console.
A chat support person will attend to your concerns or suggestions when using Cleaner One Pro. In case there is no available support engineer, you can send an email by clicking Send Email. Make sure to provide the correct email address.
Aside from Cleaner One Pro for Mac, we offer Antivirus One for Mac—as well as Cleaner One for iPhone, which you can download by scanning the QR Code. You can also submit your ideas for Other Tools by clicking the panel.
As you use your Mac over time, you need to maintain it to keep it running smoothly. Trend Micro Cleaner One Pro can clean up your disk space, help boost performance, and solve other Mac issues you might encounter during your daily work. As you consider it for your Mac, you may have remaining questions:
What’s the difference between the Free version and the Paid version? The Free version of Cleaner One Pro includes the Memory Optimizer, basic CPU and Network Monitoring, a Junk Files Cleaner, a Big Files Scanner, a Disk Map, and the Startup Manager. The Paid upgrade of Cleaner One Pro unlocks more features, including more Advanced CPU/Network Monitoring, a Duplicate Finder, a Similar Photos Scanner, an App Manager, and a File Shredder.
Is it safe to use Cleaner One Pro? Cleaner One Pro is notarized by Apple, which assures its users both security and privacy.
How can I download Cleaner One Pro? Cleaner One Pro is distributed via the official Trend Micro website and other authorized channels. Note that Cleaner One Pro is also available for Windows. To make it easy for the readers of this blog series, we’ve provided the download links here: Download Mac Version – Download Windows Version
Go to Cleaner One Windows or to Cleaner One Mac for more information or to purchase the apps.
The post Cleaner One Pro Speeds Up Your Mac: Part 2 appeared first on .
The Mac has always been pretty easy to use, but even the most ardent Mac supporters know there comes a time when their Mac is no longer new and they notice slowdowns in its performance, particularly after intensive use. They’d like a handy one-stop tool to help them optimize memory and CPU performance, free up disk space, and generally speed up their Mac, since they don’t want to dig around in the MacOS for buried utilities they don’t know how to use. Fortunately, Trend Micro has a solution for that.
Trend Micro Cleaner One Pro is an easy-to-use, all-in-one disk cleaning and optimization utility that can help you boost your Mac’s performance. Cleaner One Pro includes a number of Mac housecleaning tools such as a Memory Optimizer, a Junk Files cleaner, a Big Files scanner, a Duplicate Files finder, an App Manager, a File Shredder, and a Disk Map. These functions are all rolled into an easy-to-use interface that helps you visualize your Mac’s usage, while freeing up memory and storage on your Mac.
In this two-part blog, we will show you how you can use Cleaner One Pro to make your Mac run faster, walking you through its features. In Part 1, we focus on Quick Optimizer, the Main Console, and the Cleaning Tools. In Part 2, we’ll focus on System and Application Management, Privacy Protection, and some Other Options.
Once you’ve installed Cleaner One Pro, its Quick Optimizer appears in the Apple Menu, with handy tools to speed up your Mac. Click the icon and it displays a Console that monitors your Memory, Junk Files, CPU, and Network Usage, while letting you Optimize your Memory Usage and Clean your Junk Files with just one click. System Optimizer opens a Window onto the contents of your Mac for more detailed management.
Memory Optimizer
There are applications running in the background of your Mac that take up physical memory and affect its performance. The Memory Optimizer gives you control over how your computer consumes its memory resources—and you can free up your Mac’s memory in seconds with just one click on the Optimize button. If you want to see which apps are taking up significant memory, you can click the three-dot icon next to Memory Usage. It will show your Mac’s memory usage by app, in descending order. Click the Information (i) icon in the Memory Usage window for a breakdown of the types of memory being used.
Junk files, temporary files, system files and other non-essential items will accumulate on your Mac over time. These files take up a lot of space on your hard drive and may degrade the performance of your Mac as you reach higher disk usage. Click the Clean button and the Junk Files cleaner quickly removes application cache, system log files, update files, temporary files and hidden leftover files. You can also see the details of the identified Junk Files by clicking the three-dot icon next to Junk Files.
When your computer starts to run slowly it’s helpful to have a snapshot of its CPU usage. With this feature, you can see which apps are using significant CPU resources and how much percentage they’re using. It also let you know how long your computer has been up and running, since system reliability can degrade if it’s been awhile since you restarted your Mac.
If you want to keep an eye on your bandwidth consumption and avoid exceeding data caps, it’s useful to know the real-time download and upload speeds on your Mac. The Network Usage Monitor also provides a view of other network related information such as your Wi-Fi signal quality.
The Main Console is the core workplace in Trend Micro Cleaner One Pro and provides the following features, which are presented here grouped by purpose:
|
|
To access the Main Console, click System Optimizer in the Cleaner One Pro Apple Menu. The first time you do, you’ll need to authorize full access to your disk, so Cleaner One Pro can access more junk files. Simply click Grant Access in the System Optimizer window and watch the video or follow the written instructions. Complete the steps by closing Cleaner One Pro, then reload it. You’re now ready to begin optimizing.
The hard drive on your Mac holds the entire Mac operating system and important files including your data. As you use your Mac, over time its hard drive will accumulate junk files. These junk files are generated by the system and other programs. Cleaner One Pro is equipped with advanced and efficient algorithms that scan and remove junk files within seconds. Click Scan to scan for Junk Files and when the scan is done, either check a whole category or individual items in the category, then click Remove.
You may have a lot of clutter on your Mac in the form of big or old files that you probably no longer need and may have just forgotten about. Removing big unused files can recover a lot of disk space, but it could be time-consuming to delete them if done manually. Also, it is hard to select files for deletion if you don’t know the proper context— where the files are stored or how important they may be.
Big Files scanner provides a big file collector where you can easily spot and remove these files if you don’t need them anymore. Additionally, if you hover your mouse on a file, you’ll see a magnifier and a lock icon. Once you click the magnifier icon, you’ll locate the actual file. If you click the lock icon, the file will be added to the Ignore List, which will be locked.
Disk Map is a significant tool that helps you analyze the usage of your storage in a visual and interactive map. It quickly scans your drive and builds a visualization of files on the target folder of your Mac, allowing you to easily navigate the system. With Disk Map, you can find out the date when the file/folder was created, modified, and last opened. Furthermore, hovering your mouse on a folder then clicking the magnifier icon will direct you to the file’s location.
Another practice that you are probably comfortable doing is backing-up important files, photos, program installation files and apps on your hard drive. While this is a good practice, it creates duplicate files on your Mac that eventually add clutter and consume disk space. It’s also hard to find files in name searches when you have too many of them.
The Duplicate Files function lets you select a source folder where it will inspect and identify duplicate files on your Mac. In the scan results, an option called “Auto Select” helps you automatically select duplicate files. The information provided by “Auto Select” is listed below:
|
|
You can choose Remove to Trash or Delete Permanently on the confirmation page.
Often, you organize pictures of travels and life events, and also keep a copy to ensure you don’t lose those captured moments. But as digital photos pile up, often similar to others on your drive, they take up a lot of space. To assist you cleaning these up, use Similar Photos, and then choose your photo library to scan the photos on your Mac.
The result will display similar photos and you can choose the ones you don’t need, and the files will be added in the selected list. Click the Remove button to completely delete them from your hard drive.
That’s it for now! The second part of this blog will take up the remaining toolsets of Trend Micro Cleaner One Pro.
Go to Cleaner One Mac for more information or to purchase the app.
The post Cleaner One Pro Speeds Up Your Mac: Part 1 appeared first on .
We’re all getting a little more worldly wise to the dangers that lurk around every corner of our digital lives. We know that the flipside of being able to shop, chat, bank and share online at the push of a button is the risk of data theft, ransomware and identity fraud. That’s why we protect our families’ PCs and mobile devices with security solutions from proven providers like Trend Micro, and take extra care each time we fire up the internet.
But what about the firms that we entrust to handle our data securely?
Unfortunately, many of these organizations still aren’t doing enough to protect our personal and financial information. It could be data we enter online to pay for an item or open an account. Or it could be payment card details that we’ve used at a local outlet which are subsequently stored online. These companies are big targets for the bad guys, who only have to get lucky once to crack open an Aladdin’s Cave of lucrative customer data.
What does this mean? That data breaches are the new normal. Last year in the US there were a reported 1,473 of these incidents, exposing nearly 165 million customer records. The latest affected customers of convenience store and gas station chain Wawa — and it could be one of the biggest ever, affecting 30 million cards.
Let’s take a look at what happened, and what consumers can do to steal a march on the bad guys.
What happened this time?
Wawa first notified its customers of a payment card breach in December 2019. But although the firm discovered malware on its payment processing servers that month, it had actually been sitting there since March, potentially siphoning card data silently from every single Wawa location. That’s more than 850 stores, across Pennsylvania, New Jersey, Delaware, Maryland, Virginia, Florida, and Washington DC.
The company itself has so far declined to put a number on how many customers have been affected. However, while cardholders were still wondering whether they’ve been impacted or not, something else happened. At the end of January, a hacker began to upload the stolen cards to a notorious dark web marketplace, known as Joker’s Stash.
They are claiming to have 30 million stolen cards in total, which if accurate could make this one of the biggest card breaches of its kind, placing it alongside other incidents at Home Depot (2014) and Target (2013).
How does it affect me?
Once the data goes on sale on a dark web market like this, it is usually bought by scammers, who use it in follow-on identity fraud attacks. In this case, the stolen data includes debit and credit card numbers, expiration dates and cardholder names, but not PINs or CVV records. That means they can’t be used at ATMs and fraudsters will find it hard to use the cards online, as most merchants require the CVV number.
However, if the cards are of the old magstripe type, they could be cloned for use in face-to-face transactions.
Although Wawa said it has informed the relevant card issuers and brands, the cardholders themselves must monitor their cards for unusual transactions and then report to their issuer “in a timely manner” if they want to be reimbursed for any fraudulent usage. This can be a distressing, time-consuming process.
What should I do next?
This is by no means the first and it won’t be the last breach of this kind. In the past, data stolen from customers of Hilton Hotels, supermarket chain Hy-Vee, retailer Bebe Stores, and restaurant chains including Krystal, Moe’s and Schlotzsky’s has turned up for sale on Joker’s Stash. It can be dispiriting for consumers to see their personal data time and again compromised in this way by cyber-criminals.
Too often in the aftermath of such incidents, the customers themselves are left in the dark. There is no information on whether they’ve definitively had their personal or card data stolen, just an ominous sense that something bad may be about to happen. If the company itself doesn’t even know how many cards have been affected, how can you act decisively?
Credit monitoring is often provided by breached firms, but this is a less-than-perfect solution. For one thing, such services only alert the user if a new line of credit is being opened in their name — not if a stolen card is being used. And second, they only raise the alarm after the incident, by which time the fraudsters may already have made a serious dent in your finances.
Monitoring your bank account for fraudulent transactions is arguably more useful in cases like the Wawa breach, but it’s still too reactive. Here’s a handy 2-step plan which could provide better results:
Step 1: Dark web monitoring works
To get more proactive, consumers need Dark Web monitoring. These tools typically scour dark web sites like Joker’s Stash to look for your personal information. The beauty of this approach is that it can raise the alarm after a breach has occurred, when the data is posted to the Dark Web, but before a fraudster has had time to monetize your stolen details. With this information, you can proactively request that your lender block a particular card and issue a new one.
This approach works for all personal data you may want to keep protected, including email addresses, driver’s license, passport numbers and passwords.
Step 2: Password protection
Once you’ve determined that your data has been part of a breach and is being sold on the dark web, one of the most important things you can do is to change your passwords to any stolen accounts, in order to minimize the potential damage that fraudsters can do.
This is where password manager tools can come in very handy. They allow users to store and recall long, strong and unique credentials for each of the websites and apps they use. This means that if one password is compromised, as in a breach scenario, your other accounts will remain secure. It also makes passwords harder for hackers to guess, which they may try to do with automated tools if they already have your email address.
Following a breach, it also makes sense to look out for follow-on phishing attacks which may try to trick you into handing over more information to the fraudsters. Here are a few tips:
|
|
How Trend Micro can help
Fortunately, Trend Micro has several products that can help you, as a potential or actual victim of a data breach, to proactively mitigate the fallout from a serious security incident, or to foil the fraudsters:
Trend Micro ID Security: checks if your personal information has been uploaded to Dark Web sites by hackers. This highly secure service, available in apps for Android and iOS mobile devices, uses data hashing and an encrypted connected to keep your details safe, alerting when it has found a match on the Dark Web so you can take action. Use it to protect your emails, credit card numbers, passwords, bank accounts, passport details and more.
Trend Micro Password Manager: provides a secure place to store, manage and update your passwords. It remembers your log-ins, so you can create secure and unique credentials for each website/app you need to sign-in to. This means if one site is breached, hackers will not be able to use that password to open your other accounts. Password Manager is available for Windows, Mac, iOS, and Android, synchronizing your passwords across all four platforms.
Trend Micro Fraud Buster: is a free online service you can use to check suspicious emails It uses advanced machine learning technology to identify scam emails that don’t contain malicious URLs or attachments but still pose a risk to the user, because the email (which may be extortionist) reflects the fact that the fraudster probably got your email address from the Dark Web in the first place. Users can then decide to report the scam, get more details, or proceed as before.
Fraud Buster is also now integrated into Trend Micro Security for Windows, protecting Gmail and Outlook webmail in Internet Explorer, Chrome, and Firefox. It’s also integrated in Trend Micro Antivirus for Mac, where it does the same for Gmail webmail in Safari, Chrome and Firefox on the Mac.
In the end, only you can guard your identity credentials with vigilance.
The post The Wawa Breach: 30 Million Reasons to Try Dark Web Monitoring appeared first on .
Tax season has always been a pretty nerve-wracking time for hard-working Americans. But over the years, technology advances have arrived to gradually make the process a bit easier. The bad news is that they can also introduce new cyber risks and even more stress.
There are two things that cybercriminals are always on the hunt for: people’s identity data from their accounts, and their money. And during the tax-filing season both can be unwittingly exposed. Over the years, cybercriminals have adapted multiple tools and techniques to part taxpayers with their personal information and funds.
Let’s take look at some of the main threats out there and what you can do to stay safe.
What do they want?
Cybercrime is a highly efficient money-making business. Some reports suggest this underground economy generates as much as $1.5 trillion each year. (See Into the Web of Profit, April 2018, McGuire, Bromium.) And tax-related scams are an increasingly popular way for the bad guys to drive-up profits. The Internal Revenue Service (IRS) claims that “thousands of people have lost millions of dollars and their personal information” to such attacks.
The bottom line is that they’re after one of two things: to trick you into wiring funds to them, and/or to get hold of your personally identifiable information (PII), including bank account and Social Security Numbers (SSNs). This personal data can subsequently be used to defraud you or the IRS, or may be deployed in follow-on identity fraud schemes to capture illicit funds from you.
There are various ways cyber-criminals can achieve these goals. The most common is by using social engineering tactics to trick taxpayers into sending money or personal information. But they might also use malware, either delivered to you personally or targeted at your tax preparer. This means you not only have to look after your own cybersecurity but also demand that the third-party businesses you work with store and transmit your sensitive information securely.
Look out for these scams
Here’s a round-up of the most popular tactics used by tax scammers today:
Impersonation: The fraudster gets in touch pretending to be an IRS representative. This could be via email, phone, social media or even SMS. They usually claim you owe the IRS money in unpaid taxes or fines and demand a wire transfer, or funds from a prepaid debit card. Sometimes they may ask for personal and financial details—for example, by claiming you’re entitled to a large tax refund and they just need you to supply your bank account info.
These interactions are usually pushy. The scammer knows the best way of making you pay up is by creating a sense of urgency and, sometimes, shaming the individual into believing they’ve been withholding tax payments. Phishing emails may look highly convincing, right down to the logo and sender domain, while phone callers will use fake names and badge numbers. Sometimes the scammers use personal data they may have stolen previously or bought on the Dark Web to make their communications seem more convincing.
In some impersonation scams, the fraudsters may even pretend to work for charities and ask for personal details to help disaster victims with tax refund claims.
Spoofing, phishing, and malware: In some cases, a text, email or social media message spoofed to appear as if sent from the IRS or your tax preparer actually contains malware. The scammers use the same tactics as above but trick the recipient into clicking on a malicious link or opening an attachment laden with malware. The covert download that follows could result in: theft of your personal information; your computer being completely hijacked by hackers via remote control software; or a ransomware download that locks your computer until you pay a fee.
Fake tax returns: Another trick the scammers employ is to use stolen SSNs and other personal information to file tax returns on your behalf. They can then try to claim a large payment in tax refunds from the IRS. The PII they use to file in your name may have been taken from a third-party source without your knowledge, and the first you might hear of it is when you go to file a legitimate tax return. It can take months to resolve the problem.
Attacks targeting tax preparers: Over half of Americans use third-party tax preparation companies to help them with their returns. However, this offers another opportunity for scammers to get hold of your sensitive information. In one recently discovered campaign, malware deployed on tax preparers’ websites was designed to download to the visitor’s computer as soon as they loaded the page. The IRS warns that businesses large and small are potentially at risk, as scammers are keen to get hold of tax information which enables them to file highly convincing fake returns in your name.
What to do
The good news is that by taking a few simple steps you can insulate yourself from the worst of these scams. Remember: the IRS does not contact taxpayers by email, text messages or social media to request personal/financial information— so if you receive communications that do, they are definitely a scam. It’s also important to remember that scams happen all year round, not just in the run-up to the tax filing deadline. That means, unfortunately, that you need to be on your guard all the time.
Here are a few other recommendations:
|
|
It also pays to demand that your tax preparer take their own precautions to keep your data secure. They should not be sending sensitive data or documents unencrypted in emails and must take steps on their own to combat phishing emails that target employees, since these can cascade to you during your tax preparation process. Whether hosted in the cloud or running on-premises, the servers that hold your data should also have adequate protection—and you have a right (and a duty to yourself) to ask ahead of time what they’re doing to protect it.
According to the IRS tax preparers should put the following internal controls in place:
|
|
How Trend Micro can help
Trend Micro offers a range of security tools to help taxpayers keep their personal and financial information safe from fraudsters.
Our flagship consumer solution Trend Micro Security (TMS) provides the following protections:
|
|
To find out more, go to our Trend Micro Security website.
The post Tax Scams – Everything you need to know to keep your money and data safe appeared first on .
Cybercriminals are often seen as having the upper hand over the “white hat” community. After all, they’re anonymous, can launch attacks from virtually anywhere in the world, and usually have the element of surprise. But there’s one secret weapon the good guys have: Collaboration. That’s why Trend Micro has always prioritized its partnerships with law enforcement, academia, governments and other cybersecurity businesses.
We’re proud to have contributed to yet another successful collaborative operation with INTERPOL Global Complex for Innovation (IGCI) in Singapore that’s helped to reduce the number of users infected by cryptomining malware by 78%.
Cryptomining On The Rise
Also known as cryptojacking, these attacks have become an increasingly popular way for cybercriminals to make money.
Why?
Because victims don’t know they’ve been infected. The malware sits on their machine in the background mining for digital currency 24/7/365. Increasingly, hackers have taken to launching sophisticated attacks against enterprise IT systems and cloud servers to increase their mining and earning potential. But many still target home computer systems like routers, as these are often left relatively unprotected. Stitch enough of these devices together in a botnet and they have a ready-made cash cow.
That’s why cryptojacking remained the most detected threat in the first half of 2019 in terms of file-based threat components, according to our data.
Unlike serious data breaches, phishing attacks, ransomware and banking Trojans, cryptojacking doesn’t have major impact on the victim. They don’t lose sensitive personal data, there’s no risk of follow-on identity fraud and they’re not extorted for funds by being locked out of their PC.
However, it’s not without consequences: Cryptomining malware can slow your home network to a crawl while running up serious energy bills. It may even bring your home computers to a premature end. Also, there’s always the risk with any kind of malware infection that hackers may switch tactics and use their footprint on your home machines to launch other attacks in the future.
Enter Operation Goldfish Alpha
That’s why we were keen to offer our assistance to INTERPOL during this year’s Operation Goldfish Alpha. Thanks to our broad global visibility into attack trends and infection rates, we were able to articulate the scale of the cryptojacking threat and key mitigation steps, at a pre-operation meeting with ASEAN law enforcement officers in June.
A few months later, we developed and disseminated a key Cryptojacking Mitigation and Prevention guidance document. It details how a vulnerability in MikroTik routers had exposed countless users in the region to the risk of compromise by cryptomining malware. The document explains how to scan for this flaw using Trend Micro HouseCall for Home Networks, and how HouseCall can be used to detect and delete the Coinhive JavaScript that hackers were using to mine for digital currency on infected PCs.
Spectacular Success
Over the five months of Operation Goldfish Alpha, experts from national Computer Emergency Response Teams (CERTs) and police across 10 countries in the region worked to locate the infected routers, notify the victims and use our guidance document to patch the bugs and kick out the hackers.
Having helped to identify over 20,000 routers in the region that were hacked in this way, we’re delighted to say that by November, the number had reduced by at least 78%.
That’s the value of partnerships between law enforcement and private cybersecurity companies: They combine the power of investigative policing with the detailed subject matter expertise, visibility and resources of industry experts like us. We’ll continue to lend a hand wherever we can to make our connected, digital world a safer place.
The post INTERPOL Collaboration Reduces Cryptojacking by 78% appeared first on .
FreshRSS 