Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
There are possibilities that Government can restrict/ban crypto in the country or in any particular province. If that is the situation, the following plans helps in overcoming the problem. Also, provide the responder team who can clarify the status of that condition and possible solutions.
Always having a proactive design to avoid the regulatory compliance
A separate role to monitor the regulatory trends
Having a duplicate setup in another country
Lobby the Govt to have a Crypto friendly policy
Stay away from promoting ideas that could cause regulation issue
Have a legal counsel
Anonymous users as witnesses
Create Server space to Offload several services in other countries with Jurisdictional ability.
In order to find the solution/ to know in details about the risk that has happened, responder team is one to be communicated first.
Point of contact: Jonathan / Leadership Team
Point of contact: Team B
If the attacker has the control over the hypervisor, then the full access to VMs will be under threat. In order to overcome this situation, the following plans and ideas can be helpful. The document outcome is the ideas discussed among the SMEs.
Limit the access to admin
PEN Testing the accounts to evaluate the security. Example: Brute force test on password.
Having Backups of Hypervisor and nodes for Fallback/re-deployment
Performing Audits periodically
Updated backups that can be written over the compromised systems.
A Kill-switch to stop the process.
In order to find the solution/ to know in details about the risk that has happened, responder team is one to be communicated first.
Point of Contact: Rily and/or Robert
Point of Contact: Kyle and Haxhi
The network run the servers which can become expensive for the user based on the demands, usage and availability. In this case, to maintain the users the following plans and ideas can be useful. Also, the point of contact to understand the issue is listed in this section.
Increase liquidity to bring value to the token.
Run a node with less demand, Find a way for it.
To avoid compilation, provide the binaries of witness_node and cli_wallet.
Create best practices to build cost effective nodes
Have Periodic sync-up with other witnesses to learn about the ways remain economical.
Static-linking of libbitcoin
Publish minimum requirements to witnesses to maintain the standard spec across the platform.
Provide the Personal Package Archives (PPA) on ubuntu.
Increase witness / SON pay
In order to find the solution/ to know in details about the risk that has happened, responder team is one to be communicated first.
Point of Contact: DOCS Team
Point of Contact: Dev Team (For Static Link / PPA)
The list of risk discussed in this document are,
Too expensive servers for witnesses/SONS
Witness node not reachable
Witnesses get DDOS'd
Bad actor infiltrate witness/SONs
Power is the key factor to run any server. There are situation where the power and backup can fail to switch back which halt the servers to come up. It can be any disaster, natural calamities, accidents, etc., In order to overcome this situation, the following ideas and plans were proposed by the SMEs. This can help the user to understand the possibilities and person to help in retrieve the situation to normal.
Providing a backup to backups.
Plan Tier-3 availability.
Generators for critical operations with auto-on features over power failure.
Key actors need to have clear communication among themselves
The mirrored servers can be Off-premises
Maintenance Team with 24/7 availability
Re-deploy the services such as AWS, Linode, etc., whenever in need
Pre-written redeploy plans for critical services
Start the Generator
In order to find the solution/ to know in details about the risk that has happened, responder team is one to be communicated first.
Point of Contact: Jonathan / Maintenance Team
Point of Contact: Kyle and Riley respectively
The witness node can be unreachable at times due to several reasons. In order to overcome this situation the following ideas and plans can be helpful.
Create a witness chat room with group call functionality.
The witnesses should keep note of cell numbers of other witnesses as much as possible.
At least, one group where all the witness/ SONs should reside.
Create a separate portion for Witnesses in Scenes
A Dashboard to track the status of witnesses and chains.
Can we create a witness buddy system
Cross-post calls for action - Rocket chat, Telegram, Scenes, etc.,
Get familiar with common hubs used by witnesses
In order to find the solution/ to know in details about the risk that has happened, responder team is one to be communicated first.
Firstly, the Witnesses themselves have to communicate about the problem with the team. So that, the issue will be know to the team and solution can be provided at the earliest.
Bad actors can be a threat to any organization. As they infiltrate and gather confidential information about the company. Those action must be considered as critical and proper action must be taken to avoid the risk. The following points can help the user to have some idea about how to overcome this problem.
Follow a robust on-boarding and vetting procedure, while accepting a witnesses/SONs.
Witnesses should be able to keep their anonymity.
Implement proof of pulse consensus.
Ensure setup of witnesses is simple to lower barrier to entry.
Encourage active voting and participation.
Publish witness stats in central location periodically.
Use a White hat to identify the vulnerabilities in any account with user's consent. (White hat -Ethical security hacker)
Deeper monitoring of chain activity.
Push notification for any large transaction (Whale alert)
Establish a "Forensic Team" that can recognize any malicious activities of a witness.
In order to find the solution/ to know in details about the risk that has happened, responder team is one to be communicated first.
There are two members who can inspect the issue,
Log-Diving analyst
Forensics Team
The voters can inform about the invaders, if any.
The Risk register document helps the user to have an understanding about the risk that has occurred/ might occur in Peerplays. The document focus on the top 3 risks that are voted by the SMEs, categorized as High risk and also provides the possible solutions to solve the risk.
The document has the section which features the Responder Team which is vital to inform about the issue and to find the solution to solve the issue.
The inputs are gathered from the SMEs and categorized as mentioned below,
Bunker Issue
Core-Block Issue
Credential Security
Distributed Denial-of-Service (DDOS)
DDOS attack will deny the User to connect with any online services, sites, and application. This is a cyber attack and it's unpredictable. If a user come across any such circumstances, the below ideas, response plan can be helpful.
The following ideas are listed based on the inputs from SMEs
Having Load balancers in place.
A method to detect DDOS attack while they originate.
Using services like CloudFlare to secure the internet connectivity.
Limit the number of connections (Reasonable counts).
Direct communication with ISP NOCs.
Keeping the Backups servers Off-premises .
Find a good counter-measure software to stop/fight against the attack.
If attack has happened, the servers can be flipped to backups.
Communicate with marketing team depending on the services attacked.
In order to find the solution / to know in details about the risk that has happened, responder team is one to be communicated first.
Devops Team Point of contact: Haxhi
Development Team
The entire Peerplays network works in a Bunker. There are several things that might bring down the network. This document covers the possible risks along with the plan to solve any such occurrences. Though there are several possible risks, only 4 risks are filtered based on the audience (SME's) choice.
The list of Risks discussed are
DDOS
Hypervisor Compromised
Power and backup Failure
Crypto Restriction
Keylogger can also be as source to reveal the User's details with the hacker. A User must be aware of such malicious activities and prevent themselves from losing their information. This section helps the user with ideas and plans from SME's to overcome the situation.
If the main deployment is compromised, then shutdown & re-deploy immediately.
Run anti-virus and anti-keylogger software to scan network devices.
Create an anti-phishing system that can capture the malicious activities such as code duplication and deploying in other environment. The User should be know that the code is not from original/official.
Isolate the compromised system in locked environment to perform RCA.
Monitoring service that polls the deployment and notifies key parties whenever the hosted code changes.
Remove the infected account in the GIT lab settings.
Inform all the users and employees that will be impacted by the attack.
Perform a rapid DNS switchover to site with "Down for Maintenance" status until deployment is recovered.
Chain analysis to find the number of affected users.
Contact GitLab for help.
Any possibilities to have a counter-cyber crime employee to hack the hackers?
Article about the hacker attack, https://decrypt.co/108015/nears-rainbow-bridge-blocks-another-attack-costing-hackers-5-ethereum
In order to find the solution/ to know in details about the risk that has happened, responder team is one to be communicated first.
Point of Contact: DEV or Network Ops
Point of Contact: Community Outreach though any User forum
The risks discussed in this document are,
NEX Open source Vulnerabilities
Key Logger, access to NEX deployment
Password manager hacked
SONs active keys exposed in configuration
NEX is an open source application which might paves way for any security threat. So, this section helps the user to have some ideas to overcome the issue.
Maintain a list of "endorsed" deployments (URL list) to capture any unauthorized deployment.
Audit all the code including smart contracts, sites regularly.
PEN Test run in the production environment related to NEX
Alert message the community about the invaders.
Any scope to build API nodes that can blacklist specific services.
In order to find the solution/ to know in details about the risk that has happened, responder team is one to be communicated first.
If any suspicious activities are observed, the observer can inform about it through any User forum. All the users must be informed about it.
Point of contact: DEV OPS, NEX devs
Distributed Denial-of-service (DDOS)
In some cases, the witnesses themselves will be DDOS'd and will be denied access to use the application. This is critical and the following plans, ideas will help in sorting the issue to provide some solution.
Witnesses should have a backup or DDOS protection.
Maintain backup node which can monitor and do automatic failover.
Create a basic witnesses node that can take over automatically at once the public witnesses fail.
Create witness backup in different location.
Any temporary Fallback strategy for witness outage??
Any Recommendation to witnesses about some reliable DDOS protection service ??
Outline proper procedure to be taken during the event of DDOS attack.
Allocate individual resources to communicate periodically with witnesses about the protective measures and procedure to prevent DDOS attack.
Can vote out a witnesses who is been attacked, until they are able to get back on track
If attack is persistent, have some IAC (Infrastructure as code) to redeploy the witnesses elsewhere.
In case, if any witnesses missing blocks in a row, then Notification should pop-up.
Automated system messages in witness chat.
In order to find the solution/ to know in details about the risk that has happened, responder team is one to be communicated first.
The Witness / party that notices the issue.
The witness recovery - Liasson
If there is a possibilities that active keys getting exposed in the configuration, then the following ideas can be considered as a solution.
QA process to detect any key exposure
Proper code review has to be done before code merge to avoid conflict.
Process in place to cycle active keys.
Using active key of Operator account on server instead of SON account active key - Whether custom_permission can be used to limit the damage caused by any Key?
Can we make config files encrypted which can be accessed only via their own passphrase?
Is it possible to write SONs code not to be dependent on the active key ?
Any possibility to get certain config value comes from ENV variable?
Shut down SON, change the active key.
Vote out SON
Use Owner key to change the active key.
In order to find the solution/ to know in details about the risk that has happened, responder team is one to be communicated first.
Point of Contact: SON operator
Point of Contact: The community, who can vote out SON
A strong password is always recommended to keep the accounts safe from hackers. Still, there are many software techniques in the industry to hack the password and use it against the owner. As the world is digitalized, crimes also getting smarter to acquire our wealth. In case, if the passwordr manag is hacked, the following ideas might be helpful in overcoming the situation.
Have back-up of all stored passwords.
Keep the high-profile passwords securely and don't save them in the password manager.
If cloud services are in use, then use self hosted backup.
Use a company hosted password manager (Bitwarden)and force 2FA as one of the factor.
User should use 2FA wherever possible.
Plan to change the password periodically.
Inform all employee who will be affected by this disruption.
Use back up to reset passwords of all account.
In order to find the solution/ to know in details about the risk that has happened, responder team is one to be communicated first.
The employee whose credential has be hacked, should first inform the details to the Team. So that, the action to stop the intruder can be taken care.
Point of contact: Rily
Point of contact:
DevOps
System Admin