BasicBlock Information Security Policy

Purpose

The purpose of this policy is to define web application security assessments within BasicBlock Inc.’s software applications.

 

Scope

This policy covers all requested web application security assessments, for the purposes of maintaining the security posture, compliance, risk management, and change control of technologies in use at BasicBlock.

 

All web application security assessments will be performed by delegated software personnel either employed or contracted by BasicBlock. All findings are considered confidential and are to be distributed to persons on a “need to know” basis.  Distribution of any findings outside of BasicBlock is strictly prohibited unless approved by the Chief Executive Officer.

 

Any relationships within multi-tiered applications found during the scoping phase will be included in the assessment unless explicitly limited.

 

Policy

Web applications are subject to security assessments based on the following criteria:

1. New or Major Application Release – will be subject to a full assessment prior to approval of the change control documentation and/or release into a production environment.
2. Point Releases – will be subject to an appropriate assessment level based on the risk of the changes in the application functionality and/or architecture.
3. Hotfix Releases – An emergency release will be allowed to forgo security assessments and carry the assumed risk until such time that a proper assessment can be carried out.  Emergency releases will be designated as such by the Head of Engineering or an appropriate manager who has been delegated this authority.

 

All security issues that are discovered during assessments must be mitigated based upon the following risk levels. The Risk Levels are based on the OWASP Risk Rating Methodology. Remediation validation testing will be required for any discovered issues of Medium risk level or greater.

 

1. High – Any high risk issue must be fixed immediately, or other mitigation strategies must be put in place to limit exposure before deployment.  Applications with high risk issues are subject to being taken off-line or denied release into the production environment.
2. Medium – Medium risk issues should be reviewed to determine what is required to mitigate and scheduled accordingly.  Applications with medium risk issues may be taken off-line or denied release into the production environment based on the number of issues and if multiple issues increase the risk to an unacceptable level.  Issues should be fixed in a patch/point release unless other mitigation strategies will limit exposure.
3. Low – Issue should be reviewed to determine what is required to correct the issue and scheduled accordingly.

 

4.3 The following security assessment levels shall be established by the software team or other designated organization that will be performing the assessments. 

1. Full – A full assessment is comprised of tests for all known web application vulnerabilities using both automated and manual tools based on the OWASP Testing Guide.  A full assessment will use manual penetration testing techniques to validate discovered vulnerabilities to determine the overall risk of any and all discovered.
2. Quick – A quick assessment will consist of a (typically) automated scan of an application for the OWASP Top Ten web application security risks at a minimum.
3. Targeted – A targeted assessment is performed to verify vulnerability remediation changes or new application functionality.

 

Policy Compliance

The Infosec team will verify compliance to this policy through various methods, including but not limited to, periodic walk-thrus, video monitoring, business tool reports, internal and external audits, and feedback to the policy owner. 

Any exception to the policy must be approved by the Infosec team in advance. 

An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment. 

Web application assessments are a requirement of the change control process and are required to adhere to this policy unless found to be exempt.   All application releases must pass through the change control process.  Any web applications that do not adhere to this policy may be taken offline until such time that a formal assessment can be performed at the discretion of the Head of Engineering.

Related Standards, Policies and Processes

OWASP Top Ten Project

OWASP Testing Guide  

OWASP Risk Rating Methodology

 

Acceptable Encryption Policy

Purpose

The purpose of this policy is to provide guidance that limits the use of encryption to those algorithms that have received substantial public review and have been proven to work effectively. Additionally, this policy provides direction to ensure that Federal regulations are followed, and legal authority is granted for the dissemination and use of encryption technologies outside of the United States.

 

Scope

This policy applies to all BasicBlock employees and affiliates.

Policy

Algorithm Requirements

Ciphers in use must meet or exceed the set defined as “AES-compatible” or “partially AES-compatible” according to the IETF/IRTF Cipher Catalog, or the set defined for use in the United States National Institute of Standards and Technology (NIST) publication FIPS 140-2, or any superseding documents according to the date of implementation. The use of the Advanced Encryption Standard (AES) is strongly recommended for symmetric encryption.

Algorithms in use must meet the standards defined for use in NIST publication FIPS 140-2 or any superseding document, according to date of implementation. The use of the RSA and Elliptic Curve Cryptography (ECC) algorithms is strongly recommended for asymmetric encryption.

Signature Algorithms 

Algorithm	Key Length (min)	Additional Comment
ECDSA	P-256	Consider RFC6090 to avoid patent infringement.
RSA	2048	Must use a secure padding scheme. PKCS#7 padding scheme is recommended. Message hashing required.
LDWM	SHA256	Refer to LDWM Hash-based Signatures Draft

 

Hash Function Requirements

In general, BasicBlock adheres to the NIST Policy on Hash Functions. 

Key Agreement and Authentication

Key exchanges must use one of the following cryptographic protocols: Diffie-Hellman, IKE, or Elliptic curve Diffie-Hellman (ECDH).

End points must be authenticated prior to the exchange or derivation of session keys.

Public keys used to establish trust must be authenticated prior to use.  Examples of authentication include transmission via cryptographically signed message or manual verification of the public key hash.

All servers used for authentication (for example, RADIUS or TACACS) must have installed a valid certificate signed by a known trusted provider.

All servers and applications using SSL or TLS must have the certificates signed by a known, trusted provider. 

Key Generation

Cryptographic keys must be generated and stored in a secure manner that prevents loss, theft, or compromise. 

Key generation must be seeded from an industry standard random number generator (RNG). For examples, see NIST Annex C: Approved Random Number Generators for FIPS PUB 140-2.  

 

Policy Compliance

The software team will verify compliance to this policy through various methods, including but not limited to, business tool reports, internal and external audits, and feedback to the policy owner. 

Any exception to the policy must be approved by the Infosec team in advance. 

An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment. 

Related Standards, Policies and Processes

National Institute of Standards and Technology (NIST) publication FIPS 140-2,

NIST Policy on Hash Functions

 

Data Breach Response Policy

Purpose

The purpose of the policy is to establish the goals and the vision for the breach response process. This policy will clearly define to whom it applies and under what circumstances, and it will include the definition of a breach, staff roles and responsibilities, standards and metrics (e.g., to enable prioritization of the incidents), as well as reporting, remediation, and feedback mechanisms. The policy shall be well publicized and made easily available to all personnel whose duties involve data privacy and security protection.

 

BasicBlock’s intentions for publishing a Data Breach Response Policy are to focus significant attention on data security and data security breaches and how BasicBlock’s established culture of openness, trust and integrity should respond to such activity. BasicBlock is committed to protecting its employees, partners and itself from illegal or damaging actions. 

Background

This policy mandates that any individual who suspects that a theft, breach or exposure of BasicBlock Protected data or BasicBlock Sensitive data has occurred must immediately provide a description of what occurred to the BasicBlock software or leaderships teams. These teams will investigate all reported thefts, data breaches and exposures to confirm if a theft, breach or exposure has occurred. If a theft, breach or exposure has occurred, the software and leadership teams will follow the established procedures.

 

Scope

This policy applies to all who handle personally identifiable information or Protected Health Information (PHI) of BasicBlock members. Any agreements with vendors will contain language similar that protects the fund.

            

 

  

Policy

As soon as a theft, data breach or exposure containing BasicBlock Protected data or BasicBlock Sensitive data is identified, the process of removing all access to that resource will begin.

 

The Head of Engineering will chair an incident response team to handle the breach or exposure. 

 

The team will include members from:

• Software
• Leadership
• Operations (if member data is affected)

 

After resolution, the team will decide how to communicate the breach to: a) internal employees, b) the public, and c) those directly affected.

 

Ownership & Responsibilities

Sponsors – Sponsors are those members of the BasicBlock community that have primary responsibility for maintaining any particular information resource. Sponsors may be designated by any BasicBlock Executive in connection with their administrative responsibilities, or by the actual sponsorship, collection, development, or storage of information.

 

Information Security Administrator is that member of the BasicBlock community, designated by the Head of Engineering, who provides administrative support for the implementation, oversight and coordination of security procedures and systems with respect to specific information resources in consultation with the relevant Sponsors.

 

Users include virtually all members of the BasicBlock community to the extent they have authorized access to information resources. 

 

The Incident Response Team shall be chaired by Head of Engineering and shall include, but will not be limited to, the following departments or their representatives: Software, Leadership, Operations.

 

Enforcement

Any personnel found in violation of this policy may be subject to disciplinary action, up to and including termination of employment. Any third party partner company found in violation may have their network connection terminated. 

              

 

Database Credentials Coding Policy

Purpose

This policy states the requirements for securely storing and retrieving database usernames and passwords (i.e., database credentials) for use by a program that will access a database running on one of BasicBlock’s networks. 

 

Software applications running on BasicBlock’s networks may require access to one of the many internal database servers. In order to access these databases, a program must authenticate to the database by presenting acceptable credentials.  If the credentials are improperly stored, the credentials may be compromised leading to a compromise of the database. 

 

Scope

This policy is directed at all system implementer and/or software engineers who may be coding applications that will access a production database server on the BasicBlock Network. This policy applies to all software (programs, modules, libraries or APIS that will access a BasicBlock, multi-user production database.  It is recommended that similar requirements be in place for non-production servers and lap environments since they don’t always use sanitized information. 

 

Policy

In order to maintain the security of BasicBlock’s internal databases, access by software programs must be granted only after authentication with credentials. The credentials used for this authentication must not reside in the main, executing body of the program’s source code in clear text. Database credentials must not be stored in a location that can be accessed through a web server. 

 

Storage of database usernames and passwords 

Database usernames and passwords may be stored in a file separate from the executing body of the program’s code. This file must not be world readable or writeable.

Database credentials may reside on the database server. In this case, a hash function number identifying the credentials may be stored in the executing body of the program’s code. 

Database credentials may be stored as part of an authentication server (i.e., an entitlement directory), such as an LDAP server used for user authentication. Database authentication may occur on behalf of a program as part of the user authentication process at the authentication server. In this case, there is no need for programmatic use of database credentials. 

Database credentials may not reside in the documents tree of a web server. 

Pass through authentication (i.e., Oracle OPS$ authentication) must not allow access to the database based solely upon a remote user’s authentication on the remote host. 

Passwords or pass phrases used to access a database must adhere to the Password Policy. 

              

Retrieval of database usernames and passwords 

If stored in a file that is not source code, then database user names and passwords must be read from the file immediately prior to use. Immediately following database authentication, the memory containing the user name and password must be released or cleared. 

The scope into which you may store database credentials must be physically separated from the other areas of your code, e.g., the credentials must be in a separate source file. The file that contains the credentials must contain no other code but the credentials (i.e., the username and password) and any functions, routines, or methods that will be used to access the credentials. 

For languages that execute from source code, the credentials’ source file must not reside in the same browseable or executable file directory tree in which the executing body of code resides. 

 

Access to database usernames and passwords 

Every program or every collection of programs implementing a single business function must have unique database credentials. Sharing of credentials between programs is not allowed. 

Database passwords used by programs are system-level passwords as defined by the Password Policy. 

Developer groups must have a process in place to ensure that database passwords are controlled and changed in accordance with the Password Policy. This process must include a method for restricting knowledge of database passwords to a need-to-know basis. 

Policy Compliance

The software team will verify compliance to this policy through various methods, including but not limited to, business tool reports, internal and external audits, and feedback to the policy owner. 

Any exception to the policy must be approved by the Infosec team in advance. 

An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment. 

A violation of this policy by a temporary worker, contractor or vendor may result in the termination of their contract or assignment with BasicBlock.

Any program code or application that is found to violate this policy must be remediated within a 90 day period.  

 

Server Security Policy

Purpose

The purpose of this policy is to establish standards for the base configuration of internal server equipment that is owned and/or operated by BasicBlock. Effective implementation of this policy will minimize unauthorized access to BasicBlock proprietary information and technology.

 

Scope

All employees, contractors, consultants, temporary and other workers at BasicBlock  must adhere to this policy. This policy applies to server equipment that is owned, operated, or leased by BasicBlock or registered under a BasicBlock-owned internal network domain. 

This policy specifies requirements for equipment on the internal BasicBlock network. 

Policy

All internal servers deployed at BasicBlock are owned by a software operational group that is responsible for system administration. Approved server configuration guides must be established and maintained by each operational group, based on business needs and approved by the Head of Engineering. Operational groups should monitor configuration compliance and implement an exception policy tailored to their environment. Each operational group must establish a process for changing the configuration guides, which includes review and approval by the software team.

Configuration changes for production servers must follow the appropriate change management procedures

1. For security, compliance, and maintenance purposes, authorized personnel may monitor and audit equipment, systems, processes, and network traffic.

 

Configuration Requirements

1. Operating System configuration should be in accordance with approved software guidelines. 
2. Services and applications that will not be used must be disabled where practical.
3. Access to services should be logged and/or protected through access-control methods such as a web application firewall, if possible. 
4. The most recent security patches must be installed on the system as soon as practical, the only exception being when immediate application would interfere with business requirements. 
5. Trust relationships between systems are a security risk, and their use should be avoided. Do not use a trust relationship when some other method of communication is sufficient. 
6. Always use standard security principles of least required access to perform a function.  Do not use root when a non-privileged account will do. 
7. If a methodology for secure channel connection is available (i.e., technically feasible), privileged access must be performed over secure channels, (e.g., encrypted network connections using SSH or IPSec). 
8. Servers should be physically located in an access-controlled environment. 
9. Servers are specifically prohibited from operating from uncontrolled cubicle areas. 

 

Monitoring

All security-related events on critical or sensitive systems must be logged and audit trails saved as follows: 

• All security related logs will be kept online for a minimum of 1 week. 
• Daily incremental tape backups will be retained for at least 1 month. 
• Weekly full tape backups of logs will be retained for at least 1 month. 
• Monthly full backups will be retained for a minimum of 2 years. 

 

Security-related events will be reported to InfoSec, who will review logs and report incidents to IT management. 

Corrective measures will be prescribed as needed. Security-related events include, but are not limited to: 

• Port-scan attacks 
• Evidence of unauthorized access to privileged accounts 
• Anomalous occurrences that are not related to specific applications on the host. 

 

Policy Compliance

The software team will verify compliance to this policy through various methods, including but not limited to, periodic walk-thrus, video monitoring, business tool reports, internal and external audits, and feedback to the policy owner. 

Any exception to the policy must be approved by the software team in advance. 

An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.