How Eth2.0 mitigates specific PoS (Proof of Stake) attacks
In December 2020, ETH2.0 Beacon Chain launched. This Phase 0 launched forms part of a multi-year process that will see ETH1.x transform from a PoW (Proof of Work) to a PoS (Proof of Stake) blockchain.
This is an exciting period in Ethland and is the product of years of research of optimal solutions to ensure Ethereum remains secure and decentralized despite a change of consensus mechanism. its been a long held belief that PoW has the most security guarantees unlike, say, PoS.
I have previously covered some forms of attacks against Proof of Stake chains and so, with Ethereum moving to PoS, let’s see how it intends to defend against these PoS attacks or if any are applicable at all!
Nothing at stake attack - This attack relies on the assumption of "cheap" (almost nothing) mining on forks of the same PoS (Proof of Stake) chain. Multiple forks couldn’t be detected or discouraged.
Long range attacks - this attack occurs when an adversary creates a branch/fork on the blockchain starting from the Genesis block (or thousands of blocks in the past) and overtakes the main chain, thus rewriting history.
Eth2.0’s security model is making attacks extremely expensive by putting up economic value-at-loss i.e. security relies of penalties, not rewards.
Eth2.0:
solves 1) (nothing at stake) by making use of a punitive proof of stake algorithm where validator rewards are withheld if they sign blocks on competing forks. This was called Slasher and introduced by Vitalik in 2014.
We have indeed already seen a validator get slashed ~0.25 ETH:
An ETH2.0 validator slashed due to a violation
solves 2) (long range attacks) by accepting “weak subjectivity”, which is one of the root causes of long range attacks. Weak subjectivity relates to new nodes and offline nodes that come online after a significant amount of time. These nodes would not be able to immediately distinguish which of the branches it received is the main chain. With Proof of Work, it's easy to determine the main chain as it is the one with the most proof of work, whereas in Proof of Steak, since there is no 'work' done, it's easier for such nodes to be deceived, at least for a time.
Eth2.0 Beacon Chain uses weak subjectivity checkpoints, which is a similar concept to “genesis block”, in that it’s a block that is agreed upon by the entire network as the “real” chain.
The Eth2.0 research work went a step further to determine a weak subjectivity period - which is defined as the number of recent epochs within which there must be a weak subjectivity checkpoint so that an attacker who takes control of the validator set at the beginning of the period is slashed at least a threshold amount in case a conflicting finalized checkpoint is produced.
The Ethereum re-engineering from PoW to PoS has been defined as "trying to change an airplane engine mid-flight”. It could be disastrous if it all goes wrong, but so far, all the research work and planning that went into this is moving along nicely.
I will be eagerly watching, and researching, this progress over the next 12-18 months!
Insurance taking center stage in Cyber - improving and maturing it?
Before tweeting the above, I spend some days trying to succinctly put into words what I was observing and thinking would take place in Information Security in the near future.
There is little doubt in my mind that ransomware is one of the biggest threats facing organizations and governments these days - the initial vectors of compromise vary from vulnerability exploitation to phishing (maldocs or cred stealing).
Organization Cyber Insurance
What I then started thinking of was one of the best ways to deal with this threat. Yes, we can update our systems and use 2FA and be cautious of unsolicited emails, etc but I kept coming back to insurance.
But talks of cyber insurance are nothing new.
In 2003, Pual Kurts, former Homeland Security Council and National Security Council Director, commented :
“The Insurance industry has a pivotal role to play in protecting our national infrastructure, particularly by developing cyber insurance policies”
I’m also of the view that Cyber Insurance will do more for Cyber Security maturity and resilience, than some things we have concerned ourselves with over the years due to cyber insurers’ minimum security requirements for coverage. It may feel or sound like a cop out to some in infosec, but it is what it is.
Some of the rough ideas in my mind are:
lower security maturity could mean higher insurance premiums, especially if the Org has had breaches in the past
higher security maturity could mean lesser insurance premiums (maybe)
Just as one type of control isn’t enough, I’m of the view that cyber insurance will be a norm.
Right now, perhaps it’s talked about in hushed voices in work corridors and behind closed doors in board rooms. But I fully expect it to be an open, standard thing in infosec.
Perhaps even with third-party supplier management (“ hey, we wanna do business with you, but what are your infosec policies, processes and governance? And do you have cyber cover?”) Or maybe not :-D
cyber insurance is and should be part of every Organizations arsenal for effective risk management
Cyber Insurance is the fastest growing line of business in the insurance industry and cyber insurance premiums have grown to an estimated USD 2 billion in North America and USD 3 billion globally and there are no signs of it slowing down.
We already know of a few public instances where an Organization had to pay ransom after systems where encrypted. In a few such cases, the cyber insurance actually paid :
University of Utah pays $457,000 to ransomware gang - cyber insurance pays part of the ransom
Garmin allegedly paid ransom although still unclear if their cyber insurers cough up
Over and beyond Organizational cyber insurance, one area of interest has been on the personal cyber insurance aspect.
Personal Cyber Insurance
More on the home front, with more and more home appliances connected to the internet, could we see a rise in personal/home cyber insurance?
We often joke about ones kettle getting ransomware and that spreading within your home network and preventing you from opening the fridge - but such situations, as laughable as they may be, may not be so far fetched.
A survey conducted by Swiss RE provides some interesting results:
56% of people would buy personal cyber insurance
63% preferred personal cyber insurance bundled with other services
37% preferred stand-alone cyber insurance
Some other interesting results RE: personal cyber insurance
Personal cyber insurance may yet to be developed (or maybe it already is?). I would be very interested in seeing how it pans out.
Maybe companies will provide “personal cyber insurance” as part of employment perks ;-p.
UPDATE : I came across an awesome, data filed report on cyber insurance claims. Worth a read.
What got us here, won’t get us there - Passwords
There is no doubt passwords suck. Almost every week there are articles of “millions and billions of passwords being sold by hackers”.
R20 = ~ $1.13
Continued use and mismanagement of passwords enable and finance cyber criminal marketplaces.
What makes passwords suck even more is the outdated advise most security professionals still give (in 2020!):
“make your password complex (1 Uppercase, 1 Lower case, 1 Special Char,etc)”
change your passwords every 60 - 90 days to stay secure
Security professionals still give this advise despite recommended password best practice from NIST (National Institute of Standards and Technology). Yes, NIST recommends that passwords NOT be changed often unless there is evidence of compromise; they also advise the discontinued use of password complexity.
Passwords clearly need to go. Hopefully more and more organisations already have or at least beginning to draft a road map of doing away with outdated password security practices, enabling MFA, or even better, drafting a road map for phasing out passwords where possible.
So, what are some of the exciting passwordless innovations taking place?
Microsoft
Microsoft have awesome documentation and demos of going passwordless, focusing primarily on:
Windows Hello for Business
Microsoft Authenticator App
FIDO2 Security Keys
Their passwordless authentication options for Azure Active Directory documentation is awesome and worth checking out.
Auth0
Auth0 is also doing wonders in this push, offering the following passwordless factors:
Email
Magic Link
SMS
Auth0’s documentation has awesome explanations and walk throughs.
Magic
Magic is also another player in the passwordless arena, albeit predominantly focused on the Blockchain industry. They do away with passwords and stick with email magic links (akin to Auth0).
This reduces the friction even upon sign-ups.
How sign-ups are currently done:
How magic does sign-ups:
I found Magics documentation to also be awesome and worth reading.
I’m certain there are many more companies working on this, but I only listed those I use often.
We live in interesting and exciting times, and I often wish I was a developer when I think of all the great things that can, and have, been done in recent years.
Less Friction. More Security. No passwords.
That’s the future I look forward to.
Static analysis lessons from big tech co’s
Software is eating the world - Marc Andreeseen
In 2018 and 2019, Google and Facebook released their research outputs of lessons learnt from scaling static code analysis in their respective companies. Their articles were titled Scaling Static Analyses at Facebook and Lessons from Building Static Analysis Tools at Google, respectively
These companies build software that is used by hundreds of millions of people daily, with code bases that are hundreds of thousands if not millions lines of code. The tools mentioned and used in these respective companies may not yet be Open Sourced, but the lessons shared can be applicable to most companies building their own software.
Given my current role of working with multiple engineering teams with multiple products, a few points in these Google and Facebook articles occasionally resurface in my mind every now and then. These aren’t ground breaking ideas.
Below are a few points that continue to be impressed upon me even after months of having last read those articles:
Static analysis tools can be powerful
Static code scanning is great but can be annoying when it comes to high number of false positives. These high false positive are often justification for inaction by engineering teams - and rightly so.
Work on reducing false positive cases before they are surfaced to engineering teams. For teams that have highly configured and tested static analysis tools, these can prove to be powerful enablers of security with engineering teams.
Focus on developer teams and their tool/workflow integrations
This means that static scan dashboards and outputs must feed into engineering workflows instead of requiring engineers to go out of their way to login into your separate bug dashboard/system.
Know & focus on bugs that matter
Not all bugs matter. Enable and empower engineers to address bugs that matter by using data from production to determine which those are (e.g. exploitable bugs from pentests and bug bounties). Not every bug is important enough to address as a matter of urgency.
Mental effort of context switch
If a developer is working on one problem, and they are confronted with a report on a separate problem, they must then swap out the mental context of the first problem and swap in the second, and this can be time consuming and disruptive. Try to minimize this.
Report often, report early
Report bugs to developer teams early to get optimum fix rate. In one of the articles, the engineering teams, responding to a query from the security team, reported that issues found and flagged during compile time were deemed to be more important issues compared to issues found in checked-in code.
The lessons learnt from big tech companies who have more mature processes, tools and experiences make for good reading for almost everyone in security and developers/engineering teams themselves.