UNMITIGATED RISK | un.mit.i.gat.ed: Adj. Not diminished or moderated in intensity or severity; unrel

Time 2020-11-09 02:03:54

Web Name: UNMITIGATED RISK | un.mit.i.gat.ed: Adj. Not diminished or moderated in intensity or severity; unrel

WebSite: http://unmitigatedrisk.com

ID:109584

Keywords:

Not,Adj,diminished,

Description:

Lately, I have been thinking about the history of defensive security technology. One of the purest examples here can be found in safes and vaults. The core purpose of a safe is obvious, to make it cost-prohibitive for an attacker to gain access to whatever is inside without being detected.With that said, the topic is a lot more nuanced than it seems on the surface. If we look at a safe used by a typical community bank in the 1800s, one of the things you will notice is that they often have ornate decorations on their exteriors, beautifully designed locking mechanisms and their locking mechanisms are covered by specific patents. These traits were clearly designed to signal something to the visitors of the bank, namely that they use the latest technology to keep your valuables safe. Beyond the messaging buried in the design, these safes were also designed to mitigate specific threats, for example, In the mid-1800s it was common for attackers to steal safes, use explosives to open them and to kidnap those that had access to the secrets necessary to open a safe, or those near and dear to them.In response to this reality, safe manufacturers started to use materials like manganese to manufacture safes, making the walls very thick and as a result very heavy (often 3 tons or more!), rounding corners, and using locking cylinder-shaped doors in combination to make theft or the use of explosives no longer interesting vectors for an attack.They also started incorporating time locks, to make it so if someone was kidnapped, they would still not be able to open the safe outside core business hours, essentially enabling the creation of a fully disclosed ledger of all goods stored in or withdrawn from the safe.A famous example here is from 1876 in the robbery of the Great Northfield Minnesota Bank by Jesse James and the Cole Younger gang, it was foiled due to a safe with these design characteristics.As I think about the parallels in modern technology, I can not help but to come back to a post I did this last year titled “An Evolution of Security Thinking’, in particular how we have gone from security as something you added after the fact to one where it is built into a system from the get-go. Moreover, it seems that these safes may also represent one fo the first examples of transparency being applied as a technique used to dissuade an attacker.If a safe has no tumbler on the outside, what good would it do to kidnap the bank manager? As a result, the attacker is forced to attempt their theft during business hours when the bank was busy and they would have a larger chance of getting caught.If it is obvious a safe has 12” thick walls and weighs in at over 3 tons, then stealing the safe at night, or using explosives to open the safe, given the skills and resources of the attacker, is no longer a viable path of compromise either. As a result, forcing the assailant to attack the bank during the day, when the vault may already be opened.The safe manufactures, by making their designs, and mitigations clear, were attempting to dissuade attackers from even attempting their attack. This is not materially different from how today we are applying the concepts of cryptographic transparency as a tool to mitigate other attacks.In short, transparent systems are essentially the antithesis of security by obscurity. While designing a system to be cryptographically verifiable does not necessarily require the contents of that system to be known, just as the safe design doesn t require the contents of the safe itself to be known, the use of these patterns makes it possible to intelligently reason about the security and integrity of the system.P.S. Thanks to Fotis Loukos and Yael Grauer for providing feedback on this post.Increasingly we are seeing attacks against what is now commonly referred to as the software supply chain.One of the more notable examples in the last few months was from the Nodejs package management ecosystem [1]. In this case, an attacker convinced the owner of a popular but unmaintained Node package to transfer ownership to them. The attacker than crafted a version of the package that unsuccessfully attackedCopay, a bitcoin wallet platform.This is just one example of this class of attack, insider attacks of the software supply chain are also becoming more prevalent. When looking at this risk it holistically it is also important to realize that as deployments move to the Cloud the lines between software and services also blur.Though, not specifically an example of a Cloud deployment issue, in 2015 there was a public story of how some Facebooks employees have the ability to log into users accounts without the target user s knowledge [2]. This insider risk variant of the supply chain exists in the Cloud in a number of different areas.Probably the most notable being in the container images provided by their Cloud provider. It is conceivable that a Cloud provider could be compelled by government to build images that would attack a specific or set of customers as part of an investigation, or that an employee would do so under compulsion or in service of personal interests.This is not a new risk, in fact, management of internal and external dependencies has always been core to building secure systems. What has changed is that in the rush to the Cloud and Open Source users have adopted the tools and resources these cloud providers have built to make this migration easier without fully understanding and managing this risk that they have assumed in doing so.In response to this reality, Cloud providers are starting to provide tools to help mitigate this risk, some such examples include:Providing audit records of employee access to customer data and services,Building solutions to provide hardware-based trusted execution environments that provide some level of protection from cloud providers.Offering hardware key management solutions provided by third-parties to protect sensitive key material,Cryptographically signing the binaries and images that are published so that their distribution is controlled and tampering post-production can be detected.Despite these advancements, there is still a long way to go to mitigate these risks in a holistic fashion.One effort in this area I am actively involved in is in the adoption of the concept of Binary Transparency. This can be thought of as an evolution of legacy code signing models. In these solutions, a publisher places a cryptographic signature using a private key associated with a public certificate of some sort that is either directly trusted based on package origin and signature (such as with GPG signatures) or is authenticated based on the legal identity of the publisher of the package (as is the case with Authenticode).These solutions, while valuable, help you authenticate a package but they do not provide you the tools to understand the history of that package. As a result, these publishers can produce packages either accidentally or on purpose that are malicious in nature that is signed with their trusted keys and it is not detectable until it is too late.As an example of this risk, you only need to look at RealTek, over the years numerous times their code signing key has been compromised and used to produce malware, some of it targeted such as in the case of Stuxnet [3].Binary Transparency addresses this risk in a few ways. At its core Binary Transparency can be thought of as an append-only ledger listing of all versions of a given binary, each of these versions having a pointer to a content addressable store where that binary is available.This design enables the runtime that will execute the binary to do a few things that were not possible, It can, for example, ensure it is running the most recent version of a binary and to only run the binary when it, and some number of previous revisions are publicly discoverable. This also enables the relying parties of the published binaries and images to comp it can inspect all versions and potentially diff those versions to understand the differences.When this technique is combined with the concept of reproducible builds, as is provided by Go [4] and a community of these append-only logs and auditors of those logs you can get strong assurances that:You are running the same version as everyone else,That the binary you are running is reproducible from the source you can review,The binary are running has not neen modified since it was published,That you, and others, will not run binaries or images that have not been made publicly available for inspection.A system with these properties disincentivizes the attacker from executing these attacks as it significantly increases the probability of being caught and helps bound the impact of any compromise.Importantly, by doing these things, it makes it possible to increase the trust in the Cloud offering because it minimizes the amount of trust the user must put into the Cloud provider to remain honest.A recent project that implements these concepts is the Go Module Transparency project [5] [6].Over time we will see these same techniques applied to other areas [7] [8] of the software supply chain, and with that trend, users of open source packages, automatic update systems, and the Cloud will be able to have increased peace of mind that their external dependencies are truly delivering on their promises.[1] Node.js Event-Stream Hack Exposes Supply Chain Security Risks[2] Facebook Engineers Can Access Your Account Without A Password[3] STUXNET Malware Targets SCADA Systems[4] REPRODUCING GO BINARIES BYTE-BY-BYTE[5] Proposal: Secure the Public Go Module Ecosystem[6] Transparent Logs for Skeptical Clients[7] Firefox Security/Binary Transparency[8] Contour: A Practical System for Binary TransparencyA lot of products today claim to offer End-To-End Encryption but not all of these products offer the same level of protection. Some of the differences between these solutions are rooted in the protocols and cryptography that they use, in some, it is in the way they are implemented and in others it is the way they handle the discovery of the cryptographic keys of the peers involved in the session.The topic of key discovery itself is a complicated one, on its surface, for a messaging application all you need to do is go to a directory to request the public key pairs associated with the user or their devices you will communicate with. Where things get tricky is how, as a relying party, you can tell if the key discovery mechanism is lying to you or not.This is important because if the key discovery server is lying to you it can facilitate an impersonation of that user, add a hidden third-party to the encrypted session without your knowledge, or potentially trigger a re-encryption to a device not under your control without your knowledge.To understand the implications here you just need to look at iMessage. Although many do not know this iMessage is actually End-to-End Encrypted! Matthew Green has done several great write-ups on its protocol [1] [2] and how the lack of verifiability in the key discovery mechanism utilized weakens the overall solution.The most used End-to-End Encrypted messaging application is probably Facebook s What s App. Several years ago a security researcher [3] reached out to The Guardian to discuss what they described as a backdoor in What s App, this backdoor was related to how it handled key discovery in device recovery use cases.As a product person, you often need to make trade-offs to achieve your goals and that was what happened in this case. This backdoor was a design decision that was made to ensure billions of users could get some of the End-to-End encryption protections without compromising usability.A number of security researchers, including myself, spoke up [4] which resulted in the article being updated to correctly reflect this reality [5] flawed reporting about WhatsApp.Later WhatsApp and how Key Discovery happens came up in the news again, this time in an article from Wired [6. Alex Stamos, the former Chief Security Officer of Facebook, responded to this article [7] affirming some of the article s points and talking about how a conscious decision was made to enable the associated use case: Read the Wired article today about WhatsApp – scary headline! But there is no secret way into WhatsApp groups chats. The article makes a few key points. While is response may be true, it is nor verifiably true as it relies on the behavior of the client and not cryptographic verifiability.These solutions aim to enable automated trust establishment with untrusted communication through the use of an auditable directory of all of its users keys both past and present.The fact that these solutions provide the auditable history of keys means that both the relying party and subscriber involved in the communication can reliably be made aware of when new keys have been associated with a users account, and importantly what entity added the key to the account.With this information, they applications the users are using can both prevent messagings (via policy) being sent or notify the user when keys have changed unexpectedly.This allows messaging clients to verify the identity of users automatically and prevents malicious/compromised servers from hijacking secure communications without getting caught.On the surface, this sounds much easier than it is to acomplish at least at scale. WhatsApp serves over a billion users, any solution needs to be able to deal with key updates and reads at rates necessary to support such a large user base.It needs to do this without leaking metadata associated with who the users are communicating with.And do this without significantly increasing the amount of data a user must download or the time it takes to change keys.While these are all tractable problems, they are not problems that are solved today in this context.For this reason, applications that implement End-To-End Encryption typically either provide a mechanism that users who care about these risks can use to out of band verify cryptographic keys in person [11] or simply implicitly trust the key discovery service as an honest actor.At Google, I have the pleasure of working on Google s answer to this problem [12]. It is our hope that when complete that applications that need to securely discover keys in a verifiable way can simply download our solution and focus on their application and not need to spend years of energy to solve this problem for their applications.I firmly believe the best way to ensure the right thing happens is to make sure that the right way is the easy way and fundamentally that is the goal for the Google Key Transparency effort.[1] Attack of the Week: Apple iMessage[2] Let’s talk about iMessage (again)[3] The Guardian is backtracking on a controversial story about WhatsApp[4] Security researchers call for Guardian to retract false WhatsApp “backdoor” story[5] Flawed reporting about WhatsApp[7] Read the Wired article today about WhatsApp – scary headline![8] CONIKS Project[9] OKCUPID S FOUNDERS WANT TO BRING ENCRYPTED EMAIL TO THE MASSES[10] Google’s Key Transparency project aims to ease a tough task in cryptography)[11] Safety number updatesI just had a brief exchange with a friend on Twitter who suggested that AmpliFi HD, not UniFi was the product Ubiquiti was building for users like me.I thought folks might be interested in why I didn’t go that route so here is another post

TAGS:Not Adj diminished 

<<< Thank you for your visit >>>

Hot Websites