Controls Catalog & Best Practices

Security at the expense of usability comes at the expense of Security. - Avi Douglen, OWASP Board of Directors

This section contains controls by framework that were identified to be material to Node Operator risks

Summary

Framework	Criterion
OWASP	A01:2022: Broken Access Control
OWASP	A10:2021: Server Side Request Forgery
SOC2 Trust Services Criteria	CC 5.2
SOC2 Trust Services Criteria	CC 6.1
SOC2 Trust Services Criteria	CC 6.3
SOC2 Trust Services Criteria	CC 6.7
SOC2 Trust Services Criteria	CC 7.1
SOC2 Trust Services Criteria	CC 7.2
SOC2 Trust Services Criteria	CC 7.3
SOC2 Trust Services Criteria	CC 7.5
SOC2 Trust Services Criteria	CC 8.1
SOC2 Trust Services Criteria	CC 8.2
SOC2 Trust Services Criteria	CC 8.3
SOC2 Trust Services Criteria	CC 9.1
SOC2 Trust Services Criteria	CC 9.2
SOC2 Trust Services Criteria	A 1.1
SOC2 Trust Services Criteria	PI 1.2
SOC2 Trust Services Criteria	PI 1.3
ISO 27001 Information security controls reference	Annex A 5.15
ISO 27001 Information security controls reference	Annex A 5.16
ISO 27001 Information security controls reference	Annex A 5.17
ISO 27001 Information security controls reference	Annex A 5.18
ISO 27001 Information security controls reference	Annex A 7
ISO 27001 Information security controls reference	Annex A 8.2
ISO 27001 Information security controls reference	Annex A 8.7
ISO 27001 Information security controls reference	Annex A 8.9
ISO 27001 Information security controls reference	Annex A 8.10
ISO 27001 Information security controls reference	Annex A 8.16
ISO 27001 Information security controls reference	Annex A 8.18
ISO 27001 Information security controls reference	Annex A 8.21
ISO 27001 Information security controls reference	Annex A 8.22
ISO 27001 Information security controls reference	Annex A 8.25
ISO 27001 Information security controls reference	Annex A 8.29
ISO 27001 Information security controls reference	Annex A 8.30
ISO 27001 Information security controls reference	Annex A 8.31
ISO 27001 Information security controls reference	Annex A 8.32

OWASP

Access Control mitigations

When it comes to access control, there are three pillars that need to be considered:

• Authentication: Ensure that no service accepts requests without some form of authentication.

• Authorization: Clearly define who can read/write/update/delete resources. Ideally, this is not done on a per-user basis, but on a per-role basis.

• Audit: Ensure that all access is logged so that you can alert on anomalies. Especially login failures should be logged.

Special considerations:

• Limit the IP sources for access.

• Disable meta-data serving through public endpoints (like what server is running in what version).

• Limit the outbound traffic of a node that runs a certain service.

• Apply rate limits to ensure that internal services cannot unintentionally DDos each other.

• Where possible apply the use of authentication tokens that have a limited lifetime.

References:

• OWASP A01:2022: Broken Access Control

Examples for best practices:

• Webserver authentication configuration of Microsoft IIS servers. Observe how different authentication methods are possible to be set there. anonymousAuthentication would allow anyone to access as anonymous, which is rarely the intention except for the starting page. basicAuthentication is better than nothing, but makes user management not scalable. clientCertificateMappingAuthentication and digestAuthentication are the better ways to also implement RBAC.

Links to risks:

• GIR1

• GIR5

• GIR7

• GIR9

Server-side request forgery mitigations

An often overlooked aspect of attack vectors is server-side request forgery. In essence, an attacker sends (almost) random messages to the server and analyzes the response. Based on that, they are able to deduce behavioral patterns that can be used for a successful attack.

The most common goal of such attacks is to create some form of an overflow. Modern load-balancers and web-servers have built-in functionality that serve as a first line of defense against such mechanisms.

Functionality to look out for when creating your application is:

• Validate the user input against a given schema where possible.

• Limit the request size that the server accepts. This includes payload and header.

• Do not use redirections or symbolic links unless absolutely necessary.

• Use rate limits to make this attack infeasible.

• When writing user-input into a database, always use Object Relational Mappers to achieve maximal protection against SQL injection.

References:

• OWASP A10:2021: Server Side Request Forgery

Examples for best practices:

• ORM systems exist for almost all programming languages and frameworks. Some of the most common ones are Hibernate, TypeORM and SQLAlchemy.

• In the Apache web-server, one can control the request size of different pieces of the request:

  • LimitRequestBody

  • LimitRequestFields

• In order to protect oneself from bad redirects, one can define proper CORS headers and a ContentSecurityPolicy. Both are set in header fileds of your Web server or load balancer.

Links to risks

• GIR8

SOC 2

Control activities to achieve operational goals

In a nutshell: technology needs to serve the business goal, not the other way around.

Main outline from the COSO principles:

1. Technology Infrastructure Control — Stakeholders develop control activities over the technology infrastructure, ensuring accuracy, availability and completeness of data.

2. Security Access Control — External threats are analyzed and access rights are properly defined.

3. Third Party tool integration — Integration, management, and updates of third party tools is closely monitored.

References:

• CC 5.2 of the Trust Services Criteria

Examples for best practices:

• Every third party software that is brought in needs to be known, and proper change management applied to it.

• Every third party software needs to be analyzed for the correct access rights with respect to users who can access it, but also the privileges it needs on the system it runs on. Examples for this are:

  • Do not run main processes as root, since a compromised software can then execute privileged operations.

  • Do not allow uncontrolled inbound and outbound networking traffic to this specific service.

Links to risks:

• GIR5

• DOW18

• DOW16

• SLS11 - SLS18

• SLS1 - SLS5

Risk assessment of one's own Node operation

Node operation does not equal node operation. There are subjective goals for each organization, and the way they decided to operate. This control ensures that one is always having an eye on risk assessments.

Main outline from the COSO principles:

1. Considers Tolerances for Risk — Identify what is acceptable.

2. Complies With Externally Established Frameworks — Consider local and international laws and benchmarks when developing the node operation.

References:

• CC 3.1 of the Trust Services Criteria

Examples for best practices:

• Ensure that every service, where possible, is configuration hardened using common benchmarks such as CIS.

• Analyze each component in your infrastructure environment in terms of security, availability, processing integrity, confidentiality and privacy.

• Outline directly which risks are a high priority, and which ones are more acceptable, and the scenarios where it applies. For example, downtime comes only with an opportunity cost for ETH stakers, but may cause a slashing event in Polkadot.

Links to risks:

• GIR24

Access Control

This is, by far, the most important mitigation. On- and off-boarding should be simple, and every piece of the infrastructure should be secured from unauthenticated and unauthorized access.

Main outline from the COSO principles:

1. Keep an inventory of information assets

2. Restrict Logical Access — Logical access to information assets, should be restricted through the use of access control software and rule sets.

3. Use authentication systems.

4. Network Segmentation — Restrict access to nodes to a minimum set of IPs.

5. Manages Points of Access — Access to nodes inside the segmented area need to be controlled with authentication and authorization methods.

6. Proper credentials management for infrastructure software — A clear definition of each credential life-time is established and enforced.

7. Protects Encryption Keys — Processes are in place to protect encryption keys for their lifetime.

References:

• CC 6.1 of Trust services Criteria

Examples for best practices:

• Creation and continuous analysis of Software Bill of Materials (SBOM).

• Use of Clients, roles and groups when using AWS IAM.

• Have an internal virtual private network and only have well-defined endpoints be accessible from the web.

• Uses of vault systems to manage credentials and encryption keys. Like AWS KMS.

Links to risks:

• DOW7

• KEC4

• GIR9

• GIR22

Implement least privilege

This mitigation goes into the authorization piece of the different users and software pieces. The principle of least access should be considered, as much as possible. Putting measures in place that restrict access to certain groups as an afterthought can become fairly expensive.

Main outline from the COSO principles:

1. Creates or Modifies Access — Processes are in place to create or modify access.

2. Quick removal of access when needed

3. Use Role-based access control (RBAC)

4. Review of roles and permissions on a regular basis.

References:

• CC 6.3 of the Trust services Criteria

Examples for best practices:

• Credentials rotation needs to be in place to ensure that there is no interruption in the service when it is done.

• Off-boarding of a terminated employee should not take more than an hour. Ideally, one would only disable them inside a single-sign-on service such as Cognito or Keycloak.

• Tools need to be in place to analyze the permissions of certain users/programs and determine if these are too wide.

• Use of roles on the API endpoint level to determine the correct authorization.

Links to risks:

• KEC11

• GIR1

• KEC8

• GIR25

Protection of Data in transit

Data remains rarely in one place. It is accessed, displayed, and analyzed. For each such operation, it needs to be ensured that there is no weakest link in the chain, and that any data in transit is protected as well.

Main outline from the COSO principles:

• Transmission of sensitive data needs to be restricted.

• Data in transit needs to be encrypted.

References:

• CC 6.7 of the trust services criteria

Examples for best practices:

• Ensuring that encrypted communication is enabled for each service. This includes, but is not limited to:

  • Databases

  • Web servers

  • Streaming services

  • Load balancers

  • Authentication systems

  • CI/CD pipeline tools

• Ensure that the latest version of TLS is being used, in combination with secure algorithms.

Links to Risks:

• KEC1 - KEC3

• KEC4 - KEC11

Capture configuration changes vulnerabilities

Main outline from the COSO principles:

• Uses defined Configuration Standards, monitor and enforce them.

• Detect configuration drift.

• Detect unwanted sofware installed on nodes.

• Conducts Vulnerability and Configuration security Scans.

References:

• CC 7.1 Trust services criteria

Examples for best practices:

• Many software pieces have defined configuration standards provided by CIS benchmarks.

• Configuration standards can be enforced by automated software (e.g. CoGuard)

• An example for monitoring software is the ELK stack. A very common centralized dashboard is Grafana.

Links to Risks:

• GIR4

• KEC8

Have Monitoring in place

Monitoring is so important, it is literally present in almost all compliance and security frameworks. It is crucial that not only high level business functions are monitored, but also correct functionality of all containers. In particular, proper log collection allows to dynamically verify that e.g. a slashing database ist actually being used, and used by the right signer.

Main outline from the COSO principles:

• Implements Detection Policies, Procedures, and Tools

• Design and improve on Detection Measures — Ideally capture unauthorized access, suspicios traffic, etc.

• Implement filters to not even let suspicious requests contact the back-end.

• Check frequently if detection tools are working correctly.

• Have one or more centralized dashboards to aggregate the data and present it in a digestible way to a human observer.

References:

• CC 7.2 of the SOC 2 trust services criteria.

Examples for best practices:

• Example of alerting setup in Grafana.

• Cognito's Userpool Addons for auditing authentications.

• Filtering and anaysis of anomalies can be done in AWS using the WAF module.

Links to Risks:

• GIR13

Analyze security events and learn from them

Main outline from the COSO principles:

• Have a proper incident response plan in place, and review it periodically.

• Communicates and Reviews Detected Security Events — Either take direct actions, or create tickets for future detection of events of a similar kind.

• Develops and Implements Procedures to Analyze Security Incidents.

References:

• CC 7.3 of the SOC 2 Trust services criteria.

Examples for best practices:

• Responses can and should also be automated. Ideally, high risk alerts cause the respective instances to be nuked.

• Always have post-mortems, ideally resulting in more unit- and integration tests of the organization.

Links to Risks:

• DOW10

• GIR6

• GIR7

Identify and respond to security incidents

Main outline from the COSO principles:

• Assigns Roles and Responsibilities in case of a security event.

• Contains Security Incidents — Ideally incidents can be contained within a short period of time.

• Communication protocols are in place to inform affected parties.

• Identified vulnerabilities need to be identified.

• Evaluate the identification and response on a regular basis.

References:

• CC 7.4 of the SOC 2 Trust services criteria

Examples for best practices:

• There are several incident response templates available. One example is NIST SP 800-61.

Links to Risks:

• RER1

• RER3

Disaster recovery

This is by far the hardest to implement and to get right, but it is useful to not "train on an incident".

Main outline from the COSO principles:

• Quick restoration of affected enviroments.

• When possible, determine the root cause.

• Implement necessary changes to prevent similar disasters.

• Implements Incident-Recovery Plan Testing periodically.

References:

• CC 7.5 of the SOC 2 Trust Services Criteria

Examples for best practices:

• Use Minikube or docker-compose to create a local copy of a production environment to perform incident recovery plan testing.

• To restore affected environments and do all the automated events, one should run

• Use Chaos monkey to put your environment through the ultimate test.

Links to Risks

• GIR19

Proper change management

This is challenging for classically set up IT operations, but is straightforward if modern Infrastructure as Code principles are being used.

Main outline from the COSO principles:

• Manages Changes Throughout the System Life Cycle — To support system availability and processing integrity, any changes need to go through a well-defined process.

• Only perform authorized changes.

• Use a version control system for infrastructure.

• Maintain configuration of software in a code-base.

• Tests are in place for system changes.

• Have a ticketing system in place to document and review suggested changes.

• Have a controlled deployment.

• Certificate management for internal and external communication.

• Have a way to directly identify historical changes to the infrastructure.

• A templated configuration of IT and control systems is created and maintained.

• Have breaking-glass change mechanisms in place for emergency situations.

• Protect confidential information to be leaked or accidentally accessed in the change management system.

References:

• CC 8.1 of the SOC 2 Trust Services Criteria

Examples for best practices:

• While this seems like a lot of points, most of them can be addressed by following the GitOps lifecycle to infrastructure.

Links to Risks

• SLS6

• SLS7

• GIR3

• GIR18

• GIR20

• GIR21

• DOW19

• DOW20

Develop Risk Mitigation Activities

Main outline from the COSO principles:

• Regularly develop and improve Mitigation of Risks of Business Disruption -- This should be automated where possible.

References:

• CC 9.1 of Trust Services Criteria

Links to Risks:

• DOW6

Vendors and business partners risk management

Main outline from the COSO principles:

• Establishes Requirements for Vendor and Business Partner Engagements.

• Assesses Vendor and Business Partner Risks - A process is in place to evaluate existing vendors.

• Ensure that previously identified issues with vendors are fixed and regressions may be identified.

• Implements Procedures for Terminating Vendor Relationships.

References:

• CC 9.2 of Trust Services Criteria

Links to risks:

• SLS8

• SLS9

• GIR5

• DOW19

Maintain the right operative capacity

Main outline from the COSO principles:

• Measures Current Usage in terms of computational resources.

• Have the ability to forecase capacity requirement changes.

• Have the ability to increse/decrease capacity when needed.

References:

• A 1.1 of the Trust Services Criteria

Examples for best practices:

• Current monitoring tools can also display a live feed of CPU and memory usage of each compute instance (Zabbix reference)

Links to risks:

• DOW1

Analyze system inputs for completeness and accuracy

Main outline from the COSO principles:

• Defines Characteristics of Processing Inputs, such as schemas.

• Evaluates Processing Inputs with defined requirements and compliance.

• Monitor the system inputs.

References:

• PI 1.2 of The Trust Services Criteria

Examples for best practices:

• Use schema and schema evolution techniques to keep your data-flow clean.

• Always define minimum and maximum input sizes and MIME types (Microsoft IIS example).

Links to Risks:

• GIR8

Analyze System outputs for completeness and accuracy

Main outline from the COSO principles:

• Inputs are processed completely, accurately, and timely.

References:

• PI 1.3 of the trust services criteria

Examples for best practices:

• Ensure that all inputs are being captured and either rejected or processed (schema enforcement).

• Data should be always referencable through a unique ID.

• Data should be examined for correctness and completeness.

• For each individual user, it should be determined if they are capable of accessing data or not. Using some technologies, such as Apache Ranger, this can be done on a row-by-row basis on a table.

Links to Risks:

• GIR16

ISO 27001

Access Control

Main outline of the Information security controls reference:

• Rules to control physical and logical access to information needs to be in place.

References:

• ISO27001 Annex A 5.15

Examples for best practices:

• Role Based Access Control.

• Implement an authentication mechanism into every service.

Links to Risks:

• SLS8

• SLS9

• GIR1

• GIR5

Identity Management

Main outline of the Information security controls reference:

• The full life-cycle of a user or service identity needs to be managed.

References:

• ISO 27001 Annex A 5.16

Examples for best practices:

• Token lifetime.

• Off-boarding mechanisms.

• Potential use of 2FA

Links to Risks:

• SLS8

• SLS9

Authentication Information

Main outline of the Information security controls reference:

• Setting, revoking and updating access control and authentication needs to be a highly controlled managed process.

References:

• ISO27001 Annex A 5.17

Examples for best practices:

• Use of an Single Sign on is preferred, and from there, all other secrets should be released to authorized users through e.g. certificates and/or vault mechanisms.

Links to Risks:

• SLS8

• SLS9

Access Rights

Main outline of the Information security controls reference:

• Access rights (authorization) needs to be reviewed regularly, and set accordingly with the organization's policies.

References:

• ISO 27001 Annex A 5.18

Examples for best practices:

• Role based access control should be used, and for each individual it needs to be automatically tested if their roles are set too wide, i.e. not minimal enough.

Links to Risks:

• SLS8

• SLS9

Physical Controls

Main outline of the Information security controls reference:

This is specific for the case where node operators are running their infrastructure on bare-metal and on their own premises.

• Protect physical areas and assets.

• Control entry to physical assets.

• All physical access to premises needs to be monitored.

• As much as possible, protect against environmental threats.

• Also secure off-site assets, if present.

• Supporting utilities, such as electricity and internet access, need to be protected.

• Maintain all equipment throughout a defined life-cycle.

• Enforce a strict rule of disposal and re-use of equipment.

References:

• ISO27001 Annex A 7

Examples for best practices:

• Camera systems at doors.

• Segregation of areas where people have access to.

• Thorough destruction of storage media.

Links to Risks:

• DOW2

Privileged access rights

Main outline of the Information security controls reference:

• Any allocation of privileged access needs to go through a proper review, audit and authorization process.

References:

• ISO27001 Annex A 8.2

Examples for best practices:

• Disable privilege escalation mechanisms (like executing as root user inside a Docker container)

• Impersonation mechanisms need to be audited (if it is enabled).

Links to Risks:

• KEC11

Protection against malware

Main outline of the Information security controls reference:

• Protection against malware needs to be implemented on all assets and users need to exercise proper caution.

References:

• ISO27001 Annex A 8.7

Examples for best practices:

• All depencencies should be checked for latest CVE entries.

Links to risks:

• GIR15

• GIR17

Configuration Management

Main outline of the Information security controls reference:

• Any configurations of infrastructure components need to be documented, implemented, monitored and reviewed.

References:

• ISO27001 Annex A 8.9

Examples:

• This includes, but is not limited to:

  • Firewall configurations

  • Docker image setups

  • Container orchestration configurations

  • Database configurations

  • Webserver/Load balancer configurations

• Automated tools to track and scan for best practices are available (e.g. CoGuard)

Links to risks:

• GIR3

• KEC8

Information deletion

Main outline of the Information security controls reference:

• Information which is no longer required needs to be safely deleted.

References:

• ISO 27001 Annex A 8.10

Examples for best practices:

• Definition and enforcement of retention periods.

• Use of thorough deletion mechanisms, such as shred.

Links to Risks:

• SLS10

• DOW17

Monitoring Activities

Main outline of the Information security controls reference:

• All infrastructure components need to be monitored and proper alerting systems need to be in place.

References:

• ISO 27001 Annex A 8.16

Examples for best practices:

• See corresponding SOC 2 control.

Links to Risks:

• GIR4

Privileged utility programs

Main outline of the Information security controls reference:

• Any software in place that requires high privileges to run should be closely monitored, and as isolated as possible.

References:

• ISO 27001 Annex A 8.18

Examples for best practices:

• If there is an application that requires privileged access, any execution of it should be audited in a log.

• Access to this application should be granted only using a certificate-based authentication which as a timeout.

Links to Risks:

• KEC11

• GIR6

• GIR7

Network services

Main outline of the Information security controls reference:

• Any traffic needs to be monitored, analyzed and potentially alerted on.

References:

• ISO 27001 Annex A 8.21

Examples for best practices:

• Segmentation of networks using security groups and subnets.

• Encryption in transit should always be enabled.

• Use and enforcement of IP whitelists

Links to Risks:

• DOW10

Segregation of networks

Main outline of the Information security controls reference:

• Use private subnets where possible, and minimize the systems that belong to a given subnet.

References:

• ISO 27001 Annex A 8.22

Examples for best practices:

• RFC 1918

• Kubernetes Cluster Networking

Links to Risks:

• DOW10

• GIR9

• KEC8

Secure development life cycle

Main outline of the Information security controls reference:

• Use best practices to ensure that software development is happening in a secure and monitored way.

References:

• ISO 27001 Annex A 8.25

Examples for best practices:

• Use of CI/CD pipelines like GitHub Actions

• Use of Linters

• Use of enforced review processes

• Not allowing to directly push to the main branch

Links to Risks:

• GIR8

• DOW19

• DOW20

• KEC8

• GIR25

Testing

Main outline of the Information security controls reference:

• Use all possible tests (dynamic, static) in the CI/CD pipeline of your development lifecycle.

References:

• ISO 27001 Annex A 8.29

Examples for best practices:

• Unit tests

• Dynamic tests

• Integration tests

Links to risks:

• GIR20

• GIR21

• DOW19

• DOW20

Outsourced development

Main outline of the Information security controls reference:

• Any outsourced development needs to be controlled, monitored and closely reviewed.

References:

• ISO 27001 Annex A 8.30

Examples for best practices:

• Proper ticketing system with clear expectations.

• Minimal access to do the job.

Links to risks:

• GIR24

Separation of development, test and production environments

Main outline of the Information security controls reference:

• Development, testing and production environments shall be separated and secured. Additionally, they should be virtually the same minus DNS, credentials and IP addresses.

References:

• ISO 27001 Annex A 8.31

Examples for best practices:

• Use docker-compose or minikube to define local-production-like environments.

• Use infrastructure as code to be able to spin up and tear down test environments.

• Have well-defined interfaces to pull part of the production data into a local database for testing.

Links to risks:

• SLS6 - SLS7

• GIR11

• GIR18

Change management

Main outline of the Information security controls reference:

• Use change management systems (e.g. GIT) for any information processing changes (infrastructure and software).

References:

• ISO 27001 Annex A 8.32

Examples for best practices:

• Using GIT also for infrastructure code and configurations.

• Use database migration systems such as Liquibase.

Links to risks:

• DOW2

• DOW11

• GIR25